Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)
draft-ietf-sip-ice-option-tag-02

SIP                                                         J. Rosenberg
Internet-Draft                                                     Cisco
Intended status: Standards Track                           June 19, 2007
Expires: December 21, 2007

 Indicating Support for Interactive Connectivity Establishment (ICE) in
                 the Session Initiation Protocol (SIP)
                    draft-ietf-sip-ice-option-tag-02

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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 December 21, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).

Abstract

   This specification defines a media feature tag and an option tag for
   use with the Session Initiation Protocol (SIP).  The media feature
   tag allows a UA to communicate to its registrar that it supports ICE.
   The option tag allows a User Agent (UA) to require support for ICE in
   order for a call to proceed.

Rosenberg               Expires December 21, 2007               [Page 1]
Internet-Draft                 ICE Support                     June 2007

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . . . 3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3
   3.  Motivation  . . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.1.  Gateways  . . . . . . . . . . . . . . . . . . . . . . . . . 3
     3.2.  Mandating Support for ICE . . . . . . . . . . . . . . . . . 4
   4.  Media Feature Tag Definition  . . . . . . . . . . . . . . . . . 4
   5.  Option Tag Definition . . . . . . . . . . . . . . . . . . . . . 4
   6.  Security Considerations . . . . . . . . . . . . . . . . . . . . 5
   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5
     7.1.  Option Tag  . . . . . . . . . . . . . . . . . . . . . . . . 5
     7.2.  Media Feature Tag . . . . . . . . . . . . . . . . . . . . . 5
   8.  References  . . . . . . . . . . . . . . . . . . . . . . . . . . 6
     8.1.  Normative References  . . . . . . . . . . . . . . . . . . . 6
     8.2.  Informative References  . . . . . . . . . . . . . . . . . . 7
   Author's Address  . . . . . . . . . . . . . . . . . . . . . . . . . 7
   Intellectual Property and Copyright Statements  . . . . . . . . . . 8

Rosenberg               Expires December 21, 2007               [Page 2]
Internet-Draft                 ICE Support                     June 2007

1.  Introduction

   RFC 3264 [3] defines a two-phase exchange of Session Description
   Protocol (SDP) messages [5] for the purposes of establishment of
   multimedia sessions.  This offer/answer mechanism is used by
   protocols such as the Session Initiation Protocol (SIP) [2].

   Protocols using offer/answer are difficult to operate through Network
   Address Translators (NAT).  Because their purpose is to establish a
   flow of media packets, they tend to carry IP addresses within their
   messages, which is known to be problematic through NAT [7].  To
   remedy this, an extension to SDP, called Interactive Connectivity
   Establishment (ICE) has been defined [6].  ICE defines procedures by
   which agents gather a multiplicity of addresses, include all of them
   in an SDP offer or answer, and then use peer-to-peer Simple Traversal
   Underneath NAT (STUN) [9] connectivity checks to determine a valid
   address.

   This specification defines a media feature tag, "sip.ice", and a SIP
   option tag, "ice", that can be used by SIP user agents that make use
   of ICE.  Section 3 motivates the need for the media feature tag and
   option tag, and Section 4 and Section 5 formally define them.

2.  Terminology

   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 [1].

3.  Motivation

   There are two primary motivations for defining an option tag and a
   media feature tag.  They are support for gateways, and requiring ICE
   for a call.

3.1.  Gateways

   Unfortunately, ICE requires both endpoints to support it in order for
   it to be used.  Within a domain, there will typically be user agents
   that do and do not support ICE.  In order to facilitate deployment of
   ICE, it is anticipated that domains will make use of gateways which
   act as ICE agents on one side, an non-ICE agents on the other side.
   This would allow a call from domain A into domain B to make use of
   ICE, even if the device in domain B does not itself yet support ICE.
   However, when domain B receives a call, it will need to know whether
   the call needs to pass through such a gateway, or whether it can go

Rosenberg               Expires December 21, 2007               [Page 3]
Internet-Draft                 ICE Support                     June 2007

   to the terminating UA directly.

   In order to make such a determination, this specification defines a
   media feature tag, "sip.ice", which can be included in the Contact
   header field of a REGISTER request [4].  This allows the registrar to
   track whether a UA supports ICE or not.  This information can be
   accessed by a proxy in order to determine whether a call needs to
   route through a gateway or not.

3.2.  Mandating Support for ICE

   Although ICE provides a built in fall back to non-ICE operation when
   the answerer doesn't support it, there are cases where the offerer
   would rather abort the call rather than proceed without ICE.
   Typically, this is because they would like to choose a different m/c-
   line address for a non-ICE peer than they would for an ICE capable
   peer.

   To do this, the "ice" SIP option tag can be included in the Require
   header field of an INVITE request.

4.  Media Feature Tag Definition

   The "sip.ice" media feature tag indicates support for ICE.  An agent
   supports ICE if it is either a lite or full implementation, and
   consequently, is capable of including candidate attributes in an SDP
   offer or answer for at least one transport protocol.  An agent that
   supports ICE SHOULD include this media feature tag in the Contact
   header field of its REGISTER requests and OPTION responses.

   An agent MAY include the media feature tag in the Contact header
   field of an INVITE or INVITE response; however, doing so is redundant
   with ICE attributes in the SDP which indicate the same thing.  In
   cases where an INVITE omits an offer, the lack or presence of the
   media feature tag in the Contact header field cannot be used by the
   callee (which will be the offerer) to determine whether the caller
   supports ICE.  In cases of third party call control [8], the caller
   may be a controller that supports (or doesn't) ICE, while the
   answerer may be an agent which does (or doesn't) support ICE.

5.  Option Tag Definition

   This "ice" OPTION tag SHOULD NOT be used in conjunction with the
   Supported header field (this SHOULD NOT includes responses to OPTIONS
   requests) The media feature tag is used as the one and only mechanism
   for indicating support for ICE.  The option tag is meant to be used

Rosenberg               Expires December 21, 2007               [Page 4]
Internet-Draft                 ICE Support                     June 2007

   only with the Require header field.  When placed in the Require
   header field of an INVITE request, it indicates that the UAS must
   support ICE in order to process the call.  An agent supports ICE if
   it is either a full or lite implementation, and consequently, is
   capable of including candidate attributes in an SDP offer or answer
   for at least one transport protocol.

6.  Security Considerations

   A malicious intermediary might attempt to modify a SIP message by
   inserting a Require header field containing the "ice" option tag.  If
   ICE were not supported on the UAS, this would cause the call to fail
   when it would otherwise succeed.  Of course, this attack is not
   specific to ICE, and can be done using any option tag.  This attack
   is prevented by usage of the SIPS mechanism as defined in RFC 3261.

   Similarly, an intermediary might attempt to remove the media feature
   tag from a REGISTER request or OPTIONS request, which might cause a
   call to skip ICE processing when it otherwise might make use of it.
   This attack is also prevented using the SIPS mechanism.

7.  IANA Considerations

   This specification defines a new media feature tag and SIP option
   tag.

7.1.  Option Tag

   This section defines a new SIP option tag per the guidelines in
   Section 27.1 of RFC 3261.

   Name:  ice

   Description:  This option tag is used to identify the Interactive
      Connectivity Establishment (ICE) extension.  When present in a
      Require header field, it indicates that ICE is required by an
      agent.

7.2.  Media Feature Tag

   This section registers a new media feature tag in the SIP tree,
   defined in Section 12.1 of RFC 3840 [4].

Rosenberg               Expires December 21, 2007               [Page 5]
Internet-Draft                 ICE Support                     June 2007

   Media feature tag name:  sip.ice

   ASN.1 Identifier:  1.3.6.1.8.4.22

   Summary of the media feature indicated by this tag:  This feature tag
      indicates that the device supports Interactive Connectivity
      Establishment (ICE).

   Values appropriate for use with this feature tag:  Boolean.

   The feature tag is intended primarily for use in the following
   applications, protocols, services, or negotiation mechanisms:  This
      feature tag is most useful in a communications application, for
      describing the capabilities of a device, such as a phone or PDA.

   Examples of typical use:  Routing a call to a phone that can support
      ICE.

   Related standards or documents:  RFC XXXX [[Note to IANA: Please
      replace XXXX with the RFC number of this specification.]]

   Security Considerations:  Security considerations for this media
      feature tag are discussed in Section 6 of RFC XXXX .  [[Note to
      IANA: Please replace XXXX with the RFC number of this
      specification.]]

8.  References

8.1.  Normative References

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

   [2]  Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
        Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
        Session Initiation Protocol", RFC 3261, June 2002.

   [3]  Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model with
        Session Description Protocol (SDP)", RFC 3264, June 2002.

   [4]  Rosenberg, J., Schulzrinne, H., and P. Kyzivat, "Indicating User
        Agent Capabilities in the Session Initiation Protocol (SIP)",
        RFC 3840, August 2004.

   [5]  Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
        Description Protocol", RFC 4566, July 2006.

Rosenberg               Expires December 21, 2007               [Page 6]
Internet-Draft                 ICE Support                     June 2007

   [6]  Rosenberg, J., "Interactive Connectivity Establishment (ICE): A
        Methodology for Network  Address Translator (NAT) Traversal for
        Offer/Answer Protocols", draft-ietf-mmusic-ice-13 (work in
        progress), January 2007.

8.2.  Informative References

   [7]  Senie, D., "Network Address Translator (NAT)-Friendly
        Application Design Guidelines", RFC 3235, January 2002.

   [8]  Rosenberg, J., Peterson, J., Schulzrinne, H., and G. Camarillo,
        "Best Current Practices for Third Party Call Control (3pcc) in
        the Session Initiation Protocol (SIP)", BCP 85, RFC 3725,
        April 2004.

   [9]  Rosenberg, J., "Simple Traversal Underneath Network Address
        Translators (NAT) (STUN)", draft-ietf-behave-rfc3489bis-05 (work
        in progress), October 2006.

Author's Address

   Jonathan Rosenberg
   Cisco
   Edison, NJ
   US

   Email: jdrosen@cisco.com
   URI:   http://www.jdrosen.net

Rosenberg               Expires December 21, 2007               [Page 7]
Internet-Draft                 ICE Support                     June 2007

Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.

Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights 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; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat 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 implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.

Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).

Rosenberg               Expires December 21, 2007               [Page 8]