idnits 2.17.1 draft-ietf-mobike-design-05.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 1409. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1386. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1393. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1399. ** 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 688: '...IKEv2 packets to MUST NOT (it would br...' RFC 2119 keyword, line 1007: '...optional. Nodes MAY also perform thes...' RFC 2119 keyword, line 1093: '... the node not behind NAT SHOULD detect...' RFC 2119 keyword, line 1108: '... MUST NOT for IKE SA packets if MOBI...' RFC 2119 keyword, line 1118: '...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 (November 30, 2005) is 6722 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.dupont-ikev2-addrmgmt' is defined on line 1315, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-unique-local-addr' is defined on line 1329, but no explicit reference was found in the text -- 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-dupont-mipv6-3bombing-02 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-02 -- Obsolete informational reference (is this intentional?): RFC 3489 (Obsoleted by RFC 5389) -- Obsolete informational reference (is this intentional?): RFC 2960 (Obsoleted by RFC 4960) == Outdated reference: A later version (-22) exists of draft-ietf-tsvwg-addip-sctp-13 == Outdated reference: A later version (-07) exists of draft-ietf-ipv6-optimistic-dad-06 -- 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 (-08) exists of draft-ietf-mobike-protocol-06 Summary: 4 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: June 3, 2006 Siemens 6 November 30, 2005 8 Design of the MOBIKE Protocol 9 draft-ietf-mobike-design-05.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 June 3, 2006. 36 Copyright Notice 38 Copyright (C) The Internet Society (2005). 40 Abstract 42 The MOBIKE (IKEv2 Mobility and Multihoming) working group is 43 developing extensions for the Internet Key Exchange Protocol version 44 2 (IKEv2). These extensions should enable an efficient management of 45 IKE and IPsec Security Associations when a host possesses multiple IP 46 addresses and/or where IP addresses of an IPsec host change over time 47 (for example, due to 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 . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . 23 82 5.5.2. Return Routability Failures . . . . . . . . . . . . . 23 83 5.5.3. Suggested Approach . . . . . . . . . . . . . . . . . . 25 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 list . . . . . . . . . . . . . . . . . . 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 documents make no 116 provision to change this pair after an IKE SA is created. 118 There are scenarios where one or both of the IP addresses of this 119 pair may change during an IPsec session. In principle, the IKE SA 120 and all corresponding IPsec SAs could be re-established after the IP 121 address has changed. However, this can be problematic, as the device 122 might be too slow for this task. Moreover, manual user interaction 123 (for example when using SecurID cards) might be required as part of 124 the IKEv2 authentication procedure. Therefore, an automatic 125 mechanism is needed that updates the IP addresses associated with the 126 IKE SA and the IPsec SAs. The MOBIKE protocol provides such a 127 mechanism. 129 The work of the MOBIKE working group and therefore this document is 130 based on the assumption that the mobility and multi-homing extensions 131 are developed for IKEv2 [I-D.ietf-ipsec-ikev2]. As IKEv2 is built on 132 the architecture described in RFC2401bis [I-D.ietf-ipsec-rfc2401bis], 133 all protocols developed within the MOBIKE working group must be 134 compatible with both IKEv2 and the architecture described in 135 RFC2401bis. This document neither discusses mobility and multi- 136 homing support for IKEv1 [RFC2409] nor the IPsec architecture 137 described in RFC2401 [RFC2401]. 139 This document is structured as follows: After introducing some 140 important terms in Section 2, a number of relevant usage scenarios 141 are discussed in Section 3. Section 4 describes the scope of the 142 MOBIKE protocol. Section 5 discusses design considerations affecting 143 the MOBIKE protocol. Section 6 investigates details regarding the 144 MOBIKE protocol. Finally, this document concludes in Section 7 with 145 security considerations. 147 2. Terminology 149 This section introduces the terminology that is used in this 150 document. 152 Peer: 154 A peer is an IKEv2 endpoint. In addition, a peer implements the 155 MOBIKE extensions, defined in [I-D.ietf-mobike-protocol]. 157 Available address: 159 An address is said to be available if the following conditions are 160 met: 162 * The address has been assigned to an interface. 164 * If the address is an IPv6 address, we additionally require (a) 165 that the address is valid as defined in RFC 2461 [RFC2461], and 166 (b) that the address is not tentative as defined in RFC 2462 167 [RFC2462]. In other words, we require the address assignment 168 to be complete. 170 Note that this explicitly allows an address to be optimistic as 171 defined in [I-D.ietf-ipv6-optimistic-dad]. 173 * If the address is an IPv6 address, it is a global unicast or 174 unique site-local address, as defined in [I-D.ietf-ipv6-unique- 175 local-addr]. That is, it is not an IPv6 link-local. 177 * The address and interface is acceptable for sending and 178 receiving traffic according to a local policy. 180 This definition is taken from [I-D.arkko-multi6dt-failure- 181 detection], and adapted to the MOBIKE context (we do allow 182 [RFC1918] addresses here, they are very common addresses used 183 inside NATs). 185 Locally Operational Address: 187 An address is said to be locally operational if it is available 188 and its use is locally known to be possible and permitted. This 189 definition is taken from [I-D.arkko-multi6dt-failure-detection]. 191 Operational address pair: 193 A pair of operational addresses are said to be an operational 194 address pair, if and only if bidirectional connectivity can be 195 shown between the two addresses. Note that sometimes it is 196 necessary to consider connectivity on a per-flow level between two 197 endpoints. This differentiation might be necessary to address 198 certain Network Address Translation types or specific firewalls. 199 This definition is taken from [I-D.arkko-multi6dt-failure- 200 detection] and adapted for the MOBIKE context. Although it is 201 possible to further differentiate unidirectional and bidirectional 202 operational address pairs, only bidirectional connectivity is 203 relevant to this document and unidirectional connectivity is out 204 of scope. 206 Path: 208 The sequence of routers traversed by the MOBIKE and IPsec packets 209 exchanged between the two peers. Note that this path may be 210 affected not only by the involved source and destination IP 211 addresses, but also by the transport protocol. Since MOBIKE and 212 IPsec packets have a different appearance on the wire, they might 213 be routed along a different path, for example by load balancers. 214 This definition is taken from [RFC2960] and adapted to the MOBIKE 215 context. 217 Primary Path: 219 The sequence of routers traversed by an IP packet that carries the 220 default source and destination addresses is said to be the Primary 221 Path. This definition is taken from [RFC2960] and adapted to the 222 MOBIKE context. 224 Preferred Address: 226 The IP address of a peer to which MOBIKE and IPsec traffic should 227 be sent by default. A given peer has only one active preferred 228 address at a given point in time, except for the small time period 229 where it switches from an old to a new preferred address. This 230 definition is taken from [I-D.ietf-hip-mm] and adapted to the 231 MOBIKE context. 233 Peer Address Set: 235 We denote the two peers of a MOBIKE session by peer A and peer B. 236 A peer address set is the subset of locally operational addresses 237 of peer A that is sent to peer B. A policy available at peer A 238 indicates which addresses are included in the peer address set. 239 Such a policy might be created either manually or automatically 240 through interaction with other mechanisms that indicate new 241 available addresses. 243 Bidirectional Address Pair:: 245 The address pair, where traffic can be sent to the both 246 directions, simply by reversing the IP addresses. Note, that the 247 path of the packets going to each direction might be different. 249 Unidirectional Address Pair:: 251 The address pair, where traffic can only be sent in one direction, 252 and reversing the IP addresses and sending reply back does not 253 work. 255 Terminology regarding NAT types (e.g., Full Cone, Restricted Cone, 256 Port Restricted Cone and Symmetric), can be found in Section 5 of 257 [RFC3489]. For mobility related terminology (e.g., Make-before-break 258 or Break-before-make) see [RFC3753]. 260 3. Scenarios 262 In this section we discuss three typical usage scenarios for the 263 MOBIKE protocol. 265 3.1. Mobility Scenario 267 Figure 1 shows a break-before-make mobility scenario where a mobile 268 node changes its point of network attachment. Prior to the change, 269 the mobile node had established an IPsec connection with a security 270 gateway which offered, for example, access to a corporate network. 271 The IKEv2 exchange that facilitated the setup of the IPsec SA(s) took 272 place over the path labeled as 'old path'. The involved packets 273 carried the MN's "old" IP address and were forwarded by the "old" 274 access router (OAR) to the security gateway (GW). 276 When the MN changes its point of network attachment, it obtains a new 277 IP address using stateful or stateless address configuration. The 278 goal of MOBIKE, in this scenario, is to enable the MN and the GW to 279 continue using the existing SAs and to avoid setting up a new IKE SA. 280 A protocol exchange, denoted by 'MOBIKE Address Update', enables the 281 peers to update their state as necessary. 283 Note that in a break-before-make scenario the MN obtains the new IP 284 address after it can no longer be reached at the old IP address. In 285 a make-before-break scenario, the MN is, for a given period of time, 286 reachable at both the old and the new IP address. MOBIKE should work 287 in both of the above scenarios. 289 (Initial IKEv2 Exchange) 290 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v 291 Old IP +--+ +---+ v 292 address |MN|------> |OAR| -------------V v 293 +--+ +---+ Old path V v 294 . +----+ v>>>>> +--+ 295 .move | R | -------> |GW| 296 . | | >>>>> | | 297 v +----+ ^ +--+ 298 +--+ +---+ New path ^ ^ 299 New IP |MN|------> |NAR|--------------^ ^ 300 address +--+ +---+ ^ 301 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ 302 (MOBIKE Address Update) 304 ---> = Path taken by data packets 305 >>>> = Signaling traffic (IKEv2 and MOBIKE) 306 ...> = End host movement 308 Figure 1: Mobility Scenario 310 3.2. Multihoming Scenario 312 Another MOBIKE usage scenario is depicted in Figure 2. In this 313 scenario, the MOBIKE peers are equipped with multiple interfaces (and 314 multiple IP addresses). Peer A has two interface cards with two IP 315 addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 316 and IP_B2. Each peer selects one of its IP addresses as the 317 preferred address which is used for subsequent communication. 318 Various reasons (e.g., hardware or network link failures), may 319 require a peer to switch from one interface to another. 321 +------------+ +------------+ 322 | Peer A | *~~~~~~~~~* | Peer B | 323 | |>>>>>>>>>> * Network *>>>>>>>>>>| | 324 | IP_A1 +-------->+ +--------->+ IP_B1 | 325 | | | | | | 326 | IP_A2 +********>+ +*********>+ IP_B2 | 327 | | * * | | 328 +------------+ *~~~~~~~~~* +------------+ 330 ---> = Path taken by data packets 331 >>>> = Signaling traffic (IKEv2 and MOBIKE) 332 ***> = Potential future path through the network 333 (if Peer A and Peer B change their preferred 334 address) 336 Figure 2: Multihoming Scenario 338 Note that MOBIKE does not aim to support load balancing between 339 multiple IP addresses. That is, each peer uses only one of the 340 available IP addresses at a given point in time. 342 3.3. Multihomed Laptop Scenario 344 The third scenario we consider is about a laptop, which has multiple 345 interface cards and therefore several ways to connect to the network. 346 It may, for example, have a fixed Ethernet card, a WLAN interface, a 347 GPRS adaptor, a Bluetooth interface or USB hardware. Not all 348 interfaces are used for communication all the time for a number of 349 reasons (e.g., cost, network availability, user convenience). The 350 policies that determine which interfaces are connected to the network 351 at any given point in time is outside the scope of the MOBIKE 352 protocol and, as such, this document. However, as the laptop changes 353 its point of attachment to the network, the set of IP addresses under 354 which the laptop is reachable, changes too. 356 Even if IP addresses change due to interface switching or mobility, 357 the IP address obtained via the configuration payloads within IKEv2 358 remain unaffected. The IP address obtained via the IKEv2 359 configuration payloads allow the configuration of the inner IP 360 address of the IPsec tunnel. As such, applications might not detect 361 any change at all. 363 4. Scope of MOBIKE 365 Getting mobility and multihoming actually working requires many 366 different components to work together, including coordinating 367 decisions between different layers, different mobility mechanisms, 368 and IPsec/IKE. Most of those aspects are beyond the scope of MOBIKE: 369 MOBIKE focuses only on what two peers need to agree at the IKEv2 370 level (like new message formats and some aspects of their processing) 371 required for interoperability. 373 The MOBIKE protocol is not trying to be a full mobility protocol; 374 there is no support for simultaneous movement or rendezvous 375 mechanism, and there is no support for route optimization etc. This 376 current design document focuses mainly on tunnel mode, everything 377 going inside the tunnel is unaffected by the changes in the tunnel 378 header IP address, and this is the mobility feature provided by the 379 MOBIKE, i.e., applications running inside the MOBIKE controlled IPsec 380 tunnel might not detect the movement since their IP addresses remain 381 constant. 383 The MOBIKE protocol should be able to perform the following 384 operations: 386 o Inform the other peer about the peer address set 388 o Inform the other peer about the preferred address 390 o Test connectivity along a path and thereby to detect an outage 391 situation 393 o Change the preferred address 395 o Change the peer address set 397 o Ability to deal with Network Address Translation devices 399 Figure 3 shows an example protocol interaction between a pair of 400 MOBIKE peers. MOBIKE interacts with the IPsec engine using for 401 example the PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon 402 can create entries in the Security Association (SAD) and Security 403 Policy Databases (SPD). The IPsec engine may also interact with 404 IKEv2 and MOBIKE daemon using this API. The content of the Security 405 Policy and Security Association Databases determines what traffic is 406 protected with IPsec in which fashion. MOBIKE, on the other hand, 407 receives information from a number of sources that may run both in 408 kernel-mode and in user-mode. Information relevant for MOBIKE might 409 be stored in a database. The content of such a database, along with 410 the occurrence of events of which the MOBIKE process is notified, 411 form the basis on which MOBIKE make decisions regarding the set of 412 available addresses, the peer address set, and the preferred address. 413 Policies may also affect the selection process. 415 The peer address set and the preferred address needs to be made 416 available to the other peer. In order to address certain failure 417 cases, MOBIKE should perform connectivity tests between the peers 418 (potentially over a number of different paths). Although a number of 419 address pairs may be available for such tests, the most important is 420 the pair (source address, destination address) of the primary path. 421 This is because this pair is selected for sending and receiving 422 MOBIKE signaling and IPsec traffic. If a problem along this primary 423 path is detected (e.g., due to a router failure) it is necessary to 424 switch to a new primary path. In order to be able to do so quickly, 425 it may be helpful to perform connectivity tests of other paths 426 periodically. Such a technique would also help in identifying 427 previously disconnected paths that become operational again. 429 +-------------+ +---------+ 430 |User-space | | MOBIKE | 431 |Protocols | +-->>| Daemon | 432 |relevant for | | | | 433 |MOBIKE | | +---------+ 434 +-------------+ | ^ 435 User Space ^ | ^ 436 ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ 437 Kernel Space v | v 438 _______ | v 439 +-------------+ / \ | +--------------+ 440 |Routing | / Trigger \ | | IPsec | 441 |Protocols |<<-->>| Database |<<-+ +>+ Engine | 442 | | \ / | | (+Databases) | 443 +-----+---+---+ \_______/ | +------+-------+ 444 ^ ^ ^ | ^ 445 | +---------------+-------------+--------+-----+ 446 | v | | | 447 | +-------------+ | | | 448 I | |Kernel-space | | | | I 449 n | +-------->+Protocols +<----+-----+ | | n 450 t v v |relevant for | | v v v t 451 e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e 452 r | Input | +-------------+ | | Outgoing | r 453 f | Packet +<--------------------------+ | Interface | f 454 ==a>|Processing|===============================| Processing |=a> 455 c | | | | c 456 e +----------+ +------------+ e 457 s s 458 ===> = IP packets arriving/leaving a MOBIKE node 459 <-> = control and configuration operations 461 Figure 3: Framework 463 Please note that Figure 3 illustrates an example of how a MOBIKE 464 implementation could work. Hence, it serves illustrative purposes 465 only. 467 Extensions of the PF_KEY interface required by MOBIKE are also within 468 the scope of the working group. Finally, certain optimizations for 469 wireless environments are also covered. 471 5. Design Considerations 473 This section discusses aspects affecting the design of the MOBIKE 474 protocol. 476 5.1. Choosing Addresses 478 One of the core aspects of the MOBIKE protocol is the selection of 479 the address for the IPsec packets we send. Choosing addresses for 480 the IKEv2 request is a somewhat separate problem: in many cases, they 481 will be the same (and in some design choice they will always be the 482 same). 484 5.1.1. Inputs and Triggers 486 How address changes are triggered is largely beyond the scope of 487 MOBIKE. The triggers can include, changes in the set of addresses, 488 various link-layer indications, failing dead peer detection, and 489 changes in preferences and policies. Furthermore, there may be less 490 reliable sources of information (such as lack of IPsec packets and 491 incoming ICMP packets) that do not trigger any changes directly, but 492 rather cause Dead Peer Detection (DPD) to be scheduled earlier and if 493 it fails it might cause a change of the preferred address. 495 These triggers are largely the same as for, e.g., Mobile IP, and are 496 beyond the scope of MOBIKE. 498 5.1.2. Connectivity 500 There can be two kinds of connectivity "failures": local failures and 501 path failures. Local failures are problems locally at an MOBIKE peer 502 (e.g., an interface error). Path failures are a property of an 503 address pair and failures of nodes and links along this path. MOBIKE 504 does not support unidirectional address pairs (i.e. where you can 505 only send traffic in one direction when using single address pair). 506 Supporting them would require abandoning the principle of sending an 507 IKEv2 reply to the address the request came from. MOBIKE decided to 508 deal only with bidirectional address pairs. It does consider 509 unidirectional address pairs as broken, and does not use them, but 510 the connection between peers will not break even if unidirectional 511 address pairs are present, provided there is at least one 512 bidirectional address pair MOBIKE can use. 514 Note that MOBIKE is not really concerned about the actual path used, 515 it cannot even detect if some path is unidirectionally operational if 516 the same address pair has some other unidirectional path back. 517 Ingress filters might still cause such path pairs to be unusable, and 518 in that case MOBIKE will detect that there is no operational address 519 pair. 521 In a sense having both an IPv4 and an IPv6 address is basically a 522 case of partial connectivity (putting both an IPv4 and an IPv6 523 address in the same IP header does not work). The main difference is 524 that it is known beforehand, and there is no need to discover that 525 IPv4/IPv6 combination does not work. 527 5.1.3. Discovering Connectivity 529 To detect connectivity, i.e., failures along the path, the MOBIKE 530 protocol needs to have a mechanism to test connectivity. If a MOBIKE 531 peer receives a reply it can be sure about the existence of a working 532 (bidirectional) address pair. If a MOBIKE peer does not see a reply 533 after multiple retransmissions it may assume that the tested address 534 pair is broken. 536 The connectivity tests require congestion problems to be taken into 537 account because the connection failure might be caused by a 538 congestion, and the MOBIKE protocol should not make the congestion 539 problem worse by sending lots of DPD packets. 541 5.1.4. Decision Making 543 One of the main decisions in designing the MOBIKE protocol is who 544 makes the decisions how to fix situation when failure is detected, 545 e.g., symmetry vs. asymmetry in decision making. Symmetric decision 546 making (i.e. both peers can make decisions) may cause the different 547 peers to make different decisions, thus causing asymmetric upstream/ 548 downstream traffic. In mobility case it is desirable that the mobile 549 peer can move both upstream and downstream traffic to some particular 550 interface, and this requires asymmetric decision making (i.e. only 551 one peer makes decisions. 553 Working with stateful packet filters and NATs is easier if the same 554 address pair is used in both upstream and downstream directions. 555 Also in common cases only the peer behind NAT can actually perform 556 actions to recover from the connectivity problems, as it might be 557 that the other peer is not able to initiate any connections to the 558 peer behind NAT. 560 5.1.5. Suggested Approach 562 The working group decided to select a method where the initiator will 563 decide which addresses are used. As a consequence the outcome cannot 564 be asymmetric decisions. It also works best with NATs, as the 565 initiator is most likely the node that is located behind a NAT. 567 5.2. NAT Traversal 569 5.2.1. Background and Constraints 571 Another core aspect of MOBIKE is the treatment of different NATs and 572 NAPTs. In IKEv2 the tunnel header IP addresses are not sent inside 573 the IKEv2 payloads, and thus there is no need to do unilateral self- 574 address fixing (UNSAF). The tunnel header IP addresses are taken 575 from the outer IP header of the IKE packets, thus they are already 576 processed by the NAT. 578 The NAT detection payloads are used to determine whether the 579 addresses in the IP header were modified by a NAT along the path. 580 Detecting a NAT typically requires UDP encapsulation of IPsec ESP 581 packets to be enabled, if desired. MOBIKE is not to change how IKEv2 582 NAT-T works, in particular, any kind of UNSAF or explicit interaction 583 with NATs (e.g., MIDCOM or NSIS NATFW NSLP) are beyond the scope of 584 MOBIKE protocol. The MOBIKE protocol will need to define how MOBIKE 585 and NAT-T are used together. 587 The NAT-T support should also be optional, i.e., if the IKEv2 588 implementation does not implement NAT-T, as it is not required in 589 some particular environment, implementing MOBIKE should not require 590 adding support for NAT-T as well. 592 The property of being behind NAT is actually a property of the 593 address pair and thereby by the path taken by a packet, thus one peer 594 can have multiple IP addresses and some of those might be behind NAT 595 and some might not. 597 5.2.2. Fundamental Restrictions 599 There are some cases which cannot be carried out within the 600 restrictions of the MOBIKE charter. One of those cases is the case 601 where the party "outside" a symmetric NAT changes its address to 602 something not known by the the other peer (and old address has 603 stopped working). It cannot send a packet containing the new 604 addresses to the peer because the NAT does not contain the necessary 605 state. Furthermore, since the party behind the NAT does not know the 606 new IP address, it cannot cause the NAT state to be created. 608 This case could be solved using some rendezvous mechanism outside 609 IKEv2, but that is beyond the scope of MOBIKE. 611 5.2.3. Moving to behind a NAT and back 613 The MOBIKE protocol should provide a mechanism where a peer that is 614 initially not behind a NAT can move behind NAT, when a new preferred 615 address is selected. The same effect might be accomplished with the 616 change of the address pair if more than one path is available (e.g., 617 in case of a multi-homed host). An impact for the MOBIKE protocol is 618 only caused when the currently selected address pair causes MOBIKE 619 packets to traverse a NAT. 621 Similarly the MOBIKE protocol provides a mechanism to detect when a 622 NATed path is changed to a non-NATed path with the change of the 623 addressed pair. 625 As we only use one address pair at time, effectively the MOBIKE peer 626 is either behind NAT or not behind NAT, but each address change can 627 change this situation. Because of this and because the initiator 628 always chooses the addresses it is enough to send keepalive packets 629 only to that one address pair. 631 Enabling NAT-T involves a few different things, one is to enable the 632 UDP encapsulation of ESP packets. Another is to change the IKE SA 633 ports from port 500 to port 4500. We do not want to do unnecessary 634 UDP encapsulation unless there is really a NAT between peers, i.e. 635 UDP encapsulation should only be enabled when we actually detect NAT. 636 On the other hand, as all implementations supporting NAT-T must be 637 able to respond to port 4500 all the time, it is simpler from the 638 protocol point of view to change the port numbers from 500 to 4500 639 immediately when we detect that the other end supports NAT-T. This 640 way we do not need to start changing ports after we later detected 641 NAT, which would have caused complications to the protocol. 643 If we would do the actual changing of the port only after we detect 644 NAT, then the responder would not be able to use the IKE and IPsec 645 SAs immediately after their address is changed to be behind NAT. 646 Instead it would need to wait for the next packet from the initiator 647 to see what IP and port numbers are used after the initiator changed 648 its port from 500 to 4500. The responder would also not be able to 649 send anything to the initiator before the initiator has sent 650 something to the responder. If we do the port number changing 651 immediately after the IKE_SA_INIT and before IKE_AUTH phase, then we 652 get the rid of this problem. 654 5.2.4. Responder behind a NAT 656 MOBIKE can work in cases where the responder is behind static NAT, 657 but in that case the initiator needs to know all the possible 658 addresses where the responder can move to, i.e. the responder cannot 659 move to an address which is not known by the initiator, in case 660 initiator also moves behind NAT. 662 If the responder is behind NAPT then it might need to communicate 663 with the NAT to create a mapping so the initiator can connect to it. 664 Those external hole punching mechanisms are beyond the scope of 665 MOBIKE. 667 In case the responder is behind NAPT, then also finding the port 668 numbers used by the responder is outside the scope of MOBIKE. 670 5.2.5. NAT Prevention 672 One new feature created by MOBIKE is NAT prevention, i.e. if we 673 detect NAT between the peers, we do not allow that address pair to be 674 used. This can be used to protect IP addresses in cases where it is 675 known by the configuration that there is no NAT between the nodes 676 (for example IPv6, or fixed site-to-site VPN). This gives extra 677 protection against 3rd party bombing attacks (the attacker cannot 678 divert the traffic to some 3rd party). This feature means that we 679 authenticate the IP-address and detect if they were changed. As this 680 is done on purpose to break the connectivity if NAT is detected, and 681 decided by the configuration, there is no need to do UNSAF 682 processing. 684 5.2.6. Suggested Approach 686 The working group decided that MOBIKE uses NAT-T mechanisms from the 687 IKEv2 protocol as much as possible, but decided to change the dynamic 688 address update for IKEv2 packets to MUST NOT (it would break path 689 testing using IKEv2 packets, see Section 6.2). The working group 690 also decided to only send keepalives to the current address pair. 692 5.3. Scope of SA Changes 694 Most sections of this document discuss design considerations for 695 updating and maintaining addresses in the database entries that 696 relate to an IKE SA. However, changing the preferred address also 697 affects the entries of the IPsec SA database. The outer tunnel 698 header addresses (source and destination IP addresses) need to be 699 modified according to the primary path to allow the IPsec protected 700 data traffic to travel along the same path as the MOBIKE packets. If 701 the MOBIKE messages and the IPsec protected data traffic travel along 702 a different path then NAT handling is severely complicated. 704 The basic question is then how the IPsec SAs are changed to use the 705 new address pair (the same address pair as the MOBIKE signaling 706 traffic). One option is that when the IKE SA address is changed, 707 then all IPsec SAs associated with it are automatically moved along 708 with it to a new address pair. Another option is to have a separate 709 exchange to move the IPsec SAs separately. 711 If IPsec SAs should be updated separately then a more efficient 712 format than the Notify payload is needed to preserve bandwidth. A 713 Notify payload can only store one SPI per payload. A separate 714 payload could have a list of IPsec SA SPIs and the new preferred 715 address. If there is a large number of IPsec SAs, those payloads can 716 be quite large unless ranges of SPI values are supported. If we 717 automatically move all IPsec SAs when the IKE SA moves, then we only 718 need to keep track of which IKE SA was used to create the IPsec SA, 719 and fetch the IP addresses from the IKE SA, i.e. there is no need to 720 store IP addresses per IPsec SA. Note that IKEv2 [I-D.ietf-ipsec- 721 ikev2] already requires the implementations to keep track which IPsec 722 SAs are created using which IKE SA. 724 If we do allow address set of each IPsec SA to be updated separately, 725 then we can support scenarios where the machine has fast and/or cheap 726 connections and slow and/or expensive connections, and wants to allow 727 moving some of the SAs to the slower and/or more expensive 728 connection, and prevent the move, for example, of the news video 729 stream from the WLAN to the GPRS link. 731 On the other hand, even if we tie the IKE SA update to the IPsec SA 732 update, then we can create separate IKE SAs for this scenario, e.g., 733 we create one IKE SA which has both links as endpoints, and it is 734 used for important traffic, and then we create another IKE SA which 735 has only the fast and/or cheap connection, which is then used for 736 that kind of bulk traffic. 738 The working group decided to move all IPsec SAs implicitly when the 739 IKE SA address pair changes. If more granular handling of the IPsec 740 SA is required, then multiple IKE SAs can be created one for each set 741 of IPsec SAs needed. 743 5.4. Zero Address Set Functionality 745 One of the features which is potentially useful is for the peer to 746 announce that it will now disconnect for some time, i.e. it will not 747 be reachable at all. For instance, a laptop might go to suspend 748 mode. In this case it could send address notification with zero new 749 addresses, which would mean that it will not have any valid addresses 750 anymore. The responder of that kind of notification would then 751 acknowledge that, and could then temporarily disable all SAs and 752 therefore stop sending traffic. If any of the SAs gets any packets 753 they are simply dropped. This could also include some kind of ACK 754 spoofing to keep the TCP/IP sessions alive (or simply setting the 755 TCP/IP keepalives and timeouts large enough not to cause problems), 756 or it could simply be left to the applications, e.g. allow TCP/IP 757 sessions to notice if the link is broken. 759 The local policy could then indicate how long the peer should allow 760 remote peers to remain disconnected. 762 From a technical point of view this feature addresses two issues: 764 o There is no need to transmit IPsec data traffic. IPsec protected 765 data can be dropped which saves bandwidth. This does not provide 766 a functional benefit, i.e., nothing breaks if this feature is not 767 provided. 769 o MOBIKE signaling messages are also ignored. The IKE-SA must not 770 be deleted and the suspend functionality (realized with the zero 771 address set) may require the IKE-SA to be tagged with a lifetime 772 value since the IKE-SA should not be kept alive for an undefined 773 period of time. Note that IKEv2 does not require that the IKE-SA 774 has a lifetime associated with it. In order to prevent the IKE-SA 775 from being deleted the dead-peer detection mechanism needs to be 776 suspended as well. 778 Due to the fact that this extension could be complicated and there 779 was no clear need for it, a first version of the MOBIKE protocol will 780 not provide this feature. 782 5.5. Return Routability Check 784 Changing the preferred address and subsequently using it for 785 communication is associated with an authorization decision: Is a peer 786 allowed to use this address? Does this peer own this address? Two 787 mechanisms have been proposed in the past to allow a peer to 788 determine the answer to these questions: 790 o The addresses a peer is using are part of a certificate. 791 [RFC3554] introduced this approach. If the other peer is, for 792 example, a security gateway with a limited set of fixed IP 793 addresses, then the security gateway may have a certificate with 794 all the IP addresses appearing in the certificate. 796 o A return routability check is performed by the remote peer before 797 the address is updated in that peer's Security Association 798 Database. This is done in order provide a certain degree of 799 confidence to the remote peer that local peer is reachable at the 800 indicated address. 802 Without taking an authorization decision a malicious peer can 803 redirect traffic towards a third party or a blackhole. 805 A MOBIKE peer should not use an IP addressed provided by another 806 MOBIKE peer as a primary address without computing the authorization 807 decision. If the addresses are part of the certificate then it is 808 not necessary to execute the weaker return routability check. The 809 return routability check is a form of authorization check, although 810 it provides weaker guarantees than the inclusion of the IP address as 811 a part of a certificate. If multiple addresses are communicated to 812 the remote peer then some of these addresses may be already verified 813 even if the primary address is still operational. 815 Another option is to use the [I-D.dupont-mipv6-3bombing] approach 816 which suggests to perform a return routability check only when an 817 address update needs to be sent from some address other than the 818 indicated preferred address. 820 Finally it would be possible not to execute return routability checks 821 at all. In case of indirect change notifications we only move to the 822 new preferred address after successful dead-peer detection (i.e., a 823 response to a DPD test) on the new address, which is already a return 824 routability check. With a direct notification the authenticated peer 825 may have provided an authenticated IP address (i.e. inside IKE 826 encrypted and authenticated payload, see Section 5.2.5). Thus it is 827 would be possible to simply trust the MOBIKE peer to provide a proper 828 IP address. In this case A protection against an internal attacker, 829 i.e. the authenticated peer forwarding its traffic to the new 830 address, would not provided. On the other hand we know the identity 831 of the peer in that case. There might be problems when extensions 832 are added to IKEv2 that do not require authentication of end points 833 (e.g., opportunistic security using anonymous Diffie-Hellman). 835 There is also a policy issue of when to schedule a return routability 836 check. Before moving traffic? After moving traffic? 838 The basic format of the return routability check could be similar to 839 dead-peer detection, but potential attacks are possible if a return 840 routability check does not include some kind of a nonce. In these 841 attacks the valid end point could send an address update notification 842 for a third party, trying to get all the traffic to be sent there, 843 causing a denial of service attack. If the return routability check 844 does not contain any nonce or other random information not known to 845 the other peer, then other peer could reply to the return routability 846 checks even when it cannot see the request. This might cause a peer 847 to move the traffic to a location where the original recipient cannot 848 be reached. 850 The IKEv2 NAT-T mechanism does not perform return routability checks. 851 It simply uses the last seen source IP address used by the other peer 852 as the destination address to send response packets. An adversary 853 can change those IP addresses, and can cause the response packets to 854 be sent to a wrong IP address. The situation is self-fixing when the 855 adversary is no longer able to modify packets and the first packet 856 with an unmodified IP address reaches the other peer. Mobility 857 environments make this attack more difficult for an adversary since 858 the attack requires the adversary to be located somewhere on the 859 individual paths ({CoA1, ..., CoAn} towards the destination IP 860 address), have a shared path or, if the adversary is located near the 861 MOBIKE client then it needs to follow the user mobility patterns. 862 With IKEv2 NAT-T, the genuine client can cause third party bombing by 863 redirecting all the traffic pointed to him to a third party. As the 864 MOBIKE protocol tries to provide equal or better security than IKEv2 865 NAT-T mechanism it should protect against these attacks. 867 There may be return routability information available from the other 868 parts of the system too (as shown in Figure 3), but the checks done 869 may have a different quality. There are multiple levels for return 870 routability checks: 872 o None, no tests 874 o A party willing to answer the return routability check is located 875 along the path to the claimed address. This is the basic form of 876 return routability check. 878 o There is an answer from the tested address, and that answer was 879 authenticated, integrity and replay protected. 881 o There was an authenticated, integrity and replay protected answer 882 from the peer, but it is not guaranteed to originate at the tested 883 address or path to it (because the peer can construct a response 884 without seeing the request). 886 The return routability checks do not protect against 3rd party 887 bombing if the attacker is along the path, as the attacker can 888 forward the return routability checks to the real peer (even if those 889 packets are cryptographically authenticated). 891 If the address to be tested is carried inside the MOBIKE payload, 892 then the adversary cannot forward packets. Thus 3rd party bombings 893 are prevented (see Section 5.2.5). 895 If the reply packet can be constructed without seeing the request 896 packet (for example, if there is no nonce, challenge or similar 897 mechanism to show liveness), then the genuine peer can cause 3rd 898 party bombing, by replying to those requests without seeing them at 899 all. 901 Other levels might only provide a guarantee that there is a node at 902 the IP address which replied to the request. There is no indication 903 as to whether or not the reply is fresh, and whether or not the 904 request may have been transmitted from a different source address. 906 5.5.1. Employing MOBIKE Results in other Protocols 908 If MOBIKE has learned about new locations or verified the validity of 909 a remote address through a return routability check, can this 910 information be useful for other protocols? 912 When considering the basic MOBIKE VPN scenario, the answer is no. 913 Transport and application layer protocols running inside the VPN 914 tunnel are unaware of the outer addresses or their status. 916 Similarly, IP layer tunnel termination at a gateway rather than a 917 host endpoint limits the benefits for "other protocols" that could be 918 informed -- all application protocols at the other side are unaware 919 of IPsec, IKE, or MOBIKE. 921 However, it is conceivable that future uses or extensions of the 922 MOBIKE protocol make such information distribution useful. For 923 instance, if transport mode MOBIKE and SCTP were made to work 924 together, it would potentially be useful for SCTP dynamic address 925 reconfiguration [I-D.ietf-tsvwg-addip-sctp] to learn about the new 926 addresses at the same time as MOBIKE. Similarly, various IP layer 927 mechanisms may make use of the fact that a return routability check 928 of a specific type has been performed. However, care should be 929 exercised in all these situations. 931 [I-D.crocker-celp] discusses the use of common locator information 932 pools in a IPv6 multi-homing context; it assumed that both transport 933 and IP layer solutions are used in order to support multi-homing, and 934 that it would be beneficial for different protocols to coordinate 935 their results in some way, for instance by sharing throughput 936 information of address pairs. This may apply to MOBIKE as well, 937 assuming it co-exists with non-IPsec protocols that are faced with 938 the same or similar multi-homing choices. 940 Nevertheless, all of this is outside the scope of current MOBIKE base 941 protocol design and may be addressed in future work. 943 5.5.2. Return Routability Failures 945 If the return routability check fails, we need to tear down the IKE 946 SA if we are using IKEv2 INFORMATIONAL exchanges to send return 947 routability checks. On the other hand return routability check can 948 only fail permanently if there was an attack by the other end, thus 949 tearing down the IKE SA is a suitable action in that case. 951 There are some cases where the return routability check temporarily 952 fails that need to be considered here. In the first case there is no 953 attacker, but the selected address pair stops working immediately 954 after the address update, before the return routability check. 956 What happens there is that the initiator does the normal address 957 update, and that succeeds, and then the responder starts a return 958 routability check. If the address pair has broken down before that, 959 the responder will never get back the reply to the return routability 960 check. The responder might still be using the old IP address pair, 961 which could still work. 963 The initiator might be still seeing traffic from the responder, but 964 using the old address pair. The initiator should detect that this 965 traffic is not using the latest address pair, and after a while it 966 should start dead peer detection on the current address pair. If 967 that fails, then it should find a new working address pair, and 968 update addresses to that. The responder should notice that the 969 address pair was updated after the return routability check was 970 started, and change the ongoing return routability check to use the 971 new address pair. The result of that return routability check needs 972 to be discarded as it cannot be trusted as the packets were 973 retransmitted to a different IP address. So normally the responder 974 starts a new return routability check after that with the new address 975 pair. 977 The second case is where there is an attacker along the path 978 modifying the IP addresses. The peers will detect this as NAT and 979 will enable NAT-T recovery of changes in the NAT mappings. If the 980 attacker is along the path long enough for the return routability 981 check to succeed, then the normal recovery of changes in the NAT 982 mappings will take care of the problem. If the attacker disappears 983 before return routability check is finished, but after the update we 984 have almost a similar case than last time. Now the only difference 985 is now that the dead peer detection started by the initiator will 986 succeed, as the responder will reply to the addresses in the headers, 987 not the current address pair. The initiator will then detect that 988 the NAT mappings are changed, and it will fix the situation by doing 989 an address update. 991 The important thing for both of these cases is that the initiator 992 needs to see that the responder is both alive and synchronized with 993 initiator address pair updates. I.e. it is not enough that the 994 responder is sending traffic to an initiator, it must be also using 995 the correct IP addresses before the initiator can belive it is alive 996 and synchronized. From the implementation point of view this means 997 that the initiator must not consider packets having wrong IP 998 addresses as packets that prove the other end being alive, i.e. they 999 do not reset the dead peer detection timers. 1001 5.5.3. Suggested Approach 1003 The working group selected to use IKEv2 INFORMATIONAL exchanges as a 1004 return routability check, but included a random cookie to prevent 1005 redirections by an authenticated attacker. Return routability checks 1006 are performed by default before moving the traffic. However these 1007 tests are optional. Nodes MAY also perform these tests upon their 1008 own initiative at other times. 1010 It is worth noting that the return routability check in MOBIKE is not 1011 the same as the return routability check in MIP6: The MIP6 WG decided 1012 that it is not necessary to do return routability checks between the 1013 mobile node and the home agent at all. 1015 5.6. IPsec Tunnel or Transport Mode 1017 Current MOBIKE design is focused only on the VPN type usage and 1018 tunnel mode. Transport mode behavior would also be useful, but will 1019 be discussed in future documents. 1021 6. Protocol Details 1023 6.1. Indicating Support for MOBIKE 1025 In order for MOBIKE to function, both peers must implement the MOBIKE 1026 extension of IKEv2. If one of the peers does not support MOBIKE, 1027 then, whenever an IP address changes, IKEv2 will have to be re-run in 1028 order to create a new IKE SA and the respective IPsec SAs. In 1029 MOBIKE, a peer needs to be confident that its address change messages 1030 are understood by the other peer. If these messages are not 1031 understood, it is possible that connectivity between the peers is 1032 lost. 1034 One way to ensure that a peer receives feedback on whether its 1035 messages are understood by the other peer, is by using IKEv2 1036 messaging for MOBIKE and to mark some messages as "critical". 1037 According to the IKEv2 specification, such messages either have to be 1038 understood by the receiver, or an error message has to be returned to 1039 the sender. 1041 A second way to ensure receipt of the above-mentioned feedback is by 1042 using Vendor ID payloads that are exchanged during the initial IKEv2 1043 exchange. These payloads would then indicate whether or not a given 1044 peer supports the MOBIKE protocol. 1046 A third approach would use the Notify payload to indicate support of 1047 MOBIKE extension, such Notify payloads are also used for indicating 1048 NAT traversal support (via NAT_DETECTION_SOURCE_IP and 1049 NAT_DETECTION_DESTINATION_IP payloads). 1051 Both a Vendor ID and a Notify payload may be used to indicate the 1052 support of certain extensions. 1054 Note that a MOBIKE peer could also attempt to execute MOBIKE 1055 opportunistically with the critical bit set when an address change 1056 has occurred. The drawback of this approach is, however, that an 1057 unnecessary message exchange is introduced. 1059 Although Vendor ID payloads and Notify payloads are technically 1060 equivalent, Notify payloads are already used in IKEv2 as a capability 1061 negotiation mechanism. Hence, Notify payloads are used in MOBIKE to 1062 indicate support of MOBIKE protocol. 1064 Also, as the information of the support of MOBIKE is not needed 1065 during the IKE_SA_INIT exchange, the indication of the support is 1066 done inside the IKE_AUTH exchange. The reason for this is the need 1067 to keep the IKE_SA_INIT messages as small as possible so that they do 1068 not get fragmented. IKEv2 allows that the responder can do stateless 1069 processing of the first IKE_SA_INIT packet, and request a cookie from 1070 the other end if it is under attack. To mandate the responder to be 1071 able to reassemble initial IKE_SA_INIT packets would not allow fully 1072 stateless processing of the initial IKE_SA_INIT packets. 1074 6.2. Path Testing and Window size 1076 As IKEv2 has a window of outgoing messages, and the sender is not 1077 allowed to violate that window (meaning, that if the window is full, 1078 then the sender cannot send packets), it can cause some complications 1079 to path testing. Another complication created by IKEv2 is that once 1080 the message is created and sent to the other end, it cannot be 1081 modified in its future retransmissions. This makes it impossible to 1082 know what packet actually reached the other end first. We cannot use 1083 IP headers to find out which packet reached the other end first, as 1084 if the responder gets retransmissions of the packet it has already 1085 processed and replied to (and those replies might have been lost due 1086 unidirectional address pair), it will retransmit the previous reply 1087 using the new address pair of the request. Because of this it might 1088 be possible that the responder has already used the IP address 1089 information from the header of the previous packet, and the reply 1090 packet ending up to the initiator has a different address pair. 1092 Another complication comes from NAT-T. The current IKEv2 document 1093 says that if NAT-T is enabled the node not behind NAT SHOULD detect 1094 if the IP-address changes in the incoming authenticated packets, and 1095 update the remote peers' addresses accordingly. This works fine with 1096 NAT-T, but it causes some complications in MOBIKE, as MOBIKE needs 1097 the ability to probe another address pairs without breaking the old 1098 one. 1100 One approach to fix this would be to add a completely new protocol 1101 that is outside the IKE SA message id limitations (window code), 1102 outside identical retransmission requirements, and outside the 1103 dynamic address updating of NAT-T. 1105 Another approach is to make the protocol so that it does not violate 1106 window restrictions and does not require changing the packet on 1107 retransmissions, and change the dynamic address updating of NAT-T to 1108 MUST NOT for IKE SA packets if MOBIKE is used. In order to not 1109 violate window restrictions, the addresses of the currently ongoing 1110 exchange need to be changed to test different paths. In order to not 1111 require changing the packet after it is first sent requires that the 1112 protocol needs to restart from the beginning in case the packet was 1113 retransmitted to different addresses (because the sender does not 1114 know which packet was the one that responder got first, i.e. which 1115 IP-addresses it used). 1117 Working group decided to use normal IKEv2 exchanges for path testing, 1118 and decided to change the dynamic address updating of NAT-T to MUST 1119 NOT for IKE SA packets. I.e. a new protocol outside of IKEv2 was not 1120 adopted. 1122 6.3. Message presentation 1124 The IP address change notifications can be sent either via an 1125 informational exchange already specified in IKEv2, or via a MOBIKE- 1126 specific message exchange. Using an informational exchange has the 1127 main advantage that it is already specified in the IKEv2 protocol and 1128 implementations can already incorporate the functionality. 1130 Another question is the format of the address update notifications. 1131 The address update notifications can include multiple addresses, of 1132 which some may be IPv4 and some IPv6 addresses. The number of 1133 addresses is most likely going to be limited in typical environments 1134 (with less than 10 addresses). The format may need to indicate a 1135 preference value for each address. The format could either contain a 1136 preference number that determines the relative order of the 1137 addresses, or it could simply be an ordered list of IP addresses. If 1138 using preference numbers, then two addresses can have the same 1139 preference value, an ordered list avoids this situation. 1141 Load balancing is currently outside the scope of MOBIKE, however 1142 future work might include support for it. The selected format needs 1143 to be flexible enough to include additional information in future 1144 versions of the protocol (e.g. to enable load balancing). This may 1145 be realized with an reserved field, which can later be used to store 1146 additional information. As there may arise other information which 1147 may have to be tied to an address in the future, a reserved field 1148 seems like a prudent design in any case. 1150 There are two basic formats that place IP address lists into a 1151 message. One includes each IP address as separate payload (where the 1152 payload order indicates the preference order, or the payload itself 1153 might include the preference number), or we can put the IP address 1154 list as one payload to the exchange, and that one payload will then 1155 have an internal format which includes the list of IP addresses. 1157 Having multiple payloads with each one carrying one IP address makes 1158 the protocol probably easier to parse, as we can already use the 1159 normal IKEv2 payload parsing procedures. It also offers an easy way 1160 for the extensions, as the payload probably contains only the type of 1161 the IP address (or the type is encoded to the payload type), and the 1162 IP address itself, and as each payload already has a length field 1163 associated to it, we can detect if there is any extra data after the 1164 IP address. Some implementations might have problems parsing more 1165 than certain number of IKEv2 payloads, but if the sender sends them 1166 in the most preferred first, the receiver can only use the first 1167 addresses, it was willing to parse. 1169 Having all IP addresses in one big MOBIKE specified internal format 1170 provides more compact encoding, and keeps the MOBIKE implementation 1171 more concentrated to one module. 1173 Another choice is which type of payloads to use. IKEv2 already 1174 specifies a Notify payload. It includes some extra fields (SPI size, 1175 SPI, protocol etc), which gives 4 bytes of the extra overhead, and 1176 there is the notification data field, which could include the MOBIKE 1177 specific data. 1179 Another option would be to have a custom payload type, which then 1180 includes the information needed for the MOBIKE protocol. 1182 Working group decided to use IKEv2 Notify payloads, and put only one 1183 data item per notify, i.e. there will be one Notify payload for each 1184 item to be sent. 1186 6.4. Updating address list 1188 Because of the initiator decides all address updates, the initiator 1189 needs to know all the addresses used by the responder. The responder 1190 also needs that list in case it happens to move to an address not 1191 known by the initiator, and needs to send an address update 1192 notification to the initiator, and it might need to try different 1193 addresses for the initiator. 1195 MOBIKE could send the full peer address list every time any of the IP 1196 addresses change (either addresses are added, removed, the order 1197 changes or the preferred address is updated) or an incremental 1198 update. Sending incremental updates provides more compact packets 1199 (meaning we can support more IP addresses), but on the other hand 1200 this approach has more problems in the synchronization and packet 1201 reordering cases, i.e., incremental updates must be processed in 1202 order, but for full updates we can simply use the most recent one, 1203 and ignore old ones, even if they arrive after the most recent one 1204 (IKEv2 packets have a message id which is incremented for each 1205 packet, thus it is easy to know the sending order). 1207 Working group decided to use a protocol format where both ends send a 1208 full list of their addresses to the other end, and that list 1209 overwrites the previous list. To support NAT-T the IP-addresses of 1210 the received packet is added to the list (and they are not present in 1211 the list). 1213 7. Security Considerations 1215 As all the messages are already authenticated by IKEv2 there is no 1216 risk that any attackers would modify the contents of the packets. 1217 The IP addresses in the IP header of the packets are not 1218 authenticated, thus the protocol defined must take care that they are 1219 only used as an indication that something might be different, and 1220 that do not cause any direct actions, except when doing NAT 1221 Traversal. 1223 An attacker can also spoof ICMP error messages in an effort to 1224 confuse the peers about which addresses are not working. At worst 1225 this causes denial of service and/or the use of non-preferred 1226 addresses. 1228 One type of attack that needs to be taken care of in the MOBIKE 1229 protocol is the 'flooding attack' type. See [I-D.ietf-mip6-ro-sec] 1230 and [Aur02] for more information about flooding attacks. 1232 8. IANA Considerations 1234 This document does not introduce any IANA considerations. 1236 9. Acknowledgments 1238 This document is the result of discussions in the MOBIKE working 1239 group. The authors would like to thank Jari Arkko, Pasi Eronen, 1240 Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, 1241 James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, 1242 Udo Schilcher, Tom Henderson, Andreas Pashalidis and Maureen Stillman 1243 for their input. 1245 We would like to particularly thank Pasi Eronen for tracking open 1246 issues on the MOBIKE mailing list. He helped us to make good 1247 progress on the document. 1249 10. References 1251 10.1. Normative references 1253 [I-D.ietf-ipsec-ikev2] 1254 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1255 draft-ietf-ipsec-ikev2-17 (work in progress), 1256 October 2004. 1258 [I-D.ietf-ipsec-rfc2401bis] 1259 Kent, S. and K. Seo, "Security Architecture for the 1260 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 1261 in progress), April 2005. 1263 10.2. Informative References 1265 [I-D.arkko-multi6dt-failure-detection] 1266 Arkko, J., "Failure Detection and Locator Selection in 1267 Multi6", draft-arkko-multi6dt-failure-detection-00 (work 1268 in progress), October 2004. 1270 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1271 (IKE)", RFC 2409, November 1998. 1273 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1274 Internet Protocol", RFC 2401, November 1998. 1276 [I-D.dupont-mipv6-3bombing] 1277 Dupont, F., "A note about 3rd party bombing in Mobile 1278 IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), 1279 June 2005. 1281 [I-D.ietf-mip6-ro-sec] 1282 Nikander, P., "Mobile IP version 6 Route Optimization 1283 Security Design Background", draft-ietf-mip6-ro-sec-03 1284 (work in progress), May 2005. 1286 [I-D.ietf-hip-mm] 1287 Nikander, P., "End-Host Mobility and Multihoming with the 1288 Host Identity Protocol", draft-ietf-hip-mm-02 (work in 1289 progress), July 2005. 1291 [I-D.crocker-celp] 1292 Crocker, D., "Framework for Common Endpoint Locator 1293 Pools", draft-crocker-celp-00 (work in progress), 1294 February 2004. 1296 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1297 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1298 Through Network Address Translators (NATs)", RFC 3489, 1299 March 2003. 1301 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1302 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1303 Zhang, L., and V. Paxson, "Stream Control Transmission 1304 Protocol", RFC 2960, October 2000. 1306 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1307 RFC 3753, June 2004. 1309 [I-D.ietf-tsvwg-addip-sctp] 1310 Stewart, R., "Stream Control Transmission Protocol (SCTP) 1311 Dynamic Address Reconfiguration", 1312 draft-ietf-tsvwg-addip-sctp-13 (work in progress), 1313 November 2005. 1315 [I-D.dupont-ikev2-addrmgmt] 1316 Dupont, F., "Address Management for IKE version 2", 1317 draft-dupont-ikev2-addrmgmt-08 (work in progress), 1318 November 2005. 1320 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 1321 Stewart, "On the Use of Stream Control Transmission 1322 Protocol (SCTP) with IPsec", RFC 3554, July 2003. 1324 [I-D.ietf-ipv6-optimistic-dad] 1325 Moore, N., "Optimistic Duplicate Address Detection for 1326 IPv6", draft-ietf-ipv6-optimistic-dad-06 (work in 1327 progress), September 2005. 1329 [I-D.ietf-ipv6-unique-local-addr] 1330 Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1331 Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in 1332 progress), January 2005. 1334 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1335 E. Lear, "Address Allocation for Private Internets", 1336 BCP 5, RFC 1918, February 1996. 1338 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1339 Management API, Version 2", RFC 2367, July 1998. 1341 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1342 Autoconfiguration", RFC 2462, December 1998. 1344 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1345 Discovery for IP Version 6 (IPv6)", RFC 2461, 1346 December 1998. 1348 [I-D.ietf-mobike-protocol] 1349 Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1350 (MOBIKE)", draft-ietf-mobike-protocol-06 (work in 1351 progress), November 2005. 1353 [Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1354 Location Management", In Proc. 18th Annual Computer 1355 Security Applications Conference, pages 78-87, Las Vegas, 1356 NV USA, December 2002. 1358 Authors' Addresses 1360 Tero Kivinen 1361 Safenet, Inc. 1362 Fredrikinkatu 47 1363 HELSINKI FI-00100 1364 FI 1366 Email: kivinen@safenet-inc.com 1368 Hannes Tschofenig 1369 Siemens 1370 Otto-Hahn-Ring 6 1371 Munich, Bavaria 81739 1372 Germany 1374 Email: Hannes.Tschofenig@siemens.com 1375 URI: http://www.tschofenig.com 1377 Intellectual Property Statement 1379 The IETF takes no position regarding the validity or scope of any 1380 Intellectual Property Rights or other rights that might be claimed to 1381 pertain to the implementation or use of the technology described in 1382 this document or the extent to which any license under such rights 1383 might or might not be available; nor does it represent that it has 1384 made any independent effort to identify any such rights. Information 1385 on the procedures with respect to rights in RFC documents can be 1386 found in BCP 78 and BCP 79. 1388 Copies of IPR disclosures made to the IETF Secretariat and any 1389 assurances of licenses to be made available, or the result of an 1390 attempt made to obtain a general license or permission for the use of 1391 such proprietary rights by implementers or users of this 1392 specification can be obtained from the IETF on-line IPR repository at 1393 http://www.ietf.org/ipr. 1395 The IETF invites any interested party to bring to its attention any 1396 copyrights, patents or patent applications, or other proprietary 1397 rights that may cover technology that may be required to implement 1398 this standard. Please address the information to the IETF at 1399 ietf-ipr@ietf.org. 1401 Disclaimer of Validity 1403 This document and the information contained herein are provided on an 1404 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1405 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1406 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1407 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1408 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1409 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1411 Copyright Statement 1413 Copyright (C) The Internet Society (2005). This document is subject 1414 to the rights, licenses and restrictions contained in BCP 78, and 1415 except as set forth therein, the authors retain all their rights. 1417 Acknowledgment 1419 Funding for the RFC Editor function is currently provided by the 1420 Internet Society.