idnits 2.17.00 (12 Aug 2021) /tmp/idnits53275/draft-tschofenig-mip6-ice-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1172. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1183. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1190. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1196. 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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (June 27, 2007) is 5442 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3775' is defined on line 1075, but no explicit reference was found in the text == Unused Reference: 'RFC4474' is defined on line 1111, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-monami6-multiplecoa' is defined on line 1115, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-mip4-dsmipv4' is defined on line 1125, but no explicit reference was found in the text == Outdated reference: draft-ietf-mmusic-ice has been published as RFC 5245 ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: draft-ietf-behave-turn has been published as RFC 5766 == Outdated reference: draft-ietf-shim6-failure-detection has been published as RFC 5534 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) == Outdated reference: draft-ietf-behave-rfc3489bis has been published as RFC 5389 == Outdated reference: A later version (-05) exists of draft-wing-behave-nat-control-stun-usage-02 -- Obsolete informational reference (is this intentional?): RFC 4474 (Obsoleted by RFC 8224) == Outdated reference: draft-ietf-monami6-multiplecoa has been published as RFC 5648 == Outdated reference: A later version (-06) exists of draft-ietf-mip6-nemo-v4traversal-04 == Outdated reference: draft-ietf-mip4-dsmipv4 has been published as RFC 5454 == Outdated reference: A later version (-03) exists of draft-bajko-mip6-rrtfw-01 Summary: 3 errors (**), 0 flaws (~~), 15 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIP6 H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track G. Bajko 5 Expires: December 29, 2007 Nokia 6 June 27, 2007 8 Mobile IP Interactive Connectivity Establishment (M-ICE) 9 draft-tschofenig-mip6-ice-00.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on December 29, 2007. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2007). 40 Abstract 42 This document describes how the Interactive Connectivity 43 Establishment (ICE) methodology can be used for Mobile IP to 44 determine whether end-to-end communication is possible. ICE makes 45 use of the Session Traversal Utilities for NAT (STUN) protocol in 46 addition to mechanisms for checking connectivity between peers. 47 After running the ICE the two MIP end points will be able to 48 communicate directly or through a relay via Network Address 49 Translators (NATs), Network Address and Port Translators (NAPTs) and 50 firewalls. 52 This document addresses also the problems raised in RFC 4487 "Mobile 53 IPv6 and Firewalls: Problem Statement". 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 5 59 1.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 5 60 1.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . . 6 61 1.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 6 62 1.5. Security for Checks . . . . . . . . . . . . . . . . . . . 6 63 1.6. Concluding M-ICE . . . . . . . . . . . . . . . . . . . . . 6 64 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 65 3. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 7 66 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 8 67 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 8 68 6. Receipt of the Initial Answer . . . . . . . . . . . . . . . . 9 69 7. Performing Connectivity Checks . . . . . . . . . . . . . . . . 9 70 8. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 9 71 9. Subsequent Offer/Answer Exchanges . . . . . . . . . . . . . . 9 72 10. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 9 73 11. Attribute Encoding . . . . . . . . . . . . . . . . . . . . . . 10 74 12. Demultiplexing MIP and STUN messages . . . . . . . . . . . . . 12 75 13. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 76 14. Security Considerations . . . . . . . . . . . . . . . . . . . 16 77 14.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 16 78 14.2. Attacks on Address Gathering . . . . . . . . . . . . . . . 18 79 14.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 19 80 14.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 19 81 14.4.1. MIP Amplification Attack . . . . . . . . . . . . . . 19 82 14.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 20 83 15. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 20 84 15.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 21 85 15.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 21 86 15.3. Brittleness Introduced by M-ICE . . . . . . . . . . . . . 22 87 15.4. Requirements for a Long Term Solution . . . . . . . . . . 23 88 15.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 23 89 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 23 90 17. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 24 91 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 92 18.1. Normative References . . . . . . . . . . . . . . . . . . . 24 93 18.2. Informative References . . . . . . . . . . . . . . . . . . 24 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 95 Intellectual Property and Copyright Statements . . . . . . . . . . 27 97 1. Introduction 99 In a typical Mobile IP deployment, there are two endpoints, mobile 100 node and correspondent nodes, which want to communicate. They are 101 able to communicate indirectly via a combination of Mobile IP 102 signaling and reverse tunneling. A couple of different extensions 103 are available for Mobile IP that allow multiple care-of addresses, 104 IPv4/IPv6 interworking and different routes to be used through the 105 network. 107 Unfortunately, it is likely that some of the available paths do not 108 work due to connectivity problems caused by firewalling behavior. 109 The VoIP community has investigated these problems extensively and 110 developed a protocols and a methodology to systematically perform 111 connectivity checks in order to determine a working path between the 112 two end points. The Interactive Connectivity Establishment (ICE) 113 specification describes how the Session Traversal Utilities for NAT 114 (STUN) protocol can be used to execute these checks. This document 115 suggests to utilize the ICE methodology and if possible STUN for 116 Mobile IP, both Mobile IPv4 and Mobile IPv6. We call this usage 117 Mobile IP - ICE, M-ICE for short. 119 This document, however, concentrates on Mobile IPv6 as a starting 120 point. A future version of this document will also describe the 121 operation using Mobile IPv4. The ideal outcome is that the best 122 available path through the network can be chosen when Mobile IP is 123 used regardless of the MIP version and the environmental problems 124 the two end points are facing. 126 At the beginning of the M-ICE process, the end points are ignorant of 127 their own topologies. They might or might not be behind a NAT (or 128 multiple tiers of NATs) and might be behind firewalls that limit the 129 ability to communicate in different ways between the end points. 130 M-ICE allows these end points to discover enough information about 131 their topologies to potentially find one or more paths by which they 132 can communicate. 134 Figure 1 shows a typical environment for M-ICE deployment. The two 135 end points are labelled L and R (for left and right, which helps 136 visualize call flows). Both L and R are behind their own respective 137 NATs or firewalls though they may not be aware of it. The type of 138 NAT or firewall and their properties are also unknown. L and R are 139 capable of engaging in an end-to-end mobility protocol exchange. 140 This exchange will occur through mobility anchor points, such as Home 141 Agents. 143 In this architecture the ICE functionality of TURN servers is 144 provided by the Home Agent via reverse tunneling. In this document 145 we assume that the STUN server is co-located with the Home Agent 146 since it is convenient from a security and configuration point of 147 view even though it is, from a solution point of view, not necessary. 149 +--------+ Mobility +--------+ 150 | Home | Signalling | Home | 151 | Agent/ |----------------------------| Agent/ | 152 | STUN | | STUN | 153 | Server | | Server | 154 +--------+ +--------+ 155 ^ ^ 156 | | 157 | | 158 Mobility | |Mobility 159 Signalling| |Signalling 160 | | 161 | | 162 +---v----+ +---v----+ 163 | FW/NAT | | FW/NAT | 164 +---^----+ +---^----+ 165 | | 166 | | 167 v v 168 +--------+ +--------+ 169 | Agent | | Agent | 170 | L | | R | 171 +--------+ +--------+ 173 Figure 1: Overview 175 The basic idea behind M-ICE is as follows: each end point has a 176 variety of candidate TRANSPORT ADDRESSES (combination of IP address, 177 transport protocol (UDP), and port) it could use to communicate with 178 the other end point. 180 To avoid unnecessary UDP encapsulation of end-to-end traffic in 181 case there is no need todo so, it is also possible to consider 182 using IP addresses rather than focusing exclusively on TRANSPORT 183 ADDRESSES. For example, two MIP hosts behind the same NAT do not 184 need to use UDP encapsulation. If there is no NAT or firewall 185 between the two communicating nodes then there is again no need to 186 provide support for UDP encapsulation. A future version of this 187 document will provide support for this functionality. 189 Potentially, any of L's candidate transport addresses can be used to 190 communicate with any of R's candidate transport addresses. In 191 practice, however, many combinations do not work. For instance, if L 192 and R are both behind NATs, their directly attached interface 193 addresses (e.g., 192.168.1.100) are unlikely to be able to 194 communicate. The purpose of M-ICE is to discover which pairs of 195 addresses will work. The way that M-ICE does this is to 196 systematically try all possible pairs (in a carefully sorted order) 197 until it finds one or more that works. Once found, the best pair is 198 used for subsequent communication between the hosts. 200 1.1. Gathering Candidate Addresses 202 In order to execute ICE, an agent has to identify all of its address 203 candidates. A CANDIDATE is a transport address - a combination of IP 204 address and port for a particular transport protocol. 206 This document uses three types of candidates: 208 1. One viable candidate is a transport address obtained directly 209 from a local interface. Such a candidate is called a HOST 210 CANDIDATE. 211 2. Translated addresses on the public side of a NAT (called SERVER 212 REFLEXIVE CANDIDATES). This address is obtained via STUN. 213 3. Addresses obtained via relaying traffic through a Home Agent, 214 called RELAYED CANDIDATES. 216 1.2. Connectivity Checks 218 Once L has gathered all of its candidates, it orders them in highest 219 to lowest priority and sends them to R over the signalling channel. 220 We refer to the signaling channel to the end-to-end MIP exchange. 221 The extension to exchange candidates can be found in Section 11. 223 When R receives the L's MIP message, R performs the same candidate 224 gathering process and responds with its own list of candidates. At 225 the end of this process, each agent has a complete list of both its 226 candidates and its peer's candidates. It pairs them up, resulting in 227 CANDIDATE PAIRS. To see which pairs work, each agent schedules a 228 series of connectivity CHECKS. Each check is a STUN transaction that 229 the client will perform on a particular candidate pair by sending a 230 STUN request from the local candidate to the remote candidate; a 231 response indicates there is connectivity to the peer using that 232 candidate address. 234 It is important to note that the STUN requests are sent to and from 235 the exact same IP addresses and ports that will be used for 236 subsequent data traffic. 238 1.3. Sorting Candidates 240 Because the algorithm above searches all candidate pairs, if a 241 working pair exists it will eventually find it no matter what order 242 the candidates are tried in. In order to produce faster (and better) 243 results, the candidates are sorted in a specified order. The 244 resulting list of sorted candidate pairs is called the CHECK LIST. 246 1.4. Frozen Candidates 248 The concept of frozen candidates is not applied when ICE is applied 249 to MIP. [Editor's Note: More investigations are needed to evaluate 250 whether this is indeed true and the concept of frozen candidates can 251 be ignored.] 253 1.5. Security for Checks 255 Because the ICE algorithm is used to discover which addresses can be 256 used to send traffic between two end points, it is important to 257 ensure that the process cannot be hijacked to send traffic to the 258 wrong location. Each STUN connectivity check is covered by a message 259 authentication code (MAC). There are two ways to generate the keying 260 material for this MAC. Either keying material is derived from the 261 keying material generated by the return routability procedure or new 262 keying material is distributed separately as excercised in ICE. 263 This document currently uses the latter technique without a strong 264 preference. 265 In any case, this MAC provides message integrity and data origin 266 authentication, thus stopping an attacker from forging or modifying 267 connectivity check messages. 269 1.6. Concluding M-ICE 271 ICE checks are performed in a specific sequence, so that high 272 priority candidate pairs are checked first, followed by lower 273 priority ones. 275 2. Terminology 277 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 278 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 279 document are to be interpreted as described in RFC 2119 [RFC2119]. 281 This document heavily relies on the terminology introduced in 282 [I-D.ietf-mmusic-ice]. 284 3. Design Choices 286 The work in this document is guided by the following design choices, 287 namely: 289 o The offer/answer exchange described in ICE [I-D.ietf-mmusic-ice] 290 is mapped to the end-to-end MIP signaling exchange. For end-to- 291 end communication this document assumes that MIPv6 signaling are 292 allowed to be exchanged between the mobile node and the 293 correspondent node. When Network Address Translators and 294 firewalls are located along the path then direct end-to-end 295 communication between the two end points is typically not possible 296 and hence this protocol interaction is provided via MIP Home 297 Agents. The functionality described in [I-D.bajko-mip6-rrtfw] is 298 used. 299 o We assume that MIP initiators and MIP responders implement and use 300 STUN. For performing connectivity checks a couple of other 301 alternatives are, however, possible: 303 It would be possible to utilize the SHIM6 REAchability Protocol 304 (REAP) [I-D.ietf-shim6-failure-detection] but STUN provides the 305 same support with a more likely chance for widespread 306 deployment. REAP currently only provides IPv6 support. It it 307 obviously possible to turn a protocol in any other one. 308 Custom MIP messages could be created. 310 o If one peer does not support STUN then the optimal results of 311 M-ICE cannot be provided. There is, however, the ability to make 312 use of STUN LITE when a host is on the public address space and 313 known not to be behind a firewall. 314 o Obtaining Relay Addresses from STUN [I-D.ietf-behave-turn], 315 formerly known as TURN, is intentionally not used in this 316 document. For MIP, the Home Agent tunneling functionality is used 317 instead of TURN. 318 o This document makes use of the UDP-encapsulated of MIP packets, as 319 specified in [I-D.ietf-mip6-nemo-v4traversal]. 320 o This document focuses only on the data exchange between the two 321 end points rather than on the communication between a mobile node 322 and the Home Agent or on the ability to allow MIP signaling 323 messages to traverse NATs and firewalls. 324 o Each STUN connectivity check is covered by a message 325 authentication code (MAC) generated based on keying material 326 derived from information carried in MIP messages, see Section 11. 327 Alternatively, keying material could be derived from the return 328 routability test procedure. 330 Note that the ICE description assumes usage within a VoIP environment 331 where individual flows are controlled. However, the protocol 332 interaction described in this document operates at a lower layer 333 where application specific message flows are not visible. When a 334 CANDIDATE PAIR, consisting of two TRANSPORT ADDRESSES, is created 335 then it will typically refer to multiple flows then traffic between 336 two end points experiences UDP encapsulation (due to the need to 337 traverse a NAT or a stateful packet filtering firewall). 339 The descriptions in the ICE specification related to SIP, ANAT, RTP, 340 RTCP, third party call control, preconditions, forking, etc. are not 341 applicable to MIP and are not included in this document. 343 From an editorial point of view it would be possible to copy-and- 344 paste relevant parts of the ICE specification and to remove VoIP 345 specific descriptions but for this version of the document we did 346 not follow this approach. 348 The main accomplishment of this document is the reuse of the well- 349 established ICE specification that builds on STUN. STUN enjoys 350 widespread implementation support and maximum code re-use was one of 351 the design criteria for this document. 353 4. Sending the Initial Offer 355 In order to send the initial offer in an offer/answer exchange, an 356 agent must (1) gather candidates, (2) prioritize them, (3) choose 357 default candidates, and then (4) formulate and send them to the other 358 peer. 360 Section 4 of ICE [I-D.ietf-mmusic-ice] is applicable to this document 361 with the following two exceptions: First, TURN is not used in this 362 document but instead similar functionality is accomplished via a Home 363 Agent. Second, the description regarding encoding of candidates in 364 SDP is not applicable and replaced by a MIP specific encoding 365 described in Section 11. 367 5. Receiving the Initial Offer 369 When an agent receives an initial offer, it will check if the offerer 370 supports sufficient ICE functionality to proceed (i.e., if both 371 offerer and answerer are lite implementations, ICE cannot proceed), 372 determine its own role, gather candidates, prioritize them, choose 373 default candidates, encode and send an answer, and for full 374 implementations, form the check lists and begin connectivity checks. 376 Again, the description regarding encoding of candidates in SDP is not 377 applicable to this document and is replaced by a MIP specific 378 encoding described in Section 11. Note that only the encoding is 379 different but not the semantic. As such, the description in Section 380 5 of [I-D.ietf-mmusic-ice] is applicable to this document. 382 6. Receipt of the Initial Answer 384 Section 6 of ICE [I-D.ietf-mmusic-ice] describes the procedures that 385 an agent follows when it receives the answer from the peer. It 386 verifies that its peer supports ICE, determines its role, and for 387 full implementations, forms the check list and begins performing 388 periodic checks. 390 7. Performing Connectivity Checks 392 Section 7 of ICE [I-D.ietf-mmusic-ice] describes how connectivity 393 checks are performed using STUN [I-D.ietf-behave-rfc3489bis] and the 394 content of that section is fully applicable to this document. 396 8. Concluding ICE Processing 398 The description in Section 8 of ICE [I-D.ietf-mmusic-ice] illustrates 399 processing rules that apply only to full implementations. Concluding 400 ICE involves nominating pairs by the controlling agent and updating 401 of state machinery 403 9. Subsequent Offer/Answer Exchanges 405 Either agent may generate a subsequent offer at any time. The rules 406 in Section 9 of ICE [I-D.ietf-mmusic-ice] will cause the controlling 407 agent to send an updated offer at the conclusion of ICE processing 408 when ICE has selected different candidate pairs from the default 409 pairs. Section 9 of ICE [I-D.ietf-mmusic-ice] defines rules for 410 construction of subsequent offers and answers. 412 Note that the term "media stream" in Section 9 of ICE 413 [I-D.ietf-mmusic-ice] translates to an individual UDP-encapsulated 414 data flow exchanged between the two MIP end points. 416 10. Keepalives 418 Section 10 of ICE [I-D.ietf-mmusic-ice] describes a keepalive 419 mechanism. The RTP description, such as RTP No-Op and RTP comfort 420 noise, is not applicable to this document. Other useful keepalive 421 techniques are described in [I-D.marjou-behave-app-rtp-keepalive] and 422 may be useful for MIP; a recommendation will be made in a subsequent 423 version of this document. 425 11. Attribute Encoding 427 To accomplish the same functionality this specification needs to 428 reuse the semantic, but not necessarily the encoding, of seven 429 attributes defined in the ICE specification [I-D.ietf-mmusic-ice], 430 namely "candidate", "remote-candidates", "ice-lite", "ice-mismatch", 431 "ice-ufrag", "ice-pwd" and "ice-options". 433 Section 15.1 to Section 15.5 of ICE [I-D.ietf-mmusic-ice] describe 434 the semantic of the attributes. 436 MIP-ICE Mobility Options Format: 438 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 439 | Type | Header Len |# of candidates| 440 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 441 | Checksum |L|M| Reserved | 442 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 443 | | 444 + + 445 | Ice-pwd | 446 + + 447 | | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | ice-ufrag | ice-options (var) ... 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 . . 454 . Candidate 1 . 455 . . 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 . . 458 . Candidate 2 . 459 . . 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 . . 462 . Candidate n . 463 . . 464 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 Where L: ice-lite 467 M: ice-mismatch 468 # of candidates: the number of candidates carried by this option 470 Ice-options: 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 473 | Length | Data ... 475 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 477 Candidate: 479 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 480 | ver | Length | type | comp-id | 481 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 482 | transport | Reserved | 483 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 484 | Priority | 485 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 486 . . 487 . Connection-address . 488 | | 489 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 | port | rel-port | 491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 492 . . 493 . Rel-address . 494 | | 495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 497 The fields have the following meaning: 499 ver: IP address version contained in Connection-address and 500 Rel-address fields 502 type: cand-type as defined in ICE 504 comp-id: component-id as defined in ICE 506 transport: transport address 508 priority: sender priority assigned to the connection-address, as 509 defined in ICE 511 connection-address: IP address, 32 bit if ver=4 and 128 bit if 512 ver=6 514 port: port number 516 rel-port: port number, as defined in ICE 518 rel-address: IP address, as defined in ICE 520 Figure 2: Attribute Encoding 522 12. Demultiplexing MIP and STUN messages 524 When MIP and STUN messages are run over the same port it is necessary 525 to demultiplex them. For this usage it is necessary to have a 526 FINGERPRINT attribute in place, as defined in 527 [I-D.ietf-behave-rfc3489bis]. 529 A STUN packet always has the fixed value 0x2112A442 in its Magic 530 Cookie field (bits 32-64 from the beginning of the UDP payload). 532 0 1 2 3 533 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 535 |0 0| STUN Message Type | Message Length | 536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 537 |0 0 1 0 0 0 0 1 0 0 0 1 0 0 1 0 1 0 1 0 0 1 0 0 0 1 0 0 0 0 1 0| 538 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 539 . . . 541 Figure 3: STUN Header 543 In this same offset from the UDP header, the MIP header has the 544 Checksum field and the start of the Message Data field. The 545 concatenation of the Checksum field and the first 16 bits of the 546 Message Data field may coincide with the STUN Magic Cookie. 548 0 1 2 3 549 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 | Payload Proto | Header Len | MH Type | Reserved | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 | Checksum | | 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 555 | | 556 . . 557 . Message Data . 558 . . 559 | | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 0 1 2 3 562 . . . 564 Figure 4: MIP Header 566 When the value in that place equals the value of the STUN Magic 567 Cookie, the presence of the STUN FINGERPRINT attribute tells 568 unambigously whether this is a STUN message or not. 570 A future version will also discuss the demultiplexing when UDP 571 encapsulation is not used. 573 13. Example 575 The subsequent example shows a minimal message. For editorial 576 reasons middleboxes, such as NATs and firewalls along the path 577 between L and R are not depicted. 579 L STUN R 580 _______|_______ | | 581 | (1) gather | | | 582 | candidates | | | 583 --------------- | | 584 | (2) HoTI | | 585 |---------------------------->| 586 | (3) CoTI (candidates) | 587 |---------------------------->| 588 | | | 589 | | ______|________ 590 | | | (4) gather | 591 | | | candidates | 592 | | --------------- 593 |(5) HoT | | 594 |<----------------------------| 595 | (6) CoT (Candidates) | 596 |<----------------------------| 597 |(7) Bind Req | | 598 |S=$L-CoA-1 | | 599 |D=$R-CoA | | 600 |USE-CAND | | 601 |---------------------------->| 602 |(8) Bind Res | | 603 |S=$R-CoA | | 604 |D=$L-CoA-1 | | 605 |<----------------------------| 606 |data flows | | 607 | | | 608 |(9) Bind Req | | 609 |S=$R-CoA | | 610 |D=$L-CoA-1 | | 611 |<----------------------------| 612 | | | 613 | | | 614 |(10) Bind Res | | 615 |S=$L-CoA-1 | | 616 |D=$R-CoA | | 617 |---------------------------->| 618 | | |data flows 620 Figure 5: Example Message Flow 622 Lets assume two agents, L and R, where L is a mobile nodes with one 623 CoA and one HoA, and R is a node. L starts with gathering its host 624 (CoA) and server relayed (HoA) candidates. Agent L sets a type 625 preference of 126 for the host candidate and 100 for the server 626 relayed. The local preference is 65535. Based on this, the priority 627 for the host candidate is 2130706178 and for the server relayed 628 candidate is 1694498562. It chooses its host candidate as the 629 default candidate and encodes the candidates into the MIP signalling 630 messages. 632 The candidate is received at agent R. Agent R will also start 633 gathering its own candidates, but it only has one host candidate. 634 Type and local preferences are assigned by R in the same way as L, 635 and the priority for the candidate will have the same value as L's 636 host candidate. R also chooses its host candidate as the default 637 candidate and encodes the candidates into the MIP signalling 638 messages. 640 Since neither side indicated that they are lite, the agent which 641 initiated the signalling that began ICE processing (agent L) becomes 642 the controlling agent. 644 Agents L and R both pair up the candidates. They both have two pairs 645 with the pair priorities 4.57566E+18 and 3.63891E+18, respectively. 647 Agent R begins its connectivity check for the first pair (between the 648 two host candidates). Since R is the controlled agent for this 649 session, the check omits the USE-CANDIDATE attribute. 651 When agent L gets the answer, it performs a connectivity check. It 652 implements the aggressive nomination algorithm, and thus includes a 653 USE-CANDIDATE attribute in this check. Since the check succeeds, 654 agent L creates a new pair and is added to the valid list. In 655 addition, it is marked as selected since the Binding Request 656 contained the USE-CANDIDATE attribute. Since there is a selected 657 candidate in the Valid list for the one component of this media 658 stream, ICE processing for this stream moves into the Completed 659 state. Agent L can now send media if it so chooses. 661 If agent R is behind a firewall, then the Binding Request from agent 662 L will be dropped. The ICE draft recommends that agents send STUN 663 request for the candidate pairs every 20ms. Thus, for instance if 664 the first Binding Request will be dropped, then next one will 665 succeed, as agent R also sends a Binding Request using the same 5 666 tuple selectors and open the pinhole in the firewall. 668 Upon receipt of the STUN Binding Request from agent L, agent R will 669 generate its triggered check, from its host candidate to agent L's 670 host candidate. This check will succeed. Consequently, agent R 671 constructs a new candidate pair using the host address from the 672 response as the local candidate and the destination of the request 673 L-CoA-1 as the remote candidate. This pair is added to the Valid 674 list for that media stream. Since the check was generated in the 675 reverse direction of a check that contained the USE-CANDIDATE 676 attribute, the candidate pair is marked as selected. Consequently, 677 processing for this stream moves into the Completed state, and agent 678 R can also send media. 680 14. Security Considerations 682 There are several types of attacks possible in an M-ICE system. This 683 section considers these attacks and their countermeasures. 685 14.1. Attacks on Connectivity Checks 687 An attacker might attempt to disrupt the STUN connectivity checks. 688 Ultimately, all of these attacks fool an agent into thinking 689 something incorrect about the results of the connectivity checks. 690 The possible false conclusions an attacker can try and cause are: 692 False Invalid: 694 An attacker can fool a pair of agents into thinking a candidate 695 pair is invalid, when it isn't. This can be used to cause an 696 agent to prefer a different candidate (such as one injected by the 697 attacker), or to disrupt a call by forcing all candidates to fail. 699 False Valid: 701 An attacker can fool a pair of agents into thinking a candidate 702 pair is valid, when it isn't. This can cause an agent to proceed 703 with a session, but then not be able to receive any data traffic. 705 False Peer-Reflexive Candidate: 707 An attacker can cause an agent to discover a new peer reflexive 708 candidate, when it shouldn't have. This can be used to redirect 709 data traffic to a DoS target or to the attacker, for eavesdropping 710 or other purposes. 712 False Valid on False Candidate: 714 An attacker has already convinced an agent that there is a 715 candidate with an address that doesn't actually route to that 716 agent (for example, by injecting a false peer reflexive candidate 717 or false server reflexive candidate). It must then launch an 718 attack that forces the agents to believe that this candidate is 719 valid. 721 Of the various techniques for creating faked STUN messages described 722 in [I-D.ietf-behave-rfc3489bis], many are not applicable for the 723 connectivity checks. Compromises of STUN servers are not much of a 724 concern, since the STUN servers are embedded in endpoints and 725 distributed throughout the network. Thus, compromising the peer's 726 embedded STUN server is equivalent to compromising the end point, and 727 if that happens, far more problematic attacks are possible than those 728 against ICE. 730 Injection of fake responses and relaying modified requests all can be 731 handled in ICE with the countermeasures discussed below. 733 To force the false invalid result, the attacker has to wait for the 734 connectivity check from one of the agents to be sent. When it is, 735 the attacker needs to inject a fake response with an unrecoverable 736 error response, such as a 600. However, since the candidate is, in 737 fact, valid, the original request may reach the peer agent, and 738 result in a success response. The attacker needs to force this 739 packet or its response to be dropped, through a DoS attack, layer 2 740 network disruption, or other technique. If it doesn't do this, the 741 success response will also reach the originator, alerting it to a 742 possible attack. Fortunately, this attack is mitigated completely 743 through the STUN message integrity mechanism. The attacker needs to 744 inject a fake response, and in order for this response to be 745 processed, the attacker needs the password. If the candidates are 746 exchange in MIP messages and therefore secured, the attacker will not 747 have the password. 749 Forcing the fake valid result works in a similar way. The agent 750 needs to wait for the Binding Request from each agent, and inject a 751 fake success response. The attacker won't need to worry about 752 disrupting the actual response since, if the candidate is not valid, 753 it presumably wouldn't be received anyway. However, like the fake 754 invalid attack, this attack is mitigated completely through the STUN 755 message integrity and offer/answer security techniques. 757 Forcing the false peer reflexive candidate result can be done either 758 with fake requests or responses, or with replays. We consider the 759 fake requests and responses case first. It requires the attacker to 760 send a Binding Request to one agent with a source IP address and port 761 for the false candidate. In addition, the attacker must wait for a 762 Binding Request from the other agent, and generate a fake response 763 with a XOR-MAPPED-ADDRESS attribute containing the false candidate. 764 Like the other attacks described here, this attack is mitigated by 765 the STUN message integrity mechanisms and secure offer/answer 766 exchanges. 768 Forcing the false peer reflexive candidate result with packet replays 769 is different. The attacker waits until one of the agents sends a 770 check. It intercepts this request, and replays it towards the other 771 agent with a faked source IP address. It must also prevent the 772 original request from reaching the remote agent, either by launching 773 a DoS attack to cause the packet to be dropped, or forcing it to be 774 dropped using layer 2 mechanisms. The replayed packet is received at 775 the other agent, and accepted, since the integrity check passes (the 776 integrity check cannot and does not cover the source IP address and 777 port). It is then responded to. This response will contain a XOR- 778 MAPPED-ADDRESS with the false candidate, and will be sent to that 779 false candidate. The attacker must then receive it and relay it 780 towards the originator. 782 The other agent will then initiate a connectivity check towards that 783 false candidate. This validation needs to succeed. This requires 784 the attacker to force a false valid on a false candidate. Injecting 785 of fake requests or responses to achieve this goal is prevented using 786 the integrity mechanisms of STUN and the offer/answer exchange. 787 Thus, this attack can only be launched through replays. To do that, 788 the attacker must intercept the check towards this false candidate, 789 and replay it towards the other agent. Then, it must intercept the 790 response and replay that back as well. 792 This attack is very hard to launch unless the attacker is identified 793 by the fake candidate. This is because it requires the attacker to 794 intercept and replay packets sent by two different hosts. If both 795 agents are on different networks (for example, across the public 796 Internet), this attack can be hard to coordinate, since it needs to 797 occur against two different endpoints on different parts of the 798 network at the same time. 800 If the attacker them self is identified by the fake candidate the 801 attack is easier to coordinate. However, since MIP utilizes IPsec 802 ESP to protect the data traffic end-to-end, the attacker will not be 803 able to inspect any application data, they will only be able to 804 discard them. However, this attack requires the agent to disrupt 805 packets in order to block the connectivity check from reaching the 806 target. In that case, if the goal is to disrupt the end-to-end 807 communication, its much easier to just disrupt it with the same 808 mechanism, rather than attack ICE. 810 14.2. Attacks on Address Gathering 812 ICE endpoints make use of STUN for gathering candidates from a STUN 813 server in the network. This is corresponds to the Binding Discovery 814 usage of STUN described in [I-D.ietf-behave-rfc3489bis]. As a 815 consequence, the attacks against STUN itself that are described in 816 that specification can still be used against the binding discovery 817 usage when utilized with ICE. 819 However, the additional mechanisms provided by ICE actually 820 counteract such attacks, making binding discovery with STUN more 821 secure when combined with ICE. 823 Consider an attacker which is able to provide an agent with a faked 824 mapped address in a STUN Binding Request that is used for address 825 gathering. This is the primary attack primitive described in 826 [I-D.ietf-behave-rfc3489bis]. This address will be used as a server 827 reflexive candidate in the ICE exchange. For this candidate to 828 actually be used for media, the attacker must also attack the 829 connectivity checks, and in particular, force a false valid on a 830 false candidate. This attack is very hard to launch if the false 831 address identifies a fourth party (neither the offerer, answerer, or 832 attacker), since it requires attacking the checks generated by each 833 agent in the session. 835 If the attacker elects not to attack the connectivity checks, the 836 worst it can do is prevent the server reflexive candidate from being 837 used. However, if the peer agent has at least one candidate that is 838 reachable by the agent under attack, the STUN connectivity checks 839 themselves will provide a peer reflexive candidate that can be used 840 for the exchange of media. Peer reflexive candidates are generally 841 preferred over server reflexive candidates. As such, an attack 842 solely on the STUN address gathering will normally have no impact on 843 a session at all. 845 14.3. Attacks on the Offer/Answer Exchanges 847 An attacker that can modify or disrupt the offer/answer exchanges 848 themselves can readily launch a variety of attacks with M-ICE. They 849 could direct data traffic to a target of a DoS attack, they could 850 insert themselves into the data exchange, and so on. The security 851 considerations of MIP apply. 853 14.4. Insider Attacks 855 In addition to attacks where the attacker is a third party trying to 856 insert fake offers, answers or STUN messages, there are several 857 attacks possible with ICE when the attacker is an authenticated and 858 valid participant in the M-ICE exchange. 860 14.4.1. MIP Amplification Attack 862 In this attack, the attacker initiates communication to other agents, 863 and maliciously includes the IP address and port of a DoS target as 864 the destination for data traffic signaled in the MIP exchange. 866 This could causes substantial amplification; a single offer/answer 867 exchange can create a continuing flood of data packets, possibly at 868 high rates (consider video sources). This attack is not specific to 869 ICE, but ICE can help provide remediation. 871 Specifically, if ICE is used, the agent receiving the malicious SDP 872 will first perform connectivity checks to the target of media before 873 sending media there. If this target is a third party host, the 874 checks will not succeed, and media is never sent. 876 Unfortunately, ICE doesn't help if its not used, in which case an 877 attacker could simply send the offer without the ICE parameters. 878 However, in environments where the set of clients are known, and 879 limited to ones that support ICE, the server can reject any offers or 880 answers that don't indicate ICE support. 882 14.4.2. STUN Amplification Attack 884 The STUN amplification attack is similar to the MIP amplification 885 attack. However, instead of data packets being directed to the 886 target, STUN connectivity checks are directed to the target. The 887 attacker sends an offer with a large number of candidates, say 50. 888 The answerer receives the offer, and starts its checks, which are 889 directed at the target, and consequently, never generate a response. 890 The answerer will start a new connectivity check every 20ms, and each 891 check is a STUN transaction consisting of 7 transmissions of a 892 message 65 bytes in length (plus 28 bytes for the IP/UDP header) that 893 runs for 7.9 seconds, for a total of 58 bytes/second per transaction 894 on average. In the worst case, there can be 395 transactions in 895 progress at once (7.9 seconds divided by 20ms), for a total of 182 896 kbps, just for STUN requests. 898 It is impossible to eliminate the amplification, but the volume can 899 be reduced through a variety of heuristics. Agents SHOULD limit the 900 total number of connectivity checks they perform to 100. 901 Additionally, agents MAY limit the number of candidates they'll 902 accept in an offer or answer. 904 15. IAB Considerations 906 The IAB has studied the problem of "Unilateral Self Address Fixing", 907 which is the general process by which a agent attempts to determine 908 its address in another realm on the other side of a NAT through a 909 collaborative protocol reflection mechanism [RFC3424]. M-ICE is an 910 example of a protocol that performs this type of function. 911 Interestingly, the process for M-ICE is not unilateral, but 912 bilateral, and the difference has a significant impact on the issues 913 raised by IAB. M-ICE can be considered a B-SAF (Bilateral Self- 914 Address Fixing) protocol, rather than an UNSAF protocol. Regardless, 915 the IAB has mandated that any protocols developed for this purpose 916 document a specific set of considerations. This section meets those 917 requirements. 919 15.1. Problem Definition 921 From RFC 3424 [RFC3424] any UNSAF proposal must provide: 923 Precise definition of a specific, limited-scope problem that is to be 924 solved with the UNSAF proposal. A short term fix should not be 925 generalized to solve other problems; this is why "short term fixes 926 usually aren't". 928 The specific problems being solved by M-ICE are: 930 Provide a means for two peers to determine the set of transport 931 addresses which can be used for communication. 933 Provide a means for resolving many of the limitations of other UNSAF 934 mechanisms by wrapping them in an additional layer of processing (the 935 M-ICE methodology). 937 Provide a means for a agent to determine an address that is reachable 938 by another peer with which it wishes to communicate. 940 15.2. Exit Strategy 942 From RFC 3424, any UNSAF proposal must provide: 944 Description of an exit strategy/transition plan. The better short 945 term fixes are the ones that will naturally see less and less use as 946 the appropriate technology is deployed. 948 M-ICE itself doesn't easily get phased out. However, it is useful 949 even in a globally connected Internet, to serve as a means for 950 detecting whether communication paths are disrupted. M-ICE also 951 helps prevent certain security attacks which have nothing to do with 952 NAT. However, what M-ICE does is help phase out other UNSAF 953 mechanisms. M-ICE effectively selects amongst those mechanisms, 954 prioritizing ones that are better, and deprioritizing ones that are 955 worse. Local IPv6 addresses can be preferred. As NATs begin to 956 dissipate as IPv6 is introduced, server reflexive and relayed 957 candidates (both forms of UNSAF mechanisms) simply never get used, 958 because higher priority connectivity exists to the native host 959 candidates. Therefore, the servers get used less and less, and can 960 eventually be remove when their usage goes to zero. 962 Indeed, M-ICE can assist in the transition from IPv4 to IPv6. It can 963 be used to determine whether to use IPv6 or IPv4 when two dual-stack 964 hosts communicate. It can also allow a network with both 6to4 and 965 native v6 connectivity to determine which address to use when 966 communicating with a peer. 968 15.3. Brittleness Introduced by M-ICE 970 From RFC3424, any UNSAF proposal must provide: 972 Discussion of specific issues that may render systems more "brittle". 973 For example, approaches that involve using data at multiple network 974 layers create more dependencies, increase debugging challenges, and 975 make it harder to transition. 977 M-ICE uses ICE that is utilizes [I-D.ietf-behave-rfc3489bis] instead 978 of traditional STUN, RFC 3489 [RFC3489]). RFC 3489 has several 979 points of brittleness. One of them is the discovery process which 980 requires a agent to try and classify the type of NAT it is behind. 981 This process is error-prone. With M-ICE, that discovery process is 982 simply not used. Rather than unilaterally assessing the validity of 983 the address, its validity is dynamically determined by measuring 984 connectivity to a peer. The process of determining connectivity is 985 very robust. 987 Another point of brittleness in traditional STUN is that it assumes 988 that the STUN server is on the public Internet. Interestingly, with 989 M-ICE, that is not necessary. There can be a multitude of STUN 990 servers in a variety of address realms. ICE will discover the one 991 that has provided a usable address. 993 The most troubling point of brittleness in traditional STUN is that 994 it does not work in all network topologies. In cases where there is 995 a shared NAT between each agent and the STUN server, traditional STUN 996 may not work. With ICE, that restriction is removed. 998 Traditional STUN also introduces some security considerations. 999 Fortunately, those security considerations are also mitigated by ICE. 1001 Consequently, ICE serves to repair the brittleness introduced in 1002 other UNSAF mechanisms, and does not introduce any additional 1003 brittleness into the system. 1005 With M-ICE Home Agents are used and they are assumed to be located on 1006 the public Internet to allow MIP to work. 1008 15.4. Requirements for a Long Term Solution 1010 From RFC 3424, any UNSAF proposal must provide: 1012 Identify requirements for longer term, sound technical solutions -- 1013 contribute to the process of finding the right longer term solution. 1015 M-ICE provides a long term solution by utilizing ICE concepts that 1016 have received a lot of peer review in the VoIP community and to apply 1017 them to MIP. The only other possible long term solutions are (a) to 1018 get rid of middleboxes, such as NATs and firewalls or to (b) interact 1019 with them. Regarding (b) extensions for STUN to allow the protocol 1020 to be deployed on NATs and firewalls is currently being investigated 1021 in [I-D.wing-behave-nat-control-stun-usage]. 1023 15.5. Issues with Existing NAPT Boxes 1025 From RFC 3424, any UNSAF proposal must provide: 1027 Discussion of the impact of the noted practical issues with existing, 1028 deployed NA[P]Ts and experience reports. 1030 A number of NAT boxes are now being deployed into the market which 1031 try and provide "generic" ALG functionality. These generic ALGs hunt 1032 for IP addresses, either in text or binary form within a packet, and 1033 rewrite them if they match a binding. This interferes with 1034 traditional STUN. However, the update to STUN 1035 [I-D.ietf-behave-rfc3489bis] uses an encoding which hides these 1036 binary addresses from generic ALGs. 1038 Existing NAPT boxes have non-deterministic and typically short 1039 expiration times for UDP-based bindings. This requires 1040 implementations to send periodic keepalives to maintain those 1041 bindings. ICE uses a default of 15s, which is a very conservative 1042 estimate. Eventually, over time, as NAT boxes become compliant to 1043 behave [RFC4787], this minimum keepalive will become deterministic 1044 and well-known, and the ICE timers can be adjusted. Having a way to 1045 discover and control the minimum keepalive interval would be far 1046 better still. 1048 16. Contributors 1050 We would like to thank Thomas Schreck for his contributions to 1051 various aspects in this document. 1053 17. Acknowledgments 1055 The authors would like to thank Jonathan Rosenberg for his work on 1056 the ICE specification. This document copy-and-pastes text from the 1057 ICE specification. Hence, all the credits go to Jonathan. 1059 Finally, Dan Wing and Philip Matthews helped us with the work on HIP- 1060 ICE. 1062 18. References 1064 18.1. Normative References 1066 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1067 Requirement Levels", March 1997. 1069 [I-D.ietf-mmusic-ice] 1070 Rosenberg, J., "Interactive Connectivity Establishment 1071 (ICE): A Protocol for Network Address Translator (NAT) 1072 Traversal for Offer/Answer Protocols", 1073 draft-ietf-mmusic-ice-16 (work in progress), June 2007. 1075 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1076 in IPv6", RFC 3775, June 2004. 1078 18.2. Informative References 1080 [I-D.ietf-behave-turn] 1081 Rosenberg, J., "Obtaining Relay Addresses from Simple 1082 Traversal Underneath NAT (STUN)", 1083 draft-ietf-behave-turn-03 (work in progress), March 2007. 1085 [I-D.ietf-shim6-failure-detection] 1086 Arkko, J. and I. Beijnum, "Failure Detection and Locator 1087 Pair Exploration Protocol for IPv6 Multihoming", 1088 draft-ietf-shim6-failure-detection-08 (work in progress), 1089 June 2007. 1091 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1092 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1093 Through Network Address Translators (NATs)", RFC 3489, 1094 March 2003. 1096 [I-D.ietf-behave-rfc3489bis] 1097 Rosenberg, J., "Session Traversal Utilities for (NAT) 1098 (STUN)", draft-ietf-behave-rfc3489bis-06 (work in 1099 progress), March 2007. 1101 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1102 Self-Address Fixing (UNSAF) Across Network Address 1103 Translation", RFC 3424, November 2002. 1105 [I-D.wing-behave-nat-control-stun-usage] 1106 Wing, D. and J. Rosenberg, "Discovering, Querying, and 1107 Controlling Firewalls and NATs using STUN", 1108 draft-wing-behave-nat-control-stun-usage-02 (work in 1109 progress), June 2007. 1111 [RFC4474] Peterson, J. and C. Jennings, "Enhancements for 1112 Authenticated Identity Management in the Session 1113 Initiation Protocol (SIP)", RFC 4474, August 2006. 1115 [I-D.ietf-monami6-multiplecoa] 1116 Wakikawa, R., "Multiple Care-of Addresses Registration", 1117 draft-ietf-monami6-multiplecoa-02 (work in progress), 1118 March 2007. 1120 [I-D.ietf-mip6-nemo-v4traversal] 1121 Soliman, H., "Mobile IPv6 support for dual stack Hosts and 1122 Routers (DSMIPv6)", draft-ietf-mip6-nemo-v4traversal-04 1123 (work in progress), March 2007. 1125 [I-D.ietf-mip4-dsmipv4] 1126 Tsirtsis, G., "Dual Stack Mobile IPv4", 1127 draft-ietf-mip4-dsmipv4-02 (work in progress), May 2007. 1129 [I-D.marjou-behave-app-rtp-keepalive] 1130 Marjou, X., "Application Mechanism for maintaining alive 1131 the Network Address Translator (NAT) mappings associated 1132 to RTP flows.", draft-marjou-behave-app-rtp-keepalive-01 1133 (work in progress), February 2007. 1135 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 1136 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 1137 RFC 4787, January 2007. 1139 [I-D.bajko-mip6-rrtfw] 1140 Bajko, G., "Firewall friendly RTT for MIPv6", 1141 draft-bajko-mip6-rrtfw-01 (work in progress), 1142 October 2006. 1144 Authors' Addresses 1146 Hannes Tschofenig 1147 Nokia Siemens Networks 1148 Otto-Hahn-Ring 6 1149 Munich, Bavaria 81739 1150 Germany 1152 Email: Hannes.Tschofenig@nsn.com 1153 URI: http://www.tschofenig.com 1155 Gabor Bajko 1156 Nokia 1158 Full Copyright Statement 1160 Copyright (C) The IETF Trust (2007). 1162 This document is subject to the rights, licenses and restrictions 1163 contained in BCP 78, and except as set forth therein, the authors 1164 retain all their rights. 1166 This document and the information contained herein are provided on an 1167 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1168 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1169 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1170 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1171 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1172 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1174 Intellectual Property 1176 The IETF takes no position regarding the validity or scope of any 1177 Intellectual Property Rights or other rights that might be claimed to 1178 pertain to the implementation or use of the technology described in 1179 this document or the extent to which any license under such rights 1180 might or might not be available; nor does it represent that it has 1181 made any independent effort to identify any such rights. Information 1182 on the procedures with respect to rights in RFC documents can be 1183 found in BCP 78 and BCP 79. 1185 Copies of IPR disclosures made to the IETF Secretariat and any 1186 assurances of licenses to be made available, or the result of an 1187 attempt made to obtain a general license or permission for the use of 1188 such proprietary rights by implementers or users of this 1189 specification can be obtained from the IETF on-line IPR repository at 1190 http://www.ietf.org/ipr. 1192 The IETF invites any interested party to bring to its attention any 1193 copyrights, patents or patent applications, or other proprietary 1194 rights that may cover technology that may be required to implement 1195 this standard. Please address the information to the IETF at 1196 ietf-ipr@ietf.org. 1198 Acknowledgment 1200 Funding for the RFC Editor function is provided by the IETF 1201 Administrative Support Activity (IASA).