idnits 2.17.1 draft-ietf-mobike-protocol-03.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 1286. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1263. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1270. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1276. ** 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 (September 29, 2005) is 6784 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 1099, 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 2, 2006 September 29, 2005 6 IKEv2 Mobility and Multihoming Protocol (MOBIKE) 7 draft-ietf-mobike-protocol-03.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 2, 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 currently used one 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 . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . 16 66 4.8 NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 16 67 4.9 Path Testing . . . . . . . . . . . . . . . . . . . . . . . 17 68 4.10 Failure Recovery and Timeouts . . . . . . . . . . . . . 17 69 5. Payload Formats . . . . . . . . . . . . . . . . . . . . . . 19 70 5.1 MOBIKE_SUPPORTED Notify Payload . . . . . . . . . . . . . 19 71 5.2 ADDITIONAL_IP4/6_ADDRESS Notify Payloads . . . . . . . . . 19 72 5.3 NO_ADDITIONAL_ADDRESSES Notify Payload . . . . . . . . . . 19 73 5.4 UPDATE_SA_ADDRESSES Notify Payload . . . . . . . . . . . . 19 74 5.5 UNACCEPTABLE_ADDRESSES Notify Payload . . . . . . . . . . 20 75 5.6 COOKIE2 Notify Payload . . . . . . . . . . . . . . . . . . 20 76 5.7 NO_NATS_ALLOWED Notify Payload . . . . . . . . . . . . . . 20 77 5.8 UNEXPECTED_NAT_DETECTED Notify Payload . . . . . . . . . . 20 78 6. Security Considerations . . . . . . . . . . . . . . . . . . 21 79 6.1 Traffic Redirection and Hijacking . . . . . . . . . . . . 21 80 6.2 IPsec Payload Protection . . . . . . . . . . . . . . . . . 21 81 6.3 Denial-of-Service Attacks Against Third Parties . . . . . 22 82 6.4 Spoofing Network Connectivity Indications . . . . . . . . 23 83 6.5 Address and Topology Disclosure . . . . . . . . . . . . . 23 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . 24 85 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25 86 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 25 87 9.1 Normative References . . . . . . . . . . . . . . . . . . . 25 88 9.2 Informative References . . . . . . . . . . . . . . . . . . 26 89 Author's Address . . . . . . . . . . . . . . . . . . . . . . 27 90 A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . 27 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 roundtrips. Due to 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 making it possible for a remote 120 access VPN user to move from one address to another without re- 121 establishing all security associations with the VPN gateway. For 122 instance, a user could start from fixed Ethernet in the office, and 123 then disconnect the laptop and move to office wireless LAN. When 124 leaving the office the laptop could start using GPRS, and switch to a 125 different wireless LAN when the user arrives home. MOBIKE updates 126 only the outer (tunnel header) addresses of IPsec SAs, and the 127 addresses and others traffic selectors used inside the tunnel stay 128 unchanged. Thus, mobility can be (mostly) invisible to applications 129 and their connections using the 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 140 When messages containing IKEv2 payloads are described, optional 141 payloads are shown in brackets (for instance, "[FOO]"), and a plus 142 sign indicates that a payload can be repeated one or more times (for 143 instance, "FOO+"). In some cases, the diagrams also show what 144 payloads defined in [IKEv2] would be typically included in, for 145 instance, the IKE_AUTH exchange. These payloads are shown for 146 illustrative purposes only; see [IKEv2] for an authoritative 147 description. 149 When this document talks about updating the source/destination 150 addresses of an IPsec SA, it means updating IPsec-related state so 151 that outgoing ESP/AH packets use those addresses in the tunnel 152 header. Depending on how the nominal division between Security 153 Association Database (SAD), Security Policy Database (SPD), and Peer 154 Authorization Database (PAD) described in [IPsecArch] is actually 155 implemented, an implementation can have several different places that 156 have to be updated. 158 In this document, the term "initiator" means the party who originally 159 initiated the first IKE_SA (in a series of possibly several rekeyed 160 IKE_SAs); "responder" is the other peer. During the lifetime of the 161 IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA 162 exchanges; in this case, the terms "exchange initiator" and "exchange 163 responder" are used. The term "original initiator" (which in [IKEv2] 164 refers to the party who started the latest IKE_SA rekeying) is not 165 used in this document. 167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 169 document are to be interpreted as described in [KEYWORDS]. 171 3. Protocol Overview 173 3.1 Basic Operation 175 MOBIKE allows both parties to have several addresses, and there are 176 up to N*M pairs of IP addresses that could potentially be used. The 177 decision of which of these pairs to use has to take into account 178 several factors. First, the parties have may preferences about which 179 interface should be used, due to performance and cost reasons, for 180 instance. Second, the decision is constrained by the fact that some 181 of the pairs may not work at all due to incompatible IP versions, 182 outages somewhere in the network, problems at the local link at 183 either end, and so on. 185 MOBIKE solves this problem by taking a simple approach: the party 186 that initiated the IKE_SA (the "client" in remote access VPN 187 scenario) is responsible for deciding which address pair is used for 188 the IPsec SAs, and collecting the information it needs to make this 189 decision (such as determining which address pairs work or do not 190 work). The other party (the "gateway" in remote access VPN scenario) 191 simply tells the initiator what addresses it has, but does not update 192 the IPsec SAs until it receives a message from the initiator to do 193 so. 195 Making the decision at the initiator is consistent with how normal 196 IKEv2 works: the initiator decides which addresses it uses when 197 contacting the responder. It also makes sense especially when the 198 initiator is the mobile node: it is in a better position to decide 199 which of its network interfaces should be used for both upstream and 200 downstream traffic. 202 The details of exactly how the initiator makes the decision, what 203 information is used in making it, how the information is collected, 204 how preferences affect the decision, and when a decision needs to be 205 changed, are largely beyond the scope of MOBIKE. This does not mean 206 that these details are unimportant: on the contrary, they are likely 207 to be crucial in any real system. However, MOBIKE is concerned with 208 these details only to the extent that they are visible in IKEv2/IPsec 209 messages exchanged between the peers (and thus need to be 210 standardized to ensure interoperability). 212 Many of these issues are also not specific to MOBIKE, but common with 213 the use of existing hosts in dynamic environments or with mobility 214 protocols such as Mobile IP [MIP4] [MIP6]. A number of mechanisms 215 already exist or are being developed to deal with these issues. For 216 instance, link layer and IP layer mechanisms can be used to track the 217 status of connectivity within the local link [RFC2461], movement 218 detection is being specified in for both IPv4 and IPv6 [DNA4] [DNA6], 219 and so on. 221 Updating the addresses of IPsec SAs naturally has to take into 222 account several security considerations. MOBIKE includes two 223 features designed to address these considerations. First, a "return 224 routability" check can be used to verify the addresses provided by 225 the peer. This makes it more difficult to flood third parties with 226 large amounts of traffic. Second, a "NAT prohibition" feature 227 ensures that IP addresses have not been modified by NATs, IPv4/IPv6 228 translation agents, or other similar devices. This feature is mainly 229 intended for site-to-site VPNs where the administrators may know 230 beforehand that NATs are not present, and thus any modification to 231 the packet can be considered to be an attack. 233 3.2 Example Protocol Runs 235 A simple MOBIKE exchange in a mobile scenario is illustrated below: 237 Initiator Responder 238 ----------- ----------- 239 1) HDR, SAi1, KEi, Ni, 240 N(NAT_DETECTION_*_IP) --> 242 <-- HDR, SAr1, KEr, Nr, 243 N(NAT_DETECTION_*_IP) 245 2) HDR, SK { IDi, CERT, AUTH, 246 CP(CFG_REQUEST), 247 SAi2, TSi, TSr, 248 N(MOBIKE_SUPPORTED) } --> 250 <-- HDR, SK { IDr, CERT, AUTH, 251 CP(CFG_REPLY), 252 SAr2, TSi, TSr, 253 N(MOBIKE_SUPPORTED) } 255 (Initiator gets information from lower layers that its attachment 256 point and address has changed.) 258 3) HDR, SK { N(UPDATE_SA_ADDRESSES), 259 N(NAT_DETECTION_*_IP) } --> 261 <-- HDR, SK { N(NAT_DETECTION_*_IP) } 263 (Responder verifies that the initiator has given it 264 a correct IP address.) 266 4) <-- HDR, SK { N(COOKIE2) } 268 HDR, SK { N(COOKIE2) } --> 270 Step 1 is the normal IKE_INIT exchange. In step 2, the peers inform 271 each other that they support MOBIKE. In step 3, the initiator 272 notices a change in its own address, and informs the responder about 273 this. At this point, it also starts to use the new address as a 274 source address in its own outgoing ESP traffic. The responder 275 records the new address, and if so required by policy, performs a 276 return routability check of the address. When this check completes, 277 the responder starts to use the new address as the destination for 278 its outgoing ESP traffic. 280 Another protocol run in 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 since NATs usually introduce 337 an asymmetry in the network: only packets coming from the "inside" 338 cause state to be created. This asymmetry leads to restrictions on 339 what MOBIKE can do. To give a concrete example, consider a situation 340 where both peers have only a single address, and the initiator is 341 behind a NAT. If the responder's address now changes, it needs to 342 send a packet to the initiator using its new address. However, if 343 the NAT is, for instance, of the common "restricted cone" type (see 344 [STUN] for one description of different NAT types), this is not 345 possible: the NAT will drop packets sent from the new address (unless 346 the initiator has previously sent a packet to that address -- which 347 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 port 386 if doing UDP encapsulation) are taken from the IKE_SA, not the IP 387 header of the IKEv2 message requesting the IPsec SA. The addresses 388 in the IKE_SA are initialized as follows: If the IKE_SA_INIT request 389 contains the NAT_DETECTION_*_IP notifications and the responder 390 supports NAT Traversal, the values are initialized from the IP header 391 of the first IKE_AUTH request. Otherwise, the values are initialized 392 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, it: 565 o If an address change has occurred after the request was first 566 sent, no MOBIKE processing is done for the reply message, since 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 processes it 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 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, 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 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, return routability check SHOULD be done before updating 659 the IPsec SAs. In environments where the peer is expected to be 660 well-behaving (many corporate VPNs, for instance), or the address can 661 be verified by some other means (e.g., the address is included in the 662 peer's certificate), the return routability check MAY be omitted or 663 postponed until after the IPsec SAs have been updated. 665 Any INFORMATIONAL exchange can be used for return routability 666 purposes (with one exception, described below): when a valid response 667 is received, we know the other party can receive packets at the 668 claimed address. 670 To ensure that the peer cannot generate the correct INFORMATIONAL 671 response without seeing the request, a new payload is added to 672 INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY 673 include a COOKIE2 notification, and if included, the recipient of an 674 INFORMATIONAL request MUST copy the notification as-is to the 675 response. When processing the response, the original sender MUST 676 verify that the value is the same one as sent. If the values do not 677 match, the IKE_SA MUST be closed. 679 If the same INFORMATIONAL request has been sent to several different 680 addresses (i.e., the destination address in the IKE_SA has been 681 updated after the request was first sent), receiving the 682 INFORMATIONAL response does not tell which address is the working 683 one. In this case, a new INFORMATIONAL request needs to be sent to 684 check return routability. 686 4.7 Changes in NAT Mappings 688 IKEv2 performs Dead Peer Detection (DPD) if there has recently been 689 only outgoing traffic on all of the SAs associated with the IKE_SA. 691 In MOBIKE, these messages can also be used to detect if NAT mappings 692 have changed (for example, if the keepalive internal is too long, or 693 the NAT box is rebooted). More specifically, if both peers support 694 both this specification and NAT Traversal, NAT_DETECTION_*_IP 695 notifications MAY be included in any INFORMATIONAL request; if the 696 request includes them, the responder MUST also include them in the 697 response (but no other action is taken, unless otherwise specified). 699 When the initiator is behind a NAT (as detected earlier using 700 NAT_DETECTION_*_IP notifications), it SHOULD include these 701 notifications in DPD messages, and compare the received 702 NAT_DETECTION_DESTINATION_IP notifications with the value from the 703 previous UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). 704 If the values do not match, the IP address and/or port seen by the 705 responder has changed, and the initiator SHOULD send 706 UPDATE_SA_ADDRESSES as described in Section 4.4. 708 When MOBIKE is in use, the dynamic updates specified in [IKEv2] 709 Section 2.23 (where the peer address and port are updated from the 710 last valid authenticated packet) work in a slightly different 711 fashion. The host not behind a NAT MUST NOT use these dynamic 712 updates for IKEv2 packets, but MAY use them for ESP packets. This 713 ensures that an INFORMATIONAL exchange that does not contain 714 UPDATE_SA_ADDRESSES does not cause any changes, allowing it to be 715 used for, e.g., testing whether a particular path works. 717 4.8 NAT Prohibition 719 Basic IKEv2/IPsec without NAT Traversal support may work across some 720 types of one-to-one "basic" NATs and IPv4/IPv6 translation agents in 721 tunnel mode. This is because the IKEv2 integrity checksum does not 722 cover the addresses in the IP header. This may be considered a 723 problem in some circumstances, since in some sense any modification 724 of the IP addresses can be considered to be an attack. 726 This specification addresses the issue by protecting the IP addresses 727 when NAT Traversal has not been explicitly enabled. This means that 728 MOBIKE without NAT Traversal support will not work if the paths 729 contain NATs, IPv4/IPv6 translation agents, or other nodes that 730 modify the addresses in the IP header. This feature is mainly 731 intended for site-to-site VPN cases, where the administrators may 732 know beforehand that NATs are not present, and thus any modification 733 to the packet can be considered to be an attack. 735 More specifically, when NAT Traversal is not enabled, all messages 736 that can update the addresses associated with the IKE_SA and/or IPsec 737 SAs (the IKE_SA_INIT request and all INFORMATIONAL requests that 738 contain UPDATE_SA_ADDRESSES and/or ADDITIONAL_IP4/6_ADDRESS 739 notifications) MUST also include a NO_NATS_ALLOWED notification. The 740 exchange responder MUST verify that the contents of the 741 NO_NATS_ALLOWED notification match the addresses in the IP header. 742 If they do not match, a response containing an 743 UNEXPECTED_NAT_DETECTED notification is sent (and in the case of the 744 IKE_SA_INIT exchange, no state is created at the responder). The 745 response message is sent to the address and port the corresponding 746 request came from, not the address contained in the NO_NATS_ALLOWED 747 notification. 749 If the exchange initiator receives an UNEXPECTED_NAT_DETECTION 750 notification in response to its request, it SHOULD retry the 751 operation several times using new IKE_SA_INIT/INFORMATIONAL requests. 752 This ensures that an attacker who is able to modify only a single 753 packet does not unnecessarily cause a path to remain unused. 755 If an UNEXPECTED_NAT_DETECTED notification is sent, the exchange 756 responder MUST NOT use the contents of the NO_NATS_ALLOWED 757 notification for any other purpose than possibly logging the 758 information for troubleshooting purposes. 760 4.9 Path Testing 762 IKEv2 Dead Peer Detection allows the peers to detect if the currently 763 used path has stopped working. However, if either of the peers has 764 several addresses, Dead Peer Detection alone does not tell which of 765 the other paths might work. 767 If required by its address selection policy, the initiator can use 768 normal IKEv2 INFORMATIONAL request/response messages to test whether 769 a certain path works. Implementations MAY do path testing even if 770 the currenly used path is working to, for example, detect when a 771 better (but previously unavailable) path becomes available. 773 4.10 Failure Recovery and Timeouts 775 In MOBIKE, the initiator is responsible for detecting and recovering 776 from most failures. 778 To give the initiator enough time to detect the error, the responder 779 SHOULD use relatively long timeout intervals when, for instance, 780 retransmitting IKEv2 requests or deciding whether to initiate dead 781 peer detection. While no specific timeout lengths are required, it 782 is suggested that responders continue retransmitting IKEv2 requests 783 for at least five minutes before giving up. 785 5. Payload Formats 787 5.1 MOBIKE_SUPPORTED Notify Payload 789 The MOBIKE_SUPPORTED notification is included in the IKE_AUTH 790 exchange to indicate that the implementation supports this 791 specification. 793 The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA1. The 794 Protocol ID and SPI Size fields are set to zero. There is no data 795 associated with this Notify type. 797 5.2 ADDITIONAL_IP4/6_ADDRESS Notify Payloads 799 Both parties can include ADDITIONAL_IP4_ADDRESS and/or 800 ADDITIONAL_IP6_ADDRESS notifications in the IKE_AUTH exchange and 801 INFORMATIONAL exchange request messages; see Section 4.3 and 802 Section 4.5 for more detailed description. 804 The Notify Message Types for ADDITIONAL_IP4_ADDRESS and 805 ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA2 and TBD-BY-IANA3, 806 respectively. The Protocol ID and SPI Size fields are set to zero. 807 The data associated with these Notify types is either a four-octet 808 IPv4 address or a 16-octet IPv6 address. 810 5.3 NO_ADDITIONAL_ADDRESSES Notify Payload 812 The NO_ADDITIONAL_ADDRESSES notification can be included in an 813 INFORMATIONAL exchange request messages to indicate that the exchange 814 initiator does not have addresses beyond the one used in the exchange 815 (see Section 4.5 for more detailed description). 817 The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY-IANA4. 818 The Protocol ID and SPI Size fields are set to zero. There is no 819 data associated with this Notify type. 821 5.4 UPDATE_SA_ADDRESSES Notify Payload 823 This notification is included in INFORMATIONAL exchange requests sent 824 by the initiator to update addresses of the IKE_SA and IPsec SAs (see 825 Section 4.4). 827 The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA5. The 828 Protocol ID and SPI Size fields are set to zero. There is no data 829 associated with this Notify type. 831 5.5 UNACCEPTABLE_ADDRESSES Notify Payload 833 The responder can include this notification in an INFORMATIONAL 834 exchange response to indicate that the address change in the 835 corresponding request message (which contained an UPDATE_SA_ADDRESSES 836 notification) was not carried out. 838 The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA6. 839 The Protocol ID and SPI Size fields are set to zero. There is no 840 data associated with this Notify type. 842 5.6 COOKIE2 Notify Payload 844 This notification MAY be included in any INFORMATIONAL request for 845 return routability check purposes (see Section 4.6). If the 846 INFORMATIONAL request includes COOKIE2, the exchange responder MUST 847 copy the notification to the response message. 849 The data associated with this notification MUST be between 8 and 64 850 octets in length (inclusive), and MUST be chosen by the exchange 851 initiator in a way that is unpredictable to the exchange responder. 852 The Notify Message Type for this message is TBD-BY-IANA7. The 853 Protocol ID and SPI Size fields are set to zero. 855 5.7 NO_NATS_ALLOWED Notify Payload 857 See Section 4.8 for a description of this notification. 859 The data field of this notification contains the following 860 information: the IP address and port from which the packet was sent, 861 and the IP address and port to which the packet was sent. The Notify 862 Message Type for this message is TBD-BY-IANA8. The Protocol ID and 863 SPI Size fields are set to zero. 865 5.8 UNEXPECTED_NAT_DETECTED Notify Payload 867 See Section 4.8 for a description of this notification. 869 The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY-IANA9. 870 The Protocol ID and SPI Size fields are set to zero. There is no 871 data associated with this Notify type. 873 6. Security Considerations 875 The main goals of this specification are to not reduce the security 876 offered by usual IKEv2 procedures and to counter mobility related 877 threats in an appropriate manner. This section describes new 878 security considerations introduced by MOBIKE. See [IKEv2] for 879 security considerations for IKEv2 in general. 881 6.1 Traffic Redirection and Hijacking 883 MOBIKE payloads relating to updating addresses are encrypted, 884 integrity protected, and replay protected using the IKE_SA. This 885 assures that no one except the participants can, for instance, give a 886 control message to change the addresses. 888 However, just like with normal IKEv2, the actual IP addresses in the 889 IP header are not covered by the integrity protection. This means 890 that a NAT between the parties (or an attacker acting as a NAT) can 891 modify the addresses and cause incorrect tunnel header (outer) IP 892 addresses to be used for IPsec SAs. The scope of this attack is 893 limited mainly to denial-of-service, since all traffic is protected 894 using IPsec. 896 This attack can only be launched by on-path attackers that are 897 capable of modifying IKEv2 messages carrying NAT detection payloads 898 (such as Dead Peer Detection messages). By modifying the IP header 899 of these packets, the attackers can lead the peers believe a new NAT 900 or a changed NAT binding exists between them. The attack can 901 continue as long as the attacker is on the path, modifying the IKEv2 902 messages. If this is no longer the case, IKEv2 and MOBIKE mechanisms 903 designed to detect NAT mapping changes will eventually recognize that 904 the intended traffic is not getting through, and update the addresses 905 appropriately. 907 MOBIKE introduces the NO_NATS_ALLOWED notification that is used to 908 detect modification of the addresses in the IP header by outsiders. 909 When this notification is used, communication through NATs and other 910 address translators is impossible, so it is sent only when not doing 911 NAT Traversal. This feature is mainly intended for site-to-site VPN 912 cases, where the administrators may know beforehand that valid NATs 913 are not present, and thus any modification to the packet can be 914 considered to be an attack. 916 6.2 IPsec Payload Protection 918 The use of IPsec protection on payload traffic protects the 919 participants against disclosure of the contents of the traffic, 920 should the traffic end up in an incorrect destination or be 921 eavesdropped along the way. 923 However, security associations originally created for the protection 924 of a specific flow between specific addresses may be updated by 925 MOBIKE later on. This has to be taken into account if the level of 926 required protection depends on, for instance, the current location of 927 the VPN client. 929 It is recommended that security policies for peers that are allowed 930 to use MOBIKE are configured in a manner that takes into account that 931 a single security association can be used through paths of varying 932 security properties at different times. 934 6.3 Denial-of-Service Attacks Against Third Parties 936 Traffic redirection may be performed not just to gain access to the 937 traffic (not very interesting since it is encrypted) or to deny 938 service to the peers, but also to cause a denial-of-service attack 939 for a third party. For instance, a high-speed TCP session or a 940 multimedia stream may be redirected towards a victim host, causing 941 its communications capabilities to suffer. 943 The attackers in this threat can be either outsiders or even one of 944 the IKEv2 peers. In usual VPN usage scenarios, attacks by the peers 945 can be easily dealt with if the authentication performed in the 946 initial IKEv2 negotiation can be traced to persons who can be held 947 responsible for the attack. This may not be the case in all 948 scenarios, particularly with opportunistic approaches to security. 950 Normally such attacks would expire in a short time frame due to the 951 lack of responses (such as transport layer acknowledgements) from the 952 victim. However, as described in [Aura02], malicious participants 953 would typically be able to spoof such acknowledgements and maintain 954 the traffic flow for an extended period of time. For instance, if 955 the attacker opened the TCP stream itself before redirecting it to 956 the victim, the attacker becomes aware of the sequence number space 957 used in this particular session. 959 It should also be noted, as shown in [Bombing], that without ingress 960 filtering in the attacker's network such attacks are already possible 961 simply by sending spoofed packets from the attacker to the victim 962 directly. Furthermore, if the attacker's network has ingress 963 filtering, this attack is largely prevented for MOBIKE as well. 964 Consequently, it makes little sense to protect against attacks of 965 similar nature in MOBIKE. However, it still makes sense to limit the 966 amplification capabilities provided to attackers, so that they cannot 967 use stream redirection to send a large number of packets to the 968 victim by sending just a few packets themselves. 970 This specification includes return routability tests to limit the 971 duration of any "third party bombing" attacks by off-path (relative 972 to the victim) attackers. The tests are authenticated messages that 973 the peer has to respond to, and can be performed either before the 974 address change takes effect, immediately afterwards, or even 975 periodically during the session. The tests contain unpredictable 976 data, and only someone who has the keys associated with the IKE SA 977 and has seen the request packet can properly respond to the test. 979 6.4 Spoofing Network Connectivity Indications 981 Attackers may spoof various indications from lower layers and the 982 network in an effort to confuse the peers about which addresses are 983 or are not working. For example, attackers may spoof link-layer 984 error messages in an effort to cause the parties to move their 985 traffic elsewhere or even to disconnect. Attackers may also spoof 986 information related to network attachments, router discovery, and 987 address assignments in an effort to make the parties believe they 988 have Internet connectivity when in reality they do not. 990 This may cause use of non-preferred addresses or even denial-of- 991 service. 993 MOBIKE does not provide any protection of its own for indications 994 from other parts of the protocol stack. These vulnerabilities can be 995 mitigated through the use of techniques specific to the other parts 996 of the stack, such as validation of ICMP errors [ICMPAttacks], link 997 layer security, or the use of [SEND] to protect IPv6 Router and 998 Neighbor Discovery. 1000 Ultimately MOBIKE depends on the delivery of IKEv2 messages to 1001 determine which paths can be used. If IKEv2 messages sent using a 1002 particular source and destination addresses reach the recipient and a 1003 reply is received, MOBIKE will usually consider the path working; if 1004 no reply is received even after retransmissions, MOBIKE will suspect 1005 the path is broken. An attacker who can consistently control the 1006 delivery or non-delivery of the IKEv2 messages in the network can 1007 thus influence which addresses actually get used. 1009 6.5 Address and Topology Disclosure 1011 MOBIKE address updates and ADDITIONAL_IP4/6_ADDRESS notifications 1012 reveal information about which networks the peers are connected to. 1014 For example, consider a host A with two network interfaces: a 1015 cellular connection and a wired Ethernet connection to a company LAN. 1016 If host A now contacts host B using IKEv2/MOBIKE and sends 1017 ADDITIONAL_IP4/6_ADDRESS notifications, host B receives additional 1018 information it might not otherwise know. If host A used the cellular 1019 connection for the IKEv2/MOBIKE traffic, host B can also see the 1020 company LAN address (and perhaps further guess that host A is used by 1021 an employee of that company). If host A used the company LAN to make 1022 the connection, host B can see that host A has a subscription from 1023 this particular cellular operator. 1025 These additional addresses can also disclose more accurate location 1026 information than just a single address. Suppose that host A uses its 1027 cellular connection for IKEv2/MOBIKE traffic, but also sends an 1028 ADDITIONAL_IP4_ADDRESS notification containing an IP address 1029 corresponding to, say, a wireless LAN at a particular coffee shop 1030 location. It is likely that host B can now make a much better guess 1031 at A's location than would be possible based on the cellular IP 1032 address alone. 1034 Furthermore, as described in Section 4.3, some of the addresses could 1035 also be private addresses behind a NAT. 1037 In many environments, disclosing address information is not a problem 1038 (and indeed it cannot be avoided if the hosts wish to use those 1039 addresses for IPsec traffic). For instance, a remote access VPN 1040 client could consider the corporate VPN gateway sufficiently 1041 trustworthy for this purpose. 1043 However, if MOBIKE is used in some more opportunistic approach, it 1044 can be desirable to limit the information that is sent. The peers 1045 naturally do not have to disclose any addresses they do not want to 1046 use for IPsec traffic. Also, as noted in Section 4.5, an initiator 1047 whose policy is to always use the locally configured responder 1048 address does not have to send any ADDITIONAL_IP4/6_ADDRESS payloads. 1050 7. IANA Considerations 1052 This document does not create any new namespaces to be maintained by 1053 IANA, but it requires new values in namespaces that have been defined 1054 in the IKEv2 base specification [IKEv2]. 1056 This document defines several new IKEv2 notifications whose values 1057 are to be allocated from the "IKEv2 Notify Message Types" namespace. 1059 Notify Message Value 1060 --------------------------- ----- 1061 MOBIKE_SUPPORTED TBD-BY-IANA1 (16396..40959) 1062 ADDITIONAL_IP4_ADDRESS TBD-BY-IANA2 (16396..40959) 1063 ADDITIONAL_IP6_ADDRESS TBD-BY-IANA3 (16396..40959) 1064 NO_ADDITIONAL_ADDRESSES TBD-BY-IANA4 (16396..40959) 1065 UPDATE_SA_ADDRESSES TBD-BY-IANA5 (16396..40959) 1066 UNACCEPTABLE_ADDRESSES TBD-BY-IANA6 (40..8191) 1067 COOKIE2 TBD-BY-IANA7 (16396..40959) 1068 NO_NATS_ALLOWED TBD-BY-IANA8 (16396..40959) 1069 UNEXPECTED_NAT_DETECTED TBD-BY-IANA9 (40..8191) 1071 These notifications are described in Section 5. 1073 8. Acknowledgements 1075 This document is a collaborative effort of the entire MOBIKE WG. We 1076 would particularly like to thank Jari Arkko, Francis Dupont, Paul 1077 Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also 1078 incorporates ideas and text from earlier MOBIKE protocol proposals, 1079 including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the 1080 MOBIKE design document [Design]. 1082 9. References 1084 9.1 Normative References 1086 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1087 draft-ietf-ipsec-ikev2-17 (work in progress), 1088 October 2004. 1090 [IPsecArch] 1091 Kent, S. and K. Seo, "Security Architecture for the 1092 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 1093 in progress), March 2005. 1095 [KEYWORDS] 1096 Bradner, S., "Key words for use in RFCs to Indicate 1097 Requirement Levels", RFC 2119, March 1997. 1099 [UDPEncap] 1100 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 1101 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 1102 RFC 3948, January 2005. 1104 9.2 Informative References 1106 [AddrMgmt] 1107 Dupont, F., "Address Management for IKE version 2", 1108 draft-dupont-ikev2-addrmgmt-07 (work in progress), 1109 May 2005. 1111 [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1112 Location Management", Proc. 18th Annual Computer Security 1113 Applications Conference (ACSAC), December 2002. 1115 [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile 1116 IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), 1117 June 2005. 1119 [DNA4] Aboba, B., "Detecting Network Attachment (DNA) in IPv4", 1120 draft-ietf-dhc-dna-ipv4-15 (work in progress), 1121 August 2005. 1123 [DNA6] Narayanan, S., Daley, G., and N. Montavont, "Detecting 1124 Network Attachment in IPv6 - Best Current Practices for 1125 hosts", draft-ietf-dna-hosts-01 (work in progress), 1126 June 2005. 1128 [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE 1129 protocol", draft-ietf-mobike-design-02 (work in progress), 1130 February 2005. 1132 [ICMPAttacks] 1133 Gont, F., "ICMP attacks against TCP", 1134 draft-gont-tcpm-icmp-attacks-03 (work in progress), 1135 December 2004. 1137 [Kivinen] Kivinen, T., "MOBIKE protocol", 1138 draft-kivinen-mobike-protocol-00 (work in progress), 1139 February 2004. 1141 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 1142 August 2002. 1144 [MIP6] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1145 in IPv6", RFC 3775, June 2004. 1147 [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO- 1148 IKE)", draft-eronen-mobike-mopo-02 (work in progress), 1149 February 2005. 1151 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1152 Discovery for IP Version 6 (IPv6)", RFC 2461, 1153 December 1998. 1155 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 1156 Neighbor Discovery (SEND)", RFC 3971, March 2005. 1158 [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and 1159 Multihoming Extensions for IKEv2 (SMOBIKE)", 1160 draft-eronen-mobike-simple-00 (work in progress), 1161 March 2004. 1163 [STUN] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1164 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1165 Through Network Address Translators (NATs)", RFC 3489, 1166 March 2003. 1168 [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- 1169 Address Fixing (UNSAF) Across Network Address 1170 Translation", RFC 3424, November 2002. 1172 Author's Address 1174 Pasi Eronen (editor) 1175 Nokia Research Center 1176 P.O. Box 407 1177 FIN-00045 Nokia Group 1178 Finland 1180 Email: pasi.eronen@nokia.com 1182 Appendix A. Changelog 1184 (This section should be removed by the RFC editor.) 1186 Changes from -02 to -03: 1188 o Editorial fixes and clarifications (issues 42 and 43). 1190 o Clarified IANA considerations (issue 42). 1192 o Added security considerations about address and topology 1193 disclosure (issue 42). 1195 o Added a suggestion about retransmission timeout (issue 42). 1197 o Change dynamic address updates: MUST NOT do them based on IKEv2 1198 packets, MAY do based on ESP (issue 34). 1200 o Mandate NAT prohibition if not doing NAT traversal (issue 41). 1202 o Clarified security considerations related to NATs (issue 41). 1204 o Don't use SHA-1 in NO_NATS_ALLOWED, just send the addresses (issue 1205 42). 1207 o Added a short section about path testing. 1209 o Added an example protocol run in Section 1. 1211 Changes from -01 to -02: 1213 o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35, 1214 37). 1216 o Changed terminology related to NAT prohibition (issues 22, 24). 1218 o Rewrote much of the ADDITIONAL_*_ADDRESS text, added 1219 NO_ADDITIONAL_ADDRESSES notification. 1221 o Use NAT detection payloads to detect changes in NAT mappings 1222 (issue 34). 1224 o Removed separate PATH_TEST message (issue 34). 1226 o Clarified processing of UNACCEPTABLE_ADDRESSES when request has 1227 been sent using several different addresses (issue 36). 1229 o Clarified changing of ports 500/4500 (issue 33). 1231 o Updated security considerations (issues 27 and 28). 1233 o No need to include COOKIE2 in non-RR messages (issue 32). 1235 o Many editorial fixes and clarifications (issue 38, 40). 1237 o Use the terms initiator and responder more consistently. 1239 o Clarified that this document does not solve all problems in MOBIKE 1240 WG charter (issue 40). 1242 Changes from -00 to -01: 1244 o Editorial fixes and small clarifications (issues 21, 25, 26, 29). 1246 o Use Protocol ID zero for notifications (issue 30). 1248 o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue 1249 23). 1251 o Use the word "path" only in senses that include the route taken 1252 (issue 29). 1254 Intellectual Property Statement 1256 The IETF takes no position regarding the validity or scope of any 1257 Intellectual Property Rights or other rights that might be claimed to 1258 pertain to the implementation or use of the technology described in 1259 this document or the extent to which any license under such rights 1260 might or might not be available; nor does it represent that it has 1261 made any independent effort to identify any such rights. Information 1262 on the procedures with respect to rights in RFC documents can be 1263 found in BCP 78 and BCP 79. 1265 Copies of IPR disclosures made to the IETF Secretariat and any 1266 assurances of licenses to be made available, or the result of an 1267 attempt made to obtain a general license or permission for the use of 1268 such proprietary rights by implementers or users of this 1269 specification can be obtained from the IETF on-line IPR repository at 1270 http://www.ietf.org/ipr. 1272 The IETF invites any interested party to bring to its attention any 1273 copyrights, patents or patent applications, or other proprietary 1274 rights that may cover technology that may be required to implement 1275 this standard. Please address the information to the IETF at 1276 ietf-ipr@ietf.org. 1278 Disclaimer of Validity 1280 This document and the information contained herein are provided on an 1281 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1282 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1283 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1284 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1285 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1286 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1288 Copyright Statement 1290 Copyright (C) The Internet Society (2005). This document is subject 1291 to the rights, licenses and restrictions contained in BCP 78, and 1292 except as set forth therein, the authors retain all their rights. 1294 Acknowledgment 1296 Funding for the RFC Editor function is currently provided by the 1297 Internet Society.