Internet DRAFT - draft-keranen-mmusic-ice-address-selection
draft-keranen-mmusic-ice-address-selection
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]
