Internet Draft C.Aoun Category Informational Nortel Networks Expires on March 28 2003 October 28 2002 NSIS Network Address Translator implications < draft-aoun-nsis-nat-imps-00.txt> Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. 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. Abstract This Internet draft discusses Network Address Translators impacts on in path directed signaling. The purpose of this memo is to provide inputs to the NSIS WG on Middlebox specific considerations. Table of Contents Status of this Memo................................................1 Abstract...........................................................1 1 Overview.........................................................2 2 Conventions used in this document................................2 3 Used terminology.................................................2 4 In path signaling NAT complications..............................3 5 Proposed solution................................................3 6 Peer to peer application applicability...........................4 Aoun Informational Expires April 2003 1 NSIS NAT implications October 2002 7 Security Considerations..........................................4 8 Summary..........................................................5 9 References.......................................................5 10 Acknowledgments.................................................5 11 Author's Addresses..............................................5 12 Full Copyright Statement........................................5 1 Overview In path directed signaling is used in the Internet to allocate resources from network nodes. The allocated resources could be bandwidth, packet filter pinhole, network address translator binds and other resource types. When an NSIS Initiator (NI) ([NSISFW]) sends an in path signaling message to the NSIS Responder (NR) ([NSISFW]), it needs to know the address of the NR. When a NAT is not in the path between the NI and NR there is no issue for the NI to guess the NR address, however when one of the NSIS NF co-hosts a NAT function it is a complicated problem. This Internet draft will address the above-mentioned matter by providing dynamic means of discovering the "contact information" of NR behind NATs. 2 Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119. 3 Used terminology All the used NSIS terminology is consistent with [NSISFW] NF: NSIS Forwarder NI: NSIS Initiator NR: NSIS Responder CASP: Common Application Signaling Protocol ALSP: Application Layer Signaling Protocol Aoun Informational Expires April 2003 2 NSIS NAT implications October 2002 4 In path signaling NAT complications We shall discuss the in path signaling NAT complications by looking at a simple network deployment. The NI and NR are co-hosting an application client. +-----------------------+ +------------+ +---------------------+ + NI/AC1 ---------MB1/NF+----+The Internet+--+ MB2/NF-------NI/AC2 + + + +------------+ + a.b.c.d + +-----------------------+ +---------------------+ Network x Network y Application Server 1 Figure 1 In the used example Application Client 1 (AC1) and AC2 use Application server 1 (AS 1) as their server for registration and location purposes as well as to proxy their application messages. MB1 and MB2 are Middle boxes, as defined in [MDCMFW], that apply NAT functions and behave as an NSIS Forwarder as specified in [NSISFW]. When AC1 wants to establish an application session with AC2, it will need to request from the Middleboxes on the data path an address and port bind. In order to do so it needs to know to which address and transport port it needs to send the in path signalling message. The Middleboxes on the path prevents that, unless having an existing static bind already configured on the Middlebox and known by all NIs that would communicate with the specified NR. This would introduce a lot of operational complexity and would not scale. 5 Proposed solution As shown in figure 1, several applications require an application server for registration purposes or for continuous message proxying purposes. We could use this application's specificities to solve the above problem. When AC1 registers with AS1, AS1 would have a softstate giving the status of AC1's reachability, which includes the last source address and source port that brought the application Protocol Data Unit (PDU). The same applies to AC2. When AC1 wishes to establish an application session with AC2, AS1 would provide AC2's "contact information". This contact information Aoun Informational Expires April 2003 3 NSIS NAT implications October 2002 will be the address and source port on which AC2 could receive application signalling. As AC2 is deployed behind MB2, a bind already exists in MB2's NAT mapping table. Sample from MB2 NAT mapping table: Protocol int address int port ext address ext port UDP a.b.c.d w e.f.g.h x AC2 "contact information" consists of e.f.g.h and port x. When AC1 receives AC2's contact information it will request the NI API to send an in path signalling message to e.f.g.h as well as to provide AC2's contact information within the message's SDU. When an NSIS NF receives the in path signalling message it will look at the "contact information" and then look at its NAT mapping table. Based on the mapping it will find out that the destination of the signalling message is a.b.c.d. The NF will then forward the message to a.b.c.d which is the real recipient of the NSIS message. 5.1 Proposed method's implications on the NSIS framework The integration of the proposed solution within NSIS would only impact the Middlebox specific CASP client [CASP] or ALSP [2level]. Only NFs supporting the Middlebox specific client will need to apply the operation depicted above. 6 Peer to peer application applicability The proposed method is also applicable to peer to peer applications. When an application client is peering with another one, it could provide to its NSIS NI API the address and port from which it has received the application signaling from the remote peer. This information will be formatted as the "contact information" and sent within the CASP Middlebox specific client or the Middlebox specific ALSP. 7 Security Considerations As the "contact information" is provided by the application protocol, proper authentication mechanisms MUST be put in place to avoid having false "contact information" that would generate man in the Middle attacks. The NSIS security mechanisms will not be required any modifications. Aoun Informational Expires April 2003 4 NSIS NAT implications October 2002 8 Summary This draft proposes a realistic solution that will allow NSIS NR to be deployed behind NSIS NF co-hosting NAT functions. This draft doesn't discuss all the specificities of the Middlebox ALSP [2level], other implications should be considered. These implications are discussed in [TIST] and [Mshore], such as content manipulation related to the address and port bind when several NATs are on the path (the outer far NAT bind will need to be carried not all of them). 9 References [NSISFW] Ilya Freytsis et all, Next Steps in Signaling: Framework, draft-ietf-nsis-fw-00.txt, work in progress [2level] R. Braden and B. Lindell, A Two-Level Architecture for Internet Signaling, draft-braden-2level-signaling-00.txt, November 2001 [CASP] H. Schulzrinne et all, CASP - Cross-Application Signaling Protocol, draft-schulzrinne-nsis-casp-00.txt, work in progress [Mshore] M. Shore, Towards a Network-friendlier Midcom, draft- shore-friendly-midcom-01.txt, work in progress [TIST] M. Shore, The TIST (Topology-Insensitive Service Traversal) Protocol, draft-shore-tist-prot-00.txt, work in progress [MDCMFW] P.Srisuresh et all, Middlebox communication architecture and framework, RFC 3303,August 2002 10 Acknowledgments The authors would like to thank Louis-Nicolas Hamer for his comments related to this draft. 11 Author's Addresses Cedric Aoun Nortel Networks France Email: cedric.aoun@nortelnetworks.com 12 Full Copyright Statement Aoun Informational Expires April 2003 5 NSIS NAT implications October 2002 Copyright (C) The Internet Society (2000). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS 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." Aoun Informational Expires April 2003 6