Hi Spencer, Thanks for your comments.
According to the Gen-ART process, I'll wait for a directive from Magnus on what are the next steps. Most of the comments are editorial in nature and can easily be accomodated. Please see in-line for my comments. Magnus, let me know what you think. > -----Original Message----- > From: Spencer Dawkins [mailto:[EMAIL PROTECTED] > Sent: Friday, May 12, 2006 14:17 > To: ext Cullen Jennings; Audet, Francois [SC100:3055:EXCH] > Cc: General Area Review Team; Magnus Westerlund; Dan Wing > Subject: Gen-ART Review of draft-ietf-behave-nat-udp-06 > > > Hi, Francois and Cullen, > > I am the assigned Gen-ART reviewer for > draft-ietf-behave-nat-udp-06. For background on Gen-ART, > please see the FAQ > at<http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html>. > > Summary - this draft is almost ready for publication as a > BCP. Most of the items I noted are editorial in nature. > Section 5 and 9 have some requirements that I'd suggest be > tightened up. > > Please look at these comments along with any other Last Call > comments you may receive. > > Thanks, > > Spencer Dawkins > > (p.s. disclaimer - I have apparently looked at this draft > previously, because I'm listed in the acknowledgements > section, but I have no memory of this, so didn't recuse > myself - hope this is OK!) > > 1. Applicability Statement > > This document is meant to cover NATs of any size, from small > residential NATs to large Enterprise NATs. However, it should be > understood that Enterprise NATs normally provide much more > than just > NAT capabilities: for example, they typically provide firewall > functionalities. Firewalls are specifically out-of-scope for this > specification; however, this specification does cover the inherent > filtering aspects of NATs. > > Spencer: /filtering aspects of NATs/filtering aspects of NATs > that resembles firewall operation/ OK. I can clarify. > Approaches using directly signaled control of middle boxes such as > Midcom, UPnP, or in-path signaling are out of scope. > > Spencer: need references for these, of course (spelling out > "UPnP" would be good, too). I propose we remove "such as Midcom, UPnP, or in-path signaling". > UDP Relays are out-of-scope. > > Spencer: this document refers to both UDP relays and media > relays, without citations. I had assumed that both terms were > referring to the same thing - is this correct? Adding > citations would be clearer, but if the same term was used > throughout, that would help, too. (I also saw "UDP media > relay" a couple of times :-) I will consistently use "UDP relays". > Application aspects are out-of-scope, as the focus here is strictly > on the NAT itself. > > Spencer: s/Application aspects/Application Level Gateway aspects/ Actually, no: we meant the actual applications in this case (e.g., a gaming of VoIP app). How do you design an application for UNSAF NATs is out-of-scope. Another chartered doc is supposed to cover that. > This document only covers the UDP Unicast aspects of NAT traversal > and does not cover TCP, IPSEC, or other protocols. Since the > document is for UDP only, packet inspection above the UDP layer > (including RTP) is also out-of-scope. > > Spencer: not revisiting a recent discussion in the WG, but > this document DOES include requirements for "other protocols" > - IP and ICMP, in Sections 9, 10, and 11. It would be nice if > this paragraph reflected this. I'm not sure that the document > title needs to include this, but can see how someone might > suggest it - maybe just saying "UDP/IP" would be clear enough? I propose adding "... or other protocols unless they are related to UDP requirements." > > 2. Introduction > > Spencer: the following paragraph is the classic "NAT > Problem", but it's not the problem that's being solved in > this draft! The real introduction starts about three > paragraphs down - the real problem for this draft isn't > network address translation, it's how network address > translation is implemented, and how different implementations > can be from each other. OK. I can put some wording in there to explain that what we are tackling is the UNSAF methods, not the others. > Network Address Translators (NATs) are well known to cause very > significant problems with applications that carry IP > addresses in the > payload RFC 3027 [10]. Applications that suffer from this problem > include Voice Over IP and Multimedia Over IP (e.g., SIP [12] and > H.323 [20]), as well as online gaming. > > 4.2.1. Port Assignment Behavior > > a) Certain applications expect the source UDP port to be in the > well-known range. See RFC 2623 for an example. > > Spencer: I would suggest "See the discussion of Network File > System port expectations in RFC 2623 for an example". (most > people won't really need to chase this down, if you remind > them that RFC 2623 is about NFS) OK. > 4.2.3. Port Contiguity > > Furthermore, there is a glaring problem if many applications (or > > Spencer: "glaring problem" != "problem with 'glare'", and I > thought "glare" was obscure enough to justify "problem with > port selection collisions" anyway... Agreed. > endpoints) are trying to open mapping simultaneously. Port > preservation is also problematic since it is wasteful, especially > considering that a NAT cannot reliably distinguish between RTP over > UDP and other UDP packets where there is no contiguity rule. For > those reasons, it would be too complex to attempt to preserve the > contiguity rule by suggesting specific NAT behavior, and it would > certainly break the deterministic behavior rule. > > 4.3. Mapping Refresh > > REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 > minutes, unless REQ-5a applies. > a) A NAT MAY have UDP mapping timers that have much shorter > timers, but only for specific ports in the well-known port > range (i.e., ports 0-1023) where the IANA- > registered protocol > is strictly a request/response protocol, such as for example > DNS over UDP/53. > > Spencer: Sigh. After listening to the mailing list discussion > on this topic, the draft may really be (1) working group > consensus AND (2) the best we can achieve, but it does bother > me to assume that only registered protocols run on specific > port numbers. But I'll shut up now. So: no changes required here. > b) The value of the NAT UDP mapping timer MAY be configurable. > c) A default value of 5 minutes for the NAT UDP mapping timer is > RECOMMENDED. > > Justification: This requirement is to ensure that the > timeout is long > enough to avoid too frequent timer refresh packets. > a) Some UDP protocols using UDP use very short-lived > connections. > There can be very many such connections; keeping > them all in a > connections table could cause considerable load on the NAT. > Having shorter timers for these specific applications is > therefore an optimization technique. It is > important that the > shorter timers applied to specific protocols be used > sparingly, > and only for protocols using well-known destination port that > are known to have a shorter timer, and that are > known not to be > used by any applications for other purposes. > > Spencer: based on previous sigh - it's actually "not known to > be used", and the difference is significant. :-( > > 4.4. Conflicting Internal and External IP Address Spaces > > Spencer: I was slightly confused about one point in this > section - is REQ-7 really talking about individual addresses, > or about address spaces? If I have 10.0.0.1 and 10.0.0.3 on > one side and 10.0.0.2 on the other side, are these > "overlapping"? I'd be more comfortable if the text talked > about address spaces (that's what the section title says, anyway). I re-read this section, and it seems to me that it is pretty clear that it is talking about address spaces. Not sure exactly what specific changes you would like to see. > An alternative solution is for the NAT to be designed so > that it can > translate and forward traffic correctly even when its external and > internal interfaces are configured with numerically overlapping IP > subnets. In this scenario, for example, if the NAT's external > interface has been assigned an IP address P in RFC 1918 space, then > there might also be an internal node I having the same RFC 1918 > private IP address P. An IP packet with destination > address P on the > external network is directed at the NAT, whereas an IP packet with > the same destination address P on the internal network is > directed at > node I. The NAT therefore needs to maintain a clear operational > distinction between "external IP addresses" and "internal IP > addresses" to avoid confusing internal node I with its own external > interface. In general, the NAT needs to allow all internal nodes > (including I) to communicate with all external nodes having public > (non-RFC 1918) IP addresses or having private IP addresses that do > not conflict with the addresses used by its internal network. > > REQ-7: A NAT device whose external IP interface can be configured > dynamically MUST either (1) automatically ensure that > its internal > network uses IP addresses that do not conflict with its external > network, or (2) be able to translate and forward traffic between > all internal nodes and all external nodes whose IP addresses do > not numerically conflict with the internal network. > > Justification: If a NAT's external and internal interfaces are > configured with overlapping IP subnets, then there is > of course no > way for an internal host with RFC 1918 IP address Q to > initiate a > direct communication session to an external node having the same > RFC 1918 address Q, or to other external nodes with IP addresses > that numerically conflict with the internal subnet. Such nodes > can still open communication sessions indirectly via > NAT traversal > techniques, however, with the help of a third-party > server such as > a STUN server having a public, non-RFC 1918 IP address. In this > case, nodes with conflicting private RFC 1918 addresses on > opposite sides of the second-level NAT can communicate with each > other via their respective temporary public endpoints > on the main > Internet, as long as their common first-level NAT (e.g., the > upstream ISP's NAT) supports hairpinning behavior as > described in > Section 6. > > 5. Filtering Behavior > > Spencer: This section lists two RECOMMENDEDs (to meet two > different goals, which is fine), does not have a > mandatory-to-implement, and does not explicitly have a > recommendation (for, or against) Address and Port Dependent > Filtering in REQ-8. It would be good to include it in the > requirement, not just discuss it in the Justification. That's really by design: we didn't want to recommend anything regarding Address and port dependent. > REQ-8: If application transparency is most important, it is > RECOMMENDED that a NAT have an "Endpoint independent filtering" > behavior. If a more stringent filtering behavior is most > important, it is RECOMMENDED that a NAT have an > "Address dependent > filtering" behavior. > a) The filtering behavior MAY be an option configurable by the > administrator of the NAT. > > 6. Hairpinning Behavior > > Spencer: the following paragraph was somewhat confusing, > because I'm having to guess whether the "internal source > address" refers to an address on the NAT or the interface > address of the endpoint behind the NAT. I think I guessed > right, but I was guessing. Could this say "the X's internal > source IP address"? I can make that change. > Furthermore, the NAT may present the hairpinned packet > with either an > internal or an external source IP address and port. The > hairpinning > NAT behavior can therefore be either "External source IP > address and > port" or "Internal source IP address and port". "Internal > source IP > address and port" may cause problems by confusing implementations > that expect an external IP address and port. > > 7. Application Level Gateways > > REQ-10: If a NAT includes ALGs that affect UDP, it is RECOMMENDED > that all of those ALGs be disabled by default. > a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow > the NAT administrator to enable or disable each ALG > separately. > > Spencer: in REQ-10a), s/ALGs/multiple ALGs/ OK. > 8. Deterministic Properties > > The classification of NATs is further complicated by the fact that > under some conditions the same NAT will exhibit different > behaviors. > > Spencer: replace with "the same NAT will exhibit different > behaviors under different conditions." > > This has been seen on NATs that preserve ports or have specific > algorithms for selecting a port other than a free one. If the > > Spencer: s/other than a free one/when the desired port is > already in use/ > > external port that the NAT wishes to use is already in use > by another > session, the NAT must select a different port. This results in > different code paths for this conflict case, which results in > different behavior. > > REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT > change the NAT translation (Section 4) or the Filtering > (Section 5) Behavior at any point in time or under any > particular > conditions. > > Spencer: "under any particular conditions, unless the > behavior change is explicitly configured"? > > 9. ICMP Destination Unreachable Behavior > > REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the > NAT mapping. > a) The NAT's default configuration SHOULD NOT filter > ICMP messages > based on their source IP address. > b) It is RECOMMENDED that a NAT support ICMP Destination > Unreachable messages. > > Spencer: two points here - there is no "unless" for the > SHOULD NOT/RECOMMENDEDs, which is really needed, but after > looking at the text earlier in this section, I'm not sure why > these aren't MUST NOT/REQUIREDs, anyway. I don't really recall why it is a SHOULD instead of a MUST. > 10. Fragmentation of Outgoing Packets > > It is worth nothing that many IP stacks do not use Path > MTU Discovery > with UDP packets. > > Spencer: I probably spent too long on TCP, but isn't this > "many applications do not use"? And I don't even know what > Path MTU Discovery for UDP would look like - just set DF and > let the application figure it out? :-) > > 11. Receiving Fragmented Packets > > For a variety of reasons, a NAT may receive a fragmented > packet. The > IP packet containing the header could arrive in any fragment > depending on network conditions, packet ordering, and the > implementation of the IP stack that generated the fragments. > > A NAT that is capable only of receiving fragments in order > (that is, > with the header in the first packet) and forwarding each of the > fragments to the internal host is described as "Received Fragments > Ordered". > > A NAT that is capable of receiving fragments in or out of order and > forwarding the individual packets (or a reassembled packet) to the > > Spencer: "forwarding the individual fragments (or a > reassembled packet)" OK. > internal host is referred to as "Receive Fragments Out of Order". > See the Security Considerations section of this document for a > discussion of this behavior. > > A NAT that is neither of these is referred to as "Receive Fragments > None". > > Spencer: I didn't get "neither of these" - are you saying "is > not capable of receiving and forwarding IP fragments at all?" Correct. > And please tell me these don't exist... :^) > 12. Requirements > > Spencer: I skipped this section since it simply extracts the > requirements from the rest of the draft. > > 13. Security Considerations > > 17. References > > I was somewhat surprised to see ICMP in the references > section, but not IP or UDP... Yes, we should add UDP and IP as normative references. _______________________________________________ Gen-art mailing list [email protected] https://www1.ietf.org/mailman/listinfo/gen-art
