idnits 2.17.1 draft-ietf-mobike-protocol-02.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 1039. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1016. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1023. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1029. ** 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 12, 2005) is 6800 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 262, but not defined == Missing Reference: 'IDr' is mentioned on line 256, but not defined == Missing Reference: 'CERTREQ' is mentioned on line 589, but not defined == Unused Reference: 'UDPEncap' is defined on line 887, but no explicit reference was found in the text == Unused Reference: 'PseudoNAT' is defined on line 932, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS180-2' == 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 (-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) 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: March 16, 2006 September 12, 2005 6 IKEv2 Mobility and Multihoming Protocol (MOBIKE) 7 draft-ietf-mobike-protocol-02.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 March 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 hosts to update the 42 (outer) IP addresses associated with IKE and IPsec Security 43 Associations (SAs). A mobile VPN client could use MOBIKE to keep the 44 connection with the VPN gateway active while moving from one address 45 to another. Similarly, a multihomed host could use MOBIKE to move 46 the traffic to a different interface if, for instance, the currently 47 used one stops working. 49 Table of Contents 51 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 52 1.1 Motivation . . . . . . . . . . . . . . . . . . . . . . . . 3 53 1.2 MOBIKE Protocol Overview . . . . . . . . . . . . . . . . . 4 54 1.3 Terminology and Notations . . . . . . . . . . . . . . . . 5 55 2. MOBIKE Protocol Exchanges . . . . . . . . . . . . . . . . . . 6 56 2.1 Signaling Support for MOBIKE . . . . . . . . . . . . . . . 6 57 2.2 Additional Addresses . . . . . . . . . . . . . . . . . . . 6 58 2.3 Changing Addresses in IPsec SAs . . . . . . . . . . . . . 7 59 2.4 Updating Additional Addresses . . . . . . . . . . . . . . 10 60 2.5 Return Routability Check . . . . . . . . . . . . . . . . . 11 61 2.6 Changes in NAT Mappings . . . . . . . . . . . . . . . . . 12 62 2.7 NAT Prohibition . . . . . . . . . . . . . . . . . . . . . 12 63 2.8 Failure Recovery and Timeouts . . . . . . . . . . . . . . 14 64 3. Payload Formats . . . . . . . . . . . . . . . . . . . . . . . 15 65 3.1 MOBIKE_SUPPORTED Notification Payload . . . . . . . . . . 15 66 3.2 ADDITIONAL_IP4/6_ADDRESS Notification Payloads . . . . . . 15 67 3.3 NO_ADDITIONAL_ADDRESSES Notification Payload . . . . . . . 15 68 3.4 UPDATE_SA_ADDRESSES Notification Payload . . . . . . . . . 15 69 3.5 UNACCEPTABLE_ADDRESSES Notification Payload . . . . . . . 16 70 3.6 COOKIE2 Notification Payload . . . . . . . . . . . . . . . 16 71 3.7 NO_NATS_ALLOWED Notification Payload . . . . . . . . . . . 16 72 3.8 UNEXPECTED_NAT_DETECTED Notification Payload . . . . . . . 16 73 4. Security Considerations . . . . . . . . . . . . . . . . . . . 17 74 4.1 Traffic Redirection and Hijacking . . . . . . . . . . . . 17 75 4.2 IPsec Payload Protection . . . . . . . . . . . . . . . . . 17 76 4.3 Denial-of-Service Attacks Against Third Parties . . . . . 18 77 4.4 Spoofing Network Connectivity Indications . . . . . . . . 19 78 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 79 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 7.1 Normative References . . . . . . . . . . . . . . . . . . . 20 82 7.2 Informative References . . . . . . . . . . . . . . . . . . 20 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 21 84 A. Changelog . . . . . . . . . . . . . . . . . . . . . . . . . . 22 85 Intellectual Property and Copyright Statements . . . . . . . . 23 87 1. Introduction 89 1.1 Motivation 91 IKEv2 is used for performing mutual authentication and establishing 92 and maintaining IPsec security associations (SAs). In the current 93 specifications, the IPsec and IKE SAs are created implicitly between 94 the IP addresses that are used when the IKE_SA is established. These 95 IP addresses are then used as the outer (tunnel header) addresses for 96 tunnel mode IPsec packets. Currently, it is not possible to change 97 these addresses after the IKE_SA has been created. 99 There are scenarios where these IP addresses might change. One 100 example is mobility: a host changes its point of network attachment, 101 and receives a new IP address. Another example is a multihoming host 102 that would like to change to a different interface if, for instance, 103 the currently used address stops working for some reason. 105 Although the problem can be solved by creating new IKE and IPsec SAs 106 when the addresses need to be changed, this may not be optimal for 107 several reasons. In some cases, creating a new IKE_SA may require 108 user interaction for authentication (entering a code from a token 109 card, for instance). Creating new SAs often also involves expensive 110 calculations and possibly a large number of roundtrips. Due to these 111 reasons, a mechanism for updating the IP addresses of existing IKE 112 and IPsec SAs is needed. The MOBIKE protocol described in this 113 document provides such a mechanism. 115 The main scenario for MOBIKE is making it possible for a remote 116 access VPN user to move from one address to another without re- 117 establishing all security associations with the VPN gateway. For 118 instance, a user could start from fixed Ethernet in the office, and 119 then disconnect the laptop and move to office wireless LAN. When 120 leaving the office the laptop could start using GPRS, and switch to a 121 different wireless LAN when the user arrives home. MOBIKE updates 122 only the outer (tunnel header) addresses of IPsec SAs, and the 123 addresses and others traffic selectors used inside the tunnel stay 124 unchanged. Thus, mobility can be (mostly) invisible to applications 125 and their connections using the VPN. 127 MOBIKE also supports more complex scenarios where the VPN gateway 128 also has several network interfaces: these interfaces could be 129 connected to different networks or ISPs, they may have may be a mix 130 of IPv4 and IPv6 addresses, and the addresses may change over time. 131 Furthermore, both parties could be VPN gateways relaying traffic for 132 other parties. 134 Note that this document does not claim to solve all the problems IETF 135 MOBIKE working group has been chartered to work on. It is assumed 136 that issues such as transport mode (updating traffic selectors), 137 PFKEY extensions, and tunnel overhead reduction will be handled in 138 separate documents. 140 1.2 MOBIKE Protocol Overview 142 Since MOBIKE allows both parties to have several addresses, this 143 leads us to an important question: there are up to N*M pairs of IP 144 addresses that could potentially be used. How to decide which of 145 these pairs should be used? The decision has to take into account 146 several factors. First, the parties have may preferences about which 147 interface should be used, due to performance and cost reasons, for 148 instance. Second, the decision is constrained by the fact that some 149 of the pairs may not work at all due to incompatible IP versions, 150 outages somewhere in the network, problems at the local link at 151 either end, and so on. 153 MOBIKE solves this problem by taking a simple approach: the party 154 that initiated the IKE_SA (the "client" in remote access VPN 155 scenario) is responsible for deciding which address pair is used for 156 the IPsec SAs, and collecting the information it needs to make this 157 decision (such as determining which address pairs work or do not 158 work). The other party (the "gateway" in remote access VPN scenario) 159 simply tells the initiator what addresses it has, but does not update 160 the IPsec SAs until it receives a message from the initiator to do 161 so. 163 Making the decision at the initiator is consistent with how normal 164 IKEv2 works: the initiator decides which addresses it uses when 165 contacting the responder. It also makes sense especially when the 166 initiator is the mobile node: it is in a better position to decide 167 which of its network interfaces should be used for both upstream and 168 downstream traffic. 170 The details of exactly how the initiator makes the decision, what 171 information is used in making it, how the information is collected, 172 how preferences affect the decision, and when a decision needs to be 173 changed, are largely beyond the scope of MOBIKE. This does not mean 174 that these details are unimportant: on the contrary, they are likely 175 to be crucial in any real system. However, MOBIKE is concerned with 176 these details only to the extent that they are visible in IKEv2/IPsec 177 messages exchanged between the peers (and thus need to be 178 standardized to ensure interoperability). Issues such as mobility 179 detection and local policies are also not specific to MOBIKE, but 180 apply to existing mobility protocols such as Mobile IPv4 [MIP4] as 181 well. 183 MOBIKE also has to deal with situations where the network contains 184 NATs or stateful packet filters (for brevity, the rest of this 185 document talks simply about NATs). When the addresses used for IPsec 186 SAs are changed, MOBIKE can enable or disable IKEv2 NAT Traversal as 187 needed. However, if the party "outside" the NAT changes its IP 188 address, it may no longer be able to send packets to the party 189 "behind" the NAT, since the packets may not (depending on the exact 190 type of NAT) match the NAT mapping state. Here MOBIKE assumes that 191 the initiator is the party "behind" the NAT, and does not fully 192 support the case where the responder's addresses change when NATs are 193 present. 195 Updating the addresses of IPsec SAs naturally has to take into 196 account several security considerations. MOBIKE includes two 197 features designed to address these considerations. First, a "return 198 routability" check can be used to verify the addresses provided by 199 the peer. This makes it more difficult to flood third parties with 200 large amounts of traffic. Second, a "NAT prohibition" feature 201 ensures that IP addresses have not been modified by NATs, IPv4/IPv6 202 translation agents, or other similar devices. This feature is mainly 203 intended for site-to-site VPNs where the administrators may know 204 beforehand that NATs are not present, and thus any modification to 205 the packet can be considered to be an attack. 207 1.3 Terminology and Notations 209 When messages containing IKEv2 payloads are shown, optional payloads 210 are shown in brackets (for instance, "[FOO]"), and a plus sign 211 indicates that a payload can be repeated one or more times (for 212 instance, "FOO+"). 214 When this document talks about updating the source/destination 215 addresses of an IPsec SA, it means updating IPsec-related state so 216 that outgoing ESP/AH packets use those addresses in the tunnel 217 header. Depending on how the nominal division between Security 218 Association Database (SAD), Security Policy Database (SPD), and Peer 219 Authorization Database (PAD) described in [IPsecArch] is actually 220 implemented, an implementation can have several different places that 221 have to be updated. 223 In this document, the term "initiator" means the party who originally 224 initiated the first IKE_SA (in a series of possibly several rekeyed 225 IKE_SAs); "responder" is the other peer. During the lifetime of the 226 IKE_SA, both parties may initiate INFORMATIONAL or CREATE_CHILD_SA 227 exchanges; in this case, the terms "exchange initiator" and "exchange 228 responder" are used. The term "original initiator" (which in [IKEv2] 229 refers to the party who started the latest IKE_SA rekeying) is not 230 used in this document. 232 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 233 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 234 document are to be interpreted as described in [KEYWORDS]. 236 2. MOBIKE Protocol Exchanges 238 2.1 Signaling Support for MOBIKE 240 Implementations that wish to use MOBIKE for a particular IKE_SA MUST 241 include a MOBIKE_SUPPORTED notification in the IKE_AUTH exchange (in 242 case of multiple IKE_AUTH exchanges, in the message containing the SA 243 payload). 245 The MOBIKE_SUPPORTED notification payload is described in Section 3. 247 2.2 Additional Addresses 249 Both the initiator and responder MAY include one or more 250 ADDITIONAL_IP4_ADDRESS and/or ADDITIONAL_IP6_ADDRESS notification 251 payloads in the IKE_AUTH exchange (in case of multiple IKE_AUTH 252 exchanges, in the message containing the SA payload). 254 Initiator Responder 255 ----------- ----------- 256 HDR, SK { IDi, [CERT], [IDr], AUTH, 257 [CP(CFG_REQUEST)] 258 SAi2, TSi, TSr, 259 N(MOBIKE_SUPPORTED), 260 [N(ADDITIONAL_*_ADDRESS)+] --> 262 <-- HDR, SK { IDr, [CERT], AUTH, 263 [CP(CFG_REPLY)], 264 SAr2, TSi, TSr, 265 N(MOBIKE_SUPPORTED) 266 [N(ADDITIONAL_*_ADDRESS)+] } 268 The recipient stores this information, but no other action is taken 269 at this time. 271 Although both the initiator and responder maintain a set of peer 272 addresses (logically associated with the IKE_SA), it is important to 273 note that they use this information for slightly different purposes. 275 The initiator uses the set of responder addresses as an input to its 276 address selection policy; it may at some later point decide to move 277 the IPsec traffic to one of these addresses using the procedure 278 described in Section 2.3. The responder normally does not use the 279 set of initiator addresses for anything: the addresses are used only 280 when the responder's own addresses change. 282 The set of addresses available to the peers can change during the 283 lifetime of the IKE_SA. The procedure for updating this information 284 is described in Section 2.4. 286 Note that if some of the initiator's interfaces are behind a NAT 287 (from the responder's point of view), the addresses received by the 288 responder will be incorrect. This means the procedure for changing 289 responder addresses described in Section 2.4 does not fully work when 290 the initiator is behind a NAT. For the same reason, the peers also 291 SHOULD NOT use this information for any other purposes than what is 292 explicitly described in this document. 294 2.3 Changing Addresses in IPsec SAs 296 In MOBIKE, the initiator decides what addresses are used in the IPsec 297 SAs. That is, the responder usually never updates any IPsec SAs 298 without receiving an explicit UPDATE_SA_ADDRESSES request from the 299 initiator. (As described below, the responder can, however, update 300 the IKE_SA in some circumstances.) 302 The reasons why the initiator wishes to change the addresses are 303 largely beyond the scope of MOBIKE. Typically triggers include 304 information received from lower layers, such as changes in IP 305 addresses or link-down indications. Some of this information can be 306 unreliable: for instance, ICMP messages could be spoofed by an 307 attacker. Such information itself MUST NOT be used to conclude than 308 an update is needed: instead, the initiator SHOULD trigger dead peer 309 detection. 311 Changing addresses can also be triggered by events within IKEv2. At 312 least the following events can cause the initiator to re-evaluate its 313 local address selection policy, possibly leading to changing the 314 addresses. 316 o An IKEv2 request has been re-transmitted several times, but no 317 valid reply has been received. This suggests the current path is 318 no longer working. 320 o An INFORMATIONAL request containing ADDITIONAL_IP4/6_ADDRESS 321 payloads is received. This means the peer's addresses may have 322 changed. 324 o An UNACCEPTABLE_ADDRESSES notification is received as a response 325 to address update request (described below). 327 o The initiator receives a NAT_DETECTION_DESTINATION_IP payload that 328 does not match the previous UPDATE_SA_ADDRESSES response (see 329 Section 2.6 for a more detailed description). 331 The description in the rest of this section assumes that the 332 initiator has already decided what the new addresses should be. When 333 this decision has been made, the initiator 335 o Updates the IKE_SA and the IPsec SAs associated with this IKE_SA 336 with the new addresses, and sets the "pending_update" flag in the 337 IKE_SA. 339 o If NAT Traversal is not enabled, and the responder supports NAT 340 Traversal (as indicated by NAT detection payloads in the 341 IKE_SA_INIT exchange), and the initiator either suspects or knows 342 that a NAT is likely to be present, enables NAT Traversal. 344 o If there are outstanding IKEv2 requests (requests for which the 345 initiator has not yet received a reply), continues retransmitting 346 them using the addresses in the IKE_SA (the new addresses). 348 o When the window size allows, sends an INFORMATIONAL request 349 containing the UPDATE_SA_ADDRESSES notification payload (which 350 does not contain any data), and clears the "pending_update" flag. 352 Initiator Responder 353 ----------- ----------- 354 HDR, SK { N(UPDATE_SA_ADDRESSES), 355 [N(NAT_DETECTION_*_IP)], 356 [N(NO_NATS_ALLOWED)], 357 [N(COOKIE2)] } --> 359 o If a new address change occurs while waiting for the response, 360 starts again from the first step (and ignores responses to this 361 UPDATE_SA_ADDRESSES request). 363 When processing an INFORMATIONAL request containing the 364 UPDATE_SA_ADDRESSES notification, the responder 366 o Determines whether it has already received a newer 367 UPDATE_SA_ADDRESSES request than this one (if the responder uses a 368 window size greater than one, it is possible that requests are 369 received out of order). If it has, a response message is sent, 370 but no other action is taken. 372 o If the NO_NATS_ALLOWED payload is present, processes it as 373 described in Section 2.7. 375 o Checks that the (source IP address, destination IP address) pair 376 in the IP header is acceptable according to local policy. If it 377 is not, replies with a message containing the 378 UNACCEPTABLE_ADDRESSES notification (and possibly COOKIE2). 380 o Updates the IP addresses in the IKE_SA with the values from the IP 381 header. (Using the address from the IP header is consistent with 382 normal IKEv2, and allows IKEv2 to work with NATs without needing 383 unilateral self-address fixing [UNSAF].) 385 o Replies with an INFORMATIONAL response: 387 Initiator Responder 388 ----------- ----------- 389 <-- HDR, SK { [N(NAT_DETECTION_*_IP)], 390 [N(COOKIE2)], } 392 o If necessary, initiates a return routability check for the new 393 initiator address (see Section 2.5) and waits until the check is 394 completed. 396 o Updates the IPsec SAs associated with this IKE_SA with the new 397 addresses. 399 o If NAT Traversal is supported and NAT detection payloads were 400 included, enables or disables NAT Traversal. 402 When the initiator receives the reply, it 404 o If an address change has occured after the request was first sent, 405 no MOBIKE processing is done for the reply message, since a new 406 UPDATE_SA_ADDRESSES is going to be sent (or has already been sent, 407 if window size greater than one is in use). 409 o If the response contains the UNEXPECTED_NAT_DETECTED payload, 410 processes it as described in Section 2.7. 412 o If the response contains an UNACCEPTABLE_ADDRESSES notification 413 payload, the initiator MAY select another addresses and retry the 414 exchange, keep on using the current addresses, or disconnect. 416 o If NAT Traversal is supported and NAT detection payloads were 417 included, enables or disables NAT Traversal. 419 There is one exception to the rule that the responder never updates 420 any IPsec SAs without receiving an UPDATE_SA_ADDRESSES request. If 421 the source address the responder is currently using becomes 422 unavailable (i.e., sending packets using that source address is no 423 longer possible), the responder is allowed to update the IPsec SAs to 424 use some other address (in addition to initiating the procedure 425 described in the next section). 427 2.4 Updating Additional Addresses 429 As described in Section 2.2, both the initiator and responder can 430 send a list of additional addresses in the IKE_AUTH exchange. This 431 information can be updated by sending an INFORMATIONAL exchange 432 request message that contains either one or more ADDITIONAL_IP4/ 433 6_ADDRESS payloads or the NO_ADDITIONAL_ADDRESSES payload. 435 Initiator Responder 436 ----------- ----------- 437 HDR, SK { [N(ADDITIONAL_*_ADDRESS)+], 438 [N(NO_ADDITIONAL_ADDRESSES)], 439 [N(NO_NATS_ALLOWED)], 440 [N(COOKIE2)] } --> 442 <-- HDR, SK { [N(COOKIE2)] } 444 When a request containing ADDITIONAL_*_ADDRESS or 445 NO_ADDITIONAL_ADDRESSES payloads is received, the exchange responder 447 o Determines whether it has already received a newer request to 448 update the addresses (if a window size greater than one is used, 449 it is possible that the requests are received out of order). If 450 it has, a response message is sent, but the address set is not 451 updated. 453 o If the NO_NATS_ALLOWED payload is present, processes it as 454 described in Section 2.7. 456 o Updates the set of peer addresses based on the IP header and 457 ADDITIONAL_IP4/6_ADDRESS or NO_ADDITIONAL_ADDRESS payloads. 459 o Sends a response. 461 The initiator MAY include these payloads in the same request as 462 UPDATE_SA_ADDRESSES. 464 If the request to update the addresses is retransmitted using several 465 different source addresses, a new INFORMATIONAL request MUST be sent. 467 There is one additional complication: when the responder wants to 468 update the address set, the currently used addresses may no longer 469 work. In this case, the responder uses the additional address list 470 received from the initiator and the list of its own addresses to 471 determine which addresses to use for sending the INFORMATIONAL 472 request. This is the only time the responder uses the additional 473 address list received from the initiator. 475 Note that both peers can have their own policies about what addresses 476 are acceptable to use. A minimal "mobile client" could have a policy 477 that says that only the responder's address specified in local 478 configuration is acceptable. This kind of client does not have to 479 send or process ADDITIONAL_*_ADDRESS notification payloads. 480 Similarly, a simple "VPN gateway" that has only a single address, and 481 is not going to change it, does not need to send or understand 482 ADDITIONAL_*_ADDRESS notification payloads. 484 2.5 Return Routability Check 486 Both parties can optionally verify that the other party can actually 487 receive packets at the claimed address. This "return routability 488 check" can be done before updating the IPsec SAs, immediately after 489 updating them, or continuously during the connection. 491 By default, return routability check SHOULD be done before updating 492 the IPsec SAs. In environments where the peer is expected to be 493 well-behaving (many corporate VPNs, for instance), or the address can 494 be verified by some other means (e.g., the address is included in the 495 peer's certificate), the return routability check MAY be skipped or 496 postponed until after the IPsec SAs have been updated. 498 Any INFORMATIONAL exchange can be used for return routability 499 purposes (with one exception, described below): when a valid response 500 is received, we know the other party can receive packets at the 501 claimed address. 503 To ensure that the peer cannot generate the correct INFORMATIONAL 504 response without seeing the request, a new payload is added to 505 INFORMATIONAL messages. The sender of an INFORMATIONAL request MAY 506 include a COOKIE2 notification payload, and if included, the 507 recipient of an INFORMATIONAL request MUST copy the payload as-is to 508 the response. When processing the response, the original sender MUST 509 verify that the value is the same one as sent. If the values do not 510 match, the IKE_SA MUST be closed. 512 There is one additional issue that must be taken into account. If 513 the INFORMATIONAL request has been sent to several different 514 addresses (i.e., the destination address in the IKE_SA has been 515 updated after the request was first sent), receiving the 516 INFORMATIONAL response does not tell which address is the working 517 one. In this case, a new INFORMATIONAL request needs to be sent to 518 check return routability. 520 2.6 Changes in NAT Mappings 522 IKEv2 performs Dead Peer Detection (DPD) if there has recently been 523 only outgoing traffic on all of the SAs associated with the IKE_SA. 525 In MOBIKE, these messages can also be used to detect if NAT mappings 526 have changed (for example, if the keepalive internal is too long, or 527 the NAT box is rebooted). More specifically, if both peers support 528 both this specification and NAT Traversal, NAT_DETECTION_*_IP 529 payloads MAY be included in any INFORMATIONAL request; if the request 530 includes them, the responder MUST also include them in the response 531 (but no other action is taken, unless otherwise specified). 533 When the initiator is behind a NAT, it SHOULD include these payloads 534 in DPD messages, and compare the received 535 NAT_DETECTION_DESTINATION_IP payload with the value from the previous 536 UPDATE_SA_ADDRESSES response (or the IKE_SA_INIT response). If the 537 values do not match, the IP address and/or port seen by the responder 538 has changed, and the initiator SHOULD send UPDATE_SA_ADDRESSES as 539 described in Section 2.3. 541 When MOBIKE is in use, the host not behind a NAT SHOULD NOT use the 542 dynamic updates specified in [IKEv2] Section 2.23 (where the peer 543 address and port are updated from the last valid authenticated 544 packet). This ensures that both peers have a consistent view of when 545 addresses are to be changed, and prevents conflicts between MOBIKE- 546 originated updates and NAT-T dynamic updates. It also means that an 547 INFORMATIONAL exchange that does not contain UPDATE_SA_ADDRESSES does 548 not cause any changes, allowing it to be used for, e.g., testing 549 whether a particular path works. 551 2.7 NAT Prohibition 553 IKEv2/IPsec implementations that do not support NAT Traversal can, in 554 fact, work across some types of one-to-one "basic" NATs and IPv4/IPv6 555 translation agents in tunnel mode. This may be considered a problem 556 in some circumstances, since in some sense any modification of the IP 557 addresses can be considered to be an attack. 559 The "NAT prohibition" feature allows the initiator to have a policy 560 that prevents the use of paths that contain NATs, IPv4/IPv6 561 translation agents, or other nodes that modify the addresses in the 562 IP header. This feature is mainly intended for site-to-site VPN 563 cases, where the administrators may know beforehand that NATs are not 564 present, and thus any modification to the packet can be considered to 565 be an attack. 567 This specification addresses the issue as follows. When an IPsec SA 568 is created, the tunnel header IP addresses (and port if doing UDP 569 encapsulation) are taken from the IKE_SA, not the message IP header. 570 The NO_NATS_ALLOWED payload is used to guarantee that NATs have not 571 modified the address used in IKE_SA. However, all response messages 572 are still sent to the address and port the corresponding request came 573 from. 575 An initiator who wishes to use this feature includes a 576 NO_NATS_ALLOWED payload in the IKE_SA_INIT request. The responder 577 then MUST calculate the expected value based on the values from the 578 IP header, and compare this with the value in the NO_NATS_ALLOWED 579 payload. If they do not match, the responder replies with "HDR(A,0), 580 N(UNEXPECTED_NAT_DETECTED)" and does not create any state. 582 Initiator Responder 583 ----------- ----------- 584 HDR, [N(COOKIE)], 585 SAi1, KEi, Ni, 586 [N(NO_NATS_ALLOWED)] --> 588 <-- HDR, SAr1, KEr, Nr, 589 [CERTREQ] 591 If the values do match, the responder initializes (local_address, 592 local_port, peer_address, peer_port) in the to-be-created IKE_SA with 593 values from the IP header. The same applies if neither 594 NO_NATS_ALLOWED nor NAT_DETECTION_*_IP payloads were included, or if 595 the responder does not support NAT Traversal. 597 If the IKE_SA_INIT request included NAT_DETECTION_*_IP payloads but 598 no NO_NATS_ALLOWED payload, the situation is different since the 599 initiator may at this point change from port 500 to 4500. In this 600 case, the responder initializes (local_address, local_port, 601 peer_address, peer_port) from the first IKE_AUTH request. 603 IKEv2 requires that if an IPsec endpoint discovers a NAT between it 604 and its correspondent, it MUST send all subsequent traffic to and 605 from port 4500. To simplify things, implementations that support 606 both this specification and NAT Traversal MUST change to port 4500 if 607 the correspondent also supports both, even if no NAT was detected 608 between them (this way, there is no need to change the ports later). 610 NO_NATS_ALLOWED payloads can also be included when changing the 611 addresses of IPsec SAs (see Section 2.3) and updating the additional 612 addresses (see Section 2.4). An initiator using this "NAT 613 prohibition" feature includes a NO_NATS_ALLOWED payload in all 614 address update messages. 616 If the initiator receives an UNEXPECTED_NAT_DETECTION notification in 617 response to its request, it SHOULD retry the operation several times 618 using new IKE_SA_INIT/INFORMATIONAL requests. This ensures that an 619 attacker who is able to modify only a single packet does not 620 unnecessarily cause a path to remain unused. 622 2.8 Failure Recovery and Timeouts 624 In MOBIKE, the initiator is responsible for detecting and recovering 625 from most failures. 627 To give the initiator enough time to detect the error, the responder 628 SHOULD use relatively long timeout intervals when, for instance, 629 retransmitting IKEv2 requests or deciding whether to initiate dead 630 peer detection. 632 3. Payload Formats 634 3.1 MOBIKE_SUPPORTED Notification Payload 636 The MOBIKE_SUPPORTED notification payload is included in the IKE_AUTH 637 exchange to indicate that the implementation supports this 638 specification. 640 The Notify Message Type for MOBIKE_SUPPORTED is TBD-BY- 641 IANA(16396..40959). The Protocol ID and SPI Size fields are set to 642 zero. There is no data associated with this Notify type. 644 3.2 ADDITIONAL_IP4/6_ADDRESS Notification Payloads 646 Both parties can include ADDITIONAL_IP4_ADDRESS and/or 647 ADDITIONAL_IP6_ADDRESS payloads in the IKE_AUTH exchange and 648 INFORMATIONAL exchange request messages; see Section 2.2 and 649 Section 2.4 for more detailed description. 651 The Notify Message Types for ADDITIONAL_IP4_ADDRESS and 652 ADDITIONAL_IP6_ADDRESS are TBD-BY-IANA(16396..40959) and TBD-BY- 653 IANA(16396..40959), respectively. The Protocol ID and SPI Size 654 fields are set to zero. The data associated with these Notify types 655 is either a four-octet IPv4 address or a 16-octet IPv6 address. 657 3.3 NO_ADDITIONAL_ADDRESSES Notification Payload 659 The NO_ADDITIONAL_ADDRESSES payload can be included in an 660 INFORMATIONAL exchange request messages to indicate that the exchange 661 initiator does not have addresses beyond the one used in the exchange 662 (see Section 2.4 for more detailed description). 664 The Notify Message Type for NO_ADDITIONAL_ADDRESSES is TBD-BY- 665 IANA(16396..40959). The Protocol ID and SPI Size fields are set to 666 zero. There is no data associated with this Notify type. 668 3.4 UPDATE_SA_ADDRESSES Notification Payload 670 This payload is included in INFORMATIONAL exchange requests sent by 671 the initiator to update addresses of the IKE_SA and IPsec SAs (see 672 Section 2.3). 674 The Notify Message Type for UPDATE_SA_ADDRESSES is TBD-BY- 675 IANA(16396..40959). The Protocol ID and SPI Size fields are set to 676 zero. There is no data associated with this Notify type. 678 3.5 UNACCEPTABLE_ADDRESSES Notification Payload 680 The responder can include this notification payload in an 681 INFORMATIONAL exchange response to indicate that the address change 682 in the corresponding request message (which contained an 683 UPDATE_SA_ADDRESSES notification payload) was not carried out. 685 The Notify Message Type for UNACCEPTABLE_ADDRESSES is TBD-BY- 686 IANA(40..8191). The Protocol ID and SPI Size fields are set to zero. 687 There is no data associated with this Notify type. 689 3.6 COOKIE2 Notification Payload 691 This payload MAY be included in any INFORMATIONAL request for return 692 routability check purposes (see Section 2.5). If the INFORMATIONAL 693 request includes COOKIE2, the exchange responder MUST copy the 694 payload to the response message. 696 The data associated with this notification MUST be between 8 and 64 697 octets in length (inclusive), and MUST be chosen by the exchange 698 initiator in a way that is unpredictable to the exchange responder. 699 The Notify Message Type for this message is TBD-BY- 700 IANA(16396..40959). The Protocol ID and SPI Size fields are set to 701 zero. 703 3.7 NO_NATS_ALLOWED Notification Payload 705 See Section 2.7 for a description of this payload. 707 The data associated with this notification is the SHA-1 hash 708 [FIPS180-2] of the following data: IKE SPIs (in the order they appear 709 in the header), the IP address and port from which the packet was 710 sent, and the IP address and port to which the packet was sent. The 711 Notify Message Type for this message is TBD-BY-IANA(16396..40959). 712 The Protocol ID and SPI Size fields are set to zero. 714 3.8 UNEXPECTED_NAT_DETECTED Notification Payload 716 See Section 2.7 for a description of this payload. 718 The Notify Message Type for UNEXPECTED_NAT_DETECTED is TBD-BY- 719 IANA(40..8191). The Protocol ID and SPI Size fields are set to zero. 720 There is no data associated with this Notify type. 722 4. Security Considerations 724 The main goals of this specification are to not reduce the security 725 offered by usual IKEv2 procedures and to counter mobility related 726 threats in an appropriate manner. This section describes new 727 security considerations introduced by MOBIKE. See [IKEv2] for 728 security considerations for IKEv2 in general. 730 4.1 Traffic Redirection and Hijacking 732 MOBIKE payload relating to updating addresses are encrypted, 733 integrity protected, and replay protected using the IKE_SA. This 734 assures that no one except the participants can, for instance, give a 735 control message to change the addresses. 737 However, just like with normal IKEv2, the actual IP addresses in the 738 IP header are not covered by the integrity protection. This means 739 that a NAT between the parties (or an attacker acting as a NAT) can 740 modify the addresses and cause incorrect tunnel header (outer) IP 741 addresses to be used for IPsec SAs. The scope of this attack is 742 limited mainly to denial-of-service, since all traffic is protected 743 using IPsec. 745 MOBIKE introduces the NO_NATS_ALLOWED payload that can be used to 746 detect modification of the addresses in the IP header by outsiders 747 When this payload is used, communication through NATs and other 748 address translators is impossible. This feature is mainly intended 749 for site-to-site VPN cases, where the administrators may know 750 beforehand that valid NATs are not present, and thus any modification 751 to the packet can be considered to be an attack. However, this 752 feature SHOULD NOT be enabled by default, since it creates a denial- 753 of-service vulnerability even when no malicious attackers are 754 present: a misconfiguration or introduction of a (non-malicious) NAT 755 can cause the connection to fail. 757 4.2 IPsec Payload Protection 759 The use of IPsec protection on payload traffic protects the 760 participants against disclosure of the contents of the traffic, 761 should the traffic end up in an incorrect destination or be 762 eavesdropped along the way. 764 However, security associations originally created for the protection 765 of a specific flow between specific addresses may be moved through 766 MOBIKE. The level of required protection may be different in a new 767 location of a VPN client, for instance. 769 It is recommended that security policies for peers that are allowed 770 to use MOBIKE are configured in a manner that takes into account that 771 a single security association can be used through different paths at 772 different times. 774 4.3 Denial-of-Service Attacks Against Third Parties 776 Traffic redirection may be performed not just to gain access to the 777 traffic (not very interesting since it is encrypted) or deny service 778 to the peers, but also to cause a denial-of-service attack for a 779 third party. For instance, a high-speed TCP session or a multimedia 780 stream may be redirected towards a victim host, causing its 781 communications capabilities to suffer. 783 The attackers in this threat can be either outsiders or even one of 784 the participants. In usual VPN usage scenarios, attacks by the 785 participants can be easily dealt with if the authentication performed 786 in the initial IKEv2 negotiation can be traced to persons who can be 787 held responsible for the attack. This may not be the case in all 788 scenarios, particularly with opportunistic approaches to security. 790 Normally such attacks would expire in a short time frame due to the 791 lack of responses (such as transport layer acknowledgements) from the 792 victim. However, as described in [Aura02], malicious participants 793 would typically be able to spoof such acknowledgements and maintain 794 the traffic flow for an extended period of time. For instance, if 795 the attacker opened the TCP stream itself before redirecting it to 796 the victim, the attacker becomes aware of the sequence number space 797 used in this particular session. 799 It should also be noted, as shown in [Bombing], that without ingress 800 filtering in the attacker's network such attacks are already possible 801 simply by sending spoofed packets from the attacker to the victim 802 directly. Furthermore, if the attacker's network has ingress 803 filtering, this attack is largely prevented for MOBIKE as well. 804 Consequently, it makes little sense to protect against attacks of 805 similar nature in MOBIKE. However, it still makes sense to limit the 806 amplification capabilities provided to attackers, so that they cannot 807 use stream redirection to send 1000 packets to the victim by sending 808 just a few packets themselves. 810 This specification requires the use of return routability tests 811 (under certain conditions) to limit the duration of any "third party 812 bombing" attacks by off-path (relative to the victim) attackers. The 813 tests are authenticated messages that the peer has to respond to, and 814 can be performed either before the address change takes effect, 815 immediately afterwards, or even periodically during the session. The 816 tests contain unpredictable data, and only someone who has the keys 817 associated with the IKE SA and has seen the request packet can 818 properly respond to the test. 820 4.4 Spoofing Network Connectivity Indications 822 Attackers may spoof various indications from lower layers and the 823 network in an effort to confuse the peers about which addresses are 824 or are not working. For example, attackers may spoof link-layer 825 error messages in an effort to cause the parties to move their 826 traffic elsewhere or even to disconnect. Attackers may also spoof 827 information related to network attachments, router discovery, and 828 address assignments in an effort to make the parties believe they 829 have Internet connectivity when in reality they do not. 831 This may cause use of non-preferred addresses or even denial-of- 832 service. 834 MOBIKE does not provide any protection of its own for indications 835 from other parts of the protocol stack. These vulnerabilities can be 836 mitigated through the use of techniques specific to the other parts 837 of the stack, such as properly dealing with ICMP errors 838 [ICMPAttacks], link layer security, or the use of [SEND] to protect 839 IPv6 Router and Neighbor Discovery. 841 Ultimately MOBIKE depends on the delivery of IKEv2 messages to 842 determine which paths can be used. If IKEv2 messages sent using a 843 particular source and destination addresses reach the recipient and a 844 reply is received, MOBIKE will usually consider the path working;if 845 no reply is received even after retransmissions, MOBIKE will suspect 846 the path is broken. An attacker who can consistently control the 847 delivery or non-delivery of the IKEv2 messages in the network can 848 thus influence which addresses actually get used. 850 5. IANA Considerations 852 This document does not create any new namespaces to be maintained by 853 IANA, but it requires new values in namespaces that have been defined 854 in the IKEv2 base specification [IKEv2]. 856 This defines several new IKEv2 notification payloads whose values are 857 to be allocated from the "IKEv2 Notification Payload Types" 858 namespace. These notification payloads are described in Section 3. 860 6. Acknowledgements 862 This document is a collaborative effort of the entire MOBIKE WG. We 863 would particularly like to thank Jari Arkko, Francis Dupont, Paul 864 Hoffman, Tero Kivinen, and Hannes Tschofenig. This document also 865 incorporates ideas and text from earlier MOBIKE protocol proposals, 866 including [AddrMgmt], [Kivinen], [MOPO], and [SMOBIKE], and the 867 MOBIKE design document [Design]. 869 7. References 871 7.1 Normative References 873 [FIPS180-2] 874 National Institute of Standards and Technology, 875 "Specifications for the Secure Hash Standard", Federal 876 Information Processing Standard (FIPS) Publication 180-2, 877 August 2002. 879 [IKEv2] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 880 draft-ietf-ipsec-ikev2-17 (work in progress), 881 October 2004. 883 [KEYWORDS] 884 Bradner, S., "Key words for use in RFCs to Indicate 885 Requirement Levels", RFC 2119, March 1997. 887 [UDPEncap] 888 Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 889 Stenberg, "UDP Encapsulation of IPsec ESP Packets", 890 RFC 3948, January 2005. 892 7.2 Informative References 894 [AddrMgmt] 895 Dupont, F., "Address Management for IKE version 2", 896 draft-dupont-ikev2-addrmgmt-07 (work in progress), 897 May 2005. 899 [Aura02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 900 Location Management", Proc. 18th Annual Computer Security 901 Applications Conference (ACSAC), December 2002. 903 [Bombing] Dupont, F., "A note about 3rd party bombing in Mobile 904 IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), 905 June 2005. 907 [Design] Kivinen, T. and H. Tschofenig, "Design of the MOBIKE 908 protocol", draft-ietf-mobike-design-02 (work in progress), 909 February 2005. 911 [ICMPAttacks] 912 Gont, F., "ICMP attacks against TCP", 913 draft-gont-tcpm-icmp-attacks-03 (work in progress), 914 December 2004. 916 [IPsecArch] 917 Kent, S. and K. Seo, "Security Architecture for the 918 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 919 in progress), March 2005. 921 [Kivinen] Kivinen, T., "MOBIKE protocol", 922 draft-kivinen-mobike-protocol-00 (work in progress), 923 February 2004. 925 [MIP4] Perkins, C., "IP Mobility Support for IPv4", RFC 3344, 926 August 2002. 928 [MOPO] Eronen, P., "Mobility Protocol Options for IKEv2 (MOPO- 929 IKE)", draft-eronen-mobike-mopo-02 (work in progress), 930 February 2005. 932 [PseudoNAT] 933 Dupont, F. and J-J. Bernard, "Transient pseudo-NAT attacks 934 or how NATs are even more evil than you believed", 935 draft-dupont-transient-pseudonat-04 (expired) (work in 936 progress), June 2004. 938 [SEND] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 939 Neighbor Discovery (SEND)", RFC 3971, March 2005. 941 [SMOBIKE] Eronen, P. and H. Tschofenig, "Simple Mobility and 942 Multihoming Extensions for IKEv2 (SMOBIKE)", 943 draft-eronen-mobike-simple-00 (work in progress), 944 March 2004. 946 [UNSAF] Daigle, L., "IAB Considerations for UNilateral Self- 947 Address Fixing (UNSAF) Across Network Address 948 Translation", RFC 3424, November 2002. 950 Author's Address 952 Pasi Eronen (editor) 953 Nokia Research Center 954 P.O. Box 407 955 FIN-00045 Nokia Group 956 Finland 958 Email: pasi.eronen@nokia.com 960 Appendix A. Changelog 962 (This section should be removed by the RFC editor.) 964 Changes from -01 to -02: 966 o Moved MOBIKE_SUPPORTED from IKE_SA_INIT to IKE_AUTH (issues 35, 967 37). 969 o Changed terminology related to NAT prohibition (issues 22, 24). 971 o Rewrote much of the ADDITIONAL_*_ADDRESS text, added 972 NO_ADDITIONAL_ADDRESSES notification. 974 o Use NAT detection payloads to detect changes in NAT mappings 975 (issue 34). 977 o Removed separate PATH_TEST message (issue 34). 979 o Clarified processing of UNACCEPTABLE_ADDRESSES when request has 980 been sent using several different addresses (issue 36). 982 o Clarified changing of ports 500/4500 (issue 33). 984 o Updated security considerations (issues 27 and 28). 986 o No need to include COOKIE2 in non-RR messages (issue 32). 988 o Many editorial fixes and clarifications (issue 38, 40). 990 o Use the terms initiator and responder more consistently. 992 o Clarified that this document does not solve all problems in MOBIKE 993 WG charter (issue 40). 995 Changes from -00 to -01: 997 o Editorial fixes and small clarifications (issues 21, 25, 26, 29). 999 o Use Protocol ID zero for notifications (issue 30). 1001 o Separate ADDITIONAL_*_ADDRESS payloads for IPv4 and IPv6 (issue 1002 23). 1004 o Use the word "path" only in senses that include the route taken 1005 (issue 29). 1007 Intellectual Property Statement 1009 The IETF takes no position regarding the validity or scope of any 1010 Intellectual Property Rights or other rights that might be claimed to 1011 pertain to the implementation or use of the technology described in 1012 this document or the extent to which any license under such rights 1013 might or might not be available; nor does it represent that it has 1014 made any independent effort to identify any such rights. Information 1015 on the procedures with respect to rights in RFC documents can be 1016 found in BCP 78 and BCP 79. 1018 Copies of IPR disclosures made to the IETF Secretariat and any 1019 assurances of licenses to be made available, or the result of an 1020 attempt made to obtain a general license or permission for the use of 1021 such proprietary rights by implementers or users of this 1022 specification can be obtained from the IETF on-line IPR repository at 1023 http://www.ietf.org/ipr. 1025 The IETF invites any interested party to bring to its attention any 1026 copyrights, patents or patent applications, or other proprietary 1027 rights that may cover technology that may be required to implement 1028 this standard. Please address the information to the IETF at 1029 ietf-ipr@ietf.org. 1031 Disclaimer of Validity 1033 This document and the information contained herein are provided on an 1034 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1035 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1036 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1037 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1038 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1039 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1041 Copyright Statement 1043 Copyright (C) The Internet Society (2005). This document is subject 1044 to the rights, licenses and restrictions contained in BCP 78, and 1045 except as set forth therein, the authors retain all their rights. 1047 Acknowledgment 1049 Funding for the RFC Editor function is currently provided by the 1050 Internet Society.