idnits 2.17.00 (12 Aug 2021) /tmp/idnits65247/draft-ietf-mobike-protocol-01.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 930. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 907. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 914. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 920. ** 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 (July 15, 2005) is 6153 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'CERTREQ' is mentioned on line 232, but not defined == Missing Reference: 'CERT' is mentioned on line 251, but not defined == Missing Reference: 'IDr' is mentioned on line 246, but not defined == Unused Reference: 'UDPEncap' is defined on line 814, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-2' == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == 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: draft-ietf-mobike-design has been published as RFC 4621 == 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) Summary: 3 errors (**), 0 flaws (~~), 11 warnings (==), 9 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: January 16, 2006 July 15, 2005 6 IKEv2 Mobility and Multihoming Protocol (MOBIKE) 7 draft-ietf-mobike-protocol-01.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 January 16, 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 IKEv2. MOBIKE allows mobile and/or 42 multihomed hosts to update the (outer) IP addresses associated with 43 IKE and IPsec Security Associations (SAs). The main scenario for 44 MOBIKE is making it possible for a remote access VPN user to move 45 from one address to another while keeping the connection with the VPN 46 gateway active. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.2 MOBIKE protocol overview . . . . . . . . . . . . . . . . . 4 53 1.3 Terminology and notations . . . . . . . . . . . . . . . . 5 54 2. MOBIKE protocol exchanges . . . . . . . . . . . . . . . . . . 6 55 2.1 Signaling support for MOBIKE . . . . . . . . . . . . . . . 6 56 2.2 Additional addresses . . . . . . . . . . . . . . . . . . . 6 57 2.3 Changing addresses in IPsec SAs . . . . . . . . . . . . . 7 58 2.4 Updating additional addresses . . . . . . . . . . . . . . 9 59 2.5 Path testing . . . . . . . . . . . . . . . . . . . . . . . 10 60 2.6 Return routability check . . . . . . . . . . . . . . . . . 11 61 2.7 NAT prevention . . . . . . . . . . . . . . . . . . . . . . 11 62 3. Payload formats . . . . . . . . . . . . . . . . . . . . . . . 13 63 3.1 MOBIKE_SUPPORTED notification payload . . . . . . . . . . 13 64 3.2 ADDITIONAL_IP4/6_ADDRESS notification payloads . . . . . . 13 65 3.3 UPDATE_SA_ADDRESSES notification payload . . . . . . . . . 13 66 3.4 UNACCEPTABLE_ADDRESSES notification payload . . . . . . . 13 67 3.5 COOKIE2 notification payload . . . . . . . . . . . . . . . 14 68 3.6 NAT_PREVENTION notification payload . . . . . . . . . . . 14 69 3.7 NAT_PREVENTED notification payload . . . . . . . . . . . . 14 70 4. Security considerations . . . . . . . . . . . . . . . . . . . 15 71 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 18 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 73 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 7.1 Normative references . . . . . . . . . . . . . . . . . . . 19 75 7.2 Informative references . . . . . . . . . . . . . . . . . . 19 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 20 77 1. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 20 78 Intellectual Property and Copyright Statements . . . . . . . . 22 80 1. Introduction 82 1.1 Motivation 84 IKEv2 is used for performing mutual authentication and establishing 85 and maintaining IPsec security associations (SAs). In the current 86 specifications, the IPsec and IKE SAs are created implicitly between 87 the IP addresses that are used when the IKE_SA is established. These 88 IP addresses are then used as the outer (tunnel header) addresses for 89 tunnel mode IPsec packets. Currently, it is not possible to change 90 these addresses after the IKE_SA has been created. 92 There are scenarios where these IP addresses might change. One 93 example is mobility: a host changes its point of network attachment, 94 and receives a new IP address. Another example is a multihoming host 95 that would like to change to a different interface if, for instance, 96 the currently used address stops working for some reason. 98 Although the problem can be solved by creating new IKE and IPsec SAs 99 when the addresses need to be changed, this may not be optimal for 100 several reasons. In some cases, creating a new IKE_SA may require 101 user interaction for authentication (entering a code from a token 102 card, for instance). Creating new SAs often also involves expensive 103 calculations and possibly a large number of roundtrips. Due to these 104 reasons, a mechanism for updating the IP addresses of existing IKE 105 and IPsec SAs is needed. The MOBIKE protocol described in this 106 document provides such a mechanism. 108 The main scenario for MOBIKE is making it possible for a remote 109 access VPN user to move from one address to another without re- 110 establishing all security associations with the VPN gateway. For 111 instance, a user could start from fixed Ethernet in the office, and 112 then disconnect the laptop and move to office wireless LAN. When 113 leaving the office the laptop could start using GPRS, and switch to a 114 different wireless LAN when the user arrives home. MOBIKE updates 115 only the outer (tunnel header) addresses of IPsec SAs, and the 116 addresses and others traffic selectors used inside the tunnel stay 117 unchanged. Thus, mobility can be (mostly) invisible to applications 118 and their connections using the VPN. 120 MOBIKE also supports more complex scenarios where the VPN gateway 121 also has several network interfaces: these interfaces could be 122 connected to different networks or ISPs, they may have may be a mix 123 of IPv4 and IPv6 addresses, and the addresses may change over time. 124 Furthermore, both parties could be VPN gateways relaying traffic for 125 other parties. 127 1.2 MOBIKE protocol overview 129 Since MOBIKE allows both parties to have several addresses, this 130 leads us to an important question: there are up to N*M pairs of IP 131 addresses that could potentially be used. How to decide which of 132 these pairs should be used? The decision has to take into account 133 several factors. First, the parties have may preferences about which 134 interface should be used, due to performance and cost reasons, for 135 instance. Second, the decision is constrained by the fact that some 136 of the pairs may not work at all due to incompatible IP versions, 137 outages somewhere in the network, problems at the local link at 138 either end, and so on. 140 MOBIKE solves this problem by taking a simple approach: the party 141 that initiated the IKE_SA (the "client" in remote access VPN 142 scenario) is responsible for deciding which address pair is used for 143 the IPsec SAs, and collecting the information it needs to make this 144 decision (such as determining which address pairs work or do not 145 work). The other party (the "gateway" in remote access VPN scenario) 146 simply tells the initiator what addresses it has, but does not update 147 the IPsec SAs until it receives a message from the initiator to do 148 so. 150 Making the decision at the initiator is consistent with how normal 151 IKEv2 works: the initiator decides which addresses it uses when 152 contacting the responder. It also makes sense especially when the 153 initiator is the mobile node: it is in a better position to decide 154 which of its network interfaces should be used for both upstream and 155 downstream traffic. 157 The details of exactly how the initiator makes the decision, what 158 information is used in making it, how the information is collected, 159 how preferences affect the decision, and when a decision needs to be 160 changed, are largely beyond the scope of MOBIKE. This does not mean 161 that these details are unimportant: on the contrary, they are likely 162 to be crucial in any real system. However, MOBIKE is concerned with 163 these details only to the extent that they are visible in IKEv2/IPsec 164 messages exchanged between the peers (and thus need to be 165 standardized to ensure interoperability). Issues such as mobility 166 detection and local policies are also not specific to MOBIKE, but 167 apply to existing mobility protocols such as Mobile IPv4 [MIP4] as 168 well. 170 One important aspect of this information gathering that has to be 171 visible in the messages is determining whether a certain pair of 172 addresses can be used. IKEv2 Dead Peer Detection (DPD) feature can 173 provide information that the currently used pair does or does not 174 work. There are, however, some complications in using it for other 175 addresses, and thus MOBIKE adds a new IKEv2 message that can be used 176 to "test" whether some particular pair of addresses works or not, 177 without yet committing to changing the addresses currently in use. 179 MOBIKE also has to deal with situations where the network contains 180 NATs or stateful packet filters (for brevity, the rest of this 181 document talks simply about NATs). When the addresses used for IPsec 182 SAs are changed, MOBIKE can enable or disable IKEv2 NAT Traversal as 183 needed. However, if the party "outside" the NAT changes its IP 184 address, it may no longer be able to send packets to the party 185 "behind" the NAT, since the packets may not (depending on the exact 186 type of NAT) match the NAT mapping state. Here MOBIKE assumes that 187 the initiator is the party "behind" the NAT, and does not fully 188 support the case where the responder's addresses change when NATs are 189 present. 191 Updating the addresses of IPsec SAs naturally has to take into 192 account several security considerations. MOBIKE includes two 193 features designed to address these considerations. First, a "return 194 routability" check can be used to verify the addresses provided by 195 the peer. This makes it more difficult to flood third parties with 196 large amounts of traffic. Second, a "NAT prevention" feature ensures 197 that IP addresses have not been modified by NATs, IPv4/IPv6 198 translation agents, or other similar devices. This feature is mainly 199 intended for site-to-site VPNs where the administrators may know 200 beforehand that NATs are not present, and thus any modification to 201 the packet can be considered to be an attack. 203 1.3 Terminology and notations 205 When messages containing IKEv2 payloads are shown, optional payloads 206 are shown in brackets (for instance, "[FOO]"), and a plus sign 207 indicates that a payload can be repeated one or more times (for 208 instance, "FOO+"). 210 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 211 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 212 document are to be interpreted as described in [KEYWORDS]. 214 2. MOBIKE protocol exchanges 216 2.1 Signaling support for MOBIKE 218 Implementations that wish to use MOBIKE for a particular IKE_SA MUST 219 include a MOBIKE_SUPPORTED notification in the IKE_SA_INIT request 220 and response messages. 222 Initiator Responder 223 ----------- ----------- 224 HDR, SAi1, KEi, Ni, 225 N(MOBIKE_SUPPORTED), 226 [N(NAT_DETECTION_SOURCE_IP)+, 227 N(NAT_DETECTION_DESTINATION_IP)] --> 229 <-- HDR, SAr1, KEr, Nr, 230 [N(NAT_DETECTION_SOURCE_IP)+, 231 N(NAT_DETECTION_DESTINATION_IP)] 232 [CERTREQ], 233 N(MOBIKE_SUPPORTED) 235 The MOBIKE_SUPPORTED notification payload is described in Section 3. 237 2.2 Additional addresses 239 Both the initiator and responder MAY include one or more 240 ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notification 241 payloads in the IKE_AUTH exchange (in case of multiple IKE_AUTH 242 exchanges, in the message containing the SA payload). 244 Initiator Responder 245 ----------- ----------- 246 HDR, SK { IDi, [CERT], [IDr], AUTH, 247 [CP(CFG_REQUEST)] 248 SAi2, TSi, TSr, 249 [N(ADDITIONAL_*_ADDRESS)+] --> 251 <-- HDR, SK { IDr, [CERT], AUTH, 252 [CP(CFG_REPLY)], 253 SAr2, TSi, TSr, 254 [N(ADDITIONAL_*_ADDRESS)+] } 256 The recipient stores this information, but no other action is taken 257 at this time. 259 2.3 Changing addresses in IPsec SAs 261 In MOBIKE, the initiator of the IKE_SA decides what addresses are 262 used in the IPsec SAs. That is, the responder never updates any 263 IPsec SAs without receiving an explicit UPDATE_SA_ADDRESSES request 264 from the initiator. (As described below, the responder can, however, 265 update the IKE_SA in some circumstances.) 267 The description in this section assumes that the initiator has 268 already decided what the new addresses should be. How this decision 269 is made is beyond the scope of this specification. When this 270 decision has been made, the initiator 272 o Updates the IKE_SA and IPsec SAs with the new addresses, and sets 273 the "pending_update" flag in the IKE_SA. 275 o If NAT Traversal is not enabled, and the responder supports NAT 276 Traversal (as indicated by NAT detection payloads in the 277 IKE_SA_INIT exchange), and the initiator either suspects or knows 278 that a NAT is likely to be present, enables NAT Traversal. 280 o If there are outstanding IKEv2 requests, continues retransmitting 281 them using the addresses in the IKE_SA (the new addresses). 283 o When the window size allows, sends an INFORMATIONAL request 284 containing the UPDATE_SA_ADDRESSES notification payload (which 285 does not contain any data), and clears the "pending_update" flag. 286 (See Section 2.6 for description of the COOKIE2 notification.) 288 Initiator Responder 289 ----------- ----------- 290 HDR, SK { N(UPDATE_SA_ADDRESSES), 291 N(COOKIE2), 292 [N(NAT_DETECTION_*_IP)], 293 [N(NAT_PREVENTION)] } --> 295 o If a new address change occurs while waiting for the response, 296 starts again from the first step (and ignores responses to this 297 UPDATE_SA_ADDRESSES request). 299 Note that if the responder has NAT Traversal enabled, it can update 300 the addresses in both the IKE_SA and IPsec SAs as usual (if it 301 implements the "SHOULD" from [IKEv2] Section 2.23). 303 When processing an INFORMATIONAL request containing the 304 UPDATE_SA_ADDRESSES notification, the responder 305 o Determines whether it has already received a newer 306 UPDATE_SA_ADDRESSES request than this one (if the responder uses a 307 window size greater than one, it is possible that requests are 308 received out of order). If it has, a response message is sent, 309 but no other action is taken. 311 o If the NAT_PREVENTION payload is present, processes it as 312 described in Section 2.7. 314 o Checks that the (source IP address, destination IP address) pair 315 in the IP header is acceptable according to local policy. If it 316 is not, replies with "HDR, SK {N(COOKIE2), 317 N(UNACCEPTABLE_ADDRESSES)}". 319 o Updates the IP addresses in the IKE_SA with the values from the IP 320 header. (Using the address from the IP header is consistent with 321 normal IKEv2, and allows IKEv2 to work with NATs without needing 322 unilateral self-address fixing [UNSAF].) 324 o Replies with an INFORMATIONAL response: 326 Initiator Responder 327 ----------- ----------- 328 <-- HDR, SK { N(COOKIE2), 329 [N(NAT_DETECTION_*_IP)] } 331 o If necessary, initiates a return routability check for the new 332 initiator address (see Section 2.6) and waits for the check to 333 finish.. 335 o Updates the IPsec SAs with the new addresses. 337 o If NAT Traversal is supported and NAT detection payloads were 338 included, enables or disables NAT Traversal. 340 When the initiator receives the reply, it 342 o If the response contains the NAT_PREVENTED payload, processes it 343 as described in Section 2.7. 345 o If the response contains an UNACCEPTABLE_ADDRESSES notification 346 payload, the initiator MAY select another addresses and retry the 347 exchange, keep on using the current addresses, or disconnect. 349 o If NAT Traversal is supported and NAT detection payloads were 350 included, enables or disables NAT Traversal. 352 2.4 Updating additional addresses 354 As described in Section 2.2, both the initiator and responder can 355 send a list of additional addresses (in addition to the one used for 356 IKE_SA_INIT/IKE_AUTH exchange) to the initiator in the IKE_AUTH 357 exchange. If this list of addresses changes, a new list can be sent 358 in any INFORMATIONAL exchange request message. 360 When the responder (of the original IKE_SA) receives an INFORMATIONAL 361 request containing ADDITIONAL_*_ADDRESS payloads, it simply stores 362 the information, but no other action is taken. 364 Initiator Responder 365 ----------- ----------- 366 HDR, SK { N(ADDITIONAL_*_ADDRESS)+, 367 N(COOKIE2) } --> 369 <-- HDR, SK { N(COOKIE2) } 371 When the initiator receives an INFORMATIONAL request containing 372 ADDITIONAL_*_ADDRESS, it stores the information and also determines 373 whether the currently used addresses need to be changed (for 374 instance, if the currently used address is no longer included in the 375 list); if it does, the initiator proceeds as described in 376 Section 2.3. 378 Initiator Responder 379 ----------- ----------- 380 <-- HDR, SK { N(ADDITIONAL_*_ADDRESS)+, 381 N(COOKIE2) } 383 HDR, SK { N(COOKIE2) } --> 385 If the implementation supports window sizes greater than one, it also 386 has to keep track of the Message ID of the latest update it has 387 received, to avoid the situation where new information is overwritten 388 by older. 390 There is one additional complication: when the responder wants to 391 send a new additional address list, the currently used addresses may 392 no longer work. In this case, the responder uses the additional 393 address list received from the initiator, the list of its own 394 addresses, and, if necessary, the path testing feature (see 395 Section 2.5) to determine a path that works, updates the addresses in 396 the IKE_SA (but not IPsec SAs), and then sends the INFORMATIONAL 397 request. This is the only time the responder uses the additional 398 address list received from the initiator. 400 Note that both peers can have their own policies about what addresses 401 are acceptable to use. A minimal "mobile client" could have a policy 402 that says that only the responder's address specified in local 403 configuration is acceptable. This kind of client does not have to 404 send or process ADDITIONAL_*_ADDRESS notification payloads. 405 Similarly, a simple "VPN gateway" that has only a single address, and 406 is not going to change it, does not need to send or understand 407 ADDITIONAL_*_ADDRESS notification payloads. 409 2.5 Path testing 411 IKEv2 Dead Peer Detection allows the peers to detect if the currently 412 used path has stopped working. However, if either of the peers has 413 several addresses, DPD alone does not indicate which of the other 414 paths might work. The path testing feature allows the parties to 415 determine whether a particular path (pair of addresses) works, 416 without yet committing to changing over to these addresses. 418 MOBIKE introduces a new IKEv2 exchange type, PATH_TEST, for testing 419 connectivity. This exchange is not part of any IKE_SA, so it is not 420 cryptographically protected. It also does not result in the 421 responder keeping any state. 423 Initiator Responder 424 ----------- ----------- 425 HDR(0,0), N(COOKIE2), 426 [N(NAT_DETECTION_*_IP)] --> 428 <-- HDR(0,0), N(COOKIE2), 429 [N(NAT_DETECTION_*_IP)] 431 The reason for introducing a new exchange type, instead of using 432 INFORMATIONAL exchanges, is to simplify implementations by allowing 433 MOBIKE to work with window size 1. 435 Performing path testing over several different paths is not required 436 if the node has other information that enables it to select which 437 path should be used. Also, responders do not perform path testing 438 unless they update their list of additional addresses (as described 439 in Section 2.4). Implementations MAY do path testing even if the 440 currently used path is working to e.g. detect when a better but 441 previously unavailable path becomes available, or to speed up 442 recovery in fault situations. 444 Implementations that perform path testing MUST take steps to avoid 445 causing unnecessary congestion. TBD: add some more details here. 447 2.6 Return routability check 449 Both the initiator and the responder can optionally verify that the 450 other party can actually receive packets at the claimed address. 451 This "return routability check" MAY be done before updating the IPsec 452 SAs, immediately after updating them, or continuously during the 453 connection. 455 By default, return routability check SHOULD be done before updating 456 the IPsec SAs. In environments where the peer is expected to be 457 well-behaving (many corporate VPNs, for instance), or the address can 458 be verified by some other means (e.g., the address is included in the 459 peer's certificate), the return routability check MAY be skipped or 460 postponed until after the IPsec SAs have been updated. 462 Any INFORMATIONAL exchange can be used for return routability 463 purposes (with one exception, described below): when a valid response 464 is received, we know the other party can receive packets at the 465 claimed address. 467 To ensure that the peer cannot generate the correct INFORMATIONAL 468 response without seeing the request, a new payload is added to all 469 INFORMATIONAL messages. The sender of an INFORMATIONAL request MUST 470 include a COOKIE2 notification payload, and the recipient of an 471 INFORMATIONAL request MUST copy the payload as-is to the response. 472 When processing the response, the original sender MUST verify that 473 the value is the same one as sent. If the values do not match, the 474 IKE_SA MUST be closed. 476 There is one additional issue that must be taken into account. If 477 the INFORMATIONAL request has been sent to several different 478 addresses (i.e., the destination address in the IKE_SA has been 479 updated after the request was first sent), receiving the 480 INFORMATIONAL response does not tell which address is the working 481 one. In this case, a new INFORMATIONAL request needs to be sent to 482 check return routability. 484 2.7 NAT prevention 486 IKEv2/IPsec implementations that do not support NAT Traversal can, in 487 fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6 488 translation agents in tunnel mode. This may be considered a problem 489 in some circumstances, since in some sense any modification of the IP 490 addresses can be considered to be an attack. 492 The "NAT prevention" feature allows both the initiator and responder 493 to have a policy that prevents the use of paths that contain NATs, 494 IPv4/IPv6 translation agents, or other nodes that modify the 495 addresses in the IP header. This feature is mainly intended for 496 site-to-site VPN cases, where the administrators may know beforehand 497 that NATs are not present, and thus any modification to the packet 498 can be considered to be an attack. 500 This specification addresses the issue as follows. When an IPsec SA 501 is created, the tunnel header IP addresses (and port if doing UDP 502 encapsulation) are taken from the IKE_SA, not the message IP header. 503 The NAT_PREVENTION payload is used to guarantee that NATs have not 504 modified the address used in IKE_SA. However, all response messages 505 are still sent to the address and port the corresponding request came 506 from. 508 The initiator MAY include a NAT_PREVENTION payload in an IKE_SA_INIT 509 request. The responder then MUST calculate the expected value based 510 on the values from the IP header, and compare this with the value in 511 the NAT_PREVENTION payload. If they do not match, the responder 512 replies with "HDR(A,0), N(NAT_PREVENTED)" and does not create any 513 state. 515 If the values do match, the responder initializes (local_address, 516 local_port, peer_address, peer_port) in the to-be-created IKE_SA with 517 values from the IP header. The same applies if neither 518 NAT_PREVENTION nor NAT_DETECTION_*_IP payloads were included, or if 519 the responder does not support NAT Traversal. 521 If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but 522 no NAT_PREVENTION payload, the situation is different since the 523 initiator may at this point change from port 500 to 4500. In this 524 case, the responder initializes (local_address, local_port, 525 peer_address, peer_port) from the first IKE_AUTH request. 527 IKEv2 requires that if an IPsec endpoint discovers a NAT between it 528 and its correspondent, it MUST send all subsequent traffic to and 529 from port 4500. To simplify things, implementations that support 530 both this specification and NAT Traversal MUST change to port 4500 if 531 the correspondent also supports both, even if no NAT was detected 532 between them. 534 NAT_PREVENTION payloads can also be included when changing the 535 addresses of IPsec SAs (see Section 2.3). TBD: add better 536 description. 538 3. Payload formats 540 3.1 MOBIKE_SUPPORTED notification payload 542 The MOBIKE_SUPPORTED notification payload is included in the 543 IKE_SA_INIT messages to indicate that the implementation supports 544 this specification. 546 The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY-IANA 547 (16396..40959). The Protocol ID and SPI Size fields are set to zero. 548 There is no data associated with this Notify type. 550 3.2 ADDITIONAL_IP4/6_ADDRESS notification payloads 552 Both initiator and responder can include ADDITIONAL_IP4_ADDRESS 553 and/or ADDITIONAL_IP6_ADDRESS payloads in the IKE_AUTH exchange and 554 INFORMATIONAL exchange request messages; see Section 2.2 and 555 Section 2.4 for more detailed description. 557 The Notify Message Types for ADDITIONAL_IP4_ADDRESS and 558 ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA (16396..40959) and TBD-BY-IANA 559 (16396..40959), respectively. The Protocol ID and SPI Size fields 560 are set to zero. The data associated with these Notify types is 561 either a four-octet IPv4 address or a 16-octet IPv6 address. 563 3.3 UPDATE_SA_ADDRESSES notification payload 565 This payload is included in INFORMATIONAL exchange requests sent by 566 the initiator of the IKE_SA to update addresses of the IKE_SA and 567 IPsec SAs (see Section 2.3). 569 The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY-IANA 570 (16396..40959). The Protocol ID and SPI Size fields are set to zero. 571 There is no data associated with this Notify type. 573 3.4 UNACCEPTABLE_ADDRESSES notification payload 575 The responder can include this notification payload in an 576 INFORMATIONAL exchange response to indicate that the address change 577 in the corresponding request message (which contained an 578 UPDATE_SA_ADDRESSES notification payload) was not carried out. 580 The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY-IANA 581 (40..8191). The Protocol ID and SPI Size fields are set to zero. 582 There is no data associated with this Notify type. 584 3.5 COOKIE2 notification payload 586 This payload is included in all INFORMATIONAL exchange messages for 587 return routability check purposes (see Section 2.6). It is also used 588 in PATH_TEST messages to match requests and responses (see 589 Section 2.5). 591 The data associated with this notification MUST be between 8 and 64 592 octets in length (inclusive), and MUST be chosen in a way that is 593 unpredictable to the recipient. The Notify Message Type for this 594 message is TBD-BY-IANA (16396..40959). The Protocol ID and SPI Size 595 fields are set to zero. 597 3.6 NAT_PREVENTION notification payload 599 See Section 2.7 for a description of this payload. 601 The data associated with this notification is the SHA-1 hash 602 [FIPS180-2] of the following data: IKE SPIs (in the order they appear 603 in the header), the IP address and port from which the packet was 604 sent, and the IP address and port to which the packet was sent. The 605 Notify Message Type for this message is TBD-BY-IANA (16396..40959). 606 The Protocol ID and SPI Size fields are set to zero. 608 3.7 NAT_PREVENTED notification payload 610 See Section 2.7 for a description of this payload. 612 The Notify Message Type for NAT_PREVENTED is TBD-BY-IANA (40..8191). 613 The Protocol ID and SPI Size fields are set to zero. There is no 614 data associated with this Notify type. 616 4. Security considerations 618 The main goals of this specification are to not reduce the security 619 offered by usual IKEv2 procedures and to counter mobility related 620 threats in an appropriate manner. In some specific cases MOBIKE is 621 also capable of protecting address changes better than existing NAT 622 Traversal procedures. 624 The threats arising in scenarios targeted by MOBIKE are: 626 Traffic redirection and hijacking 628 Insecure mobility management mechanisms may allow inappropriate 629 redirection of traffic. This may allow inspection of the 630 traffic as well as man-in-the-middle and session hijacking 631 attacks. 633 The scope of these attacks in the MOBIKE case is limited, as 634 all traffic is protected using IPsec. However, it should be 635 observed that security associations originally created for the 636 protection of a specific flow between specific addresses may be 637 moved through MOBIKE. The level of required protection may be 638 different in a new location of a VPN client, for instance. 640 Third-party denial-of-service through flooding 642 Traffic redirection may be performed not just to gain access to 643 the traffic, but also to cause a denial-of-service attack for a 644 third party. For instance, a high-speed TCP session or a 645 multimedia stream may be redirected towards a victim host, 646 causing its communications capabilities to suffer. 648 The attackers in this threat can be either outsiders or even 649 one of the participants. In usual VPN usage scenarios attacks 650 by participants can be easily dealt with. However, this 651 requires that strong authentication was performed in the 652 initial IKEv2 negotiation. This may not be the case in all 653 scenarios, particularly with opportunistic approaches to 654 security. 656 Normally such attacks would expire in a short time frame due to 657 the lack of responses (such as transport layer 658 acknowledgements) from the victim. However, as described in 659 [Aura02], malicious participants would typically be able to 660 spoof such acknowledgements and maintain the traffic flow for 661 an extended period of time. For instance, if the attacker 662 opened the TCP stream itself before redirecting it to the 663 victim, the attacker becomes aware of the sequence number space 664 used in this particular session. 666 It should also be noted, as shown in [Bombing], that without 667 ingress filtering in the attacker's network such attacks are 668 already possible simply by sending spoofed packets from the 669 attacker to the victim directly. Consequently, it makes little 670 sense to protect against attacks of similar nature in MOBIKE. 671 However, it still makes sense to limit the amplification 672 capabilities provided to attackers, so that they cannot use 673 stream redirection to send 1000 packets to the victim by 674 sending just a few packets themselves. 676 Note that a variant of the flooding attack exists in IKEv2 NAT 677 Traversal functionality [PseudoNAT]. In this variant, the 678 attacker has to be on the path between the participants, 679 changing the addresses in the packets that pass by. This 680 attack is possible because the addresses in the outer headers 681 are not protected. When the attacker leaves the path, the 682 correct situation is restored after the exchange of the next 683 packets between the participants. 685 Spoofing indications related to network connectivity 687 Attackers may also spoof various indications from lower layers 688 and the network in an effort to confuse the peers about which 689 addresses are or are not working. For example, attackers may 690 spoof ICMP error messages in an effort to cause the parties to 691 move their traffic elsewhere or even to disconnect. Attackers 692 may also spoof information related to network attachments, 693 router discovery, and address assignments in an effort to make 694 the parties believe they have Internet connectivity when in 695 reality they do not. 697 This may cause use of non-preferred addresses or even denial- 698 of-service. 700 Denial-of-service of the participants through MOBIKE 702 Inappropriate MOBIKE protocol mechanisms might make it possible 703 for attackers to disconnect the participants, or to move them 704 to non-operational addresses. 706 MOBIKE addresses these threats using the following countermeasures: 708 Payload traffic protection 710 The use of IPsec protection on payload traffic protects the 711 participants against disclosure of the contents of the traffic, 712 should the traffic end up in an incorrect destination. It is 713 recommended that security policies be configured in a manner 714 that takes into account that a single security association can 715 be used through different paths at different times. 717 Protection of MOBIKE payloads 719 The payloads used in MOBIKE are encrypted, integrity protected, 720 and replay protected. This assures that no one except the 721 participants can, for instance, give a control message to 722 change the addresses. 724 Note, however, that the actual IP address communicated in these 725 messages is in the outer IP header and not protected, just as 726 in IKEv2 NAT Traversal. MOBIKE adds the NAT_PREVENTION 727 payload, however, which can be used to prevent modifications by 728 outsiders. Where this payload is used, communication through 729 NATs and other address translators is impossible, however. 730 This feature is mainly intended for site-to-site VPN cases, 731 where the administrators may know beforehand that NATs are not 732 present, and thus any modification to the packet can be 733 considered to be an attack. 735 Explicit address change 737 MOBIKE allows only address changes that are explicitly 738 requested. This provides additional security beyond to what 739 IKEv2 NAT Traversal has, but it should be noted that the 740 benefits of this can only be realized when MOBIKE is used 741 without intervening NATs and NAT Traversal. 743 When NAT Traversal is supported, the peer's address may be 744 updated automatically to allow changes in NAT mappings. The 745 "continued return routability" feature, implemented by the 746 COOKIE2 payload, allows verification of the new address after 747 the change. This limits the duration of any "third party 748 bombing" attack by off-path (relative to the victim) attackers. 750 Return routability tests 752 This specification requires the use of return routability tests 753 (under certain conditions) to ensure that third party flooding 754 attacks are prevented. The tests are authenticated messages 755 that the peer has to respond to in order for the address change 756 to be committed to. The tests contain unpredictable data, and 757 can only be properly responded to by someone who has the keys 758 associated with the IKEv2 security association and who has seen 759 the request packet for the test. 761 MOBIKE does not provide any protection of its own for indications 762 from other parts of the protocol stack. However, MOBIKE is resistant 763 to incorrect information from these sources in the sense that it 764 provides its own security for both the signaling of addressing 765 information as well as actual payload data transmission. Denial-of- 766 service vulnerabilities remain, however. Some aspects of these 767 vulnerabilities can be mitigated through the use of techniques 768 specific to the other parts of the stack, such as properly dealing 769 with ICMP errors [ICMPAttacks], link layer security, or the use of 770 [SEND] to protect IPv6 Router and Neighbor Discovery. 772 5. IANA considerations 774 This document does not create any new namespaces to be maintained by 775 IANA, but it requires new values in namespaces that have been defined 776 in the IKEv2 base specification [IKEv2]. 778 This document defines one new IKEv2 exchange, "PATH_TEST", whose 779 value is to be allocated from the "IKEv2 Exchange Types" namespace. 780 This exchange is described in Section 2.5. 782 This document also defines several new IKEv2 notification payloads 783 whose values are to be allocated from the "IKEv2 Notification Payload 784 Types" namespace. These notification payloads are described in 785 Section 3. 787 6. Acknowledgements 789 This document is a collaborative effort of the entire MOBIKE WG. We 790 would particularly like to thank Jari Arkko, Francis Dupont, Paul 791 Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also 792 incorporates ideas and text from earlier MOBIKE protocol proposals, 793 including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the 794 MOBIKE design document [Design]. 796 7. References 798 7.1 Normative references 800 [FIPS180-2] 801 National Institute of Standards and Technology, 802 "Specifications for the Secure Hash Standard", Federal 803 Information Processing Standard (FIPS) Publication 180-2, 804 August 2002. 806 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 807 draft-ietf-ipsec-ikev2-17 (work in progress), 808 October 2004. 810 [KEYWORDS] 811 Bradner, S., "Key words for use in RFCs to Indicate 812 Requirement Levels", RFC 2119, March 1997. 814 [UDPEncap] 815 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 816 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 817 RFC 3948, January 2005. 819 7.2 Informative references 821 [AddrMgmt] 822 Dupont, F., "Address Management for IKE version 2", 823 draft-dupont-ikev2-addrmgmt-07 (work in progress), 824 May 2005. 826 [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 827 Location Management", Proc. 18th Annual Computer Security 828 Applications Conference (ACSAC), December 2002. 830 [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile 831 IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), 832 June 2005. 834 [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE 835 protocol", draft-ietf-mobike-design-02 (work in progress), 836 February 2005. 838 [ICMPAttacks] 839 Gont, F., "ICMP attacks against TCP", 840 draft-gont-tcpm-icmp-attacks-03 (work in progress), 841 December 2004. 843 [Kivinen] Kivinen, T., "MOBIKE protocol", 844 draft-kivinen-mobike-protocol-00 (work in progress), 845 February 2004. 847 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 848 August 2002. 850 [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO- 851 IKE)", draft-eronen-mobike-mopo-02 (work in progress), 852 February 2005. 854 [PseudoNAT] 855 Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks 856 or how NATs are even more evil than you believed", 857 draft-dupont-transient-pseudonat-04 (expired) (work in 858 progress), June 2004. 860 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 861 Neighbor Discovery (SEND)", RFC 3971, March 2005. 863 [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and 864 Multihoming Extensions for IKEv2 (SMOBIKE)", 865 draft-eronen-mobike-simple-00 (work in progress), 866 March 2004. 868 [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- 869 Address Fixing (UNSAF) Across Network Address 870 Translation", RFC 3424, November 2002. 872 Author's Address 874 Pasi Eronen (editor) 875 Nokia Research Center 876 P.O. Box 407 877 FIN-00045 Nokia Group 878 Finland 880 Email: pasi.eronen@nokia.com 882 1. Changelog 884 (This section should be removed by the RFC editor.) 886 Changes from -00 to -01: 888 o Editorial fixes and small clarifications (issues 21, 25, 26, 29). 890 o Use Protocol ID zero for notifications (issue 30). 892 o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue 893 23). 895 o Use the word "path" only in senses that include the route taken 896 (issue 29). 898 Intellectual Property Statement 900 The IETF takes no position regarding the validity or scope of any 901 Intellectual Property Rights or other rights that might be claimed to 902 pertain to the implementation or use of the technology described in 903 this document or the extent to which any license under such rights 904 might or might not be available; nor does it represent that it has 905 made any independent effort to identify any such rights. Information 906 on the procedures with respect to rights in RFC documents can be 907 found in BCP 78 and BCP 79. 909 Copies of IPR disclosures made to the IETF Secretariat and any 910 assurances of licenses to be made available, or the result of an 911 attempt made to obtain a general license or permission for the use of 912 such proprietary rights by implementers or users of this 913 specification can be obtained from the IETF on-line IPR repository at 914 http://www.ietf.org/ipr. 916 The IETF invites any interested party to bring to its attention any 917 copyrights, patents or patent applications, or other proprietary 918 rights that may cover technology that may be required to implement 919 this standard. Please address the information to the IETF at 920 ietf-ipr@ietf.org. 922 Disclaimer of Validity 924 This document and the information contained herein are provided on an 925 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 926 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 927 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 928 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 929 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 930 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 932 Copyright Statement 934 Copyright (C) The Internet Society (2005). This document is subject 935 to the rights, licenses and restrictions contained in BCP 78, and 936 except as set forth therein, the authors retain all their rights. 938 Acknowledgment 940 Funding for the RFC Editor function is currently provided by the 941 Internet Society.