NSIS Working Group M. Stiemerling Internet-Draft NEC Expires: January 18, 2006 July 17, 2005 Loose End Message Routing Method for NATFW NSLP draft-stiemerling-nsis-natfw-mrm-02 Status of this Memo 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. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on January 18, 2006. Copyright Notice Copyright (C) The Internet Society (2005). Abstract This memo describes the use cases and solution for a new NTLP message routing method (MRM) that is used by the NATFW NSLP protocol to locate Network Address Translators (NAT) on the upstream data path. This message routing method is used by NSIS NATFW nodes behind a NAT to allocate a public reachable IP address and/or port number. The current way to do so has been named as "signaling the wrong way" and should be replaced by the proposed message routing method. The scope of this memo is limited to the usage of locating upstream Network Address Translator. Stiemerling Expires January 18, 2006 [Page 1] Internet-Draft NSIS NATFW NSLP MRM July 2005 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Signaling the Wrong Way . . . . . . . . . . . . . . . . . . . 5 3. Loose End Message Routing Method . . . . . . . . . . . . . . . 8 4. GIMPS Message Routing Method . . . . . . . . . . . . . . . . . 11 4.1 Signaling Destination Address . . . . . . . . . . . . . . 11 5. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.1 Normative References . . . . . . . . . . . . . . . . . . . 14 7.2 Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 14 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15 Intellectual Property and Copyright Statements . . . . . . . . 16 Stiemerling Expires January 18, 2006 [Page 2] Internet-Draft NSIS NATFW NSLP MRM July 2005 1. Introduction The NATFW NSIS Signaling Layer Protocol (NATFW NSLP) [4] describes a path-coupled protocol to configure Network Address Translators (NATs) and firewalls to let subsequent data traffic traverse these devices. The NSIS Transport Layer Protocol (NTLP) [3] is used to route those NATFW NSLP signaling messages on the data path. Typically, the NATFW NSLP signaling messages are initially sent downstream, meaning from data sender to data receiver, and responses are sent upstream, from receiver to sender. In this case, the data sender, and the NATFW NSLP, know the final receiver of the data flow. Commonly, this scenario is referred to sender behind NAT or firewall (see Section 2.3 of [4]). Another scenario, described in Section 2.4 of [4], describes a data receiver behind a NAT. Data receivers located in a network that is separated by a NAT from the public network are not directly addressable by means of IP addresses. These data receivers are using private IP addresses, only meaningful in their private network. To receive data from outside this private network, data receivers must first obtain a globally routable IP address (public IP address). This public IP address is located at the NAT of the network and is usually used in application level signaling exchanges to inform the data sender where to send its data. Note that there may be several NATs connecting this private network to the public network, NATs can be placed in parallel or NATs can be placed in sequence. Figure 1 shows such a network configuration. The local network can consist of several other Firewalls or NATs located on the data path and NSIS signaling path. //------\\ +------+ /----------\ DR ---| Local |----| edge |----| Internet |---- DS | Network| | NAT | \----------/ \\------// +------+ private public DS: Data sender DR: Data receiver Figure 1: Data Receiver behind NAT When a data receiver knows the data sender's IP address (at least), it will send its NSIS NATFW NSLP signaling message upstream towards this address. The NTLP must forward this signaling message upstream and the NATFW NSLP will stop the forwarding process a the outermost NAT, the so-called edge-NAT. The NATFW NSLP message type to be used Stiemerling Expires January 18, 2006 [Page 3] Internet-Draft NSIS NATFW NSLP MRM July 2005 for this upstream signaling is RESERVE-EXTERNAL-ADDRESS (REA). The above described assumes that the data receiver knows the IP address of the data sender in advance. However, in many applications the IP address of the data sender is not known in advance, such as SIP. In this case the NATFW NSLP signaling message for REA cannot be sent upstream towards the ultimately IP address of the data sender. Nevertheless, to get a public reachable IP address the data receiver must somehow find the external NAT and allocated an IP address or port number, depending on the NAT type. This document focuses on NATs only and does not consider firewalls. Limiting the scope of this document to NATs only has a simple but compelling reason: Locating upstream firewalls and NATs is not a simple task to be performed by NSIS. Other working groups, such as IETF's ICMP traceback, trying to find the path of data streams upstream, from data receivers to data senders. This seems to be a non-trivial task for the regular Internet with a single IP address space. This applies to networks with firewall deployments too. Networks using a private IP address space are easier to handle in this case: NSIS just needs to find an edge-NAT that is the border between the public Internet and the private network. The IP address and port number allocated at the edge-NAT by means of NATFW NSLP's REA message is in fact a route pinning and thus all traffic will traverse this single edge-NAT. Section 2 describes the current proposed way of locating the external NAT and requesting an external IP address and port number (as described in in [4]). The new proposed way of locating the NAT is described in Section 3. The terminology used throughout this memo is aligned to the NSIS terminology. Stiemerling Expires January 18, 2006 [Page 4] Internet-Draft NSIS NATFW NSLP MRM July 2005 2. Signaling the Wrong Way The NATFW NSLP protocol specification defines a mechanism to locate upstream NATs; This mechanism is commonly referred to as signaling the wrong way (see Section 5.4.2 in [4].) This way of signaling uses a faked data sender's address and sends the RESERVE-EXTERNAL-ADDRESS (REA) message against the intended direction of the data stream towards the faked address. This REA messages uses the standard downstream message routing method (MRM) defined in NTLP [3]. edge NAT +------+ |NATFW | +----+ .'+NSLP `. ' OA | / |w/ NAT| \ ,-----. +----+ +------+ .' +------+ `./ . NR+ +----+ |NATFW | / / \ | NR |----+NSLP |+ ( Internet ) +----+ |w/ NAT| \ \ / NI+ +------+ `. +------+ .' `. \ |NATFW | .' `-----' `. +----+ `.+NSLP .' `.| NI | |w/ NAT| +----+ +------+ edge NAT Figure 2: NATFW NSLP elements Figure 2 shows a typical network topology for data receivers behind NATs. The figure denotes the data receiver as NSIS NATFW NSLP receiver (NR) and the data sender as NSIS NATFW NSLP initiator (NI). NR+ denotes an arbitrary IP address, named as Opportunistic Address (OA). The naming convention NR/NI refers to the CREATE signaling where the data sender is initiating the signaling. The naming convention printed below the particular boxes (NI+ and NR+) refer to the REA signaling where the data receiver is initiating the NATFW NSLP signaling. The data receiver acting as NI+ sets the NTLP message routing information (MRI) for the REA message as follows o the NTLP signaling destination address is set to the faked data sender's address (Opportunistic Address, NR+), Stiemerling Expires January 18, 2006 [Page 5] Internet-Draft NSIS NATFW NSLP MRM July 2005 o the NTLP signaling source address is set to data receiver's address (NI+), and o the signaling direction is set to downstream. Further information like port numbers, transport protocol, etc might be set in the MRI, too. The NSLP uses the RESERVE-EXTERNAL-ADDRESS (REA) request message. The signaling message is sent downstream to NR+, intercepted and processed by NATFW NSLP nodes implementing Network Address Translation (NAT). NATFW NSLP nodes implementing just firewall functionality, forward the message, unless they are edge-firewalls. Edge-firewalls stop the message forwarding and do reply with an error response 'no NAT here' to indicate that there is no NAT on this path. Each NAT on the path takes the message and processes it. An IP address/port is reserved at the NAT, but not enabled, and the translation is prepared for future use. Reserved and prepared refers to getting all necessary configurations done at the NAT to enable later translations immediately. The message is forwarded until it reaches an edge-NAT. The edge-NAT stops the message forwarding and replies with a response message indicating the reserved external IP address/port number. This IP address and port number can now be used by the application at the NR to indicate its reachable address to other parties. To enable data transmission, a real NSIS initiator (NI) must now send a CREATE request message to the allocated IP address/port number at the edge-NAT. This CREATE request message enables the NATs and firewalls to forward the data packets. The defined rules for processing and forwarding CREATE apply, meaning that these messages are sent from NI to NR and install NSIS state and firewall/NAT rules in the NATFW NSLP nodes. Note that the NSIS initiator of this CREATE message is not necessary the same as used by the REA message noted as NI+. This method of locating upstream NATs on the data path installs several states on NTLP and NSLP level. First of all, state is installed on the NTLP level from NR to the edge-NAT with the final destination address set to NR+ at each NATFW NSLP node. This state must be maintained with REA refresh messages, since it is subject to the regular timeout handling. Second, with the arrival of the CREATE message at NR, the state for REA must be removed since it is no longer used. Instead of this, the state for CREATE must be maintained. The state built during the REA phase is probably never used by any incoming CREATE request message and is to a certain degree misleading, since NI+ is not the real NSIS initiator. Figure 3 shows the state installed for REA and CREATE in a mixed firewall and NAT environment. Stiemerling Expires January 18, 2006 [Page 6] Internet-Draft NSIS NATFW NSLP MRM July 2005 Firewall +------+ |NATFW | +----+ *********|NSLP |******** | OA | * |w/ FW | * ,-----. +----+ * +------+ +--*---+ / \ NR+ +-*--+ |NATFW | / \ | NR ++++ |NSLP | ( Internet ) +----+ + +++w/ NAT+++ \ / NI+ + +------+ + +------+ + \ / + |NATFW | + edge-NAT + `-----' +----+ ++++NSLP ++++ +++++++++++++++++++| NI | |w/ FW | +----+ +------+ Firewall ****: State created by REA ++++: State created by CREATE Figure 3: Installed NATFW NSLP state The figure shows a scenario with routing asymmetry on the path between the edge-NAT and the NR. This highlights that the path taken by REA signaling messages and CREATE signaling messages must not be the same and must be treated independently. Keeping state involves the setup and maintenance of NTLP connection mode (C-MODE, most likely TCP based) between all neighboring NSIS peers running the NATFW NSLP. Figure 3 shows that REA state is kept between NR and the firewall and the edge-NAT but is never used in subsequent signaling for CREATE. The 'signaling the wrong way' approach seems to be more a work around solution instead of a proper one that is well understood. Therefore, the next section proposes a new way of spotting the NAT, minimizing state and giving a clean way of finding NATs even without knowing the data sender. Stiemerling Expires January 18, 2006 [Page 7] Internet-Draft NSIS NATFW NSLP MRM July 2005 3. Loose End Message Routing Method This section proposes a new message routing method (MRM) to find NATs on the network side of data receivers. As described earlier, some applications require the retrieval of a public reachable IP address/ port number without knowing where the data traffic is coming from, meaning that data sender and thus the later NSIS initiator (NI) is unknown, and without being required to have knowledge about the network topology. For the first reason, signaling messages must be sent to a faked address NR+, resulting in a loose end with respect to the signaling since this not the actual fixed sender's address but an imaginary IP address located in the public IP space. This faked address of the NSIS sender NR+ is called signaling destination address (SDA) within this document. The current NATFW NSLP specification uses the term Opportunistic Address, see also Section 2 of this memo. The loose end message routing method (LEMRM) requires that the NTLP routes messages upstream from NI+ to NR+ and that NATFW NSLP nodes implementing NAT are processing these messages only. All other NTLP nodes just forward the messages and NATFW NSLP nodes implementing firewall functionality do not process this messages at all. The processing at NATs and edge-NATs regarding NAT configuration is performed as described in Section 2. NTLP and NSLP state is kept at the NATs that intercepted and processed the REA message. All other messages, such as responses and repeated REAs for state refresh, are exchanged directly between NATFW NSLP nodes involved. Through this, state to be maintained is minimized and only the NR and NATFW NSLP nodes with NAT functionality are forced to keep this NTLP and NSLP state. A NR using the REA request message must set NTLP's MRI to signaling destination address (SDA, NR+) as destination-address and its own address NR as source-address. A new field (yet to be defined) indicates to the NTLP that the destination-address is not the real NSIS initiator's (NI) address, but the SDA and that LEMRM must be used for routing this message. The NTLP routes the REA message upstream to towards the SDA via D-MODE. NATFW NSLPs implementing NAT functionality intercept and process the REA message according [4]. Edge NATs stop the message forwarding. NTLP C-MODE connections are being established between neighboring NATFW NSLP peers that implement NAT functionality. Figure 4 shows the state installed for REA and CREATE in a mixed firewall and NAT environment when using LEMRM. Stiemerling Expires January 18, 2006 [Page 8] Internet-Draft NSIS NATFW NSLP MRM July 2005 Firewall +------+ |NATFW | +-----+ |NSLP | | SDA | |w/ FW | ,-----. +-----+ +------+ +------+ / \ NR+ +----+******************NATFW | / \ | NR ++++ |NSLP | ( Internet ) +----+ + +++w/ NAT+++ \ / NI+ + +------+ + +------+ + \ / + |NATFW | + edge-NAT + `-----' +----+ ++++NSLP ++++ +++++++++++++++++++| NI | |w/ FW | +----+ +------+ Firewall ****: State created by REA ++++: State created by CREATE Figure 4: LEMRM installed NATFW NSLP state This approach raises questions with respect to intermediate NATFW NSLP nodes implementing firewall functionality only. Detecting neighboring NTLP nodes, and NSLP nodes, is done by using NTLP's D-MODE GIMPS-query and GIMPS-response messages. Assuming UDP as transport protocol, with router alert option set, intermediate firewalls need to forward these packets and remember firewall state locally (this is not NATFW state). A NATFW NSLP aware edge-NAT on the data path will intercept this UDP packet and respond back to the particular signaling source. This UDP packet is routed back to the signaling source and uses the regular standard routing. The packet will reach the firewall with stored state with symmetric routes between the edge-NAT and the signaling source and is going to be forwarded further. Asymmetric routing, as shown in Figure 4, will forward the packet to the wrong firewall that most likely drops the packet. The LEMRM as described above makes these assumptions: o Intermediate firewalls allow UDP packets of the NTLP D-MODE exchange to traverse in both directions, from internal to external and vice versa. At least they allow UDP packets being initiated from internal side to external and back by storing state for this UDP packet. o Symmetric routes are in place. Stiemerling Expires January 18, 2006 [Page 9] Internet-Draft NSIS NATFW NSLP MRM July 2005 o TCP connections initiated from the NSIS peer located internally (the upstream peer) are allowed to traverse towards the NSIS peer located externally (the downstream peer). In the above figure NR is able to initiated a TCP connection to the edge-NAT. This assumes TCP for C-MODE. Assuming other transport protocols than TCP and UDP will result in even more complicated problems, since firewalls usually understand TCP and UDP at best. The LEMRM may require intermediate NATFW NSLP peers implementing firewall functionality to store NTLP/NSLP state. A real NSIS initiator (NI) can use the via REA allocated IP address/ port number to send its CREATE request message to. The CREATE message is processed as in [4] and requires a new path discovery from edge NAT towards NR. This path discovery will located all NATFW NSLP nodes (firewalls and NATs) along the data path and enable the data path from NI to NR. Stiemerling Expires January 18, 2006 [Page 10] Internet-Draft NSIS NATFW NSLP MRM July 2005 4. GIMPS Message Routing Method This section describes the message routing method (MRM) definition for GIMPS of the LEMRM. Section 3.3 of [3] outlines the elements need for a MRM definition. The elements of the LEMRM are: o Path-coupled transport is required. o Flow-identifier as defined in Section 5.7.1.1 of [3]. The source- address field must be set to the data sender's address (NI), if known. Otherwise, this field must be wildcarded. The destination-address field must be set to data receiver's address (NR, NI+). All other fields of the flow-identifier are set accordingly to the source or destination properties, for instance, the destination's port number. o Signaling direction is upstream. o A new object containing the signaling destination address (SDA). The signaling destination address must contain a publicly reachable IP address and must not contain a private IP address defined in [8]. o The QUERY encapsulation follows the same rules as defined in Section 5.7.1.2 of [3] with the exception of using the SDA as signaling destination. The destination address must be set to the SDA and the source address must be set to NR's address. 4.1 Signaling Destination Address The signaling destination address (SDA) object contains the IP address of NR+. Type: Signaling-Destination-Address Length: 1 for IPv4 and 4 for IPv6. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // SDA // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5 Stiemerling Expires January 18, 2006 [Page 11] Internet-Draft NSIS NATFW NSLP MRM July 2005 5. Conclusions This memo discusses a new message routing method for the NATFW NSLP. This new MRM is intended to replace the current proposed 'signaling the wrong way' approach. Apparently, LEMRM concerns two layers of the NSIS stack, the NTLP and NATFW NSLP. Message routing is part of the NTLP layer and state setup is part of the NATFW NSLP layer. This separation is not yet fully described in this document. Stiemerling Expires January 18, 2006 [Page 12] Internet-Draft NSIS NATFW NSLP MRM July 2005 6. Security Considerations Security considerations are to be done. Stiemerling Expires January 18, 2006 [Page 13] Internet-Draft NSIS NATFW NSLP MRM July 2005 7. References 7.1 Normative References [1] Klensin, J., "Terminology for Describing Internet Connectivity", BCP 104, RFC 4084, May 2005. [2] Brunner, M., "Requirements for Signaling Protocols", RFC 3726, April 2004. [3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", draft-ietf-nsis-ntlp-06 (work in progress), May 2005. [4] Stiemerling, M., "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-06 (work in progress), May 2005. 7.2 Informative References [5] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. [6] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. [7] Tsirtsis, G. and P. Srisuresh, "Network Address Translation - Protocol Translation (NAT-PT)", RFC 2766, February 2000. [8] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. Author's Address Martin Stiemerling Network Laboratories, NEC Europe Ltd. Kurfuersten-Anlage 36 Heidelberg 69115 Germany Phone: +49 (0) 6221 905 11 13 Email: stiemerling@netlab.nec.de URI: http://www.stiemerling.org Stiemerling Expires January 18, 2006 [Page 14] Internet-Draft NSIS NATFW NSLP MRM July 2005 Appendix A. Acknowledgments The author would like to thank Robert Hancock, Hannes Tschofenig, and Cedric Aoun for discussing the LEMRM. Stiemerling Expires January 18, 2006 [Page 15] Internet-Draft NSIS NATFW NSLP MRM July 2005 Intellectual Property Statement The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Disclaimer of Validity This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Copyright Statement Copyright (C) The Internet Society (2005). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. Acknowledgment Funding for the RFC Editor function is currently provided by the Internet Society. Stiemerling Expires January 18, 2006 [Page 16]