Draft: draft-ietf-behave-nat-udp-06 Reviewer: Spencer Dawkins [spencer@mcsr-labs.org] Review Date: Friday 5/12/2006 4:17 PM CST IETF LC Date: 5/23/2006 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/ 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). 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 :-) Application aspects are out-of-scope, as the focus here is strictly on the NAT itself. Spencer: s/Application aspects/Application Level Gateway aspects/ 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? 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. 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) 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... 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. 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). 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. 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"? 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/ 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. 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)" 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?" 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...