idnits 2.17.1 draft-ietf-mobike-design-08.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 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1370. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1377. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1383. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 674: '...IKEv2 packets to MUST NOT (it would br...' RFC 2119 keyword, line 990: '...optional. Nodes MAY also perform thes...' RFC 2119 keyword, line 1076: '... the node not behind NAT SHOULD detect...' RFC 2119 keyword, line 1091: '... MUST NOT for IKE SA packets if MOBI...' RFC 2119 keyword, line 1101: '...amic address updating of NAT-T to MUST...' 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 (March 3, 2006) is 6622 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) == Unused Reference: 'I-D.ietf-ipv6-unique-local-addr' is defined on line 1305, but no explicit reference was found in the text == Unused Reference: 'RFC1918' is defined on line 1310, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-nsis-nslp-natfw' is defined on line 1332, but no explicit reference was found in the text ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) == Outdated reference: A later version (-13) exists of draft-ietf-shim6-failure-detection-03 -- Obsolete informational reference (is this intentional?): RFC 2409 (Obsoleted by RFC 4306) -- Obsolete informational reference (is this intentional?): RFC 2401 (Obsoleted by RFC 4301) == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-03 -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) -- Obsolete informational reference (is this intentional?): RFC 3775 (Obsoleted by RFC 6275) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-13 -- Obsolete informational reference (is this intentional?): RFC 2462 (Obsoleted by RFC 4862) -- Obsolete informational reference (is this intentional?): RFC 2461 (Obsoleted by RFC 4861) == Outdated reference: A later version (-25) exists of draft-ietf-nsis-nslp-natfw-09 Summary: 5 errors (**), 0 flaws (~~), 9 warnings (==), 13 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IKEv2 Mobility and Multihoming T. Kivinen 3 (mobike) Safenet, Inc. 4 Internet-Draft H. Tschofenig 5 Expires: September 4, 2006 Siemens 6 March 3, 2006 8 Design of the MOBIKE Protocol 9 draft-ietf-mobike-design-08.txt 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on September 4, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2006). 40 Abstract 42 The MOBIKE (IKEv2 Mobility and Multihoming) is an extension of the 43 Internet Key Exchange Protocol version 2 (IKEv2). These extensions 44 should enable an efficient management of IKE and IPsec Security 45 Associations when a host possesses multiple IP addresses and/or where 46 IP addresses of an IPsec host change over time (for example, due to 47 mobility). 49 This document discusses the involved network entities, and the 50 relationship between IKEv2 signaling and information provided by 51 other protocols. Design decisions for the MOBIKE protocol, 52 background information and discussions within the working group are 53 recorded. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. Mobility Scenario . . . . . . . . . . . . . . . . . . . . 8 61 3.2. Multihoming Scenario . . . . . . . . . . . . . . . . . . . 9 62 3.3. Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 9 63 4. Scope of MOBIKE . . . . . . . . . . . . . . . . . . . . . . . 11 64 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 14 65 5.1. Choosing Addresses . . . . . . . . . . . . . . . . . . . . 14 66 5.1.1. Inputs and Triggers . . . . . . . . . . . . . . . . . 14 67 5.1.2. Connectivity . . . . . . . . . . . . . . . . . . . . . 14 68 5.1.3. Discovering Connectivity . . . . . . . . . . . . . . . 15 69 5.1.4. Decision Making . . . . . . . . . . . . . . . . . . . 15 70 5.1.5. Suggested Approach . . . . . . . . . . . . . . . . . . 15 71 5.2. NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 15 72 5.2.1. Background and Constraints . . . . . . . . . . . . . . 16 73 5.2.2. Fundamental Restrictions . . . . . . . . . . . . . . . 16 74 5.2.3. Moving to behind a NAT and back . . . . . . . . . . . 16 75 5.2.4. Responder behind a NAT . . . . . . . . . . . . . . . . 17 76 5.2.5. NAT Prevention . . . . . . . . . . . . . . . . . . . . 18 77 5.2.6. Suggested Approach . . . . . . . . . . . . . . . . . . 18 78 5.3. Scope of SA Changes . . . . . . . . . . . . . . . . . . . 18 79 5.4. Zero Address Set Functionality . . . . . . . . . . . . . . 19 80 5.5. Return Routability Check . . . . . . . . . . . . . . . . . 20 81 5.5.1. Employing MOBIKE Results in other Protocols . . . . . 22 82 5.5.2. Return Routability Failures . . . . . . . . . . . . . 23 83 5.5.3. Suggested Approach . . . . . . . . . . . . . . . . . . 24 84 5.6. IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25 85 6. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 26 86 6.1. Indicating Support for MOBIKE . . . . . . . . . . . . . . 26 87 6.2. Path Testing and Window size . . . . . . . . . . . . . . . 27 88 6.3. Message presentation . . . . . . . . . . . . . . . . . . . 28 89 6.4. Updating address set . . . . . . . . . . . . . . . . . . . 29 90 7. Security Considerations . . . . . . . . . . . . . . . . . . . 30 91 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 31 92 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 32 93 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33 94 10.1. Normative references . . . . . . . . . . . . . . . . . . . 33 95 10.2. Informative References . . . . . . . . . . . . . . . . . . 33 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36 97 Intellectual Property and Copyright Statements . . . . . . . . . . 37 99 1. Introduction 101 The purpose of IKEv2 is to mutually authenticate two hosts, establish 102 one or more IPsec Security Associations (SAs) between them, and 103 subsequently manage these SAs (for example, by rekeying or deleting). 104 IKEv2 enables the hosts to share information that is relevant to both 105 the usage of the cryptographic algorithms that should be employed 106 (e.g., parameters required by cryptographic algorithms and session 107 keys) and to the usage of local security policies, such as 108 information about the traffic that should experience protection. 110 IKEv2 assumes that an IKE SA is created implicitly between the IP 111 address pair that is used during the protocol execution when 112 establishing the IKEv2 SA. This means that, in each host, only one 113 IP address pair is stored for the IKEv2 SA as part of a single IKEv2 114 protocol session, and, for tunnel mode SAs, the hosts places this 115 single pair in the outer IP headers. Existing IPsec documents make 116 no provision to change this pair after an IKE SA is created (except 117 for dynamic address update of NAT-T). 119 There are scenarios where one or both of the IP addresses of this 120 pair may change during an IPsec session. In principle, the IKE SA 121 and all corresponding IPsec SAs could be re-established after the IP 122 address has changed. However, this is a relatively expensive 123 operation, and can be problematic when such changes are frequent. 124 Moreover, manual user interaction (for example when using human- 125 operated token cards (SecurID)) might be required as part of the 126 IKEv2 authentication procedure. Therefore, an automatic mechanism is 127 needed that updates the IP addresses associated with the IKE SA and 128 the IPsec SAs. The MOBIKE protocol provides such a mechanism. 130 The MOBIKE protocol is assumed to work on top of IKEv2 [RFC4306]. As 131 IKEv2 is built on the architecture described in RFC2401bis [RFC4301], 132 all protocols developed within the MOBIKE working group must be 133 compatible with both IKEv2 and the architecture described in RFC4301. 134 This document does not discusses mobility and multi-homing support 135 for IKEv1 [RFC2409] nor the IPsec architecture described in RFC2401 136 [RFC2401]. 138 This document is structured as follows: After introducing some 139 important terms in Section 2, a number of relevant usage scenarios 140 are discussed in Section 3. Section 4 describes the scope of the 141 MOBIKE protocol. Section 5 discusses design considerations affecting 142 the MOBIKE protocol. Section 6 investigates details regarding the 143 MOBIKE protocol. Finally, this document concludes in Section 7 with 144 security considerations. 146 2. Terminology 148 This section introduces the terminology that is used in this 149 document. 151 Peer 153 A peer is an IKEv2 endpoint. In addition, a peer implements the 154 MOBIKE extensions, defined in [I-D.ietf-mobike-protocol]. 156 Available address 158 An address is said to be available if the following conditions are 159 met: 161 * The address has been assigned to an interface. 163 * If the address is an IPv6 address, we additionally require (a) 164 that the address is valid as defined in RFC 2461 [RFC2461], and 165 (b) that the address is not tentative as defined in RFC 2462 166 [RFC2462]. In other words, we require the address assignment 167 to be complete. 169 Note that this explicitly allows an address to be optimistic as 170 defined in [I-D.ietf-ipv6-optimistic-dad]. 172 * If the address is an IPv6 address, it is a global unicast or 173 unique site-local address, as defined in [I-D.ietf-ipv6-unique- 174 local-addr]. That is, it is not an IPv6 link-local address. 176 * The address and interface is acceptable for sending and 177 receiving traffic according to a local policy. 179 This definition is taken from [I-D.ietf-shim6-failure-detection] 180 and adapted for the MOBIKE context. 182 Locally operational address 184 An address is said to be locally operational if it is available 185 and its use is locally known to be possible and permitted. This 186 definition is taken from [I-D.ietf-shim6-failure-detection]. 188 Operational address pair 190 A pair of operational addresses are said to be an operational 191 address pair, if and only if bidirectional connectivity can be 192 shown between the two addresses. Note that sometimes it is 193 necessary to consider connectivity on a per-flow level between two 194 endpoints. This differentiation might be necessary to address 195 certain Network Address Translation types or specific firewalls. 196 This definition is taken from [I-D.ietf-shim6-failure-detection] 197 and adapted for the MOBIKE context. Although it is possible to 198 further differentiate unidirectional and bidirectional operational 199 address pairs, only bidirectional connectivity is relevant to this 200 document and unidirectional connectivity is out of scope. 202 Path 204 The sequence of routers traversed by the MOBIKE and IPsec packets 205 exchanged between the two peers. Note that this path may be 206 affected not only by the involved source and destination IP 207 addresses, but also by the transport protocol. Since MOBIKE and 208 IPsec packets have a different appearance on the wire, they might 209 be routed along a different path, for example due to load 210 balancing. This definition is taken from [RFC2960] and adapted to 211 the MOBIKE context. 213 Current path 215 The sequence of routers traversed by an IP packet that carries the 216 default source and destination addresses is said to be the Current 217 Path. This definition is taken from [RFC2960] and adapted to the 218 MOBIKE context. 220 Preferred address 222 The IP address of a peer to which MOBIKE and IPsec traffic should 223 be sent by default. A given peer has only one active preferred 224 address at a given point in time, except for the small time period 225 where it switches from an old to a new preferred address. This 226 definition is taken from [I-D.ietf-hip-mm] and adapted to the 227 MOBIKE context. 229 Peer address set 231 We denote the two peers of a MOBIKE session by peer A and peer B. 232 A peer address set is the subset of locally operational addresses 233 of peer A that is sent to peer B. A policy available at peer A 234 indicates which addresses are included in the peer address set. 235 Such a policy might be created either manually or automatically 236 through interaction with other mechanisms that indicate new 237 available addresses. 239 Bidirectional address pair 241 The address pair, where traffic can be sent to both directions, 242 simply by reversing the IP addresses. Note, that the path of the 243 packets going to each direction might be different. 245 Unidirectional address pair 247 The address pair, where traffic can only be sent in one direction, 248 and reversing the IP addresses and sending reply back does not 249 work. 251 For mobility related terminology (e.g., Make-before-break or Break- 252 before-make) see [RFC3753]. 254 3. Scenarios 256 In this section we discuss three typical usage scenarios for the 257 MOBIKE protocol. 259 3.1. Mobility Scenario 261 Figure 1 shows a break-before-make mobility scenario where a mobile 262 node changes its point of network attachment. Prior to the change, 263 the mobile node had established an IPsec connection with a security 264 gateway which offered, for example, access to a corporate network. 265 The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took 266 place over the path labeled as 'old path'. The involved packets 267 carried the MN's "old" IP address and were forwarded by the "old" 268 access router (OAR) to the security gateway (GW). 270 When the MN changes its point of network attachment, it obtains a new 271 IP address using stateful or stateless address configuration. The 272 goal of MOBIKE, in this scenario, is to enable the MN and the GW to 273 continue using the existing SAs and to avoid setting up a new IKE SA. 274 A protocol exchange, denoted by 'MOBIKE Address Update', enables the 275 peers to update their state as necessary. 277 Note that in a break-before-make scenario the MN obtains the new IP 278 address after it can no longer be reached at the old IP address. In 279 a make-before-break scenario, the MN is, for a given period of time, 280 reachable at both the old and the new IP address. MOBIKE should work 281 in both of the above scenarios. 283 (Initial IKEv2 Exchange) 284 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v 285 Old IP +--+ +---+ v 286 address |MN|------> |OAR| -------------V v 287 +--+ +---+ Old path V v 288 . +----+ v>>>>> +--+ 289 .move | R | -------> |GW| 290 . | | >>>>> | | 291 v +----+ ^ +--+ 292 +--+ +---+ New path ^ ^ 293 New IP |MN|------> |NAR|--------------^ ^ 294 address +--+ +---+ ^ 295 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ 296 (MOBIKE Address Update) 298 ---> = Path taken by data packets 299 >>>> = Signaling traffic (IKEv2 and MOBIKE) 300 ...> = End host movement 302 Figure 1: Mobility Scenario 304 3.2. Multihoming Scenario 306 Another MOBIKE usage scenario is depicted in Figure 2. In this 307 scenario, the MOBIKE peers are equipped with multiple interfaces (and 308 multiple IP addresses). Peer A has two interface cards with two IP 309 addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 310 and IP_B2. Each peer selects one of its IP addresses as the 311 preferred address which is used for subsequent communication. 312 Various reasons (e.g., hardware or network link failures), may 313 require a peer to switch from one interface to another. 315 +------------+ +------------+ 316 | Peer A | *~~~~~~~~~* | Peer B | 317 | |>>>>>>>>>> * Network *>>>>>>>>>>| | 318 | IP_A1 +-------->+ +--------->+ IP_B1 | 319 | | | | | | 320 | IP_A2 +********>+ +*********>+ IP_B2 | 321 | | * * | | 322 +------------+ *~~~~~~~~~* +------------+ 324 ---> = Path taken by data packets 325 >>>> = Signaling traffic (IKEv2 and MOBIKE) 326 ***> = Potential future path through the network 327 (if Peer A and Peer B change their preferred 328 address) 330 Figure 2: Multihoming Scenario 332 Note that MOBIKE does not aim to support load balancing between 333 multiple IP addresses. That is, each peer uses only one of the 334 available address pairs at a given point in time. 336 3.3. Multihomed Laptop Scenario 338 The third scenario we consider is about a laptop, which has multiple 339 interface cards and therefore several ways to connect to the network. 340 It may, for example, have a fixed Ethernet card, a WLAN interface, a 341 GPRS adaptor, a Bluetooth interface or USB hardware. Not all 342 interfaces are used for communication all the time for a number of 343 reasons (e.g., cost, network availability, user convenience). The 344 policies that determine which interfaces are connected to the network 345 at any given point in time is outside the scope of the MOBIKE 346 protocol and, as such, this document. However, as the laptop changes 347 its point of attachment to the network, the set of IP addresses under 348 which the laptop is reachable, changes too. 350 In all of these scenarios, even if IP addresses change due to 351 interface switching or mobility, the IP address obtained via the 352 configuration payloads within IKEv2 remain unaffected. The IP 353 address obtained via the IKEv2 configuration payloads allow the 354 configuration of the inner IP address of the IPsec tunnel. As such, 355 applications might not detect any change at all. 357 4. Scope of MOBIKE 359 Getting mobility and multihoming actually working requires many 360 different components to work together, including coordinating 361 decisions between different layers, different mobility mechanisms, 362 and IPsec/IKE. Most of those aspects are beyond the scope of MOBIKE: 363 MOBIKE focuses only on what two peers need to agree at the IKEv2 364 level (like new message formats and some aspects of their processing) 365 required for interoperability. 367 The MOBIKE protocol is not trying to be a full mobility protocol; 368 there is no support for simultaneous movement or rendezvous 369 mechanism, and there is no support for route optimization etc. The 370 design document focuses on tunnel mode, everything going inside the 371 tunnel is unaffected by the changes in the tunnel header IP address, 372 and this is the mobility feature provided by the MOBIKE, i.e., 373 applications running inside the MOBIKE controlled IPsec tunnel might 374 not detect the movement since their IP addresses remain constant. 376 The MOBIKE protocol should be able to perform the following 377 operations (not all of those are done explictly by the current 378 protocol): 380 o Inform the other peer about the peer address set 382 o Inform the other peer about the preferred address 384 o Test connectivity along a path and there by to detect an outage 385 situation 387 o Change the preferred address 389 o Change the peer address set 391 o Ability to deal with Network Address Translation devices 393 Figure 3 shows an example protocol interaction between a pair of 394 MOBIKE peers. MOBIKE interacts with the packet processing module of 395 the IPsec implementation using an internal API (such as those based 396 on PF_KEY [RFC2367]). Using this API, the MOBIKE module can create 397 entries in the Security Association (SAD) and Security Policy 398 Databases (SPD). The packet processing module of the IPsec 399 implementation may also interact with IKEv2 and MOBIKE module using 400 this API. The content of the Security Policy and Security 401 Association Databases determines what traffic is protected with IPsec 402 in which fashion. MOBIKE, on the other hand, receives information 403 from a number of sources that may run both in kernel-mode and in 404 user-mode. These sources form the basis on which MOBIKE make 405 decisions regarding the set of available addresses, the peer address 406 set, and the preferred address. Policies may also affect the 407 selection process. 409 The peer address set and the preferred address needs to be made 410 available to the other peer. In order to address certain failure 411 cases, MOBIKE should perform connectivity tests between the peers 412 (potentially over a number of different paths). Although a number of 413 address pairs may be available for such tests, the most important is 414 the pair (source address, destination address) of the current path. 415 This is because this pair is selected for sending and receiving 416 MOBIKE signaling and IPsec traffic. If a problem along this current 417 path is detected (e.g., due to a router failure) it is necessary to 418 switch to a new current path. In order to be able to do so quickly, 419 it may be helpful to perform connectivity tests of other paths 420 periodically. Such a technique would also help in identifying 421 previously disconnected paths that become operational again. 423 +---------------------+ +----------------+ 424 | User-space | | | 425 | Protocols and | | MOBIKE and | 426 | Functions Relevant |<---------->| IKEv2 Module | 427 | MOBIKE (e.g., DHCP, | | | 428 | policies) | +----------------+ 429 +---------------------+ ^ 430 ^ | 431 | | User space 432 ++++++++++API++++++++++++++++++++++++++++PF_KEY+++++++++++++++ 433 | | Kernel space 434 | v 435 | +----------------+ 436 v | | 437 +---------------------+ | IPsec engine | 438 | Kernel-space |<---------->| (and databases)| 439 | Protocols | | | 440 | Relevant for | +----------------+ 441 | MOBIKE (e.g., ND, | ^ 442 | DNA, L2) |<---------------+ | 443 +---------------------+ v v 444 || +----------------+ 445 \/ | | 446 Inter- =====================>| IP forwarding, | 447 faces <=====================|input and output| 448 | | 449 +----------------+ 451 ===> = IP packets arriving/leaving a MOBIKE node 452 <-> = control and configuration operations 454 Figure 3: Framework 456 Please note that Figure 3 illustrates an example of how a MOBIKE 457 implementation could work. Hence, it serves illustrative purposes 458 only. 460 5. Design Considerations 462 This section discusses aspects affecting the design of the MOBIKE 463 protocol. 465 5.1. Choosing Addresses 467 One of the core aspects of the MOBIKE protocol is the selection of 468 the address for the IPsec packets we send. Choosing addresses for 469 the IKEv2 request is a somewhat separate problem: in many cases, they 470 will be the same (and in some design choice they will always be the 471 same, and could be forced to be the same by design). 473 5.1.1. Inputs and Triggers 475 How address changes are triggered is largely beyond the scope of 476 MOBIKE. The triggers can include, changes in the set of addresses, 477 various link-layer indications, failing dead peer detection, and 478 changes in preferences and policies. Furthermore, there may be less 479 reliable sources of information (such as lack of IPsec packets and 480 incoming ICMP packets) that do not trigger any changes directly, but 481 rather cause Dead Peer Detection (DPD) to be scheduled earlier and if 482 it fails it might cause a change of the preferred address. 484 These triggers are largely the same as for, e.g., Mobile IP, and are 485 beyond the scope of MOBIKE. 487 5.1.2. Connectivity 489 There can be two kinds of connectivity "failures": local failures and 490 path failures. Local failures are problems locally at an MOBIKE peer 491 (e.g., an interface error). Path failures are a property of an 492 address pair and failures of nodes and links along this path. MOBIKE 493 does not support unidirectional address pairs. Supporting them would 494 require abandoning the principle of sending an IKEv2 reply to the 495 address the request came from. MOBIKE decided to deal only with 496 bidirectional address pairs. It does consider unidirectional address 497 pairs as broken, and does not use them, but the connection between 498 peers will not break even if unidirectional address pairs are 499 present, provided there is at least one bidirectional address pair 500 MOBIKE can use. 502 Note that MOBIKE is not concerned about the actual path used, it 503 cannot even detect if some path is unidirectionally operational if 504 the same address pair has some other unidirectional path back. 505 Ingress filters might still cause such path pairs to be unusable, and 506 in that case MOBIKE will detect that there is no operational address 507 pair. 509 In a sense having both an IPv4 and an IPv6 address is basically a 510 case of partial connectivity (putting both an IPv4 and an IPv6 511 address in the same IP header does not work). The main difference is 512 that it is known beforehand, and there is no need to discover that 513 IPv4/IPv6 combination does not work. 515 5.1.3. Discovering Connectivity 517 To detect connectivity, the MOBIKE protocol needs to have a mechanism 518 to test connectivity. If a MOBIKE peer receives a reply it can be 519 sure about the existence of a working (bidirectional) address pair. 520 If a MOBIKE peer does not see a reply after multiple retransmissions 521 it may assume that the tested address pair is broken. 523 The connectivity tests require congestion problems to be taken into 524 account because the connection failure might be caused by a 525 congestion, and the MOBIKE protocol should not make the congestion 526 problem worse by sending many of DPD packets. 528 5.1.4. Decision Making 530 One of the main questions in designing the MOBIKE protocol was who 531 makes the decisions how to fix situation when failure is detected, 532 e.g., symmetry vs. asymmetry in decision making. Symmetric decision 533 making (i.e. both peers can make decisions) may cause the different 534 peers to make different decisions, thus causing asymmetric upstream/ 535 downstream traffic. In mobility case it is desirable that the mobile 536 peer can move both upstream and downstream traffic to some particular 537 interface, and this requires asymmetric decision making (i.e. only 538 one peer makes decisions). 540 Working with stateful packet filters and NATs is easier if the same 541 address pair is used in both upstream and downstream directions. 542 Also in common cases only the peer behind NAT can actually perform 543 actions to recover from the connectivity problems, as it might be 544 that the other peer is not able to initiate any connections to the 545 peer behind NAT. 547 5.1.5. Suggested Approach 549 The working group decided to select a method where the initiator will 550 decide which addresses are used. As a consequence the outcome is 551 always the same for both parties. It also works best with NATs, as 552 the initiator is most likely the node that is located behind a NAT. 554 5.2. NAT Traversal 555 5.2.1. Background and Constraints 557 Another core aspect of MOBIKE is the treatment of different NATs and 558 NAPTs. In IKEv2 the tunnel header IP addresses are not sent inside 559 the IKEv2 payloads, and thus there is no need to do unilateral self- 560 address fixing (UNSAF [RFC3424]). The tunnel header IP addresses are 561 taken from the outer IP header of the IKE packets, thus they are 562 already processed by the NAT. 564 The NAT detection payloads are used to determine whether the 565 addresses in the IP header were modified by a NAT along the path. 566 Detecting a NAT typically requires UDP encapsulation of IPsec ESP 567 packets to be enabled, if desired. MOBIKE is not to change how IKEv2 568 NAT-T works, in particular, any kind of UNSAF or explicit interaction 569 with NATs (e.g., MIDCOM [RFC3303] or NSIS NATFW NSLP [I-D.ietf-nsis- 570 nslp-natfw]) are beyond the scope of MOBIKE protocol. The MOBIKE 571 protocol will need to define how MOBIKE and NAT-T are used together. 573 The NAT-T support should also be optional, i.e., if the IKEv2 574 implementation does not implement NAT-T, as it is not required in 575 some particular environment, implementing MOBIKE should not require 576 adding support for NAT-T either. 578 The property of being behind NAT is actually a property of the 579 address pair and thereby by the path taken by a packet, thus one peer 580 can have multiple IP addresses and some of those might be behind NAT 581 and some might not. 583 5.2.2. Fundamental Restrictions 585 There are some cases which cannot be carried out within MOBIKE. One 586 of those cases is the case where the party "outside" a symmetric NAT 587 changes its address to something not known by the the other peer (and 588 old address has stopped working). It cannot send a packet containing 589 the new addresses to the peer because the NAT does not contain the 590 necessary state. Furthermore, since the party behind the NAT does 591 not know the new IP address, it cannot cause the NAT state to be 592 created. 594 This case could be solved using some rendezvous mechanism outside 595 IKEv2, but that is beyond the scope of MOBIKE. 597 5.2.3. Moving to behind a NAT and back 599 The MOBIKE protocol should provide a mechanism where a peer that is 600 initially not behind a NAT can move behind NAT, when a new preferred 601 address is selected. The same effect might be accomplished with the 602 change of the address pair if more than one path is available (e.g., 603 in case of a multi-homed host). An impact for the MOBIKE protocol is 604 only caused when the currently selected address pair causes MOBIKE 605 packets to traverse a NAT. 607 Similarly the MOBIKE protocol provides a mechanism to detect when a 608 NATed path is changed to a non-NATed path with the change of the 609 addressed pair. 611 As we only use one address pair at time, effectively the MOBIKE peer 612 is either behind NAT or not behind NAT, but each address change can 613 change this situation. Because of this and because the initiator 614 always chooses the addresses it is enough to send keepalive packets 615 only to that one address pair. 617 Enabling NAT-T involves a few different things, one is to enable the 618 UDP encapsulation of ESP packets. Another is to change the IKE SA 619 ports from port 500 to port 4500. We do not want to do unnecessary 620 UDP encapsulation unless there is really a NAT between peers, i.e. 621 UDP encapsulation should only be enabled when we actually detect NAT. 622 On the other hand, as all implementations supporting NAT-T must be 623 able to respond to port 4500 all the time, it is simpler from the 624 protocol point of view to change the port numbers from 500 to 4500 625 immediately upon detecting that the other end supports NAT-T. This 626 way it is not necessary to change ports after we later detected NAT, 627 which would have caused complications to the protocol. 629 If we would do the actual changing of the port only after we detect 630 NAT, then the responder would not be able to use the IKE and IPsec 631 SAs immediately after their address is changed to be behind NAT. 632 Instead it would need to wait for the next packet from the initiator 633 to see what IP and port numbers are used after the initiator changed 634 its port from 500 to 4500. The responder would also not be able to 635 send anything to the initiator before the initiator has sent 636 something to the responder. If we do the port number changing 637 immediately after the IKE_SA_INIT and before IKE_AUTH phase, then we 638 get the rid of this problem. 640 5.2.4. Responder behind a NAT 642 MOBIKE can work in cases where the responder is behind static NAT, 643 but in that case the initiator needs to know all the possible 644 addresses where the responder can move to, i.e. the responder cannot 645 move to an address which is not known by the initiator, in case 646 initiator also moves behind NAT. 648 If the responder is behind NAPT then it might need to communicate 649 with the NAT to create a mapping so the initiator can connect to it. 650 Those external firewall pinhole opening mechanisms are beyond the 651 scope of MOBIKE. 653 In case the responder is behind NAPT, then also finding the port 654 numbers used by the responder is outside the scope of MOBIKE. 656 5.2.5. NAT Prevention 658 One new feature created by MOBIKE is NAT prevention, i.e. if we 659 detect NAT between the peers, we do not allow that address pair to be 660 used. This can be used to protect IP addresses in cases where it is 661 known by the configuration that there is no NAT between the nodes 662 (for example IPv6, or fixed site-to-site VPN). This avoids any 663 possibility of on-path attackers modifying addresses in headers. 664 This feature means that we authenticate the IP-address and detect if 665 they were changed. As this is done on purpose to break the 666 connectivity if NAT is detected, and decided by the configuration, 667 there is no need to do UNSAF processing. 669 5.2.6. Suggested Approach 671 The working group decided that MOBIKE uses NAT-T mechanisms from the 672 IKEv2 protocol as much as possible, but decided to change the dynamic 673 address update (see [RFC4306] section 2.23 second last paragraph) for 674 IKEv2 packets to MUST NOT (it would break path testing using IKEv2 675 packets, see Section 6.2). The working group also decided to only 676 send keepalives to the current address pair. 678 5.3. Scope of SA Changes 680 Most sections of this document discuss design considerations for 681 updating and maintaining addresses in the database entries that 682 relate to an IKE SA. However, changing the preferred address also 683 affects the entries of the IPsec SA database. The outer tunnel 684 header addresses (source and destination IP addresses) need to be 685 modified according to the current path to allow the IPsec protected 686 data traffic to travel along the same path as the MOBIKE packets. If 687 the MOBIKE messages and the IPsec protected data traffic travel along 688 a different path then NAT handling is severely complicated. 690 The basic question is then how the IPsec SAs are changed to use the 691 new address pair (the same address pair as the MOBIKE signaling 692 traffic). One option is that when the IKE SA address is changed, 693 then all IPsec SAs associated with it are automatically moved along 694 with it to a new address pair. Another option is to have a separate 695 exchange to move the IPsec SAs separately. 697 If IPsec SAs should be updated separately then a more efficient 698 format than the Notify payload is needed to preserve bandwidth. A 699 Notify payload can only store one SPI per payload. A separate 700 payload could have a list of IPsec SA SPIs and the new preferred 701 address. If there is a large number of IPsec SAs, those payloads can 702 be quite large unless list of ranges of SPI values are supported. If 703 we automatically move all IPsec SAs when the IKE SA moves, then we 704 only need to keep track of which IKE SA was used to create the IPsec 705 SA, and fetch the IP addresses from the IKE SA, i.e. there is no need 706 to store IP addresses per IPsec SA. Note that IKEv2 [RFC4306] 707 already requires the implementations to keep track which IPsec SAs 708 are created using which IKE SA. 710 If we do allow address set of each IPsec SA to be updated separately, 711 then we can support scenarios where the machine has fast and/or cheap 712 connections and slow and/or expensive connections, and wants to allow 713 moving some of the SAs to the slower and/or more expensive 714 connection, and prevent the move, for example, of the news video 715 stream from the WLAN to the GPRS link. 717 On the other hand, even if we tie the IKE SA update to the IPsec SA 718 update, then we can create separate IKE SAs for this scenario, e.g., 719 we create one IKE SA which has both links as endpoints, and it is 720 used for important traffic, and then we create another IKE SA which 721 has only the fast and/or cheap connection, which is then used for 722 that kind of bulk traffic. 724 The working group decided to move all IPsec SAs implicitly when the 725 IKE SA address pair changes. If more granular handling of the IPsec 726 SA is required, then multiple IKE SAs can be created one for each set 727 of IPsec SAs needed. 729 5.4. Zero Address Set Functionality 731 One of the features which is potentially useful is for the peer to 732 announce that it will now disconnect for some time, i.e. it will not 733 be reachable at all. For instance, a laptop might go to suspend 734 mode. In this case it could send address notification with zero new 735 addresses, which would mean that it will not have any valid addresses 736 anymore. The responder of that kind of notification would then 737 acknowledge that, and could then temporarily disable all SAs and 738 therefore stop sending traffic. If any of the SAs gets any packets 739 they are simply dropped. This could also include some kind of ACK 740 spoofing to keep the TCP/IP sessions alive (or simply setting the 741 TCP/IP keepalives and timeouts large enough not to cause problems), 742 or it could simply be left to the applications, e.g. allow TCP/IP 743 sessions to notice if the link is broken. 745 The local policy could then indicate how long the peer should allow 746 remote peers to remain disconnected. 748 From a technical point of view this would provide following two 749 features: 751 o There is no need to transmit IPsec data traffic. IPsec protected 752 data can be dropped which saves bandwidth. This does not provide 753 a functional benefit, i.e., nothing breaks if this feature is not 754 provided. 756 o MOBIKE signaling messages are also ignored. The IKE-SA must not 757 be deleted and the suspend functionality (realized with the zero 758 address set) may require the IKE-SA to be tagged with a lifetime 759 value since the IKE-SA should not be kept alive for an undefined 760 period of time. Note that IKEv2 does not require that the IKE-SA 761 has a lifetime associated with it. In order to prevent the IKE-SA 762 from being deleted the dead-peer detection mechanism needs to be 763 suspended as well. 765 Due to its complexity and no clear requirement for it, it was decided 766 that MOBIKE does not support this feature. 768 5.5. Return Routability Check 770 Changing the preferred address and subsequently using it for 771 communication is associated with an authorization decision: Is a peer 772 allowed to use this address? Does this peer own this address? Two 773 mechanisms have been proposed in the past to allow a peer to 774 determine the answer to these questions: 776 o The addresses a peer is using are part of a certificate. 777 [RFC3554] introduced this approach. If the other peer is, for 778 example, a security gateway with a limited set of fixed IP 779 addresses, then the security gateway may have a certificate with 780 all the IP addresses appearing in the certificate. 782 o A return routability check is performed by the remote peer before 783 the address is updated in that peer's Security Association 784 Database. This is done in order provide a certain degree of 785 confidence to the remote peer that local peer is reachable at the 786 indicated address. 788 Without taking an authorization decision a malicious peer can 789 redirect traffic towards a third party or a blackhole. 791 A MOBIKE peer should not use an IP addressed provided by another 792 MOBIKE peer as a current address without computing the authorization 793 decision. If the addresses are part of the certificate then it is 794 not necessary to execute the return routability check. The return 795 routability check is a form of authorization check, although it 796 provides weaker guarantees than the inclusion of the IP address as a 797 part of a certificate. If multiple addresses are communicated to the 798 remote peer then some of these addresses may be already verified. 800 Finally it would be possible not to execute return routability checks 801 at all. In case of indirect change notifications (i.e. something we 802 notice from the network, not from the peer directly) we only move to 803 the new preferred address after successful dead-peer detection (i.e., 804 a response to a DPD test) on the new address, which is already a 805 return routability check. With a direct notification (i.e. 806 notification from the other end directly) the authenticated peer may 807 have provided an authenticated IP address (i.e. inside IKE encrypted 808 and authenticated payload, see Section 5.2.5). Thus it is would be 809 possible to simply trust the MOBIKE peer to provide a proper IP 810 address. In this case A protection against an internal attacker, 811 i.e. the authenticated peer forwarding its traffic to the new 812 address, would not provided. On the other hand we know the identity 813 of the peer in that case. There might be problems when extensions 814 are added to IKEv2 that do not require authentication of end points 815 (e.g., opportunistic security using anonymous Diffie-Hellman). 817 There is also a policy issue of when to schedule a return routability 818 check. Before moving traffic? After moving traffic? 820 The basic format of the return routability check could be similar to 821 dead-peer detection, but potential attacks are possible if a return 822 routability check does not include some kind of a nonce. In these 823 attacks the valid end point could send an address update notification 824 for a third party, trying to get all the traffic to be sent there, 825 causing a denial of service attack. If the return routability check 826 does not contain any nonce or other random information not known to 827 the other peer, then other peer could reply to the return routability 828 checks even when it cannot see the request. This might cause a peer 829 to move the traffic to a location where the original recipient cannot 830 be reached. 832 The IKEv2 NAT-T mechanism does not perform return routability checks. 833 It simply uses the last seen source IP address used by the other peer 834 as the destination address to send response packets. An adversary 835 can change those IP addresses, and can cause the response packets to 836 be sent to a wrong IP address. The situation is self-fixing when the 837 adversary is no longer able to modify packets and the first packet 838 with an unmodified IP address reaches the other peer. Mobility 839 environments make this attack more difficult for an adversary since 840 the attack requires the adversary to be located somewhere on the 841 individual paths ({CoA1, ..., CoAn} towards the destination IP 842 address), have a shared path or, if the adversary is located near the 843 MOBIKE client then it needs to follow the user mobility patterns. 845 With IKEv2 NAT-T, the genuine client can cause third party bombing by 846 redirecting all the traffic pointed to him to a third party. As the 847 MOBIKE protocol tries to provide equal or better security than IKEv2 848 NAT-T mechanism it should protect against these attacks. 850 There may be return routability information available from the other 851 parts of the system too (as shown in Figure 3), but the checks done 852 may have a different quality. There are multiple levels for return 853 routability checks: 855 o None, no tests 857 o A party willing to answer the return routability check is located 858 along the path to the claimed address. This is the basic form of 859 return routability check. 861 o There is an answer from the tested address, and that answer was 862 authenticated, integrity and replay protected. 864 o There was an authenticated, integrity and replay protected answer 865 from the peer, but it is not guaranteed to originate at the tested 866 address or path to it (because the peer can construct a response 867 without seeing the request). 869 The return routability checks do not protect against 3rd party 870 bombing if the attacker is along the path, as the attacker can 871 forward the return routability checks to the real peer (even if those 872 packets are cryptographically authenticated). 874 If the address to be tested is carried inside the MOBIKE payload, 875 then the adversary cannot forward packets. Thus 3rd party bombings 876 are prevented (see Section 5.2.5). 878 If the reply packet can be constructed without seeing the request 879 packet (for example, if there is no nonce, challenge or similar 880 mechanism to show liveness), then the genuine peer can cause 3rd 881 party bombing, by replying to those requests without seeing them at 882 all. 884 Other levels might only provide a guarantee that there is a node at 885 the IP address which replied to the request. There is no indication 886 as to whether or not the reply is fresh, and whether or not the 887 request may have been transmitted from a different source address. 889 5.5.1. Employing MOBIKE Results in other Protocols 891 If MOBIKE has learned about new locations or verified the validity of 892 a remote address through a return routability check, can this 893 information be useful for other protocols? 895 When considering the basic MOBIKE VPN scenario, the answer is no. 896 Transport and application layer protocols running inside the VPN 897 tunnel are unaware of the outer addresses or their status. 899 Similarly, IP layer tunnel termination at a gateway rather than a 900 host endpoint limits the benefits for "other protocols" that could be 901 informed -- all application protocols at the other side are unaware 902 of IPsec, IKE, or MOBIKE. 904 However, it is conceivable that future uses or extensions of the 905 MOBIKE protocol make such information distribution useful. For 906 instance, if transport mode MOBIKE and SCTP were made to work 907 together, it would potentially be useful for SCTP dynamic address 908 reconfiguration [I-D.ietf-tsvwg-addip-sctp] to learn about the new 909 addresses at the same time as MOBIKE. Similarly, various IP layer 910 mechanisms may make use of the fact that a return routability check 911 of a specific type has been performed. However, care should be 912 exercised in all these situations. 914 [I-D.crocker-celp] discusses the use of common locator information 915 pools in a IPv6 multi-homing context; it assumed that both transport 916 and IP layer solutions are used in order to support multi-homing, and 917 that it would be beneficial for different protocols to coordinate 918 their results in some way, for instance by sharing throughput 919 information of address pairs. This may apply to MOBIKE as well, 920 assuming it co-exists with non-IPsec protocols that are faced with 921 the same or similar multi-homing choices. 923 Nevertheless, all of this is outside the scope of current MOBIKE base 924 protocol design and may be addressed in future work. 926 5.5.2. Return Routability Failures 928 If the return routability check fails, we need to tear down the IKE 929 SA if we are using IKEv2 INFORMATIONAL exchanges to send return 930 routability checks. On the other hand return routability check can 931 only fail permanently if there was an attack by the other end, thus 932 tearing down the IKE SA is a suitable action in that case. 934 There are some cases where the return routability check temporarily 935 fails that need to be considered here. In the first case there is no 936 attacker, but the selected address pair stops working immediately 937 after the address update, before the return routability check. 939 What happens there is that the initiator performs the normal address 940 update, and that succeeds, and then the responder starts a return 941 routability check. If the address pair has broken down before that, 942 the responder will never get back the reply to the return routability 943 check. The responder might still be using the old IP address pair, 944 which could still work. 946 The initiator might be still seeing traffic from the responder, but 947 using the old address pair. The initiator should detect that this 948 traffic is not using the latest address pair, and after a while it 949 should start dead peer detection on the current address pair. If 950 that fails, then it should find a new working address pair, and 951 update addresses to that. The responder should notice that the 952 address pair was updated after the return routability check was 953 started, and change the ongoing return routability check to use the 954 new address pair. The result of that return routability check needs 955 to be discarded as it cannot be trusted as the packets were 956 retransmitted to a different IP address. So normally the responder 957 starts a new return routability check after that with the new address 958 pair. 960 The second case is where there is an attacker along the path 961 modifying the IP addresses. The peers will detect this as NAT and 962 will enable NAT-T recovery of changes in the NAT mappings. If the 963 attacker is along the path long enough for the return routability 964 check to succeed, then the normal recovery of changes in the NAT 965 mappings will take care of the problem. If the attacker disappears 966 before return routability check is finished, but after the update we 967 have almost a similar case than last time. Now the only difference 968 is now that the dead peer detection started by the initiator will 969 succeed, as the responder will reply to the addresses in the headers, 970 not the current address pair. The initiator will then detect that 971 the NAT mappings are changed, and it will fix the situation by doing 972 an address update. 974 The important thing for both of these cases is that the initiator 975 needs to see that the responder is both alive and synchronized with 976 initiator address pair updates. I.e. it is not enough that the 977 responder is sending traffic to an initiator, it must be also using 978 the correct IP addresses before the initiator can believe it is alive 979 and synchronized. From the implementation point of view this means 980 that the initiator must not consider packets having wrong IP 981 addresses as packets that prove the other end being alive, i.e. they 982 do not reset the dead peer detection timers. 984 5.5.3. Suggested Approach 986 The working group selected to use IKEv2 INFORMATIONAL exchanges as a 987 return routability check, but included a random cookie to prevent 988 redirection by an authenticated attacker. Return routability checks 989 are performed by default before moving the traffic. However these 990 tests are optional. Nodes MAY also perform these tests upon their 991 own initiative at other times. 993 It is worth noting that the return routability check in MOBIKE is 994 different from Mobile IPv6 [RFC3775], which does not perform return 995 routability operations between the mobile node and its home agent at 996 all. 998 5.6. IPsec Tunnel or Transport Mode 1000 Current MOBIKE design is focused only on the VPN type usage and 1001 tunnel mode. Transport mode behavior would also be useful, but will 1002 be discussed in future documents. 1004 6. Protocol Details 1006 6.1. Indicating Support for MOBIKE 1008 In order for MOBIKE to function, both peers must implement the MOBIKE 1009 extension of IKEv2. If one of the peers does not support MOBIKE, 1010 then, whenever an IP address changes, IKEv2 will have to be re-run in 1011 order to create a new IKE SA and the respective IPsec SAs. In 1012 MOBIKE, a peer needs to be confident that its address change messages 1013 are understood by the other peer. If these messages are not 1014 understood, it is possible that connectivity between the peers is 1015 lost. 1017 One way to ensure that a peer receives feedback on whether its 1018 messages are understood by the other peer, is by using IKEv2 1019 messaging for MOBIKE and to mark some messages as "critical". 1020 According to the IKEv2 specification, such messages either have to be 1021 understood by the receiver, or an error message has to be returned to 1022 the sender. 1024 A second way to ensure receipt of the above-mentioned feedback is by 1025 using Vendor ID payloads that are exchanged during the initial IKEv2 1026 exchange. These payloads would then indicate whether or not a given 1027 peer supports the MOBIKE protocol. 1029 A third approach would use the Notify payload to indicate support of 1030 MOBIKE extension, such Notify payloads are also used for indicating 1031 NAT traversal support (via NAT_DETECTION_SOURCE_IP and 1032 NAT_DETECTION_DESTINATION_IP payloads). 1034 Both a Vendor ID and a Notify payload may be used to indicate the 1035 support of certain extensions. 1037 Note that a MOBIKE peer could also attempt to execute MOBIKE 1038 opportunistically with the critical bit set when an address change 1039 has occurred. The drawback of this approach is, however, that an 1040 unnecessary message exchange is introduced. 1042 Although Vendor ID payloads and Notify payloads are technically 1043 equivalent, Notify payloads are already used in IKEv2 as a capability 1044 negotiation mechanism. Hence, Notify payloads are used in MOBIKE to 1045 indicate support of MOBIKE protocol. 1047 Also, as the information of the support of MOBIKE is not needed 1048 during the IKE_SA_INIT exchange, the indication of the support is 1049 done inside the IKE_AUTH exchange. The reason for this is the need 1050 to keep the IKE_SA_INIT messages as small as possible so that they do 1051 not get fragmented. IKEv2 allows that the responder can do stateless 1052 processing of the first IKE_SA_INIT packet, and request a cookie from 1053 the other end if it is under attack. To mandate the responder to be 1054 able to reassemble initial IKE_SA_INIT packets would not allow fully 1055 stateless processing of the initial IKE_SA_INIT packets. 1057 6.2. Path Testing and Window size 1059 As IKEv2 has a window of outgoing messages, and the sender is not 1060 allowed to violate that window (meaning, that if the window is full, 1061 then the sender cannot send packets), it can cause some complications 1062 to path testing. Another complication created by IKEv2 is that once 1063 the message is created and sent to the other end, it cannot be 1064 modified in its future retransmissions. This makes it impossible to 1065 know what packet actually reached the other end first. We cannot use 1066 IP headers to find out which packet reached the other end first, as 1067 if the responder gets retransmissions of the packet it has already 1068 processed and replied to (and those replies might have been lost due 1069 unidirectional address pair), it will retransmit the previous reply 1070 using the new address pair of the request. Because of this it might 1071 be possible that the responder has already used the IP address 1072 information from the header of the previous packet, and the reply 1073 packet ending up to the initiator has a different address pair. 1075 Another complication comes from NAT-T. The current IKEv2 document 1076 says that if NAT-T is enabled the node not behind NAT SHOULD detect 1077 if the IP-address changes in the incoming authenticated packets, and 1078 update the remote peers' addresses accordingly. This works fine with 1079 NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs 1080 the ability to probe another address pairs without breaking the old 1081 one. 1083 One approach to fix this would be to add a completely new protocol 1084 that is outside the IKE SA message id limitations (window code), 1085 outside identical retransmission requirements, and outside the 1086 dynamic address updating of NAT-T. 1088 Another approach is to make the protocol so that it does not violate 1089 window restrictions and does not require changing the packet on 1090 retransmissions, and change the dynamic address updating of NAT-T to 1091 MUST NOT for IKE SA packets if MOBIKE is used. In order to not 1092 violate window restrictions, the addresses of the currently ongoing 1093 exchange need to be changed to test different paths. In order to not 1094 require changing the packet after it is first sent requires that the 1095 protocol needs to restart from the beginning in case the packet was 1096 retransmitted to different addresses (because the sender does not 1097 know which packet was the one that responder got first, i.e. which 1098 IP-addresses it used). 1100 Working group decided to use normal IKEv2 exchanges for path testing, 1101 and decided to change the dynamic address updating of NAT-T to MUST 1102 NOT for IKE SA packets. I.e. a new protocol outside of IKEv2 was not 1103 adopted. 1105 6.3. Message presentation 1107 The IP address change notifications can be sent either via an 1108 informational exchange already specified in IKEv2, or via a MOBIKE- 1109 specific message exchange. Using an informational exchange has the 1110 main advantage that it is already specified in the IKEv2 protocol and 1111 implementations can already incorporate the functionality. 1113 Another question is the format of the address update notifications. 1114 The address update notifications can include multiple addresses, of 1115 which some may be IPv4 and some IPv6 addresses. The number of 1116 addresses is most likely going to be limited in typical environments 1117 (with less than 10 addresses). The format may need to indicate a 1118 preference value for each address. The format could either contain a 1119 preference number that determines the relative order of the 1120 addresses, or it could simply be an ordered list of IP addresses. If 1121 using preference numbers, then two addresses can have the same 1122 preference value, an ordered list avoids this situation. 1124 Load balancing is currently outside the scope of MOBIKE, however 1125 future work might include support for it. The selected format needs 1126 to be flexible enough to include additional information in future 1127 versions of the protocol (e.g. to enable load balancing). This may 1128 be realized with an reserved field, which can later be used to store 1129 additional information. As there may arise other information which 1130 may have to be tied to an address in the future, a reserved field 1131 seems like a prudent design in any case. 1133 There are two basic formats that place IP address lists into a 1134 message. One includes each IP address as separate payload (where the 1135 payload order indicates the preference order, or the payload itself 1136 might include the preference number), or we can put the IP address 1137 list as one payload to the exchange, and that one payload will then 1138 have an internal format which includes the list of IP addresses. 1140 Having multiple payloads with each one carrying one IP address makes 1141 the protocol probably easier to parse, as we can already use the 1142 normal IKEv2 payload parsing procedures. It also offers an easy way 1143 for the extensions, as the payload probably contains only the type of 1144 the IP address (or the type is encoded to the payload type), and the 1145 IP address itself, and as each payload already has a length field 1146 associated to it, we can detect if there is any extra data after the 1147 IP address. Some implementations might have problems parsing more 1148 than certain number of IKEv2 payloads, but if the sender sends them 1149 in the most preferred first, the receiver can only use the first 1150 addresses, it was willing to parse. 1152 Having all IP addresses in one big MOBIKE specified internal format 1153 provides more compact encoding, and keeps the MOBIKE implementation 1154 more concentrated to one module. 1156 Another choice is which type of payloads to use. IKEv2 already 1157 specifies a Notify payload. It includes some extra fields (SPI size, 1158 SPI, protocol etc), which gives 4 bytes of the extra overhead, and 1159 there is the notification data field, which could include the MOBIKE 1160 specific data. 1162 Another option would be to have a custom payload type, which then 1163 includes the information needed for the MOBIKE protocol. 1165 Working group decided to use IKEv2 Notify payloads, and put only one 1166 data item per notify, i.e. there will be one Notify payload for each 1167 item to be sent. 1169 6.4. Updating address set 1171 Because of the initiator decides all address updates, the initiator 1172 needs to know all the addresses used by the responder. The responder 1173 also needs that list in case it happens to move to an address not 1174 known by the initiator, and needs to send an address update 1175 notification to the initiator, and it might need to try different 1176 addresses for the initiator. 1178 MOBIKE could send the whole peer address list every time any of the 1179 IP addresses change (either addresses are added, removed, the order 1180 changes or the preferred address is updated) or an incremental 1181 update. Sending incremental updates provides more compact packets 1182 (meaning we can support more IP addresses), but on the other hand 1183 this approach has more problems in the synchronization and packet 1184 reordering cases, i.e., incremental updates must be processed in 1185 order, but for full updates we can simply use the most recent one, 1186 and ignore old ones, even if they arrive after the most recent one 1187 (IKEv2 packets have a message id which is incremented for each 1188 packet, thus it is easy to know the sending order). 1190 Working group decided to use a protocol format where both ends send a 1191 full list of their addresses to the other end, and that list 1192 overwrites the previous list. To support NAT-T the IP-addresses of 1193 the received packet are considered as one address of the peer, even 1194 when not present in the list. 1196 7. Security Considerations 1198 As all the packets are already authenticated by IKEv2 there is no 1199 risk that any attackers would modify the contents of the packets. 1200 The IP addresses in the IP header of the packets are not 1201 authenticated, thus the protocol defined must take care that they are 1202 only used as an indication that something might be different, and 1203 that do not cause any direct actions, except when doing NAT 1204 Traversal. 1206 An attacker can also spoof ICMP error messages in an effort to 1207 confuse the peers about which addresses are not working. At worst 1208 this causes denial of service and/or the use of non-preferred 1209 addresses. 1211 One type of attack that needs to be taken care of in the MOBIKE 1212 protocol is the bombing attack type. See [RFC4225] and [Aur02] for 1213 more information about flooding attacks. 1215 See Security considerations section of [I-D.ietf-mobike-protocol] for 1216 more information about security considerations of the actual 1217 protocol. 1219 8. IANA Considerations 1221 This document does not introduce any IANA considerations. 1223 9. Acknowledgments 1225 This document is the result of discussions in the MOBIKE working 1226 group. The authors would like to thank Jari Arkko, Pasi Eronen, 1227 Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, 1228 James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, 1229 Udo Schilcher, Tom Henderson, Andreas Pashalidis and Maureen Stillman 1230 for their input. 1232 We would like to particularly thank Pasi Eronen for tracking open 1233 issues on the MOBIKE mailing list. He helped us to make good 1234 progress on the document. 1236 10. References 1238 10.1. Normative references 1240 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1241 RFC 4306, December 2005. 1243 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1244 Internet Protocol", RFC 4301, December 2005. 1246 10.2. Informative References 1248 [I-D.ietf-mobike-protocol] 1249 Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1250 (MOBIKE)", draft-ietf-mobike-protocol-08 (work in 1251 progress), February 2006. 1253 [I-D.ietf-shim6-failure-detection] 1254 Arkko, J. and I. Beijnum, "Failure Detection and Locator 1255 Pair Exploration Protocol for IPv6 Multihoming", 1256 draft-ietf-shim6-failure-detection-03 (work in progress), 1257 December 2005. 1259 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1260 (IKE)", RFC 2409, November 1998. 1262 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1263 Internet Protocol", RFC 2401, November 1998. 1265 [RFC4225] Nikander, P., Arkko, J., Aura, T., Montenegro, G., and E. 1266 Nordmark, "Mobile IP Version 6 Route Optimization Security 1267 Design Background", RFC 4225, December 2005. 1269 [I-D.ietf-hip-mm] 1270 Nikander, P., "End-Host Mobility and Multihoming with the 1271 Host Identity Protocol", draft-ietf-hip-mm-03 (work in 1272 progress), March 2006. 1274 [I-D.crocker-celp] 1275 Crocker, D., "Framework for Common Endpoint Locator 1276 Pools", draft-crocker-celp-00 (work in progress), 1277 February 2004. 1279 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1280 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1281 Zhang, L., and V. Paxson, "Stream Control Transmission 1282 Protocol", RFC 2960, October 2000. 1284 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1285 RFC 3753, June 2004. 1287 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1288 in IPv6", RFC 3775, June 2004. 1290 [I-D.ietf-tsvwg-addip-sctp] 1291 Stewart, R., "Stream Control Transmission Protocol (SCTP) 1292 Dynamic Address Reconfiguration", 1293 draft-ietf-tsvwg-addip-sctp-13 (work in progress), 1294 November 2005. 1296 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 1297 Stewart, "On the Use of Stream Control Transmission 1298 Protocol (SCTP) with IPsec", RFC 3554, July 2003. 1300 [I-D.ietf-ipv6-optimistic-dad] 1301 Moore, N., "Optimistic Duplicate Address Detection for 1302 IPv6", draft-ietf-ipv6-optimistic-dad-07 (work in 1303 progress), December 2005. 1305 [I-D.ietf-ipv6-unique-local-addr] 1306 Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1307 Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in 1308 progress), January 2005. 1310 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1311 E. Lear, "Address Allocation for Private Internets", 1312 BCP 5, RFC 1918, February 1996. 1314 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1315 Management API, Version 2", RFC 2367, July 1998. 1317 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1318 Autoconfiguration", RFC 2462, December 1998. 1320 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1321 Discovery for IP Version 6 (IPv6)", RFC 2461, 1322 December 1998. 1324 [RFC3424] Daigle, L. and IAB, "IAB Considerations for UNilateral 1325 Self-Address Fixing (UNSAF) Across Network Address 1326 Translation", RFC 3424, November 2002. 1328 [RFC3303] Srisuresh, P., Kuthan, J., Rosenberg, J., Molitor, A., and 1329 A. Rayhan, "Middlebox communication architecture and 1330 framework", RFC 3303, August 2002. 1332 [I-D.ietf-nsis-nslp-natfw] 1333 Stiemerling, M., "NAT/Firewall NSIS Signaling Layer 1334 Protocol (NSLP)", draft-ietf-nsis-nslp-natfw-09 (work in 1335 progress), February 2006. 1337 [Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1338 Location Management", In Proc. 18th Annual Computer 1339 Security Applications Conference, pages 78-87, Las Vegas, 1340 NV USA, December 2002. 1342 Authors' Addresses 1344 Tero Kivinen 1345 Safenet, Inc. 1346 Fredrikinkatu 47 1347 HELSINKI FI-00100 1348 FI 1350 Email: kivinen@safenet-inc.com 1352 Hannes Tschofenig 1353 Siemens 1354 Otto-Hahn-Ring 6 1355 Munich, Bavaria 81739 1356 Germany 1358 Email: Hannes.Tschofenig@siemens.com 1359 URI: http://www.tschofenig.com 1361 Intellectual Property Statement 1363 The IETF takes no position regarding the validity or scope of any 1364 Intellectual Property Rights or other rights that might be claimed to 1365 pertain to the implementation or use of the technology described in 1366 this document or the extent to which any license under such rights 1367 might or might not be available; nor does it represent that it has 1368 made any independent effort to identify any such rights. Information 1369 on the procedures with respect to rights in RFC documents can be 1370 found in BCP 78 and BCP 79. 1372 Copies of IPR disclosures made to the IETF Secretariat and any 1373 assurances of licenses to be made available, or the result of an 1374 attempt made to obtain a general license or permission for the use of 1375 such proprietary rights by implementers or users of this 1376 specification can be obtained from the IETF on-line IPR repository at 1377 http://www.ietf.org/ipr. 1379 The IETF invites any interested party to bring to its attention any 1380 copyrights, patents or patent applications, or other proprietary 1381 rights that may cover technology that may be required to implement 1382 this standard. Please address the information to the IETF at 1383 ietf-ipr@ietf.org. 1385 Disclaimer of Validity 1387 This document and the information contained herein are provided on an 1388 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1389 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1390 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1391 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1392 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1393 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1395 Copyright Statement 1397 Copyright (C) The Internet Society (2006). This document is subject 1398 to the rights, licenses and restrictions contained in BCP 78, and 1399 except as set forth therein, the authors retain all their rights. 1401 Acknowledgment 1403 Funding for the RFC Editor function is currently provided by the 1404 Internet Society.