idnits 2.17.1 draft-tschofenig-hip-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 17. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 991. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1002. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1009. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1015. 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 21, 2007) is 6153 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) == Outdated reference: A later version (-19) exists of draft-ietf-mmusic-ice-16 == Outdated reference: A later version (-16) exists of draft-ietf-behave-turn-03 == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-07 == Outdated reference: A later version (-09) exists of draft-ietf-hip-nat-traversal-01 == Outdated reference: A later version (-10) exists of draft-ietf-hip-base-08 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) == Outdated reference: A later version (-18) exists of draft-ietf-behave-rfc3489bis-06 == Outdated reference: A later version (-05) exists of draft-wing-behave-nat-control-stun-usage-02 Summary: 2 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 HIP H. Tschofenig 3 Internet-Draft Nokia Siemens Networks 4 Intended status: Standards Track D. Wing 5 Expires: December 23, 2007 Cisco 6 June 21, 2007 8 Utilizing Interactive Connectivity Establishment (ICE) for the Host 9 Identity Protocol (HIP) 10 draft-tschofenig-hip-ice-00.txt 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet- 22 Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 This Internet-Draft will expire on December 23, 2007. 37 Copyright Notice 39 Copyright (C) The IETF Trust (2007). 41 Abstract 43 This document describes how the Interactive Connectivity 44 Establishment (ICE) methodology can be used for the Host Identity 45 Protocol (HIP) to determine whether end-to-end communication is 46 possible. ICE makes use of the Session Traversal Utilities for NAT 47 (STUN) protocol in addition to mechanisms for checking connectivity 48 between peers. After running the ICE the two HIP end points will be 49 able to communicate directly or through a relay via Network Address 50 Translators (NATs), Network Address and Port Translators (NAPTs) and 51 firewalls . 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Gathering Candidate Addresses . . . . . . . . . . . . . . 5 57 1.2. Connectivity Checks . . . . . . . . . . . . . . . . . . . 5 58 1.3. Sorting Candidates . . . . . . . . . . . . . . . . . . . . 5 59 1.4. Frozen Candidates . . . . . . . . . . . . . . . . . . . . 6 60 1.5. Security for Checks . . . . . . . . . . . . . . . . . . . 6 61 1.6. Concluding HIP-ICE . . . . . . . . . . . . . . . . . . . . 6 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3. Design Choices . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Sending the Initial Offer . . . . . . . . . . . . . . . . . . 8 65 5. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 8 66 6. Receiving the Initial Offer . . . . . . . . . . . . . . . . . 8 67 7. Concluding ICE Processing . . . . . . . . . . . . . . . . . . 9 68 8. Generating the Offer . . . . . . . . . . . . . . . . . . . . . 9 69 9. Keepalives . . . . . . . . . . . . . . . . . . . . . . . . . . 9 70 10. Attribute Encoding . . . . . . . . . . . . . . . . . . . . . . 9 71 11. Demultiplexing HIP and STUN . . . . . . . . . . . . . . . . . 10 72 12. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 73 13. Security Considerations . . . . . . . . . . . . . . . . . . . 11 74 13.1. Attacks on Connectivity Checks . . . . . . . . . . . . . . 11 75 13.2. Attacks on Address Gathering . . . . . . . . . . . . . . . 14 76 13.3. Attacks on the Offer/Answer Exchanges . . . . . . . . . . 15 77 13.4. Insider Attacks . . . . . . . . . . . . . . . . . . . . . 15 78 13.4.1. HIP Amplification Attack . . . . . . . . . . . . . . 15 79 13.4.2. STUN Amplification Attack . . . . . . . . . . . . . . 15 80 14. IAB Considerations . . . . . . . . . . . . . . . . . . . . . . 16 81 14.1. Problem Definition . . . . . . . . . . . . . . . . . . . . 16 82 14.2. Exit Strategy . . . . . . . . . . . . . . . . . . . . . . 17 83 14.3. Brittleness Introduced by HIP-ICE . . . . . . . . . . . . 17 84 14.4. Requirements for a Long Term Solution . . . . . . . . . . 18 85 14.5. Issues with Existing NAPT Boxes . . . . . . . . . . . . . 19 86 15. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 19 87 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 88 16.1. Normative References . . . . . . . . . . . . . . . . . . . 20 89 16.2. Informative References . . . . . . . . . . . . . . . . . . 20 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 91 Intellectual Property and Copyright Statements . . . . . . . . . . 22 93 1. Introduction 95 This document describes how the Interactive Connectivity 96 Establishment (ICE [I-D.ietf-mmusic-ice]) methodology can be used for 97 the Host Identity Protocol (HIP) to determine whether end-to-end 98 communication is possible. We call this usage HIP-ICE. ICE makes 99 use of the Session Traversal Utilities for NAT (STUN [RFC3489], 100 STUNbis [I-D.ietf-behave-rfc3489bis]) protocol to learn candidate 101 transport addresses and to verify connectivity between peers. After 102 running the ICE methodology, the two HIP end points will be able to 103 communicate as directly possible -- directly with each other, through 104 a HIP relay, via Network Address Translators (NATs), Network Address 105 and Port Translators (NAPTs), and firewalls. 107 In a typical deployment, there are two endpoints, Agent L and Agent 108 R, which want to communicate. These two agents play the role of HIP 109 initiators and HIP responders. They are able to communicate 110 indirectly via a combination of HIP and traversal via a HIP 111 rendezvous server. 113 At the beginning of the HIP-ICE process, the end points are ignorant 114 of their own topologies. They might or might not be behind a NAT (or 115 multiple tiers of NATs) and might be behind firewalls that limit the 116 ability to communicate in different ways between the end points. 117 HIP-ICE allows these end points to discover enough information about 118 their topologies to potentially find one or more paths by which they 119 can communicate. 121 Figure 1 shows a typical environment for HIP-ICE deployment. The two 122 end points are labelled L and R (for left and right). Both L and R 123 are behind their own respective NATs or firewalls though they may not 124 be aware of it. The type of NAT or firewall and their properties are 125 also unknown. L and R are capable of engaging in an end-to-end 126 protocol exchange with the help of HIP rendezvous servers. 128 If desired, TURN [I-D.ietf-behave-turn] could be used for relaying 129 IPsec traffic rather than relying on dedicated HIP rendezvous 130 servers. This would allow HIP DNS [I-D.ietf-hip-dns] to be used. 131 This aspect is for further study. 133 In Figure 1 the STUN server is co-located with the HIP rendezvous 134 servers for editorial reasons. From a solution point of view this 135 is, however, not necessary. 137 HIP 138 +----------+ Signalling +----------+ 139 |Rendezvous|<---------------------->|Rendezvous| 140 |Server A | |Server B | 141 +----------+ +----------+ 142 ^ ^ 143 | | 144 | | 145 | | 146 HIP | |HIP 147 Signalling| |Signalling 148 | | 149 | | 150 +---v----+ Optimal HIP/IPsec path +---v----+ 151 | FW/NAT |<-------------------------->| FW/NAT | 152 +---^----+ +---^----+ 153 | | 154 | | 155 v v 156 +--------+ +--------+ 157 | Agent | | Agent | 158 | L | | R | 159 +--------+ +--------+ 161 Figure 1: Overview 163 The basic idea behind HIP-ICE is as follows: each end point has a 164 variety of candidate TRANSPORT ADDRESSES (combination of IP address, 165 transport protocol (UDP), and port) it could use to communicate with 166 the other end point. 168 To avoid unnecessary UDP encapsulation of IPsec traffic, it is 169 also possible to consider using IP addresses rather than focusing 170 exclusively on TRANSPORT ADDRESSES. For example, two HIP hosts 171 behind the same NAT do not need to use UDP encapsulation. As 172 another example, a HIP host behind a HIP-friendly NAT or HIP- 173 friendly firewall does not need UDP encapsulation. The need and 174 desire for this functionality will be analysed in a future version 175 of this document. 177 Potentially, any of L's candidate transport addresses can be used to 178 communicate with any of R's candidate transport addresses. In 179 practice, however, many combinations do not work. For instance, if L 180 and R are both behind NATs, their directly attached interface 181 addresses (e.g., 192.168.1.100) are unlikely to be able to 182 communicate. The purpose of HIP-ICE is to discover which pairs of 183 addresses will work. The way that HIP-ICE does this is to 184 systematically try all possible pairs (in a carefully sorted order) 185 until it finds one or more that works. Once found, the best pair is 186 used for subsequent communication between the hosts. 188 1.1. Gathering Candidate Addresses 190 In order to execute ICE, an agent has to identify all of its address 191 candidates. A CANDIDATE is a transport address - a combination of IP 192 address and port for a particular transport protocol. 194 This document uses three types of candidates: 196 1. One viable candidate is a transport address obtained directly 197 from a local interface. Such a candidate is called a HOST 198 CANDIDATE. 199 2. Translated addresses on the public side of a NAT (called SERVER 200 REFLEXIVE CANDIDATES). This address is obtained via STUN. 201 3. Addresses obtained via relaying traffic through the rendezvous 202 server, called RELAYED CANDIDATES. 204 1.2. Connectivity Checks 206 Once L has gathered all of its candidates, it orders them in highest 207 to lowest priority and sends them to R over the signalling channel. 208 We refer to the signaling channel to the end-to-end HIP exchange. 209 The extension to exchange candidates can be found in Section 10. 211 When R receives the L's HIP I2 message, R performs the same candidate 212 gathering process and responds with its own list of candidates. At 213 the end of this process, each agent has a complete list of both its 214 candidates and its peer's candidates. It pairs them up, resulting in 215 CANDIDATE PAIRS. To see which pairs work, each agent schedules a 216 series of connectivity CHECKS. Each check is a STUN transaction that 217 the client will perform on a particular candidate pair by sending a 218 STUN request from the local candidate to the remote candidate; a 219 response indicates there is connectivity to the peer using that 220 candidate address. 222 It is important to note that the STUN requests are sent to and from 223 the exact same IP addresses and ports that will be used for 224 subsequent data traffic. 226 1.3. Sorting Candidates 228 Because the algorithm above searches all candidate pairs, if a 229 working pair exists it will eventually find it no matter what order 230 the candidates are tried in. In order to produce faster (and better) 231 results, the candidates are sorted in a specified order. The 232 resulting list of sorted candidate pairs is called the CHECK LIST. 234 1.4. Frozen Candidates 236 The concept of frozen candidates is not applicable when ICE is 237 applied to HIP. 239 1.5. Security for Checks 241 Because the ICE algorithm is used to discover which addresses can be 242 used to send traffic between two end points, it is important to 243 ensure that the process cannot be hijacked to send traffic to the 244 wrong location. Each STUN connectivity check is covered by a message 245 authentication code (MAC) generated based on passwords exchanged via 246 the HIP exchange. This MAC provides message integrity and data 247 origin authentication, thus stopping an attacker from forging or 248 modifying connectivity check messages. 250 1.6. Concluding HIP-ICE 252 ICE checks are performed in a specific sequence, so that high 253 priority candidate pairs are checked first, followed by lower 254 priority ones. 256 2. Terminology 258 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 259 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 260 document are to be interpreted as described in RFC 2119 [RFC2119]. 262 This document heavily relies on the terminology introduced in 263 [I-D.ietf-mmusic-ice]. 265 3. Design Choices 267 The work in this document is guided by the following design choices, 268 namely: 270 o The offer/answer exchange described in ICE [I-D.ietf-mmusic-ice] 271 is mapped to the end-to-end HIP exchange. An initial offer is 272 carried inside the I2 message and an initial answer is carried 273 inside the R2 message. A later offer/answer exchange is conveyed 274 in a NOTIFY packet (inside the NOTIFICATION parameter). When 275 Network Address Translators and firewalls are located along the 276 path then direct end-to-end communication between the two end 277 point is typically not possible and hence this protocol 278 interaction is provided via HIP rendezvous nodes. 280 o We assume that HIP initiators and HIP responders implement and use 281 STUN. For performing connectivity checks a couple of other 282 alternatives are, however, possible: 284 It would be possible to utilize REAP 285 [I-D.ietf-shim6-failure-detection] but STUN provides the same 286 support with a more likely chance for widespread deployment. 287 REAP currently only provides IPv6 support. 288 Custom HIP messages could be created as described in 289 [I-D.ietf-hip-nat-traversal]. 290 HIP multi-homing and mobility support [I-D.ietf-hip-mm] 291 provides a basic support for address checks. 293 o If one peer does not support STUN then the optimal results of HIP- 294 ICE cannot be provided. There is, however, the ability to make 295 use of STUN LITE when a host is on the public address space and 296 not behind a firewall. 297 o Obtaining Relay Addresses from STUN [I-D.ietf-behave-turn], 298 formerly known as TURN, is intentionally not used. For HIP, a HIP 299 rendezvous server reverse tunneling functionality is used instead 300 of TURN. 301 o This document makes use of the UDP-encapsulated of HIP packets, as 302 specified in [I-D.ietf-hip-nat-traversal]. 303 o This document focuses only on the data exchange between the two 304 end points rather than on the communication between a HIP end 305 point and a rendezvous server or on the ability to allow HIP 306 signaling messages to traverse NATs and firewalls. 307 o Each STUN connectivity check is covered by a message 308 authentication code (MAC) generated based on passwords exchanged 309 via the HIP exchange. This is similar to how ICE exchanges 310 username and password fragments in the offer/answer exchange. 312 Alternatively, it is also possible to generate keying material 313 for the message authentication code used in STUN based on the 314 key derivation procedure described in Section 6.5 of 315 [I-D.ietf-hip-base]. 317 Note that the ICE description assumes usage within a VoIP environment 318 where individual flows are controlled. However, the protocol 319 interaction described in this document operates at a lower layer 320 where application specific message flows are not visible. When a 321 CANDIDATE PAIR, consisting of two TRANSPORT ADDRESSES, is created 322 then it will typically refer to multiple flows then traffic between 323 two end points experiences UDP encapsulation (due to the need to 324 traverse a NAT or a stateful packet filtering firewall). 326 The descriptions in the ICE specification related to SIP, ANAT, RTP, 327 RTCP, third party call control, preconditions, forking, etc. are not 328 applicable to HIP and are not included in this document. 330 From an editorial point of view it would be possible to copy-and- 331 paste relevant parts of the ICE specification and to remove VoIP 332 specific descriptions but for this version of the document we did 333 not follow this approach. 335 The main accomplishment of this document is the reuse of the well- 336 established ICE specification that builds on STUN. STUN enjoys 337 widespread implementation support and maximum code re-use was one of 338 the design criteria for this document. 340 4. Sending the Initial Offer 342 In order to send the initial offer in an offer/answer exchange, an 343 agent must (1) gather candidates, (2) prioritize them, (3) choose 344 default candidates, and then (4) formulate and send them to the other 345 peer. 347 Section 4 of ICE [I-D.ietf-mmusic-ice] is applicable to this document 348 with the following two exceptions: First, TURN is not used in this 349 document but instead the same functionality is accomplished via the 350 HIP rendezvous mechanism. Second, the description regarding encoding 351 of candidates in SDP is not applicable and replaced by a HIP specific 352 encoding described in Section 10. 354 5. Receiving the Initial Offer 356 When an agent receives an initial offer, it will check if the offerer 357 supports sufficient ICE functionality to proceed (i.e., if both 358 offerer and answerer are lite implementations, ICE cannot proceed), 359 determine its own role, gather candidates, prioritize them, choose 360 default candidates, encode and send an answer, and for full 361 implementations, form the check lists and begin connectivity checks. 363 Again, the description regarding encoding of candidates in SDP is not 364 applicable to this document and is replaced by a HIP specific 365 encoding described in Section 10. Note that only the encoding is 366 different but not the semantic. As such, the description in Section 367 5 of [I-D.ietf-mmusic-ice] is applicable to this document. 369 6. Receiving the Initial Offer 371 Section 6 of ICE [I-D.ietf-mmusic-ice] describes the procedures that 372 an agent follows when it receives the answer from the peer. It 373 verifies that its peer supports ICE, determines its role, and for 374 full implementations, forms the check list and begins performing 375 periodic checks. 377 7. Concluding ICE Processing 379 The description in Section of ICE [I-D.ietf-mmusic-ice] illustrates 380 processing rules that apply only to full implementations. Concluding 381 ICE involves nominating pairs by the controlling agent and updating 382 of state machinery 384 8. Generating the Offer 386 Either agent may generate a subsequent offer at any time. The rules 387 in Section 8 of ICE [I-D.ietf-mmusic-ice] will cause the controlling 388 agent to send an updated offer at the conclusion of ICE processing 389 when ICE has selected different candidate pairs from the default 390 pairs. Section 9 of ICE [I-D.ietf-mmusic-ice] defines rules for 391 construction of subsequent offers and answers. 393 Note that the term "media stream" in Section 9 of ICE 394 [I-D.ietf-mmusic-ice] translates to an individual UDP-encapsulated 395 data flow exchanged between the two HIP peers. 397 9. Keepalives 399 Section 10 of ICE [I-D.ietf-mmusic-ice] describes a keepalive 400 mechanism. The RTP description, such as RTP No-Op and RTP comfort 401 noise, is not applicable to this document. Other useful keepalive 402 techniques are described in [I-D.marjou-behave-app-rtp-keepalive] and 403 may be useful for HIP; a recommendation will be made in a subsequent 404 version of this document. 406 10. Attribute Encoding 408 This specification reuses seven SDP attributes, the "candidate", 409 "remote-candidates", "ice-lite", "ice-mismatch", "ice- ufrag", "ice- 410 pwd" and "ice-options" attributes, and places them in a single HIP 411 TLVs. 413 For this version of the document we decided to utilize the same gamma 414 as used in Section 15 of ICE [I-D.ietf-mmusic-ice]. 416 All HIP TLV parameters have a length (including Type and Length 417 fields) which is a multiple of 8 bytes. When needed, padding MUST be 418 added to the end of the parameter so that the total length becomes a 419 multiple of 8 bytes. 421 Section 15.1 to Section 15.5 of ICE [I-D.ietf-mmusic-ice] describe 422 the content of the attributes. 424 0 1 2 3 425 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 426 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 | Type | Length | 428 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 ~ ICE attribute ~ 430 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 432 Type TBD 433 Length variable 434 ICE attribute Attributes specified in ICE 436 Figure 2: Attribute Encoding 438 This TLV MUST be protected by the ENCRYPTED TLV. 440 11. Demultiplexing HIP and STUN 442 When HIP and STUN are run over the same port it is necessary to 443 demultiplex them. 445 A STUN packet always has the fixed value 0x2112A442 in its Magic 446 Cookie field (bits 32-64 from the beginning of the UDP payload): 448 0 1 2 3 449 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 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 451 |0 0| STUN Message Type | Message Length | 452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 453 |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| 454 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 . . . 457 Figure 3: STUN Header 459 In this same offset from the UDP header, the HIP header has its 460 Checksum field and its Controls field. The Controls field currently 461 only defines its last bit (bit 64); the rest of the bits in the 462 Control field are for extensions and must be 0. 464 0 1 2 3 465 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 466 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 467 | Next Header | Header Length |0| Packet Type | VER. | RES.|1| 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 | Checksum | Controls | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 . . . 473 Figure 4: HIP Header 475 Bit 16 of STUN's magic cookie is 1. To ensure HIP and STUN can 476 always be demultiplexed, HIP should require the first bit in the same 477 position always be 0. That bit is first bit of the HIP Controls 478 field, which is currently undefined and currently must be zero 479 [I-D.ietf-hip-base]. 481 12. Example 483 [Editor's Note: We will provide a message flow in a future version of 484 this document.] 486 13. Security Considerations 488 There are several types of attacks possible in an HIP-ICE system. 489 This section considers these attacks and their countermeasures. 491 13.1. Attacks on Connectivity Checks 493 An attacker might attempt to disrupt the STUN connectivity checks. 494 Ultimately, all of these attacks fool an agent into thinking 495 something incorrect about the results of the connectivity checks. 496 The possible false conclusions an attacker can try and cause are: 498 False Invalid: 500 An attacker can fool a pair of agents into thinking a candidate 501 pair is invalid, when it isn't. This can be used to cause an 502 agent to prefer a different candidate (such as one injected by the 503 attacker), or to disrupt a call by forcing all candidates to fail. 505 False Valid: 507 An attacker can fool a pair of agents into thinking a candidate 508 pair is valid, when it isn't. This can cause an agent to proceed 509 with a session, but then not be able to receive any data traffic. 511 False Peer-Reflexive Candidate: 513 An attacker can cause an agent to discover a new peer reflexive 514 candidate, when it shouldn't have. This can be used to redirect 515 data traffic to a DoS target or to the attacker, for eavesdropping 516 or other purposes. 518 False Valid on False Candidate: 520 An attacker has already convinced an agent that there is a 521 candidate with an address that doesn't actually route to that 522 agent (for example, by injecting a false peer reflexive candidate 523 or false server reflexive candidate). It must then launch an 524 attack that forces the agents to believe that this candidate is 525 valid. 527 Of the various techniques for creating faked STUN messages described 528 in [I-D.ietf-behave-rfc3489bis], many are not applicable for the 529 connectivity checks. Compromises of STUN servers are not much of a 530 concern, since the STUN servers are embedded in endpoints and 531 distributed throughout the network. Thus, compromising the peer's 532 embedded STUN server is equivalent to compromising the end point, and 533 if that happens, far more problematic attacks are possible than those 534 against ICE. When a rendezvous server that also operators a STUN 535 server is compromised then various attacks are possible since the 536 rendezvous server maintains also mappings between identifiers and 537 locators. 539 Injection of fake responses and relaying modified requests all can be 540 handled in ICE with the countermeasures discussed below. 542 To force the false invalid result, the attacker has to wait for the 543 connectivity check from one of the agents to be sent. When it is, 544 the attacker needs to inject a fake response with an unrecoverable 545 error response, such as a 600. However, since the candidate is, in 546 fact, valid, the original request may reach the peer agent, and 547 result in a success response. The attacker needs to force this 548 packet or its response to be dropped, through a DoS attack, layer 2 549 network disruption, or other technique. If it doesn't do this, the 550 success response will also reach the originator, alerting it to a 551 possible attack. Fortunately, this attack is mitigated completely 552 through the STUN message integrity mechanism. The attacker needs to 553 inject a fake response, and in order for this response to be 554 processed, the attacker needs the password. If the candidates are 555 exchange in HIP messages and therefore secured, the attacker will not 556 have the password. 558 Forcing the fake valid result works in a similar way. The agent 559 needs to wait for the Binding Request from each agent, and inject a 560 fake success response. The attacker won't need to worry about 561 disrupting the actual response since, if the candidate is not valid, 562 it presumably wouldn't be received anyway. However, like the fake 563 invalid attack, this attack is mitigated completely through the STUN 564 message integrity and offer/answer security techniques. 566 Forcing the false peer reflexive candidate result can be done either 567 with fake requests or responses, or with replays. We consider the 568 fake requests and responses case first. It requires the attacker to 569 send a Binding Request to one agent with a source IP address and port 570 for the false candidate. In addition, the attacker must wait for a 571 Binding Request from the other agent, and generate a fake response 572 with a XOR-MAPPED-ADDRESS attribute containing the false candidate. 573 Like the other attacks described here, this attack is mitigated by 574 the STUN message integrity mechanisms and secure offer/answer 575 exchanges. 577 Forcing the false peer reflexive candidate result with packet replays 578 is different. The attacker waits until one of the agents sends a 579 check. It intercepts this request, and replays it towards the other 580 agent with a faked source IP address. It must also prevent the 581 original request from reaching the remote agent, either by launching 582 a DoS attack to cause the packet to be dropped, or forcing it to be 583 dropped using layer 2 mechanisms. The replayed packet is received at 584 the other agent, and accepted, since the integrity check passes (the 585 integrity check cannot and does not cover the source IP address and 586 port). It is then responded to. This response will contain a XOR- 587 MAPPED-ADDRESS with the false candidate, and will be sent to that 588 false candidate. The attacker must then receive it and relay it 589 towards the originator. 591 The other agent will then initiate a connectivity check towards that 592 false candidate. This validation needs to succeed. This requires 593 the attacker to force a false valid on a false candidate. Injecting 594 of fake requests or responses to achieve this goal is prevented using 595 the integrity mechanisms of STUN and the offer/answer exchange. 596 Thus, this attack can only be launched through replays. To do that, 597 the attacker must intercept the check towards this false candidate, 598 and replay it towards the other agent. Then, it must intercept the 599 response and replay that back as well. 601 This attack is very hard to launch unless the attacker is identified 602 by the fake candidate. This is because it requires the attacker to 603 intercept and replay packets sent by two different hosts. If both 604 agents are on different networks (for example, across the public 605 Internet), this attack can be hard to coordinate, since it needs to 606 occur against two different endpoints on different parts of the 607 network at the same time. 609 If the attacker them self is identified by the fake candidate the 610 attack is easier to coordinate. However, since HIP utilizes IPsec 611 ESP to protect the data traffic end-to-end, the attacker will not be 612 able to inspect any application data, they will only be able to 613 discard them. However, this attack requires the agent to disrupt 614 packets in order to block the connectivity check from reaching the 615 target. In that case, if the goal is to disrupt the end-to-end 616 communication, its much easier to just disrupt it with the same 617 mechanism, rather than attack ICE. 619 13.2. Attacks on Address Gathering 621 ICE endpoints make use of STUN for gathering candidates from a STUN 622 server in the network. This is corresponds to the Binding Discovery 623 usage of STUN described in [I-D.ietf-behave-rfc3489bis]. As a 624 consequence, the attacks against STUN itself that are described in 625 that specification can still be used against the binding discovery 626 usage when utilized with ICE. 628 However, the additional mechanisms provided by ICE actually 629 counteract such attacks, making binding discovery with STUN more 630 secure when combined with ICE. 632 Consider an attacker which is able to provide an agent with a faked 633 mapped address in a STUN Binding Request that is used for address 634 gathering. This is the primary attack primitive described in 635 [I-D.ietf-behave-rfc3489bis]. This address will be used as a server 636 reflexive candidate in the ICE exchange. For this candidate to 637 actually be used for media, the attacker must also attack the 638 connectivity checks, and in particular, force a false valid on a 639 false candidate. This attack is very hard to launch if the false 640 address identifies a fourth party (neither the offerer, answerer, or 641 attacker), since it requires attacking the checks generated by each 642 agent in the session. 644 If the attacker elects not to attack the connectivity checks, the 645 worst it can do is prevent the server reflexive candidate from being 646 used. However, if the peer agent has at least one candidate that is 647 reachable by the agent under attack, the STUN connectivity checks 648 themselves will provide a peer reflexive candidate that can be used 649 for the exchange of media. Peer reflexive candidates are generally 650 preferred over server reflexive candidates. As such, an attack 651 solely on the STUN address gathering will normally have no impact on 652 a session at all. 654 13.3. Attacks on the Offer/Answer Exchanges 656 An attacker that can modify or disrupt the offer/answer exchanges 657 themselves can readily launch a variety of attacks with HIP-ICE. 658 They could direct data traffic to a target of a DoS attack, they 659 could insert themselves into the data exchange, and so on. The 660 security considerations of HIP [I-D.ietf-hip-base] apply. 662 13.4. Insider Attacks 664 In addition to attacks where the attacker is a third party trying to 665 insert fake offers, answers or STUN messages, there are several 666 attacks possible with ICE when the attacker is an authenticated and 667 valid participant in the HIP-ICE exchange. 669 13.4.1. HIP Amplification Attack 671 In this attack, the attacker initiates communication to other agents, 672 and maliciously includes the IP address and port of a DoS target as 673 the destination for data traffic signaled in the HIP exchange. 675 This could causes substantial amplification; a single offer/answer 676 exchange can create a continuing flood of data packets, possibly at 677 high rates (consider video sources). This attack is not specific to 678 ICE, but ICE can help provide remediation. 680 Specifically, if ICE is used, the agent receiving the malicious SDP 681 will first perform connectivity checks to the target of media before 682 sending media there. If this target is a third party host, the 683 checks will not succeed, and media is never sent. 685 Unfortunately, ICE doesn't help if its not used, in which case an 686 attacker could simply send the offer without the ICE parameters. 687 However, in environments where the set of clients are known, and 688 limited to ones that support ICE, the server can reject any offers or 689 answers that don't indicate ICE support. 691 13.4.2. STUN Amplification Attack 693 The STUN amplification attack is similar to the HIP amplification 694 attack. However, instead of data packets being directed to the 695 target, STUN connectivity checks are directed to the target. The 696 attacker sends an offer with a large number of candidates, say 50. 698 The answerer receives the offer, and starts its checks, which are 699 directed at the target, and consequently, never generate a response. 700 The answerer will start a new connectivity check every 20ms, and each 701 check is a STUN transaction consisting of 7 transmissions of a 702 message 65 bytes in length (plus 28 bytes for the IP/UDP header) that 703 runs for 7.9 seconds, for a total of 58 bytes/second per transaction 704 on average. In the worst case, there can be 395 transactions in 705 progress at once (7.9 seconds divided by 20ms), for a total of 182 706 kbps, just for STUN requests. 708 It is impossible to eliminate the amplification, but the volume can 709 be reduced through a variety of heuristics. Agents SHOULD limit the 710 total number of connectivity checks they perform to 100. 711 Additionally, agents MAY limit the number of candidates they'll 712 accept in an offer or answer. 714 14. IAB Considerations 716 The IAB has studied the problem of "Unilateral Self Address Fixing", 717 which is the general process by which a agent attempts to determine 718 its address in another realm on the other side of a NAT through a 719 collaborative protocol reflection mechanism [RFC3424]. HIP-ICE is an 720 example of a protocol that performs this type of function. 721 Interestingly, the process for HIP-ICE is not unilateral, but 722 bilateral, and the difference has a significant impact on the issues 723 raised by IAB. HIP-ICE can be considered a B-SAF (Bilateral Self- 724 Address Fixing) protocol, rather than an UNSAF protocol. Regardless, 725 the IAB has mandated that any protocols developed for this purpose 726 document a specific set of considerations. This section meets those 727 requirements. 729 14.1. Problem Definition 731 From RFC 3424 [RFC3424] any UNSAF proposal must provide: 733 Precise definition of a specific, limited-scope problem that is to be 734 solved with the UNSAF proposal. A short term fix should not be 735 generalized to solve other problems; this is why "short term fixes 736 usually aren't". 738 The specific problems being solved by HIP-ICE are: 740 Provide a means for two peers to determine the set of transport 741 addresses which can be used for communication. 743 Provide a means for resolving many of the limitations of other UNSAF 744 mechanisms by wrapping them in an additional layer of processing (the 745 HIP-ICE methodology). 747 Provide a means for a agent to determine an address that is reachable 748 by another peer with which it wishes to communicate. 750 14.2. Exit Strategy 752 From RFC 3424, any UNSAF proposal must provide: 754 Description of an exit strategy/transition plan. The better short 755 term fixes are the ones that will naturally see less and less use as 756 the appropriate technology is deployed. 758 HIP-ICE itself doesn't easily get phased out. However, it is useful 759 even in a globally connected Internet, to serve as a means for 760 detecting whether communication paths are disrupted. HIP-ICE also 761 helps prevent certain security attacks which have nothing to do with 762 NAT. However, what HIP-ICE does is help phase out other UNSAF 763 mechanisms. HIP-ICE effectively selects amongst those mechanisms, 764 prioritizing ones that are better, and deprioritizing ones that are 765 worse. Local IPv6 addresses can be preferred. As NATs begin to 766 dissipate as IPv6 is introduced, server reflexive and relayed 767 candidates (both forms of UNSAF mechanisms) simply never get used, 768 because higher priority connectivity exists to the native host 769 candidates. Therefore, the servers get used less and less, and can 770 eventually be remove when their usage goes to zero. 772 Indeed, HIP-ICE can assist in the transition from IPv4 to IPv6. It 773 can be used to determine whether to use IPv6 or IPv4 when two dual- 774 stack hosts communicate. It can also allow a network with both 6to4 775 and native v6 connectivity to determine which address to use when 776 communicating with a peer. 778 14.3. Brittleness Introduced by HIP-ICE 780 From RFC3424, any UNSAF proposal must provide: 782 Discussion of specific issues that may render systems more "brittle". 783 For example, approaches that involve using data at multiple network 784 layers create more dependencies, increase debugging challenges, and 785 make it harder to transition. 787 HIP-ICE uses ICE that is utilizes [I-D.ietf-behave-rfc3489bis] 788 instead of traditional STUN, RFC 3489 [RFC3489]). RFC 3489 has 789 several points of brittleness. One of them is the discovery process 790 which requires a agent to try and classify the type of NAT it is 791 behind. This process is error-prone. With HIP-ICE, that discovery 792 process is simply not used. Rather than unilaterally assessing the 793 validity of the address, its validity is dynamically determined by 794 measuring connectivity to a peer. The process of determining 795 connectivity is very robust. 797 Another point of brittleness in any other unilateral mechanism is its 798 absolute reliance on an additional server on the public Internet, 799 namely the rendezvous server. ICE makes use of a server for 800 allocating unilateral addresses, but allows agents to directly 801 connect if possible. Therefore, in some cases, the failure of a STUN 802 server would still allow data packets to be exchanged in an end-to- 803 end fashion when ICE is used. 805 Another point of brittleness in traditional STUN is that it assumes 806 that the STUN server is on the public Internet. Interestingly, with 807 HIP-ICE, that is not necessary. There can be a multitude of STUN 808 servers in a variety of address realms. ICE will discover the one 809 that has provided a usable address. 811 The most troubling point of brittleness in traditional STUN is that 812 it does not work in all network topologies. In cases where there is 813 a shared NAT between each agent and the STUN server, traditional STUN 814 may not work. With ICE, that restriction is removed. 816 Traditional STUN also introduces some security considerations. 817 Fortunately, those security considerations are also mitigated by ICE. 819 Consequently, ICE serves to repair the brittleness introduced in 820 other UNSAF mechanisms, and does not introduce any additional 821 brittleness into the system. 823 With HIP-ICE rendezvous servers are used and they are assumed to be 824 located on the public Internet to allow HIP to work. Without the 825 usage of TURN servers it is, however, not possible to allow HIP usage 826 without rendezvous server and solely with HIP DNS [I-D.ietf-hip-dns] 827 to work in presence of NATs and firewalls. 829 14.4. Requirements for a Long Term Solution 831 From RFC 3424, any UNSAF proposal must provide: 833 Identify requirements for longer term, sound technical solutions -- 834 contribute to the process of finding the right longer term solution. 836 HIP-ICE provides a long term solution by utilizing ICE concepts that 837 have received a lot of peer review in the VoIP community and to apply 838 them to HIP. The only other possible long term solutions are (a) to 839 get rid of middleboxes, such as NATs and firewalls or to (b) interact 840 with them. Regarding (b) extensions for STUN to allow the protocol 841 to be deployed on NATs and firewalls is currently being investigated 842 in [I-D.wing-behave-nat-control-stun-usage]. 844 14.5. Issues with Existing NAPT Boxes 846 From RFC 3424, any UNSAF proposal must provide: 848 Discussion of the impact of the noted practical issues with existing, 849 deployed NA[P]Ts and experience reports. 851 A number of NAT boxes are now being deployed into the market which 852 try and provide "generic" ALG functionality. These generic ALGs hunt 853 for IP addresses, either in text or binary form within a packet, and 854 rewrite them if they match a binding. This interferes with 855 traditional STUN. However, the update to STUN 856 [I-D.ietf-behave-rfc3489bis] uses an encoding which hides these 857 binary addresses from generic ALGs. 859 Existing NAPT boxes have non-deterministic and typically short 860 expiration times for UDP-based bindings. This requires 861 implementations to send periodic keepalives to maintain those 862 bindings. ICE uses a default of 15s, which is a very conservative 863 estimate. Eventually, over time, as NAT boxes become compliant to 864 behave [RFC4787], this minimum keepalive will become deterministic 865 and well-known, and the ICE timers can be adjusted. Having a way to 866 discover and control the minimum keepalive interval would be far 867 better still. 869 15. Acknowledgments 871 The authors would like to thank Jonathan Rosenberg for his work on 872 the ICE specification. This document copy-and-pastes text from the 873 ICE specification. 875 We would also like to thank the authors of 876 [I-D.ietf-hip-nat-traversal] for the discussions on the IETF HIP 877 mailing list. Note, however, that the approach described in this 878 document is considerably different than the approach outlined in 879 [I-D.ietf-hip-nat-traversal]. 881 Finally, we would like to thank Thomas Schreck for his help on 882 discussions various aspects in this document. 884 16. References 885 16.1. Normative References 887 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 888 Requirement Levels", March 1997. 890 [I-D.ietf-mmusic-ice] 891 Rosenberg, J., "Interactive Connectivity Establishment 892 (ICE): A Protocol for Network Address Translator (NAT) 893 Traversal for Offer/Answer Protocols", 894 draft-ietf-mmusic-ice-16 (work in progress), June 2007. 896 16.2. Informative References 898 [I-D.ietf-behave-turn] 899 Rosenberg, J., "Obtaining Relay Addresses from Simple 900 Traversal Underneath NAT (STUN)", 901 draft-ietf-behave-turn-03 (work in progress), March 2007. 903 [I-D.ietf-shim6-failure-detection] 904 Arkko, J. and I. Beijnum, "Failure Detection and Locator 905 Pair Exploration Protocol for IPv6 Multihoming", 906 draft-ietf-shim6-failure-detection-07 (work in progress), 907 December 2006. 909 [I-D.ietf-hip-nat-traversal] 910 Schmitt, V., "HIP Extensions for the Traversal of Network 911 Address Translators", draft-ietf-hip-nat-traversal-01 912 (work in progress), March 2007. 914 [I-D.ietf-hip-mm] 915 Henderson, T., "End-Host Mobility and Multihoming with the 916 Host Identity Protocol", draft-ietf-hip-mm-05 (work in 917 progress), March 2007. 919 [I-D.ietf-hip-dns] 920 Nikander, P. and J. Laganier, "Host Identity Protocol 921 (HIP) Domain Name System (DNS) Extensions", 922 draft-ietf-hip-dns-09 (work in progress), April 2007. 924 [I-D.ietf-hip-base] 925 Moskowitz, R., "Host Identity Protocol", 926 draft-ietf-hip-base-08 (work in progress), June 2007. 928 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 929 "STUN - Simple Traversal of User Datagram Protocol (UDP) 930 Through Network Address Translators (NATs)", RFC 3489, 931 March 2003. 933 [I-D.ietf-behave-rfc3489bis] 934 Rosenberg, J., "Session Traversal Utilities for (NAT) 935 (STUN)", draft-ietf-behave-rfc3489bis-06 (work in 936 progress), March 2007. 938 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 939 Self-Address Fixing (UNSAF) Across Network Address 940 Translation", RFC 3424, November 2002. 942 [I-D.wing-behave-nat-control-stun-usage] 943 Wing, D. and J. Rosenberg, "Discovering, Querying, and 944 Controlling Firewalls and NATs using STUN", 945 draft-wing-behave-nat-control-stun-usage-02 (work in 946 progress), June 2007. 948 [I-D.marjou-behave-app-rtp-keepalive] 949 Marjou, X., "Application Mechanism for maintaining alive 950 the Network Address Translator (NAT) mappings associated 951 to RTP flows.", draft-marjou-behave-app-rtp-keepalive-01 952 (work in progress), February 2007. 954 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 955 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 956 RFC 4787, January 2007. 958 Authors' Addresses 960 Hannes Tschofenig 961 Nokia Siemens Networks 962 Otto-Hahn-Ring 6 963 Munich, Bavaria 81739 964 Germany 966 Email: Hannes.Tschofenig@nsn.com 967 URI: http://www.tschofenig.com 969 Dan Wing 970 Cisco 971 170 West Tasman Drive 972 San Jose, CA 95134 973 USA 975 Email: dwing@cisco.com 977 Full Copyright Statement 979 Copyright (C) The IETF Trust (2007). 981 This document is subject to the rights, licenses and restrictions 982 contained in BCP 78, and except as set forth therein, the authors 983 retain all their rights. 985 This document and the information contained herein are provided on an 986 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 987 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 988 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 989 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 990 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 991 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 993 Intellectual Property 995 The IETF takes no position regarding the validity or scope of any 996 Intellectual Property Rights or other rights that might be claimed to 997 pertain to the implementation or use of the technology described in 998 this document or the extent to which any license under such rights 999 might or might not be available; nor does it represent that it has 1000 made any independent effort to identify any such rights. Information 1001 on the procedures with respect to rights in RFC documents can be 1002 found in BCP 78 and BCP 79. 1004 Copies of IPR disclosures made to the IETF Secretariat and any 1005 assurances of licenses to be made available, or the result of an 1006 attempt made to obtain a general license or permission for the use of 1007 such proprietary rights by implementers or users of this 1008 specification can be obtained from the IETF on-line IPR repository at 1009 http://www.ietf.org/ipr. 1011 The IETF invites any interested party to bring to its attention any 1012 copyrights, patents or patent applications, or other proprietary 1013 rights that may cover technology that may be required to implement 1014 this standard. Please address the information to the IETF at 1015 ietf-ipr@ietf.org. 1017 Acknowledgment 1019 Funding for the RFC Editor function is provided by the IETF 1020 Administrative Support Activity (IASA).