Internet DRAFT - draft-audet-sipping-add-realm

draft-audet-sipping-add-realm




       
                                          
         SIPPING Working Group                                                 
         Internet Draft                                         Francois Audet 
         Document: draft-audet-sipping-add-realm-00.txt        Nortel Networks 
         Expires on December 2003                                    June 2003 
                                               
                                                    
                        
              Identifying intra-realm calls with explicit addressing realm 
                                  identifier attribute 
                                             
                                           
        
      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 
          
         This internet draft will expire on 20 December 2003. 
       
      Copyright Notice 
             
         Copyright (C) The Internet Society (2003). All Rights Reserved.        
           
      Abstract 
             
         This draft describes the use of an explicit addressing identifier 
         SDP attribute to assist in the process of choosing which addresses 
         shall be used by SIP User Agents (UAs) when multiple IP addresses 
         are known (STUN-derived, local, etc.). This draft complements the 
         Interactive Connectivity Establishment (ICE) draft.  
           
           
       
          
       
       
       
      Audet                   Expires December 2003                [Page 1] 
       

       
                        draft-audet-sipping-add-realm-00.txt      June 2003 
      1  Introduction
        
         This draft describes the use of an explicit addressing identifier 
         SDP attribute to assist in the process of choosing which addresses 
         shall be used by SIP UAs. It applies when multiple IP addresses are 
         known, e.g., STUN-derived IP addresses and local IP addresses. This 
         draft proposes to allow for an explicit realm identification SDP 
         attribute to be used as part of the Interactive Connectivity 
         Establishment (ICE) draft [1] to facilitate deployment in networks 
         where not all media termination support STUN server capabilities. 
         The objectives of the explicit realm identifier attribute are: (1) 
         to facilitate migration to universal deployment of ICE across all 
         media termination, provided that some media termination will get 
         there before others, (2) to support networks where some media 
         endpoint do not support STUN server capabilities, (3) to allow for 
         not using the peer-to-peer STUN mechanism defined in ICE when not 
         required, for efficiency purposes.  
          
         The core idea in this proposal is that if both media termination in 
         a session have a priori knowledge of having addresses in the same IP 
         addressing realm, it may not be necessary to perform the peer-to-
         peer STUN requests between them. 
          
         This proposal should address the biggest difficulties facing ICE 
         which is that it requires all media termination devices to support 
         it to be effective, making it a chicken-and-egg problem. It also 
         gives the ability to optimize the performance of systems where it is 
         knows that the STUN requests between the media termination are not 
         required(for example, between large gateways). 
          
          
      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  Usage of explicit realm identifier attribute 
       
         This document proposes that SIP UAs could include an explicit realm 
         identifier attribute for advertised IP addresses included in SDP in 
         SIP. By adding an explicit addressing realm description, the UAs may 
         be able to make decisions on which IP addresses to use for sending 
         media. This explicit addressing realm indicator may be provided in 
         SDP in addition to the STUN indication support described in ICE, or 
         it can be provided alone when STUN is not supported by the media 
         termination device. The explicit realm identifier SHALL be globally 
         unique. 
          
       
      Audet          Informational - Expires 20 December 2003       [Page 2]
                                          

       
                        draft-audet-sipping-add-realm-00.txt      June 2003 
         Recognizing that many endpoints may not support the explicit realm 
         indication, the proposal is backward-compatible with systems that 
         don't indicate any addressing realm. 
          
         Care has been taken to make this proposal consistent with ICE. As 
         such, it inherits the same mechanisms to describe IP addresses, RTP 
         and RTCP ports in SDP. 
          
         Addresses can be gathered according the means discussed in ICE, in 
         particular, STUN derived addresses. 
          
         A SIP UAs can determine that the addresses of the media termination 
         and media source can be used directly, bypassing the ICE peer-to-
         peer STUN requests between them, if and only if the media 
         termination addresses of the source and destination are located in 
         the same addressing realm. The SIP UAs MAY thus compare the realm 
         identifiers, and if the realm identifiers match, the addresses MAY 
         be used directly without further procedures (such as STUN requests). 
         If they do not match, or if one or both addressing realm identifiers 
         are not provided, the UAs SHALL NOT assume that the addresses are in 
         the same addressing realm, and normal treatment SHOULD apply: i.e., 
         use STUN (as per ICE) if supported, or otherwise use the derived 
         address or local address as per normal policy. 
          
         The examples in this document describe the case where there is only 
         one level of NAT. However, it is possible that certain deployment 
         scenarios will include "nested NATs". The explicit realm identifier 
         method will function properly with nested NAT because the derived 
         addresses are included in the SDP, along with their respective realm 
         identifier. Each embedded realm will thus have its own realm 
         identifier. Correlating the realm identifier with a specific address 
         (and thus potentially with the STUN IP address discovery procedures) 
         will thus be necessary and may require some configuration.  
          
          
      4  Format of the addressing realm identifier attribute 
          
         The addressing realm identifier SHALL be globally unique. A unique 
         number or a unique random string of any sort, including a VPN 
         identifier such as defined in RFC  2685 [3], a unique global 
         identifier of any sort (e.g., [4]) would work. In the examples in 
         this proposal, we use a string of character that is similar to a 
         user and domain name, analogous to the way the phone-context is 
         defined in draft-antti-rfc2806bis-08 [2]. An addressing-realm-type 
         parameter is defined to indicate what type of format is used to 
         describe the unique addressing realm identifier. 
          
         The addressing realm indication format is defined as follows in 
         ABNF: 
       
      Audet          Informational - Expires 20 December 2003       [Page 3]
                                          

       
                        draft-audet-sipping-add-realm-00.txt      June 2003 
          
         addressing-realm-attribute = "addressing-realm" ":"  
                               addressing-realm-type SP realm-descriptor 
         addressing-realm-type = "userdomain" 
         addressing-realm-descriptor = [ word "@" ] domainname 
          
         If allowing VPN identifiers or other mechanisms is required, more 
         addressing-realm-type and addressing-realm-descriptor elements would 
         need to be added to the ABNF. 
          
         The elements word and domainname are already defined in RFC3261 [5] 
         and draft-antti-rfc2806bis-08. They are transcribed below for the 
         reader's benefit: 
          
         domainname = *( domainlabel ... ) toplabel [ ... ] 
         domainlabel = alphanum / alphanum*(alphanum)/ .-. ) alphanum 
         toplabel = ALPHA / ALPHA *( alphanum / .-. ) alphanum 
         alphanum = ALPHA / DIGIT 
         DIGIT = %x30-39 ; 0-9 
         ALPHA = %x41-5A / %x61-7A ; A-Z / a-z 
         word  = 1*(alphanum / "-" / "." / "!" / "%" / "*" / "_" / "+" /  
                 "`" / "'"/ "~" / "(" / ")" / "<" / ">" / ":" / "\" /  
                 DQUOTE / "/" / "[" / "]" / "?" / "{" / "}" ) 
          
         The following are examples of addressing-realm attributes: 
          
         - Private Address in corporate network of Foo Inc.:  
           "a=addressing-realm:userdomain foo.com" 
          
         - Private Address in San Jose branch of Foo Inc.:  
           "a=addressing-realm:userdomain sanjose@foo.com" 
            
         - Private Address in NATed lab in San Jose branch of Foo Inc.:  
           "a=addressing-realm:userdomain lab3.sanjose@foo.com" 
          
         - Private Address behind NAT in home office:  
           "a=addressing-realm:userdomain audet@isp.net" 
          
         The means by which the UA gets the addressing realm identifier is 
         outside the scope of this document. It could be manually configured, 
         or some automated process could be used.  
          
         One advantage of this proposal is that for home users, there is no 
         need to configure an addressing realm identifier if there is no 
         possibility of 2 devices in the home network communicating together 
         through the home NAT. 
          
          
       
      Audet          Informational - Expires 20 December 2003       [Page 4]
                                          

       
                        draft-audet-sipping-add-realm-00.txt      June 2003 
      5  Example use cases 
          
         This section illustrates 3 different scenarios applicable to the 
         explicit realm identification method. 
           
         Configuration 1 is where A calls B, and A is behind a NAT and B is 
         in the public address space (i.e., in different IP addressing 
         realm). We assume the following: 
          
         A =  RTP/47.0.2.1:54344, RTCP/ 47.0.2.2:44345 (derived), and 
              RTP/10.0.1.2:22334, RTCP/10.0.1.2:22335 (corporate.foo.com)
          
         B =  RTP/66.8.1.7:78122, RTCP/66.8.1.7:78123 
          
         Configuration 2 is where A calls B, and A and B are each behind 
         their own NAT (i.e., in different IP addressing realm). We assume 
         the following: 
          
         A =  RTP/47.0.2.1:54344, RTCP/ 47.0.2.2:44345 (derived), and  
              RTP/10.0.1.2:22334, RTCP/10.0.1.2:22335 (corporate.foo.com) 
          
         B =  RTP/66.8.1.7:78122, RTCP/66.8.1.10:66111 (derived), and  
              RTP/192.168.0.2:55000, RTCP/192.168.0.2:55001 (audet@isp.net) 
          
         Configuration 3 is where A calls B, and A and B are behind the same 
         NAT (i.e., in the same IP addressing realm). We assume the 
         following: 
          
         A =  RTP/47.0.2.1:54344, RTCP/ 47.0.2.2:44345 (derived), and  
              RTP/10.0.1.2:22334, RTCP/10.0.1.2:22335 (corporate.foo.com) 
         B =  RTP/66.8.1.7:78122, RTCP/66.8.1.10:66111 (derived), and  
              RTP/10.8.8.13:37880, RTCP/10.8.8.13:37881 (corporate.foo.com) 
          
         In the examples below, no stun-attribute are included. However, it 
         should be understood that stun-attribute could be present, as per 
         the ICE draft. 
          
          
      5.1  Configuration 1 - A behind a NAT 
          
         Offer: 
          
           v=0 
           o=alice 2890844730 2890844731 IN IP4 host.foo.com 
           s= 
           t=0 0 
           a=group:ALT 1 2 
           m=audio 22334 RTP/AVP 0 
           c=IN IP4 10.0.1.2 
       
      Audet          Informational - Expires 20 December 2003       [Page 5]
                                          

       
                        draft-audet-sipping-add-realm-00.txt      June 2003 
           a=mid:1 
           a=addressing-realm:userdomain corporate@foo.com 
           m=audio 54344 RTP/AVP 0 
           c=IN IP4 47.0.2.1 
           a=rtcp:44345 IN IP4 47.0.2.2 
           a=mid:1 
           a=derived:1 
          
         Answer: 
          
           v=0 
           o=bob 280744730 28977631 IN IP4 host2.isp.net 
           s= 
           t=0 0 
           a=group:ALT 1 2 
           m=audio 0 RTP/AVP 0  -- The "0" rejects the media stream 
           c=IN IP4 66.8.1.7    -- The value of the IP address is of no 
           importance 
           a=mid:1 
           m=audio 78122 RTP/AVP 0 
           c=IN IP4 66.8.1.7 
           a=mid:2 
            
            
      5.2  Configuration 2 - A and B each behind their own NAT 
          
         Offer: 
          
           v=0 
           o=alice 2890844730 2890844731 IN IP4 host.foo.com 
           s= 
           t=0 0 
           a=group:ALT 1 2 
           m=audio 22334 RTP/AVP 0 
           c=IN IP4 10.0.1.2 
           a=mid:1 
           a=addressing-realm:userdomain corporate@foo.com 
           m=audio 54344 RTP/AVP 0 
           c=IN IP4 47.0.2.1 
           a=rtcp:44345 IN IP4 47.0.2.2 
           a=mid:1 
           a=derived:1 
          
         Answer: 
          
           v=0 
           o=bob 280744730 28977631 IN IP4 host2.isp.net 
           s= 
           t=0 0 
       
      Audet          Informational - Expires 20 December 2003       [Page 6]
                                          

       
                        draft-audet-sipping-add-realm-00.txt      June 2003 
           a=group:ALT 1 2 
           m=audio 0 RTP/AVP 0    -- Port "0" rejects the media stream 
           c=IN IP4 192.168.0.2   -- Value of IP address is of no importance 
           a=mid:1 
           a=addressing-realm:userdomain audet@isp.net 
           m=audio 78122 RTP/AVP 0 
           c=IN IP4 66.8.1.7 
           a=rtcp:66111 IN IP4 66.8.1.10 
           a=mid:2 
           a=derived:2 
            
            
      5.3  Configuration 3 - A and B behind one common NAT 
          
         Offer: 
          
           v=0 
           o=alice 2890844730 2890844731 IN IP4 host.foo.com 
           s= 
           t=0 0 
           a=group:ALT 1 2 
           m=audio 22334 RTP/AVP 0 
           c=IN IP4 10.0.1.2 
           a=mid:1 
           a=addressing-realm:userdomain corporate@foo.com 
           m=audio 54344 RTP/AVP 0 
           c=IN IP4 47.0.2.1 
           a=rtcp:44345 IN IP4 47.0.2.2 
           a=mid:1 
           a=derived:1 
          
         Answer: 
          
           v=0 
           o=bob 280744730 28977631 IN IP4 host2.foo.com 
           s= 
           t=0 0 
           a=group:ALT 1 2 
           m=audio 37880 RTP/AVP 0 
           c=IN IP4 10.8.8.13 
           a=mid:1 
           a=addressing-realm:userdomain corporate@foo.com 
           m=audio 0 RTP/AVP 0   -- Port "0" rejects the media stream 
           c=IN IP4 66.8.1.7     -- Value of IP address is of no importance 
           a=mid:2 
           a=derived:2 
          
          
       
      Audet          Informational - Expires 20 December 2003       [Page 7]
                                          

       
                        draft-audet-sipping-add-realm-00.txt      June 2003 
      6  Security Considerations 
          
         No particular security issues are introduced by this proposal beyond 
         the ones mentioned in RFC 3261 [5] and the ICE draft [1]. 
          
          
      7   IANA Considerations 
          
         This document registers a new SDP attribute: addressing-realm, 
         defined in section 4.  
          
          
      8  References
                    
         [1]  Rosenberg, "Interactive Connectivity Establishment (ICE): 
              Methodology for Network Address Translator (NAT) Traversal for 
              the Session Initiation Protocol (SIP)", Internet draft 
              http://www.ietf.org/internet-drafts/draft-rosenberg-sipping-ice-
              00.txt, February 2003 
          
         [2]  Schulzrinne, Vaha-Sipila, "The tel URI for Telephone Calls", 
              Internet draft http://www.ietf.org/internet-drafts/draft-antti-
              rfc2806bis-08.txt (work in progress), February 2003 
          
         [3]  Fox, Gleeson, "Virtual Private Networks Identifier", RFC 2685, 
              http://www.ietf.org/rfc/rfc2685.txt, September 1999 
          
         [4]  Ould-Brahim, Gleeson, Rekhter, "Global Unique Identifiers 
              (GID)", Internet draft http://www.ietf.org/internet-
              drafts/draft-ouldbrahim-ppvpn-gid-02.txt (work in progress), 
              December 2002 
          
         [5]  Rosenberg, Schulzrinne, et al., "SIP: Session Initiation 
              Protocol", http://www.ietf.org/rfc/rfc3261, June 2002 
          
                      
      9  Contributors   
          
         The authors would like to thank the following people for their 
         useful comments and suggestions related to this draft: Cedric Aoun, 
         Mary Barnes, Julian Mitchell, Patrick Ma and Sean March. 
          
            
       
      Audet          Informational - Expires 20 December 2003       [Page 8]
                                          

       
                        draft-audet-sipping-add-realm-00.txt      June 2003 
      10 Author's Address 
          
         Comments can be sent to the author: 
          
         Francois Audet 
         Nortel Networks 
         4655 Great America Parkway 
         Santa Clara, CA 95054 
         USA 
          
         tel:+1-408-495-3756 
         mailto:audet@nortelnetworks.com 
          
            
      11 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 BCP-11.  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. 
          
          
      12 Full Copyright Statement 
          
         Copyright (C) The Internet Society (2003).  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 
       
      Audet          Informational - Expires 20 December 2003       [Page 9]
                                          

       
                        draft-audet-sipping-add-realm-00.txt      June 2003 
         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." 
          
          
         Acknowledgement 
          
            Funding for the RFC Editor function is currently provided by the 
            Internet Society. 
       
      Audet          Informational - Expires 20 December 2003      [Page 10]