diff options
Diffstat (limited to 'doc/rfc/rfc5768.txt')
| -rw-r--r-- | doc/rfc/rfc5768.txt | 339 |
1 files changed, 339 insertions, 0 deletions
diff --git a/doc/rfc/rfc5768.txt b/doc/rfc/rfc5768.txt new file mode 100644 index 0000000..71cff71 --- /dev/null +++ b/doc/rfc/rfc5768.txt @@ -0,0 +1,339 @@ + + + + + + +Internet Engineering Task Force (IETF) J. Rosenberg +Request for Comments: 5768 jdrosen.net +Category: Standards Track April 2010 +ISSN: 2070-1721 + + + Indicating Support for Interactive Connectivity Establishment (ICE) + in the Session Initiation Protocol (SIP) + +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 User Agent (UA) to communicate to its registrar that it + supports ICE. The option tag allows a UA to require support for ICE + in order for a call to proceed. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc5768. + +Copyright Notice + + Copyright (c) 2010 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + +Rosenberg Standards Track [Page 1] + +RFC 5768 ICE Support April 2010 + + +Table of Contents + + 1. Introduction ....................................................2 + 2. Terminology .....................................................2 + 3. Motivation ......................................................3 + 3.1. Gateways ...................................................3 + 3.2. Mandating Support for ICE ..................................3 + 4. Media Feature Tag Definition ....................................3 + 5. Option Tag Definition ...........................................4 + 6. Security Considerations .........................................4 + 7. IANA Considerations .............................................4 + 7.1. Option Tag .................................................4 + 7.2. Media Feature Tag ..........................................5 + 8. References ......................................................5 + 8.1. Normative References .......................................5 + 8.2. Informative References .....................................6 + +1. Introduction + + RFC 3264 [RFC3264] defines a two-phase exchange of Session + Description Protocol (SDP) [RFC4566] messages for the purposes of + establishment of multimedia sessions. This offer/answer mechanism is + used by protocols such as the Session Initiation Protocol (SIP) + [RFC3261]. + + 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 [RFC3235]. To + remedy this, an extension to SDP, called Interactive Connectivity + Establishment (ICE) has been defined [RFC5245]. 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 Session Traversal Utilities for NAT (STUN) [RFC5389] + 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 [RFC2119]. + + + + + +Rosenberg Standards Track [Page 2] + +RFC 5768 ICE Support April 2010 + + +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 that + act as ICE agents on one side, and 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 + 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 [RFC3840]. This allows the + registrar to track whether or not a UA supports ICE. This + information can be accessed by a proxy in order to determine whether + or not a call needs to route through a gateway. + +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. + + + + + +Rosenberg Standards Track [Page 3] + +RFC 5768 ICE Support April 2010 + + + 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 that 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 [RFC3725], the + caller may be a controller that does (or doesn't) support ICE, while + the answerer may be an agent that 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 include responses to OPTION + 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 only with the Require header field. When placed in the + Require header field of an INVITE request, it indicates that the User + Agent Server (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. + + + + + +Rosenberg Standards Track [Page 4] + +RFC 5768 ICE Support April 2010 + + + 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 [RFC3840]. + + 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 5768 + + Security Considerations: Security considerations for this media + feature tag are discussed in Section 6 of this document. + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC3261] 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. + + + + +Rosenberg Standards Track [Page 5] + +RFC 5768 ICE Support April 2010 + + + [RFC3264] Rosenberg, J. and H. Schulzrinne, "An Offer/Answer Model + with Session Description Protocol (SDP)", RFC 3264, + June 2002. + + [RFC3840] Rosenberg, J., Schulzrinne, H., and P. Kyzivat, + "Indicating User Agent Capabilities in the Session + Initiation Protocol (SIP)", RFC 3840, August 2004. + + [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session + Description Protocol", RFC 4566, July 2006. + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, April + 2010. + +8.2. Informative References + + [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly + Application Design Guidelines", RFC 3235, January 2002. + + [RFC3725] 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. + + [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, + "Session Traversal Utilities for NAT (STUN)", RFC 5389, + October 2008. + +Author's Address + + Jonathan Rosenberg + jdrosen.net + Monmouth, NJ + US + + EMail: jdrosen@jdrosen.net + URI: http://www.jdrosen.net + + + + + + + + + + + + +Rosenberg Standards Track [Page 6] + |