Skip to main content

IETF conflict review for draft-tsou-behave-natx4-log-reduction
conflict-review-tsou-behave-natx4-log-reduction-03

Yes

(Spencer Dawkins)

No Objection

(Alia Atlas)
(Alissa Cooper)
(Alvaro Retana)
(Barry Leiba)
(Ben Campbell)
(Benoît Claise)
(Deborah Brungard)
(Joel Jaeggli)
(Martin Stiemerling)
(Terry Manderson)

Note: This ballot was opened for revision 00 and is now closed.

Ballot question: "Is this the correct conflict review response?"

Spencer Dawkins Former IESG member
Yes
Yes (for -00) Unknown

                            
Alia Atlas Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Alissa Cooper Former IESG member
(was Discuss) No Objection
No Objection (for -01) Unknown

                            
Alvaro Retana Former IESG member
No Objection
No Objection (for -00) Unknown

                            
Barry Leiba Former IESG member
No Objection
No Objection (for -00) Unknown

                            
Ben Campbell Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Benoît Claise Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Brian Haberman Former IESG member
No Objection
No Objection (2015-08-19 for -01) Unknown
I agree with Stephen's point that the recommendations are obvious.  Additionally, this document does not even reference a BCP (RFC 6302) on recommended logging procedures (as pointed out by Alissa). Given the increased security risk mentioned, the IESG needs to discuss what to do with this draft.
Deborah Brungard Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Jari Arkko Former IESG member
No Objection
No Objection (2015-08-20 for -01) Unknown
I have no firm opinion on this yet - will follow the IESG discussion with interest!
Joel Jaeggli Former IESG member
No Objection
No Objection (for -00) Unknown

                            
Kathleen Moriarty Former IESG member
No Objection
No Objection (2015-08-06 for -01) Unknown
I'm interested to see the response to Alissa's discuss.
Martin Stiemerling Former IESG member
No Objection
No Objection (for -01) Unknown

                            
Stephen Farrell Former IESG member
(was Discuss, No Objection) No Objection
No Objection (2015-08-20 for -01) Unknown
Comments for the ISE/Authors:

The IESG discussed which kind of 5742 response to send for
this because the draft makes some kinds of attack easier, (the
draft itself says "the reduced range sizes proposed by the present
document increase the attacker's chances"), this could maybe
be considered to justify a response of "The IESG has concluded
that this document extends an IETF protocol in a way that
requires IETF review and should therefore not be published
without IETF review and IESG approval."  In this case the IESG 
figured that this did not justify trying to have the draft to be 
processed in the IETF stream. (My own opinion is that it's a 
borderline case but nobody on the IESG including me strongly 
felt that we needed to try drag this into the IETF stream.)

One significant issue with that is that one cannot tell from
the draft just how much worse this might make attacks as
there is not sufficient detail in section 2 to allow one to do
any analysis of that aspect. The IESG did I think agree that
this draft would be much better if it had sufficient detail
to allow deployments to make that calculation and if the
security considerations documented how that ought be
done.

My other comments below were not discussed by the IESG.

- General: I find it very hard to see what's useful here that's
not included in the references. Section 2 is so vague as to be
utterly obvious. While a document with some real detail could
arguably be a good ISE output, an arm-wave like this seems odd
to me.

- General: there should be some recognition that any logging
of this nature generates highly privacy sensitive information
that really is better deleted as soon as can be.

- intro, para 2: "For various reasons it is necessary to log
these mappings" That is both too coy and assumes necessity
which I think is too strong a statement.

- intro; why are megabytes per second scary? Seems like a small
number to me. This ought be qualified as per binding to be a
useful estimate

- intro, last para: be better to synopsise or repeat the reqs
here - it is not very "introductory" to use such opaqueness
here

- section 2: I wonder what a bad actor could do if they knew
the block allocation scheme? was that considered? one can't
I guess describe that given there is no block allocation
scheme described in sufficient detail.
Terry Manderson Former IESG member
No Objection
No Objection (for -01) Unknown