NSIS Working Group M. Stiemerling Internet-Draft NEC Expires: April 18, 2005 October 18, 2004 Loose End Message Routing Method for NATFW NSLP draft-stiemerling-nsis-natfw-mrm-00 Status of this Memo 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 become aware will be disclosed, in accordance with RFC 3668. 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 April 18, 2005. Copyright Notice Copyright (C) The Internet Society (2004). 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 located Network Address Translators on the upstream data path. This message routing method is used by NSIS nodes behind a NAT to allocate a public reachable IP address and/or port number. The current way to do so has been name as "signaling the wrong way" and should be replaced by the proposed message routing method. The scope of this memo is currently limited to Network Address Translator usage only. Stiemerling Expires April 18, 2005 [Page 1] Internet-Draft NSIS NATFW NSLP MRM October 2004 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Signaling the Wrong Way . . . . . . . . . . . . . . . . . . . 4 3. Loose End Message Routing Method . . . . . . . . . . . . . . . 6 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Security Considerations . . . . . . . . . . . . . . . . . . . 8 6. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 Normative References . . . . . . . . . . . . . . . . . . . . 10 7.2 Informative References . . . . . . . . . . . . . . . . . . . 10 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 10 A. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 Intellectual Property and Copyright Statements . . . . . . . . 12 Stiemerling Expires April 18, 2005 [Page 2] Internet-Draft NSIS NATFW NSLP MRM October 2004 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 (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 to the data sender where to send its data. Note that there may be several NATs connecting this private network to the public network. 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 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 an IP address. 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. The remaining document describes the current proposed way of finding the external NAT as described in [4] in Section 2 and the new proposed way of locating the NAT in Section 3. The terminology used throughout this memo is aligned to the NSIS terminology. Stiemerling Expires April 18, 2005 [Page 3] Internet-Draft NSIS NATFW NSLP MRM October 2004 2. Signaling the Wrong Way In [4] Section 5.4.2 the wrong way signaling approach is mentioned. This way of signaling fakes a data sender's address and uses the standard downstream message routing method (MRM) defined in [3]. edge NAT +------+ |NATFW | +----+ .'+NSLP `. ' NS*+ / |w/ NAT| \ ,-----. +----+ +------+ .' +------+ `./ . +----+ |NATFW | / / \ | NR |----+NSLP |+ ( Internet ) +----+ |w/ NAT| \ \ / +------+ `. +------+ .' `. \ |NATFW | .' `-----' `. +----+ `.+NSLP .' `.| NS + |w/ NAT| +----+ +------+ edge NAT Figure 1: NATFW NSLP elements The NTLP message routing information is set NSLP receiver (NR) to source-address, faked NSLP sender (NS*) to destination-address. Where, NR is the NSLP receiver for the later happening CREATE request message exchange and NS* is an arbitrary public IP address. Further information like port numbers might be set, too. The NSLP uses the RESERVE-EXTERNAL-ADDRESS (REA) request message. The signaling message is sent downstream to NS*, intercepted and processed by NATFW NSLP nodes implementing Network Address Translation (NAT). NATFW NSLP nodes implementing Firewall functionality only, just 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 the 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 Stiemerling Expires April 18, 2005 [Page 4] Internet-Draft NSIS NATFW NSLP MRM October 2004 the NR to indicate its reachable address. To make data transmission work, a real NSIS sender (NS) must now send a CREATE request message to the allocated IP address 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 NS to NR and installing NSIS state and Firewall/NAT rules in he NATFW NSLP nodes. Please note that the NSIS sender of this CREATE message is not necessary the same as used by the REA message noted as NS*. This method of finding a NAT on the data path installs several states on NTLP and NSLP level. First of all, a state on the NTLP level is installed from NR until the edge-NAT with final destination of NS* at each NATFW NSLP node. This state must be maintained with repeating REA 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 never used by any incoming CREATE request message and is to a certain degree misleading, since the later source NS* is not the real NSIS sender. 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 and minimizing state and giving a clean way of finding NATs even without knowing the NSIS sender NS. Stiemerling Expires April 18, 2005 [Page 5] Internet-Draft NSIS NATFW NSLP MRM October 2004 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 to get a public reachable IP address/port number without knowing where the data traffic is coming from, meaning that NSIS sender (NS) is unknown. Therefore, signaling messages must be sent to a faked address NS*, resulting in a loose end with respect to the signaling since this not the actual fixed sender's address. This faked address of the NSIS sender NS* is called signaling destination address (SDA). The loose end message routing method (LEMRM) requires that the NTLP is routing messages upstream from NR to NS* and requires that NATFW NSLP nodes implementing NAT are processing these messages only. All other NTLP nodes just forward the message and NATFW NSLP nodes implementing Firewall functionality do not process this message at all. The processing at NATs and edge NATs regarding NAT configuration is unchanged. NTLP and NSLP state is only 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) 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 sender's address, but the SDA and that LEMRM is to be used. 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. The C-MODE connection are being established between NR and the NATFW NSLPs implementing NAT functionality only. A real NSIS sender (NS) 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 NS to NR. Section 8.9 of [3] describes how new MRMs must be defined. The exact format, filtering/security, and NAT processing of MRI format are to be done in future versions of this document. Stiemerling Expires April 18, 2005 [Page 6] Internet-Draft NSIS NATFW NSLP MRM October 2004 4. 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. The current text contained within this document is a first cut and needs further refinement. Stiemerling Expires April 18, 2005 [Page 7] Internet-Draft NSIS NATFW NSLP MRM October 2004 5. Security Considerations Security considerations are to be done. Stiemerling Expires April 18, 2005 [Page 8] Internet-Draft NSIS NATFW NSLP MRM October 2004 6. Open Issues o Asymmetric routing and why it is not a problem with NATs o Spotting the NAT with SDA equal to real NS o Using LEMRM for locating Firewalls Stiemerling Expires April 18, 2005 [Page 9] Internet-Draft NSIS NATFW NSLP MRM October 2004 7. References 7.1 Normative References [1] Hancock et al, R., "Next Steps in Signaling: Framework", DRAFT draft-ietf-nsis-fw-05.txt, October 2003. [2] Brunner et al., M., "Requirements for Signaling Protocols", DRAFT draft-ietf-nsis-req-09.txt, October 2003. [3] Schulzrinne, H. and R. Hancock, "GIMPS: General Internet Messaging Protocol for Signaling", DRAFT draft-ietf-nsis-ntlp-02.txt, October 2003. [4] Stiemerling, M., Tschofenig, H., Martin, M. and C. Aoun, "NAT/Firewall NSIS Signaling Layer Protocol (NSLP)", DRAFT draft-ietf-nsis-nslp-natfw-03.txt, July 2004. 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 E. 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] Carpenter, B. and S. Brim, "Middleboxes: Taxonomy and Issues", RFC 3234, February 2002. [9] Rekhter et al, Y., "Address Allocation for Private Internets", 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 April 18, 2005 [Page 10] Internet-Draft NSIS NATFW NSLP MRM October 2004 Appendix A. Acknowledgments The author would like to thank Robert Hancock, Hannes Tschofenig, and Cedric Aoun for the discussions. Stiemerling Expires April 18, 2005 [Page 11] Internet-Draft NSIS NATFW NSLP MRM October 2004 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 (2004). 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 April 18, 2005 [Page 12]