idnits 2.17.1 draft-ietf-mobike-protocol-04.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 1289. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1266. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1279. ** 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 7, 2005) is 6766 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 417, but not defined == Missing Reference: 'IDr' is mentioned on line 411, but not defined == Unused Reference: 'UDPEncap' is defined on line 1098, 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 10, 2006 October 7, 2005 6 IKEv2 Mobility and Multihoming Protocol (MOBIKE) 7 draft-ietf-mobike-protocol-04.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 10, 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 IPsec Security Associations. A mobile VPN client could use 44 MOBIKE to keep the connection with the VPN gateway active while 45 moving from one address to another. Similarly, a multihomed host 46 could use MOBIKE to move the traffic to a different interface if, for 47 instance, the one currently being used stops working. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 2. Terminology and Notation . . . . . . . . . . . . . . . . . . . 3 53 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 54 3.1. Basic Operation . . . . . . . . . . . . . . . . . . . . . 4 55 3.2. Example Protocol Runs . . . . . . . . . . . . . . . . . . 6 56 3.3. MOBIKE and Network Address Translation (NAT) . . . . . . . 8 57 3.4. Limitations . . . . . . . . . . . . . . . . . . . . . . . 8 58 4. Protocol Exchanges . . . . . . . . . . . . . . . . . . . . . . 9 59 4.1. Signaling Support for MOBIKE . . . . . . . . . . . . . . . 9 60 4.2. Initial Tunnel Header Addresses . . . . . . . . . . . . . 9 61 4.3. Additional Addresses . . . . . . . . . . . . . . . . . . . 9 62 4.4. Changing Addresses in IPsec SAs . . . . . . . . . . . . . 11 63 4.5. Updating Additional Addresses . . . . . . . . . . . . . . 14 64 4.6. Return Routability Check . . . . . . . . . . . . . . . . . 15 65 4.7. Changes in NAT Mappings . . . . . . . . . . . . . . . . . 15 66 4.8. NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 16 67 4.9. Path Testing . . . . . . . . . . . . . . . . . . . . . . . 17 68 4.10. Failure Recovery and Timeouts . . . . . . . . . . . . . . 17 69 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 18 70 5.1. MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 18 71 5.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 18 72 5.3. NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 18 73 5.4. UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 18 74 5.5. UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 19 75 5.6. COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 19 76 5.7. NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 19 77 5.8. UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 19 78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 20 79 6.1. Traffic Redirection and Hijacking . . . . . . . . . . . . 20 80 6.2. IPsec Payload Protection . . . . . . . . . . . . . . . . . 20 81 6.3. Denial-of-Service Attacks Against Third Parties . . . . . 21 82 6.4. Spoofing Network Connectivity Indications . . . . . . . . 22 83 6.5. Address and Topology Disclosure . . . . . . . . . . . . . 22 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 23 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 87 9.1. Normative References . . . . . . . . . . . . . . . . . . . 24 88 9.2. Informative References . . . . . . . . . . . . . . . . . . 25 89 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . . 26 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 29 91 Intellectual Property and Copyright Statements . . . . . . . . . . 30 93 1. Introduction 95 IKEv2 is used for performing mutual authentication and establishing 96 and maintaining IPsec Security Associations (SAs). In the current 97 specifications, the IPsec and IKE SAs are created implicitly between 98 the IP addresses that are used when the IKE_SA is established. These 99 IP addresses are then used as the outer (tunnel header) addresses for 100 tunnel mode IPsec packets. Currently, it is not possible to change 101 these addresses after the IKE_SA has been created. 103 There are scenarios where these IP addresses might change. One 104 example is mobility: a host changes its point of network attachment, 105 and receives a new IP address. Another example is a multihoming host 106 that would like to change to a different interface if, for instance, 107 the currently used interface stops working for some reason. 109 Although the problem can be solved by creating new IKE and IPsec SAs 110 when the addresses need to be changed, this may not be optimal for 111 several reasons. In some cases, creating a new IKE_SA may require 112 user interaction for authentication (entering a code from a token 113 card, for instance). Creating new SAs often also involves expensive 114 calculations and possibly a large number of round-trips. For these 115 reasons, a mechanism for updating the IP addresses of existing IKE 116 and IPsec SAs is needed. The MOBIKE protocol described in this 117 document provides such a mechanism. 119 The main scenario for MOBIKE is enabling a remote access VPN user to 120 move from one address to another without re-establishing all security 121 associations with the VPN gateway. For instance, a user could start 122 from fixed Ethernet in the office, and then disconnect the laptop and 123 move to office wireless LAN. When leaving the office the laptop 124 could start using GPRS, and switch to a different wireless LAN when 125 the user arrives home. MOBIKE updates only the outer (tunnel header) 126 addresses of IPsec SAs, and the addresses and others traffic 127 selectors used inside the tunnel stay unchanged. Thus, mobility can 128 be (mostly) invisible to applications and their connections using the 129 VPN. 131 MOBIKE also supports more complex scenarios where the VPN gateway 132 also has several network interfaces: these interfaces could be 133 connected to different networks or ISPs, they may have may be a mix 134 of IPv4 and IPv6 addresses, and the addresses may change over time. 135 Furthermore, both parties could be VPN gateways relaying traffic for 136 other parties. 138 2. Terminology and Notation 139 When messages containing IKEv2 payloads are described, optional 140 payloads are shown in brackets (for instance, "[FOO]"), and a plus 141 sign indicates that a payload can be repeated one or more times (for 142 instance, "FOO+"). In some cases, the diagrams also show what 143 payloads defined in [IKEv2] would be typically included in, for 144 instance, the IKE_AUTH exchange. These payloads are shown for 145 illustrative purposes only; see [IKEv2] for an authoritative 146 description. 148 When this document talks about updating the source/destination 149 addresses of an IPsec SA, it means updating IPsec-related state so 150 that outgoing ESP/AH packets use those addresses in the tunnel 151 header. Depending on how the nominal division between Security 152 Association Database (SAD), Security Policy Database (SPD), and Peer 153 Authorization Database (PAD) described in [IPsecArch] is actually 154 implemented, an implementation can have several different places that 155 have to be updated. 157 In this document, the term "initiator" means the party who originally 158 initiated the first IKE_SA (in a series of possibly several rekeyed 159 IKE_SAs); "responder" is the other peer. During the lifetime of the 160 IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA 161 exchanges; in this case, the terms "exchange initiator" and "exchange 162 responder" are used. The term "original initiator" (which in [IKEv2] 163 refers to the party who started the latest IKE_SA rekeying) is not 164 used in this document. 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 167 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 168 document are to be interpreted as described in [KEYWORDS]. 170 3. Protocol Overview 172 3.1. Basic Operation 174 MOBIKE allows both parties to have several addresses, and there are 175 up to N*M pairs of IP addresses that could potentially be used. The 176 decision of which of these pairs to use has to take into account 177 several factors. First, the parties may have preferences about which 178 interface should be used, due to performance and cost reasons, for 179 instance. Second, the decision is constrained by the fact that some 180 of the pairs may not work at all due to incompatible IP versions, 181 outages somewhere in the network, problems at the local link at 182 either end, and so on. 184 MOBIKE solves this problem by taking a simple approach: the party 185 that initiated the IKE_SA (the "client" in a remote access VPN 186 scenario) is responsible for deciding which address pair is used for 187 the IPsec SAs, and for collecting the information it needs to make 188 this decision (such as determining which address pairs work or do not 189 work). The other party (the "gateway" in a remote access VPN 190 scenario) simply tells the initiator what addresses it has, but does 191 not update the IPsec SAs until it receives a message from the 192 initiator to do so. 194 Making the decision at the initiator is consistent with how normal 195 IKEv2 works: the initiator decides which addresses it uses when 196 contacting the responder. It also makes sense, especially when the 197 initiator is the mobile node: it is in a better position to decide 198 which of its network interfaces should be used for both upstream and 199 downstream traffic. 201 The details of exactly how the initiator makes the decision, what 202 information is used in making it, how the information is collected, 203 how preferences affect the decision, and when a decision needs to be 204 changed, are largely beyond the scope of MOBIKE. This does not mean 205 that these details are unimportant: on the contrary, they are likely 206 to be crucial in any real system. However, MOBIKE is concerned with 207 these details only to the extent that they are visible in IKEv2/IPsec 208 messages exchanged between the peers (and thus need to be 209 standardized to ensure interoperability). 211 Also, many of these issues are not specific to MOBIKE, but are common 212 with the use of existing hosts in dynamic environments or with 213 mobility protocols such as Mobile IP [MIP4] [MIP6]. A number of 214 mechanisms already exist or are being developed to deal with these 215 issues. For instance, link layer and IP layer mechanisms can be used 216 to track the status of connectivity within the local link [RFC2461]; 217 movement detection is being specified for both IPv4 and IPv6 in 218 [DNA4], [DNA6], and so on. 220 Naturally, updating the addresses of IPsec SAs has to take into 221 account several security considerations. MOBIKE includes two 222 features designed to address these considerations. First, a "return 223 routability" check can be used to verify the addresses provided by 224 the peer. This makes it more difficult to flood third parties with 225 large amounts of traffic. Second, a "NAT prohibition" feature 226 ensures that IP addresses have not been modified by NATs, IPv4/IPv6 227 translation agents, or other similar devices. This feature is mainly 228 intended for site-to-site VPNs where the administrators may know 229 beforehand that NATs are not present, and thus any modification to 230 the packet can be considered to be an attack. 232 3.2. Example Protocol Runs 234 A simple MOBIKE exchange in a mobile scenario is illustrated below: 236 Initiator Responder 237 ----------- ----------- 238 1) HDR, SAi1, KEi, Ni, 239 N(NAT_DETECTION_*_IP) --> 241 <-- HDR, SAr1, KEr, Nr, 242 N(NAT_DETECTION_*_IP) 244 2) HDR, SK { IDi, CERT, AUTH, 245 CP(CFG_REQUEST), 246 SAi2, TSi, TSr, 247 N(MOBIKE_SUPPORTED) } --> 249 <-- HDR, SK { IDr, CERT, AUTH, 250 CP(CFG_REPLY), 251 SAr2, TSi, TSr, 252 N(MOBIKE_SUPPORTED) } 254 (Initiator gets information from lower layers that its attachment 255 point and address has changed.) 257 3) HDR, SK { N(UPDATE_SA_ADDRESSES), 258 N(NAT_DETECTION_*_IP) } --> 260 <-- HDR, SK { N(NAT_DETECTION_*_IP) } 262 (Responder verifies that the initiator has given it 263 a correct IP address.) 265 4) <-- HDR, SK { N(COOKIE2) } 267 HDR, SK { N(COOKIE2) } --> 269 Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform 270 each other that they support MOBIKE. In step 3, the initiator 271 notices a change in its own address, and informs the responder about 272 this. At this point, it also starts to use the new address as a 273 source address in its own outgoing ESP traffic. The responder 274 records the new address, and if so required by policy, performs a 275 return routability check of the address. When this check completes, 276 the responder starts to use the new address as the destination for 277 its outgoing ESP traffic. 279 Another protocol run in a multihoming scenario is illustrated below. 281 In this scenario, the initiator has one address but the responder has 282 two. 284 Initiator Responder 285 ----------- ----------- 286 1) HDR, SAi1, KEi, Ni, 287 N(NAT_DETECTION_*_IP) --> 289 <-- HDR, SAr1, KEr, Nr, 290 N(NAT_DETECTION_*_IP) 292 2) HDR, SK { IDi, CERT, AUTH, 293 CP(CFG_REQUEST), 294 SAi2, TSi, TSr, 295 N(MOBIKE_SUPPORTED) } --> 297 <-- HDR, SK { IDr, CERT, AUTH, 298 CP(CFG_REPLY), 299 SAr2, TSi, TSr, 300 N(MOBIKE_SUPPORTED), 301 N(ADDITIONAL_IPV4_ADDRESS) } 303 (The initiator suspects a problem in the currently used address pair, 304 and probes its liveness.) 306 3) HDR, SK { N(NAT_DETECTION_*_IP) } --> 308 <-- HDR, SK { N(NAT_DETECTION_*_IP) } 310 (The initiator gives up on the current address pair, and tests the 311 other available address pair.) 313 4) HDR, SK { N(NAT_DETECTION_*_IP), 314 N(COOKIE2) } --> 316 <-- HDR, SK { N(NAT_DETECTION_*_IP), 317 N(COOKIE2) } 319 (This worked, and the initiator requests the peer to switch to new 320 addresses.) 322 5) HDR, SK { N(UPDATE_SA_ADDRESSES), 323 N(NAT_DETECTION_*_IP) } --> 325 <-- HDR, SK { N(NAT_DETECTION_*_IP) } 327 3.3. MOBIKE and Network Address Translation (NAT) 329 In some MOBIKE scenarios the network may contain NATs or stateful 330 packet filters (for brevity, the rest of this document talks simply 331 about NATs). The NAT Traversal feature specified in [IKEv2] allows 332 IKEv2 to work through NATs in many cases, and MOBIKE can leverage 333 this functionality: when the addresses used for IPsec SAs are 334 changed, MOBIKE can enable or disable IKEv2 NAT Traversal as needed. 336 Nevertheless, there are some limitations because NATs usually 337 introduce an asymmetry in the network: only packets coming from the 338 "inside" cause state to be created. This asymmetry leads to 339 restrictions on what MOBIKE can do. To give a concrete example, 340 consider a situation where both peers have only a single address, and 341 the initiator is behind a NAT. If the responder's address now 342 changes, it needs to send a packet to the initiator using its new 343 address. However, if the NAT is, for instance, of the common 344 "restricted cone" type (see [STUN] for one description of different 345 NAT types), this is not possible: the NAT will drop packets sent from 346 the new address (unless the initiator has previously sent a packet to 347 that address -- which it cannot do until it knows the address). 349 For simplicity, MOBIKE does not attempt to handle all possible NAT- 350 related scenarios. Instead, MOBIKE assumes that if NATs are present, 351 the initiator is the party "behind" the NAT, and does not fully 352 support the case where the responder's addresses change. 354 "Does not fully support" means that no special effort is made to 355 support this functionality. However, if the alternative is losing 356 connectivity completely, the responder can still attempt to proceed 357 with the change, and depending on, e.g., the exact type of NAT, it 358 may succeed. However, analyzing the exact circumstances when this 359 will or will not work is not done in this document. 361 3.4. Limitations 363 This document focuses on the main scenario outlined in Section 1, and 364 supports only tunnel mode. 366 The base version of the MOBIKE protocol may not cover all potential 367 future use scenarios, such as transport mode, application to securing 368 SCTP, or optimizations desirable in specific circumstances. Future 369 extensions may be defined later to support additional requirements. 371 4. Protocol Exchanges 373 4.1. Signaling Support for MOBIKE 375 Implementations that wish to use MOBIKE for a particular IKE_SA MUST 376 include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in 377 case of multiple IKE_AUTH exchanges, in the message containing the SA 378 payload). 380 The format of the MOBIKE_SUPPORTED notification is described in 381 Section 5. 383 4.2. Initial Tunnel Header Addresses 385 When an IPsec SA is created, the tunnel header IP addresses (and 386 port, if doing UDP encapsulation) are taken from the IKE_SA, not the 387 IP header of the IKEv2 message requesting the IPsec SA. The 388 addresses in the IKE_SA are initialized as follows: If the 389 IKE_SA_INIT request contains the NAT_DETECTION_*_IP notifications and 390 the responder supports NAT Traversal, the values are initialized from 391 the IP header of the first IKE_AUTH request. Otherwise, the values 392 are initialized from the IP header of the IKE_SA_INIT request. 394 The addresses are taken from the IKE_AUTH request when NAT Traversal 395 is being used because IKEv2 requires changing from port 500 to 4500 396 if a NAT is discovered. To simplify things, implementations that 397 support both this specification and NAT Traversal MUST change to port 398 4500 if the correspondent also supports both, even if no NAT was 399 detected between them (this way, there is no need to change the ports 400 later). 402 4.3. Additional Addresses 404 Both the initiator and responder MAY include one or more 405 ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notifications in 406 the IKE_AUTH exchange (in case of multiple IKE_AUTH exchanges, in the 407 message containing the SA payload). 409 Initiator Responder 410 ----------- ----------- 411 HDR, SK { IDi, [CERT], [IDr], AUTH, 412 [CP(CFG_REQUEST)] 413 SAi2, TSi, TSr, 414 N(MOBIKE_SUPPORTED), 415 [N(ADDITIONAL_*_ADDRESS)+] } --> 417 <-- HDR, SK { IDr, [CERT], AUTH, 418 [CP(CFG_REPLY)], 419 SAr2, TSi, TSr, 420 N(MOBIKE_SUPPORTED) 421 [N(ADDITIONAL_*_ADDRESS)+] } 423 The recipient stores this information, but no other action is taken 424 at this time. 426 Although both the initiator and responder maintain a set of peer 427 addresses (logically associated with the IKE_SA), it is important to 428 note that they use this information for slightly different purposes. 430 The initiator uses the set of responder addresses as an input to its 431 address selection policy; it may, at some later point, decide to move 432 the IPsec traffic to one of these addresses using the procedure 433 described in Section 4.4. The responder normally does not use the 434 set of initiator addresses for anything: the addresses are used only 435 when the responder's own addresses change (see Section 4.5). 437 The set of addresses available to the peers can change during the 438 lifetime of the IKE_SA. The procedure for updating this information 439 is described in Section 4.5. 441 Note that if some of the initiator's interfaces are behind a NAT 442 (from the responder's point of view), the addresses received by the 443 responder will be incorrect. This means the procedure for changing 444 responder addresses described in Section 4.5 does not fully work when 445 the initiator is behind a NAT. For the same reason, the peers also 446 SHOULD NOT use this information for any other purposes than what is 447 explicitly described in this document. 449 4.4. Changing Addresses in IPsec SAs 451 In MOBIKE, the initiator decides what addresses are used in the IPsec 452 SAs. That is, the responder usually never updates any IPsec SAs 453 without receiving an explicit UPDATE_SA_ADDRESSES request from the 454 initiator. (As described below, the responder can, however, update 455 the IKE_SA in some circumstances.) 457 The reasons why the initiator wishes to change the addresses are 458 largely beyond the scope of MOBIKE. Typically, triggers include 459 information received from lower layers, such as changes in IP 460 addresses or link-down indications. Some of this information can be 461 unreliable: for instance, ICMP messages could be spoofed by an 462 attacker. Unreliable information itself MUST NOT be used to conclude 463 than an update is needed: instead, the initiator SHOULD trigger dead 464 peer detection (that is, send an INFORMATIONAL request). 466 Changing addresses can also be triggered by events within IKEv2. At 467 least the following events can cause the initiator to re-evaluate its 468 local address selection policy, possibly leading to changing the 469 addresses. 471 o An IKEv2 request has been re-transmitted several times, but no 472 valid reply has been received. This suggests the current path is 473 no longer working. 475 o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS 476 notifications is received. This means the peer's addresses may 477 have changed. 479 o An UNACCEPTABLE_ADDRESSES notification is received as a response 480 to address update request (described below). 482 o The initiator receives a NAT_DETECTION_DESTINATION_IP notification 483 that does not match the previous UPDATE_SA_ADDRESSES response (see 484 Section 4.7 for a more detailed description). 486 The description in the rest of this section assumes that the 487 initiator has already decided what the new addresses should be. When 488 this decision has been made, the initiator: 490 o Updates the IKE_SA with the new addresses, and sets the 491 "pending_update" flag in the IKE_SA. 493 o Updates the IPsec SAs associated with this IKE_SA with the new 494 addresses (unless the initiator's policy requires a return 495 routability check before updating the IPsec SAs, and the check has 496 not been done for this responder address yet). 498 o If the IPsec SAs were updated in the previous step: If NAT 499 Traversal is not enabled, and the responder supports NAT Traversal 500 (as indicated by NAT detection payloads in the IKE_SA_INIT 501 exchange), and the initiator either suspects or knows that a NAT 502 is likely to be present, enables NAT Traversal. 504 o If there are outstanding IKEv2 requests (requests for which the 505 initiator has not yet received a reply), continues retransmitting 506 them using the addresses in the IKE_SA (the new addresses). 508 o When the window size allows, sends an INFORMATIONAL request 509 containing the UPDATE_SA_ADDRESSES notification (which does not 510 contain any data), and clears the "pending_update" flag. The 511 request will be as follows: 513 Initiator Responder 514 ----------- ----------- 515 HDR, SK { N(UPDATE_SA_ADDRESSES), 516 [N(NAT_DETECTION_*_IP)], 517 [N(NO_NATS_ALLOWED)], 518 [N(COOKIE2)] } --> 520 o If a new address change occurs while waiting for the response, 521 starts again from the first step (and ignores responses to this 522 UPDATE_SA_ADDRESSES request). 524 When processing an INFORMATIONAL request containing the 525 UPDATE_SA_ADDRESSES notification, the responder: 527 o Determines whether it has already received a newer 528 UPDATE_SA_ADDRESSES request than this one (if the responder uses a 529 window size greater than one, it is possible that requests are 530 received out of order). If it has, a normal response message 531 (described below) is sent, but no other action is taken. 533 o If the NO_NATS_ALLOWED notification is present, processes it as 534 described in Section 4.8. 536 o Checks that the (source IP address, destination IP address) pair 537 in the IP header is acceptable according to local policy. If it 538 is not, replies with a message containing the 539 UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). 541 o Updates the IP addresses in the IKE_SA with the values from the IP 542 header. (Using the address from the IP header is consistent with 543 normal IKEv2, and allows IKEv2 to work with NATs without needing 544 unilateral self-address fixing [UNSAF].) 546 o Replies with an INFORMATIONAL response: 548 Initiator Responder 549 ----------- ----------- 550 <-- HDR, SK { [N(NAT_DETECTION_*_IP)], 551 [N(COOKIE2)] } 553 o If necessary, initiates a return routability check for the new 554 initiator address (see Section 4.6) and waits until the check is 555 completed. 557 o Updates the IPsec SAs associated with this IKE_SA with the new 558 addresses. 560 o If NAT Traversal is supported and NAT detection payloads were 561 included, enables or disables NAT Traversal. 563 When the initiator receives the reply: 565 o If an address change has occurred after the request was first 566 sent, no MOBIKE processing is done for the reply message because a 567 new UPDATE_SA_ADDRESSES is going to be sent (or has already been 568 sent, if window size greater than one is in use). 570 o If the response contains the UNEXPECTED_NAT_DETECTED notification, 571 it processes the response as described in Section 4.8. 573 o If the response contains an UNACCEPTABLE_ADDRESSES notification, 574 the initiator MAY select another addresses and retry the exchange, 575 keep on using the current addresses, or disconnect. 577 o It updates the IPsec SAs associated with this IKE_SA with the new 578 addresses (unless this was already done before sending the 579 request). 581 o If NAT Traversal is supported and NAT detection payloads were 582 included, it enables or disables NAT Traversal. 584 There is one exception to the rule that the responder never updates 585 any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If 586 the source address that the responder is currently using becomes 587 unavailable (i.e., sending packets using that source address is no 588 longer possible), the responder is allowed to update the IPsec SAs to 589 use some other address (in addition to initiating the procedure 590 described in the next section). 592 4.5. Updating Additional Addresses 594 As described in Section 4.3, both the initiator and responder can 595 send a list of additional addresses in the IKE_AUTH exchange. This 596 information can be updated by sending an INFORMATIONAL exchange 597 request message that contains either one or more ADDITIONAL_IP4/ 598 6_ADDRESS notifications or the NO_ADDITIONAL_ADDRESSES notification. 599 The message exchange will look as follows: 601 Initiator Responder 602 ----------- ----------- 603 HDR, SK { [N(ADDITIONAL_*_ADDRESS)+], 604 [N(NO_ADDITIONAL_ADDRESSES)], 605 [N(NO_NATS_ALLOWED)], 606 [N(COOKIE2)] } --> 608 <-- HDR, SK { [N(COOKIE2)] } 610 When a request containing ADDITIONAL_*_ADDRESS or 611 NO_ADDITIONAL_ADDRESSES notification is received, the exchange 612 responder: 614 o Determines whether it has already received a newer request to 615 update the addresses (if a window size greater than one is used, 616 it is possible that the requests are received out of order). If 617 it has, a response message is sent, but the address set is not 618 updated. 620 o If the NO_NATS_ALLOWED notification is present, processes it as 621 described in Section 4.8. 623 o Updates the set of peer addresses based on the IP header and 624 ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS notifications. 626 o Sends a response. 628 The initiator MAY include these notifications in the same request as 629 UPDATE_SA_ADDRESSES. 631 If the request to update the addresses is retransmitted using several 632 different source addresses, a new INFORMATIONAL request MUST be sent. 634 There is one additional complication: when the responder wants to 635 update the address set, the currently used addresses may no longer 636 work. In this case, the responder uses the additional address list 637 received from the initiator, and the list of its own addresses, to 638 determine which addresses to use for sending the INFORMATIONAL 639 request. This is the only time the responder uses the additional 640 address list received from the initiator. 642 Note that both peers can have their own policies about what addresses 643 are acceptable to use. A minimal "mobile client" could have a policy 644 that says that only the responder's address specified in local 645 configuration is acceptable. This kind of client does not have to 646 send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a 647 simple "VPN gateway" that has only a single address, and is not going 648 to change it, does not need to send or understand 649 ADDITIONAL_*_ADDRESS notifications. 651 4.6. Return Routability Check 653 Both parties can optionally verify that the other party can actually 654 receive packets at the claimed address. This "return routability 655 check" can be done before updating the IPsec SAs, immediately after 656 updating them, or continuously during the connection. 658 By default, the return routability check SHOULD be done before 659 updating the IPsec SAs. In environments where the peer is expected 660 to be well-behaved (many corporate VPNs, for instance), or the 661 address can be verified by some other means (e.g., the address is 662 included in the peer's certificate), the return routability check MAY 663 be omitted or postponed until after the IPsec SAs have been updated. 665 Any INFORMATIONAL exchange can be used for return routability 666 purposes, with one exception: when a valid response is received, we 667 know the other party can receive packets at the claimed address. 669 To ensure that the peer cannot generate the correct INFORMATIONAL 670 response without seeing the request, a new payload is added to 671 INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY 672 include a COOKIE2 notification, and if included, the recipient of an 673 INFORMATIONAL request MUST copy the notification as-is to the 674 response. When processing the response, the original sender MUST 675 verify that the value is the same one as sent. If the values do not 676 match, the IKE_SA MUST be closed. 678 If the same INFORMATIONAL request has been sent to several different 679 addresses (i.e., the destination address in the IKE_SA has been 680 updated after the request was first sent), receiving the 681 INFORMATIONAL response does not tell which address is the working 682 one. In this case, a new INFORMATIONAL request needs to be sent to 683 check return routability. 685 4.7. Changes in NAT Mappings 687 IKEv2 performs Dead Peer Detection (DPD) if there has recently been 688 only outgoing traffic on all of the SAs associated with the IKE_SA. 690 In MOBIKE, these messages can also be used to detect if NAT mappings 691 have changed (for example, if the keepalive internal is too long, or 692 the NAT box is rebooted). More specifically, if both peers support 693 both this specification and NAT Traversal, NAT_DETECTION_*_IP 694 notifications MAY be included in any INFORMATIONAL request; if the 695 request includes them, the responder MUST also include them in the 696 response (but no other action is taken, unless otherwise specified). 698 When the initiator is behind a NAT (as detected earlier using 699 NAT_DETECTION_*_IP notifications), it SHOULD include these 700 notifications in DPD messages, and compare the received 701 NAT_DETECTION_DESTINATION_IP notifications with the value from the 702 previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). 703 If the values do not match, the IP address and/or port seen by the 704 responder has changed, and the initiator SHOULD send 705 UPDATE_SA_ADDRESSES as described in Section 4.4. 707 When MOBIKE is in use, the dynamic updates specified in [IKEv2] 708 Section 2.23 (where the peer address and port are updated from the 709 last valid authenticated packet) work in a slightly different 710 fashion. The host not behind a NAT MUST NOT use these dynamic 711 updates for IKEv2 packets, but MAY use them for ESP packets. This 712 ensures that an INFORMATIONAL exchange that does not contain 713 UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be 714 used for, e.g., testing whether a particular path works. 716 4.8. NAT Prohibition 718 Basic IKEv2/IPsec without NAT Traversal support may work across some 719 types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in 720 tunnel mode. This is because the IKEv2 integrity checksum does not 721 cover the addresses in the IP header. This may be considered a 722 problem in some circumstances, because in some sense any modification 723 of the IP addresses can be considered an attack. 725 This specification addresses the issue by protecting the IP addresses 726 when NAT Traversal has not been explicitly enabled. This means that 727 MOBIKE without NAT Traversal support will not work if the paths 728 contain NATs, IPv4/IPv6 translation agents, or other nodes that 729 modify the addresses in the IP header. This feature is mainly 730 intended for site-to-site VPN cases, where the administrators may 731 know beforehand that NATs are not present, and thus any modification 732 to the packet can be considered an attack. 734 More specifically, when NAT Traversal is not enabled, all messages 735 that can update the addresses associated with the IKE_SA and/or IPsec 736 SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that 737 contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS 738 notifications) MUST also include a NO_NATS_ALLOWED notification. The 739 exchange responder MUST verify that the contents of the 740 NO_NATS_ALLOWED notification match the addresses in the IP header. 741 If they do not match, a response containing an 742 UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the 743 IKE_SA_INIT exchange, no state is created at the responder). The 744 response message is sent to the address and port that the 745 corresponding request came from, not to the address contained in the 746 NO_NATS_ALLOWED notification. 748 If the exchange initiator receives an UNEXPECTED_NAT_DETECTION 749 notification in response to its request, it SHOULD retry the 750 operation several times using new IKE_SA_INIT/INFORMATIONAL requests. 751 This ensures that an attacker who is able to modify only a single 752 packet does not unnecessarily cause a path to remain unused. 754 If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange 755 responder MUST NOT use the contents of the NO_NATS_ALLOWED 756 notification for any other purpose than possibly logging the 757 information for troubleshooting purposes. 759 4.9. Path Testing 761 IKEv2 Dead Peer Detection allows the peers to detect if the currently 762 used path has stopped working. However, if either of the peers has 763 several addresses, Dead Peer Detection alone does not tell which of 764 the other paths might work. 766 If required by its address selection policy, the initiator can use 767 normal IKEv2 INFORMATIONAL request/response messages to test whether 768 a certain path works. Implementations MAY do path testing even if 769 the path currently being used is working to, for example, detect when 770 a better (but previously unavailable) path becomes available. 772 4.10. Failure Recovery and Timeouts 774 In MOBIKE, the initiator is responsible for detecting and recovering 775 from most failures. 777 To give the initiator enough time to detect the error, the responder 778 SHOULD use relatively long timeout intervals when, for instance, 779 retransmitting IKEv2 requests or deciding whether to initiate dead 780 peer detection. While no specific timeout lengths are required, it 781 is suggested that responders continue retransmitting IKEv2 requests 782 for at least five minutes before giving up. 784 5. Payload Formats 786 5.1. MOBIKE_SUPPORTED Notify Payload 788 The MOBIKE_SUPPORTED notification is included in the IKE_AUTH 789 exchange to indicate that the implementation supports this 790 specification. 792 The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The 793 Protocol ID and SPI Size fields are set to zero. There is no data 794 associated with this Notify type. 796 5.2. ADDITIONAL_IP4/6_ADDRESS Notify Payloads 798 Both parties can include ADDITIONAL_IP4_ADDRESS and/or 799 ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and 800 INFORMATIONAL exchange request messages; see Section 4.3 and 801 Section 4.5 for more detailed description. 803 The Notify Message Types for ADDITIONAL_IP4_ADDRESS and 804 ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA2 and TBD-BY-IANA3, 805 respectively. The Protocol ID and SPI Size fields are set to zero. 806 The data associated with these Notify types is either a four-octet 807 IPv4 address or a 16-octet IPv6 address. 809 5.3. NO_ADDITIONAL_ADDRESSES Notify Payload 811 The NO_ADDITIONAL_ADDRESSES notification can be included in an 812 INFORMATIONAL exchange request message to indicate that the exchange 813 initiator does not have addresses beyond the one used in the exchange 814 (see Section 4.5 for more detailed description). 816 The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-IANA4. 817 The Protocol ID and SPI Size fields are set to zero. There is no 818 data associated with this Notify type. 820 5.4. UPDATE_SA_ADDRESSES Notify Payload 822 This notification is included in INFORMATIONAL exchange requests sent 823 by the initiator to update addresses of the IKE_SA and IPsec SAs (see 824 Section 4.4). 826 The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA5. The 827 Protocol ID and SPI Size fields are set to zero. There is no data 828 associated with this Notify type. 830 5.5. UNACCEPTABLE_ADDRESSES Notify Payload 832 The responder can include this notification in an INFORMATIONAL 833 exchange response to indicate that the address change in the 834 corresponding request message (which contained an UPDATE_SA_ADDRESSES 835 notification) was not carried out. 837 The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6. 838 The Protocol ID and SPI Size fields are set to zero. There is no 839 data associated with this Notify type. 841 5.6. COOKIE2 Notify Payload 843 This notification MAY be included in any INFORMATIONAL request for 844 return routability check purposes (see Section 4.6). If the 845 INFORMATIONAL request includes COOKIE2, the exchange responder MUST 846 copy the notification to the response message. 848 The data associated with this notification MUST be between 8 and 64 849 octets in length (inclusive), and MUST be chosen by the exchange 850 initiator in a way that is unpredictable to the exchange responder. 851 The Notify Message Type for this message is TBD-BY-IANA7. The 852 Protocol ID and SPI Size fields are set to zero. 854 5.7. NO_NATS_ALLOWED Notify Payload 856 See Section 4.8 for a description of this notification. 858 The data field of this notification contains the following 859 information: the IP address and port from which the packet was sent, 860 and the IP address and port to which the packet was sent. The Notify 861 Message Type for this message is TBD-BY-IANA8. The Protocol ID and 862 SPI Size fields are set to zero. 864 5.8. UNEXPECTED_NAT_DETECTED Notify Payload 866 See Section 4.8 for a description of this notification. 868 The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9. 869 The Protocol ID and SPI Size fields are set to zero. There is no 870 data associated with this Notify type. 872 6. Security Considerations 874 The main goals of this specification are to not reduce the security 875 offered by usual IKEv2 procedures and to counter mobility-related 876 threats in an appropriate manner. This section describes new 877 security considerations introduced by MOBIKE. See [IKEv2] for 878 security considerations for IKEv2 in general. 880 6.1. Traffic Redirection and Hijacking 882 MOBIKE payloads relating to updating addresses are encrypted, 883 integrity protected, and replay protected using the IKE_SA. This 884 assures that no one except the participants can, for instance, give a 885 control message to change the addresses. 887 However, just like with normal IKEv2, the actual IP addresses in the 888 IP header are not covered by the integrity protection. This means 889 that a NAT between the parties (or an attacker acting as a NAT) can 890 modify the addresses and cause incorrect tunnel header (outer) IP 891 addresses to be used for IPsec SAs. The scope of this attack is 892 limited mainly to denial-of-service because all traffic is protected 893 using IPsec. 895 This attack can only be launched by on-path attackers that are 896 capable of modifying IKEv2 messages carrying NAT detection payloads 897 (such as Dead Peer Detection messages). By modifying the IP header 898 of these packets, the attackers can lead the peers to believe a new 899 NAT or a changed NAT binding exists between them. The attack can 900 continue as long as the attacker is on the path, modifying the IKEv2 901 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms 902 designed to detect NAT mapping changes will eventually recognize that 903 the intended traffic is not getting through, and will update the 904 addresses appropriately. 906 MOBIKE introduces the NO_NATS_ALLOWED notification that is used to 907 detect modification, by outsiders, of the addresses in the IP header. 908 When this notification is used, communication through NATs and other 909 address translators is impossible, so it is sent only when not doing 910 NAT Traversal. This feature is mainly intended for site-to-site VPN 911 cases, where the administrators may know beforehand that valid NATs 912 are not present, and thus any modification to the packet can be 913 considered an attack. 915 6.2. IPsec Payload Protection 917 The use of IPsec protection on payload traffic protects the 918 participants against disclosure of the contents of the traffic, 919 should the traffic end up in an incorrect destination or be 920 eavesdropped along the way. 922 However, security associations originally created for the protection 923 of a specific flow between specific addresses may be updated by 924 MOBIKE later on. This has to be taken into account if the level of 925 required protection depends on, for instance, the current location of 926 the VPN client. 928 It is recommended that security policies, for peers that are allowed 929 to use MOBIKE, are configured in a manner that takes into account 930 that a single security association can be used at different times 931 through paths of varying security properties. 933 6.3. Denial-of-Service Attacks Against Third Parties 935 Traffic redirection may be performed not just to gain access to the 936 traffic (not very interesting because it is encrypted) or to deny 937 service to the peers, but also to cause a denial-of-service attack 938 for a third party. For instance, a high-speed TCP session or a 939 multimedia stream may be redirected towards a victim host, causing 940 its communications capabilities to suffer. 942 The attackers in this threat can be either outsiders or even one of 943 the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers 944 can be easily dealt with if the authentication performed in the 945 initial IKEv2 negotiation can be traced to persons who can be held 946 responsible for the attack. This may not be the case in all 947 scenarios, particularly with opportunistic approaches to security. 949 Normally, such attacks would expire in a short time frame due to the 950 lack of responses (such as transport layer acknowledgements) from the 951 victim. However, as described in [Aura02], malicious participants 952 would typically be able to spoof such acknowledgements and maintain 953 the traffic flow for an extended period of time. For instance, if 954 the attacker opened the TCP stream itself before redirecting it to 955 the victim, the attacker becomes aware of the sequence number space 956 used in this particular session. 958 It should also be noted, as shown in [Bombing], that without ingress 959 filtering in the attacker's network, such attacks are already 960 possible simply by sending spoofed packets from the attacker to the 961 victim directly. Furthermore, if the attacker's network has ingress 962 filtering, this attack is largely prevented for MOBIKE as well. 963 Consequently, it makes little sense to protect against attacks of 964 similar nature in MOBIKE. However, it still makes sense to limit the 965 amplification capabilities provided to attackers, so that they cannot 966 use stream redirection to send a large number of packets to the 967 victim by sending just a few packets themselves. 969 This specification includes return routability tests to limit the 970 duration of any "third party bombing" attacks by off-path (relative 971 to the victim) attackers. The tests are authenticated messages that 972 the peer has to respond to, and can be performed either before the 973 address change takes effect, immediately afterwards, or even 974 periodically during the session. The tests contain unpredictable 975 data, and only someone who has the keys associated with the IKE SA 976 and has seen the request packet can properly respond to the test. 978 6.4. Spoofing Network Connectivity Indications 980 Attackers may spoof various indications from lower layers and the 981 network in an effort to confuse the peers about which addresses are 982 or are not working. For example, attackers may spoof link-layer 983 error messages in an effort to cause the parties to move their 984 traffic elsewhere or even to disconnect. Attackers may also spoof 985 information related to network attachments, router discovery, and 986 address assignments in an effort to make the parties believe they 987 have Internet connectivity when, in reality, they do not. 989 This may cause use of non-preferred addresses or even denial-of- 990 service. 992 MOBIKE does not provide any protection of its own for indications 993 from other parts of the protocol stack. These vulnerabilities can be 994 mitigated through the use of techniques specific to the other parts 995 of the stack, such as validation of ICMP errors [ICMPAttacks], link 996 layer security, or the use of [SEND] to protect IPv6 Router and 997 Neighbor Discovery. 999 Ultimately, MOBIKE depends on the delivery of IKEv2 messages to 1000 determine which paths can be used. If IKEv2 messages sent using a 1001 particular source and destination addresses reach the recipient and a 1002 reply is received, MOBIKE will usually consider the path working; if 1003 no reply is received even after retransmissions, MOBIKE will suspect 1004 the path is broken. An attacker who can consistently control the 1005 delivery or non-delivery of the IKEv2 messages in the network can 1006 thus influence which addresses actually get used. 1008 6.5. Address and Topology Disclosure 1010 MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications 1011 reveal information about which networks the peers are connected to. 1013 For example, consider a host A with two network interfaces: a 1014 cellular connection and a wired Ethernet connection to a company LAN. 1015 If host A now contacts host B using IKEv2/MOBIKE and sends 1016 ADDITIONAL_IP4/6_ADDRESS notifications, host B receives additional 1017 information it might not otherwise know. If host A used the cellular 1018 connection for the IKEv2/MOBIKE traffic, host B can also see the 1019 company LAN address (and perhaps further guess that host A is used by 1020 an employee of that company). If host A used the company LAN to make 1021 the connection, host B can see that host A has a subscription from 1022 this particular cellular operator. 1024 These additional addresses can also disclose more accurate location 1025 information than just a single address. Suppose that host A uses its 1026 cellular connection for IKEv2/MOBIKE traffic, but also sends an 1027 ADDITIONAL_IP4_ADDRESS notification containing an IP address 1028 corresponding to, say, a wireless LAN at a particular coffee shop 1029 location. It is likely that host B can now make a much better guess 1030 at A's location than would be possible based on the cellular IP 1031 address alone. 1033 Furthermore, as described in Section 4.3, some of the addresses could 1034 also be private addresses behind a NAT. 1036 In many environments, disclosing address information is not a problem 1037 (and indeed it cannot be avoided if the hosts wish to use those 1038 addresses for IPsec traffic). For instance, a remote access VPN 1039 client could consider the corporate VPN gateway sufficiently 1040 trustworthy for this purpose. 1042 However, if MOBIKE is used in some more opportunistic approach, it 1043 can be desirable to limit the information that is sent. Naturally, 1044 the peers do not have to disclose any addresses they do not want to 1045 use for IPsec traffic. Also, as noted in Section 4.5, an initiator 1046 whose policy is to always use the locally configured responder 1047 address does not have to send any ADDITIONAL_IP4/6_ADDRESS payloads. 1049 7. IANA Considerations 1051 This document does not create any new namespaces to be maintained by 1052 IANA, but it requires new values in namespaces that have been defined 1053 in the IKEv2 base specification [IKEv2]. 1055 This document defines several new IKEv2 notifications whose values 1056 are to be allocated from the "IKEv2 Notify Message Types" namespace. 1058 Notify Message Value 1059 --------------------------- ----- 1060 MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) 1061 ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) 1062 ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) 1063 NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) 1064 UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) 1065 UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) 1066 COOKIE2 TBD-BY-IANA7 (16396..40959) 1067 NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) 1068 UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) 1070 These notifications are described in Section 5. 1072 8. Acknowledgements 1074 This document is a collaborative effort of the entire MOBIKE WG. We 1075 would particularly like to thank Jari Arkko, Francis Dupont, Paul 1076 Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also 1077 incorporates ideas and text from earlier MOBIKE protocol proposals, 1078 including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the 1079 MOBIKE design document [Design]. 1081 9. References 1083 9.1. Normative References 1085 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1086 draft-ietf-ipsec-ikev2-17 (work in progress), 1087 October 2004. 1089 [IPsecArch] 1090 Kent, S. and K. Seo, "Security Architecture for the 1091 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 1092 in progress), March 2005. 1094 [KEYWORDS] 1095 Bradner, S., "Key words for use in RFCs to Indicate 1096 Requirement Levels", RFC 2119, March 1997. 1098 [UDPEncap] 1099 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1100 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1101 RFC 3948, January 2005. 1103 9.2. Informative References 1105 [AddrMgmt] 1106 Dupont, F., "Address Management for IKE version 2", 1107 draft-dupont-ikev2-addrmgmt-07 (work in progress), 1108 May 2005. 1110 [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1111 Location Management", Proc. 18th Annual Computer Security 1112 Applications Conference (ACSAC), December 2002. 1114 [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile 1115 IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), 1116 June 2005. 1118 [DNA4] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", 1119 draft-ietf-dhc-dna-ipv4-15 (work in progress), 1120 August 2005. 1122 [DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting 1123 Network Attachment in IPv6 - Best Current Practices for 1124 hosts", draft-ietf-dna-hosts-01 (work in progress), 1125 June 2005. 1127 [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE 1128 protocol", draft-ietf-mobike-design-02 (work in progress), 1129 February 2005. 1131 [ICMPAttacks] 1132 Gont, F., "ICMP attacks against TCP", 1133 draft-gont-tcpm-icmp-attacks-03 (work in progress), 1134 December 2004. 1136 [Kivinen] Kivinen, T., "MOBIKE protocol", 1137 draft-kivinen-mobike-protocol-00 (work in progress), 1138 February 2004. 1140 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1141 August 2002. 1143 [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1144 in IPv6", RFC 3775, June 2004. 1146 [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO- 1147 IKE)", draft-eronen-mobike-mopo-02 (work in progress), 1148 February 2005. 1150 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1151 Discovery for IP Version 6 (IPv6)", RFC 2461, 1152 December 1998. 1154 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1155 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1157 [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and 1158 Multihoming Extensions for IKEv2 (SMOBIKE)", 1159 draft-eronen-mobike-simple-00 (work in progress), 1160 March 2004. 1162 [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1163 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1164 Through Network Address Translators (NATs)", RFC 3489, 1165 March 2003. 1167 [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- 1168 Address Fixing (UNSAF) Across Network Address 1169 Translation", RFC 3424, November 2002. 1171 Appendix A. Changelog 1173 (This section should be removed by the RFC editor.) 1175 Changes from -03 to -04: 1177 o Copy-editing done by the RFC editor. 1179 Changes from -02 to -03: 1181 o Editorial fixes and clarifications (issues 42 and 43). 1183 o Clarified IANA considerations (issue 42). 1185 o Added security considerations about address and topology 1186 disclosure (issue 42). 1188 o Added a suggestion about retransmission timeout (issue 42). 1190 o Change dynamic address updates: MUST NOT do them based on IKEv2 1191 packets, MAY do based on ESP (issue 34). 1193 o Mandate NAT prohibition if not doing NAT traversal (issue 41). 1195 o Clarified security considerations related to NATs (issue 41). 1197 o Don't use SHA-1 in NO_NATS_ALLOWED, just send the addresses (issue 1198 42). 1200 o Added a short section about path testing. 1202 o Added an example protocol run in Section 1. 1204 Changes from -01 to -02: 1206 o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35, 1207 37). 1209 o Changed terminology related to NAT prohibition (issues 22, 24). 1211 o Rewrote much of the ADDITIONAL_*_ADDRESS text, added 1212 NO_ADDITIONAL_ADDRESSES notification. 1214 o Use NAT detection payloads to detect changes in NAT mappings 1215 (issue 34). 1217 o Removed separate PATH_TEST message (issue 34). 1219 o Clarified processing of UNACCEPTABLE_ADDRESSES when request has 1220 been sent using several different addresses (issue 36). 1222 o Clarified changing of ports 500/4500 (issue 33). 1224 o Updated security considerations (issues 27 and 28). 1226 o No need to include COOKIE2 in non-RR messages (issue 32). 1228 o Many editorial fixes and clarifications (issue 38, 40). 1230 o Use the terms initiator and responder more consistently. 1232 o Clarified that this document does not solve all problems in MOBIKE 1233 WG charter (issue 40). 1235 Changes from -00 to -01: 1237 o Editorial fixes and small clarifications (issues 21, 25, 26, 29). 1239 o Use Protocol ID zero for notifications (issue 30). 1241 o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue 1242 23). 1244 o Use the word "path" only in senses that include the route taken 1245 (issue 29). 1247 Author's Address 1249 Pasi Eronen (editor) 1250 Nokia Research Center 1251 P.O. Box 407 1252 FIN-00045 Nokia Group 1253 Finland 1255 Email: pasi.eronen@nokia.com 1257 Intellectual Property Statement 1259 The IETF takes no position regarding the validity or scope of any 1260 Intellectual Property Rights or other rights that might be claimed to 1261 pertain to the implementation or use of the technology described in 1262 this document or the extent to which any license under such rights 1263 might or might not be available; nor does it represent that it has 1264 made any independent effort to identify any such rights. Information 1265 on the procedures with respect to rights in RFC documents can be 1266 found in BCP 78 and BCP 79. 1268 Copies of IPR disclosures made to the IETF Secretariat and any 1269 assurances of licenses to be made available, or the result of an 1270 attempt made to obtain a general license or permission for the use of 1271 such proprietary rights by implementers or users of this 1272 specification can be obtained from the IETF on-line IPR repository at 1273 http://www.ietf.org/ipr. 1275 The IETF invites any interested party to bring to its attention any 1276 copyrights, patents or patent applications, or other proprietary 1277 rights that may cover technology that may be required to implement 1278 this standard. Please address the information to the IETF at 1279 ietf-ipr@ietf.org. 1281 Disclaimer of Validity 1283 This document and the information contained herein are provided on an 1284 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1285 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1286 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1287 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1288 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1289 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1291 Copyright Statement 1293 Copyright (C) The Internet Society (2005). This document is subject 1294 to the rights, licenses and restrictions contained in BCP 78, and 1295 except as set forth therein, the authors retain all their rights. 1297 Acknowledgment 1299 Funding for the RFC Editor function is currently provided by the 1300 Internet Society.