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

The following approval message was sent
From: The IESG
To: "Nevil Brownlee" , draft-tsou-behave-natx4-log-reduction@ietf.org
Cc: The IESG , , 
Subject: Results of IETF-conflict review for draft-tsou-behave-natx4-log-reduction-05

The IESG has completed a review of
draft-tsou-behave-natx4-log-reduction-05 consistent with RFC5742.


The IESG has no problem with the publication of 'Port Management To
Reduce Logging In Large-Scale NATs'
as an Informational RFC.


The IESG has concluded that this work is related to active documents
in the IETF that came from the concluded working group BEHAVE, but
this relationship does not prevent publishing.



The IESG would also like the RFC-Editor to review the comments in the
datatracker related to this document and determine whether or not they
merit incorporation into the document. Comments may exist in both the
ballot and the history log.

The IESG review is documented at:
https://datatracker.ietf.org/doc/conflict-review-tsou-behave-natx4-log-reduction/

A URL of the reviewed Internet Draft is:
https://datatracker.ietf.org/doc/draft-tsou-behave-natx4-log-reduction/

The process for such documents is described at
https://www.rfc-editor.org/indsubs.html

Thank you,

The IESG Secretary

[Ballot comment]

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.

[Ballot comment]
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.

[Ballot discuss]
By making some kinds of attack easier, (the
draft 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." I'm not sure in this
case that this is making CGN so much worse that that ought
apply, but I appreciate the chance to discuss that with the IESG.
(Thanks Spencer for putting this back on to allow that to
happen.)

At the very least, I'd want to understand the degree to which
this makes things worse and as-is the draft hasn't got enough
information to allow such a calculation/estimate.

[Ballot comment]


Comments for the ISE/Authors:

- 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.

[Ballot comment]
Likely DISCUSS ballot:

By making some kinds of attack easier, (the
draft 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." I'm not sure in this
case that this is making CGN so much worse that that ought
apply, but I might have wanted to discuss that with the IESG.
At the very least, I'd want to understand the degree to which
this makes things worse and as-is the draft hasn't got enough
information to allow such a calculation/estimate.

Comments for the ISE/Authors:

- 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.

[Ballot discuss]
I think this document is related to a couple of documents produced by INTAREA, specifically RFC 6269 and RFC 6302. Given that RFC 6302 is a BCP and that Section 3 of this draft seems to further articulate on its recommendations, might this draft more properly belong in INTAREA?