idnits 2.17.1 draft-eggert-middlebox-control-survey-01.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 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 834. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 845. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 852. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 858. 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 document has an RFC 3978 Section 5.2(a) Derivative Works Limitation clause. == The copyright year in the IETF Trust 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 (July 9, 2007) is 6128 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-07) exists of draft-cheshire-nat-pmp-02 == Outdated reference: A later version (-12) exists of draft-ietf-behave-multicast-08 == Outdated reference: A later version (-12) exists of draft-ietf-behave-nat-icmp-04 == Outdated reference: A later version (-08) exists of draft-ietf-behave-tcp-07 == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-14 == Outdated reference: A later version (-20) exists of draft-ietf-nsis-ntlp-13 == Outdated reference: A later version (-04) exists of draft-manner-nsis-nslp-auth-03 == Outdated reference: A later version (-05) exists of draft-wing-behave-nat-control-stun-usage-02 == Outdated reference: A later version (-03) exists of draft-woodyatt-ald-01 Summary: 1 error (**), 0 flaws (~~), 10 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group L. Eggert 3 Internet-Draft P. Sarolahti 4 Intended status: Informational R. Denis-Courmont 5 Expires: January 10, 2008 V. Stirbu 6 Nokia 7 H. Tschofenig 8 Nokia Siemens Networks 9 July 9, 2007 11 A Survey of Protocols to Control Network Address Translators and 12 Firewalls 13 draft-eggert-middlebox-control-survey-01.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 This document may not be modified, and derivative works of it may not 22 be created, except to publish it as an RFC and to translate it into 23 languages other than English. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on January 10, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 This document surveys existing protocols for the control of network 50 address translators and firewalls. It includes standards-level 51 protocols developed by the IETF and other standards organizations, as 52 well as protocols designed by individuals. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2. Protocol Classification . . . . . . . . . . . . . . . . . . . 4 58 3. SOCKS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 59 4. NSIS - NAT/Firewall Signaling Layer Protocol . . . . . . . . . 7 60 5. MIDCOM - Managed Objects for Middlebox Communication . . . . . 11 61 6. SIMCO - NEC's Simple Middlebox Configuration Protocol . . . . 11 62 7. Diameter Gq', Rx+, Gx+ . . . . . . . . . . . . . . . . . . . . 11 63 8. UPnP - Internet Gateway Device Standardized Device Control 64 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 65 9. NAT-PMP - NAT Port Mapping Protocol . . . . . . . . . . . . . 13 66 10. STUN - Controlling NAT Bindings using STUN . . . . . . . . . . 14 67 11. RSIP - Realm-Specific IP . . . . . . . . . . . . . . . . . . . 14 68 12. ALD - Application Listener Discovery for IPv6 . . . . . . . . 14 69 13. NLS - Network Layer Signaling Transport Layer . . . . . . . . 15 70 14. AFWC - Authorized IP Firewall Control Application . . . . . . 15 71 15. Security Considerations . . . . . . . . . . . . . . . . . . . 15 72 16. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 74 18. Informative References . . . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 76 Intellectual Property and Copyright Statements . . . . . . . . . . 20 78 1. Introduction 80 Network address translators (NATs) and firewalls - frequently 81 referred to as "middleboxes" - are a subject of active discussion in 82 the IETF and related development and standardization communities. 83 These devices are not part of the traditional end-to-end Internet 84 architecture, because they usually operate on transport- and higher- 85 layer information inside the network, which is a layering violation 86 in the original architecture, because operating on that information 87 was the exclusive providence of the end-hosts. 89 However, in practice, NATs have turned out to be necessary to be able 90 to mitigate the IPv4 address space limitations of many network 91 domains. Similarly, because the networking software in many systems 92 has turned out to contain security defects of different kinds, use of 93 firewalls is common to protect the systems from attacks coming from 94 the network. Another motivation for firewalls is to protect against 95 the abuse of possibly scarce of expensive bandwidth, for example, 96 unwanted traffic on wireless links. 98 A shared disadvantage of NATs and firewalls is that they often encode 99 knowledge about a particular set of higher-layer protocols and 100 applications in order to operate. This practice prevents new types 101 of network protocols or applications from being deployed end-to-end, 102 unless the middleboxes are upgraded or reconfigured as well. For 103 example, a firewall is usually configured with a list of ports for a 104 set of common network applications, preventing introduction of new 105 applications. Furthermore, they commonly only support traditional 106 transport protocols, such as TCP and UDP, preventing the use of other 107 protocols, such as IPsec, IP tunneling, or other transport protocols. 108 In addition, many NATs and firewalls maintain some state for each 109 active transport-layer session that typically needs to be refreshed 110 in constant intervals, and can be initiated only by certain hosts. 112 The IETF is currently developing recommendations for the operation of 113 NATs in the BEHAVE working group. These recommendations provide 114 guidelines for how NATs should translate a number of common 115 protocols, including TCP [I-D.ietf-behave-tcp], UDP [RFC4787], ICMP 116 [I-D.ietf-behave-nat-icmp] and IP multicast 117 [I-D.ietf-behave-multicast]. Other organizations are developing 118 similar guidelines. One example are Microsoft's requirements for the 119 "Works with Windows Vista" and "Certified for Windows Vista" logo 120 program [VISTALOGO] (see page 121 to page 132). 122 Even if these efforts result in more unified behavior of middleboxes, 123 they will not necessarily overcome the above-mentioned limitations: 124 different protocols and applications will still need to adapt to the 125 behavior of NATs and firewalls. Commonly, new protocols must be 126 encapsulated into UDP packets in order to pass through these devices. 127 Although the UDP header and protocol logic are minimal and do not 128 consume much network capacity, the use of UDP causes other problems, 129 because it is not connection-oriented. Because there are no messages 130 for connection establishment or connection tear-down in UDP, a 131 stateful NAT or firewall needs to monitor ongoing UDP traffic between 132 a source and destination, and in the absence of such traffic assumes 133 that the session has ended, removing the related session state. In 134 practice, the timers for state clean-up have turned out to be short 135 (on the order of seconds), requiring the end hosts to transmit 136 frequent and resource-consuming keep-alive messages to refresh the 137 session state maintained at middleboxes. 139 A more advanced method to overcome the limitations caused by NATs or 140 firewalls would be to allow end-hosts to signal their communication 141 characteristics and profiles explicitly to the NATs and firewalls, or 142 alternatively to allow these devices to signal their configuration 143 information to the end-hosts. With such schemes, the number of 144 state-refreshing keep-alives could be significantly reduced, and NATs 145 and firewalls could be made directly aware of the communication 146 characteristics of the end-hosts. 148 A number of existing protocols have been proposed for this purpose, 149 and new proposals are being prepared. This document aims to support 150 such efforts by surveying existing proposals and by discussing the 151 the benefits and shortcomings of these schemes. 153 2. Protocol Classification 155 This section categorizes the proposals into clusters to illustrate 156 the major design choices. 158 o End-System-Initiated Protocols 160 * Two Party Approach 162 + UPnP (Section 8) 164 + NAT-PMP (Section 9) 166 * Multi-Party Approach 168 + STUN controlled NAT (Section 10) 170 + NLS (Section 13) 171 + NSIS NATFW NSLP (Section 4) 173 o Third-Party-Initiated Approaches 175 * Diameter Gq', Rx+, Gx+ (Section 7) 177 * SIMCO (Section 6) 179 * MIDCOM (Section 5) 181 A reasonable classification of RSIP (Section 11), ALD (Section 12), 182 SOCKS (Section 3) and AFWC (Section 14) is still pending. 184 The following document were (or are being) developed within the IETF: 186 o SOCKS Section 3 188 o NSIS NATFW NSLP, Section 4 190 o MIDCOM - Managed Objects for Middlebox Communication, Section 5 192 o SIMCO - NEC's Simple Middlebox Configuration Protocol, Section 6 194 These protocols were developed outside the IETF: 196 o UPnP - Internet Gateway Device Standardized Device Control 197 Protocol (Section 8) 199 o Diameter Gq', Rx+, Gx+ (Section 7) 201 The following protocols are proposals by individuals: 203 o NAT-PMP - NAT Port Mapping Protocol (Section 9) 205 o STUN - Controlling NAT Bindings using STUN (Section 10) 207 o RSIP - Realm-Specific IP (Section 11) 209 o ALD - Application Listener Discovery for IPv6 (Section 12) 211 o NLS - Network Layer Signaling Transport Layer (Section 13) 213 o AFWC - Authorized IP Firewall Control Application (Section 14) 215 3. SOCKS 217 3.1. Protocol Overview 219 The SOCKS Protocol Version 5 [RFC1928] defines a method for nodes 220 located on an IP network (such as an Intranet with no routing to the 221 Internet) to establish TCP sessions and exchange UDP datagrams with 222 another IP network (usually the global Internet). To that end, a 223 SOCKS server must be located on the boundary of both networks, and 224 SOCKS clients must explicitly request the server to relay their 225 communication sessions. 227 When a SOCKS client establishes a TCP session to the remote network, 228 it first connects to the SOCKS server on a well-known TCP port, 229 sending a connection request with optional authentication 230 credentials. The request specifies in which direction the TCP 231 session is to be established, i.e., whether the SOCKS server will act 232 as the active or passive endpoint. The SOCKS server, if it accepts 233 the request, informs the client of the external IP address and TCP 234 port number that it will use. If the SOCKS server acts as the 235 passive endpoint, it sends an additional response once the TCP three- 236 way handshake is completed. The SOCKS server then forwards traffic 237 between the internal and external TCP sessions, until either of them 238 is terminated. 240 UDP sessions are also initially negotiated via a TCP session to the 241 SOCKS server, in a similar manner. If successful, the client obtains 242 the IP address and UDP port number of a UDP relay server. The relay 243 forwards UDP datagrams between the local and remote networks. When 244 sending a datagram, the client adds an additional, SOCKS-specific 245 header, which carries the IP address or DNS name of the remote peer 246 and the intended destination UDP port number of the datagram. The 247 relay adds the same header when forwarding datagrams from the remote 248 network back to the client. 250 3.2. Protocol Analysis 252 The SOCKS protocol makes few assumptions about the network 253 environment it operates in. In particular, there can be any number 254 NAT/firewall devices between the client and the SOCKS server, and 255 there need not be a router between the local and remote networks. It 256 is assumed that the SOCKS server itself can freely exchange TCP and 257 UDP packets with the remote network. 259 SOCKS supports both IPv4 and IPv6 as well as translation from one to 260 the other. SOCKS only supports UDP and TCP as transport protocols. 261 Conveyance of IP header parameters other than the IP addresses (such 262 as IP options, hop limit, TOS field, etc.) are not defined. SOCKS 263 cannot be used for generic server applications: only one passive TCP 264 session per request is allowed. 266 The protocol is mature and implementations for clients and servers 267 are widely available. SOCKS is supported in many FTP and HTTP 268 clients. Applications must usually be modified to support SOCKS, but 269 it is also possible to implement SOCKS transparently as a shim layer 270 above the BSD socket API. 272 SOCKS requires manual configuration on the client. SOCKS server 273 address and optional credentials must be explicitly provisioned. 275 4. NSIS - NAT/Firewall Signaling Layer Protocol 277 4.1. Protocol Overview 279 NSIS uses a two-layer architecture with one lower-layer transport 280 (NTLP) and multiple upper-layer application signaling protocols 281 (NSLPs). This section first discusses the generic properties of the 282 NTLP transport and then the specific characteristics of the NAT/ 283 Firewall signaling protocol built upon it. 285 GIST [I-D.ietf-nsis-ntlp] establishes NTLP "routing" state that 286 allows signaling messages to be routed forwards and backwards along a 287 path. GIST also provides two ways to send signaling messages: 289 1. An RSVP-like signaling style with end-to-end addressed messages 290 that contain the source and the destination IP addresses of the 291 data flow. The messages are intercepted along the path by NSIS 292 nodes interested in these messages (by using Router Alert 293 Options). The GIST specification refers to this as the Datagram 294 mode (D-mode). 296 2. Connection mode (or C-mode) is used when NSIS nodes are directly 297 addressed. This mode assumes that the discovery procedure has 298 already finished (or the address of the receiving node is known 299 via other means) and information about the node is already 300 available. 302 An important part of GIST is its discovery mechanism. As an outcome 303 of the discovery procedure the querying node learns the address of 304 the responding node, its capability and establishes GIST routing 305 state. 307 Once the next NSIS aware node is known, a messaging association can 308 be established between these two nodes using C-mode. The same 309 procedure is repeated again and again for the C-Mode until the last 310 GIST node is reached. 312 The NAT/Firewall NSLP description [I-D.ietf-nsis-nslp-natfw] defines 313 an NSIS Signaling Layer Protocol (NSLP) for configuration of network 314 address translators and firewalls on top of GIST. 316 The NATFW NSLP uses GIST as a transport for its signaling messages. 317 Objects about a created NAT binding, as well as lifetime and 318 signaling information (such as protocol headers and error messages) 319 are contained in a NATFW NSLP message itself. All other information 320 about the flow identifier and the session identifier is carried in 321 GIST. For communication security between neighboring NATFW NSLP 322 nodes the usage of Transport Layer Security (TLS) is specified. The 323 usage of an authorization token is possible 324 [I-D.manner-nsis-nslp-auth] 326 It is useful to distinguish between two signaling modes: 328 The first mode (CREATE) is the traditional way of creating a NAT 329 binding by sending a message from the data sender along the path 330 to the data receiver. Figure 1 shows a message exchange for this 331 signaling mode. 333 The second mode (EXTERNAL) is used when a data receiver is behind 334 a NAT and wants to establish a NAT binding to allow incoming data 335 traffic. Figure 2 shows this mode. It was necessary to introduce 336 this mode, because of an end-to-end reachability problem. 337 Furthermore, it provides a transition scenario where the data 338 receiver behind a NAT or a firewall is able to configure their 339 middlebox locally. 341 Private Address Public Address 342 +----------+ Space +----------+ Space +----------+ 343 | Data | | NAT | | Data | 344 | Sender | | | | Receiver | 345 +----------+ +----------+ +----------+ 346 | | | 347 | CREATE | CREATE | 348 |----------------------------->+--------------------------->| 349 | | | 350 | RESPONSE | RESPONSE | 351 |<-----------------------------+<---------------------------| 352 | | | 353 ============================================================> 354 Direction of data traffic 356 Figure 1: The NATFW NSLP CREATE Mode 358 With the CREATE mode shown in Figure 1 the data sender (which happens 359 to be the NSIS initiator in this case) sends a message to request a 360 NAT binding to be created. The message is targeted to the data 361 receiver, which returns a success or failure in the RESPONSE message. 362 The data sender learns about the new NAT binding with information 363 carried in the RESPONSE message. 365 Public Internet Private Address 366 +----------+ +----------+ Space +----------+ 367 | Data | | NAT | | Data | 368 | Sender | | | | Receiver | 369 +----------+ +----------+ +----------+ 370 | | | 371 | | EXTERNAL | 372 | |<---------------------------| 373 | | | 374 | | RESPONSE | 375 | |--------------------------->| 376 | | | 377 ============================================================> 378 Direction of data traffic 380 Figure 2: The NATFW NSLP EXTERNAL Mode 382 With the EXTERNAL mode shown in Figure 2 the data receiver behind a 383 NAT creates a NAT binding. This allows data traffic from a node on 384 the Internet to be received. Please note that the EXTERNAL message 385 is sent in the opposite direction of the data traffic. 387 4.2. Protocol Analysis 389 This section discusses the pros and cons of the protocol. 391 Is the protocol is restricted to certain applications or network 392 environments? 394 The usage of the protocol is not restricted to a specific environment 395 but to take advantage of its features it is necessary that Network 396 Address Translators and firewalls implement this protocol. 398 Does it require additional infrastructure, lower-layer features or 399 cooperation from other entities? 401 While the protocol supports a zero-configuration scheme so that it 402 works in almost network topologies. The protocol works with multiple 403 nested NATs and firewalls unless the data receiver is behind a 404 complex network topology combined with routing asymmetry (without) 405 state synchronization between the edge firewalls when the data sender 406 does not support the protocol as well. 408 To make use of the security functionality and to perform meaningful 409 authorization capabilities it is, however, necessary to have some 410 form of security infrastructure in place. The protocol provides a 411 very flexible security model with support in different security 412 architectures. 414 Furthermore,for the EXTERNAL signal mode to work it is necessary that 415 the edge firewall or edge NAT towards the public Internet terminates 416 the signaling message exchange since the message might be targeted 417 towards an address that does not exist. 419 Does it require modifications to applications? 421 The protocol can be used in a proxy mode where no end host support is 422 necessary. In order to benefit best from the supported functionality 423 is is advisable to make applications aware of the capability. 425 How mature is the specification? Has the protocol seen any use or 426 deployment? 428 The specification is passed Working Group Last Call and several 429 implementations (including open source implementations) exist. 430 However, the protocol is not deployed yet. 432 How does the client discover the middlebox? 434 The middlebox discovery is accomplished as part of the functionality 435 provided in GIST, namely specifically crafted packets that look like 436 data packets are used. These discovery packets are marked with a 437 router alert option and they are intercepted by firewalls and NATs 438 along the path. 440 What kinds of "pinholes" does the protocol support? 442 The protocol supports a long range of pinholes. The complete list 443 can be found in Section 5.8.1.1 of GIST. 445 What kinds of prior security arrangements does the protocol 446 assume? 448 When client authentication is required then the credentials of a 449 ciphersuite available for TLS need to be available to the end host. 450 The security architecture builds on a hop-by-hop security 451 architecture. Alternatively, the usage of an authorization token is 452 possible. Authorization tokens can also be used in a non-hop-by-hop 453 fashion. 455 The security architecture is meant to provide strong security 456 protection rather than opportunistic security mechanisms. Further 457 security mechanisms can be added without the need to re-define the 458 protocol by plugging new security functionality into GIST or the 459 NATFW NSLP and my making use of the initial capability exchange. 461 Does it work if routers (not supporting this protocol) somewhere 462 drop packets with IP options? 464 GIST and the NATFW NSLP has problems if routers drop packets marked 465 with the Router Alert option. It is, however, possible to extend 466 GIST with a different path-coupled signaling procedure. 468 Does the protocol allow running a general-purpose server behind 469 the NAT/firewall? 471 Yes. 473 5. MIDCOM - Managed Objects for Middlebox Communication 475 To be completed [RFC3303]. 477 6. SIMCO - NEC's Simple Middlebox Configuration Protocol 479 To be completed [RFC4540]. 481 7. Diameter Gq', Rx+, Gx+ 483 To be completed [need reference]. 485 8. UPnP - Internet Gateway Device Standardized Device Control Protocol 487 8.1. Protocol Overview 489 The Internet Gateway Device (IGD) is an "edge" interconnection device 490 between a residential Local Area Network (LAN) and a Wide Area 491 Network (WAN), providing connectivity to the Internet for the 492 networked devices in the residential network. The IGD could be 493 physically implemented as a dedicated, standalone device or modeled 494 as a set of Universal Plug-and-Play (UPnP) devices and services on a 495 personal computer. 497 As an UPnP-based protocol, the IGD Standardized Device Control 498 Protocol [UPNP] inherits the features that the UPnP Device 499 Architecture provides for support zero-configuration, "invisible" 500 networking, and automatic discovery for a breadth of device 501 categories. Any device can dynamically join a network, obtain an IP 502 address, announce its name, convey its capabilities upon request, and 503 learn about the presence and capabilities of other devices. Devices 504 can disconnect from the network automatically without leaving any 505 unwanted state information behind. 507 The IGD Standardized Device Control Protocol contains a set of 508 devices and services that allow clients (in the UPnP context also 509 called "Control Points") to control the initiation and termination of 510 connections, monitor status and events of connections, or manage host 511 configuration services, e.g., DHCP or Dynamic DNS. Among these 512 services, the "WANIPConnection" service provides the functionality 513 that allows the Control Points to manage the network address 514 translation on the IGD device. 516 The IGD Standardized Device Control Protocol preserves the ability of 517 non-UPnP devices to initiate and/or share Internet access. 519 8.2. Protocol Analysis 521 The IGD Standardized Device Control Protocol is intended to be used 522 in unmanaged network environments such as those found typically in 523 residential networks. The residential network can have up to four 524 segments, a limitation inherited from the UPnP Device Architecture, 525 because the TTL value for the link-local multicast discovery messages 526 is four. 528 By design, the protocol does permit the presence of several 529 residential gateways in the same network and also permits residential 530 gateways to have multiple connections to the Internet. In practice, 531 a lack of routing mechanisms across multiple, simultaneously active 532 WAN connections on multiple WAN interfaces and related issues caused 533 by multiple, simultaneously active Internet Gateway devices (e.g., 534 default gateway conflict resolution, load balancing or fail over) 535 make scenarios other than that of a single Gateway Device with a 536 single Internet connection difficult to support. 538 A residential gateway supporting the IGD Standardized Device Control 539 Protocol is able to operate in two modes. In "routed mode", the 540 gateway shares the routable WAN IP address with the control points on 541 the LAN using NAT. In "bridged" mode, all Ethernet packets from 542 devices on the LAN are bridged to the WAN. In scenarios where the IP 543 address on the WAN interface is not routable, the device can be 544 switched from routed to bridged mode, allowing both the discovery of 545 IGD Standardized Device Control Protocol devices further along the 546 path as well as the use of other NAT hole-punching protocols. 548 Applications that intend to create port mappings on a residential 549 gateway supporting the IGD Standardized Device Control Protocol need 550 to have embedded control point functionality, enabling them to create 551 port mappings from TCP or UDP port on the external IPv4 address to 552 the corresponding ports on the internal IPv4 addresses. 554 The protocol is implemented in more than 90% of the consumer routers, 555 although the functionality might not be enabled by default. 557 9. NAT-PMP - NAT Port Mapping Protocol 559 9.1. Protocol Overview 561 The NAT Port Mapping Protocol [I-D.cheshire-nat-pmp] is a light- 562 weight binary protocol running on top of UDP between client hosts and 563 their IPv4 gateway. Clients can send requests to their first-hop 564 gateway on a well-known UDP port, in order to determine whether NAT- 565 PMP is supported. If that is the case, they will also learn the 566 external IPv4 address of the gateway device. 568 If the gateway supports NAT-PMP, a host can assume that it is behind 569 a NAT and start sending request for mapping of external TCP or UDP 570 ports on the external IPv4 address. Mappings can be destroyed 571 explicitly. They also automatically expire after a timeout that can 572 be negotiated per mapping, unless refreshed. 574 Through the use of link-local multicast, the gateway can notify hosts 575 if its external IP changes, and/or if it has rebooted. In the latter 576 case, hosts are expected to recreate any mappings. This procedure 577 attempts to protect against loss of state at the gateway. 579 NAT-PMP assumes that there is one and only one NAT along the path, 580 which also has to be the first-hop gateway. A gateway must not 581 enable NAT-PMP if it is does not perform address/port translation. 583 9.2. Protocol Analysis 585 NAT-PMP is applicable to small, unmanaged, non-routed networks, 586 connecting multiple hosts to the IPv4 Internet through a single 587 public IPv4 address. It does not require any configuration. Support 588 from the gateway can be auto-detected by clients, and the trust model 589 is solely based on network attachment. There is no support for IPv6, 590 nor is there support for transport protocols other than TCP or UDP. 591 Nested NATs and non-NAT'ing firewalls are not supported. 593 NAT-PMP covers the same use cases as [UPNP], although it is not as 594 widely deployed today. (NAT-PMP is currently mostly implemented by 595 equipment from Apple Computer, Inc.). The specification is recent, 596 but nevertheless mature. 598 Applications will normally need to be modified to explicitly request 599 port mappings from the operating system, which would then operate the 600 NAT-PMP state machine and message handling. By design, the protocol 601 allows applications to expose services to the outside, so hole- 602 punching could conceivably be done automatically whenever an 603 application listens to a local TCP port (although this would probably 604 have unwelcome security implications). 606 10. STUN - Controlling NAT Bindings using STUN 608 To be completed [I-D.wing-behave-nat-control-stun-usage]. 610 11. RSIP - Realm-Specific IP 612 To be completed [RFC3103]. 614 12. ALD - Application Listener Discovery for IPv6 616 12.1. Protocol Overview 618 Application Listener Discovery for IPv6 [I-D.woodyatt-ald] is a 619 light-weight, binary protocol to explicitly punch holes through 620 stateful IPv6 firewalls. It uses ICMPv6 for signaling and is auto- 621 configured through an explicit ICMPv6 router advertisement option. 623 If the gateway supports ALD, a host can request the opening of holes 624 for any incoming packet toward its own IPv6 address, based on one of 625 multiple possible criteria: 627 o always 629 o an IP protocol (excluding IPv6 extension headers) 631 o for any standard transport protocol, a destination port number 633 o for IPsec ESP, an SPI value 634 Holes automatically expire if not refreshed before a negotiated 635 timeout. The gateway can additionally notify hosts through 636 unsolicited advertisements if it has rebooted or lost state. 638 12.2. Protocol Analysis 640 ALD is aimed at unmanaged IPv6 networks, where it might not be 641 acceptable to pass any unsolicited packets coming from the outside 642 toward any hosts in the internal network. ALD needs support from all 643 IPv6 routers within the network, because clients learn the ALD 644 middlebox address through IPv6 Neighbor Discovery auto-configuration. 645 It is expected that ALD will operate on the router itself in most 646 cases. As with IPv6 Neighbor Discovery, there is no authentication. 648 The specification is currently a work-in-progress; there is no known 649 deployment to date. Applications would supposedly need slight 650 modifications, similar as with [UPNP] or [I-D.cheshire-nat-pmp]. 652 ALD can handle "pinholes" for any transport protocol, although it is 653 limited to IPv6 networks, and is meant to restore the ability to 654 operate general-purpose servers behind stateful firewalls. It 655 currently does not explicitly support nesting, though ALD middleboxes 656 could probably forward pinholes request in a hierarchical manner 657 (from innermost to outermost device). 659 13. NLS - Network Layer Signaling Transport Layer 661 To be completed [I-D.shore-nls-fw]. 663 14. AFWC - Authorized IP Firewall Control Application 665 To be completed [I-D.shore-afwc]. 667 15. Security Considerations 669 This document is a survey of existing protocols and does not raise 670 any new security considerations. The security considerations of the 671 surveyed protocols are discussed in their respective specifications, 672 at least for protocols developed within the IETF. 674 16. IANA Considerations 676 This document raises no IANA considerations. 678 17. Acknowledgments 680 The authors would like to thank Pasi Eronen, Albrecht Schwarz and Dan 681 Wing for their comments on this document. 683 Dave Thaler provided information on the "Works with Windows Vista" 684 and "Certified for Windows Vista" logo program [VISTALOGO]. 686 18. Informative References 688 [I-D.cheshire-nat-pmp] 689 Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", 690 draft-cheshire-nat-pmp-02 (work in progress), 691 October 2006. 693 [I-D.ietf-behave-multicast] 694 Eckert, T. and D. Wing, "IP Multicast Requirements for a 695 Network Address (and port) Translator (NAT)", 696 draft-ietf-behave-multicast-08 (work in progress), 697 July 2007. 699 [I-D.ietf-behave-nat-icmp] 700 Srisuresh, P., "NAT Behavioral Requirements for ICMP 701 protocol", draft-ietf-behave-nat-icmp-04 (work in 702 progress), July 2007. 704 [I-D.ietf-behave-tcp] 705 Guha, S., "NAT Behavioral Requirements for TCP", 706 draft-ietf-behave-tcp-07 (work in progress), April 2007. 708 [I-D.ietf-nsis-nslp-natfw] 709 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 710 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-14 (work in 711 progress), March 2007. 713 [I-D.ietf-nsis-ntlp] 714 Schulzrinne, H. and R. Hancock, "GIST: General Internet 715 Signalling Transport", draft-ietf-nsis-ntlp-13 (work in 716 progress), April 2007. 718 [I-D.manner-nsis-nslp-auth] 719 Manner, J., "Authorization for NSIS Signaling Layer 720 Protocols", draft-manner-nsis-nslp-auth-03 (work in 721 progress), March 2007. 723 [I-D.shore-afwc] 724 Shore, M. and D. McGrew, "An Authorized IP Firewall 725 Control Application", draft-shore-afwc-00 (work in 726 progress), September 2006. 728 [I-D.shore-nls-fw] 729 Shore, M., "The NLS Firewall Application", 730 draft-shore-nls-fw-00 (work in progress), February 2006. 732 [I-D.wing-behave-nat-control-stun-usage] 733 Wing, D. and J. Rosenberg, "Discovering, Querying, and 734 Controlling Firewalls and NATs using STUN", 735 draft-wing-behave-nat-control-stun-usage-02 (work in 736 progress), June 2007. 738 [I-D.woodyatt-ald] 739 Woodyatt, J., "Application Listener Discovery (ALD) for 740 IPv6", draft-woodyatt-ald-01 (work in progress), 741 June 2007. 743 [RFC1928] Leech, M., Ganis, M., Lee, Y., Kuris, R., Koblas, D., and 744 L. Jones, "SOCKS Protocol Version 5", RFC 1928, 745 March 1996. 747 [RFC3103] Borella, M., Grabelsky, D., Lo, J., and K. Taniguchi, 748 "Realm Specific IP: Protocol Specification", RFC 3103, 749 October 2001. 751 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 752 A. Rayhan, "Middlebox communication architecture and 753 framework", RFC 3303, August 2002. 755 [RFC4540] Stiemerling, M., Quittek, J., and C. Cadar, "NEC's Simple 756 Middlebox Configuration (SIMCO) Protocol Version 3.0", 757 RFC 4540, May 2006. 759 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 760 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 761 RFC 4787, January 2007. 763 [UPNP] UPnP Forum, "Internet Gateway Device (IGD) Standardized 764 Device Control Protocol V 1.0", November 2001. 766 [VISTALOGO] 767 Microsoft Corporation, "Windows Logo Program Device 768 Requirements for Windows Vista Client and Windows Server 769 code named 'Longhorn' (Version 3.09)", December 2006. 771 Authors' Addresses 773 Lars Eggert 774 Nokia Research Center 775 P.O. Box 407 776 Nokia Group FIN-00045 777 Finland 779 Phone: +358 50 4824461 780 Email: lars.eggert@nokia.com 781 URI: http://research.nokia.com/people/lars_eggert/ 783 Pasi Sarolahti 784 Nokia Research Center 785 P.O. Box 407 786 Nokia Group FIN-00045 787 Finland 789 Phone: +358 50 4876607 790 Email: pasi.sarolahti@nokia.com 791 URI: http://www.iki.fi/pasi.sarolahti/ 793 Remi Denis-Courmont 794 Nokia Technology Platforms 795 P.O. Box 407 796 Nokia Group FIN-00045 797 Finland 799 Phone: +358 50 4876315 800 Email: remi.denis-courmont@nokia.com 801 URI: http://www.remlab.net/ 803 Vlad Stirbu 804 Nokia Technology Platforms 805 P.O. Box 407 806 Nokia Group FIN-00045 807 Finland 809 Phone: +358 50 3860572 810 Email: vlad.stirbu@nokia.com 811 Hannes Tschofenig 812 Nokia Siemens Networks 813 Otto-Hahn-Ring 6 814 Munich, Bavaria 81739 815 Germany 817 Email: hannes.tschofenig@nsn.com 818 URI: http://www.tschofenig.com/ 820 Full Copyright Statement 822 Copyright (C) The IETF Trust (2007). 824 This document is subject to the rights, licenses and restrictions 825 contained in BCP 78, and except as set forth therein, the authors 826 retain all their rights. 828 This document and the information contained herein are provided on an 829 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 830 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 831 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 832 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 833 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 834 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 836 Intellectual Property 838 The IETF takes no position regarding the validity or scope of any 839 Intellectual Property Rights or other rights that might be claimed to 840 pertain to the implementation or use of the technology described in 841 this document or the extent to which any license under such rights 842 might or might not be available; nor does it represent that it has 843 made any independent effort to identify any such rights. Information 844 on the procedures with respect to rights in RFC documents can be 845 found in BCP 78 and BCP 79. 847 Copies of IPR disclosures made to the IETF Secretariat and any 848 assurances of licenses to be made available, or the result of an 849 attempt made to obtain a general license or permission for the use of 850 such proprietary rights by implementers or users of this 851 specification can be obtained from the IETF on-line IPR repository at 852 http://www.ietf.org/ipr. 854 The IETF invites any interested party to bring to its attention any 855 copyrights, patents or patent applications, or other proprietary 856 rights that may cover technology that may be required to implement 857 this standard. Please address the information to the IETF at 858 ietf-ipr@ietf.org. 860 Acknowledgment 862 Funding for the RFC Editor function is provided by the IETF 863 Administrative Support Activity (IASA).