idnits 2.17.1 draft-keranen-mmusic-ice-address-selection-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year (Using the creation date from RFC5245, updated by this document, for RFC5378 checks: 2003-10-29) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 16, 2012) is 4299 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 4566 (Obsoleted by RFC 8866) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 6336 (Obsoleted by RFC 8839) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 1 warning (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Keranen 3 Internet-Draft J. Arkko 4 Updates: 5245, 6544 (if approved) Ericsson 5 Intended status: Standards Track July 16, 2012 6 Expires: January 17, 2013 8 Update on Candidate Address Selection for 9 Interactive Connectivity Establishment (ICE) 10 draft-keranen-mmusic-ice-address-selection-01 12 Abstract 14 This document revisits the rules on how candidate addresses are 15 selected and combined when the Interactive Connectivity Establishment 16 (ICE) NAT traversal method is used. This document updates RFCs 5245 17 and 6544. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 17, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 55 3. Changes to Candidate Address Selection . . . . . . . . . . . . 4 56 4. Negotiating Address Selection Scheme . . . . . . . . . . . . . 4 57 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 58 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 59 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7.1. Normative References . . . . . . . . . . . . . . . . . . . 6 61 7.2. Informative References . . . . . . . . . . . . . . . . . . 7 62 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 7 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 65 1. Introduction 67 When Interactive Connectivity Establishment (ICE) [RFC5245] [RFC6544] 68 is used for NAT traversal, both endpoints gather multiple IP 69 addresses and ports, also called candidate addresses, and test for 70 connectivity between them. One of the principles of ICE is to gather 71 all possible candidate addresses and pair them with all the addresses 72 of the peer in order to test all combinations and get high 73 probability for successful NAT traversal. 75 A prioritization formula is used by ICE so that most preferred 76 address pairs are tested first, and if a sufficiently good pair is 77 discovered, the tests can be stopped. Addresses obtained from local 78 network interfaces, called host candidates, are recommended as high- 79 priority ones to be tested first since if they work, they provide 80 usually the best path between the two hosts. With IPv4 this approach 81 works well since interfaces usually have just a single unicast IP 82 address. However, with IPv6 addressing architecture [RFC4291] 83 interfaces commonly have multiple addresses: global, link-local, 84 Unique Local (ULA) [RFC4193], etc. 86 The ICE specification recommends to use the rules defined in 87 [RFC3484] as part of the prioritization formula for IPv6 candidates, 88 but does not give much further advice on how to handle different kind 89 of IPv6 addresses. However, if all different kind of IPv6 addresses 90 are paired with each other, some of the combinations will never work 91 and may unnecessarily delay the completion of the ICE process. 93 This document updates the ICE rules defined in [RFC5245] and 94 [RFC6544] on how candidate addresses are selected and how they should 95 be combined with each other in order to maintain high performance for 96 the ICE NAT traversal process. 98 2. Terminology 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in RFC 103 2119 [RFC2119]. 105 This document uses the same terminology as ICE (see Section 3 of 106 [RFC5245]) and the following: 108 Local relayed candidate: a relayed candidate (obtained, e.g., from a 109 TURN server) and included in an ICE offer or answer the agent has or 110 will send. 112 3. Changes to Candidate Address Selection 114 This document proposes the following updates to the rules for 115 selecting and combining IPv6 candidate addresses: 117 o Instead of RFC 3484 rules, the rules defined in 118 [I-D.ietf-6man-rfc3484bis] MUST be used for determining the 119 candidate priorities. If operating system address preferences are 120 available (e.g,. via appropriate API extension), those SHOULD be 121 used instead of default preferences. 123 o Deprecated IPv4-compatible IPv6 addresses [RFC4291] and IPv6 site- 124 local unicast addresses [RFC3879] MUST NOT be included in the 125 address candidates. 127 o Candidate addresses from link-local addresses MUST NOT be combined 128 with any other candidates except other link-local candidates. 130 o Candidate addresses from Unique Local Addresses (ULAs) MUST NOT be 131 combined with any other candidates except other ULA candidates. 133 o IPv4-mapped IPv6 addresses MUST NOT be included in the offered 134 candidates unless the application using ICE does not support IPv4 135 (i.e., is an IPv6-only application [RFC4038]). 137 The following updates pertain to both IPv4 and IPv6 addresses: 139 o Addresses from a loopback interface MUST NOT be included in the 140 candidate addresses. 142 o Local relayed candidates MUST NOT be combined with remote host 143 candidates from IPv4 private address space [RFC1918] or IPv6 link- 144 local addresses or ULAs. 146 4. Negotiating Address Selection Scheme 148 The prioritization method for the candidate address pairs used by ICE 149 results in matching checklists for both endpoints and hence both 150 endpoints start the checks for the same candidate pair roughly at the 151 same time. This is important since in many scenarios a connectivity 152 check initiated by both endpoints for the same pair is needed before 153 a check for the pair succeeds. Also, some NAT devices have very 154 short timeouts for their address translation bindings and a binding 155 created by a connectivity check from one endpoint may expire before 156 the corresponding connectivity check from the other endpoint is sent 157 if there is a long delay between the two checks. 159 Depending on how different candidates are paired and whether RFC 3484 160 or the revised version of it [I-D.ietf-6man-rfc3484bis] is used, the 161 endpoints may end up with different priorities and checklists. 162 Therefore, the endpoints need to agree on how the address selection 163 and pairing is done. 165 To indicate that the address selection and pairing rules defined in 166 this document are used, the ICE offerer MUST include ice-options 167 attribute with "bis-candidates" option identifier in the Session 168 Description Protocol (SDP) [RFC4566] ICE offer. If the ICE offer 169 does not include this option tag, the answerer SHOULD NOT utilize the 170 updated rules defined in this document. If the offer included the 171 option tag and the answerer supports this specification, the answerer 172 SHOULD add the same option tag to the response and use the updated 173 rules. 175 If the ICE answer does not contain the option tag, the offerer SHOULD 176 NOT use the updated rules. However, even if the other endpoint does 177 not indicate support for the updated rules, loopback addresses or the 178 deprecated IPv6 addresses SHOULD NOT be included in the candidates. 180 5. Security Considerations 182 The general security considerations for ICE have been documented in 183 Section 18 of [RFC5245] and Section 12 of [RFC6544]. The general 184 security considerations for IPv6 address selection rules have been 185 documented in [I-D.ietf-6man-rfc3484bis]. The vulnerabilities in ICE 186 and RFC3484bis relate to attempts to hijack sessions opened through 187 ICE, denial-of-service attacks, and accidental disclosure of private 188 information. Mechanisms described in [RFC5245] and [RFC6544] - such 189 as validated TCP connections - are designed to protect against 190 connection hijacking. 192 Denial-of-service attacks can not be completely eliminated, but the 193 amplification capabilities of ICE are limited through a maximum value 194 of concurrently probed connections. 196 Any address probing mechanism opens up the possibility of outsiders 197 learning the correlation between different IP addresses. For 198 instance, the existence of a privacy address [RFC4941] in the 199 candidate set along with other, more stable addresses will tell at 200 least the peer and maybe eavesdroppers that the addresses are 201 related. 203 This specification introduces no specific new security concerns 204 beyond these, as it only attempts to unify the algorithms associated 205 with candidate address pair selection. However, where address 206 selection rules in a node are configured through an external 207 mechanism, as suggested in [I-D.ietf-6man-rfc3484bis], this opens up 208 another avenue for introducing incorrect addresses into the probing 209 mechanism. The resulting system is only as secure as its weakest 210 component. For instance, even if sufficient security mechanisms are 211 in place in ICE, vulnerabilities in the configuration mechanisms for 212 the 3484bis priority tables may introduce weaknesses in the ability 213 of ICE to select the right addresses. 215 6. IANA Considerations 217 IANA is requested to register "bis-candidates" option identifier 218 under the "ICE Options" [RFC6336] registry. The required 219 registration information is as follows: 221 Option identifier: bis-candidates 223 Contact: Ari Keranen, ari.keranen@ericsson.com 225 Change control: IETF 227 Description: Existence of this option identifier indicates that 228 the revised rules (defined in RFCXXXX) are used for candidate 229 address selection. 231 Reference: RFCXXXX 233 [RFC editor: replace XXXX with the RFC number of this document] 235 7. References 237 7.1. Normative References 239 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 240 E. Lear, "Address Allocation for Private Internets", 241 BCP 5, RFC 1918, February 1996. 243 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 244 Requirement Levels", BCP 14, RFC 2119, March 1997. 246 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 247 Addresses", RFC 4193, October 2005. 249 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 250 Architecture", RFC 4291, February 2006. 252 [RFC4566] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session 253 Description Protocol", RFC 4566, July 2006. 255 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 256 (ICE): A Protocol for Network Address Translator (NAT) 257 Traversal for Offer/Answer Protocols", RFC 5245, 258 April 2010. 260 [RFC6336] Westerlund, M. and C. Perkins, "IANA Registry for 261 Interactive Connectivity Establishment (ICE) Options", 262 RFC 6336, July 2011. 264 [RFC6544] Rosenberg, J., Keranen, A., Lowekamp, B., and A. Roach, 265 "TCP Candidates with Interactive Connectivity 266 Establishment (ICE)", RFC 6544, March 2012. 268 [I-D.ietf-6man-rfc3484bis] 269 Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 270 "Default Address Selection for Internet Protocol version 6 271 (IPv6)", draft-ietf-6man-rfc3484bis-06 (work in progress), 272 June 2012. 274 7.2. Informative References 276 [RFC3484] Draves, R., "Default Address Selection for Internet 277 Protocol version 6 (IPv6)", RFC 3484, February 2003. 279 [RFC3879] Huitema, C. and B. Carpenter, "Deprecating Site Local 280 Addresses", RFC 3879, September 2004. 282 [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. 283 Castro, "Application Aspects of IPv6 Transition", 284 RFC 4038, March 2005. 286 [RFC4941] Narten, T., Draves, R., and S. Krishnan, "Privacy 287 Extensions for Stateless Address Autoconfiguration in 288 IPv6", RFC 4941, September 2007. 290 Appendix A. Acknowledgments 292 The authors would like to thank Jan Melen, Dan Wing, and Jonathan 293 Lennox for comments, reviews and valuable input to the document. 295 Authors' Addresses 297 Ari Keranen 298 Ericsson 299 Jorvas 02420 300 Finland 302 Email: ari.keranen@ericsson.com 304 Jari Arkko 305 Ericsson 306 Jorvas 02420 307 Finland 309 Email: jari.arkko@piuha.net