idnits 2.17.1 draft-ietf-mobike-protocol-05.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1383. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (October 24, 2005) is 6752 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) == Missing Reference: 'CERT' is mentioned on line 482, but not defined == Missing Reference: 'IDr' is mentioned on line 476, but not defined == Unused Reference: 'UDPEncap' is defined on line 1195, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-dupont-ikev2-addrmgmt-07 == Outdated reference: A later version (-05) exists of draft-dupont-mipv6-3bombing-02 == Outdated reference: A later version (-18) exists of draft-ietf-dhc-dna-ipv4-15 == Outdated reference: A later version (-03) exists of draft-ietf-dna-hosts-01 == Outdated reference: A later version (-08) exists of draft-ietf-mobike-design-02 == Outdated reference: A later version (-05) exists of draft-gont-tcpm-icmp-attacks-03 -- Obsolete informational reference (is this intentional?): RFC 3344 (ref. 'MIP4') (Obsoleted by RFC 5944) -- Obsolete informational reference (is this intentional?): RFC 3775 (ref. 'MIP6') (Obsoleted by RFC 6275) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) -- Obsolete informational reference (is this intentional?): RFC 3489 (ref. 'STUN') (Obsoleted by RFC 5389) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MOBIKE Working Group P. Eronen, Ed. 3 Internet-Draft Nokia 4 Expires: April 27, 2006 October 24, 2005 6 IKEv2 Mobility and Multihoming Protocol (MOBIKE) 7 draft-ietf-mobike-protocol-05.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 27, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This document describes the MOBIKE protocol, a mobility and 41 multihoming extension to Internet Key Exchange (IKEv2). MOBIKE 42 allows hosts to update the (outer) IP addresses associated with IKEv2 43 and tunnel mode IPsec Security Associations. A mobile VPN client 44 could use MOBIKE to keep the connection with the VPN gateway active 45 while moving from one address to another. Similarly, a multihomed 46 host could use MOBIKE to move the traffic to a different interface 47 if, for instance, the one currently being used stops working. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1. Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2. Scope and Limitations . . . . . . . . . . . . . . . . . . 4 54 1.3. Terminology and Notation . . . . . . . . . . . . . . . . . 4 55 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 56 2.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 5 57 2.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 6 58 2.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 9 59 3. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 10 60 3.1. Initial IKE Exchange . . . . . . . . . . . . . . . . . . . 10 61 3.2. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 10 62 3.3. Initial Tunnel Header Addresses . . . . . . . . . . . . . 10 63 3.4. Additional Addresses . . . . . . . . . . . . . . . . . . . 11 64 3.5. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 12 65 3.6. Updating Additional Addresses . . . . . . . . . . . . . . 15 66 3.7. Return Routability Check . . . . . . . . . . . . . . . . . 16 67 3.8. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 17 68 3.9. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 18 69 3.10. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 19 70 3.11. Failure Recovery and Timeouts . . . . . . . . . . . . . . 19 71 4. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 20 72 4.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 20 73 4.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 20 74 4.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 20 75 4.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 20 76 4.5. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 21 77 4.6. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 21 78 4.7. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 21 79 4.8. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 21 80 5. Security Considerations . . . . . . . . . . . . . . . . . . . 23 81 5.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 23 82 5.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 23 83 5.3. Denial-of-Service Attacks Against Third Parties . . . . . 24 84 5.4. Spoofing Network Connectivity Indications . . . . . . . . 25 85 5.5. Address and Topology Disclosure . . . . . . . . . . . . . 25 86 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 87 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 88 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 89 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 90 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 91 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 29 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 32 93 Intellectual Property and Copyright Statements . . . . . . . . . . 33 95 1. Introduction 97 1.1. Motivation 99 IKEv2 is used for performing mutual authentication, as well as 100 establishing and maintaining IPsec Security Associations (SAs). In 101 the base IKEv2 protocol, the IPsec and IKE SAs are created implicitly 102 between the IP addresses that are used when the IKE_SA is 103 established. These IP addresses are then used as the outer (tunnel 104 header) addresses for tunnel mode IPsec packets. Currently, it is 105 not possible to change these addresses after the IKE_SA has been 106 created. 108 There are scenarios where these IP addresses might change. One 109 example is mobility: a host changes its point of network attachment, 110 and receives a new IP address. Another example is a multihoming host 111 that would like to change to a different interface if, for instance, 112 the currently used interface stops working for some reason. 114 Although the problem can be solved by creating new IKE and IPsec SAs 115 when the addresses need to be changed, this may not be optimal for 116 several reasons. In some cases, creating a new IKE_SA may require 117 user interaction for authentication, such as entering a code from a 118 token card. Creating new SAs often also involves expensive 119 calculations and possibly a large number of round-trips. For these 120 reasons, a mechanism for updating the IP addresses of existing IKE 121 and IPsec SAs is needed. The MOBIKE protocol described in this 122 document provides such a mechanism. 124 The main scenario for MOBIKE is enabling a remote access VPN user to 125 move from one address to another without re-establishing all security 126 associations with the VPN gateway. For instance, a user could start 127 from fixed Ethernet in the office and then disconnect the laptop and 128 move to the office's wireless LAN. When leaving the office the 129 laptop could start using GPRS; when the user arrives home, the laptop 130 could switch the the home wireless LAN. MOBIKE updates only the 131 outer (tunnel header) addresses of IPsec SAs, and the addresses and 132 other traffic selectors used inside the tunnel stay unchanged. Thus, 133 mobility can be (mostly) invisible to applications and their 134 connections using the VPN. 136 MOBIKE also supports more complex scenarios where the VPN gateway 137 also has several network interfaces: these interfaces could be 138 connected to different networks or ISPs, they may be a mix of IPv4 139 and IPv6 addresses, and the addresses may change over time. 140 Furthermore, both parties could be VPN gateways relaying traffic for 141 other parties. 143 1.2. Scope and Limitations 145 This document focuses on the main scenario outlined above, and 146 supports only tunnel mode IPsec SAs. 148 The mobility support in MOBIKE allows both parties to move, but does 149 not provide a "rendezvous" mechanism that would allow simultaneous 150 movement of both parties, or discovering the addresses when the 151 IKE_SA is first established. This implies that MOBIKE is best suited 152 for situations where the address of at least one endpoint is 153 relatively stable, and can be discovered using existing mechanisms 154 such as DNS (see Section 3.1). 156 MOBIKE allows both parties to be multihomed; however, only one pair 157 of addresses is used for an SA at a time. In particular, load 158 balancing is beyond the scope of this specification. 160 MOBIKE follows the IKEv2 practice where a response message is sent to 161 the same address and port from which the request was received. This 162 implies that MOBIKE does not work over unidirectional paths. 164 NATs introduce additional limitations beyond those listed above. For 165 details, refer to Section 2.3. 167 The base version of the MOBIKE protocol does not cover all potential 168 future use scenarios, such as transport mode, application to securing 169 SCTP, or optimizations desirable in specific circumstances. Future 170 extensions may be defined later to support additional requirements. 172 Readers are encouraged to consult the MOBIKE design document [Design] 173 for further information and rationale behind these limitations. 175 1.3. Terminology and Notation 177 When messages containing IKEv2 payloads are described, optional 178 payloads are shown in brackets (for instance, "[FOO]"), and a plus 179 sign indicates that a payload can be repeated one or more times (for 180 instance, "FOO+"). To provide context, some diagrams also show what 181 existing IKEv2 payloads would typically be included in the exchanges. 182 These payloads are shown for illustrative purposes only; see [IKEv2] 183 for an authoritative description. 185 When this document talks about updating the source/destination 186 addresses of an IPsec SA, it means updating IPsec-related state so 187 that outgoing ESP/AH packets use those addresses in the tunnel 188 header. Depending on how the nominal division between Security 189 Association Database (SAD), Security Policy Database (SPD), and Peer 190 Authorization Database (PAD) described in [IPsecArch] is actually 191 implemented, an implementation can have several different places that 192 have to be updated. 194 In this document, the term "initiator" means the party who originally 195 initiated the first IKE_SA (in a series of possibly several rekeyed 196 IKE_SAs); "responder" is the other peer. During the lifetime of the 197 IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA 198 exchanges; in this case, the terms "exchange initiator" and "exchange 199 responder" are used. The term "original initiator" (which in [IKEv2] 200 refers to the party who started the latest IKE_SA rekeying) is not 201 used in this document. 203 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 204 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 205 document are to be interpreted as described in [KEYWORDS]. 207 2. Protocol Overview 209 2.1. Basic Operation 211 MOBIKE allows both parties to have several addresses, and there are 212 up to N*M pairs of IP addresses that could potentially be used. The 213 decision of which of these pairs to use has to take into account 214 several factors. First, the parties may have preferences about which 215 interface should be used due to, for instance, performance and cost 216 reasons. Second, the decision is constrained by the fact that some 217 of the pairs may not work at all due to incompatible IP versions, 218 outages in the network, problems at the local link at either end, and 219 so on. 221 MOBIKE solves this problem by taking a simple approach: the party 222 that initiated the IKE_SA (the "client" in a remote access VPN 223 scenario) is responsible for deciding which address pair is used for 224 the IPsec SAs and for collecting the information it needs to make 225 this decision (such as determining which address pairs work or do not 226 work). The other party (the "gateway" in a remote access VPN 227 scenario) simply tells the initiator what addresses it has but does 228 not update the IPsec SAs until it receives a message from the 229 initiator to do so. This approach applies to the addresses in the 230 IPsec SAs; in the IKE_SA case, the exchange initiator can decide 231 which addresses are used. 233 Making the decision at the initiator is consistent with how normal 234 IKEv2 works: the initiator decides which addresses it uses when 235 contacting the responder. It also makes sense, especially when the 236 initiator is a mobile node: it is in a better position to decide 237 which of its network interfaces should be used for both upstream and 238 downstream traffic. 240 The details of exactly how the initiator makes the decision, what 241 information is used in making it, how the information is collected, 242 how preferences affect the decision, and when a decision needs to be 243 changed are largely beyond the scope of MOBIKE. This does not mean 244 that these details are unimportant: on the contrary, they are likely 245 to be crucial in any real system. However, MOBIKE is concerned with 246 these details only to the extent that they are visible in IKEv2/IPsec 247 messages exchanged between the peers (and thus need to be 248 standardized to ensure interoperability). 250 Also, many of these issues are not specific to MOBIKE, but are common 251 with the use of existing hosts in dynamic environments or with 252 mobility protocols such as Mobile IP [MIP4] [MIP6]. A number of 253 mechanisms already exist or are being developed to deal with these 254 issues. For instance, link layer and IP layer mechanisms can be used 255 to track the status of connectivity within the local link [RFC2461]; 256 movement detection is being specified for both IPv4 and IPv6 in 257 [DNA4], [DNA6], and so on. 259 Naturally, updating the addresses of IPsec SAs has to take into 260 account several security considerations. MOBIKE includes two 261 features designed to address these considerations. First, a "return 262 routability" check can be used to verify the addresses provided by 263 the peer. This makes it more difficult to flood third parties with 264 large amounts of traffic. Second, a "NAT prohibition" feature 265 ensures that IP addresses have not been modified by NATs, IPv4/IPv6 266 translation agents, or other similar devices. This feature is 267 enabled only when NAT Traversal is not used. 269 2.2. Example Protocol Runs 271 A simple MOBIKE exchange in a mobile scenario is illustrated below: 273 Initiator Responder 274 ----------- ----------- 275 1) (IP_I1:500 -> IP_R1:500) 276 HDR, SAi1, KEi, Ni, 277 N(NAT_DETECTION_*_IP) --> 279 <-- (IP_R1:500 -> IP_I1:500) 280 HDR, SAr1, KEr, Nr, 281 N(NAT_DETECTION_*_IP) 283 2) (IP_I1:500 -> IP_R1:500) 284 HDR, SK { IDi, CERT, AUTH, 285 CP(CFG_REQUEST), 286 SAi2, TSi, TSr, 287 N(MOBIKE_SUPPORTED) } --> 289 <-- (IP_R1:500 -> IP_I1:500) 290 HDR, SK { IDr, CERT, AUTH, 291 CP(CFG_REPLY), 292 SAr2, TSi, TSr, 293 N(MOBIKE_SUPPORTED) } 295 (Initiator gets information from lower layers that its attachment 296 point and address have changed.) 298 3) (IP_I2:500 -> IP_R1:500) 299 HDR, SK { N(UPDATE_SA_ADDRESSES), 300 N(NAT_DETECTION_*_IP) } --> 302 <-- (IP_R1:500 -> IP_I2:500) 303 HDR, SK { N(NAT_DETECTION_*_IP) } 305 (Responder verifies that the initiator has given it 306 a correct IP address.) 308 4) <-- (IP_R1:500 -> IP_I2:500) 309 HDR, SK { N(COOKIE2) } 311 (IP_I2:500 -> IP_R1:500) 312 HDR, SK { N(COOKIE2) } --> 314 Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform 315 each other that they support MOBIKE. In step 3, the initiator 316 notices a change in its own address, and informs the responder about 317 this by sending an INFORMATIONAL request containing the 318 UPDATE_SA_ADDRESSES notification. The request is sent using the new 319 IP address. At this point, it also starts to use the new address as 320 a source address in its own outgoing ESP traffic. Upon receiving the 321 UPDATE_SA_ADDRESSES notification the responder records the new 322 address, and if so required by policy, performs a return routability 323 check of the address. When this check (step 4) completes, the 324 responder starts to use the new address as the destination for its 325 outgoing ESP traffic. 327 Another protocol run in a multihoming scenario is illustrated below. 328 In this scenario, the initiator has one address but the responder has 329 two. 331 Initiator Responder 332 ----------- ----------- 333 1) (IP_I1:500 -> IP_R1:500) 334 HDR, SAi1, KEi, Ni, 335 N(NAT_DETECTION_*_IP) --> 337 <-- (IP_R1:500 -> IP_I1:500) 338 HDR, SAr1, KEr, Nr, 339 N(NAT_DETECTION_*_IP) 341 2) (IP_I1:500 -> IP_R1:500) 342 HDR, SK { IDi, CERT, AUTH, 343 CP(CFG_REQUEST), 344 SAi2, TSi, TSr, 345 N(MOBIKE_SUPPORTED) } --> 347 <-- (IP_R1:500 -> IP_I1:500) 348 HDR, SK { IDr, CERT, AUTH, 349 CP(CFG_REPLY), 350 SAr2, TSi, TSr, 351 N(MOBIKE_SUPPORTED), 352 N(ADDITIONAL_IPV4_ADDRESS) } 354 (The initiator suspects a problem in the currently used address pair, 355 and probes its liveness.) 357 3) (IP_I1:500 -> IP_R1:500) 358 HDR, SK { N(NAT_DETECTION_*_IP) } --> 360 (IP_I1:500 -> IP_R1:500) 361 HDR, SK { N(NAT_DETECTION_*_IP) } --> 363 ... 365 (Eventually, the initiator gives up on the current address pair, and 366 tests the other available address pair.) 367 4) (IP_I1:500 -> IP_R2:500) 368 HDR, SK { N(NAT_DETECTION_*_IP) } 370 <-- (IP_R2:500 -> IP_I1:500) 371 HDR, SK { N(NAT_DETECTION_*_IP) } 373 (This worked, and the initiator requests the peer to switch to new 374 addresses.) 376 5) (IP_I1:500 -> IP_R2:500) 377 HDR, SK { N(UPDATE_SA_ADDRESSES), 378 N(NAT_DETECTION_*_IP), 379 N(COOKIE2) } --> 381 <-- (IP_R2:500 -> IP_I1:500) 382 HDR, SK { N(NAT_DETECTION_*_IP), 383 N(COOKIE2) } 385 2.3. MOBIKE and Network Address Translation (NAT) 387 In some MOBIKE scenarios the network may contain NATs or stateful 388 packet filters (for brevity, the rest of this document talks simply 389 about NATs). The NAT Traversal feature specified in [IKEv2] allows 390 IKEv2 to work through NATs in many cases, and MOBIKE can leverage 391 this functionality: when the addresses used for IPsec SAs are 392 changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed. 394 Nevertheless, there are some limitations because NATs usually 395 introduce an asymmetry in the network: only packets coming from the 396 "inside" cause state to be created. This asymmetry leads to 397 restrictions on what MOBIKE can do. To give a concrete example, 398 consider a situation where both peers have only a single address, and 399 the initiator is behind a NAT. If the responder's address now 400 changes, it needs to send a packet to the initiator using its new 401 address. However, if the NAT is, for instance, of the common 402 "restricted cone" type (see [STUN] for one description of different 403 NAT types), this is not possible: the NAT will drop packets sent from 404 the new address (unless the initiator has previously sent a packet to 405 that address -- which it cannot do until it knows the address). 407 For simplicity, MOBIKE does not attempt to handle all possible NAT- 408 related scenarios. Instead, MOBIKE assumes that if NATs are present, 409 the initiator is the party "behind" the NAT, and does not fully 410 support the case where the responder's addresses change. 412 "Does not fully support" means that no special effort is made to 413 support this functionality. Responders may also be unaware of NATs 414 or specific types of NATs they are behind. However, when a change 415 has occurred that will cause a loss of connectivity, MOBIKE 416 responders will still attempt to inform the initiator of the change. 417 Depending on, for instance, the exact type of NAT, it may or may not 418 succeed. However, analyzing the exact circumstances when this will 419 or will not work is not done in this document. 421 3. Protocol Exchanges 423 3.1. Initial IKE Exchange 425 The initiator is responsible for finding a working pair of addresses 426 so that the initial IKE exchange can be carried out. Any information 427 from MOBIKE extensions will only be available later, when the 428 exchange has progressed far enough. Exactly how the addresses used 429 for the initial exchange are discovered is beyond the scope of this 430 specification; typical sources of information include local 431 configuration and DNS. 433 If either or both of the peers have multiple addresses, some 434 combinations may not work. Thus, the initiator SHOULD try various 435 source and destination address combinations when retransmitting the 436 IKE_SA_INIT request. 438 3.2. Signaling Support for MOBIKE 440 Implementations that wish to use MOBIKE for a particular IKE_SA MUST 441 include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in 442 case of multiple IKE_AUTH exchanges, in the message containing the SA 443 payload). 445 The format of the MOBIKE_SUPPORTED notification is described in 446 Section 4. 448 3.3. Initial Tunnel Header Addresses 450 When an IPsec SA is created, the tunnel header IP addresses (and 451 port, if doing UDP encapsulation) are taken from the IKE_SA, not the 452 IP header of the IKEv2 message requesting the IPsec SA. The 453 addresses in the IKE_SA are initialized as follows: If the 454 IKE_SA_INIT request contains the NAT_DETECTION_*_IP notifications and 455 the responder supports NAT Traversal, the values are initialized from 456 the IP header of the first IKE_AUTH request. Otherwise, the values 457 are initialized from the IP header of the IKE_SA_INIT request. 459 The addresses are taken from the IKE_AUTH request when NAT Traversal 460 is being used because IKEv2 requires changing from port 500 to 4500 461 if a NAT is discovered. To simplify things, implementations that 462 support both this specification and NAT Traversal MUST change to port 463 4500 if the correspondent also supports both, even if no NAT was 464 detected between them (this way, there is no need to change the ports 465 later). 467 3.4. Additional Addresses 469 Both the initiator and responder MAY include one or more 470 ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in 471 the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the 472 message containing the SA payload). 474 Initiator Responder 475 ----------- ----------- 476 HDR, SK { IDi, [CERT], [IDr], AUTH, 477 [CP(CFG_REQUEST)] 478 SAi2, TSi, TSr, 479 N(MOBIKE_SUPPORTED), 480 [N(ADDITIONAL_*_ADDRESS)+] } --> 482 <-- HDR, SK { IDr, [CERT], AUTH, 483 [CP(CFG_REPLY)], 484 SAr2, TSi, TSr, 485 N(MOBIKE_SUPPORTED) 486 [N(ADDITIONAL_*_ADDRESS)+] } 488 The recipient stores this information, but no other action is taken 489 at this time. 491 Although both the initiator and responder maintain a set of peer 492 addresses (logically associated with the IKE_SA), it is important to 493 note that they use this information for slightly different purposes. 495 The initiator uses the set of responder addresses as an input to its 496 address selection policy; it may, at some later point, decide to move 497 the IPsec traffic to one of these addresses using the procedure 498 described in Section 3.5. The responder normally does not use the 499 set of initiator addresses for anything: the addresses are used only 500 when the responder's own addresses change (see Section 3.6). 502 The set of addresses available to the peers can change during the 503 lifetime of the IKE_SA. The procedure for updating this information 504 is described in Section 3.6. 506 Note that if some of the initiator's interfaces are behind a NAT 507 (from the responder's point of view), the addresses received by the 508 responder will be incorrect. This means the procedure for changing 509 responder addresses described in Section 3.6 does not fully work when 510 the initiator is behind a NAT. For the same reason, the peers also 511 SHOULD NOT use this information for any other purpose than what is 512 explicitly described either in this document or a future 513 specification updating it. 515 3.5. Changing Addresses in IPsec SAs 517 In MOBIKE, the initiator decides what addresses are used in the IPsec 518 SAs. That is, the responder usually never updates any IPsec SAs 519 without receiving an explicit UPDATE_SA_ADDRESSES request from the 520 initiator. (As described below, the responder can, however, update 521 the IKE_SA in some circumstances.) 523 The reasons why the initiator wishes to change the addresses are 524 largely beyond the scope of MOBIKE. Typically, triggers include 525 information received from lower layers, such as changes in IP 526 addresses or link-down indications. Some of this information can be 527 unreliable: for instance, ICMP messages could be spoofed by an 528 attacker. Unreliable information SHOULD be treated only as a hint 529 that there might be a problem, and the initiator SHOULD trigger dead 530 peer detection (that is, send an INFORMATIONAL request) to determine 531 if the current path is still usable. 533 Changing addresses can also be triggered by events within IKEv2. At 534 least the following events can cause the initiator to re-evaluate its 535 local address selection policy, possibly leading to changing the 536 addresses. 538 o An IKEv2 request has been re-transmitted several times, but no 539 valid reply has been received. This suggests the current path is 540 no longer working. 542 o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS or 543 NO_ADDITIONAL_ADDRESS notifications is received. This means the 544 peer's addresses may have changed. This is particularly important 545 if the announced set of address no longer contains the currently 546 used address. 548 o An UNACCEPTABLE_ADDRESSES notification is received as a response 549 to address update request (described below). 551 o The initiator receives a NAT_DETECTION_DESTINATION_IP notification 552 that does not match the previous UPDATE_SA_ADDRESSES response (see 553 Section 3.8 for a more detailed description). 555 The description in the rest of this section assumes that the 556 initiator has already decided what the new addresses should be. When 557 this decision has been made, the initiator: 559 o Updates the IKE_SA with the new addresses, and sets the 560 "pending_update" flag in the IKE_SA. 562 o Updates the IPsec SAs associated with this IKE_SA with the new 563 addresses (unless the initiator's policy requires a return 564 routability check before updating the IPsec SAs, and the check has 565 not been done for this responder address yet). 567 o If the IPsec SAs were updated in the previous step: If NAT 568 Traversal is not enabled, and the responder supports NAT Traversal 569 (as indicated by NAT detection payloads in the IKE_SA_INIT 570 exchange), and the initiator either suspects or knows that a NAT 571 is likely to be present, enables NAT Traversal (that is, enables 572 UDP encapsulation of outgoing ESP packets and sending of NAT- 573 Keepalive packets). 575 o If there are outstanding IKEv2 requests (requests for which the 576 initiator has not yet received a reply), continues retransmitting 577 them using the addresses in the IKE_SA (the new addresses). 579 o When the window size allows, sends an INFORMATIONAL request 580 containing the UPDATE_SA_ADDRESSES notification (which does not 581 contain any data), and clears the "pending_update" flag. The 582 request will be as follows: 584 Initiator Responder 585 ----------- ----------- 586 HDR, SK { N(UPDATE_SA_ADDRESSES), 587 [N(NAT_DETECTION_*_IP)], 588 [N(NO_NATS_ALLOWED)], 589 [N(COOKIE2)] } --> 591 o If a new address change occurs while waiting for the response, 592 starts again from the first step (and ignores responses to this 593 UPDATE_SA_ADDRESSES request). 595 When processing an INFORMATIONAL request containing the 596 UPDATE_SA_ADDRESSES notification, the responder: 598 o Determines whether it has already received a newer 599 UPDATE_SA_ADDRESSES request than this one (if the responder uses a 600 window size greater than one, it is possible that requests are 601 received out of order). If it has, a normal response message 602 (described below) is sent, but no other action is taken. 604 o If the NO_NATS_ALLOWED notification is present, processes it as 605 described in Section 3.9. 607 o Checks that the (source IP address, destination IP address) pair 608 in the IP header is acceptable according to local policy. If it 609 is not, replies with a message containing the 610 UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). 612 o Updates the IP addresses in the IKE_SA with the values from the IP 613 header. (Using the address from the IP header is consistent with 614 normal IKEv2, and allows IKEv2 to work with NATs without needing 615 unilateral self-address fixing [UNSAF].) 617 o Replies with an INFORMATIONAL response: 619 Initiator Responder 620 ----------- ----------- 621 <-- HDR, SK { [N(NAT_DETECTION_*_IP)], 622 [N(COOKIE2)] } 624 o If necessary, initiates a return routability check for the new 625 initiator address (see Section 3.7) and waits until the check is 626 completed. 628 o Updates the IPsec SAs associated with this IKE_SA with the new 629 addresses. 631 o If NAT Traversal is supported and NAT detection payloads were 632 included, enables or disables NAT Traversal. 634 When the initiator receives the reply: 636 o If an address change has occurred after the request was first 637 sent, no MOBIKE processing is done for the reply message because a 638 new UPDATE_SA_ADDRESSES is going to be sent (or has already been 639 sent, if window size greater than one is in use). 641 o If the response contains the UNEXPECTED_NAT_DETECTED notification, 642 it processes the response as described in Section 3.9. 644 o If the response contains an UNACCEPTABLE_ADDRESSES notification, 645 the initiator MAY select another addresses and retry the exchange, 646 keep on using the current addresses, or disconnect. 648 o It updates the IPsec SAs associated with this IKE_SA with the new 649 addresses (unless this was already done before sending the 650 request). 652 o If NAT Traversal is supported and NAT detection payloads were 653 included, it enables or disables NAT Traversal. 655 There is one exception to the rule that the responder never updates 656 any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If 657 the source address that the responder is currently using becomes 658 unavailable (i.e., sending packets using that source address is no 659 longer possible), the responder is allowed to update the IPsec SAs to 660 use some other address (in addition to initiating the procedure 661 described in the next section). 663 3.6. Updating Additional Addresses 665 As described in Section 3.4, both the initiator and responder can 666 send a list of additional addresses in the IKE_AUTH exchange. This 667 information can be updated by sending an INFORMATIONAL exchange 668 request message that contains either one or more ADDITIONAL_IP4/ 669 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. 670 The message exchange will look as follows: 672 Initiator Responder 673 ----------- ----------- 674 HDR, SK { [N(ADDITIONAL_*_ADDRESS)+], 675 [N(NO_ADDITIONAL_ADDRESSES)], 676 [N(NO_NATS_ALLOWED)], 677 [N(COOKIE2)] } --> 679 <-- HDR, SK { [N(COOKIE2)] } 681 When a request containing ADDITIONAL_*_ADDRESS or 682 NO_ADDITIONAL_ADDRESSES notification is received, the exchange 683 responder: 685 o Determines whether it has already received a newer request to 686 update the addresses (if a window size greater than one is used, 687 it is possible that the requests are received out of order). If 688 it has, a response message is sent, but the address set is not 689 updated. 691 o If the NO_NATS_ALLOWED notification is present, processes it as 692 described in Section 3.9. 694 o Updates the set of peer addresses based on the IP header and 695 ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS notifications. 697 o Sends a response. 699 The initiator MAY include these notifications in the same request as 700 UPDATE_SA_ADDRESSES. 702 If the request to update the addresses is retransmitted using several 703 different source addresses, a new INFORMATIONAL request MUST be sent. 705 There is one additional complication: when the responder wants to 706 update the address set, the currently used addresses may no longer 707 work. In this case, the responder uses the additional address list 708 received from the initiator, and the list of its own addresses, to 709 determine which addresses to use for sending the INFORMATIONAL 710 request. This is the only time the responder uses the additional 711 address list received from the initiator. 713 Note that both peers can have their own policies about what addresses 714 are acceptable to use, and certain types of policies may simplify 715 implementation. For instance, if the responder has a single fixed 716 address, it does need to process ADDITIONAL_*_ADDRESS notifications 717 it receives (beyond ignoring unrecognized status notifications as 718 already required in [IKEv2]). Furthermore, if the initiator has a 719 policy saying that only the responder address specified in local 720 configuration is acceptable, it does not have to send its own 721 additional addresses to the responder (since the responder does not 722 need them except when changing its own address). 724 3.7. Return Routability Check 726 Both parties can optionally verify that the other party can actually 727 receive packets at the claimed address. By default, this "return 728 routability check" SHOULD be performed. In environments where the 729 peer is expected to be well-behaved (many corporate VPNs, for 730 instance), or the address can be verified by some other means (e.g., 731 the address is included in the peer's certificate), the return 732 routability check MAY be omitted. 734 The check can be done before updating the IPsec SAs, immediately 735 after updating them, or continuously during the connection. By 736 default, the return routability check SHOULD be done before updating 737 the IPsec SAs, but in some environments it MAY be postponed until 738 after the IPsec SAs have been updated. 740 Any INFORMATIONAL exchange can be used for return routability 741 purposes, with one exception (described later in this section): when 742 a valid response is received, we know the other party can receive 743 packets at the claimed address. 745 To ensure that the peer cannot generate the correct INFORMATIONAL 746 response without seeing the request, a new payload is added to 747 INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY 748 include a COOKIE2 notification, and if included, the recipient of an 749 INFORMATIONAL request MUST copy the notification as-is to the 750 response. When processing the response, the original sender MUST 751 verify that the value is the same one as sent. If the values do not 752 match, the IKE_SA MUST be closed. (See also Section 4.6 for the 753 format of the COOKIE2 notification.) 755 The exception mentioned earlier is as follows: If the same 756 INFORMATIONAL request has been sent to several different addresses 757 (i.e., the destination address in the IKE_SA has been updated after 758 the request was first sent), receiving the INFORMATIONAL response 759 does not tell which address is the working one. In this case, a new 760 INFORMATIONAL request needs to be sent to check return routability. 762 3.8. Changes in NAT Mappings 764 IKEv2 performs Dead Peer Detection (DPD) if there has recently been 765 only outgoing traffic on all of the SAs associated with the IKE_SA. 767 In MOBIKE, these messages can also be used to detect if NAT mappings 768 have changed (for example, if the keepalive interval is too long, or 769 the NAT box is rebooted). More specifically, if both peers support 770 both this specification and NAT Traversal, NAT_DETECTION_*_IP 771 notifications MAY be included in any INFORMATIONAL request; if the 772 request includes them, the responder MUST also include them in the 773 response (but no other action is taken, unless otherwise specified). 775 When the initiator is behind a NAT (as detected earlier using 776 NAT_DETECTION_*_IP notifications), it SHOULD include these 777 notifications in DPD messages, and compare the received 778 NAT_DETECTION_DESTINATION_IP notifications with the value from the 779 previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). 780 If the values do not match, the IP address and/or port seen by the 781 responder has changed, and the initiator SHOULD send 782 UPDATE_SA_ADDRESSES as described in Section 3.5. If the initiator 783 suspects that the NAT mapping has changed, it MAY also skip the 784 detection step and send UPDATE_SA_ADDRESSES immediately. This saves 785 one roundtrip if the NAT mapping has indeed changed. 787 Note that this approach to detecting NAT mapping changes may cause an 788 extra address update when the IKE_SA is rekeyed. This is because the 789 NAT_DETECTION_DESTINATION_IP hash also includes the IKE SPIs, which 790 change when performing rekeying. This unnecessary update is 791 harmless, however. 793 When MOBIKE is in use, the dynamic updates specified in [IKEv2] 794 Section 2.23 (where the peer address and port are updated from the 795 last valid authenticated packet) work in a slightly different 796 fashion. The host not behind a NAT MUST NOT use these dynamic 797 updates for IKEv2 packets, but MAY use them for ESP packets. This 798 ensures that an INFORMATIONAL exchange that does not contain 799 UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be 800 used for, e.g., testing whether a particular path works. 802 3.9. NAT Prohibition 804 Basic IKEv2/IPsec without NAT Traversal support may work across some 805 types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in 806 tunnel mode. This is because the IKEv2 integrity checksum does not 807 cover the addresses in the IP header. This may be considered a 808 problem in some circumstances, because in some sense any modification 809 of the IP addresses can be considered an attack. 811 This specification addresses the issue by protecting the IP addresses 812 when NAT Traversal has not been explicitly enabled. This means that 813 MOBIKE without NAT Traversal support will not work if the paths 814 contain NATs, IPv4/IPv6 translation agents, or other nodes that 815 modify the addresses in the IP header. This feature is mainly 816 intended for IPv6 and site-to-site VPN cases, where the 817 administrators may know beforehand that NATs are not present, and 818 thus any modification to the packet can be considered an attack. 820 More specifically, when NAT Traversal is not enabled, all messages 821 that can update the addresses associated with the IKE_SA and/or IPsec 822 SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that 823 contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS 824 notifications) MUST also include a NO_NATS_ALLOWED notification. The 825 exchange responder MUST verify that the contents of the 826 NO_NATS_ALLOWED notification match the addresses in the IP header. 827 If they do not match, a response containing an 828 UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the 829 IKE_SA_INIT exchange, no state is created at the responder). The 830 response message is sent to the address and port that the 831 corresponding request came from, not to the address contained in the 832 NO_NATS_ALLOWED notification. 834 If the exchange initiator receives an UNEXPECTED_NAT_DETECTED 835 notification in response to its request, it SHOULD retry the 836 operation several times using new IKE_SA_INIT/INFORMATIONAL requests. 837 This ensures that an attacker who is able to modify only a single 838 packet does not unnecessarily cause a path to remain unused. 840 If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange 841 responder MUST NOT use the contents of the NO_NATS_ALLOWED 842 notification for any other purpose than possibly logging the 843 information for troubleshooting purposes. 845 3.10. Path Testing 847 IKEv2 Dead Peer Detection allows the peers to detect if the currently 848 used path has stopped working. However, if either of the peers has 849 several addresses, Dead Peer Detection alone does not tell which of 850 the other paths might work. 852 If required by its address selection policy, the initiator can use 853 normal IKEv2 INFORMATIONAL request/response messages to test whether 854 a certain path works. Implementations MAY do path testing even if 855 the path currently being used is working to, for example, detect when 856 a better (but previously unavailable) path becomes available. 858 3.11. Failure Recovery and Timeouts 860 In MOBIKE, the initiator is responsible for detecting and recovering 861 from most failures. 863 To give the initiator enough time to detect the error, the responder 864 SHOULD use relatively long timeout intervals when, for instance, 865 retransmitting IKEv2 requests or deciding whether to initiate dead 866 peer detection. While no specific timeout lengths are required, it 867 is suggested that responders continue retransmitting IKEv2 requests 868 for at least five minutes before giving up. 870 4. Payload Formats 872 This specification defines several new IKEv2 Notify payload types. 873 The UNACCEPTABLE_ADDRESSES and UNEXPECTED_NAT_DETECTED notifications 874 are "error types"; the other notifications are "status types". See 875 [IKEv2] Section 3.10 for a general description of the Notify payload. 877 4.1. MOBIKE_SUPPORTED Notify Payload 879 The MOBIKE_SUPPORTED notification is included in the IKE_AUTH 880 exchange to indicate that the implementation supports this 881 specification. 883 The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The 884 Protocol ID and SPI Size fields are set to zero. The notification 885 data field MUST be left empty (zero-length) when sending, and its 886 contents (if any) MUST be ignored when this notification is received. 887 This allows the field to be used by future versions of this protocol. 889 4.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads 891 Both parties can include ADDITIONAL_IP4_ADDRESS and/or 892 ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and 893 INFORMATIONAL exchange request messages; see Section 3.4 and 894 Section 3.6 for more detailed description. 896 The Notify Message Types for ADDITIONAL_IP4_ADDRESS and 897 ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA2 and TBD-BY-IANA3, 898 respectively. The Protocol ID and SPI Size fields are set to zero. 899 The data associated with these Notify types is either a four-octet 900 IPv4 address or a 16-octet IPv6 address. 902 4.3. NO_ADDITIONAL_ADDRESSES Notify Payload 904 The NO_ADDITIONAL_ADDRESSES notification can be included in an 905 INFORMATIONAL exchange request message to indicate that the exchange 906 initiator does not have addresses beyond the one used in the exchange 907 (see Section 3.6 for more detailed description). 909 The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-IANA4. 910 The Protocol ID and SPI Size fields are set to zero. There is no 911 data associated with this Notify type. 913 4.4. UPDATE_SA_ADDRESSES Notify Payload 915 This notification is included in INFORMATIONAL exchange requests sent 916 by the initiator to update addresses of the IKE_SA and IPsec SAs (see 917 Section 3.5). 919 The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA5. The 920 Protocol ID and SPI Size fields are set to zero. There is no data 921 associated with this Notify type. 923 4.5. UNACCEPTABLE_ADDRESSES Notify Payload 925 The responder can include this notification in an INFORMATIONAL 926 exchange response to indicate that the address change in the 927 corresponding request message (which contained an UPDATE_SA_ADDRESSES 928 notification) was not carried out. 930 The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6. 931 The Protocol ID and SPI Size fields are set to zero. There is no 932 data associated with this Notify type. 934 4.6. COOKIE2 Notify Payload 936 This notification MAY be included in any INFORMATIONAL request for 937 return routability check purposes (see Section 3.7). If the 938 INFORMATIONAL request includes COOKIE2, the exchange responder MUST 939 copy the notification to the response message. 941 The data associated with this notification MUST be between 8 and 64 942 octets in length (inclusive), and MUST be chosen by the exchange 943 initiator in a way that is unpredictable to the exchange responder. 944 The Notify Message Type for this message is TBD-BY-IANA7. The 945 Protocol ID and SPI Size fields are set to zero. 947 4.7. NO_NATS_ALLOWED Notify Payload 949 See Section 3.9 for a description of this notification. 951 The data field of this notification contains the following 952 information: the IP address from which the packet was sent (4 or 16 953 bytes), the port from which the packet was sent (2 bytes, network 954 byte order), the IP addresss to which the packet was sent (4 or 16 955 bytes), and the port to which the packet was sent (2 bytes, network 956 byte order). The total length of the data field is thus 12 bytes for 957 IPv4 and 36 bytes for IPv6. The Notify Message Type for this message 958 is TBD-BY-IANA8. The Protocol ID and SPI Size fields are set to 959 zero. 961 4.8. UNEXPECTED_NAT_DETECTED Notify Payload 963 See Section 3.9 for a description of this notification. 965 The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9. 966 The Protocol ID and SPI Size fields are set to zero. There is no 967 data associated with this Notify type. 969 5. Security Considerations 971 The main goals of this specification are to maintain the security 972 offered by usual IKEv2 procedures and to counter mobility-related 973 threats in an appropriate manner. This section describes new 974 security considerations introduced by MOBIKE. See [IKEv2] for 975 security considerations for IKEv2 in general. 977 5.1. Traffic Redirection and Hijacking 979 MOBIKE payloads relating to updating addresses are encrypted, 980 integrity protected, and replay protected using the IKE_SA. This 981 assures that no one except the participants can, for instance, give a 982 control message to change the addresses. 984 However, as with normal IKEv2, the actual IP addresses in the IP 985 header are not covered by the integrity protection. This means that 986 a NAT between the parties (or an attacker acting as a NAT) can modify 987 the addresses and cause incorrect tunnel header (outer) IP addresses 988 to be used for IPsec SAs. The scope of this attack is limited mainly 989 to denial-of-service because all traffic is protected using IPsec. 991 This attack can only be launched by on-path attackers that are 992 capable of modifying IKEv2 messages carrying NAT detection payloads 993 (such as Dead Peer Detection messages). By modifying the IP header 994 of these packets, the attackers can lead the peers to believe a new 995 NAT or a changed NAT binding exists between them. The attack can 996 continue as long as the attacker is on the path, modifying the IKEv2 997 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms 998 designed to detect NAT mapping changes will eventually recognize that 999 the intended traffic is not getting through, and will update the 1000 addresses appropriately. 1002 MOBIKE introduces the NO_NATS_ALLOWED notification that is used to 1003 detect modification, by outsiders, of the addresses in the IP header. 1004 Such modifications can only be performed by attackers who are on the 1005 path and capable of modifying the When this notification is used, 1006 communication through NATs and other address translators is 1007 impossible, so it is sent only when not doing NAT Traversal. 1009 5.2. IPsec Payload Protection 1011 The use of IPsec protection on payload traffic protects the 1012 participants against disclosure of the contents of the traffic, 1013 should the traffic end up in an incorrect destination or be 1014 eavesdropped along the way. 1016 However, security associations originally created for the protection 1017 of a specific flow between specific addresses may be updated by 1018 MOBIKE later on. This has to be taken into account if the level of 1019 required protection depends on, for instance, the current location of 1020 the VPN client. 1022 It is recommended that security policies, for peers that are allowed 1023 to use MOBIKE, are configured in a manner that takes into account 1024 that a single security association can be used at different times 1025 through paths of varying security properties. 1027 5.3. Denial-of-Service Attacks Against Third Parties 1029 Traffic redirection may be performed not just to gain access to the 1030 traffic (not very interesting because it is encrypted) or to deny 1031 service to the peers, but also to cause a denial-of-service attack 1032 for a third party. For instance, a high-speed TCP session or a 1033 multimedia stream may be redirected towards a victim host, causing 1034 its communications capabilities to suffer. 1036 The attackers in this threat can be either outsiders or even one of 1037 the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers 1038 can be easily dealt with if the authentication performed in the 1039 initial IKEv2 negotiation can be traced to persons who can be held 1040 responsible for the attack. This may not be the case in all 1041 scenarios, particularly with opportunistic approaches to security. 1043 Normally, such attacks would expire in a short time frame due to the 1044 lack of responses (such as transport layer acknowledgements) from the 1045 victim. However, as described in [Aura02], malicious participants 1046 would typically be able to spoof such acknowledgements and maintain 1047 the traffic flow for an extended period of time. For instance, if 1048 the attacker opened the TCP stream itself before redirecting it to 1049 the victim, the attacker becomes aware of the sequence number space 1050 used in this particular session. 1052 It should also be noted, as shown in [Bombing], that without ingress 1053 filtering in the attacker's network, such attacks are already 1054 possible simply by sending spoofed packets from the attacker to the 1055 victim directly. Furthermore, if the attacker's network has ingress 1056 filtering, this attack is largely prevented for MOBIKE as well. 1057 Consequently, it makes little sense to protect against attacks of 1058 similar nature in MOBIKE. However, it still makes sense to limit the 1059 amplification capabilities provided to attackers, so that they cannot 1060 use stream redirection to send a large number of packets to the 1061 victim by sending just a few packets themselves. 1063 This specification includes return routability tests to limit the 1064 duration of any "third party bombing" attacks by off-path (relative 1065 to the victim) attackers. The tests are authenticated messages that 1066 the peer has to respond to, and can be performed either before the 1067 address change takes effect, immediately afterwards, or even 1068 periodically during the session. The tests contain unpredictable 1069 data, and only someone who has the keys associated with the IKE SA 1070 and has seen the request packet can properly respond to the test. 1072 5.4. Spoofing Network Connectivity Indications 1074 Attackers may spoof various indications from lower layers and the 1075 network in an effort to confuse the peers about which addresses are 1076 or are not working. For example, attackers may spoof link-layer 1077 error messages in an effort to cause the parties to move their 1078 traffic elsewhere or even to disconnect. Attackers may also spoof 1079 information related to network attachments, router discovery, and 1080 address assignments in an effort to make the parties believe they 1081 have Internet connectivity when, in reality, they do not. 1083 This may cause use of non-preferred addresses or even denial-of- 1084 service. 1086 MOBIKE does not provide any protection of its own for indications 1087 from other parts of the protocol stack. These vulnerabilities can be 1088 mitigated through the use of techniques specific to the other parts 1089 of the stack, such as validation of ICMP errors [ICMPAttacks], link 1090 layer security, or the use of [SEND] to protect IPv6 Router and 1091 Neighbor Discovery. 1093 Ultimately, MOBIKE depends on the delivery of IKEv2 messages to 1094 determine which paths can be used. If IKEv2 messages sent using a 1095 particular source and destination addresses reach the recipient and a 1096 reply is received, MOBIKE will usually consider the path working; if 1097 no reply is received even after retransmissions, MOBIKE will suspect 1098 the path is broken. An attacker who can consistently control the 1099 delivery or non-delivery of the IKEv2 messages in the network can 1100 thus influence which addresses actually get used. 1102 5.5. Address and Topology Disclosure 1104 MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications 1105 reveal information about which networks the peers are connected to. 1107 For example, consider a host A with two network interfaces: a 1108 cellular connection and a wired Ethernet connection to a company LAN. 1109 If host A now contacts host B using IKEv2/MOBIKE and sends 1110 ADDITIONAL_IP4/6_ADDRESS notifications, host B receives additional 1111 information it might not otherwise know. If host A used the cellular 1112 connection for the IKEv2/MOBIKE traffic, host B can also see the 1113 company LAN address (and perhaps further guess that host A is used by 1114 an employee of that company). If host A used the company LAN to make 1115 the connection, host B can see that host A has a subscription from 1116 this particular cellular operator. 1118 These additional addresses can also disclose more accurate location 1119 information than just a single address. Suppose that host A uses its 1120 cellular connection for IKEv2/MOBIKE traffic, but also sends an 1121 ADDITIONAL_IP4_ADDRESS notification containing an IP address 1122 corresponding to, say, a wireless LAN at a particular coffee shop 1123 location. It is likely that host B can now make a much better guess 1124 at A's location than would be possible based on the cellular IP 1125 address alone. 1127 Furthermore, as described in Section 3.4, some of the addresses could 1128 also be private addresses behind a NAT. 1130 In many environments, disclosing address information is not a problem 1131 (and indeed it cannot be avoided if the hosts wish to use those 1132 addresses for IPsec traffic). For instance, a remote access VPN 1133 client could consider the corporate VPN gateway sufficiently 1134 trustworthy for this purpose. Furthermore, the ADDITIONAL_IP4/ 1135 6_ADDRESS notifications are sent encrypted, so the addresses are not 1136 visible to eavesdroppers (unless, of course, they are later used for 1137 sending IKEv2/IPsec traffic). 1139 However, if MOBIKE is used in some more opportunistic approach, it 1140 can be desirable to limit the information that is sent. Naturally, 1141 the peers do not have to disclose any addresses they do not want to 1142 use for IPsec traffic. Also, as noted in Section 3.6, an initiator 1143 whose policy is to always use the locally configured responder 1144 address does not have to send any ADDITIONAL_IP4/6_ADDRESS payloads. 1146 6. IANA Considerations 1148 This document does not create any new namespaces to be maintained by 1149 IANA, but it requires new values in namespaces that have been defined 1150 in the IKEv2 base specification [IKEv2]. 1152 This document defines several new IKEv2 notifications whose values 1153 are to be allocated from the "IKEv2 Notify Message Types" namespace. 1155 Notify Message Value 1156 --------------------------- ----- 1157 MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) 1158 ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) 1159 ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) 1160 NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) 1161 UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) 1162 UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) 1163 COOKIE2 TBD-BY-IANA7 (16396..40959) 1164 NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) 1165 UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) 1167 These notifications are described in Section 4. 1169 7. Acknowledgements 1171 This document is a collaborative effort of the entire MOBIKE WG. We 1172 would particularly like to thank Jari Arkko, Francis Dupont, Paul 1173 Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also 1174 incorporates ideas and text from earlier MOBIKE protocol proposals, 1175 including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the 1176 MOBIKE design document [Design]. 1178 8. References 1180 8.1. Normative References 1182 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1183 draft-ietf-ipsec-ikev2-17 (work in progress), 1184 October 2004. 1186 [IPsecArch] 1187 Kent, S. and K. Seo, "Security Architecture for the 1188 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 1189 in progress), March 2005. 1191 [KEYWORDS] 1192 Bradner, S., "Key words for use in RFCs to Indicate 1193 Requirement Levels", RFC 2119, March 1997. 1195 [UDPEncap] 1196 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1197 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1198 RFC 3948, January 2005. 1200 8.2. Informative References 1202 [AddrMgmt] 1203 Dupont, F., "Address Management for IKE version 2", 1204 draft-dupont-ikev2-addrmgmt-07 (work in progress), 1205 May 2005. 1207 [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1208 Location Management", Proc. 18th Annual Computer Security 1209 Applications Conference (ACSAC), December 2002. 1211 [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile 1212 IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), 1213 June 2005. 1215 [DNA4] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", 1216 draft-ietf-dhc-dna-ipv4-15 (work in progress), 1217 August 2005. 1219 [DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting 1220 Network Attachment in IPv6 - Best Current Practices for 1221 hosts", draft-ietf-dna-hosts-01 (work in progress), 1222 June 2005. 1224 [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE 1225 protocol", draft-ietf-mobike-design-02 (work in progress), 1226 February 2005. 1228 [ICMPAttacks] 1229 Gont, F., "ICMP attacks against TCP", 1230 draft-gont-tcpm-icmp-attacks-03 (work in progress), 1231 December 2004. 1233 [Kivinen] Kivinen, T., "MOBIKE protocol", 1234 draft-kivinen-mobike-protocol-00 (work in progress), 1235 February 2004. 1237 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1238 August 2002. 1240 [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1241 in IPv6", RFC 3775, June 2004. 1243 [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO- 1244 IKE)", draft-eronen-mobike-mopo-02 (work in progress), 1245 February 2005. 1247 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1248 Discovery for IP Version 6 (IPv6)", RFC 2461, 1249 December 1998. 1251 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1252 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1254 [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and 1255 Multihoming Extensions for IKEv2 (SMOBIKE)", 1256 draft-eronen-mobike-simple-00 (work in progress), 1257 March 2004. 1259 [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1260 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1261 Through Network Address Translators (NATs)", RFC 3489, 1262 March 2003. 1264 [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- 1265 Address Fixing (UNSAF) Across Network Address 1266 Translation", RFC 3424, November 2002. 1268 Appendix A. Changelog 1270 (This section should be removed by the RFC editor.) 1272 Changes from -04 to -05: 1274 o Editorial fixes and clarifications (issue 44, 47, 48, 49, 50, 53, 1275 62, 66, 67, 68, 69). 1277 o Ignore data in MOBIKE_SUPPORTED (issue 61). 1279 Changes from -03 to -04: 1281 o Copy-editing done by the RFC editor. 1283 Changes from -02 to -03: 1285 o Editorial fixes and clarifications (issues 42 and 43). 1287 o Clarified IANA considerations (issue 42). 1289 o Added security considerations about address and topology 1290 disclosure (issue 42). 1292 o Added a suggestion about retransmission timeout (issue 42). 1294 o Change dynamic address updates: MUST NOT do them based on IKEv2 1295 packets, MAY do based on ESP (issue 34). 1297 o Mandate NAT prohibition if not doing NAT traversal (issue 41). 1299 o Clarified security considerations related to NATs (issue 41). 1301 o Don't use SHA-1 in NO_NATS_ALLOWED, just send the addresses (issue 1302 42). 1304 o Added a short section about path testing. 1306 o Added an example protocol run in Section 1. 1308 Changes from -01 to -02: 1310 o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35, 1311 37). 1313 o Changed terminology related to NAT prohibition (issues 22, 24). 1315 o Rewrote much of the ADDITIONAL_*_ADDRESS text, added 1316 NO_ADDITIONAL_ADDRESSES notification. 1318 o Use NAT detection payloads to detect changes in NAT mappings 1319 (issue 34). 1321 o Removed separate PATH_TEST message (issue 34). 1323 o Clarified processing of UNACCEPTABLE_ADDRESSES when request has 1324 been sent using several different addresses (issue 36). 1326 o Clarified changing of ports 500/4500 (issue 33). 1328 o Updated security considerations (issues 27 and 28). 1330 o No need to include COOKIE2 in non-RR messages (issue 32). 1332 o Many editorial fixes and clarifications (issue 38, 40). 1334 o Use the terms initiator and responder more consistently. 1336 o Clarified that this document does not solve all problems in MOBIKE 1337 WG charter (issue 40). 1339 Changes from -00 to -01: 1341 o Editorial fixes and small clarifications (issues 21, 25, 26, 29). 1343 o Use Protocol ID zero for notifications (issue 30). 1345 o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue 1346 23). 1348 o Use the word "path" only in senses that include the route taken 1349 (issue 29). 1351 Author's Address 1353 Pasi Eronen (editor) 1354 Nokia Research Center 1355 P.O. Box 407 1356 FIN-00045 Nokia Group 1357 Finland 1359 Email: pasi.eronen@nokia.com 1361 Intellectual Property Statement 1363 The IETF takes no position regarding the validity or scope of any 1364 Intellectual Property Rights or other rights that might be claimed to 1365 pertain to the implementation or use of the technology described in 1366 this document or the extent to which any license under such rights 1367 might or might not be available; nor does it represent that it has 1368 made any independent effort to identify any such rights. Information 1369 on the procedures with respect to rights in RFC documents can be 1370 found in BCP 78 and BCP 79. 1372 Copies of IPR disclosures made to the IETF Secretariat and any 1373 assurances of licenses to be made available, or the result of an 1374 attempt made to obtain a general license or permission for the use of 1375 such proprietary rights by implementers or users of this 1376 specification can be obtained from the IETF on-line IPR repository at 1377 http://www.ietf.org/ipr. 1379 The IETF invites any interested party to bring to its attention any 1380 copyrights, patents or patent applications, or other proprietary 1381 rights that may cover technology that may be required to implement 1382 this standard. Please address the information to the IETF at 1383 ietf-ipr@ietf.org. 1385 Disclaimer of Validity 1387 This document and the information contained herein are provided on an 1388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1390 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1391 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1392 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1395 Copyright Statement 1397 Copyright (C) The Internet Society (2005). This document is subject 1398 to the rights, licenses and restrictions contained in BCP 78, and 1399 except as set forth therein, the authors retain all their rights. 1401 Acknowledgment 1403 Funding for the RFC Editor function is currently provided by the 1404 Internet Society.