idnits 2.17.1 draft-ietf-mobike-design-04.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 1296. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1273. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1280. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1286. ** 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 641: '...IKEv2 packets to MUST NOT (it would br...' RFC 2119 keyword, line 904: '...optional. Nodes MAY also perform thes...' RFC 2119 keyword, line 989: '...enabled the node not behind NAT SHOULD...' RFC 2119 keyword, line 1003: '... updating of NAT-T to MUST NOT in case...' RFC 2119 keyword, line 1014: '... to MUST NOT....' 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 (October 21, 2005) is 6759 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-tsvwg-addip-sctp' is defined on line 1201, but no explicit reference was found in the text == Unused Reference: 'I-D.dupont-ikev2-addrmgmt' is defined on line 1207, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-ipv6-unique-local-addr' is defined on line 1221, 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-12 == Outdated reference: A later version (-08) exists of draft-dupont-ikev2-addrmgmt-07 == 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) Summary: 4 errors (**), 0 flaws (~~), 10 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: April 24, 2006 Siemens 6 October 21, 2005 8 Design of the MOBIKE Protocol 9 draft-ietf-mobike-design-04.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 April 24, 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 . . . . . . . . . . . . . . . . 10 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 NAT and back . . . . . . . . . . . . 16 75 5.2.4. Responder behind NAT . . . . . . . . . . . . . . . . . 17 76 5.2.5. NAT Prevention . . . . . . . . . . . . . . . . . . . . 17 77 5.2.6. Suggested approach . . . . . . . . . . . . . . . . . . 17 78 5.3. Scope of SA changes . . . . . . . . . . . . . . . . . . . 18 79 5.4. Zero address set functionality . . . . . . . . . . . . . . 19 80 5.5. Return routability test . . . . . . . . . . . . . . . . . 19 81 5.5.1. Employing MOBIKE results in other protocols . . . . . 22 82 5.5.2. Suggested approach . . . . . . . . . . . . . . . . . . 23 83 5.6. IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 23 84 6. Protocol detail issues . . . . . . . . . . . . . . . . . . . . 24 85 6.1. Indicating support for mobike . . . . . . . . . . . . . . 24 86 6.2. Path Testing and Window size . . . . . . . . . . . . . . . 25 87 6.3. Message presentation . . . . . . . . . . . . . . . . . . . 26 88 6.4. Updating address list . . . . . . . . . . . . . . . . . . 27 89 7. Security Considerations . . . . . . . . . . . . . . . . . . . 28 90 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 91 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 92 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 93 10.1. Normative references . . . . . . . . . . . . . . . . . . . 31 94 10.2. Informative References . . . . . . . . . . . . . . . . . . 31 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 34 96 Intellectual Property and Copyright Statements . . . . . . . . . . 35 98 1. Introduction 100 The purpose of IKEv2 is to mutually authenticate two hosts, establish 101 one or more IPsec Security Associations (SAs) between them, and 102 subsequently manage these SAs (for example, by rekeying or deleting). 103 IKEv2 enables the hosts to share information that is relevant to both 104 the usage of the cryptographic algorithms that should be employed 105 (e.g., parameters required by cryptographic algorithms and session 106 keys) and to the usage of local security policies, such as 107 information about the traffic that should experience protection. 109 IKEv2 assumes that an IKE SA is created implicitly between the IP 110 address pair that is used during the protocol execution when 111 establishing the IKEv2 SA. This means that, in each host, only one 112 IP address pair is stored for the IKEv2 SA as part of a single IKEv2 113 protocol session, and, for tunnel mode SAs, the hosts places this 114 single pair in the outer IP headers. Existing documents make no 115 provision to change this pair after an IKE SA is created. 117 There are scenarios where one or both of the IP addresses of this 118 pair may change during an IPsec session. In principle, the IKE SA 119 and all corresponding IPsec SAs could be re-established after the IP 120 address has changed. However, this can be problematic, as the device 121 might be too slow for this task. Moreover, manual user interaction 122 (for example when using SecurID cards) might be required as part of 123 the IKEv2 authentication procedure. Therefore, an automatic 124 mechanism is need that updates the IP addresses associated with the 125 IKE SA and the IPsec SAs. MOBIKE provides such a mechanism. 127 The work of the MOBIKE working group and therefore this document is 128 based on the assumption that the mobility and multi-homing extensions 129 are developed for IKEv2 [I-D.ietf-ipsec-ikev2]. As IKEv2 is built on 130 the architecture described in RFC2401bis [I-D.ietf-ipsec-rfc2401bis], 131 all protocols developed within the MOBIKE working group must be 132 compatible with both IKEv2 and the architecture described in 133 RFC2401bis. The document does not aim to neither provide support 134 IKEv1 [RFC2409] nor the architecture described in RFC2401 [RFC2401]. 136 This document is structured as follows. After introducing some 137 important terms in Section 2 a number of relevant usage scenarios are 138 discussed in Section 3. The next section Section 4 will describe the 139 scope of the MOBIKE protocol. Finally, Section 5 discusses design 140 considerations affecting the MOBIKE protocol. The document concludes 141 in Section 7 with security considerations. 143 2. Terminology 145 This section introduces the terminology that is used in this 146 document. 148 Peer: 150 A peer is an IKEv2 endpoint. In addition, a peer implements the 151 MOBIKE extensions, as defined in this and related documents. 153 Available address: 155 An address is said to be available if the following conditions are 156 met: 158 * The address has been assigned to an interface. 160 * If the address is an IPv6 address, we additionally require (a) 161 that the address is valid as defined in RFC 2461 [RFC2461], and 162 (b) that the address is not tentative as defined in RFC 2462 163 [RFC2462]. In other words, we require the address assignment 164 to be complete. 166 Note that this explicitly allows an address to be optimistic as 167 defined in [I-D.ietf-ipv6-optimistic-dad]. 169 * If the address is an IPv6 address, it is a global unicast or 170 unique site-local address, as defined in [I-D.ietf-ipv6-unique- 171 local-addr]. That is, it is not an IPv6 link-local. Where 172 IPv4 is considered, it is not an RFC 1918 [RFC1918] address. 174 * The address and interface is acceptable for sending and 175 receiving traffic according to a local policy. 177 This definition is taken from [I-D.arkko-multi6dt-failure- 178 detection]. 180 Locally Operational Address: 182 An address is said to be locally operational if it is available 183 and its use is locally known to be possible and permitted. This 184 definition is taken from [I-D.arkko-multi6dt-failure-detection]. 186 Operational address pair: 188 A pair of operational addresses are said to be an operational 189 address pair, if and only if bidirectional connectivity can be 190 shown between the two addresses. Note that sometimes it is 191 necessary to consider connectivity on a per-flow level between two 192 endpoints needs to be tested. This differentiation might be 193 necessary to address certain Network Address Translation types or 194 specific firewalls. This definition is taken from [I-D.arkko- 195 multi6dt-failure-detection] and adapted for the MOBIKE context. 196 Although it is possible to further differentiate unidirectional 197 and bidirectional operational address pairs, only bidirectional 198 connectivity is relevant to this document and unidirectional 199 connectivity is out of scope. 201 Path: 203 The sequence of routers traversed by the MOBIKE and IPsec packets 204 exchanged between the two peers. Note that this path may be 205 affected not only by the involved source and destination IP 206 addresses, but also by the transport protocol. Since MOBIKE and 207 IPsec packets have a different appearance on the wire they might 208 be routed along a different path, for example by load balancers. 209 This definition is taken from [RFC2960] and adapted to the MOBIKE 210 context. 212 Primary Path: 214 The sequence of routers traversed by an IP packet that carries the 215 default source and destination addresses is said to be the Primary 216 Path. This definition is taken from [RFC2960] and adapted to the 217 MOBIKE context. 219 Preferred Address: 221 The IP address of a peer to which MOBIKE and IPsec traffic should 222 be sent by default. A given peer has only one active preferred 223 address at a given point in time, except for the small time period 224 where it switches from an old to a new preferred address. This 225 definition is taken from [I-D.ietf-hip-mm] and adapted to the 226 MOBIKE context. 228 Peer Address Set: 230 We denote the two peers of a MOBIKE session by peer A and peer B. 231 A peer address set is the subset of locally operational addresses 232 of peer A that is sent to peer B. A policy available at peer A 233 indicates which addresses are included in the peer address set. 234 Such a policy might be created either manually or automatically 235 through interaction with other mechanisms that indicate new 236 available addresses. 238 Terminology regarding NAT types (e.g. Full Cone, Restricted Cone, 239 Port Restricted Cone and Symmetric), can be found in Section 5 of 240 [RFC3489]. For mobility related terminology (e.g. Make-before-break 241 or Break-before-make) see [RFC3753]. 243 3. Scenarios 245 In this section we discuss three typical usage scenarios for the 246 MOBIKE protocol. 248 3.1. Mobility Scenario 250 Figure 1 shows a break-before-make mobility scenario where a mobile 251 node changes its point of network attachment. Prior to the change, 252 the mobile node had established an IPsec connection with a security 253 gateway which offered, for example, access to a corporate network. 254 The IKEv2 exchange that facilitated the set up of the IPsec SA(s) 255 took place over the path labeled as 'old path'. The involved packets 256 carried the MN's "old" IP address and were forwarded by the "old" 257 access router (OAR) to the security gateway (GW). 259 When the MN changes its point of network attachment, it obtains a new 260 IP address using stateful address configuration techniques or via the 261 stateless address autoconfiguration mechanism. The goal of MOBIKE, 262 in this scenario, is to enable the MN and the GW to continue using 263 the existing SAs and to avoid setting up a new IKE SA. A protocol 264 exchange, denoted by 'MOBIKE Address Update', enables the peers to 265 update their state as necessary. 267 Note that in a break-before-make scenario the MN obtains the new IP 268 address after it can no longer be reached at the old IP address. In 269 a make-before-break scenario, the MN is, for a given period of time, 270 reachable at both the old and the new IP address. MOBIKE should work 271 in both the above scenarios. 273 (Initial IKEv2 Exchange) 274 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v 275 Old IP +--+ +---+ v 276 address |MN|------> |OAR| -------------V v 277 +--+ +---+ Old path V v 278 . +----+ v>>>>> +--+ 279 .move | R | -------> |GW| 280 . | | >>>>> | | 281 v +----+ ^ +--+ 282 +--+ +---+ New path ^ ^ 283 New IP |MN|------> |NAR|--------------^ ^ 284 address +--+ +---+ ^ 285 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ 286 (MOBIKE Address Update) 288 ---> = Path taken by data packets 289 >>>> = Signaling traffic (IKEv2 and MOBIKE) 290 ...> = End host movement 292 Figure 1: Mobility Scenario 294 3.2. Multihoming Scenario 296 Another MOBIKE usage scenario is depicted in Figure 2. In this 297 scenario, the MOBIKE peers are equipped with multiple interfaces (and 298 multiple IP addresses). Peer A has two interface cards with two IP 299 addresses, IP_A1 and IP_A2, and peer B has two IP addresses, IP_B1 300 and IP_B2. Each peer selects one of its IP addresses as the 301 preferred address which is used for subsequent communication. 302 Various reasons, (e.g hardware or network link failures), may require 303 a peer to switch from one interface to another. 305 +------------+ +------------+ 306 | Peer A | *~~~~~~~~~* | Peer B | 307 | |>>>>>>>>>> * Network *>>>>>>>>>>| | 308 | IP_A1 +-------->+ +--------->+ IP_B1 | 309 | | | | | | 310 | IP_A2 +********>+ +*********>+ IP_B2 | 311 | | * * | | 312 +------------+ *~~~~~~~~~* +------------+ 314 ---> = Path taken by data packets 315 >>>> = Signaling traffic (IKEv2 and MOBIKE) 316 ***> = Potential future path through the network 317 (if Peer A and Peer B change their preferred 318 address) 320 Figure 2: Multihoming Scenario 321 Note that MOBIKE does not aim to support load balancing between 322 multiple IP addresses. That is, each peer uses only one of the 323 available IP addresses at a given point in time. 325 3.3. Multihomed Laptop Scenario 327 The third scenario we consider is about a laptop, which has multiple 328 interface cards and therefore several ways to connect to the network. 329 It may for example have a fixed Ethernet card, a WLAN interface, a 330 GPRS adaptor, a Bluetooth interface or USB hardware. Not all 331 interfaces are connected to the network at all times for a number of 332 reasons (e.g., cost, availability of certain link layer technologies, 333 user convenience). The mechanism that determines which interfaces 334 are connected to the network at any given point in time is outside 335 the scope of the MOBIKE protocol and, as such, this document. 336 However, as the laptop changes its point of attachment to the 337 network, the set of IP addresses under which the laptop is reachable, 338 changes too. 340 Even if IP addresses change due to interface switching or mobility, 341 the IP address obtained via the configuration payloads within IKEv2 342 remain unaffected. The IP address obtained via the IKEv2 343 configuration payloads allow the configuration of the inner IP 344 address of the IPsec tunnel. As such, applications might not detect 345 any change at all. 347 4. Scope of MOBIKE 349 Getting mobility and multihoming actually working requires lots of 350 different components working together, including coordinating things 351 and making consistent decisions in several link layers, the IP 352 layers, different mobility mechanisms in those layers, and IPsec/IKE. 353 Most of those aspects are beyond the scope of MOBIKE: The MOBIKE 354 focuses on what two peers need to agree in IKEv2 level (like new 355 message formats and some aspects of their processing) for 356 interoperability. 358 The MOBIKE is not trying to be full mobility protocol; there is no 359 support for simultaneous movement or rendezvous mechanism, and there 360 is no support for route optimization etc. This current design 361 document focuses mainly on the tunnel mode, everything going inside 362 the tunnel is unaffected by the changes in the tunnel header IP 363 address, and this is the mobility feature provided by the MOBIKE. 364 I.e. the applications running through the MOBIKE IPsec tunnel cannot 365 even detect the movement, their IP address etc stay constant. 367 A MOBIKE protocol should be able to perform the following operations: 369 o inform the other peer about the peer address set 371 o inform the other peer about the preferred address 373 o test connectivity along a path and thereby to detect an outage 374 situation 376 o change the preferred address 378 o change the peer address set 380 o Ability to deal with Network Address Translation devices 382 Figure 3 shows an example protocol interaction between a pair of 383 MOBIKE peers. MOBIKE interacts with the IPsec engine using the 384 PF_KEY API [RFC2367]. Using this API, the MOBIKE daemon can create 385 entries in the Security Association (SAD) and Security Policy 386 Databases (SPD). The IPsec engine may also interact with IKEv2 and 387 MOBIKE daemon using this API. The content of the Security Policy and 388 Security Association Databases determines what traffic is protected 389 with IPsec in which fashion. MOBIKE, on the other hand, receives 390 information from a number of sources that may run both in kernel-mode 391 and in user-mode. Information relevant for MOBIKE might be stored in 392 a database. The contents of such a database, along with the 393 occurrence of events of which the MOBIKE process is notified, form 394 the basis on which MOBIKE decides regarding the set of available 395 addresses, the peer address set, and the preferred address. Policies 396 may also affect the selection process. 398 The a peer address set and the preferred address needs to be 399 available to the other peer. In order to address certain failure 400 cases, MOBIKE should perform connectivity tests between the peers 401 (potentially over a number of different paths). Although a number of 402 address pairs may be available for such tests, the most important is 403 the pair (source address, destination address) of the primary path. 404 This is because this pair is selected for sending and receiving 405 MOBIKE signaling and IPsec traffic. If a problem along this primary 406 path is detected (e.g., due to a router failure) it is necessary to 407 switch to a new primary path. In order to be able to do so quickly, 408 it may be helpful to perform connectivity tests of other paths 409 periodically. Such a technique would also help in identifying 410 previously disconnected paths that become operational. 412 +-------------+ +---------+ 413 |User-space | | MOBIKE | 414 |Protocols | +-->>| Daemon | 415 |relevant for | | | | 416 |MOBIKE | | +---------+ 417 +-------------+ | ^ 418 User Space ^ | ^ 419 ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ 420 Kernel Space v | v 421 _______ | v 422 +-------------+ / \ | +--------------+ 423 |Routing | / Trigger \ | | IPsec | 424 |Protocols |<<-->>| Database |<<-+ +>+ Engine | 425 | | \ / | | (+Databases) | 426 +-----+---+---+ \_______/ | +------+-------+ 427 ^ ^ ^ | ^ 428 | +---------------+-------------+--------+-----+ 429 | v | | | 430 | +-------------+ | | | 431 I | |Kernel-space | | | | I 432 n | +-------->+Protocols +<----+-----+ | | n 433 t v v |relevant for | | v v v t 434 e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e 435 r | Input | +-------------+ | | Outgoing | r 436 f | Packet +<--------------------------+ | Interface | f 437 ==a>|Processing|===============================| Processing |=a> 438 c | | | | c 439 e +----------+ +------------+ e 440 s s 441 ===> = IP packets arriving/leaving a MOBIKE node 442 <-> = control and configuration operations 444 Figure 3: Framework 446 Please note that Figure 3 illustrates an example of how a MOBIKE 447 implementation could work. Hence, it serves illustrative purposes 448 only. 450 Extensions of the PF_KEY interface required by MOBIKE are also within 451 the scope of the working group. Finally, certain optimizations for 452 wireless environments are also covered. 454 5. Design Considerations 456 This section discusses aspects affecting the design of the MOBIKE 457 protocol. 459 5.1. Choosing addresses 461 One of the core aspects of the MOBIKE protocol is the selection of 462 the address for the IPsec packets we send. Choosing addresses for 463 the IKEv2 request is somewhat separate problem: in many cases, they 464 will be the same (and in some design choice they will always be the 465 same). 467 5.1.1. Inputs and triggers 469 How the address changes are triggered are largerly beyond the scope 470 of MOBIKE. The triggers can include e.g. changes in the set of 471 addresses, various link-layer indications, failing dead peer 472 detection, and changes in preferences and policies. Furthermore, 473 there may be less reliable sources of information (such as lack of 474 IPsec packets and ICMP packets) that do not trigger any changes 475 directly, but rather cause DPD to be performed sooner than it 476 otherwise would have been (and if that DPD fails, that may trigger 477 changing of addresses). 479 These triggers are largerly the same as for, e.g. Mobile IP, and are 480 beyond the scope of MOBIKE. 482 5.1.2. Connectivity 484 There can be two kind of "failures" in the connectivity; local or 485 middle. Local failure is a property of an address (interface), while 486 the failures in the middle is property of address pair. MOBIKE does 487 not assume full connectivity, but it does not try to use 488 unidirectional address pairs (multi6 has discussed about how to deal 489 with unidirectional paths). Unidirectional address pairs is 490 complicated issue, and supporting it would require abandoning the 491 principle that you always send the IKEv2 reply to the address the 492 request came from. Because of that MOBIKE decided to deal only with 493 bidirectional address pairs. It does consider unidirectional address 494 pairs as broken, and not use them, but the connection will not break 495 even if unidirectional address pairs are present, provided there is 496 at least one bidirectional address pair it can use. 498 Note, that MOBIKE is not really concerned about the actual path used, 499 it cannot even detect if some path is unidirectional, if the same 500 address pair has some other unidirectional path back. Ingress 501 filters might still cause such path pairs to be unusable, and in that 502 case MOBIKE will detect that there is no connection between address 503 pair. 505 In a sense having both IPv4 and IPv6 address is basically a case of 506 partial connectivity (putting both IPv4 and IPv6 address in the same 507 IP header does not work). The main difference is that it is known 508 beforehand, and there is no need to discover that IPv4/IPv6 509 combination does not work. 511 5.1.3. Discovering connectivity 513 To detect connectivity, i.e failures in the middle, MOBIKE needs to 514 have some kind of probe which it can send to the other end and get a 515 reply back to that. If it will see the reply it knows the connection 516 works, if it does not see the reply after multiple retransmissions it 517 may assume that the address pair tested is broken. 519 The connectivity tests do require to take in to account the 520 congestion problems, because the connection failure might be because 521 of congestion, and the MOBIKE should not make it worse by sending 522 lots of probe packets. 524 5.1.4. Decision making 526 One of the core decisions to the MOBIKE protocol is to who makes the 527 decisions to fix situations, i.e. symmetry in decision making vs. 528 asymmetry in decisions. Symmetric decision making may cause the 529 different peers to make different decisions, thus causing asymmetric 530 upstream/downstream traffic. In mobility case it is desirable that 531 the mobile peer can move both upstream and downstream traffic to some 532 particular interface, and this requires asymmetric decision making. 534 Working with stateful packet filters and NATs is easier if same 535 address pair is used in both upstream and downstream directions. 536 Also in common cases only the peer behind NAT can actually do actions 537 to recover from the connectivity problems, as it might be that the 538 other peer is not able to initiate any connections to the peer behind 539 NAT. 541 5.1.5. Suggested approach 543 Because of those issues listed above, the MOBIKE protocol decided to 544 select method where the initiator will decide which addresses are 545 used. This has the benefits that it makes one peer to decide, thus 546 we cannot end up in the asymmetric decisions, and it also works best 547 with NATs, as the initiator is the most common peer to be behind NAT, 548 and thus is the only peer which can recover in those cases. 550 5.2. NAT Traversal 552 5.2.1. Background and constraints 554 Another core aspect of the MOBIKE was the co-operation and working 555 with NATs. In IKEv2 the tunnel header IP addresses are not sent 556 inside the IKEv2 payloads, and thus there is no need to do unilateral 557 self-address fixing (UNSAF). The tunnel header IP addresses are 558 taken from the outer IP header of the IKE packets, thus they are 559 already processed by the NAT. 561 The NAT detection payloads are used to detect if the addresses in the 562 IP header were modified by a NAT between the peers, and that enables 563 UDP encapsulation of ESP packets if needed. MOBIKE is not to change 564 how IKEv2 NAT-T works, in particular, any kind of UNSAF or explicit 565 interaction with NATs (e.g. midcom or nsis natfw) are beyond the 566 scope. The MOBIKE will need to define how MOBIKE and NAT-T are used 567 together. 569 The NAT-T support should also be optional, i.e. if the IKEv2 570 implementation does not implement NAT-T, since it is not required in 571 some particular environment, implementing MOBIKE should not require 572 adding support for NAT-T as well. 574 The property of being behind NAT is actually property of the address 575 pair, thus one peer can have multiple IP-addresses and some of those 576 might be behind NAT and some might not be behind NAT. 578 5.2.2. Fundamental restrictions 580 There are some cases which cannot be made work with the restrictions 581 provided by the MOBIKE charter. One of those cases is the case where 582 the party "outside" a symmetric NAT changes its address to something 583 not known by the the other peer (and old address has stopped 584 working). It cannot send a packet containing the new addresses to 585 the peer, because the NAT does not contain the necessary state. 586 Furthermore, since the party behind the NAT does not know the new IP 587 address, it cannot cause the NAT state to be created. 589 This case could be solved using some rendezvous mechanism outside 590 IKEv2, but that is beyond the scope of MOBIKE. 592 5.2.3. Moving to behind NAT and back 594 MOBIKE provides mechanism where peer not initially behind the NAT, 595 can move to behind NAT, when new address pair is selected. MOBIKE 596 does not need to detect when someone attach NAT to the currently 597 working address pair, i.e. the NAT detection is only done when MOBIKE 598 changes the address pair used. 600 Similarly the MOBIKE provides mechanism to move from the address pair 601 having NAT to the address pair not having NAT. 603 As we only use one address pair at time, effectively MOBIKE peer is 604 either behind NAT or not behind NAT, but each address change can 605 change the situation. Because of this and because initiator always 606 chooses the addresses it is enough to send keepalive packets only to 607 that one address pair. 609 5.2.4. Responder behind NAT 611 MOBIKE can work in cases where the responder is behind static NAT, 612 but in that case the initiator needs to know all possible addresses 613 where the responder can move to, i.e. responder cannot move to the 614 address which is not known by the initiator. 616 If the responder is behind NAPT then it might need to communicate 617 with the NAT to create mapping so initiator can connect to it. Those 618 external hole punching mechanisms are beyond the scope of MOBIKE. 620 In case the responder is behind NAPT then also finding the port 621 numbers used by the responder, is outside the scope of MOBIKE. 623 5.2.5. NAT Prevention 625 One new feature created by the MOBIKE, is the NAT prevention, i.e. if 626 we detect NAT between the peers, we do not allow that address pair to 627 be used. This can be used to protect IP-addresses in cases where it 628 is known by the configuration that there is no NAT between the nodes 629 (for example IPv6, or fixed site-to-site VPN). This gives extra 630 protection against 3rd party bombing attacks (attacker cannot divert 631 the traffic to some 3rd party). This feature means that we 632 authenticate the IP-address and detect if they were changed. As this 633 is done on purpose to break the connectivity if NAT is detect, and 634 decided by the configuration, there is no need to do UNSAF 635 processing. 637 5.2.6. Suggested approach 639 The working group decided that MOBIKE uses NAT-T mechanisms from the 640 IKEv2 protocol as much as possible, but decided to change the dynamic 641 address update for IKEv2 packets to MUST NOT (it would break path 642 testing using IKEv2 packets). Working group also decided to only 643 send keepalives to the current address pair. 645 5.3. Scope of SA changes 647 Most sections of this document discuss design considerations for 648 updating and maintaining addresses in the database entries that 649 relate to an IKE-SA. However, changing the preferred address also 650 affects the entries of the IPsec SA database. The outer tunnel 651 header addresses (source and destination IP addresses) need to be 652 modified according to the primary path to allow the IPsec protected 653 data traffic to travel along the same path as the MOBIKE packets (if 654 we only consider the IP header information). If the MOBIKE messages 655 and the IPsec protected data traffic travel along a different path 656 then NAT handling is severely complicated. 658 The basic question is then how the IPsec SAs are changed to use the 659 new address pair (the same address pair as the MOBIKE signaling 660 traffic). One option is that when the IKE SA address is changed then 661 automatically all IPsec SAs associated with it are moved along with 662 it to new address pair. Another option is to have a separate 663 exchange to move the IPsec SAs separately. 665 If IPsec SAs should be updated separately then a more efficient 666 format than the notification payload is needed to preserve bandwidth. 667 A notification payload can only store one SPI per payload. A 668 separate payload could have list of IPsec SA SPIs and new preferred 669 address. If there is a large number of IPsec SAs, those payloads can 670 be quite large unless ranges of SPI values are supported. If we 671 automatically move all IPsec SAs when the IKE SA moves, then we only 672 need to keep track which IKE SA was used to create the IPsec SA, and 673 fetch the IP addresses from IKE SA, i.e. no need to store IP 674 addresses per IPsec SA. Note that IKEv2 [I-D.ietf-ipsec-ikev2] 675 already requires implementations to keep track which IPsec SAs are 676 created using which IKE SA. 678 If we do allow each IPsec SA address set to be updated separately, 679 then we can support scenarios, where the machine has fast and/or 680 cheap connections and slow and/or expensive connections, and it wants 681 to allow moving some of the SAs to the slower and/or more expensive 682 connection, and prevent the move, for example, of the news video 683 stream from the WLAN to the GPRS link. 685 On the other hand, even if we tie the IKE SA update to the IPsec SA 686 update, then we can create separate IKE SAs for this scenario, e.g., 687 we create one IKE SA which have both links as endpoints, and it is 688 used for important traffic, and then we create another IKE SA which 689 have only the fast and/or cheap connection, which is then used for 690 that kind of bulk traffic. 692 MOBIKE protocol decided to move all IPsec SAs implicitly when the IKE 693 SA address pair changes. If more granular handling of the IPsec SA 694 is required, then multiple IKE SAs can be created one for each set of 695 IPsec SAs needed. 697 5.4. Zero address set functionality 699 One of the features which is potentially useful is for the peer to 700 announce that it will now disconnect for some time, i.e. it will not 701 be reachable at all. For instance, a laptop might go to suspend 702 mode. In this case the it could send address notification with zero 703 new addresses, which means that it will not have any valid addresses 704 anymore. The responder of that kind of notification would then 705 acknowledge that, and could then temporarily disable all SAs and 706 therefore stop sending traffic. If any of the SAs gets any packets 707 they are simply dropped. This could also include some kind of ACK 708 spoofing to keep the TCP/IP sessions alive (or simply set the TCP/IP 709 keepalives and timeouts large enough not to cause problems), or it 710 could simply be left to the applications, e.g. allow TCP/IP sessions 711 to notice the link is broken. 713 The local policy could then indicate how long the peer should allow 714 remote peers to remain disconnected. 716 From a technical point of view this feature addresses two aspects: 718 o There is no need to transmit IPsec data traffic. IPsec protected 719 data can be dropped which saves bandwidth. This does not provide 720 a functional benefit, i.e., nothing breaks if this feature is not 721 provided. 723 o MOBIKE signaling messages are also ignored. The IKE-SA must not 724 be deleted and the suspend functionality (realized with the zero 725 address set) may require the IKE-SA to be tagged with a lifetime 726 value since the IKE-SA should not be kept in alive for an 727 undefined period of time. Note that IKEv2 does not require that 728 the IKE-SA has a lifetime associated with it. In order to prevent 729 the IKE-SA from being deleted the dead-peer detection mechanism 730 needs to be suspended as well. 732 Due to the fact that this extension could be complicated and there 733 was no clear need for it, a first version of the MOBIKE protocol will 734 not provide this feature. 736 5.5. Return routability test 738 Changing the preferred address and subsequently using it for 739 communication is associated with an authorization decision: Is a peer 740 allowed to use this address? Does this peer own this address? Two 741 mechanisms have been proposed in the past to allow a peer to 742 determine the answer to this question: 744 o The addresses a peer is using are part of a certificate. 745 [RFC3554] introduced this approach. If the other peer is, for 746 example, a security gateway with a limited set of fixed IP 747 addresses, then the security gateway may have a certificate with 748 all the IP addresses appear in the certificate. 750 o A return routability check is performed by the remote peer before 751 the address is updated in that peer's Security Association 752 Database. This is done in order provide a certain degree of 753 confidence to the remote peer that local peer is reachable at the 754 indicated address. 756 Without taking an authorization decision a malicious peer can 757 redirect traffic towards a third party or a blackhole. 759 A MOBIKE peer should not use an IP addressed provided by another 760 MOBIKE peer as a primary address without computing the authorization 761 decision. If the addresses are part of the certificate then it is 762 not necessary to execute the weaker return-routability test. The 763 return-routability test is a form of authorization check, although it 764 provides weaker guarantees then the inclusion of the IP address as 765 part of a certificate. If multiple addresses are communicated to the 766 remote peer then some of these addresses may be already verified even 767 if the primary address is still operational. 769 Another option is to use the [I-D.dupont-mipv6-3bombing] approach 770 which suggests to perform a return routability test only when an 771 address update needs to be sent from some address other than the 772 indicated preferred address. 774 Finally it would be possible not to execute return routability checks 775 at all. In case of indirect change notifications we only move to the 776 new preferred address after successful dead-peer detection (i.e., a 777 response to a DPD test) on the new address, which is already a return 778 routability check. With a direct notification the authenticated peer 779 may have provided an authenticated IP address. Thus it is would be 780 possible to simply trust the MOBIKE peer to provide a proper IP 781 address. There is no way an adversary can successfully launch an 782 attack by injecting faked addresses since it does not know the IKE SA 783 and the corresponding keying material. A protection against an 784 internal attacker, i.e. the authenticated peer forwarding its traffic 785 to the new address, is not provided. This might be an issue when 786 extensions are added to IKEv2 that do not require authentication of 787 end points (e.g., opportunistic security using anonymous Diffie- 788 Hellman). On the other hand we know the identity of the peer in that 789 case. 791 There is also a policy issue when to schedule a return routability 792 test. Before moving traffic? After moving traffic? 794 The basic format of the return routability check could be similar to 795 dead-peer detection. There are potential attacks if a return 796 routability check does not include some kind of nonce. The valid end 797 point could send an address update notification for a third party, 798 trying to get all the traffic to be sent there, causing a denial of 799 service attack. If the return routability checks does not contain 800 any cookies or other random information not known to the other end, 801 then that valid node could reply to the return routability checks 802 even when it cannot see the request. This might cause a peer to move 803 the traffic to a location where the original recipient cannot be 804 reached. 806 The IKEv2 NAT-T mechanism does not perform return routability checks. 807 It simply uses the last seen source IP address used by the other peer 808 as the destination address to send response packets. An adversary 809 can change those IP addresses, and can cause the response packets to 810 be sent to wrong IP address. The situation is self-fixing when the 811 adversary is no longer able to modify packets and the first packet 812 with an unmodified IP address reaches the other peer. Mobility 813 environments make this attack more difficult for an adversary since 814 it requires the adversary to be located somewhere on the individual 815 paths ({CoA1, ..., CoAn} towards the destination IP address) have a 816 shared path or if the adversary is located near the MOBIKE client 817 then it needs to follow the user mobility patterns. With IKEv2 818 NAT-T, the genuine client can cause third party bombing by 819 redirecting all the traffic pointed to him to third party. As the 820 MOBIKE protocol tries to provide equal or better security than IKEv2 821 NAT-T mechanism it should protect against these attacks. 823 There may be return routability information available from the other 824 parts of the system too (as shown in Figure 3), but the checks done 825 may have a different quality. There are multiple levels for return 826 routability checks: 828 o None, no tests 830 o A party willing to answer the return routability check is located 831 along the path to the claimed address. This is the basic form of 832 return routability test. 834 o There is an answer from the tested address, and that answer was 835 authenticated, integrity and replay protected. 837 o There was an authenticated, integrity and replay protected answer 838 from the peer, but it is not guaranteed to originate at the tested 839 address or path to it (because the peer can construct a response 840 without seeing the request). 842 The return routability checks do not protect against 3rd party 843 bombing if the attacker is along the path, as the attacker can 844 forward the return routability checks to the real peer (even if those 845 packets are cryptographically authenticated). 847 If the address to be tested is carried inside the MOBIKE payload, 848 then the adversary cannot forward packets. Thus 3rd party bombings 849 are prevented. 851 If the reply packet can be constructed without seeing the request 852 packet (for example, if there is no nonce, challenge or similar 853 mechanism to show liveness), then the genuine peer can cause 3rd 854 party bombing, by replying to those requests without seeing them at 855 all. 857 Other levels might only provide a guarantee that there is a node at 858 the IP address which replied to the request. There is no indication 859 as to whether or not the reply is fresh, and whether or not the 860 request may have been transmitted from a different source address. 862 5.5.1. Employing MOBIKE results in other protocols 864 If MOBIKE has learned about new locations or verified the validity of 865 a remote address through a return routability check, can this 866 information be useful for other protocols? 868 When considering the basic MOBIKE VPN scenario, the answer is no. 869 Transport and application layer protocols running inside the VPN 870 tunnel are unaware of the outer addresses or their status. 872 Similarly, IP layer tunnel termination at a gateway rather than a 873 host endpoint limits the benefits for "other protocols" that could be 874 informed -- all application protocols at the other side are unaware 875 of IPsec, IKE, or MOBIKE. 877 However, it is conceivable that future uses or extensions of the 878 MOBIKE protocol make such information distribution useful. For 879 instance, if transport mode MOBIKE and SCTP were made to work 880 together, it would potentially be useful for SCTP to learn about the 881 new addresses at the same time as MOBIKE. Similarly, various IP 882 layer mechanisms may make use of the fact that a return routability 883 test of a specific type has been performed. However, care should be 884 exercised in all these situations. 886 [I-D.crocker-celp] discusses the use of common locator information 887 pools in a IPv6 multi-homing context; it assumed that both transport 888 and IP layer solutions are be used in order to support multi-homing, 889 and that it would be beneficial for different protocols to coordinate 890 their results in some way, for instance by sharing throughput 891 information of address pairs. This may apply to MOBIKE as well, 892 assuming it co-exists with non-IPsec protocols that are faced with 893 the same or similar multi-homing choices. 895 Nevertheless, all of this is outside the scope of current MOBIKE base 896 protocol design and may be addressed in future work. 898 5.5.2. Suggested approach 900 MOBIKE protocol selected to use IKEv2 INFORMATIONAL exchanges as a 901 return routability tests, but added random cookie there to prevent 902 redirections done by authenticated attacker. Return routability 903 tests are done by default before moving the traffic. However these 904 tests are optional. Nodes MAY also perform these tests upon their 905 own initiative at other times. 907 It is worth noting that the return routability test in MOBIKE is not 908 he same as return routability test in MIP6: The MIP6 WG decided that 909 it is not necessary to do return routability tests between the mobile 910 node and the home agent at all. 912 5.6. IPsec Tunnel or Transport Mode 914 Current MOBIKE design is focused only on the VPN type usage and 915 tunnel mode. Transport mode behavior would also be useful, but will 916 be discussed in future documents. 918 6. Protocol detail issues 920 6.1. Indicating support for mobike 922 In order for MOBIKE to function, both peers must implement the MOBIKE 923 extension of IKEv2. If one or none of the peers supports MOBIKE, 924 then, whenever an IP address changes, IKEv2 will have to be re-run in 925 order to create a new IKE SA and the respective IPsec SAs. In 926 MOBIKE, a peer needs to be confident that its address change messages 927 are understood by the other peer. If these messages are not 928 understood, it is possible that connectivity between the peers is 929 lost. 931 One way to ensure that a peer receives feedback on whether or not its 932 messages are understood by the other peer, is by using IKEv2 933 messaging for MOBIKE and to mark some messages as "critical". 934 According to the IKEv2 specification, such messages either have to be 935 understood by the receiver, or an error message has to be returned to 936 the sender. 938 A second way to ensure receipt of the above-mentioned feedback is by 939 using Vendor ID payloads that are exchanged during the initial IKEv2 940 exchange. These payloads would then indicate whether or not a given 941 peer supports the MOBIKE protocol. 943 A third approach would use the Notify payload which is also used for 944 NAT detection (via NAT_DETECTION_SOURCE_IP and 945 NAT_DETECTION_DESTINATION_IP payloads). 947 Both a Vendor ID and a Notify payload may be used to indicate the 948 support of certain extensions. 950 Note that a MOBIKE peer could also attempt to execute MOBIKE 951 opportunistically with the critical bit set when an address change 952 has occurred. The drawback of this approach is, however, that an 953 unnecessary message exchange is introduced. 955 Although Vendor ID payloads and Notifications are technically 956 equivalent, Notifications are already used in IKEv2 as a capability 957 negotiation mechanism. Hence, notification payloads are used in the 958 MOBIKE to indicate support of it. 960 Also as the information of the support of the MOBIKE is not needed 961 during the IKE_SA_INIT exchange, the indication of the support is 962 done inside the IKE_AUTH exchange. The reason for this is to need to 963 keep the IKE_SA_INIT messages as small as possible, so they do not 964 get fragmented. The idea is that responder can do stateless 965 processing of the first IKE_SA_INIT packet, and request cookie from 966 the other end if it is under attack. To mandate responder to be able 967 to reassemble initial IKE_SA_INIT packets would not allow fully 968 stateless processing of the initial IKE_SA_INIT packets. 970 6.2. Path Testing and Window size 972 As the IKEv2 has the window of outgoing messages, and the sender is 973 not allowed to violate that window (meaning, that if the window is 974 full, then he cannot send packets), it do cause some complications to 975 the path testing. The another complication created by IKEv2 is that 976 once the message is first time sent to the other end, it cannot be 977 modified in its future retransmissions. This makes it impossible to 978 know what packet actually reached first to the other end. We cannot 979 use IP headers to find out which packet reached the other end first, 980 as if responder gets retransmissions of the packet it has already 981 replied (and those replies might have been lost due unidirectional 982 address pair), it will retransmit the previous reply using the new 983 address pair of the request. Because of this it might be possible 984 that the responder has already used the IP-address information from 985 the header of the packet, and the reply packet ending up to the 986 initiator has different address pair. 988 Another complication comes from the NAT-T. The current IKEv2 989 document says that if NAT-T is enabled the node not behind NAT SHOULD 990 detect if the IP-address changes in the incoming authenticated 991 packets, and update the remote peers addresses accordingly. This 992 works fine with the NAT-T, but it causes some complications in the 993 MOBIKE, as it needs an ability to probe the another address pairs, 994 without breaking the old one. 996 One approach to fix those would be to add completely new protocol 997 that is outside the IKE SA message id limitations (window code), 998 outside identical retransmission requirements, and outside the 999 dynamic address updating of the NAT-T. 1001 Another approach is to make the protocol so that it does not violate 1002 window restrictions and does not require changing the packet is sent, 1003 and change the dynamic address updating of NAT-T to MUST NOT in case 1004 MOBIKE is used. To not to violate window restrictions, it means that 1005 the addresses of the currently ongoing exchange needs to be changed, 1006 to test different paths. To not to require changing the packet after 1007 it is first sent, requires that the protocol needs to restart from 1008 the beginning in case packet was retransmitted to different addresses 1009 (so sender does not know which packet was the one that responder got 1010 first, i.e. which IP-addresses it used). 1012 MOBIKE protocol decided to use normal IKEv2 exchanges for the path 1013 testing, and decided to change the dynamic address updating of NAT-T 1014 to MUST NOT. 1016 6.3. Message presentation 1018 The IP address change notifications can be sent either via an 1019 informational exchange already specified in the IKEv2, or via a 1020 MOBIKE specific message exchange. Using informational exchange has 1021 the main advantage that it is already specified in the IKEv2 and 1022 implementations incorporate the functionality already. 1024 Another question is the format of the address update notifications. 1025 The address update notifications can include multiple addresses, of 1026 which some may be IPv4 and some IPv6 addresses. The number of 1027 addresses is most likely going to be limited in typical environments 1028 (with less than 10 addresses). The format may need to indicate a 1029 preference value for each address. The format could either contain a 1030 preference number that determines the relative order of the 1031 addresses, or it could simply be ordered, according to preference, 1032 list of IP addresses. While two addresses can have the same 1033 preference value an ordered list avoids this situation. 1035 Even if load balancing is currently outside the scope of MOBIKE, 1036 future work might include support for it. The selected format needs 1037 to be flexible enough to include additional information (e.g. to 1038 enable load balancing). This may be realized with an reserved field, 1039 which can later be used to store additional information. As there 1040 may arise other information which may have to be tied to an address 1041 in the future, a reserved field seems like a prudent design in any 1042 case. 1044 There are two formats that place IP address lists into a message. 1045 One includes each IP address as separate payload (where the payload 1046 order indicates the preference value, or the payload itself might 1047 include the preference value), or we can put the IP address list as 1048 one payload to the exchange, and that one payload will then have 1049 internal format which includes the list of IP addresses. 1051 Having multiple payloads with each one having carrying one IP address 1052 makes the protocol probably easier to parse, as we can already use 1053 the normal IKEv2 payload parsing procedures. It also offers an easy 1054 way for the extensions, as the payload probably contains only the 1055 type of the IP address (or the type is encoded to the payload type), 1056 and the IP address itself, and as each payload already has length 1057 associated to it, we can detect if there is any extra data after the 1058 IP address. Some implementations might have problems parsing IKEv2 1059 payloads that are longer than a certain threshold, but if the sender 1060 sends them in the most preferred first, the receiver can only use the 1061 first addresses. 1063 Having all IP addresses in one big MOBIKE specified internal format 1064 provides more compact encoding, and keeps the MOBIKE implementation 1065 more concentrated to one module. It also avoids problems of packets 1066 arriving in an order different from what they were sent. 1068 Another choice is which type of payloads to use. IKEv2 already 1069 specifies a notify payload. It includes some extra fields (SPI size, 1070 SPI, protocol etc), which gives 4 bytes of the extra overhead, and 1071 there is the notify data field, which could include the MOBIKE 1072 specific data. 1074 Another option would be to have a custom payload type, which then 1075 includes the information needed for the MOBIKE protocol. 1077 MOBIKE decided to use IKEv2 NOTIFY payloads, and put only one data 1078 item per notify, i.e. there will be one NOTIFY payload for each item 1079 to be sent. 1081 6.4. Updating address list 1083 Because of the initiator decides, the initiator needs to know all the 1084 addresses used by the responder. The responder needs also that list 1085 in case it happens move to the address unknown by the initiator, and 1086 needs to send address update notify to the initiator, and it might 1087 need to try different addresses for the initiator. 1089 MOBIKE could send the full peer address list every time any of the IP 1090 addresses changes (either addresses are added, removed, the order 1091 changes or the preferred address is updated) or an incremental 1092 update. Sending incremental updates provides more compact packets 1093 (meaning we can support more IP addresses), but on the other hand 1094 have more problems in the synchronization and packet reordering 1095 cases, i.e., the incremental updates must be processed in order, but 1096 for full updates we can simply use the most recent one, and ignore 1097 old ones, even if they arrive after the most recent one (IKEv2 1098 packets have message id which is incremented for each packet, thus we 1099 know the sending order easily). 1101 MOBIKE decided to use protocol format, where both ends can send full 1102 list of their addresses to the other end, and that list overwrites 1103 the previous list. To support NAT-T the IP-addresses of the received 1104 packet is added to the list (and they are not present in the list). 1106 7. Security Considerations 1108 As all the messages are already authenticated by the IKEv2 there is 1109 no problem that any attackers would modify the contents of the 1110 packets. The IP addresses in the IP header of the packets are not 1111 authenticated, thus the protocol defined must take care that they are 1112 only used as an indication that something might be different, and 1113 that do not cause any direct actions. 1115 An attacker can also spoof ICMP error messages in an effort to 1116 confuse the peers about which addresses are not working. At worst 1117 this causes denial of service and/or the use of non-preferred 1118 addresses. 1120 One type of attack that needs to be taken care of in the MOBIKE 1121 protocol is the 'flooding attack' type. See [I-D.ietf-mip6-ro-sec] 1122 and [Aur02] for more information about flooding attacks. 1124 8. IANA Considerations 1126 This document does not introduce any IANA considerations. 1128 9. Acknowledgments 1130 This document is the result of discussions in the MOBIKE working 1131 group. The authors would like to thank Jari Arkko, Pasi Eronen, 1132 Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, 1133 James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, 1134 Udo Schilcher, Tom Henderson, Andreas Pashalidis and Maureen Stillman 1135 for their input. 1137 We would like to particularly thank Pasi Eronen for tracking open 1138 issues on the MOBIKE mailing list. He helped us to make good 1139 progress on the document. 1141 10. References 1143 10.1. Normative references 1145 [I-D.ietf-ipsec-ikev2] 1146 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1147 draft-ietf-ipsec-ikev2-17 (work in progress), 1148 October 2004. 1150 [I-D.ietf-ipsec-rfc2401bis] 1151 Kent, S. and K. Seo, "Security Architecture for the 1152 Internet Protocol", draft-ietf-ipsec-rfc2401bis-06 (work 1153 in progress), April 2005. 1155 10.2. Informative References 1157 [I-D.arkko-multi6dt-failure-detection] 1158 Arkko, J., "Failure Detection and Locator Selection in 1159 Multi6", draft-arkko-multi6dt-failure-detection-00 (work 1160 in progress), October 2004. 1162 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1163 (IKE)", RFC 2409, November 1998. 1165 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1166 Internet Protocol", RFC 2401, November 1998. 1168 [I-D.dupont-mipv6-3bombing] 1169 Dupont, F., "A note about 3rd party bombing in Mobile 1170 IPv6", draft-dupont-mipv6-3bombing-02 (work in progress), 1171 June 2005. 1173 [I-D.ietf-mip6-ro-sec] 1174 Nikander, P., "Mobile IP version 6 Route Optimization 1175 Security Design Background", draft-ietf-mip6-ro-sec-03 1176 (work in progress), May 2005. 1178 [I-D.ietf-hip-mm] 1179 Nikander, P., "End-Host Mobility and Multihoming with the 1180 Host Identity Protocol", draft-ietf-hip-mm-02 (work in 1181 progress), July 2005. 1183 [I-D.crocker-celp] 1184 Crocker, D., "Framework for Common Endpoint Locator 1185 Pools", draft-crocker-celp-00 (work in progress), 1186 February 2004. 1188 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, 1189 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1190 Through Network Address Translators (NATs)", RFC 3489, 1191 March 2003. 1193 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1194 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1195 Zhang, L., and V. Paxson, "Stream Control Transmission 1196 Protocol", RFC 2960, October 2000. 1198 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1199 RFC 3753, June 2004. 1201 [I-D.ietf-tsvwg-addip-sctp] 1202 Stewart, R., "Stream Control Transmission Protocol (SCTP) 1203 Dynamic Address Reconfiguration", 1204 draft-ietf-tsvwg-addip-sctp-12 (work in progress), 1205 June 2005. 1207 [I-D.dupont-ikev2-addrmgmt] 1208 Dupont, F., "Address Management for IKE version 2", 1209 draft-dupont-ikev2-addrmgmt-07 (work in progress), 1210 May 2005. 1212 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A., and R. 1213 Stewart, "On the Use of Stream Control Transmission 1214 Protocol (SCTP) with IPsec", RFC 3554, July 2003. 1216 [I-D.ietf-ipv6-optimistic-dad] 1217 Moore, N., "Optimistic Duplicate Address Detection for 1218 IPv6", draft-ietf-ipv6-optimistic-dad-06 (work in 1219 progress), September 2005. 1221 [I-D.ietf-ipv6-unique-local-addr] 1222 Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1223 Addresses", draft-ietf-ipv6-unique-local-addr-09 (work in 1224 progress), January 2005. 1226 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 1227 E. Lear, "Address Allocation for Private Internets", 1228 BCP 5, RFC 1918, February 1996. 1230 [RFC2367] McDonald, D., Metz, C., and B. Phan, "PF_KEY Key 1231 Management API, Version 2", RFC 2367, July 1998. 1233 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1234 Autoconfiguration", RFC 2462, December 1998. 1236 [RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor 1237 Discovery for IP Version 6 (IPv6)", RFC 2461, 1238 December 1998. 1240 [Aur02] Aura, T., Roe, M., and J. Arkko, "Security of Internet 1241 Location Management", In Proc. 18th Annual Computer 1242 Security Applications Conference, pages 78-87, Las Vegas, 1243 NV USA, December 2002. 1245 Authors' Addresses 1247 Tero Kivinen 1248 Safenet, Inc. 1249 Fredrikinkatu 47 1250 HELSINKI FIN-00100 1251 FI 1253 Email: kivinen@safenet-inc.com 1255 Hannes Tschofenig 1256 Siemens 1257 Otto-Hahn-Ring 6 1258 Munich, Bavaria 81739 1259 Germany 1261 Email: Hannes.Tschofenig@siemens.com 1262 URI: http://www.tschofenig.com 1264 Intellectual Property Statement 1266 The IETF takes no position regarding the validity or scope of any 1267 Intellectual Property Rights or other rights that might be claimed to 1268 pertain to the implementation or use of the technology described in 1269 this document or the extent to which any license under such rights 1270 might or might not be available; nor does it represent that it has 1271 made any independent effort to identify any such rights. Information 1272 on the procedures with respect to rights in RFC documents can be 1273 found in BCP 78 and BCP 79. 1275 Copies of IPR disclosures made to the IETF Secretariat and any 1276 assurances of licenses to be made available, or the result of an 1277 attempt made to obtain a general license or permission for the use of 1278 such proprietary rights by implementers or users of this 1279 specification can be obtained from the IETF on-line IPR repository at 1280 http://www.ietf.org/ipr. 1282 The IETF invites any interested party to bring to its attention any 1283 copyrights, patents or patent applications, or other proprietary 1284 rights that may cover technology that may be required to implement 1285 this standard. Please address the information to the IETF at 1286 ietf-ipr@ietf.org. 1288 Disclaimer of Validity 1290 This document and the information contained herein are provided on an 1291 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1292 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1293 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1294 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1295 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1296 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1298 Copyright Statement 1300 Copyright (C) The Internet Society (2005). This document is subject 1301 to the rights, licenses and restrictions contained in BCP 78, and 1302 except as set forth therein, the authors retain all their rights. 1304 Acknowledgment 1306 Funding for the RFC Editor function is currently provided by the 1307 Internet Society.