idnits 2.17.1 draft-iab-nat-traversal-considerations-00.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 937. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 943. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 (February 13, 2005) is 7005 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 2326 (ref. '3') (Obsoleted by RFC 7826) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. '5') (Obsoleted by RFC 5389) == Outdated reference: A later version (-08) exists of draft-rosenberg-midcom-turn-06 == Outdated reference: A later version (-05) exists of draft-huitema-v6ops-teredo-04 == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-03 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-04 == Outdated reference: A later version (-11) exists of draft-ietf-midcom-mib-04 -- Obsolete informational reference (is this intentional?): RFC 2327 (ref. '14') (Obsoleted by RFC 4566) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-00 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J. Rosenberg 2 Internet-Draft IAB 3 Expires: August 14, 2005 February 13, 2005 5 Considerations for Selection of Techniques for NAT Traversal 6 draft-iab-nat-traversal-considerations-00 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 14, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 There are many protocols designed and deployed on the Internet today 42 which do not naturally traverse Network Address Translators (NAT). 43 In order to allow these protocols to work in the presence of NAT, 44 additional logic needs to be added to the network. This logic 45 modifies the behavior of the protocol in some way. There are choices 46 where this logic can be placed in the network. It can reside in the 47 NATs themselves, transparently altering the protocol; when this 48 occurs, it is called an Application Layer Gateway (ALG). It can 49 reside in server components, hiding the changes from NATs and clients 50 alike, it can reside in the clients, or it can reside in a 51 combination thereof. The choice of the placement of this logic 52 typically has implications on many aspects of the protocol, including 53 security, deployability, manageability and availability. This 54 document provides a set of considerations that should be taken into 55 account by protocol and network designers when making this choice. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Network Model . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Techniques for Traversal . . . . . . . . . . . . . . . . . . . 5 62 3.1 Modify the NAT: Application Layer Gateways (ALG) . . . . . 5 63 3.2 Modify the Clients: Unilaternal Self-Address Fixing 64 (UNSAF) . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3.3 Modify the Servers: Server Involvement in NAT 66 Navigation (SINN) . . . . . . . . . . . . . . . . . . . . 6 67 3.4 Modify the NAT and the Client: RSIP, NSIS . . . . . . . . 7 68 3.5 Modify the NAT and the Server: MIDCOM . . . . . . . . . . 7 69 3.6 Modify the Clients and Servers: Protocol Update . . . . . 7 70 3.7 Modify Everything: IPv6 . . . . . . . . . . . . . . . . . 7 71 4. Considerations for Selection . . . . . . . . . . . . . . . . . 8 72 4.1 Security . . . . . . . . . . . . . . . . . . . . . . . . . 8 73 4.1.1 Undermining Application Security Measures . . . . . . 8 74 4.1.2 Vulnerabilities Inherent in Traversal Technique . . . 11 75 4.2 Deployability Considerations . . . . . . . . . . . . . . . 12 76 4.3 Manageability . . . . . . . . . . . . . . . . . . . . . . 13 77 4.4 Avaiability . . . . . . . . . . . . . . . . . . . . . . . 16 78 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 6. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 81 8. IAB Members . . . . . . . . . . . . . . . . . . . . . . . . . 18 82 9. Informative References . . . . . . . . . . . . . . . . . . . . 19 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 84 Intellectual Property and Copyright Statements . . . . . . . . 21 86 1. Introduction 88 A Network Address Translator (NAT) is defined in RFC 2663 [1] as "a 89 method by which IP addresses are mapped from one address realm to 90 another, providing transparent routing to end hosts." NAT and its 91 many variations have seen widespread deployment over the past few 92 years. However, many protocols were designed and deployed before the 93 widespread deployment of NAT. Some of these protocols cease to work 94 correctly in the presence of NAT. These include the File Transfer 95 Protocol (FTP), the Domain Name System (DNS), the Session Initiation 96 Protocol (SIP) [2], and the Real Time Streaming Protocol (RTSP) [3] 97 amongst others. 99 In order for these protocols to operate on the network in the face of 100 NAT, numerous techniques have been developed, many of which are 101 protocol specific. These include deploying Application Layer 102 Gateways (ALGs), upgraded clients or servers, or one of the many 103 Unilateral Self Address Fixing (UNSAF) techniques [4], such as the 104 Simple Traversal of UDP through NAT (STUN) [5], Traversal Using Relay 105 NAT (TURN) [6], Teredo [7] and Interactive Connectivity Establishment 106 (ICE) [8]. As such, network designers and operators are faced with a 107 choice of techniques. 109 The right choice of technique depends on a number of architectural 110 considerations. The purpose of this specification is to provide 111 guidance to network designers, planners and operators on the 112 selection of general technique for NAT traversal. It is not a 113 detailed comparison of STUN, TURN, Teredo, and ICE, but focuses on 114 the architectural issues around the choice between modified 115 application components, ALGs, and UNSAF techniques. Many of the 116 considerations here also apply to the design of traversal techniques 117 for new protocols. However, that is not the focus of this document. 119 Firewalls play a related role to NAT. A NAT itself provides a form 120 of firewall - it prevents inbound communications unless there was a 121 matching outbound communications first. However, firewalls allow a 122 nearly infinite set of policies about whether a packet will traverse 123 or not. This means that a so-called firewall traversal technique may 124 or may not work depending on the firewall policies. Because of this, 125 the considerations described here are applicable to firewall 126 traversal techniques to the degree that the firewall policy would 127 permit the technique to work. That said, the focus of the document 128 is on NAT, not firewall. 130 Section 2 provides a simplified view of the network under 131 consideration, sufficient for the purposes of demonstrating the role 132 of each technique. Section 3 is a more detailed description of the 133 various techniques. Section 4 discusses the key architectural 134 considerations when making the choice. These include security 135 (Section 4.1), deployability (Section 4.2), manageability (Section 136 4.3) and availability (Section 4.4). 138 2. Network Model 140 This section provides a basic model of the network deployments under 141 consideration. It serves several purposes in this specification: 143 o It serves to delineate the scope of the networks and application 144 protocols under consideration. If an application protocol cannot 145 be mapped into this model, or if a network deployment looks 146 different than this model, the considerations documented here may 147 not apply. 149 o It serves as a way to help classify the various traversal 150 techniques in terms of their impact on components in the network. 152 +---------+ +---------+ 153 | | | | 154 | Server |<------------------->| Server | 155 | |<--\ >| | 156 +---------+ \ / +---------+ 157 ^ \ / ^ 158 | \ / | 159 | \ / | 160 | \ / | 161 | \ / | 162 | \ / | 163 +-----------+ \/ +-----------+ 164 | NAT | /\ | NAT | 165 +-----------+ / \ +-----------+ 166 | / \ | 167 | / \ | 168 | / \ | 169 | / \ | 170 V / \ V 171 +---------+ / \ +---------+ 172 | |<--/ >| | 173 | Client |<------------------->| Client | 174 | | | | 175 +---------+ +---------+ 177 Figure 1 179 The model under consideration is shown in Figure 1 In this model, the 180 application protocol consists of two classes of entities - clients 181 and servers. Clients refer here to the set of protocol functions 182 that typically reside on end user hosts. In the problem under 183 consideration here, these clients reside behind a NAT or NAT variant, 184 such as Network Address Port Translation (NAPT) (from this point 185 forward, we use the term NAT to include basic NAT and all of its 186 variations). Servers refer here to the set of protocol functions 187 that typically reside in the network. In the problem under 188 consideration here, the servers reside on the public side of the NAT. 189 They are deployed and operated by the service provider. The NAT sits 190 between the clients and servers. It may be owned and deployed by the 191 end user, by the service provider, or by a third entity (typically, 192 the owner of the access network used by the users). 194 Depending on the application protocol, clients may communicate with 195 each other directly or through servers. Servers may talk with each 196 other or just with clients, also depending on the application 197 protocol. 199 This model covers application protocols such as FTP, DNS, SIP, RTSP, 200 ITU H.323 and others. 202 3. Techniques for Traversal 204 There are many techniques that have been developed to facilitate the 205 traversal of NAT. These techniques can be classified based on the 206 way in which they affect the network in Figure 1. The various 207 techniques ultimately modify the behavior of one or more of the 208 components in the network, and possibly add additional components. 209 With three separate logical components (clients, servers and NAT), 210 there are 7 combinations of modifications that can be made. All 211 seven are actually possible and have been used in actual deployments. 213 3.1 Modify the NAT: Application Layer Gateways (ALG) 215 RFC 2663 [1] defines an Application Layer Gateway (ALG) as 216 "application specific translation agents that allow an application on 217 a host in one address realm to connect to its counterpart running on 218 a host in different realm transparently". ALGs are also used to 219 refer to application specific agents in firewalls that allow an 220 application on a host in one network to talk to its counterpart 221 running on a host in another network. One of the key characteristics 222 of the ALG is that it is transparent. It operates without explicit 223 awareness from, or consent by, other entities involved in the 224 application layer protocol. 226 ALGs appear to have many benefits. By placing them in a small number 227 of locations in a network, they allow a large number of hosts to use 228 an application which, before deployment of the ALG, did not function. 229 No change is required in the protocols used by those applications. 230 No changes are needed in the clients, and no changes are needed in 231 the servers. The only element that is modified is the element that 232 introduced the problem in the first place - the NAT. 234 ALGs have seen substantial deployment by enterprises and network 235 operators, particularly for a small number of protocols that were 236 already defined at the time that NAT and firewall usage became 237 commonplace, most notably FTP and DNS. 239 3.2 Modify the Clients: Unilaternal Self-Address Fixing (UNSAF) 241 RFC 3424 defines UNSAF as a technique by which a client behind a NAT 242 attempts to discover its address as would be seen in the address 243 realm on the public side of the NAT, and then use that address within 244 application layer protocols instead of its actual IP address. This 245 is done by adding a new element, an "UNSAF server", on the public 246 side of the NAT, and then modifying the client so that it knows how 247 to use the UNSAF server. The actual application protocol server 248 remains unchanged, as does the NAT. 250 The Simple Traversal of UDP Through NAT [5] is one example of an 251 UNSAF protocol. Teredo [7] is similar to STUN, but focuses on v6 252 hosts behind a v4 network with NAT that wish to obtain v6 253 connectivity. Traversal Using Relay NAT (TURN) [6] is a cousin of 254 STUN. However, packets sent to the address provided by the TURN 255 server are actually relayed through the TURN server. TURN is a close 256 cousin of Virtual Private Networks (VPN), of which there are many 257 varieties. TURN differs from VPN in that it operates at a higher 258 layer in the protocol stack, but is similar in that it provides the 259 client with an address and port that route to a server which forwards 260 the packet to the client. 262 All of the techniques in this section share the property that they 263 require the client software to be modified so that it becomes UNSAF 264 aware. However, this modification tends to be isolated from the 265 application protocol processing itself, with few touch points. 266 Indeed, VPN solutions require no change in the application software 267 itself. 269 3.3 Modify the Servers: Server Involvement in NAT Navigation (SINN) 271 The SINN technique involves modifying the servers so that their 272 actual application processing changes, possibly in violation of the 273 specifications they are implementing. However, for some application 274 protocols, the SINN technique allows for NAT traversal without 275 modifying the clients or the NATs - only the servers. Whether this 276 technique is possible or not depends entirely on the application 277 layer protocol, and usually involves assumptions on client behavior. 279 One example of the SINN technique are the so-called Session Border 280 Controllers (SBC) in SIP. An SBC operates by ignoring IP addresses 281 and ports provided by the client in its SIP messages, and modifying 282 the IP addresses and ports in SIP messages sent to the clients. 283 These modifications force the media traffic for the session through 284 the SBC, making the SIP network look more like a pure client/server 285 network. SBCs operate only when certain assumptions about client 286 behavior are met - that the client sends and receives its media 287 traffic from the same IP address and port, and that it sends and 288 receives its SIP signaling traffic from the same IP address and port 289 (SIP does not require send and receive address/ports to be the same, 290 though this is common practice). 292 3.4 Modify the NAT and the Client: RSIP, NSIS 294 Realm Specific IP (RSIP) [9] can be considered a variant on the UNSAF 295 technique. However, instead of the UNSAF server being outside of the 296 NAT, it is part of the NAT. It is also like VPN in that the client 297 modifications reside below the application processing layer. 299 Next Steps in Signaling (NSIS) allows clients to directly signal with 300 their NAT to obtain bindings for use in application protocols [10]. 302 3.5 Modify the NAT and the Server: MIDCOM 304 Middlebox Communications (MIDCOM) [11] allows servers to communicate 305 with the NAT using an application-independent protocol (the MIDCOM 306 protocol [12]) to create and remove NAT bindings. The server can 307 then use the bindings it learned from the NAT to modify the 308 application packets in much the same way an ALG would. In fact, 309 MIDCOM represents a way to build a distributed ALG, by placing the 310 ALG functionality in a protocol server, separate from the NAT itself. 311 In that regards, MIDCOM is a mix between an ALG solution and a SINN 312 solution. 314 3.6 Modify the Clients and Servers: Protocol Update 316 In this technique, the protocol gets re-engineered so that it 317 traverses NAT without modification to the NAT itself. This has in 318 fact occurred for several protocols. 320 3.7 Modify Everything: IPv6 322 Finally, one can elect to modify the clients and servers, adding 323 IPv6, and modify the NAT itself by literally removing it from the 324 network based on the presumption that it is no longer needed in IPv6. 326 4. Considerations for Selection 328 There are many considerations that must take into account when making 329 a choice. Many of these considerations are not architectural in 330 nature - cost, for example, is a major consideration, but not an 331 architectural one. There are many considerations around selection of 332 a technique within a specific class (i.e., choosing one UNSAF 333 technique over another). These kinds of considerations are important 334 but are difficult to discuss in general, and out of scope for this 335 document. Rather, this section discusses the general architectural 336 considerations around the selection of one of the classes of 337 techniques - ALG, UNSAF, RSIP, NSIS, SINN, MIDCOM, protocol updates 338 and IPv6. 340 4.1 Security 342 Security is one of the most important considerations when selecting a 343 technique, and it is one of the biggest differences amongst the 344 techniques. Security issues can be broken broadly into impacts that 345 the technique has on application security, and security concerns from 346 the technique itself. 348 4.1.1 Undermining Application Security Measures 350 The reason that the application doesn't work through the NAT is that 351 the application assumes uniquess and reachability properties for its 352 IP addresses. However, the intermediary has broken those properties. 353 Furthermore, reachability through the intermediary requires creation 354 of a translation or binding in that intermediary, which doesn't 355 normally exist based on the application-unaware processing logic in 356 the intermediary. This condition arises when an application protocol 357 includes IP addresses or hostnames within its payloads, and those 358 addresses or hostnames are used by the application protocol as a 359 destination for messages. For such messages to flow, appropriate 360 permissions and/or bindings need to be in place. Thus, all NAT 361 traversal techniques ultimately involve the installation of bindings 362 in the NAT, and the modification of the application protocol messages 363 to reflect the bindings created by the NAT. 365 In all techniques, the NAT is responsible for installing the needed 366 bindings. However, the various traversal techniques differ in which 367 entities are responsible for modifying the application protocol 368 messages. Performing this modification requires the entity doing so 369 to be able to inspect them and then change them. If the entity that 370 needs to do the inspection and modification is not trusted to do so 371 by the application protocol, the application protocol itself might 372 provide security techniques which would prohibit the entity from 373 doing so. As such, the technique may require those application 374 security techniques to be disabled, thus undermining the security 375 provided overall. 377 Unfortunately, these portions of the message - the IP addresses or 378 domain names of hosts to which protocol messages need to be addressed 379 - are exactly the parts of the message that are most critical to 380 protect. Indeed, in the case of DNS, a DNS ALG modifies the primary 381 piece of information that protocols such as DNSSEC were designed to 382 protect [13]. Generally speaking, several classes of attacks can be 383 introduced if these addresses are not protected: 385 Denial-of-Service: If an attacker can modify these addresses as they 386 transit the network, the attacker can set them to point to a 387 target of a denial-of-service attack. Recipients of these 388 modified messages will direct subsequent messages to this target. 389 Depending on the protocol, this may result in substantial message 390 amplification properties. 392 Eavesdropping: Instead of modifying the addresses to point to a DoS 393 target, the attacker can modify them to point to themself. Once 394 it receives these messages, the attacker can forward them to the 395 proper recipient. This allows an attacker to eavesdrop the 396 protocol. 398 Service Disruption: An attacker can modify the addresses so that they 399 route to nowhere (for example, a non-existent IP host). This will 400 likely disrupt operation of the protocol, so that the client 401 receives no service. 403 Other types of attacks might be possible, depending on the specific 404 protocol. 406 Worse yet, many application protocols do not provide security that 407 protects only the IP address and port information in a protocol 408 message. Rather, larger parts of the message, if not the entire 409 message, is usually protected. As a result, if the security 410 techniques protecting the IP address and port information are 411 disabled, this will usually disable protection over other, perhaps 412 more critical, parts of the message. 414 Generally speaking then, the extent to which the traversal technique 415 undermines application layer protocol security measures depends on 416 two factors - whether or not the IP address and port information is 417 protected by security measures in the protocol, and the degree to 418 which the protocol entity is allowed by those measures to modify 419 those parts of message. In this regard, the entity which should 420 ideally modify the protocol message is the "natural" one - the entity 421 which is responsible for the creation of those parts of the message 422 in the first place. When the "natural" entity modifies the message, 423 its not really a modification at all; the message is created properly 424 in the first place with the IP addresses and ports on the public side 425 of the NAT. 427 This makes ALGs particularly problematic. Since ALGs reside in the 428 network, as opposed to in the clients or servers, they are never the 429 "natural" entity to modify the protocol message. It is a 430 man-in-the-middle, inspecting and modifying protocol messages without 431 explicit awareness or consent by the actual entities in the protocol. 432 In order for them to function, any application protocol security 433 measures protecting those parts of the message will need to be 434 disabled. The nature of the security functions that need to be 435 disabled differ between firewall and NAT. NAT requires the protocol 436 to be inspected and modified. As such, any security mechanisms 437 providing confidentiality or integrity must be disabled. For 438 firewalls, only inspection is needed. This means that 439 confidentiality mechanisms must be disabled; integrity mechanisms can 440 still function. 442 Consider the example of SIP. SIP messages carry a MIME payload that 443 describes the multimedia session being established. This payload is 444 usually the Session Description Protocol (SDP) [14]. SDP includes IP 445 address and port information, indicating the transport address where 446 media packets (such as audio and video) should be sent. The SDP is 447 protected by SIP's TLS mechanism, SIP S/MIME, and even digest 448 authentication with the auth-int quality of protection. If these are 449 disabled, SIP's security becomes almost impotent, and many attacks 450 are opened up. For example, if an attacker can access and modify the 451 addresses in the SDP, serious security holes are introduced. The 452 attacker can modify the address to direct the media stream to 453 themself, allowing for eavesdropping of a phone call. Worse yet, an 454 attacker can modify the address across several SIP messages, changing 455 them to point to a target of a distributed denial-of-service attack. 456 This target will receive a steady stream of media packets from the 457 recipients of the modified SIP messages. 459 As such, ALGs are only appropriate in protocols that lack security in 460 the first place, or in environments where the security measures in a 461 protocol are not needed, such as a closed network environment. 463 For those protocols where the client is responsible for generating 464 the IP address and port information in the protocol messages (such as 465 for SIP, RTSP, and FTP), and where the application protocol security 466 measures are desired, techniques involving modification of the client 467 (the UNSAF approaches in Section 3.2) are least intrusive, and do not 468 undermine the application protocol security. 470 4.1.2 Vulnerabilities Inherent in Traversal Technique 472 Section 4.1.1 considers security vulnerabilities introduced by NAT 473 traversal techniques because of the need to disable security features 474 in application protocols. Another class of attacks are possible 475 depending on the way in which the traversal technique works. 477 When the traversal technique is accomplished using a protocol, such 478 as STUN, TURN, ICE, RSIP and MIDCOM, the specifications for those 479 techniques include their security considerations. Many of these 480 security considerations are around secure creation of bindings in a 481 NAT. The bindings are what permit packets from the outside to be 482 routed to a particular host on the inside. They represent the 483 principal resource that needs to be protected by traversal security 484 techniques. Attacks become possible when bindings can be created by 485 unauthorized entities. Denial of service attacks can be launched if 486 the port space in a NAT is exhausted with unauthorized bindings, for 487 example. Numerous attacks are possible when a client believes it has 488 obtained a binding that maps to itself, when it fact it maps to 489 another client. These attacks are discussed in Section 12.1 of RFC 490 3489 [5]. 492 Generally speaking, the attacks documented in Section 12.1 of RFC 493 3489 are applicable to any traversal technique where the IP address 494 and port provided to the client are obtained from the source address 495 and port seen by the server, and where the address cannot be security 496 verified before use. This applies to STUN and Teredo, though the 497 usage of these techniques with ICE obviates this risk, since they are 498 validated before use. UNSAF techniques using relays, such as VPN and 499 TURN, do not suffer from these attacks. 501 These attacks may also be possible in SINN techniques depending on 502 the application protocol. In the case of SIP, SINN is susceptible to 503 these same attacks. The server determines the IP address and port to 504 send media traffic to by using the source IP and port of media it 505 receives from the client. A user eavesdropping a call setup request 506 could inject packets with the IP address and port of the target, 507 creating the attacks. These can also be mitigated with ICE, or 508 through the usage of secure media. 510 ALGs are also susceptible to these attacks, but they are particularly 511 vulnerable since the attacks are easy to launch. An ALG looks for IP 512 addresses present in a protocol message, and allocates a binding or 513 permission that will allow packets from the outside to traverse the 514 intermediary, and be delivered to the address present in the protocol 515 message. Creation of a binding to an arbitrary address is 516 accomplished by placing that address into the protocol payload. 517 Thus, source address spoofing is not required, as it is for other 518 traversal techniques. 520 This attack is particularly easy to launch. Consider a client who is 521 browsing the web behind a firewall. The user goes to a website of a 522 malicious provider. That website provides the user with a java 523 application implementing a basic SIP client. This application 524 generates a SIP INVITE message, and sends it back to the web server. 525 The INVITE message has, within its SDP, the IP address and port of a 526 mail server behind the firewall. The ALG within the firewall creates 527 a permission, allowing traffic from the outside, towards the mail 528 server. The provider can then inject a flood of packets towards the 529 mail server, disabling it. 531 In a similar attack, if an internal server has vulnerable ports - for 532 example, a port used for telnet-based CLI access - the INVITE request 533 can contain the IP address and port of that service on the server. 534 Rather than launching a DoS attack, the malicious provider can then 535 attempt to telnet into the server. 537 MIDCOM, like ALGs, create the binding based on the IP address and 538 port in the protocol messages, and thus have similar security 539 considerations. 541 For protocols like RSIP and NSIS, the bindings are created based on 542 protocol exchanges with the NAT. These exchanges generally require 543 return routability to the IP address and port of the client, and thus 544 provide a means to validate the private addresses used in the 545 binding. As such, they do not suffer from these attacks. 547 4.2 Deployability Considerations 549 The various techniques differ in their deployability. The primary 550 factors influencing deployability are the ability of the service 551 provider to modify parts of the system, and the number of such 552 elements that need to be modified. 554 As discussed in Section 2, the assumption here is that the service 555 provider owns the servers. They may or may not own the NATs in the 556 network, and they may or may not have any ability to affect the 557 clients. As such, traversal techniques that only involve modifying 558 the servers (the SINN technique) are the easiest to deploy. Those 559 which require modifying the clients (the UNSAF techniques) may be 560 feasible depending on whether the service provider can specify to its 561 customers a particular version of client software that needs to be 562 used. 564 However, techniques which require modification of the NAT itself can 565 be very hard to deploy. In many situations, the service provider is 566 not the same as the operator of the access network used by its 567 customers. In such cases, the access provider may be using NAT, and 568 the service provider has no ability to influence the features or 569 configuration of the device. It may be possible that the device 570 supports the needed capabilities (ALG, NSIS, RSIP, or MIDCOM) anyway. 571 This is more likely for those traversal techniques where the logic in 572 the NAT is not application-specific - NSIS, RSIP, MIDCOM and similar 573 protocols. However, in those cases, those capabilities in the NAT 574 need to be activated, and permissions set up for the application 575 component (the client in the case of NSIS and RSIP, or the proxy 576 server in MIDCOM) to control the NAT. The existence of these 577 permissions may hinge on a business relationship between the service 578 provider and the owner of the NAT. When the customers for a service 579 provider come from many different access networks, and thus many 580 different access network providers, this may be difficult to 581 establish. 583 For ALGs, there is a chicken and egg problem. Typically, vendors of 584 such devices build functions based on customer demand. A large 585 driver for demand is customer deployment and usage of a new 586 application. However, the application cannot be deployed or used 587 without the ALG that the vendor needs to build. Thus, the 588 application doesn't get deployed and the demand for the ALG never 589 manifests. This is a non-issue for protocols with ALGs widely 590 supported in NAT, including FTP and DNS. 592 Control is not the only factor impacting deployability; the number of 593 such components is also a factor. For example, if a service provider 594 is offering services to large enterprises, the enterprise is the 595 owner of the NAT. However, the service provider may have a 596 relatively small number of enterprise customers, and thus it may not 597 be unreasonable to require them to use a particular version of a NAT 598 product from a particular vendor in order to get services. As such, 599 the barriers to deploying solutions that require changes in NAT is 600 not as high. The problem becomes amplified for a service provider 601 offering services to small enterprises, of which there are a lot 602 more. 604 4.3 Manageability 606 When a failure occurs in the usage of an application (for example, a 607 network timeout or other problem), it will often fall on the 608 shoulders of the application provider to determine the cause of the 609 problem. Diagnosing such difficulties in an operational network is a 610 complex problem. As a result, many application layer protocols 611 contain built in features that allow a provider to trace a problem 612 after it has occurred. As an example, the Real Time Transport 613 Protocol (RTP) [15] provides a feedback mechanism that allows a 614 participant in a media session to track packet loss and latency as 615 received by the recipient. As another example, SIP provides message 616 header fields, such as Via and Warning, that allow for a trace of the 617 flow of a message through a series of elements, along with an 618 indication of detailed error conditions. Such diagnostic indications 619 become increasingly important as the application protocol involves a 620 large number of network elements or domains; the more entities in the 621 picture, the more places something can go wrong, and the more 622 important the need to find out where it went wrong. 624 Diagnosing network faults is only one aspect of manageability; 625 managing configuations, accounting, performance and security are also 626 key parts of operating a network. 628 The ability of the service provider to manage the service they are 629 providing is dependent on their ability to collect information from 630 the various elements on the way in which the service is operating, 631 and to correlate that information together for a coherent view on the 632 state of the network. The selection of a NAT traversal technique 633 impacts manageability of the network primarily due to the differing 634 levels of visibility that the service provider will have on the 635 operation of that aspect of the service. Visibility is based on the 636 level of transparency of operation. 638 Transparency is primarily an issue for ALGs. They represent yet 639 another entity that is application aware, and involved in the 640 processing of an application protocol. It is possible for failures 641 to occur at these elements, just like they can occur within actual 642 elements of the application protocol. When such failures do occur, 643 the transparent nature of the ALGs makes network diagnostics an 644 almost impossible task. 646 Firstly, it becomes hard to determine where the failure occurred. 647 Because the ALG is transparent, its operation is invisible to 648 protocol entities on either side of it. Indeed, there may even be 649 multiple ALGs inserted between legitimate protocol entities, and this 650 is often undetectable. No logging information or application 651 protocol features would be able to help pinpoint the location (in 652 terms of IP address or network provider) of the element that 653 generated the errored message. 655 With some application protocols, it might be possible for the ALG to 656 only be "partly transparent", which means that it might attempt to 657 make its presence known to other protocol entities. While this may 658 seem at first glance to be a good idea, it only further complicates 659 the problem. It results in entities that are now participants in the 660 application protocol for some aspects of the protocol, but not 661 others. This will likely lead to interoperability problems and 662 additional failure cases, because the behavior of the ALG is not 663 actually compliant to the full requirements outlined by the protocol 664 specification. 666 ALGs also make it hard to determine when a failure occurs. For 667 example, when an application provider deploys a new protocol element, 668 such as a server or intermediary, it knows that such an element has 669 been deployed, and can therefore look for correlations in errors. 670 Thus, if an operator deploys a new server on Wednesday, and it sees a 671 steep rise in support calls that very same day, there is a good 672 chance that the new server is at fault. 674 However, such correlations become impossible with ALGs. The reason 675 is that, in the problematic cases, the ALGs will be deployed by 676 different organizations than the provider of the application. As an 677 example, if an application provider deploys a Voice over IP 678 application using SIP, its customer might be an enterprise. One of 679 the routers buried deep within the enterprise network might have a 680 SIP ALG which is turned on one day by an enterprise administrator. 681 This represents a change in the application deployment topology, but 682 not one that is known to the application provider. If that ALG 683 introduces errors into the network, the VoIP provider will begin to 684 see problems and receive customer support calls, but have no idea 685 why, all of a sudden, errors started to happen. 687 Of course, an application provider is dependent on the enterprise for 688 deployment of normal IP infrastructure in order for the VoIP 689 application to work. It is also possible that the enterprise 690 administrator might deploy a traditional router which introduces 691 packet loss, thereby affecting the VoIP application as well. 692 However, this represents a fundamentally different case. Why? 693 Because the router provides a service (routing of IP datagrams) which 694 is well defined and understood by the developers of applications and 695 application protocols. As a result, those protocols are designed to 696 take into account the known failure modes of those elements (packet 697 loss and jitter, for example), and either recover from them, or allow 698 them to be detected so that further diagnosis can occur. An ALG is 699 different. It doesnt provide a well known service, and its failure 700 modes are not well understood, nor can they be taken into account as 701 part of the design of the application protocol. 703 In essence, the problem is that an ALG runs counter to the very 704 notion of the end-to-end principle. The end-to-end principle pushes 705 intelligence to the edges of the network. However, an ALG places 706 application intelligence back into the network. This alters the very 707 service model provided by the underlying IP network, and as a result, 708 makes it difficult for applications to be built around a service 709 model which is then ill defined. 711 4.4 Avaiability 713 The choice of a traversal technique impacts availability in many 714 ways. Firstly, techniques which add an additional component to the 715 network add an additional point of failure. This is primarily an 716 issue with the UNSAF techniques, all of which use an additional 717 server of some sort to support traversal through the NAT. 719 Secondly, network availability depends on the proper functioning of 720 the technique itself. For a technique to function, the essential 721 algorithm and protocol needs to be sound, and its implementation 722 needs to be correct. Both of these can be an issue. Why would the 723 algorithm and protocol be unsound? There are two reasons. The first 724 is that the technique may make assumptions that prove to be untrue in 725 the actual deployment. Second, the technique may not be sufficiently 726 well specified and may miss corner cases not conceived by the 727 designers. Let us consider both of these in turn. 729 Many of the traversal algorithms and techniques are built around 730 assumptions that they make. Frequently, these assumptions are around 731 behaviors in other components in the system. For example, the SINN 732 techniques make assumptions about the behavior of the clients. The 733 UNSAF techniques make assumptions about the operation of the NAT. 734 These assumptions can be wrong, resulting in brittle operation and 735 failure of the network to operate. STUN is particularly sensitive in 736 this regard; its NAT detection algorithm makes many assumptions about 737 the behavior of a NAT and then tries to validate that behavior by 738 black box testing. This has been addressed in a revision of STUN 739 [16], and when used in conjunction with other techniques, such as ICE 740 [8], the overall system makes fewer assumptions about operation of 741 components in the network, and it is therefore less brittle. service 742 providers should carefully consider the assumptions made by the 743 technique, and validate that these assumptions are correct to the 744 greatest extent possible. 746 Even if the assumptions are sound, the technique can still fail if 747 the technique has not been fully specified. This problem arises for 748 ALGs, since they are not "first class citizens" in the application 749 protocols they are interacting with. As such, their role in the 750 processing of the protocol is not well defined by specifications, 751 leading to the possibility that corner cases are missed, or that the 752 ALG has interactions with the protocol that cannot be easily 753 resolved. Similar issues arise in the SINN-based solutions, as these 754 are based on non-standard behaviors from elements in the network. 755 Operators should carefully consider that the various cases of 756 interest are fully supported by the traversal technique. 758 As an example, SIP describes numerous ways in which SDP can be 759 exchanged during a SIP call in the process of negotiation of codec 760 types and parameters. In the vast majority of calls, a basic 761 exchange occurs - one SDP is sent in the SIP INVITE message (this SDP 762 is called the offer), and a SDP in response (called an answer) in the 763 SIP 200 OK message. However, the spec allows numerous other cases 764 that are far less common, and as a result, likely to be overlooked by 765 ALG implementors. Furthermore, extensions to SIP, such as UPDATE 766 [17] add additional cases. Even if both endpoints in a call support 767 this specification, they will not be able to implement it if the ALG 768 does not support it. Of course, the fact that it is not supported by 769 the ALG will be hard to ascertain because of the diagnostic issues 770 described above. 772 Finally, the implementation of the technique may not be sound. This 773 is an issue not specific to NAT traversal, of course, but there are 774 some considerations, specifically for ALGs. The manufacturers of 775 intermediary devices housing the ALG are typically router and switch 776 vendors. Building such devices requires expertise at the IP layer, 777 and not for any specific application protocol. However, an ALG is 778 fundamentally an application protocol component, and to develop one 779 properly, requires expertise in that application protocol. This 780 would not be a problem if there was only one application protocol. 781 However, the intermediary vendor needs to have expertise for all 782 application protocols for which ALG support is needed. That is a far 783 more daunting task. Indeed, this problem is identified in the Midcom 784 Architecture [11], which attempts to extract the ALG functionality 785 from the intermediary, place it into an application layer entity, and 786 use a protocol (the MIDCOM protocol) to control the intermediary. 788 5. Conclusions 790 There are many techniques that have been described for facilitating 791 the traversal of NAT for protocols for which that capability is not 792 inherent. Broadly speaking, those techniques can be characterized by 793 the set of elements which need to be modified from the "normal" 794 behavior in order for the application to work. As such, a service 795 provider wishing to deploy an application has a wide choice about 796 what technique to use. There are many considerations in that 797 selection. Foremost amongst them is security. NAT traversal 798 techniques frequently impair the inherent security features of the 799 application protocol, and techniques where manipulation is done on 800 the element that is trusted to manipulate that aspect of the message 801 are preferred. Deployability is another concern, and different 802 techniques will only be applicable depending on the scope of control 803 and number of elements that need to be affected. The traveral 804 techniques also impact manageability, in that some techniques may be 805 difficult to diagnose and monitor in certain deployments. Finally, 806 availability is affected by the technique, due to assumptions on the 807 behavior of elements that may be false, incompletely specified 808 behavior, or incomplete implementation. 810 6. Security Considerations 812 Security is a critical consideration when selecting a technique for 813 NAT traversal. The various techniques differ substantially in the 814 impact on overall network security. Service providers should 815 consider carefully their security needs when selecting a technique. 817 7. IANA Considerations 819 There are no IANA considerations associated with this specification. 821 8. IAB Members 823 Internet Architecture Board members at the time of writing of this 824 document are: 826 Bernard Aboba 828 Harald Alvestrand 830 Rob Austein 832 Leslie Daigle 834 Patrik Faltstrom 836 Sally Floyd 838 Mark Handley 840 Bob Hinden 842 Geoff Huston 844 Jun-ichiro Itojun Hagino 846 Eric Rescorla 848 Pete Resnick 849 Jonathan Rosenberg 851 9 Informative References 853 [1] Srisuresh, P. and M. Holdrege, "IP Network Address Translator 854 (NAT) Terminology and Considerations", RFC 2663, August 1999. 856 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 857 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 858 Session Initiation Protocol", RFC 3261, June 2002. 860 [3] Schulzrinne, H., Rao, A. and R. Lanphier, "Real Time Streaming 861 Protocol (RTSP)", RFC 2326, April 1998. 863 [4] Daigle, L. and IAB, "IAB Considerations for UNilateral 864 Self-Address Fixing (UNSAF) Across Network Address 865 Translation", RFC 3424, November 2002. 867 [5] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, "STUN - 868 Simple Traversal of User Datagram Protocol (UDP) Through 869 Network Address Translators (NATs)", RFC 3489, March 2003. 871 [6] Rosenberg, J., "Traversal Using Relay NAT (TURN)", 872 draft-rosenberg-midcom-turn-06 (work in progress), October 873 2004. 875 [7] Huitema, C., "Teredo: Tunneling IPv6 over UDP through NATs", 876 draft-huitema-v6ops-teredo-04 (work in progress), January 2005. 878 [8] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A 879 Methodology for Network Address Translator (NAT) Traversal for 880 Multimedia Session Establishment Protocols", 881 draft-ietf-mmusic-ice-03 (work in progress), October 2004. 883 [9] Borella, M., Grabelsky, D., Lo, J. and K. Taniguchi, "Realm 884 Specific IP: Protocol Specification", RFC 3103, October 2001. 886 [10] Stiemerling, M., "A NAT/Firewall NSIS Signaling Layer Protocol 887 (NSLP)", draft-ietf-nsis-nslp-natfw-04 (work in progress), 888 October 2004. 890 [11] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A. and A. 891 Rayhan, "Middlebox communication architecture and framework", 892 RFC 3303, August 2002. 894 [12] Quittek, J., Stiemerling, M. and P. Srisuresh, "Definitions of 895 Managed Objects for Middlebox Communication", 896 draft-ietf-midcom-mib-04 (work in progress), January 2005. 898 [13] Srisuresh, P., Tsirtsis, G., Akkiraju, P. and A. Heffernan, 899 "DNS extensions to Network Address Translators (DNS_ALG)", RFC 900 2694, September 1999. 902 [14] Handley, M. and V. Jacobson, "SDP: Session Description 903 Protocol", RFC 2327, April 1998. 905 [15] Schulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, 906 "RTP: A Transport Protocol for Real-Time Applications", RFC 907 3550, July 2003. 909 [16] Rosenberg, J., "Simple Traversal of UDP Through Network Address 910 Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-00 911 (work in progress), October 2004. 913 [17] Rosenberg, J., "The Session Initiation Protocol (SIP) UPDATE 914 Method", RFC 3311, October 2002. 916 Author's Address 918 Jonathan Rosenberg, Editor 919 IAB 921 Intellectual Property Statement 923 The IETF takes no position regarding the validity or scope of any 924 Intellectual Property Rights or other rights that might be claimed to 925 pertain to the implementation or use of the technology described in 926 this document or the extent to which any license under such rights 927 might or might not be available; nor does it represent that it has 928 made any independent effort to identify any such rights. Information 929 on the procedures with respect to rights in RFC documents can be 930 found in BCP 78 and BCP 79. 932 Copies of IPR disclosures made to the IETF Secretariat and any 933 assurances of licenses to be made available, or the result of an 934 attempt made to obtain a general license or permission for the use of 935 such proprietary rights by implementers or users of this 936 specification can be obtained from the IETF on-line IPR repository at 937 http://www.ietf.org/ipr. 939 The IETF invites any interested party to bring to its attention any 940 copyrights, patents or patent applications, or other proprietary 941 rights that may cover technology that may be required to implement 942 this standard. Please address the information to the IETF at 943 ietf-ipr@ietf.org. 945 Disclaimer of Validity 947 This document and the information contained herein are provided on an 948 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 949 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 950 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 951 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 952 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 953 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 955 Copyright Statement 957 Copyright (C) The Internet Society (2005). This document is subject 958 to the rights, licenses and restrictions contained in BCP 78, and 959 except as set forth therein, the authors retain all their rights. 961 Acknowledgment 963 Funding for the RFC Editor function is currently provided by the 964 Internet Society.