Network Working Group A. Keranen Internet-Draft J. Arkko Updates: 5245, 6544 (if approved) Ericsson Intended status: Standards Track July 16, 2012 Expires: January 17, 2013 Update on Candidate Address Selection for Interactive Connectivity Establishment (ICE) draft-keranen-mmusic-ice-address-selection-01 Abstract This document revisits the rules on how candidate addresses are selected and combined when the Interactive Connectivity Establishment (ICE) NAT traversal method is used. This document updates RFCs 5245 and 6544. 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 January 17, 2013. Copyright Notice Copyright (c) 2012 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 Keranen & Arkko Expires January 17, 2013 [Page 1] Internet-Draft Candidate Address Selection for ICE July 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Changes to Candidate Address Selection . . . . . . . . . . . . 4 4. Negotiating Address Selection Scheme . . . . . . . . . . . . . 4 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 Keranen & Arkko Expires January 17, 2013 [Page 2] Internet-Draft Candidate Address Selection for ICE July 2012 1. Introduction When Interactive Connectivity Establishment (ICE) [RFC5245] [RFC6544] is used for NAT traversal, both endpoints gather multiple IP addresses and ports, also called candidate addresses, and test for connectivity between them. One of the principles of ICE is to gather all possible candidate addresses and pair them with all the addresses of the peer in order to test all combinations and get high probability for successful NAT traversal. A prioritization formula is used by ICE so that most preferred address pairs are tested first, and if a sufficiently good pair is discovered, the tests can be stopped. Addresses obtained from local network interfaces, called host candidates, are recommended as high- priority ones to be tested first since if they work, they provide usually the best path between the two hosts. With IPv4 this approach works well since interfaces usually have just a single unicast IP address. However, with IPv6 addressing architecture [RFC4291] interfaces commonly have multiple addresses: global, link-local, Unique Local (ULA) [RFC4193], etc. The ICE specification recommends to use the rules defined in [RFC3484] as part of the prioritization formula for IPv6 candidates, but does not give much further advice on how to handle different kind of IPv6 addresses. However, if all different kind of IPv6 addresses are paired with each other, some of the combinations will never work and may unnecessarily delay the completion of the ICE process. This document updates the ICE rules defined in [RFC5245] and [RFC6544] on how candidate addresses are selected and how they should be combined with each other in order to maintain high performance for the ICE NAT traversal process. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. This document uses the same terminology as ICE (see Section 3 of [RFC5245]) and the following: Local relayed candidate: a relayed candidate (obtained, e.g., from a TURN server) and included in an ICE offer or answer the agent has or will send. Keranen & Arkko Expires January 17, 2013 [Page 3] Internet-Draft Candidate Address Selection for ICE July 2012 3. Changes to Candidate Address Selection This document proposes the following updates to the rules for selecting and combining IPv6 candidate addresses: o Instead of RFC 3484 rules, the rules defined in [I-D.ietf-6man-rfc3484bis] MUST be used for determining the candidate priorities. If operating system address preferences are available (e.g,. via appropriate API extension), those SHOULD be used instead of default preferences. o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site- local unicast addresses [RFC3879] MUST NOT be included in the address candidates. o Candidate addresses from link-local addresses MUST NOT be combined with any other candidates except other link-local candidates. o Candidate addresses from Unique Local Addresses (ULAs) MUST NOT be combined with any other candidates except other ULA candidates. o IPv4-mapped IPv6 addresses MUST NOT be included in the offered candidates unless the application using ICE does not support IPv4 (i.e., is an IPv6-only application [RFC4038]). The following updates pertain to both IPv4 and IPv6 addresses: o Addresses from a loopback interface MUST NOT be included in the candidate addresses. o Local relayed candidates MUST NOT be combined with remote host candidates from IPv4 private address space [RFC1918] or IPv6 link- local addresses or ULAs. 4. Negotiating Address Selection Scheme The prioritization method for the candidate address pairs used by ICE results in matching checklists for both endpoints and hence both endpoints start the checks for the same candidate pair roughly at the same time. This is important since in many scenarios a connectivity check initiated by both endpoints for the same pair is needed before a check for the pair succeeds. Also, some NAT devices have very short timeouts for their address translation bindings and a binding created by a connectivity check from one endpoint may expire before the corresponding connectivity check from the other endpoint is sent if there is a long delay between the two checks. Keranen & Arkko Expires January 17, 2013 [Page 4] Internet-Draft Candidate Address Selection for ICE July 2012 Depending on how different candidates are paired and whether RFC 3484 or the revised version of it [I-D.ietf-6man-rfc3484bis] is used, the endpoints may end up with different priorities and checklists. Therefore, the endpoints need to agree on how the address selection and pairing is done. To indicate that the address selection and pairing rules defined in this document are used, the ICE offerer MUST include ice-options attribute with "bis-candidates" option identifier in the Session Description Protocol (SDP) [RFC4566] ICE offer. If the ICE offer does not include this option tag, the answerer SHOULD NOT utilize the updated rules defined in this document. If the offer included the option tag and the answerer supports this specification, the answerer SHOULD add the same option tag to the response and use the updated rules. If the ICE answer does not contain the option tag, the offerer SHOULD NOT use the updated rules. However, even if the other endpoint does not indicate support for the updated rules, loopback addresses or the deprecated IPv6 addresses SHOULD NOT be included in the candidates. 5. Security Considerations The general security considerations for ICE have been documented in Section 18 of [RFC5245] and Section 12 of [RFC6544]. The general security considerations for IPv6 address selection rules have been documented in [I-D.ietf-6man-rfc3484bis]. The vulnerabilities in ICE and RFC3484bis relate to attempts to hijack sessions opened through ICE, denial-of-service attacks, and accidental disclosure of private information. Mechanisms described in [RFC5245] and [RFC6544] - such as validated TCP connections - are designed to protect against connection hijacking. Denial-of-service attacks can not be completely eliminated, but the amplification capabilities of ICE are limited through a maximum value of concurrently probed connections. Any address probing mechanism opens up the possibility of outsiders learning the correlation between different IP addresses. For instance, the existence of a privacy address [RFC4941] in the candidate set along with other, more stable addresses will tell at least the peer and maybe eavesdroppers that the addresses are related. This specification introduces no specific new security concerns beyond these, as it only attempts to unify the algorithms associated with candidate address pair selection. However, where address Keranen & Arkko Expires January 17, 2013 [Page 5] Internet-Draft Candidate Address Selection for ICE July 2012 selection rules in a node are configured through an external mechanism, as suggested in [I-D.ietf-6man-rfc3484bis], this opens up another avenue for introducing incorrect addresses into the probing mechanism. The resulting system is only as secure as its weakest component. For instance, even if sufficient security mechanisms are in place in ICE, vulnerabilities in the configuration mechanisms for the 3484bis priority tables may introduce weaknesses in the ability of ICE to select the right addresses. 6. IANA Considerations IANA is requested to register "bis-candidates" option identifier under the "ICE Options" [RFC6336] registry. The required registration information is as follows: Option identifier: bis-candidates Contact: Ari Keranen, ari.keranen@ericsson.com Change control: IETF Description: Existence of this option identifier indicates that the revised rules (defined in RFCXXXX) are used for candidate address selection. Reference: RFCXXXX [RFC editor: replace XXXX with the RFC number of this document] 7. References 7.1. Normative References [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. Keranen & Arkko Expires January 17, 2013 [Page 6] Internet-Draft Candidate Address Selection for ICE July 2012 [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. [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for Interactive Connectivity Establishment (ICE) Options", RFC 6336, July 2011. [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, "TCP Candidates with Interactive Connectivity Establishment (ICE)", RFC 6544, March 2012. [I-D.ietf-6man-rfc3484bis] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol version 6 (IPv6)", draft-ietf-6man-rfc3484bis-06 (work in progress), June 2012. 7.2. Informative References [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local Addresses", RFC 3879, September 2004. [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy Extensions for Stateless Address Autoconfiguration in IPv6", RFC 4941, September 2007. Appendix A. Acknowledgments The authors would like to thank Jan Melen, Dan Wing, and Jonathan Lennox for comments, reviews and valuable input to the document. Keranen & Arkko Expires January 17, 2013 [Page 7] Internet-Draft Candidate Address Selection for ICE July 2012 Authors' Addresses Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Keranen & Arkko Expires January 17, 2013 [Page 8]