idnits 2.17.1 draft-ietf-behave-nat-udp-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1269. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1287. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1293. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 10, 2006) is 6401 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Obsolete informational reference (is this intentional?): RFC 2460 (Obsoleted by RFC 8200) -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-04 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-11 == Outdated reference: A later version (-04) exists of draft-jennings-behave-test-results-02 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-02 Summary: 3 errors (**), 0 flaws (~~), 5 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 BEHAVE F. Audet, Ed. 3 Internet-Draft Nortel Networks 4 Intended status: Standards Track C. Jennings 5 Expires: April 13, 2007 Cisco Systems 6 October 10, 2006 8 NAT Behavioral Requirements for Unicast UDP 9 draft-ietf-behave-nat-udp-08 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on April 13, 2007. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 This document defines basic terminology for describing different 43 types of NAT behavior when handling Unicast UDP and also defines a 44 set of requirements that would allow many applications, such as 45 multimedia communications or on-line gaming, to work consistently. 46 Developing NATs that meet this set of requirements will greatly 47 increase the likelihood that these applications will function 48 properly. 50 Table of Contents 52 1. Applicability Statement . . . . . . . . . . . . . . . . . . . 3 53 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 55 4. Network Address and Port Translation Behavior . . . . . . . . 5 56 4.1. Address and Port Mapping . . . . . . . . . . . . . . . . . 5 57 4.2. Port Assignment . . . . . . . . . . . . . . . . . . . . . 8 58 4.2.1. Port Assignment Behavior . . . . . . . . . . . . . . . 8 59 4.2.2. Port Parity . . . . . . . . . . . . . . . . . . . . . 10 60 4.2.3. Port Contiguity . . . . . . . . . . . . . . . . . . . 11 61 4.3. Mapping Refresh . . . . . . . . . . . . . . . . . . . . . 11 62 4.4. Conflicting Internal and External IP Address Spaces . . . 13 63 5. Filtering Behavior . . . . . . . . . . . . . . . . . . . . . . 14 64 6. Hairpinning Behavior . . . . . . . . . . . . . . . . . . . . . 16 65 7. Application Level Gateways . . . . . . . . . . . . . . . . . . 17 66 8. Deterministic Properties . . . . . . . . . . . . . . . . . . . 17 67 9. ICMP Destination Unreachable Behavior . . . . . . . . . . . . 19 68 10. Fragmentation of Outgoing Packets . . . . . . . . . . . . . . 19 69 11. Receiving Fragmented Packets . . . . . . . . . . . . . . . . . 20 70 12. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 20 71 13. Security Considerations . . . . . . . . . . . . . . . . . . . 22 72 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24 73 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 24 74 16. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 25 75 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 25 76 17.1. Normative References . . . . . . . . . . . . . . . . . . . 25 77 17.2. Informational References . . . . . . . . . . . . . . . . . 25 78 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27 79 Intellectual Property and Copyright Statements . . . . . . . . . . 29 81 1. Applicability Statement 83 The purpose of this specification is to define a set of requirements 84 for NATs that would allow many applications, such as multimedia 85 communications or on-line gaming, to work consistently. Developing 86 NATs that meet this set of requirements will greatly increase the 87 likelihood that these applications will function properly. 89 The requirements of this specification apply to Traditional NATs as 90 described in [RFC2663]. 92 This document is meant to cover NATs of any size, from small 93 residential NATs to large Enterprise NATs. However, it should be 94 understood that Enterprise NATs normally provide much more than just 95 NAT capabilities: for example, they typically provide firewall 96 functionalities. A comprehensive description of firewall behaviors 97 and associated requirements is specifically out-of-scope for this 98 specification. However, this specification does cover basic firewall 99 aspects present in NATs (see Section 5). 101 Approaches using directly signaled control of middle boxes are out of 102 scope. 104 UDP Relays (e.g., TURN [I-D.ietf-behave-turn]) are out-of-scope. 106 Application aspects are out-of-scope, as the focus here is strictly 107 on the NAT itself. 109 This document only covers aspects of NAT traversal related to Unicast 110 UDP [RFC0768] over IP [RFC0791] and their dependencies on other 111 protocols. 113 2. Introduction 115 Network Address Translators (NATs) are well known to cause very 116 significant problems with applications that carry IP addresses in the 117 payload (see [RFC3027]). Applications that suffer from this problem 118 include Voice Over IP and Multimedia Over IP (e.g., SIP [RFC3261] and 119 H.323 [ITU.H323]), as well as online gaming. 121 Many techniques are used to attempt to make realtime multimedia 122 applications, online games, and other applications work across NATs. 123 Application Level Gateways [RFC2663] are one such mechanism. STUN 124 [I-D.ietf-behave-rfc3489bis] describes a UNilateral Self-Address 125 Fixing (UNSAF) mechanism [RFC3424]. Teredo [RFC4380] describes an 126 UNSAF mechanism consisting of tunnelling IPv6 [RFC2460] over UDP/ 127 IPv4. UDP Relays have also been used to enable applications across 128 NATs, but these are generally seen as a solution of last resort. ICE 129 [I-D.ietf-mmusic-ice] describes a methodology for using many of these 130 techniques and avoiding a UDP relay unless the type of NAT is such 131 that it forces the use of such a UDP relay. This specification 132 defines requirements for improving NATs. Meeting these requirements 133 ensures that applications will not be forced to use UDP relay. 135 As pointed out in UNSAF [RFC3424], "From observations of deployed 136 networks, it is clear that different NAT box implementations vary 137 widely in terms of how they handle different traffic and addressing 138 cases." This wide degree of variability is one factor in the overall 139 brittleness introduced by NATs and makes it extremely difficult to 140 predict how any given protocol will behave on a network traversing 141 NAT. Discussions with many of the major NAT vendors have made it 142 clear that they would prefer to deploy NATs that were deterministic 143 and caused the least harm to applications while still meeting the 144 requirements that caused their customers to deploy NATs in the first 145 place. The problem NAT vendors face is that they are not sure how 146 best to do that or how to document how their NATs behave. 148 The goals of this document are to define a set of common terminology 149 for describing the behavior of NATs and to produce a set of 150 requirements on a specific set of behaviors for NATs. 152 This document forms a common set of requirements that are simple and 153 useful for voice, video, and games, which can be implemented by NAT 154 vendors. This document will simplify the analysis of protocols for 155 deciding whether or not they work in this environment and will allow 156 providers of services that have NAT traversal issues to make 157 statements about where their applications will work and where they 158 will not, as well as to specify their own NAT requirements. 160 3. Terminology 162 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 163 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 164 document are to be interpreted as described in [RFC2119]. 166 Readers are urged to refer to [RFC2663] for information on NAT 167 taxonomy and terminology. Traditional NAT is the most common type of 168 NAT device deployed. Readers may refer to [RFC3022] for detailed 169 information on traditional NAT. Traditional NAT has two main 170 varieties - Basic NAT and Network Address/Port Translator (NAPT). 172 NAPT is by far the most commonly deployed NAT device. NAPT allows 173 multiple internal hosts to share a single public IP address 174 simultaneously. When an internal host opens an outgoing TCP or UDP 175 session through a NAPT, the NAPT assigns the session a public IP 176 address and port number, so that subsequent response packets from the 177 external endpoint can be received by the NAPT, translated, and 178 forwarded to the internal host. The effect is that the NAPT 179 establishes a NAT session to translate the (private IP address, 180 private port number) tuple to (public IP address, public port number) 181 tuple and vice versa for the duration of the session. An issue of 182 relevance to peer-to-peer applications is how the NAT behaves when an 183 internal host initiates multiple simultaneous sessions from a single 184 (private IP, private port) endpoint to multiple distinct endpoints on 185 the external network. In this specification, the term "NAT" refers 186 to both "Basic NAT" and "Network Address/Port Translator (NAPT)". 188 This document uses the term "session" as defined in RFC 2663: "TCP/ 189 UDP sessions are uniquely identified by the tuple of (source IP 190 address, source TCP/UDP ports, target IP address, target TCP/UDP 191 Port)." 193 This document uses the term "address and port mapping" as the 194 translation between an external address and port and an internal 195 address and port. Note that this is not the same as an "address 196 binding" as defined in RFC 2663. 198 This document uses IANA terminology for port ranges, i.e., "Well 199 Known Ports" is 0-1023, "Registered" is 1024-49151, and "Dynamic 200 and/or Private" is 49152-65535, as defined in 201 http://www.iana.org/assignments/port-numbers. 203 STUN [RFC3489] used the terms "Full Cone", "Restricted Cone", "Port 204 Restricted Cone" and "Symmetric" to refer to different variations of 205 NATs applicable to UDP only. Unfortunately, this terminology has 206 been the source of much confusion as it has proven inadequate at 207 describing real-life NAT behavior. This specification therefore 208 refers to specific individual NAT behaviors instead of using the 209 Cone/Symmetric terminology. 211 4. Network Address and Port Translation Behavior 213 This section describes the various NAT behaviors applicable to NATs. 215 4.1. Address and Port Mapping 217 When an internal endpoint opens an outgoing session through a NAT, 218 the NAT assigns the session an external IP address and port number so 219 that subsequent response packets from the external endpoint can be 220 received by the NAT, translated, and forwarded to the internal 221 endpoint. This is a mapping between an internal IP address and port 222 IP:port and external IP:port tuple. It establishes the translation 223 that will be performed by the NAT for the duration of the session. 224 For many applications, it is important to distinguish the behavior of 225 the NAT when there are multiple simultaneous sessions established to 226 different external endpoints. 228 The key behavior to describe is the criteria for re-use of a mapping 229 for new sessions to external endpoints, after establishing a first 230 mapping between an internal X:x address and port and an external 231 Y1:y1 address tuple. Let's assume that the internal IP address and 232 port X:x is mapped to X1':x1' for this first session. The endpoint 233 then sends from X:x to an external address Y2:y2 and gets a mapping 234 of X2':x2' on the NAT. The relationship between X1':x1' and X2':x2' 235 for various combinations of the relationship between Y1:y1 and Y2:y2 236 is critical for describing the NAT behavior. This arrangement is 237 illustrated in the following diagram: 239 E 240 +------+ +------+ x 241 | Y1 | | Y2 | t 242 +--+---+ +---+--+ e 243 | Y1:y1 Y2:y2 | r 244 +----------+ +----------+ n 245 | | a 246 X1':x1' | | X2':x2' l 247 +--+---+-+ 248 ...........| NAT |............... 249 +--+---+-+ I 250 | | n 251 X:x | | X:x t 252 ++---++ e 253 | X | r 254 +-----+ n 255 a 256 l 258 Address and Port Mapping 260 The following address and port mapping behavior are defined: 262 Endpoint Independent Mapping: 263 The NAT reuses the port mapping for subsequent packets sent 264 from the same internal IP address and port (X:x) to any 265 external IP address and port. Specifically, X1':x1' equals 266 X2':x2' for all values of Y2:y2. 268 Address Dependent Mapping: 269 The NAT reuses the port mapping for subsequent packets sent 270 from the same internal IP address and port (X:x) to the same 271 external IP address, regardless of the external port. 272 Specifically, X1':x1' equals X2':x2' if, and only if, Y2 equals 273 Y1. 275 Address and Port Dependent Mapping: 276 The NAT reuses the port mapping for subsequent packets sent 277 from the same internal IP address and port (X:x) to the same 278 external IP address and port while the mapping is still active. 279 Specifically, X1':x1' equals X2':x2' if, and only if, Y2:y2 280 equals Y1:y1. 282 It is important to note that these three possible choices make no 283 difference to the security properties of the NAT. The security 284 properties are fully determined by which packets the NAT allows in 285 and which it does not. This is determined by the filtering behavior 286 in the filtering portions of the NAT. 288 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior. 290 Justification: In order for UNSAF methods to work, REQ-1 needs to be 291 met. Failure to meet REQ-1 will force the use of a UDP relay 292 which is very often impractical. 294 Some NATs are capable of assigning IP addresses from a pool of IP 295 addresses on the external side of the NAT, as opposed to just a 296 single IP address. This is especially common with larger NATs. Some 297 NATs use the external IP address mapping in an arbitrary fashion 298 (i.e. randomly): one internal IP address could have multiple external 299 IP address mappings active at the same time for different sessions. 300 These NATs have an "IP address pooling" behavior of "Arbitrary". 301 Some large Enterprise NATs use an IP address pooling behavior of 302 "Arbitrary" as a means of hiding the IP address assigned to specific 303 endpoints by making their assignment less predictable. Other NATs 304 use the same external IP address mapping for all sessions associated 305 with the same internal IP address. These NATs have an "IP address 306 pooling" behavior of "Paired." NATs that use an "IP address pooling" 307 behavior of "arbitrary" can cause issues for applications that use 308 multiple ports from the same endpoint but do not negotiate IP 309 addresses individually (e.g., some applications using RTP and RTCP). 311 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 312 behavior of "Paired". Note that this requirement is not 313 applicable to NATs that do not support IP address pooling. 315 Justification: This will allow applications that use multiple ports 316 originating from the same internal IP address to also have the 317 same external IP address. This is to avoid breaking peer-to-peer 318 applications that are not capable of negotiating the IP address 319 for RTP and the IP address for RTCP separately. As such it is 320 envisioned that this requirement will become less important as 321 applications become NAT-friendlier with time. The main reason why 322 this requirement is here is that in a peer-to-peer application, 323 you are subject to the other peer's mistake. In particular, in 324 the context of SIP, if my application supports the extensions 325 defined in [RFC3605] for indicating RTP and RTCP addresses and 326 ports separately, but the other peer does not, there may still be 327 breakage in the form of the stream losing RTCP packets. This 328 requirement will avoid the loss of RTP in this context, although 329 the loss of RTCP may be inevitable in this particular example. It 330 is also worth noting that RFC 3605 is unfortunately not a 331 mandatory part of SIP (RFC 3261). This requirement will therefore 332 address a particularly nasty problem that will prevail for a 333 significant period of time. 335 4.2. Port Assignment 337 4.2.1. Port Assignment Behavior 339 This section uses the following diagram for reference. 341 E 342 +-------+ +-------+ x 343 | Y1 | | Y2 | t 344 +---+---+ +---+---+ e 345 | Y1:y1 Y2:y2 | r 346 +---------+ +---------+ n 347 | | a 348 X1':x1' | | X2':x2' l 349 +--+---+--+ 350 ...........| NAT |............... 351 +--+---+--+ I 352 | | n 353 +---------+ +---------+ t 354 | X1:x1 X2':x2 | e 355 +---+---+ +---+---+ r 356 | X1 | | X2 | n 357 +-------+ +-------+ a 358 l 360 Port Assignment 362 Some NATs attempt to preserve the port number used internally when 363 assigning a mapping to an external IP address and port (e.g., 364 x=x1=x2=x1'=x2', or more succinctly, a mapping of X:x to X':x). A 365 basic NAT, for example, will preserve the same port and will assign a 366 different IP address from a pool of external IP addresses in case of 367 port collision (e.g. X1:x to X1':x and X2:x to X2':x). This is only 368 possible as long as the NAT has enough external IP addresses. If the 369 port x is already in use on all available external IP addresses, then 370 the NAT needs to switch from Basic NAT to Network Address and Port 371 Translator (NAPT) mode (i.e., X'=X1'=X2' and x=x1=x2 but x1'!=x2', or 372 a mapping of X1:x to X':x1' and X2:x to X':x2'). This port 373 assignment behavior is referred to as "port preservation". It does 374 not guarantee that the external port x' will always be the same as 375 the internal port x but only that the NAT will preserve the port if 376 possible. 378 A NAT that does not attempt to make the external port numbers match 379 the internal port numbers in any case (i.e., X1:x to X':x1', X2:x to 380 X':x2') is referred to as "No port preservation". 382 Some NATs use "Port overloading", i.e. they always use port 383 preservation even in the case of collision (i.e., X'=X1'=X2' and 384 x=x1=x2=x1'=x2', or a mapping of X1:x to X':x, and X2:x to X':x). 385 These NATs rely on the source of the response from the external 386 endpoint (Y1:y1, Y2:y2) to forward a packet to the proper internal 387 endpoint (X1 or X2). Port overloading fails if the two internal 388 endpoints are establishing sessions to the same external destination. 390 Most applications fail in some cases with "Port overloading". It is 391 clear that "Port overloading" behavior will result in many problems. 392 For example it will fail if two internal endpoints try to reach the 393 same external destination, e.g., a SIP proxy server used by both 394 endpoints. 396 When NATs do allocate a new source port, there is the issue of which 397 IANA-defined range of port to choose. The ranges are "well-known" 398 from 0 to 1023, "registered" from 1024 to 49151, and "dynamic/ 399 private" from 49152 through 65535. For most protocols, these are 400 destination ports and not source ports, so mapping a source port to a 401 source port that is already registered is unlikely to have any bad 402 effects. Some NATs may choose to use only the ports in the dynamic 403 range; the only down side of this practice is that it limits the 404 number of ports available. Other NAT devices may use everything but 405 the well-known range and may prefer to use the dynamic range first or 406 possibly avoid the actual registered ports in the registered range. 407 Other NATs preserve the port range if it is in the well-known range. 408 [RFC0768] specifies that the source port is set to zero if no reply 409 packet are expected. In this case it does not matter what the NAT 410 maps it to as the source port will not be used. However, many common 411 OS APIs do not allow a user to send from port zero, applications do 412 not use port zero, and the behavior of various existing NATs with 413 regards to a packet with a source of port zero is unknown. This 414 document does not specify any normative behavior for a NAT when 415 handling a packet with a source port of zero which means that 416 applications can not count on any sort of deterministic behavior for 417 these packets. 419 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 420 overloading". 421 a) If the host's source port was in the range 0-1023, it is 422 RECOMMENDED the NAT's source port be in the same range. If the 423 host's source port was in the range 1024-65535, it is 424 RECOMMENDED that the NAT's source port be in that range. 426 Justification: This requirement must be met in order to enable two 427 applications on the internal side of the NAT both to use the same 428 port to try to communicate with the same destination. NATs that 429 implement port preservation have to deal with conflicts on ports, 430 and the multiple code paths this introduces often result in 431 nondeterministic behavior. However, it should be understood that 432 when a port is randomly assigned, it may just randomly happen to 433 be assigned the same port. Applications must therefore be able to 434 deal with both port preservation and no port preservation. 435 a) Certain applications expect the source UDP port to be in the 436 well-known range. See the discussion of Network File System 437 port expectations in [RFC2623] for an example. 439 4.2.2. Port Parity 441 Some NATs preserve the parity of the UDP port, i.e., an even port 442 will be mapped to an even port, and an odd port will be mapped to an 443 odd port. This behavior respects the [RFC3550] rule that RTP use 444 even ports, and RTCP use odd ports. RFC 3550 allows any port numbers 445 to be used for RTP and RTCP if the two numbers are specified 446 separately, for example using [RFC3605]. However, some 447 implementations do not include RFC 3605 and do not recognize when the 448 peer has specified the RTCP port separately using RFC 3605. If such 449 an implementation receives an odd RTP port number from the peer 450 (perhaps after having been translated by a NAT), and then follows the 451 RFC 3550 rule to change the RTP port to the next lower even number, 452 this would obviously result in the loss of RTP. NAT-friendly 453 application aspects are outside the scope of this document. It is 454 expected that this issue will fade away with time, as implementations 455 improve. Preserving the port parity allows for supporting 456 communication with peers that do not support explicit specification 457 of both RTP and RTCP port numbers. 459 REQ-4: It is RECOMMENDED that a NAT have a "Port parity 460 preservation" behavior of "Yes". 462 Justification: This is to avoid breaking peer-to-peer applications 463 which do not explicitly and separately specify RTP and RTCP port 464 numbers and which follow the RFC 3550 rule to decrement an odd RTP 465 port to make it even. The same considerations as per the IP 466 address pooling requirement apply. 468 4.2.3. Port Contiguity 470 Some NATs attempt to preserve the port contiguity rule of RTCP=RTP+1. 471 These NATs do things like sequential assignment or port reservation. 472 Sequential port assignment assumes that the application will open a 473 mapping for RTP first and then open a mapping for RTCP. It is not 474 practical to enforce this requirement on all applications. 475 Furthermore, there is a problem with glare if many applications (or 476 endpoints) are trying to open mapping simultaneously. Port 477 preservation is also problematic since it is wasteful, especially 478 considering that a NAT cannot reliably distinguish between RTP over 479 UDP and other UDP packets where there is no contiguity rule. For 480 those reasons, it would be too complex to attempt to preserve the 481 contiguity rule by suggesting specific NAT behavior, and it would 482 certainly break the deterministic behavior rule. 484 In order to support both RTP and RTCP, it will therefore be necessary 485 that applications follow rules to negotiate RTP and RTCP separately, 486 and account for the very real possibility that the RTCP=RTP+1 rule 487 will be broken. As this is an application requirement, it is outside 488 of the scope of this document. 490 4.3. Mapping Refresh 492 NAT mapping timeout implementations vary but include the timer's 493 value and the way the mapping timer is refreshed to keep the mapping 494 alive. 496 The mapping timer is defined as the time a mapping will stay active 497 without packets traversing the NAT. There is great variation in the 498 values used by different NATs. 500 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 501 minutes, unless REQ-5a applies. 502 a) For specific destination ports in the well-known port range 503 (ports 0-1023), a NAT MAY have shorter UDP mapping timers that 504 are specific to the IANA-registered application running over 505 that specific destination port. 507 b) The value of the NAT UDP mapping timer MAY be configurable. 508 c) A default value of 5 minutes or more for the NAT UDP mapping 509 timer is RECOMMENDED. 511 Justification: This requirement is to ensure that the timeout is 512 long enough to avoid too frequent timer refresh packets. 513 a) Some UDP protocols using UDP use very short-lived connections. 514 There can be very many such connections; keeping them all in a 515 connections table could cause considerable load on the NAT. 516 Having shorter timers for these specific applications is 517 therefore an optimization technique. It is important that the 518 shorter timers applied to specific protocols be used sparingly, 519 and only for protocols using well-known destination port that 520 are known to have a shorter timer, and that are known not to be 521 used by any applications for other purposes. 522 b) Configuration is desirable for adapting to specific networks 523 and troubleshooting. 524 c) This default is to avoid too frequent timer refresh packets. 526 Some NATs keep the mapping active (i.e., refresh the timer value) 527 when a packet goes from the internal side of the NAT to the external 528 side of the NAT. This is referred to as having a NAT Outbound 529 refresh behavior of "True". 531 Some NATs keep the mapping active when a packet goes from the 532 external side of the NAT to the internal side of the NAT. This is 533 referred to as having a NAT Inbound Refresh Behavior of "True". 535 Some NATs keep the mapping active on both, in which case both 536 properties are "True". 538 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 539 refresh behavior" of "True". 540 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 541 refresh behavior" of "True". 543 Justification: Outbound refresh is necessary for allowing the client 544 to keep the mapping alive. 545 a) Inbound refresh may be useful for applications with no outgoing 546 UDP traffic. However, allowing inbound refresh may allow an 547 external attacker or misbehaving application to keep a mapping 548 alive indefinitely. This may be a security risk. Also, if the 549 process is repeated with different ports, over time it could 550 use up all the ports on the NAT. 552 4.4. Conflicting Internal and External IP Address Spaces 554 Many NATs, particularly consumer-level devices designed to be 555 deployed by nontechnical users, routinely obtain their external IP 556 address, default router, and other IP configuration information for 557 their external interface dynamically from an external network such as 558 an upstream ISP. The NAT in turn automatically sets up its own 559 internal subnet in one of the private IP address spaces assigned to 560 this purpose in [RFC1918], typically providing dynamic IP 561 configuration services for hosts on this internal network. 563 Auto-configuration of NATs and private networks can be problematic, 564 however, if the NAT's external network is also in RFC 1918 private 565 address space. In a common scenario, an ISP places its customers 566 behind a NAT and hands out private RFC 1918 addresses to them. Some 567 of these customers in turn deploy consumer-level NATs, which in 568 effect act as "second-level" NATs, multiplexing their own private RFC 569 1918 IP subnets onto the single RFC 1918 IP address provided by the 570 ISP. There is no inherent guarantee in this case that the ISP's 571 "intermediate" privately-addressed network and the customer's 572 internal privately-addressed network will not use numerically 573 identical or overlapping RFC 1918 IP subnets. Customers of consumer- 574 level NATs further cannot be expected to have the technical knowledge 575 to prevent this scenario from occurring by manually configuring their 576 internal network with non-conflicting RFC 1918 subnets. 578 NAT vendors need to design their NATs to ensure that they function 579 correctly and robustly even in such problematic scenarios. One 580 possible solution is for the NAT to ensure that whenever its external 581 link is configured with an RFC 1918 private IP address, the NAT 582 automatically selects a different, non-conflicting RFC 1918 IP subnet 583 for its internal network. A disadvantage of this solution is that if 584 the NAT's external interface is dynamically configured or re- 585 configured after its internal network is already in use, then the NAT 586 may have to renumber its entire internal network dynamically if it 587 detects a conflict. 589 An alternative solution is for the NAT to be designed so that it can 590 translate and forward traffic correctly even when its external and 591 internal interfaces are configured with numerically overlapping IP 592 subnets. In this scenario, for example, if the NAT's external 593 interface has been assigned an IP address P in RFC 1918 space, then 594 there might also be an internal node I having the same RFC 1918 595 private IP address P. An IP packet with destination address P on the 596 external network is directed at the NAT, whereas an IP packet with 597 the same destination address P on the internal network is directed at 598 node I. The NAT therefore needs to maintain a clear operational 599 distinction between "external IP addresses" and "internal IP 600 addresses" to avoid confusing internal node I with its own external 601 interface. In general, the NAT needs to allow all internal nodes 602 (including I) to communicate with all external nodes having public 603 (non-RFC 1918) IP addresses or having private IP addresses that do 604 not conflict with the addresses used by its internal network. 606 REQ-7: A NAT device whose external IP interface can be configured 607 dynamically MUST either (1) automatically ensure that its internal 608 network uses IP addresses that do not conflict with its external 609 network, or (2) be able to translate and forward traffic between 610 all internal nodes and all external nodes whose IP addresses 611 numerically conflicts with the internal network. 613 Justification: If a NAT's external and internal interfaces are 614 configured with overlapping IP subnets, then there is of course no 615 way for an internal host with RFC 1918 IP address Q to initiate a 616 direct communication session to an external node having the same 617 RFC 1918 address Q, or to other external nodes with IP addresses 618 that numerically conflict with the internal subnet. Such nodes 619 can still open communication sessions indirectly via NAT traversal 620 techniques, however, with the help of a third-party server such as 621 a STUN server having a public, non-RFC 1918 IP address. In this 622 case, nodes with conflicting private RFC 1918 addresses on 623 opposite sides of the second-level NAT can communicate with each 624 other via their respective temporary public endpoints on the main 625 Internet, as long as their common first-level NAT (e.g., the 626 upstream ISP's NAT) supports hairpinning behavior as described in 627 Section 6. 629 5. Filtering Behavior 631 This section describes various filtering behaviors observed in NATs. 633 When an internal endpoint opens an outgoing session through a NAT, 634 the NAT assigns a filtering rule for the mapping between an internal 635 IP:port (X:x) and external IP:port (Y:y) tuple. 637 The key behavior to describe is what criteria are used by the NAT to 638 filter packets originating from specific external endpoints. 640 Endpoint Independent Filtering: 641 The NAT filters out only packets not destined to the internal 642 address and port X:x, regardless of the external IP address and 643 port source (Z:z). The NAT forwards any packets destined to 644 X:x. In other words, sending packets from the internal side of 645 the NAT to any external IP address is sufficient to allow any 646 packets back to the internal endpoint. 648 Address Dependent Filtering: 649 The NAT filters out packets not destined to the internal 650 address X:x. Additionally, the NAT will filter out packets 651 from Y:y destined for the internal endpoint X:x if X:x has not 652 sent packets to Y:any previously (independently of the port 653 used by Y). In other words, for receiving packets from a 654 specific external endpoint, it is necessary for the internal 655 endpoint to send packets first to that specific external 656 endpoint's IP address. 658 Address and Port Dependent Filtering: 659 This is similar to the previous behavior, except that the 660 external port is also relevant. The NAT filters out packets 661 not destined for the internal address X:x. Additionally, the 662 NAT will filter out packets from Y:y destined for the internal 663 endpoint X:x if X:x has not sent packets to Y:y previously. In 664 other words, for receiving packets from a specific external 665 endpoint, it is necessary for the internal endpoint to send 666 packets first to that external endpoint's IP address and port. 668 REQ-8: If application transparency is most important, it is 669 RECOMMENDED that a NAT have an "Endpoint independent filtering" 670 behavior. If a more stringent filtering behavior is most 671 important, it is RECOMMENDED that a NAT have an "Address dependent 672 filtering" behavior. 673 a) The filtering behavior MAY be an option configurable by the 674 administrator of the NAT. 676 Justification: The recommendation to use Endpoint Independent 677 Filtering is aimed at maximizing application transparency, in 678 particular for applications that receive media simultaneously from 679 multiple locations (e.g., gaming), or applications that use 680 rendezvous techniques. However, it is also possible that in some 681 circumstances, it may be preferable to have a more stringent 682 filtering behavior. Filtering independently of the external 683 endpoint is not as secure: an unauthorized packet could get 684 through a specific port while the port was kept open if it was 685 lucky enough to find the port open. In theory, filtering based on 686 both IP address and port is more secure than filtering based only 687 on the IP address (because the external endpoint could in reality 688 be two endpoints behind another NAT, where one of the two 689 endpoints is an attacker): however, such a policy could interfere 690 with applications that expect to receive UDP packets on more than 691 one UDP port. Using Endpoint Independent Filtering or Address 692 Dependent Filtering instead of Address and Port Dependent 693 Filtering on a NAT (say NAT-A) also has benefits when the other 694 endpoint is behind a non-BEHAVE compliant NAT (say NAT-B) that 695 does not support REQ-1. When the endpoints use ICE, if NAT-A uses 696 Address and Port Dependent Filtering, connectivity will require a 697 UDP relay. However, if NAT-A uses Endpoint Independent Filtering 698 or Address Dependent Filtering, ICE will ultimately find 699 connectivity without requiring a UDP relay. Having the filtering 700 behavior being an option configurable by the administrator of the 701 NAT ensures that a NAT can be used in the widest variety of 702 deployment scenarios. 704 6. Hairpinning Behavior 706 If two hosts (called X1 and X2) are behind the same NAT and 707 exchanging traffic, the NAT may allocate an address on the outside of 708 the NAT for X2, called X2':x2'. If X1 sends traffic to X2':x2', it 709 goes to the NAT, which must relay the traffic from X1 to X2. This is 710 referred to as hairpinning and is illustrated below. 712 NAT 713 +----+ from X1:x1 to X2':x2' +-----+ X1':x1' 714 | X1 |>>>>>>>>>>>>>>>>>>>>>>>>>>>>>--+--- 715 +----+ | v | 716 | v | 717 | v | 718 | v | 719 +----+ from X1':x1' to X2:x2 | v | X2':x2' 720 | X2 |<<<<<<<<<<<<<<<<<<<<<<<<<<<<<--+--- 721 +----+ +-----+ 723 Hairpinning Behavior 725 Hairpinning allows two endpoints on the internal side of the NAT to 726 communicate even if they only use each other's external IP addresses 727 and ports. 729 More formally, a NAT that supports hairpinning forwards packets 730 originating from an internal address, X1:x1, destined for an external 731 address X2':x2' that has an active mapping to an internal address 732 X2:x2, back to that internal address X2:x2. Note that typically X1' 733 is the same as X2'. 735 Furthermore, the NAT may present the hairpinned packet with either an 736 internal (X1:x1) or an external (X1':x1') source IP address and port. 737 The hairpinning NAT behavior can therefore be either "External source 738 IP address and port" or "Internal source IP address and port". 739 "Internal source IP address and port" may cause problems by confusing 740 implementations that expect an external IP address and port. 742 REQ-9: A NAT MUST support "Hairpinning". 743 a) A NAT Hairpinning behavior MUST be "External source IP address 744 and port". 746 Justification: This requirement is to allow communications between 747 two endpoints behind the same NAT when they are trying each 748 other's external IP addresses. 749 a) Using the external source IP address is necessary for 750 applications with a restrictive policy of not accepting packets 751 from IP addresses that differ from what is expected. 753 7. Application Level Gateways 755 Certain NATs have implemented Application Level Gateways (ALGs) for 756 various protocols, including protocols for negotiating peer-to-peer 757 sessions such as SIP. 759 Certain NATs have these ALGs turned on permanently, others have them 760 turned on by default but let them be be turned off, and others have 761 them turned off by default but let them be turned on. 763 NAT ALGs may interfere with UNSAF methods or protocols that try to be 764 NAT-aware and must therefore be used with extreme caution. 766 REQ-10: To eliminate interference with UNSAF NAT traversal 767 mechanisms and allow integrity protection of UDP communications, 768 NAT ALGs for UDP-based protocols SHOULD be turned off. Future 769 standards track specifications that define an ALG can update this 770 to recommend that the ALGs they define default on. 771 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow 772 the NAT administrator to enable or disable each ALG separately. 774 Justification: NAT ALGs may interfere with UNSAF methods. 775 a) This requirement allows the user to enable those ALGs that are 776 necessary to aid in the operation of some applications without 777 enabling ALGs which interfere with the operation of other 778 applications. 780 8. Deterministic Properties 782 The classification of NATs is further complicated by the fact that 783 under some conditions the same NAT will exhibit different behaviors. 784 This has been seen on NATs that preserve ports or have specific 785 algorithms for selecting a port other than a free one. If the 786 external port that the NAT wishes to use is already in use by another 787 session, the NAT must select a different port. This results in 788 different code paths for this conflict case, which results in 789 different behavior. 791 For example, if three hosts X1, X2, and X3 all send from the same 792 port x, through a port preserving NAT with only one external IP 793 address, called X1', the first one to send (i.e., X1) will get an 794 external port of x but the next two will get x2' and x3' (where these 795 are not equal to x). There are NATs where the External NAT mapping 796 characteristics and the External Filter characteristics change 797 between the X1:x and the X2:x mapping. To make matters worse, there 798 are NATs where the behavior may be the same on the X1:x and X2:x 799 mappings but different on the third X3:x mapping. 801 Another example is that some NATs have an "Endpoint Independent 802 Mapping" combined with "Port Overloading" as long as two endpoints 803 are not establishing sessions to the same external direction, but 804 then switch their behavior to "Address and Port Dependent Mapping" 805 without "Port Preservation" upon detection of these conflicting 806 sessions establishments. 808 Any NAT that changes the NAT Mapping or the Filtering behavior 809 without configuration changes, at any point in time under any 810 particular conditions is referred to as a "non-deterministic" NAT. 811 NATs that don't are called "deterministic". 813 Non-deterministic NATs generally change behavior when a conflict of 814 some sort happens, i.e. when the port that would normally be used is 815 already in use by another mapping. The NAT mapping and External 816 Filtering in the absence of conflict is referred to as the Primary 817 behavior. The behavior after the first conflict is referred to as 818 Secondary and after the second conflict is referred to as Tertiary. 819 No NATs have been observed that change on further conflicts but it is 820 certainly possible that they exist. 822 REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT 823 change the NAT translation (Section 4) or the Filtering 824 (Section 5) Behavior at any point in time or under any particular 825 conditions. 827 Justification: Non-deterministic NATs are very difficult to 828 troubleshoot because they require more intensive testing. This 829 non-deterministic behavior is the root cause of much of the 830 uncertainty that NATs introduce about whether or not applications 831 will work. 833 9. ICMP Destination Unreachable Behavior 835 When a NAT sends a packet towards a host on the other side of the 836 NAT, an ICMP message may be sent in response to that packet. That 837 ICMP message may be sent by the destination host or by any router 838 along the network path. The NAT's default configuration SHOULD NOT 839 filter ICMP messages based on their source IP address. Such ICMP 840 messages SHOULD be rewritten by the NAT (specifically the IP headers 841 and the ICMP payload) and forwarded to the appropriate internal or 842 external host. The NAT needs to perform this function for as long as 843 the UDP mapping is active. Receipt of any sort of ICMP message MUST 844 NOT destroy the NAT mapping. A NAT which performs the functions 845 described in the paragraph above is referred to as "support ICMP 846 Processing". 848 There is no significant security advantage to blocking ICMP 849 Destination Unreachable packets. Additionally, blocking ICMP 850 Destination Unreachable packets can interfere with application 851 failover, UDP Path MTU Discovery (see [RFC1191] and [RFC1435]), and 852 traceroute. Blocking any ICMP message is discouraged, and blocking 853 ICMP Destination Unreachable is strongly discouraged. 855 REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the 856 NAT mapping. 857 a) The NAT's default configuration SHOULD NOT filter ICMP messages 858 based on their source IP address. 859 b) It is RECOMMENDED that a NAT support ICMP Destination 860 Unreachable messages. 862 Justification: This is easy to do, is used for many things including 863 MTU discovery and rapid detection of error conditions, and has no 864 negative consequences. 866 10. Fragmentation of Outgoing Packets 868 When the MTU of the adjacent link is too small, fragmentation of 869 packets going from the internal side to the external side of the NAT 870 may occur. This can occur if the NAT is doing PPPoE, or if the NAT 871 has been configured with a small MTU to reduce serialization delay 872 when sending large packets and small higher-priority packets, or for 873 other reasons. 875 It is worth noting that many IP stacks do not use Path MTU Discovery 876 with UDP packets. 878 The packet could have its Don't Fragment bit set to 1 (DF=1) or 0 879 (DF=0). 881 REQ-13: If the packet received on an internal IP address has DF=1, 882 the NAT MUST send back an ICMP message "fragmentation needed and 883 DF set" message to the host as described in [RFC0792]. 884 a) If the packet has DF=0, the NAT MUST fragment the packet and 885 SHOULD send the fragments in order. 887 Justification: This is as per RFC 792. 888 a) This is the same function a router performs in a similar 889 situation [RFC1812]. 891 11. Receiving Fragmented Packets 893 For a variety of reasons, a NAT may receive a fragmented packet. The 894 IP packet containing the header could arrive in any fragment 895 depending on network conditions, packet ordering, and the 896 implementation of the IP stack that generated the fragments. 898 A NAT that is capable only of receiving fragments in order (that is, 899 with the header in the first packet) and forwarding each of the 900 fragments to the internal host is described as "Received Fragments 901 Ordered". 903 A NAT that is capable of receiving fragments in or out of order and 904 forwarding the individual fragments (or a reassembled packet) to the 905 internal host is referred to as "Receive Fragments Out of Order". 906 See the Security Considerations section of this document for a 907 discussion of this behavior. 909 A NAT that is neither of these is referred to as "Receive Fragments 910 None". 912 REQ-14: A NAT MUST support receiving in order and out of order 913 fragments, so it MUST have "Received Fragment Out of Order" 914 behavior. 915 a) A NAT's out of order fragment processing mechanism MUST be 916 designed so that fragmentation-based DoS attacks do not 917 compromise the NAT's ability to process in-order and 918 unfragmented IP packets. 920 Justification: See Security Considerations. 922 12. Requirements 924 The requirements in this section are aimed at minimizing the 925 complications caused by NATs to applications such as realtime 926 communications and online gaming. The requirements listed earlier in 927 the document are consolidated here into a single section. 929 It should be understood, however, that applications normally do not 930 know in advance if the NAT conforms to the recommendations defined in 931 this section. Peer-to-peer media applications still need to use 932 normal procedures such as ICE [I-D.ietf-mmusic-ice]. 934 A NAT that supports all of the mandatory requirements of this 935 specification (i.e., the "MUST"), is "compliant with this 936 specification." A NAT that supports all of the requirements of this 937 specification (i.e., including the "RECOMMENDED") is "fully compliant 938 with all the mandatory and recommended requirements of this 939 specification." 941 REQ-1: A NAT MUST have an "Endpoint Independent Mapping" behavior. 942 REQ-2: It is RECOMMENDED that a NAT have an "IP address pooling" 943 behavior of "Paired". Note that this requirement is not 944 applicable to NATs that do not support IP address pooling. 945 REQ-3: A NAT MUST NOT have a "Port assignment" behavior of "Port 946 overloading". 947 a) If the host's source port was in the range 0-1023, it is 948 RECOMMENDED the NAT's source port be in the same range. If the 949 host's source port was in the range 1024-65535, it is 950 RECOMMENDED that the NAT's source port be in that range. 951 REQ-4: It is RECOMMENDED that a NAT have a "Port parity 952 preservation" behavior of "Yes". 953 REQ-5: A NAT UDP mapping timer MUST NOT expire in less than 2 954 minutes, unless REQ-5a applies. 955 a) For specific destination ports in the well-known port range 956 (ports 0-1023), a NAT MAY have shorter UDP mapping timers that 957 are specific to the IANA-registered application running over 958 that specific destination port. 959 b) The value of the NAT UDP mapping timer MAY be configurable. 960 c) A default value of 5 minutes or more for the NAT UDP mapping 961 timer is RECOMMENDED. 962 REQ-6: The NAT mapping Refresh Direction MUST have a "NAT Outbound 963 refresh behavior" of "True". 964 a) The NAT mapping Refresh Direction MAY have a "NAT Inbound 965 refresh behavior" of "True". 966 REQ-7 A NAT device whose external IP interface can be configured 967 dynamically MUST either (1) Automatically ensure that its internal 968 network uses IP addresses that do not conflict with its external 969 network, or (2) Be able to translate and forward traffic between 970 all internal nodes and all external nodes whose IP addresses 971 numerically conflicts with the internal network. 973 REQ-8: If application transparency is most important, it is 974 RECOMMENDED that a NAT have "Endpoint independent filtering" 975 behavior. If a more stringent filtering behavior is most 976 important, it is RECOMMENDED that a NAT have "Address dependent 977 filtering" behavior. 978 a) The filtering behavior MAY be an option configurable by the 979 administrator of the NAT. 980 REQ-9: A NAT MUST support "Hairpinning". 981 a) A NAT Hairpinning behavior MUST be "External source IP address 982 and port". 983 REQ-10: To eliminate interference with UNSAF NAT traversal 984 mechanisms and allow integrity protection of UDP communications, 985 NAT ALGs for UDP-based protocols SHOULD be turned off. Future 986 standards track specifications that define an ALG can update this 987 to recommend that the ALGs they define default on. 988 a) If a NAT includes ALGs, it is RECOMMENDED that the NAT allow 989 the NAT administrator to enable or disable each ALG separately. 990 REQ-11: A NAT MUST have deterministic behavior, i.e., it MUST NOT 991 change the NAT translation (Section 4) or the Filtering 992 (Section 5) Behavior at any point in time or under any particular 993 conditions. 994 REQ-12: Receipt of any sort of ICMP message MUST NOT terminate the 995 NAT mapping. 996 a) The NAT's default configuration SHOULD NOT filter ICMP messages 997 based on their source IP address. 998 b) It is RECOMMENDED that a NAT support ICMP Destination 999 Unreachable messages. 1000 REQ-13 If the packet received on an internal IP address has DF=1, 1001 the NAT MUST send back an ICMP message "fragmentation needed and 1002 DF set" message to the host as described in [RFC0792]. 1003 a) If the packet has DF=0, the NAT MUST fragment the packet and 1004 SHOULD send the fragments in order. 1005 REQ-14: A NAT MUST support receiving in order and out of order 1006 fragments, so it MUST have "Received Fragment Out of Order" 1007 behavior. 1008 a) A NAT's out of order fragment processing mechanism MUST be 1009 designed so that fragmentation-based DoS attacks do not 1010 compromise the NAT's ability to process in-order and 1011 unfragmented IP packets. 1013 13. Security Considerations 1015 NATs are often deployed to achieve security goals. Most of the 1016 recommendations and requirements in this document do not affect the 1017 security properties of these devices, but a few of them do have 1018 security implications and are discussed in this section. 1020 This document recommends that the timers for mapping be refreshed 1021 only on outgoing packets (see REQ-6) and does not make 1022 recommendations about whether or not inbound packets should update 1023 the timers. If inbound packets update the timers, an external 1024 attacker can keep the mapping alive forever and attack future devices 1025 that may end up with the same internal address. A device that was 1026 also the DHCP server for the private address space could mitigate 1027 this by cleaning any mappings when a DHCP lease expired. For unicast 1028 UDP traffic (the scope of this document), it may not seem relevant to 1029 support inbound timer refresh; however, for multicast UDP, the 1030 question is harder. It is expected that future documents discussing 1031 NAT behavior with multicast traffic will refine the requirements 1032 around handling of the inbound refresh timer. Some devices today do 1033 update the timers on inbound packets. 1035 This document recommends that the NAT filters be specific to the 1036 external IP address only (see REQ-8) and not to the external IP 1037 address and UDP port. It can be argued that this is less secure than 1038 using the IP and port. Devices that wish to filter on IP and port do 1039 still comply with these requirements. 1041 Non-deterministic NATs are risky from a security point of view. They 1042 are very difficult to test because they are, well, non-deterministic. 1043 Testing by a person configuring one may result in the person thinking 1044 it is behaving as desired, yet under different conditions, which an 1045 attacker can create, the NAT may behave differently. These 1046 requirements recommend that devices be deterministic. 1048 This document requires that NATs have an "external NAT mapping is 1049 endpoint independent" behavior. This does not reduce the security of 1050 devices. Which packets are allowed to flow across the device is 1051 determined by the external filtering behavior, which is independent 1052 of the mapping behavior. 1054 When a fragmented packet is received from the external side and the 1055 packets are out of order so that the initial fragment does not arrive 1056 first, many systems simply discard the out of order packets. 1057 Moreover, since some networks deliver small packets ahead of large 1058 ones, there can be many out of order fragments. NATs that are 1059 capable of delivering these out of order packets are possible but 1060 they need to store the out of order fragments, which can open up a 1061 DoS opportunity if done incorrectly. Fragmentation has been a tool 1062 used in many attacks, some involving passing fragmented packets 1063 through NATs and others involving DoS attacks based on the state 1064 needed to reassemble the fragments. NAT implementers should be aware 1065 of [RFC3128] and [RFC1858]. 1067 14. IANA Considerations 1069 There are no IANA considerations. 1071 15. IAB Considerations 1073 The IAB has studied the problem of "Unilateral Self Address Fixing", 1074 which is the general process by which a client attempts to determine 1075 its address in another realm on the other side of a NAT through a 1076 collaborative protocol reflection mechanism [RFC3424]. 1078 This specification does not in itself constitute an UNSAF 1079 application. It consists of a series of requirements for NATs aimed 1080 at minimizing the negative impact that those devices have on peer-to- 1081 peer media applications, especially when those applications are using 1082 UNSAF methods. 1084 Section 3 of UNSAF lists several practical issues with solutions to 1085 NAT problems. This document makes recommendations to reduce the 1086 uncertainty and problems introduced by these practical issues with 1087 NATs. In addition, UNSAF lists five architectural considerations. 1088 Although this is not an UNSAF proposal, it is interesting to consider 1089 the impact of this work on these architectural considerations. 1091 Arch-1: The scope of this is limited to UDP packets in NATs like the 1092 ones widely deployed today. The "fix" helps constrain the 1093 variability of NATs for true UNSAF solutions such as STUN. 1094 Arch-2: This will exit at the same rate that NATs exit. It does not 1095 imply any protocol machinery that would continue to live 1096 after NATs were gone or make it more difficult to remove 1097 them. 1098 Arch-3: This does not reduce the overall brittleness of NATs but 1099 will hopefully reduce some of the more outrageous NAT 1100 behaviors and make it easer to discuss and predict NAT 1101 behavior in given situations. 1102 Arch-4: This work and the results [I-D.jennings-behave-test-results] 1103 of various NATs represent the most comprehensive work at 1104 IETF on what the real issues are with NATs for applications 1105 like VoIP. This work and STUN have pointed out more than 1106 anything else the brittleness NATs introduce and the 1107 difficulty of addressing these issues. 1108 Arch-5: This work and the test results 1109 [I-D.jennings-behave-test-results] provide a reference model 1110 for what any UNSAF proposal might encounter in deployed 1111 NATs. 1113 16. Acknowledgments 1115 The editor would like to acknowledge Bryan Ford, Pyda Srisuresh and 1116 Dan Kegel for the their multiple contributions on peer-to-peer 1117 communications across a NAT. Dan Wing contributed substantial text 1118 on IP fragmentation and ICMP behavior. Thanks to Rohan Mahy, 1119 Jonathan Rosenberg, Mary Barnes, Melinda Shore, Lyndsay Campbell, 1120 Geoff Huston, Jiri Kuthan, Harald Welte, Steve Casner, Robert 1121 Sanders, Spencer Dawkins, Saikat Guha, Christian Huitema, Yutaka 1122 Takeda, Paul Hoffman, Lisa Dusseault, Pekka Savola, Peter Koch and 1123 Jari Arkko for their contributions. 1125 17. References 1127 17.1. Normative References 1129 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 1130 August 1980. 1132 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1133 September 1981. 1135 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1136 Requirement Levels", BCP 14, RFC 2119, March 1997. 1138 17.2. Informational References 1140 [RFC0792] Postel, J., "Internet Control Message Protocol", STD 5, 1141 RFC 792, September 1981. 1143 [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, 1144 November 1990. 1146 [RFC1435] Knowles, S., "IESG Advice from Experience with Path MTU 1147 Discovery", RFC 1435, March 1993. 1149 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1150 RFC 1812, June 1995. 1152 [RFC1858] Ziemba, G., Reed, D., and P. Traina, "Security 1153 Considerations for IP Fragment Filtering", RFC 1858, 1154 October 1995. 1156 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1157 E. Lear, "Address Allocation for Private Internets", 1158 BCP 5, RFC 1918, February 1996. 1160 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 1161 (IPv6) Specification", RFC 2460, December 1998. 1163 [RFC2623] Eisler, M., "NFS Version 2 and Version 3 Security Issues 1164 and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5", 1165 RFC 2623, June 1999. 1167 [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address 1168 Translator (NAT) Terminology and Considerations", 1169 RFC 2663, August 1999. 1171 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1172 Address Translator (Traditional NAT)", RFC 3022, 1173 January 2001. 1175 [RFC3027] Holdrege, M. and P. Srisuresh, "Protocol Complications 1176 with the IP Network Address Translator", RFC 3027, 1177 January 2001. 1179 [RFC3128] Miller, I., "Protection Against a Variant of the Tiny 1180 Fragment Attack (RFC 1858)", RFC 3128, June 2001. 1182 [RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, 1183 A., Peterson, J., Sparks, R., Handley, M., and E. 1184 Schooler, "SIP: Session Initiation Protocol", RFC 3261, 1185 June 2002. 1187 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1188 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1189 Through Network Address Translators (NATs)", RFC 3489, 1190 March 2003. 1192 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1193 Jacobson, "RTP: A Transport Protocol for Real-Time 1194 Applications", STD 64, RFC 3550, July 2003. 1196 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1197 Self-Address Fixing (UNSAF) Across Network Address 1198 Translation", RFC 3424, November 2002. 1200 [RFC3605] Huitema, C., "Real Time Control Protocol (RTCP) attribute 1201 in Session Description Protocol (SDP)", RFC 3605, 1202 October 2003. 1204 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 1205 Network Address Translations (NATs)", RFC 4380, 1206 February 2006. 1208 [I-D.ietf-behave-rfc3489bis] 1209 Rosenberg, J., "Simple Traversal Underneath Network 1210 Address Translators (NAT) (STUN)", 1211 draft-ietf-behave-rfc3489bis-04 (work in progress), 1212 July 2006. 1214 [I-D.ietf-mmusic-ice] 1215 Rosenberg, J., "Interactive Connectivity Establishment 1216 (ICE): A Methodology for Network Address Translator (NAT) 1217 Traversal for Offer/Answer Protocols", 1218 draft-ietf-mmusic-ice-11 (work in progress), October 2006. 1220 [I-D.jennings-behave-test-results] 1221 Jennings, C., "NAT Classification Test Results", 1222 draft-jennings-behave-test-results-02 (work in progress), 1223 June 2006. 1225 [I-D.ietf-behave-turn] 1226 Rosenberg, J., "Obtaining Relay Addresses from Simple 1227 Traversal Underneath NAT (STUN)", 1228 draft-ietf-behave-turn-02 (work in progress), 1229 October 2006. 1231 [ITU.H323] 1232 "Packet-based Multimedia Communications Systems", ITU- 1233 T Recommendation H.323, July 2003. 1235 Authors' Addresses 1237 Francois Audet (editor) 1238 Nortel Networks 1239 4655 Great America Parkway 1240 Santa Clara, CA 95054 1241 US 1243 Phone: +1 408 495 3756 1244 Email: audet@nortel.com 1245 Cullen Jennings 1246 Cisco Systems 1247 170 West Tasman Drive 1248 MS: SJC-21/2 1249 San Jose, CA 95134 1250 US 1252 Phone: +1 408 902 3341 1253 Email: fluffy@cisco.com 1255 Full Copyright Statement 1257 Copyright (C) The Internet Society (2006). 1259 This document is subject to the rights, licenses and restrictions 1260 contained in BCP 78, and except as set forth therein, the authors 1261 retain all their rights. 1263 This document and the information contained herein are provided on an 1264 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1265 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1266 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1267 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1268 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1269 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1271 Intellectual Property 1273 The IETF takes no position regarding the validity or scope of any 1274 Intellectual Property Rights or other rights that might be claimed to 1275 pertain to the implementation or use of the technology described in 1276 this document or the extent to which any license under such rights 1277 might or might not be available; nor does it represent that it has 1278 made any independent effort to identify any such rights. Information 1279 on the procedures with respect to rights in RFC documents can be 1280 found in BCP 78 and BCP 79. 1282 Copies of IPR disclosures made to the IETF Secretariat and any 1283 assurances of licenses to be made available, or the result of an 1284 attempt made to obtain a general license or permission for the use of 1285 such proprietary rights by implementers or users of this 1286 specification can be obtained from the IETF on-line IPR repository at 1287 http://www.ietf.org/ipr. 1289 The IETF invites any interested party to bring to its attention any 1290 copyrights, patents or patent applications, or other proprietary 1291 rights that may cover technology that may be required to implement 1292 this standard. Please address the information to the IETF at 1293 ietf-ipr@ietf.org. 1295 Acknowledgment 1297 Funding for the RFC Editor function is provided by the IETF 1298 Administrative Support Activity (IASA).