MMUSIC WG S. Veikkolainen Internet-Draft Nokia Intended status: Standards Track October 8, 2010 Expires: April 11, 2011 Interactive Connectivity Establishment (ICE) extensions for suppressing connectivity checks draft-veikkolainen-mmusic-ice-suppress-checks-00 Abstract Connectivity checks as proposed by Interactive Connectivity Establishment (ICE) are used to detect problems that cause endpoints not to receive media. However, in some cases connectivity checks are not seen as necessary, or such checks are not feasible for certain bearer types. This document defines a new candidate address type for which connectivity checks are not performed. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 11, 2011. 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 Veikkolainen Expires April 11, 2011 [Page 1] Internet-Draft Suppressing connectivity checks in ICE October 2010 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. This document may contain material from IETF Documents or IETF Contributions published or made publicly available before November 10, 2008. The person(s) controlling the copyright in some of this material may not have granted the IETF Trust the right to allow modifications of such material outside the IETF Standards Process. Without obtaining an adequate license from the person(s) controlling the copyright in such materials, this document may not be modified outside the IETF Standards Process, and derivative works of it may not be created outside the IETF Standards Process, except to format it for publication as an RFC or to translate it into languages other than English. Veikkolainen Expires April 11, 2011 [Page 2] Internet-Draft Suppressing connectivity checks in ICE October 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 3. Overview of operation . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Description . . . . . . . . . . . . . . . . . . . . . 5 4.1. Sending the initial offer . . . . . . . . . . . . . . . . 5 4.1.1. Gathering candidates . . . . . . . . . . . . . . . . . 5 4.1.2. Prioritizing . . . . . . . . . . . . . . . . . . . . . 5 4.1.3. Eliminating redundant candidates . . . . . . . . . . . 5 4.1.4. Choosing default candidates . . . . . . . . . . . . . 6 4.1.5. Encoding the SDP . . . . . . . . . . . . . . . . . . . 6 4.2. Receiving the Initial Offer . . . . . . . . . . . . . . . 6 4.2.1. Verifying ICE support . . . . . . . . . . . . . . . . 6 4.2.2. Determining role . . . . . . . . . . . . . . . . . . . 6 4.2.3. Gathering candidates . . . . . . . . . . . . . . . . . 6 4.2.4. Prioritizing candidates . . . . . . . . . . . . . . . 6 4.2.5. Choosing default candidates . . . . . . . . . . . . . 6 4.2.6. Encoding the SDP . . . . . . . . . . . . . . . . . . . 7 4.2.7. Forming the check lists . . . . . . . . . . . . . . . 7 4.3. Receipt of the Initial Answer . . . . . . . . . . . . . . 7 4.3.1. Verifying ICE support . . . . . . . . . . . . . . . . 7 4.3.2. Determining role . . . . . . . . . . . . . . . . . . . 7 4.3.3. Forming the check list . . . . . . . . . . . . . . . . 7 4.3.4. Performing ordinary checks . . . . . . . . . . . . . . 7 4.4. Concluding ICE . . . . . . . . . . . . . . . . . . . . . . 7 5. Extensions to SDP . . . . . . . . . . . . . . . . . . . . . . 8 5.1. Extensions to 'candidate' attribute . . . . . . . . . . . 8 5.2. Extensions to 'ice-options' attribute . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 9.1. Normative References . . . . . . . . . . . . . . . . . . . 9 9.2. Informative References . . . . . . . . . . . . . . . . . . 9 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 10 Veikkolainen Expires April 11, 2011 [Page 3] Internet-Draft Suppressing connectivity checks in ICE October 2010 1. Introduction Interactive Connectivity Establishment, ICE, [RFC5245] defines connectivity checks as a mechanism to ensure that media path can be used between two endpoints. There are however cases when connectivity checks are not needed or they may not be possible. [I-D.boucadair-mmusic-altc] and [I-D.hutton-mmusic-icemicrolite] argue that ICE is overly complex in certain deployment cases, and that a simpler alternative to full- blown ICE would be desired. One component creating this complexity are the connectivity checks. Also, [I-D.wing-dispatch-v6-migration] proposes a mechanism for migrating to IPv6 networks whereby connectivity checks may be bypassed by simultaneously sending media over IPv4 and IPv6 thus probing which of the media paths is operational. Media is usually transported using RTP, but other possibilities exist as well. [I-D.ietf-mmusic-sdp-cs] defines conventions for describing circuit-switched bearers in SDP. When such a circuit-switched bearer is used as a candidate address in ICE, connectivity checks are not feasible due to the nature of the circuit-switched bearer. This document defines an extension to ICE for suppressing connectivity checks for certain candidate addresses. Implementations conforming to this document do not perform connectivity checks for these candidate addresses, but rather indicate the checks as having been successful when going through the ICE process of creating candidate pairs. 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 BCP 14, RFC 2119 [RFC2119] and indicate requirement levels for compliant implementations. 3. Overview of operation An Full ICE (see Section 3 of [RFC5245]) implementation may be aware of certain candidate addresses for which connectivity checks need not be used. The agent indicates these kind of candidate addresses with a new candidate address type, "Suppressed host candidate", defined in this document. Veikkolainen Expires April 11, 2011 [Page 4] Internet-Draft Suppressing connectivity checks in ICE October 2010 For candidate addresses which are of type Suppressed host candidate, no connectivity checks are performed. Instead, they are treated during the ICE process as having successfully completed the connectivity checking, and resulted in Succeeded state when forming the Check List. 4. Protocol Description For convenience, we use the same section structure as in [RFC5245] Sections 4, 5, and 6, even if in many cases there are no modifications to the original procedures. 4.1. Sending the initial offer 4.1.1. Gathering candidates An agent gathers candidates according to Section 4.1 of [RFC5245] with the following additions. Any host candidate for which an agent wishes not to use connectivity checks should be declared as "Suppressed host candidate" type. As discussed in Section 4.1.1.2 of [RFC5245], use of STUN or TURN servers and thus Server Reflexive and Relayed Candidates may be unnecessary in closed networks where agents are never connected to the public Internet or to endpoints outside of the closed network. Therefore, only host candidates are likely to be defined as Suppressed host candidates. The criteria for declaring a host candidate as Suppressed host candidate is outside the scope of this document. However, it is RECOMMENDED that this criteria is configurable and could thus be modified if the conditions change in the future. 4.1.2. Prioritizing Prioritizing candidates follows the procedures defined in Section 4.1.2 of [RFC5245]. 4.1.3. Eliminating redundant candidates Eliminating redundant candidates follows the procedures defined in Section 4.1.3 of [RFC5245]. Veikkolainen Expires April 11, 2011 [Page 5] Internet-Draft Suppressing connectivity checks in ICE October 2010 4.1.4. Choosing default candidates Choosing default candidates follows the procedures defined in Section 4.1.4 of [RFC5245]. 4.1.5. Encoding the SDP Encoding the SDP follows the procedures defined in Section 4.3 of [RFC5245] with the following additions. The type of each candidate attribute for which an endpoint wishes to suppress connectivity checks is set to Suppressed host candidate using the token "suppr". The SDP encoding rules are defined in Section 5. An agent which sets some candidate addresses as Suppressed host candidates MUST include the value "suppressed-candidates" in the ice- options attribute in the Initial Offer. 4.2. Receiving the Initial Offer 4.2.1. Verifying ICE support Verifying ICE support follows the procedures defined in Section 5.1 of [RFC5245]. 4.2.2. Determining role Determining role follows the procedures defined in Section 5.2 of [RFC5245]. 4.2.3. Gathering candidates Choosing default candidates follows the procedures defined in Section 5.3 of [RFC5245]. 4.2.4. Prioritizing candidates Choosing default candidates follows the procedures defined in Section 5.4 of [RFC5245]. 4.2.5. Choosing default candidates Choosing default candidates follows the procedures defined in Section 5.5 of [RFC5245]. Veikkolainen Expires April 11, 2011 [Page 6] Internet-Draft Suppressing connectivity checks in ICE October 2010 4.2.6. Encoding the SDP The process for encodig the SDP for the Initial Answer is identical to the process followed by the offerer, as described in Section 4.1.5. 4.2.7. Forming the check lists Forming check lists follows the procedures defined in Section 4.1.4 of [RFC5245] with the following additions. For candidate address pairs which are of type Suppressed host candidates, the state assigned MUST be Succeeded, as if the connectivity checks for those candidate pairs was already completed. An agent MUST NOT perform connectivity checks for pairs that are of type Suppressed host candidate. 4.3. Receipt of the Initial Answer 4.3.1. Verifying ICE support Verifying ICE support follows the procedures defined in Section 6.1 of [RFC5245]. 4.3.2. Determining role Determining role follows the procedures defined in Section 6.2 of [RFC5245]. 4.3.3. Forming the check list The offerer follows the same procedures described for the answerer in Section 4.2.7. 4.3.4. Performing ordinary checks The procedures defined in Section 7 of [RFC5245] are followed, except for candidate addresses which are of type Suppressed host candidate, for which connectivity checks MUST NOT be performed. 4.4. Concluding ICE The agents follow the procedures for Full implementations defined in Section 8.1 of [RFC5245]. As defined therein, if the peer is using ice-options which the agent does not understand, the agent MUST use a regular nomination algorithm. Veikkolainen Expires April 11, 2011 [Page 7] Internet-Draft Suppressing connectivity checks in ICE October 2010 If both agents use the ice-option "suppressed-candidates" defined in this document, the agents MAY use either the aggressive or the regular nomination algorithm. 5. Extensions to SDP 5.1. Extensions to 'candidate' attribute ICE defines a "candidate" attribute with the following syntax (from [RFC5245]): candidate-attribute = "candidate" ":" foundation SP component-id SP transport SP priority SP connection-address SP ;from RFC 4566 port ;port from RFC 4566 SP cand-type [SP rel-addr] [SP rel-port] *(SP extension-att-name SP extension-att-value) The candidate address type is defined with: cand-type = "typ" SP candidate-types candidate-types = "host" / "srflx" / "prflx" / "relay" / token This document extends the the candidate address type with Suppressed host candidate type, which has the following ABNF: candidate-types /= "suppr" 5.2. Extensions to 'ice-options' attribute The "ice-options" attribute is defined by the following ABNF: ice-options = "ice-options" ":" ice-option-tag 0*(SP ice-option-tag) ice-option-tag = 1*ice-char This document extends the "ice-options" attribute with a new value, "suppressed-candidates", with the following ABNF: ice-option-tag /= "suppressed-candidates" Veikkolainen Expires April 11, 2011 [Page 8] Internet-Draft Suppressing connectivity checks in ICE October 2010 6. IANA Considerations At this time, there is no registry or registration procedures defined for ICE option tags. This section needs to be revised if conditions change in the future. 7. Security Considerations The possible attacks on connectivity checks are discussed in Section 18 of [RFC5245], including the case of False Valids. Since the connectivity checking for Suppressed host candidates is declared as successful even if no connectivity checks are actually sent, the end result can be in misconfigured networks the same as for False Valid: a pair of agents think a candidate pair is valid even when in realiy it is not. This can lead an agent to proceed with the session, but then not be able to receive any media. Care must be there paid that Suppressed host candidates are only used in environments where connectivity between agents can be guaranteed without connectivity checks. 8. Acknowledgments 9. References 9.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols", RFC 5245, April 2010. 9.2. Informative References [I-D.boucadair-mmusic-altc] Boucadair, M., Kaplan, H., Gilman, R., and S. Veikkolainen, "Session Description Protocol (SDP) Alternate Connectivity (ALTC) Attribute", draft-boucadair-mmusic-altc-01 (work in progress), September 2010. [I-D.hutton-mmusic-icemicrolite] Hutton, A. and J. Elwell, "A mechanism for conveying Veikkolainen Expires April 11, 2011 [Page 9] Internet-Draft Suppressing connectivity checks in ICE October 2010 alternate addresses using ICE syntax", draft-hutton-mmusic-icemicrolite-01 (work in progress), March 2010. [I-D.ietf-mmusic-sdp-cs] Garcia, M. and S. Veikkolainen, "Session Description Protocol (SDP) Extension For Setting Up Audio and Video Media Streams Over Circuit-Switched Bearers In The Public Switched Telephone Network (PSTN)", draft-ietf-mmusic-sdp-cs-05 (work in progress), October 2010. [I-D.wing-dispatch-v6-migration] Wing, D. and A. Yourtchenko, "Migrating SIP to IPv6 Media Without Connectivity Checks", draft-wing-dispatch-v6-migration-00 (work in progress), August 2010. Author's Address Simo Veikkolainen Nokia P.O. Box 407 NOKIA GROUP, FI 00045 Finland Phone: +358 50 486 4463 Email: simo.veikkolainen@nokia.com Veikkolainen Expires April 11, 2011 [Page 10]