Internet Draft C.Aoun Category Informational Nortel Networks Expires on September 2003 March 1st 2003 NSIS Network Address Translator implications < draft-aoun-nsis-nat-imps-01.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.........................7 Aoun Informational Expires April 2003 1 NSIS NAT implications March 2003 7 NSIS NAT and Firewall transitions issues.......................7 8 Security Considerations........................................9 9 Summary.......................................................10 10 References....................................................10 11 Acknowledgments...............................................10 12 AuthorÆs Addresses............................................10 13 Full Copyright Statement......................................11 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. In addition the document covers generic NAT implications on NSIS for both NSIS aware NATs and non NSIS aware NATs and their coexistence. 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 NE: NSIS Element, one of the above 3 components CASP: Common Application Signaling Protocol Aoun Informational Expires September 2003 2 NSIS NAT implications March 2003 ALSP: Application Layer Signaling Protocol 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 September 2003 3 NSIS NAT implications March 2003 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. Figures 2 and 3, shows message sequences of the mode of operation for the proposed method of signalling NEs when NATs are in the path. Figure 2 shows how the æContact InformationÆ is gathered. Figure 3 shows how an NE discovers the next hop NE in the path towards the end destination, more information on next hop NE discovery could be found in [CASP] within the SCOUT related sections. Analysis done in [CASP] and [CASP-NATFW] show that in order to secure NSIS signalling, the discovery of the next hop peer NE needs to be separate from installing policy rules on the NSIS aware NATs and firewalls. Once the next hop peer NE is discovered, a security association is established with it as specified in [CASP] and then policy rule installation will proceed as discussed in [CASP-NATFW]. Aoun Informational Expires September 2003 4 NSIS NAT implications March 2003 NE1/AC1 NF1 AS1 NF2 NE2/AC2 a.b.c.d User apps message <-------- NAT bind creation User apps message <------------- User apps message Came from e.f.g.h:x, it Is linked to AC2, AC2 æContact InformationÆ = e.f.g.h:x UDP . .Same done with AC1 . . Figure 2 Initiate user app With AC2 -----------------> Initiate user app With AC2 -----------------> NE1/AC1 NF1 AS1 NF2 NE2/AC2 a.b.c.d AC2 æContact InformationÆ e.f.g.h:x UDP < --------------- AC2 æContact InformationÆ e.f.g.h:x UDP < --------------- NSIS Nxt hop discovery msg AC2 æContact InformationÆ e.f.g.h:x UDP -------------------- > NF1 will keep a state Related to the msg originator NSIS Nxt hop discovery msg AC2 æContact InformationÆ e.f.g.h:x UDP --------------------------------> æContact InformationÆ maps to a.b.c.d host. Aoun Informational Expires September 2003 5 NSIS NAT implications March 2003 NE1/AC1 NF1 AS1 NF2 NE2/AC2 a.b.c.d Need to transfer message to a.b.c.dNF2 keeps an associated state to the received message including from where message came from (NF1) NSIS Nxt hop discovery msg AC2 æContact InformationÆ a.b.c.d:w UDP ------------> RESPONSE < ---------- RESPONSE < --------------- RESPONSE <--------------- RESPONSE < --------------- Figure 3 RESPONSE message in figure 3, provides information on the next hop NE, this may include the NE capabilities. 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. 5.2 Multi-homing considerations In case there are several NATs a the edge of local network, it is quite possible that the discovery phase of the æContact InformationÆ was based on traversal of a specific NAT that is not the one in the natural path of the remote application end point. Hence NSIS signaling could traverse a different NAT than the one traversed by the data flows exchange between the user application clients. Aoun Informational Expires September 2003 6 NSIS NAT implications March 2003 To solve the multi-homing problem, proper anchoring mechanisms should be used to ensure that the data flows will be traversing the same NFs as the one traversed by the signaling. Current known packet anchoring mechanisms: a) Twice NAT, as defined in [NAT], translates both the source and destination addresses (and transport ports) b) Source routing Option a) is quite controversial as the Internet architecture evolution is going towards of getting rid of NATs. Option b) is also controversial as source routing is not much supported in the Internet today, but it could be less controversial as the source routing is required within the local network. In case a) is used, it implied that the NSIS-NATFW client supports the concept of a local destination address/port pair. When the NSIS-NAT/FW client provides an address/port pair to the application client it will need to also provide a local destination address/port pair. That local destination address/port pair will be a recipient on a specific NSIS aware NAT. That NAT will obviously be the same one as the one traversed by the NSIS signaling and the used message to discover the æContact InformationÆ. In case b) is used, the NSIS-NATFW will need to have the capability to specify the next hop in a source route specific object. This next hop will be specified within a source route option for data packets being transmitted between the 2 user application clients. 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 NSIS NAT and Firewall transitions issues As there is no D day where all deployed NATs and Firewalls will support NSIS, proper analysis should be done to understand how we could minimize the co-existence issues between NSIS-NATFW clients and existing none NSIS aware NATs and firewalls. Aoun Informational Expires September 2003 7 NSIS NAT implications March 2003 7.1 Traversed Firewall is not NSIS aware In case a NSIS unaware firewall is traversed by NSIS messages, NSIS messages should be allowed to go through it, as well as the data flows exchanged between the user application clients. This is not necessarily an obvious task to perform in case the NSIS messages canÆt be identified by the NSIS unaware firewall. Same applies for the user application data flows. 7.1.1 NSIS message identification NSIS message identification should be supported by existing firewall. Currently firewalls support flow identification by using the 5 tuple or a sub-set of it. We canÆt assume that the firewall will support router alert option ([Ralert]) and even if it did support it, it may mean something else. 7.1.2 User application Data flow identification User application data flow identification, should be deterministic at some level. Normally this means that the application clients uses a combination of an address and specific transport port range. This combination should be configured on the firewall. NE1/AC1 NSIS-unaware FW NSIS-NATFW FW NE2/AC2 a.b.c.d Figure 5 7.1.3 NSIS-NATFW aware NF is deployed in the path In case a NAT is deployed on the path and it is NSIS-NATFW client aware ([CASP-NATFW]), then assigned bind should be consistent with policy rules configured with the NSIS unaware firewall. NE1/AC1 NSIS-unaware FW NSIS-NATFW NAT NE2/AC2 a.b.c.d Policy rules configured To allow specific filters For NSIS signaling and user Application data flows Figure 6 Aoun Informational Expires September 2003 8 NSIS NAT implications March 2003 7.2 Traversed NAT is not NSIS-NATFW aware NE1/AC1 NSIS unaware NAT NE2/AC2 a.b.c.d Figure 7 In case an NSIS unaware NAT is on the path of packets from AC2 towards AC1, the following could be applicable. NE2 sends an NSIS message towards NE1, we assume that æContact InformationÆ method is used. When the NSIS message reaches the NSIS unaware NAT the NAT doesnÆt translate the filter attribute [CASP- NATFW]. When NE1 receives the NSIS message it will know that there is an NSIS unware NAT in the path, and will provide this information within the response to NE2. All consequent NSIS messages between NE1 and NE2 will now include this information. NE2 will then provide the filter matching the data flows to be exchanged between AC1 and AC2 and send this information within an NSIS message to NE1. That NSIS message will be sent by using the same transport protocol than the data flows to be exchanged between the user application client (AC1 and AC2). When NE1 will receive the NSIS message it will replace the filter attribute with the source address and source transport port information. This implies that the NSIS-NATFW implementation on NE1 and NE2 supports the same transport protocol as the one used for the data exchanges. The generic requirement on NSIS will be that it should be transported on several transport protocols, changing from one transport protocol to the other should be based on specific events as shown above. 8 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 September 2003 9 NSIS NAT implications March 2003 9 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],[CASP-NATFW]), other implications should be considered as the ones discussed in [CASP-NATFW]. In addition the draft provides inputs on transition issues when deploying NSIS-NATFW signaling application with existing NAT and Firewalls in the path. 10 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-01.txt, work in progress [CASP] H. Schulzrinne et all, CASP - Cross-Application Signaling Protocol, draft-schulzrinne-nsis-casp-01.txt, work in progress [CASP-NATFW] H. Tschofenig et all, A Firewall/NAT Traversal Client for CASP, draft-tschofenig-nsis-casp-midcom-01.txt, work in progress [MDCMFW] P.Srisuresh et all, Middlebox communication architecture and framework, RFC 3303,August 2002 [NAT] P. Srisuresh, ôIP Network Address Translator (NAT) Terminology and Considerationsö, RFC 2663, Internet Engineering Task Force, Aug. 1999 [Ralert] D. Katz, ôIP Router Alert optionö, RFC 2113, IETF, February 1997 11 Acknowledgments The authors would like to thank Louis-Nicolas Hamer for his comments related to this draft. 12 AuthorÆs Addresses Cedric Aoun Nortel Networks Aoun Informational Expires September 2003 10 NSIS NAT implications March 2003 France Email: cedric.aoun@nortelnetworks.com 13 Full Copyright Statement 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 September 2003 11