Common Requirements for Carrier-Grade NATs (CGNs)
draft-ietf-behave-lsn-requirements-10
Yes
(Wesley Eddy)
No Objection
(Gonzalo Camarillo)
(Ralph Droms)
(Russ Housley)
Note: This ballot was opened for revision 07 and is now closed.
Wesley Eddy Former IESG member
Yes
Yes
(for -07)
Unknown
Adrian Farrel Former IESG member
No Objection
No Objection
(2012-07-19 for -08)
Unknown
I agree with Ralph and Russ
Barry Leiba Former IESG member
No Objection
No Objection
(2012-07-11 for -07)
Unknown
Substantive comments; these are non-blocking, but please consider them seriously, and feel free to chat with me about them: -- REQ-5 -- It is at the SHOULD level to account for the fact that means other than rate limiting may be used to attain the same goal. It seems, then, that there is a higher-level requirement that's missing, and that this "requirement" is really stating a suggested means to achieve it. UPDATE: Simon explains that "It" in the above quotation refers to list item B only. I'm requesting that he change "It" to "Item B" to make that clear. This state consumes resources for which, in the case of a CGN, subscribers may compete. It is necessary to ensure that each subscriber has access to a fair share of the CGN's resources. Limiting TCP sessions per subscriber and per time unit is an effective mitigation against inter-subscriber DoS attacks. UPDATE: Simon also explains that the last sentence in the paragraph above needs to be removed.
Benoît Claise Former IESG member
No Objection
No Objection
(2012-07-19 for -08)
Unknown
I'll trust the ADs who reported the DISCUSSes to solve the issues. Note that I'll have a closer look at the next version
Brian Haberman Former IESG member
No Objection
No Objection
(2012-07-12 for -08)
Unknown
1. In section 3, the text states "If NAT behavioral requirements documents are created for additional protocols, then these new documents MUST update this list by adding themselves to it." Do these new behavioral requirements documents need to update this document? Does this document need to be updated each time a new behavioral document is published as an RFC? 2. For REQ-6, what is the impact of disabling translation on state tables within the NAT? If no state is maintained, is there a DoS vulnerability for the client? For example, if I know that traffic from X2:x2 --> X1:x1 is not translated, could I use that knowledge to attack the client? 3. REQ-8 recommends not re-using a port until 120 seconds elapses. Is that value applicable to all transport protocols? How do you envision a CGN enforcing that value after a crash (as mentioned in the last paragraph of the requirement justification)?
Gonzalo Camarillo Former IESG member
No Objection
No Objection
(for -08)
Unknown
Martin Stiemerling Former IESG member
(was Discuss, No Objection)
No Objection
No Objection
(2012-08-10 for -09)
Unknown
Thank you for addressing my issue.
Pete Resnick Former IESG member
No Objection
No Objection
(2012-07-17 for -08)
Unknown
For the IESG: Perhaps I'm just being contrarian today, but I *do* think this document should be BCP and not Informational. It is not a requirements document in the sense that it is laying out requirements for future protocol documents being developed by a WG; it is a consensus document listing the requirements for the operation and administration of a type of device. If that doesn't fall within the 2nd paragraph of RFC 2026 section 5, I don't know what does. For the authors/WG: I agree with Stephen's point about REQ-1, but disagree with the solution suggested on the IESG list; I think it reversed the sense of the statement. You had: OLD: If NAT behavioral requirements documents are created for additional protocols, then these new documents MUST update this list by adding themselves to it. NEW: Any future NAT behavioral requirements documents for IPv4 transport protocols will also need to consider the requirements for CGNs stated here. But this loses the sense that new NAT behavioral requirements documents will impose new requirements on CGNs. Might I instead suggest: Any future NAT behavioral requirements documents for IPv4 transport protocols will impose additional requirements for CGNs on top of those stated here. The requirement is not a requirement for future documents; it's a requirement for CGNs.
Ralph Droms Former IESG member
(was Discuss)
No Objection
No Objection
(for -09)
Unknown
Robert Sparks Former IESG member
No Objection
No Objection
(2012-07-18 for -08)
Unknown
Ron Bonica Former IESG member
(was Discuss)
No Objection
No Objection
(2012-07-18 for -09)
Unknown
Agree with Russ that this document should be INFORMATIONAL
Russ Housley Former IESG member
(was Discuss)
No Objection
No Objection
(for -08)
Unknown
Sean Turner Former IESG member
(was Discuss)
No Objection
No Objection
(2012-07-18 for -09)
Unknown
s4: Because you gave an out in the previous paragraph it's worth noting in the following that one reason might be that the CGN isn't following 6302: This requirement is at the SHOULD level to account for the fact that there may be other reasons for logging destination addresses or ports.
Stephen Farrell Former IESG member
(was Discuss)
No Objection
No Objection
(2012-08-10 for -09)
Unknown
I still don't get why you need a MUST in REQ-4 for per-subsciber limits. Seems over contstrained to me.
Stewart Bryant Former IESG member
No Objection
No Objection
(2012-07-17 for -08)
Unknown
I agree with Russ's DISCUSS concerning the classification of this document as BCP. Informational seems more appropriate. === Why does REQ-1 not also specify draft-ietf-behave-sctpnat-06? === Limiting the rate of allocation is intended to prevent against CPU resource exhaustion. d/against/ ==== REQ-12: A CGN SHOULD NOT log destination addresses or ports. Justification: Destination logging at the CGN creates privacy issues. Why is this not "SHOULD NOT log destinations addresses or ports unless required to do so for administrative reasons" followed by privacy advice? As much as the IETF finds it distasteful, this sort of logging may well be administratively required at number of levels, and we should deal with minimizing the privacy issues when this happens. ====