Internet DRAFT - draft-aoun-mgcp-nat-package

draft-aoun-mgcp-nat-package





   Internet Draft                                                C.Aoun 
   Category Informational                                     M. Wakley 
                                                           T.Sassenberg 
                                                        Nortel Networks 
   Expires on July 28 2003                             February 28 2003 
 
    
                        A NAT package for MGCP NAT traversal 
                         
                   < draft-aoun-mgcp-nat-package-02.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 
    
   Network Address translators impact several application protocols in 
   the internet; this document discusses how the MGCP protocol could 
   work through NATs. Only the signaling protocol message traversal is 
   discussed in this version of the document. The VoIP streams NAT 
   traversal are already documented and researched within the MIDCOM 
   WG. 
 
 
Table of Contents 
    
   Status of this Memo................................................1 
   Abstract...........................................................1 
   1  Overview.......................................................2 
   2  Conventions used in this document..............................2 
   3  MGCP NAT complications.........................................2 
     
   Aoun, Wakley, Sassenberg  Informational - Expires August 2003     1 
                 A NAT package for MGCP NAT traversal    February 2003
                                    
    
   4  NAT package description........................................4 
   5  NAT traversal fragmentation considerations.....................6 
   6  Applicability statement........................................7 
   7  IANA consideration.............................................7 
   8  Security Considerations........................................7 
   9  Changes since draft-aoun-mgcp-nat-package-00.txt...............7 
   10 References.....................................................7 
   11 Acknowledgments................................................8 
   12 Author's Addresses.............................................8 
   13 Intellectual Property Statement................................8 
   14 Full Copyright Statement.......................................8 
    
1  Overview 
    
   Network Address translators ([NAT]) impact several application 
   protocols in the Internet. [NAT-COMP] provides a good reference on 
   the impact of NATs on certain protocols. This document defines how 
   the MGCP [MGCP] protocol could work in networks where NATs are 
   deployed, whether a single one of them or several in a chain. 
   Typical examples of NAT deployments include (but are not restricted 
   to): 
   -Deployment of a NAT in the customer premise network 
   -Deployment of a NAT in the ISP 
   -Deployment of NATs in both the customer premise network and the ISP 
   (i.e. there is a chain of NATs that is traversed). 
   Only the signaling protocol interface is discussed in this version 
   of the draft (i.e. the MGCP message traversal through NATs). The 
   MGCP controlled, VoIP streamsĘ NAT traversal is already documented 
   and researched within the MIDCOM IETF WG [MDCMFW]. The next version 
   of the draft will provide an overview of the VoIP media traversal 
   solutions discussed in the MIDCOM WG [MDCMFW]. 
    
    
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  MGCP NAT complications 
    
   When Media Gateways (MGW) controlled with the MGCP protocol are 
   deployed behind NATs, the Media Gateway Controller (MGC) should be 
   allowed to control the MGW transparently (or almost transparently). 
    
   When the MGW establishes MGCP communication with its MGC, the NAT  
   creates a bind which includes the private IP address and port of the 
   MGCP client on the MGW and the public IP address and port allocated 
   by the NAT (case a). In some NAT implementations the binding could 
   also include the IP address of the MGC (case b) or both the IP 
   address and port of the MGC (case c). 
     
   Aoun, Wakley, Sassenberg Informational - Expires August 2003      2 
                 A NAT package for MGCP NAT traversal    February 2003
                                    
    
    
   NATs behaving as in : 
        -case a) are known as full cone NATs 
        -case b) are known as restricted cone NATs 
        -case c) are known as restricted port cone NATs 
    
   These NATs belong to the traditional NAT family [TNAT] and are 
   documented in [STUN]. The created NAT bind will have an associated 
   watch dog inactivity timer. In the event that no packets are sent 
   from the MGW to the MGC through the bind over the established 
   duration, the bind will be removed by the NAT. 
    
   When the bind  is removed by the NAT, the MGC will no longer be able 
   to contact the MGW. 
    
    
3.1 Proposed keep alive mechanism 
 
   There are 2 possible ways to reuse existing MGCP messages as keep 
   alives: 
    
   a) Use the audit message (AUEP, AUdit EndPoint) sent by the MGC to 
      which the MGW will reply, thus the response to the AUEP will 
      serve as the keep alive. 
    
  b) Use an event notification message, where the event is persistent. 
     The event in this case being that the MGW watch dog inactivity 
     timer has timed-out. 
    
   Method a) meets the requirement by sending a response to the audit 
   request but requires the MGC host to have an inactivity timer (which 
   is already required but with a bigger auditing period) as well as 
   processing the audit message, and processing the audit response 
   message. Moreover, this method doesnĘt allow the MGC to reach its 
   controlled MGW after fail-over. 
    
   Method b) requires the MGW to notify the MGC each time the 
   inactivity watch dog timer times out. This method allows the MGC to 
   communicate with the MGW when the MGC recovers from a failure and 
   keeps the bind active by generating a message from the MGW to the 
   MGC. 
    
3.2 Method of operation of the proposed keep alive mechanism 
    
   This draft provides a solution to the NAT expiration problem by 
   defining a timer and a persistent package/event.  
    
   The MGW must define a "keep alive" timer. The duration of the "keep 
   alive" timer is determined by the NAT bind's watch dog inactivity 
   timer. The MGW must enable the "keep alive" timer after successful 
   registration (i.e. when an RSIP message has been acknowledged by the 
   MGC). The MGW must reset the "keep alive" timer each time the MGW 
     
   Aoun, Wakley, Sassenberg Informational - Expires August 2003      3 
                 A NAT package for MGCP NAT traversal    February 2003
                                    
    
   sends an MGCP message. The MGW must disable the "keep alive" timer 
   if it becomes Disconnected. 
    
   Expiry of the "keep alive" timer must cause the MGW to generate a 
   MGCP Notification of the persistent event defined below.  
    
 
 
    
   If the MGW doesnĘt receive a response to the Notify message after 
   several retransmissions, the standard MGCP algorithm applies (i.e. 
   transition into the disconnected state). 
   When retransmitting the Notify message (due to lack of 
   acknowledgment) the retransmission timer should not be exponentially 
   backed off but instead the retransmission timer should reuse the 
   inactivity watch dog timer (else the NAT bind could expire as the 
   exponentially backed off retransmission timer could be bigger than 
   the NAT bind timer).  
    
   The keep alive expiry persistent event abides by the persistent 
   event rules as defined in [MGCP].  
     
    
    
    
4  NAT package description 
    
   Package Name : NAT Package 
   PackageID    : NAT 
   Version      : 1 
    
   This package is a new MGCP package. In its first version, only one 
   event is defined (keep alive). 
    
   Events MUST always be prefixed with the "NAT" package name. 
    
   4.1 Properties 
    
      None 
    
   4.2 Events 
    
      Keep Alive 
    
      EventID    : NAT/ka 
      Event Type : Persistent 
       
      This event must be reported by the MGW when its keep alive timer 
      expires.  The timer is reset each time the MGW sends any MGCP 
      message (including MGW responses to commands from the call agent, 
      such as "200 xxx OK" acknowledgements).  
       
     
   Aoun, Wakley, Sassenberg Informational - Expires August 2003      4 
                 A NAT package for MGCP NAT traversal    February 2003
                                    
    
      On timer expiry, the event must be reported from a virtual 
      endpoint on the gateway named 'nat-timeout'. 
       
       
 
       
  4.3 Signals 
   
      None 
   
  4.4 Statistics 
   
      None 
   
  4.5 Procedures 
   
      The keep alive timeout is a gateway specific event, rather than a 
      call processing event that could occur on a normal endpoint. 
      Therefore, since the "all of" wildcard convention cannot be used 
      with the MGCP Notify (NTFY) message, a virtual endpoint is used 
      to report the event.   
       
      The virtual endpoint, named 'nat-timeout', does not need to be 
      under the supervision of a NotificationRequest in order to report 
      the event.  As per the persistent event definition, a RequestID 
      of 0 must be used to report the event if the endpoint is not 
      under the supervision of a NotificationRequest. 
       
       
      Note that the sending of the keep alive event itself constitutes 
      an outgoing MGCP message and hence the keep alive timer must be 
      reset when this NTFY is sent. 
       
      If no response is received from the MGC, the normal 
      retransmission algorithm for the message should be applied 
      (bearing in mind that each of the retransmissions will also reset 
      the keep alive timer).  
       
      If the MGC replies to the MGWĘs notify message (notifying the 
      inactivity timer expiration) with a negative acknowledgment (i.e. 
      error code 522, unknown event), the negative acknowledgment 
      should be ignored and the keep alive operations continue as 
      defined above. 
       
      Gateways that implement this package MUST provide control of 
      operation through a provisioning system.  This should include the 
      ability to enable or disable the keep alive timer completely, and 
      allow configuration of the timer duration in seconds.   
   
  4.6 Use Cases: Example Message Flow 
   
      The keep alive timer must be reset each time the MGW sends any 
      MGCP message. For example: 
     
   Aoun, Wakley, Sassenberg Informational - Expires August 2003      5 
                 A NAT package for MGCP NAT traversal    February 2003
                                    
    
   
         200 123 OK   (keep alive timer reset) 
       
      If the timer expires (no MGCP message is sent by the MGW for the 
      duration of the keep alive timer), the MGW reports the keep alive 
      event: 
       
      ------> 
         NTFY 456 nat-timeout@mgw.nortel.com MGCP 1.0 
         X: 0 
         O: NAT/ka 
       
      The call agent acknowledges: 
       
      <------ 
         200 456 OK 
          
    
5  NAT traversal fragmentation considerations 
    
   NATs have known issues with fragmentation ([NAT-COMP]): 
    
   -In case the fragments get to the NAT, the NAT may not be able to 
   correlate the received fragment with an existing bind; only the 
   initial fragment including the transport headers will be forwarded 
   and the rest of fragments will be dropped. 
         
             -Certain NATs (not all low end NATs support this behavior) 
             install a state, containing the IP packet ID and the 
             source address and destination pair of the packet, when 
             the packet has the more-fragments bit enabled (i.e. packet 
             has been fragmented). This is used to correlate fragments 
             received with the same specified packet ID and same source 
             and destination address pair. Even with that there might 
             be some issues in case the initial fragment doesnĘt arrive 
             in sequence and all other fragments that arrived first 
             will be dropped. 
              
    
   -When 2 clients (in our case MGWs) behind the same NAT are trying to 
   reach the same remote end (i.e. the MGC in this case), they might 
   use the same packet ID. If this happens when fragments reach the 
   MGC, the MGC could get confused during reassembly of the packets as 
   there are no ways to identify to which remote end does the fragment 
   belong. 
    
   3 ways to engineer your network to avoid NAT fragmentation problems, 
   listed by order of priority: 
    
        -Fragment at the data link layer if applicable (case of PPP) 
         
        -In case the MTU could be extended, extend the MTU to the data 
        link MTU size, after analyzing the related jitter impacts. 
     
   Aoun, Wakley, Sassenberg Informational - Expires August 2003      6 
                 A NAT package for MGCP NAT traversal    February 2003
                                    
    
         
   -Minimize the size of the MGCP datagram, below the MTU, either by 
   using fragmentation at the MGCP level (which is not yet defined) or 
   by avoiding the aggregation of MGCP commands in single transaction 
   messages (this needs to be configured locally when the MGW is known 
   to be behind a NAT). 
         
6  Applicability statement 
    
   The mechanism discussed in this draft, to maintain MGWs behind NATs 
   reachable by their MGC, is applicable ONLY when the MGCP messages 
   are sent and received on the same address and port.  
    
7  IANA consideration 
    
   As the NAT package doesnĘt exist, the MGCP NAT package will follow 
   the IANA MGCP package reservation process as defined in [MGCP]. The 
   authors of the draft will request from IANA a specific MGCP NAT 
   package identifier. 
    
8  Security Considerations 
    
   Security considerations in [MGCP] apply to the introduced keep alive 
   mechanism in this document. 
    
9  Changes since draft-aoun-mgcp-nat-package-01.txt 
    
   Minor editing updates. 
    
    
10 References 
    
        [MGCP] F. Andreasen et all, Media Gateway Control Protocol 
        (MGCP)version 1.0, RFC 3435, January 2003  
    
        [MDCMFW] P.Srisuresh et all, Middlebox communication 
        architecture and framework, RFC 3303, August 2002 
         
         
        [NAT] Holdrege, M. and Srisuresh, P., IP Network Address 
        Translator (NAT) Terminology and Considerations, RFC 2663, 
        August 1999 
         
        [NAT-COMP] Holdrege, M. and Srisuresh, P., Protocol 
        Complications with the IP Network Address Translator, RFC 3027, 
        January 2001 
         
        [STUN] Rosenberg, J.et all, STUN - Simple Traversal of UDP 
        Through NATs, draft-ietf-midcom-stun-05.txt, work in progress 
         
        [TNAT] Srisuresh, P and Egevang, K., Traditional IP Network 
        Address Translator, RFC 3022, January 2001 
         
     
   Aoun, Wakley, Sassenberg Informational - Expires August 2003      7 
                 A NAT package for MGCP NAT traversal    February 2003
                                    
    
    
    
11 Acknowledgments 
    
   The authors would like to thank Flemming Andreasen, Kevin Boyle, 
   Bill Foster, Louis Levay, Tony Macdonald, Julian Mitchell, Craig 
   Telke, Richard Willis and Dan Wing for their useful comments and 
   suggestions related to this draft. 
    
12 Author's Addresses 
    
   Cedric Aoun 
   Nortel Networks 
   France 
   Email:  cedric.aoun@nortelnetworks.com 
    
   Martin Wakley 
  Nortel Networks 
  Email:  mwakley@nortelnetworks.com 
    
   Tania Sassenberg 
   Nortel Networks 
   Email:  tanisas@nortelnetworks.com 
    
    
13 Intellectual Property Statement 
   The IETF takes no position regarding the validity or scope of any 
   intellectual property 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; neither does it represent that it 
   has made any effort to identify any such rights.  Information on the 
   IETF's procedures with respect to rights in standards-track and 
   standards-related documentation can be found in RFC 2026.  Copies of 
   claims of rights made available for publication 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 implementors or users of this specification 
   can be obtained from the IETF Secretariat. 
       
   The IETF invites any interested party to bring to its attention any 
   copyrights, patents or patent applications, or other proprietary 
   rights which may cover technology that may be required to practice 
   this standard.  Please address the information to the IETF Executive 
   Director. 
    
14 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 
     
   Aoun, Wakley, Sassenberg Informational - Expires August 2003      8 
                 A NAT package for MGCP NAT traversal    February 2003
                                    
    
   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, Wakley, Sassenberg Informational - Expires August 2003      9