Internet DRAFT - draft-aoun-nsis-nat-imps

draft-aoun-nsis-nat-imps





   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