idnits 2.17.00 (12 Aug 2021) /tmp/idnits2090/draft-ietf-mobike-design-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1338. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1315. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1322. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1328. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (February 20, 2005) is 6298 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) == Outdated reference: draft-ietf-ipsec-ikev2 has been published as RFC 4306 == Outdated reference: draft-ietf-ipsec-rfc2401bis has been published as RFC 4301 -- 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-01 == Outdated reference: draft-ietf-mip6-ro-sec has been published as RFC 4225 == Outdated reference: draft-ietf-hip-mm has been published as RFC 5206 -- 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: draft-ietf-tsvwg-addip-sctp has been published as RFC 5061 == Outdated reference: A later version (-08) exists of draft-dupont-ikev2-addrmgmt-06 == Outdated reference: draft-ietf-ipv6-optimistic-dad has been published as RFC 4429 == Outdated reference: draft-ietf-ipv6-unique-local-addr has been published as RFC 4193 -- 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: 5 errors (**), 0 flaws (~~), 11 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: August 24, 2005 Siemens 6 February 20, 2005 8 Design of the MOBIKE Protocol 9 draft-ietf-mobike-design-02.txt 11 Status of this Memo 13 This document is an Internet-Draft and is subject to all provisions 14 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 15 author represents that any applicable patent or other IPR claims of 16 which he or she is aware have been or will be disclosed, and any of 17 which he or she become aware will be disclosed, in accordance with 18 RFC 3668. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as 23 Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on August 24, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2005). 42 Abstract 44 The MOBIKE (IKEv2 Mobility and Multihoming) working group is 45 developing protocol extensions to the Internet Key Exchange Protocol 46 version 2 (IKEv2) to enable its use in the context where there are 47 multiple IP addresses per host or where IP addresses of an IPsec host 48 change over time (for example, due to mobility). 50 This document discusses the involved network entities, and the 51 relationship between IKEv2 signaling and information provided by 52 other protocols and the rest of the network. Design decisions for 53 the base MOBIKE protocol, background information and discussions 54 within the working group are recorded. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. Scenarios . . . . . . . . . . . . . . . . . . . . . . . . . . 7 61 3.1 Mobility Scenario . . . . . . . . . . . . . . . . . . . . 7 62 3.2 Multihoming Scenario . . . . . . . . . . . . . . . . . . . 8 63 3.3 Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 9 64 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 10 65 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 13 66 5.1 Indicating Support for MOBIKE . . . . . . . . . . . . . . 13 67 5.2 Changing a Preferred Address and Multihoming Support . . . 13 68 5.2.1 Storing a single or multiple addresses . . . . . . . . 14 69 5.2.2 Indirect or Direct Indication . . . . . . . . . . . . 15 70 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection . . 16 71 5.3 Simultaneous Movements . . . . . . . . . . . . . . . . . . 17 72 5.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 18 73 5.5 Changing addresses or changing the paths . . . . . . . . . 19 74 5.6 Return Routability Tests . . . . . . . . . . . . . . . . . 20 75 5.7 Employing MOBIKE results in other protocols . . . . . . . 22 76 5.8 Scope of SA changes . . . . . . . . . . . . . . . . . . . 23 77 5.9 Zero Address Set . . . . . . . . . . . . . . . . . . . . . 24 78 5.10 IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 25 79 5.11 Message Representation . . . . . . . . . . . . . . . . . . 25 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 28 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 30 83 9. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 31 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 32 85 10.1 Normative references . . . . . . . . . . . . . . . . . . . 32 86 10.2 Informative References . . . . . . . . . . . . . . . . . . 32 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 34 88 Intellectual Property and Copyright Statements . . . . . . . . 35 90 1. Introduction 92 IKEv2 is used for performing mutual authentication and establishing 93 and maintaining IPsec security associations (SAs). IKEv2 establishes 94 both cryptographic state (such as session keys and algorithms) as 95 well as non-cryptographic information (such as IP addresses). 97 The current IKEv2 and IPsec documents explicitly say that the IPsec 98 and IKE SAs are created implicitly between the IP address pair used 99 during the protocol execution when establishing the IKEv2 SA. This 100 means that there is only one IP address pair stored for the IKEv2 SA, 101 and this single IP address pair is used as an outer endpoint address 102 for tunnel mode IPsec SAs. After the IKE SA is created there is no 103 way to change them. 105 There are scenarios where this IP address might change, even 106 frequently. In some cases the problem could be solved by rekeying 107 all the IPsec and IKE SAs after the IP address has changed. However, 108 this can be problematic, as the device might be too slow to rekey the 109 SAs that often, and other scenarios the rekeying and required IKEv2 110 authentication might require user interaction (SecurID cards etc). 111 Due to these reasons, a mechanism to update the IP addresses tied to 112 the IPsec and IKEv2 SAs is needed. MOBIKE provides solution to the 113 problem of the updating the IP addresses stored with IKE SAs and 114 IPsec SAs. 116 The charter of the MOBIKE working group requires IKEv2 117 [I-D.ietf-ipsec-ikev2], and as IKEv2 assumes that the RFC2401bis 118 architecture [I-D.ietf-ipsec-rfc2401bis] is used, all protocols 119 developed will use both IKEv2 and RFC2401bis. MOBIKE does not 120 support IKEv1 [RFC2409] or the old RFC2401 architecture [RFC2401]. 122 This document is structured as follows. After introducing some 123 important terms in Section 2 we list a few scenarios in Section 3, to 124 illustrate possible deployment environments. MOBIKE depends on 125 information from other sources (e.g., detect an address change) which 126 are discussed in Section 4. Finally, Section 5 discusses design 127 considerations effecting the MOBIKE protocol. The document concludes 128 with security considerations in Section 6. 130 2. Terminology 132 This section introduces some useful terms for a MOBIKE protocol. 134 Peer: 136 Within this document we refer to IKEv2 endpoints as peers. A peer 137 implements MOBIKE and therefore IKEv2. 139 Available address: 141 An address is said to be available if the following conditions are 142 fulfilled: 143 * The address has been assigned to an interface of the node. 144 * If the address is an IPv6 address, we additionally require that 145 (a) the address is valid in the sense of RFC 2461 [RFC2461], 146 and that (b) the address is not tentative in the sense of RFC 147 2462 [RFC2462]. In other words, the address assignment is 148 complete so that communications can be started. 150 Note this explicitly allows an address to be optimistic in the 151 sense of [I-D.ietf-ipv6-optimistic-dad] even though 152 implementations are probably better off using other addresses 153 as long as there is an alternative. 154 * The address is a global unicast or unique site-local address 155 [I-D.ietf-ipv6-unique-local-addr]. That is, it is not an IPv6 156 link-local or site-local address. Where IPv4 is considered, it 157 is not an RFC 1918 [RFC1918] address. 158 * The address and interface is acceptable for use according to a 159 local policy. 160 This definition is reused from 161 [I-D.arkko-multi6dt-failure-detection] 163 . 164 Locally Operational Address: 166 An available address is said to be locally operational when its 167 use is known to be possible locally. This definition is taken 168 from [I-D.arkko-multi6dt-failure-detection]. 170 Operational address pair: 172 A pair of operational addresses are said to be an operational 173 address pair, iff bidirectional connectivity can be shown between 174 the two addresses. Note that sometimes it is necessary to 175 consider a 5-tuple when connectivity between two endpoints need to 176 be tested. This differentiation might be necessary to address 177 load balancers, certain Network Address Translation types or 178 specific firewalls. This definition is taken from 179 [I-D.arkko-multi6dt-failure-detection] and enhanced to fit the 180 MOBIKE context. Although it is possible to further differentiate 181 unidirectional and bidirectional operational address pairs only 182 bidirectional connectivity is relevant for this document and 183 unidirectional connectivity is out of scope. 185 Path: 187 The route taken by the MOBIKE and/or IPsec packets sent via the IP 188 address of one peer to a specific destination address of the other 189 peer. Note that the path might be effected not only by the source 190 and destination IP addresses but also by the selected transport 191 protocol and transport protocol identifier. Since MOBIKE and 192 IPsec packets have a different appearance on the wire they might 193 be routed along a different path. This definition is taken from 194 [RFC2960] and modified to fit the MOBIKE context. 196 Primary Path: 198 The primary path is the destination and source address that will 199 be put into a packet outbound to the peer by default. This 200 definition is taken from [RFC2960] and modified to fit the MOBIKE 201 context. 203 Preferred Address: 205 An address on which a peer prefers to receive MOBIKE messages and 206 IPsec protected data traffic. A given peer has only one active 207 preferred address at a given point in time (ignoring the small 208 time period where it needs to switch from the old preferred 209 address to a new preferred address). This definition is taken 210 from [I-D.ietf-hip-mm] and modified to fit the MOBIKE context. 212 Peer Address Set: 214 We denote the two peers in this Mobike session by peer A and peer 215 B. A peer address set is a subset of locally operational 216 addresses of peer A that are sent to peer B. A policy available 217 at peer A indicates which addresses to include in the peer address 218 set. Such a policy might be impacted by manual configuration or 219 by interaction with other protocols that indicate new available 220 addresses. 222 Terminology for different NAT types, such as Full Cone, Restricted 223 Cone, Port Restricted Cone and Symmetric, can be found in Section 5 224 of [RFC3489]. For mobility related terminology, such as 225 Make-before-break or Break-before-make see [RFC3753]. 227 3. Scenarios 229 The MOBIKE protocol can be used in different scenarios. Three of 230 them are discussed below. 232 3.1 Mobility Scenario 234 Figure 1 shows a break-before-make mobility scenario where a mobile 235 node attaches to, for example a wireless LAN, to obtain connectivity 236 to some security gateway. This security gateway might connect the 237 mobile node to a corporate network, to a 3G network or to some other 238 network. The initial IKEv2 exchange takes place along the path 239 labeled as 'old path' from the MN using its old IP address via the 240 old access router (OAR) towards the security gateway (GW). The IPsec 241 tunnel mode terminates there but the decapsulated data packet will 242 typically address another destination. Since only MOBIKE 243 communication from the MN to the gateway is relevant for this 244 discussion the end-to-end communication between the MN and some 245 destination is not shown in Figure 1. 247 When the MN moves to a new network and obtains a new IP address from 248 a new access router (NAR) it is the responsibility of MOBIKE to avoid 249 restarting the IKEv2 exchange from scratch. As a result, a protocol 250 exchange, denoted by 'MOBIKE Address Update' , will perform the 251 necessary state update. 253 Note that in a break-before-make mobility scenario the MN obtains a 254 new IP address after reachability to the old IP address has been 255 lost. MOBIKE is also assumed to work in scenarios where the mobile 256 node is able to establish connectivity with the new IP address while 257 still being reachable at the old IP address. 259 (Initial IKEv2 Exchange) 260 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v 261 Old IP +--+ +---+ v 262 address |MN|------> |OAR| -------------V v 263 +--+ +---+ Old path V v 264 . +----+ v>>>>> +--+ 265 .move | R | -------> |GW| 266 . | | >>>>> | | 267 v +----+ ^ +--+ 268 +--+ +---+ New path ^ ^ 269 New IP |MN|------> |NAR|--------------^ ^ 270 address +--+ +---+ ^ 271 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ 272 (MOBIKE Address Update) 274 ---> = Path taken by data packets 275 >>>> = Signaling traffic (IKEv2 and MOBIKE) 276 ...> = End host movement 278 Figure 1: Mobility Scenario 280 3.2 Multihoming Scenario 282 Another scenario where MOBIKE might be used is between two peers 283 equipped with multiple interfaces (and multiple IP addresses). 284 Figure 2 shows two such multi-homed peers. Peer A has two interface 285 cards with two IP addresses IP_A1 and IP_A2. Additionally, Peer B 286 also has two IP addresses, IP_B1 and IP_B2. Each peer selects one of 287 its IP addresses as the preferred address which will subsequently be 288 used for communication. Various reasons, such as problems with the 289 interface card, might require a peer to switch from one IP address to 290 the other one. 292 +------------+ +------------+ 293 | Peer A | *~~~~~~~~~* | Peer B | 294 | |>>>>>>>>>> * Network *>>>>>>>>>>| | 295 | IP_A1 +-------->+ +--------->+ IP_B1 | 296 | | | | | | 297 | IP_A2 +********>+ +*********>+ IP_B2 | 298 | | * * | | 299 +------------+ *~~~~~~~~~* +------------+ 301 ---> = Path taken by data packets 302 >>>> = Signaling traffic (IKEv2 and MOBIKE) 303 ***> = Potential future path through the network 304 (if Peer A and Peer B change their preferred 305 address) 307 Figure 2: Multihoming Scenario 309 Note that MOBIKE does not support load balancing between multiple IP 310 addresses. That is, each peer uses only one of the available IP 311 addresses at a given point in time. 313 3.3 Multihomed Laptop Scenario 315 In the multihomed laptop scenario we consider a laptop, which has 316 multiple interface cards and therefore several ways to connect to a 317 network. It might for example have a fixed Ethernet, WLAN, GPRS, 318 Bluetooth or USB hardware in order to send IP packets. A number of 319 interfaces might connected to a network over time depending on a 320 number of reasons (e.g., cost, availability of certain link layer 321 technologies, user convenience). Note that a policy for selecting a 322 network interface based on cost, etc. is out of scope for MOBIKE. 323 For example, the user can disconnect himself from the fixed Ethernet, 324 use the office WLAN, and then later leave the office and start using 325 GPRS during the trip home. At home he might use WLAN. At a certain 326 point in time multiple interfaces might be connected. As such, the 327 laptop is a multihomed device. In any case, the IP address of the 328 individual interfaces are subject to change. 330 The user desires to keep the established IKE-SA and IPsec SAs alive 331 all the time without the need to re-run the initial IKEv2 exchange 332 which could require user interaction as part of the authentication 333 process. Furthermore, even if IP addresses change due to interface 334 switching or mobility, the IP source and destination address obtained 335 via the configuration payloads within IKEv2 and used inside the IPsec 336 tunnel remains unaffected, i.e., applications might not detect any 337 change at all. 339 4. Framework 341 The working group will develop a MOBIKE protocol which needs to 342 perform the following functionality: 343 o Ability to inform the other peer about the peer address set 344 o Ability to inform the other peer about the preferred address 345 o Ability to test connectivity along a path and thereby to detect an 346 outage situation 347 o Ability to change the preferred address 348 o Ability to change the peer address set 349 o Ability to deal with Network Address Translation devices 351 The technical details of these functions are discussed below. 352 Although the interaction with other protocols is important for MOBIKE 353 to operate correctly the working group is chartered to leave this 354 aspect outside the scope. 356 When a MOBIKE peer initiates a protocol exchange with its MOBIKE peer 357 it needs to define a peer address set based on the available 358 addresses. It might want to make this peer address set available to 359 the other peer. The Initiator does not need to explicitly indicate 360 its preferred address since it is already using its preferred 361 address. The outgoing IKEv2 and MOBIKE messages use this preferred 362 address as the source IP address and the MOBIKE peer expects incoming 363 signaling messages to be sent to this address. Interaction with 364 other protocols at the MOBIKE host is required to build the peer 365 address set and the preferred address. In some cases the peer 366 address set is available before the initial protocol exchange and 367 does not change during the lifetime of the IKE-SA. The preferred 368 address might change due to policy reasons. Section 3 describes 369 three scenarios in which the peer address set is modified (by adding 370 or deleting addresses). In these scenarios the preferred address 371 needs to be changed as well. 373 Modifying the peer address set or changing the preferred address is 374 effected by the host's local policy and by the interaction with other 375 protocols (such as DHCP or IPv6 Neighbor Discovery). 377 Figure 3 shows an example protocol interaction at a MOBIKE peer. 378 MOBIKE interacts with the IPsec engine using the PF_KEY interface 379 [RFC2367] to create entries in the Security Association and Security 380 Policy Databases. The IPsec engine might also interact with IKEv2 381 and MOBIKE. Established state at the IPsec databases has an impact 382 on the incoming and outgoing data traffic. MOBIKE receives 383 information from other protocols running in both kernel-mode and 384 user-mode, as previously mentioned. Information relevant for MOBIKE 385 is stored in a database, referred as Trigger database, that guides 386 MOBIKE in its decisions regarding the available addresses, peer 387 address set, and the preferred address. Policies might affect the 388 selection process. 390 Building and maintaining a peer address set and selecting or changing 391 a preferred address based on locally available information is, 392 however, insufficient. This information needs to be available to the 393 other peer and in order to address various failure cases it is 394 necessary to test connectivity along a path. A number of address 395 pairs might be available for connectivity tests but most important 396 are the source and the destination IP address of the primary path 397 since these addresses are selected for sending and receiving MOBIKE 398 signaling messages and for sending and receiving IPsec protected data 399 traffic. If a problem along this primary path is detected (e.g., due 400 to a router failure) it is necessary to switch to the new primary 401 path. Optionally, periodic testing of other paths might be useful to 402 determine when a disconnected path becomes operational. 404 +-------------+ +---------+ 405 |User-space | | MOBIKE | 406 |Protocols | +-->>| Daemon | 407 |relevant for | | | | 408 |MOBIKE | | +---------+ 409 +-------------+ | ^ 410 User Space ^ | ^ 411 ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ 412 Kernel Space v | v 413 _______ | v 414 +-------------+ / \ | +--------------+ 415 |Routing | / Trigger \ | | IPsec | 416 |Protocols |<<-->>| Database |<<-+ +>+ Engine | 417 | | \ / | | (+Databases) | 418 +-----+---+---+ \_______/ | +------+-------+ 419 ^ ^ ^ | ^ 420 | +---------------+-------------+--------+-----+ 421 | v | | | 422 | +-------------+ | | | 423 I | |Kernel-space | | | | I 424 n | +-------->+Protocols +<----+-----+ | | n 425 t v v |relevant for | | v v v t 426 e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e 427 r | Input | +-------------+ | | Outgoing | r 428 f | Packet +<--------------------------+ | Interface | f 429 ==a>|Processing|===============================| Processing |=a> 430 c | | | | c 431 e +----------+ +------------+ e 432 s s 433 ===> = IP packets arriving/leaving a MOBIKE node 434 <-> = control and configuration operations 436 Figure 3: Framework 438 Please note that Figure 3 is only one way of implementing MOBIKE. 439 Hence, it serves illustrative purposes only. 441 Extensions of the PF_KEY interface required by MOBIKE are also within 442 the scope of the working group. Finally, optimizations in wireless 443 environment will also be covered. 445 5. Design Considerations 447 This section discusses aspects affecting the design of the MOBIKE 448 protocol. 450 5.1 Indicating Support for MOBIKE 452 In order for MOBIKE to function correctly, both peers must implement 453 this extension. We propose extensions to IKEv2 described below for 454 MOBIKE support. If only one peer supports MOBIKE, then the peers 455 will just run IKEv2. Specifically, a node needs to be able to 456 guarantee that its address change messages are understood by its 457 corresponding peer. Otherwise an address change may render the 458 connection useless, and it is important that both sides realize this 459 as early as possible. 461 Ensuring that the messages are understood can in be arranged either 462 by marking some IKEv2 payloads critical so that they are either 463 processed or an error message is returned, by using Vendor ID 464 payloads or via a Notify. 466 The first solution approach is to use Vendor ID payloads during the 467 initial IKEv2 exchange using a specific string denoting MOBIKE to 468 signal the support of the MOBIKE protocol. This ensures that in all 469 cases a MOBIKE capable node knows whether its peer supports MOBIKE or 470 not. 472 The second solution approach uses the Notify payload which is also 473 used for NAT detection (via NAT_DETECTION_SOURCE_IP and 474 NAT_DETECTION_DESTINATION_IP). 476 Both a Vendor ID and a Notify payload might be used to indicate the 477 support of certain extensions. 479 Note that the node could also attempt MOBIKE opportunistically with 480 the critical bit set when an address change has occurred. The 481 drawback of this approach is, however, that the an unnecessary MOBIKE 482 message exchange is introduced. 484 Although Vendor ID payloads and Notifications are technically 485 equivalent Notifications are already used in IKEv2 as a capability 486 negotiation mechanism and is therefore the preferred mechanism. 488 5.2 Changing a Preferred Address and Multihoming Support 490 From MOBIKE's point of view multihoming support is integrated by 491 supporting a peer address set rather than a single address and 492 protocol mechanisms to change to use a new preferred IP address. 494 From a protocol point of view each peer needs to learn the preferred 495 address and the peer address set either implicitly or explicitly. 497 5.2.1 Storing a single or multiple addresses 499 One design decision is whether an IKE-SA should store a single IP 500 address or multiple IP addresses as part of the peer address set. 501 One option is that the other end can provide a list of addresses 502 which can be used as destination addresses. MOBIKE does not support 503 load balancing, i.e., only one IP address is set to a preferred 504 address at a time and changing the preferred address typically 505 requires some MOBIKE signaling. 507 Another option is to only communicate one address to the other peer 508 and both peers only use that address when communicating. If this 509 preferred address cannot be used anymore then an address update is 510 sent to the other peer changing the preferred address. 512 If peer A provides a peer address set with multiple IP addresses then 513 peer B can recover from a failure of the preferred address on its 514 own, meaning that when it detects that the primary path does not work 515 anymore it can either switch to a new preferred address locally 516 (i.e., causing the source IP address of outgoing MOBIKE messages to 517 have a non-preferred address) or try an IP address from A's peer 518 address set. If peer B only received a single IP address as the A's 519 peer address set then peer B can only change its own preferred 520 address. The other end has to wait for an address update from peer A 521 with a new IP address in order to fix the problem. The main 522 advantage about using a single IP address for the remote host is that 523 it makes retransmission easy, and it also simplifies the recovery 524 procedure. The peer, whose IP address changed, must start the 525 recovery process and send the new IP address to the other peer. 526 Failures along the path are not well covered with advertising a 527 single IP address. 529 The single IP address approach will not work if both peers happen to 530 loose their IP address at the same time (due to, say, the failure of 531 one of the links that both nodes are connected to). It may also 532 require the IKEv2 window size to be larger than 1, especially if only 533 direct indications are used. This is because the host needs to be 534 able to send the IP address change notifications before it can switch 535 to another address, and depending on the return routability checks, 536 retransmissions policies etc, it might be hard to make the protocol 537 such that it works with window size of 1 too. Furthermore, the 538 single IP address approach does not really benefit much from indirect 539 indications as the peer receiving these indications might not be able 540 to fix the situation by itself (e.g., even if a peer receives an ICMP 541 host unreachable message for the old IP address, it cannot try other 542 IP addresses, since they are unknown). 544 The problems with IP address lists are mostly in its complexity. 545 Notification and recovery processes are more complex. Both ends can 546 recover from the IP address changes. However, both peers should not 547 attempt to recover at the same time or nearly the same time as it 548 could cause them to lose connectivity. The MOBIKE protocol is 549 required to prevent this. 551 The previous discussion is independent of the question of how many 552 addresses to send in a single MOBIKE message. A MOBIKE message might 553 be able to carry more than one IP address (with the IP address list 554 approach) or a single address only. The latter approach has the 555 advantage of dealing with NAT traversal in a proper fashion. A NAT 556 cannot change addresses carried inside the MOBIKE message but it can 557 change IP address (and transport layer addresses) in the IP header 558 and Transport Protocol header (if NAT traversal is enabled). 559 Furthermore, a MOBIKE message carrying the peer address set could be 560 idempotent (i.e., always resending the full address list) or the 561 protocol may allow add/delete operations to be specified. 562 [I-D.dupont-ikev2-addrmgmt], for example, offers an approach which 563 defines add/delete operations. The same is true for the dynamic 564 address reconfiguration extension for SCTP 565 [I-D.ietf-tsvwg-addip-sctp]. 567 5.2.2 Indirect or Direct Indication 569 An indication to change the preferred IP address might be either 570 direct or indirect. 572 Direct indication: 574 A direct indication means that the other peer will send an message 575 with the address change. Such a message can, for example, 576 accomplished by having MOBIKE sending an authenticated address 577 update notification with a different preferred address. 579 Indirect indication: 581 An indirect indication to change the preferred address can be 582 obtained by observing the environment. An indirect indication 583 might, for example, be be the receipt of an ICMP message or 584 information of a link failure. This information should be seen as 585 a hint and might not directly cause any changes to the preferred 586 address. Depending on the local policy MOBIKE might decide to 587 perform a dead-peer detection exchange for the preferred address 588 pair (or another address pair from the peer address set). When a 589 peer detects that the other end started to use a different source 590 IP address than before, it might want to authorize the new 591 preferred address (if not already authorized). A peer might also 592 start a connectivity test of this particular address. If a 593 bidirectionally operational address pair is selected then MOBIKE 594 needs to communicate this new preferred address to its remote 595 peer. 597 MOBIKE will utilize both mechanisms, direct and indirect indications, 598 to make a more intelligent decision which address pair to select as 599 the preferred address. The more information will be available to 600 MOBIKE the faster a new primary path can be selected among the 601 available candiates. 603 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection 605 This section discusses the suitability of the IKEv2 dead-peer 606 detection (DPD) mechanism for connectivity tests between address 607 pairs. The basic IKEv2 DPD mechanism is not modified by MOBIKE but 608 it needs to be investigated whether it can be used for MOBIKE 609 purposes as well. 611 The IKEv2 DPD mechanism is done by sending an empty informational 612 exchange packet to the other peer, in which case the other end will 613 respond with an acknowledgement. If no acknowledgement is received 614 after a certain timeout (and after couple of retransmissions), the 615 other peer is considered to be not reachable. Note that the receipt 616 of IPsec protected data traffic is also a guarantee that the other 617 peer is alive. 619 When reusing dead-peer detection in MOBIKE for connectivity tests it 620 seems to be reasonable to try other IP addresses (if they are 621 available) in case of an unsuccessful connectivity test for a given 622 address pair. Dead-peer detection messages using a different address 623 pair should use the same message-id as the original dead-peer 624 detection message (i.e. they are simply retransmissions of the 625 dead-peer detection packet using different destination IP address). 626 If different message-id is used then it violates constraints placed 627 by the IKEv2 specification on the DPD message with regard to the 628 mandatory ACK for each message-id, causing the IKEv2 SA to be 629 deleted. 631 If MOBIKE strictly follows the guidelines of the dead-peer detection 632 mechanism in IKEv2 then an IKE-SA should be marked as dead and 633 deleted if the connectivity test for all address pairs fails. Note 634 that this is not in-line with the approach used, for example, in SCTP 635 where a failed connectivity test for an address does not lead to (a) 636 the IP address or IP address pair to be marked as dead and (b) delete 637 state. Connectivity tests will be continued for the address pairs in 638 hope that the problem will recover soon. 640 Note that as IKEv2 implementations might have window size of 1, which 641 prevents it from initiating a dead-peer detection exchange while 642 doing another exchange. As a result, all other exchanges experience 643 the identical retransmission policy as used for the dead-peer 644 detection. 646 The dead-peer detection for the other IP address pairs can also be 647 executed simultaneously (with a window size larger than 1), meaning 648 that after the initial timeout of the preferred address expires, we 649 send packets simultaneously to all other address pairs. It is 650 necessary to differentiate individual acknowledgement messages in 651 order to determine which address pair is operational. Therefore the 652 source IP address of the acknowledgement should match the destination 653 IP towards the message that was previously sent. 655 Also the other peer is most likely going to reply only to the first 656 packet it receives, and that first packet might not be the best (by 657 whatever criteria) address pair. The reason the other peer is only 658 responding to the first packet it receives is that implementations 659 should not send retransmissions if they have just sent out an 660 identical response message. This is to protect the packet 661 multiplication problem, which can happen if some node in the network 662 queues up packets and then sends them to the destination. If the 663 destination were to reply to all of them then the other end will 664 again see multiple packets, and will reply to all of them, etc. 666 The protocol should also be nice to the network, meaning, that when 667 some core router link goes down, and a large number of MOBIKE clients 668 notice it, they should not start sending a large number of messages 669 while trying to recover from the problem. This might be especially 670 bad because packets are dropped because of the congested network. If 671 MOBIKE clients simultaneously try to test all possible address pairs 672 by executing connectivity tests then the congestion problem only gets 673 worse. 675 Also note that the IKEv2 dead-peer detection is not sufficient for 676 the return routability check. See Section 5.6 for more information. 678 5.3 Simultaneous Movements 680 MOBIKE does not aim to provide a full mobility solution which allows 681 simultaneous movements. Instead, the MOBIKE working group focuses on 682 selected scenarios as described in Section 3. Some of the scenarios 683 assume that one peer has a fixed set of addresses (from which some 684 subset might be in use). Thus it cannot move to the address unknown 685 to the other peer. Situations in which both peers move and the 686 movement notifications cannot reach the other peer are outside the 687 scope of the MOBIKE WG. MOBIKE has not being chartered to deal with 688 the rendezvous problem, or with the introduction of any new entities 689 in the network. 691 Note that if only a single address is stored in the peer address set 692 (instead of an address list) we might end up in the case where it 693 seems that both peers changed their addresses at the same time. This 694 is something that the protocol must deal with. 696 Three cases can be differentiated: 698 o Two mobile nodes obtain a new address at the same time, and then 699 being unable to tell each other where they are (in a 700 break-before-make scenario). This problem is called the 701 rendezvous problem, and is traditionally solved by introducing 702 another third entity, for example, the home agents (in Mobile 703 IPv4/IPv6) or forwarding agents (in Host Identity Protocol). 704 Essentially, solving this problem requires the existence of a 705 stable infrastructure node somewhere. 707 o Simultaneous changes to addresses such that at least one of the 708 new addresses is known to the other peer before the change 709 occurred. 711 o No simultaneous changes at all. 713 5.4 NAT Traversal 715 IKEv2 has support of legacy NAT traversal built-in. This feature is 716 known as NAT-T which allows IKEv2 to work even if a NAT along the 717 path between the Initiator and the Responder modified the source and 718 possibly the destination IP address. With NAPT even the transport 719 protocol identifiers are modified (which then requires UDP 720 encapsulation for subsequent IPsec protected data traffic). 721 Therefore, the required IP address information is taken from the IP 722 header (if a NAT was detected who rewrote IP header information) 723 rather than from the protected payload. This problem is not new and 724 was discovered during the design of mobility protocol where the only 725 valuable information is IP address information. 727 One of the goals in the MOBIKE protocol is to securely exchange one 728 or more addresses of the peer address set and to securely set the 729 primary address. If no other protocol is used to securely retrieve 730 the IP address and port information allocated by the NAT then it is 731 not possible to tackle all attacks against MOBIKE. Various solution 732 approaches have been presented: 734 o Securely retrieving IP address and port information allocated by 735 the NAT using a protocol different from MOBIKE. This approach is 736 outside the scope of the MOBIKE working group since other working 737 groups, such as MIDCOM and NSIS, already deal with this problem. 738 The MOBIKE protocol can benefit from the interaction with these 739 protocols. 741 o Design a protocol in such a way that NAT boxes are able to inspect 742 (or even participate) in the protocol exchange. This approach was 743 taken with HIP but is not an option for IKEv2 and MOBIKE. 745 o Disable NAT-T support by indicating the desire never to use 746 information from the (unauthenticated) header. While this 747 approach prevents some problems it effectively disallows the 748 protocol to work in certain environments. 750 There is no way to distinguish the cases where there is NAT along the 751 path that modifies the header information in packets or whether an 752 adversary mounts an attack. If NAT is detected in the IKE SA 753 creation, that should automatically disable the MOBIKE extensions and 754 use NAT-T. 756 A design question is whether NAT detection capabilities should be 757 enabled only during the initial exchange or even at subsequent 758 message exchanges. If MOBIKE is executed with no NAT along the path 759 when the IKE SA was created, then a NAT which appears after moving to 760 a new network cannot be dealt with if NAT detection is enabled only 761 during the initial exchange. Hence, it might be desirable to also 762 support a scenario where a MOBIKE peer moves from a network which 763 does not deploy a NAT to a network which uses a private address 764 space. 766 A NAT prevention mechanism can be used to make sure that no adversary 767 can interact with the protocol if no NAT is expected between the 768 Initiator and the Responder. 770 The support for NAT traversal is certainly one of the most important 771 design decisions with an impact on other protocol aspects. 773 5.5 Changing addresses or changing the paths 775 A design decision is whether it is enough for the MOBIKE protocol to 776 detect dead address, or does it need to detect also dead paths. Dead 777 address detection means that we only detect that we cannot get 778 packets through to that remote address by using the local IP address 779 given by the local IP-stack (i.e., local address selected normally by 780 the routing information). Dead path detection means that we need to 781 try all possible local interfaces/IP addresses for each remote 782 addresses, i.e., find all possible paths between the hosts and try 783 them all to see which of them work (or at least find one working 784 path). 786 While performing just an address change is simpler, the existence of 787 locally operational addresses are not, however, a guarantee that 788 communications can be established with the peer. A failure in the 789 routing infrastructure can prevent the sent packets from reaching 790 their destination. Or a failure of an interface on one side can be 791 related to the failure of an interface on the other side, making it 792 necessary to change more than one address at a time. 794 5.6 Return Routability Tests 796 Setting a new preferred address which is subsequently used for 797 communication is associated with an authorization decision: Is a peer 798 allowed to use this address? Does this peer own this address? Two 799 mechanisms have been proposed in the past to allow a peer to 800 determine the answer to this question: 802 o The addresses a peer is using are part of a certificate. 803 [RFC3554] introduced this approach. If the other peer is, for 804 example, a security gateway with a limited set of fixed IP 805 addresses, then the security gateway may have a certificate with 806 all the IP addresses in the certificate. 808 o A return routability check is performed before the address is used 809 to ensure that the peer is reachable at the indicated address. 811 Without performing an authorization decision a malicious peer can 812 redirect traffic towards a third party or a blackhole. 814 An IP address should not be used as a primary address without 815 computing the authorization decision. If the addresses are part of 816 the certificate then it is not necessary to execute the weaker return 817 routability test. If multiple addresses are communicated to another 818 peer as part of the peer address set then some of these addresses 819 might be already verified even if the primary address is still 820 operational. 822 Another option is to use the [I-D.dupont-mipv6-3bombing] approach 823 which suggests to do a return routability test only if you have to 824 send an address update from some other address than the indicated 825 preferred address. 827 Finally it would be possible not to execute return routability checks 828 at all. In case of indirect change notifications then we only move 829 to the new preferred address after successful dead-peer detection on 830 the new address, which is already a return routability check. With a 831 direct notifications the authenticated peer may have provided an 832 authenticated IP address, thus we could simply trust the other end. 833 There is no way external attacker can cause any attacks, but we are 834 not protected from the internal attacker, i.e. the authenticated 835 peer forwarding its traffic to the new address. On the other hand we 836 do know the identity of the peer in that case. 838 As such, it seems that there it is also a policy issue when to 839 schedule a return routability test. 841 The basic format of the return routability check could be similar to 842 dead-peer detection, but the problem is that if that fails then the 843 IKEv2 specification requires the IKE SA to be deleted. Because of 844 this we might need to do some kind of other exchange. 846 There are potential attacks if a return routability check does not 847 include some kind of nonce. In this attack the valid end point sends 848 address update notification for the third party, trying to get all 849 the traffic to be sent there, causing a denial of service attack. If 850 the return routability checks does not contain any cookies or other 851 random information not known by the other end, then that valid node 852 could reply to the return routability checks even when it cannot see 853 the request. This might cause the other end to turn the traffic to 854 there, even when the true original recipient cannot be reached at 855 this address. 857 The IKEv2 NAT-T mechanism does not perform any return routability 858 checks. It simply uses the last seen source IP address used by the 859 other peer as the destination address to send response packets. An 860 adversary can change those IP addresses, and can cause the response 861 packets to be sent to wrong IP address. The situation is self-fixing 862 when the adversary is no longer able to modify packets and the first 863 packet with true IP address reaches the other peer. In a certain 864 sense mobility handling makes this attack difficult for an adversary 865 since it needs to be located somewhere along the path where the 866 individual paths ({CoA1, ..., CoAn} towards the destination IP 867 address) have a shared path or if the adversary is located near the 868 MOBIKE client then it needs to follow the users mobility patterns. 869 With IKEv2 NAT-T, the genuine client can cause third party bombing by 870 redirecting all the traffic pointed to him to third party. As the 871 MOBIKE protocol tries to provide equal or better security than IKEv2 872 NAT-T the MOBIKE protocol should protect against these attacks. 874 There might be also return routability information available from the 875 other parts of the system too (as shown in Figure 3), but the checks 876 done might have a different quality. There are multiple levels for 877 return routability checks: 879 o None, no tests 881 o A party willing to answer is on the path to the claimed address. 882 This is the basic form of return routability test. 884 o There is an answer from the tested address, and that answer was 885 authenticated (including the address) to be from our peer. 887 o There was an authenticated answer from the peer, but it is not 888 guaranteed to be from the tested address or path to it (because 889 the peer can construct a response without seeing the request). 891 The basic return routability checks do not protect against 3rd party 892 bombing if the attacker is along the path, as the attacker can 893 forward the return routability checks to the real peer (even if those 894 packets are cryptographically authenticated). 896 If the address to be tested is inside the MOBIKE packet too, then the 897 adversary cannot forward packets, thus it prevents 3rd party 898 bombings. 900 If the reply packet can be constructed without seeing the request 901 packet (for example, if there is no nonce, challenge or similar 902 mechanism to show liveness), then the genuine peer can cause 3rd 903 party bombing, by replying to those requests without seeing them at 904 all. 906 Other levels might only provide information that there is someone at 907 the IP address which replied to the request. There might not be an 908 indication that the reply was freshly generated or repeated, or the 909 request might have been transmitted from a different source address. 911 Requirements for a MOBIKE protocol for the return routability test 912 might be able to verify that there is the same (cryptographically) 913 authenticated node at the other peer and it can now receive packets 914 from the IP address it claims to have. 916 5.7 Employing MOBIKE results in other protocols 918 If MOBIKE has learned about new locations or verified the validity of 919 an address through a return routability test, can this information be 920 useful for other protocols? 922 When considering the basic MOBIKE VPN scenario, the answer is no. 923 Transport and application layer protocols running inside the VPN 924 tunnel have no consideration about the outer addresses or their 925 status. 927 Similarly, IP layer tunnel termination at a gateway rather than a 928 host endpoint limits the benefits for "other protocols" that could be 929 informed -- all application protocols at the other side are running 930 in a node that is unaware of IPsec, IKE, or MOBIKE. 932 However, it is conceivable that future uses or extensions of the 933 MOBIKE protocol make such information distribution useful. For 934 instance, if transport mode MOBIKE and SCTP were made to work 935 together, it would likely be useful for SCTP to learn about the new 936 addresses at the same time as MOBIKE learns them. Similarly, various 937 IP layer mechanisms might make use of the fact that a return 938 routability test of a specific type has already been performed. 939 However, in all of these cases careful consideration should be 940 applied. This consideration should answer to questions such as 941 whether other alternative sources exist for the information, whether 942 dependencies are created between parts that prior to this had no 943 dependencies, and what the impacts in terms of number of messages or 944 latency are. 946 [I-D.crocker-celp] discussed the use of common locator information 947 pools in IPv6 multihoming context; it assumed that both transport and 948 IP layer solutions would be used for providing multihoming, and that 949 it would be beneficial for different protocols to coordinate their 950 results in some manner, for instance by sharing experienced 951 throughput information for address pairs. This may apply to MOBIKE 952 as well, assuming it co-exists with non-IPsec protocols that are 953 faced with the same multiaddressing choices. 955 Nevertheless, all of this is outside the scope of current MOBIKE base 956 protocol design and may be addressed in future work. 958 5.8 Scope of SA changes 960 Most sections of this document discuss design considerations for 961 updating and maintaining addresses for the IKE-SA. However, changing 962 the preferred address also has an impact for IPsec SAs. The outer 963 tunnel header addresses (source IP and destination IP addresses) need 964 to be modified according to the primary path to allow the IPsec 965 protected data traffic to travel along the same path as the MOBIKE 966 packets (if we only consider the IP header information). 968 The basic question is then how the IPsec SAs are changed to use the 969 new address pair (the same address pair as the MOBIKE signaling 970 traffic -- the primary path). One option is that when the IKE SA 971 address is changed then automatically all IPsec SAs associated with 972 it are moved along with it to new address pair. Another option is to 973 have a separate exchange to move the IPsec SAs separately. 975 If IPsec SAs should be updated separately then a more efficient 976 format than notification payload is needed. A notification payload 977 can only store one SPI per payload. A separate payload which would 978 have list of IPsec SA SPIs and new preferred address. If there are 979 large number of IPsec SAs, those payloads can be quite large unless 980 ranges of SPI values are supported. If we automatically move all 981 IPsec SAs when the IKE SA moves, then we only need to keep track 982 which IKE SA was used to create the IPsec SA, and fetch the IP 983 addresses. Note that IKEv2 [I-D.ietf-ipsec-ikev2] already requires 984 implementations to keep track which IPsec SAs are created using which 985 IKE SA. 987 If we do allow each IPsec SAs address set to be updated separately, 988 then we can support scenarios, where the machine has fast and/or 989 cheap connections and slow and/or expensive connections, and it wants 990 to allow moving some of the SAs to the slower and/or more expensive 991 connection, and prevent the move, for example, of the news video 992 stream from the WLAN to the GPRS link. 994 On the other hand, even if we tie the IKE SA update to the IPsec SA 995 update, then we can create separate IKE SAs for this scenario, e.g., 996 we create one IKE SA which have both links as endpoints, and it is 997 used for important traffic, and then we create another IKE SA which 998 have only the fast and/or cheap connection, which is then used for 999 that kind of bulk traffic. 1001 5.9 Zero Address Set 1003 One of the features which might be useful would be for the peer to 1004 announce the other end that it will now disconnect for some time, 1005 i.e., it will not be reachable at all. For instance, a laptop might 1006 go to suspend mode. In this case the peer could send address 1007 notification with zero new addresses, which means that it will not 1008 have any valid addresses anymore. The responder of that kind of 1009 notification would then acknowledge that, and could then temporarily 1010 disable all SAs. If any of the SAs gets any packets they are simply 1011 dropped. This could also include some kind of ACK spoofing to keep 1012 the TCP/IP sessions alive (or simply set the TCP/IP keepalives and 1013 timeouts large enough not to cause problems), or it could simply be 1014 left to the applications, e.g., allow TCP/IP sessions to notice the 1015 link is broken. 1017 The local policy could then decide how long the peer would allow 1018 other peers to be disconnected, e.g., whether this is only allowed 1019 for few minutes, or do they allow users to disconnect Friday evening 1020 and reconnect Monday morning (consuming resources during weekend too, 1021 but on the other hand not more than is normally used during week 1022 days, but we do not need lots of extra resources on the Monday 1023 morning to support all those people connecting back to network). 1025 From a technical point of view this feature addresses two aspects: 1027 o There is no need to transmit IPsec data traffic. IPsec protected 1028 data needs to be dropped which saves bandwidth. This does not 1029 provide a functional benefit i.e, nothing breaks if this feature 1030 is not provided. 1032 o MOBIKE signaling messages are also ignored and need to be 1033 suspended. The IKE-SA must not be deleted and the suspend 1034 functionality (realized with the zero address set) might require 1035 the IKE-SA to be tagged with a lifetime value since the IKE-SA 1036 will not be kept in memory an arbitrary amount of time. Note that 1037 the IKE-SA has no lifetime associated with it. In order to 1038 prevent the IKE-SA to be deleted the dead-peer detection mechanism 1039 needs to be suspended as well. 1041 Due to the enhanced complexity of this extension a first version of 1042 the MOBIKE protocol will not provide this feature. 1044 5.10 IPsec Tunnel or Transport Mode 1046 Current MOBIKE design is focused only on the VPN type usage and 1047 tunnel mode. Transport mode behaviour would also be useful, but will 1048 be discussed in future documents. 1050 5.11 Message Representation 1052 The basic IP address change notifications can be sent either via an 1053 informational exchange already specified in the IKEv2, or via a 1054 MOBIKE specific message exchange. Using informational exchange has 1055 the main advantage that it is already specified in the IKEv2 and 1056 implementations incorporated the functionality already. 1058 Another question is the basic format of the address update 1059 notifications. The address update notifications can include multiple 1060 addresses, which some can be IPv4 and some IPv6 addresses. The 1061 number of addresses is most likely going to be quite small (less than 1062 10). The format might need to indicate a preference value for each 1063 address. Furthermore, one of the addresses in the peer address set 1064 must be labeled as the preferred address. The format could either 1065 contain the preference number, giving out the relative order of the 1066 addresses, or it could simply be ordered list of IP addresses in the 1067 order of the most preferred first. While two addresses can have the 1068 same preference value an ordered list avoids this problem. 1070 Even if load balancing is currently outside the scope of MOBIKE, 1071 there might be future work to include this feature. The format 1072 selected needs to be flexible enough to include additional 1073 information (e.g., to enable load balancing). This might be 1074 something like one reserved field, which can later be used to store 1075 additional information. As there is other potential information 1076 which might have to be tied to the address in the future, a reserved 1077 field seems like a prudent design in any case. 1079 There are two basic formats for putting IP address list in to the 1080 exchange, we can include each IP address as separate payload (where 1081 the payload order indicates the preference value, or the payload 1082 itself might include the preference value), or we can put the IP 1083 address list as one payload to the exchange, and that one payload 1084 will then have internal format which includes the list of IP 1085 addresses. 1087 Having multiple payloads each having one IP address makes the 1088 protocol probably easier to parse, as we can already use the normal 1089 IKEv2 payload parsing procedures to get the list out. It also offers 1090 easy way for the extensions, as the payload probably contains only 1091 the type of the IP address (or the type is encoded to the payload 1092 type), and the IP address itself, and as each payload already has 1093 length associated to it, we can detect if there is any extra data 1094 after the IP address. Some implementations might have problems 1095 parsing too long of a list of IKEv2 payloads, but if the sender sends 1096 them in the most preferred first, the other end can simply only take 1097 the first addresses and use them. 1099 Having all IP addresses in one big MOBIKE specified internal format 1100 provides more compact encoding, and keeps the MOBIKE implementation 1101 more concentrated to one module. 1103 The next choice is which type of payloads to use. IKEv2 already 1104 specifies a notify payload. It includes some extra fields (SPI size, 1105 SPI, protocol etc), which gives 4 bytes of the extra overhead, and 1106 there is the notify data field, which could include the MOBIKE 1107 specific data. 1109 Another option would be to have a custom payload type, which then 1110 includes the information needed for the MOBIKE protocol. 1112 MOBIKE might send the full peer address list once one of the IP 1113 addresses changes (either addresses are added, removed, the order 1114 changes or the preferred address is updated) or an incremental 1115 update. Sending incremental updates provides more compact packets 1116 (meaning we can support more IP addresses), but on the other hand 1117 have more problems in the synchronization and packet reordering 1118 cases, i.e., the incremental updates must be processed in order, but 1119 for full updates we can simply use the most recent one, and ignore 1120 old ones, even if they arrive after the most recent one (IKEv2 1121 packets have message id which is incremented for each packet, thus we 1122 know the sending order easily). 1124 Note that each peer needs to communicate its peer address set to the 1125 other peer. 1127 6. Security Considerations 1129 As all the messages are already authenticated by the IKEv2 there is 1130 no problem that any attackers would modify the actual contents of the 1131 packets. The IP addresses in IP header of the packets are not 1132 authenticated, thus the protocol defined must take care that they are 1133 only used as an indication that something might be different, they 1134 should not cause any direct actions. 1136 Attacker can also spoof ICMP error messages in an effort to confuse 1137 the peers about which addresses are not working. At worst this 1138 causes denial of service and/or the use of non-preferred addresses, 1139 so it is not that serious. 1141 One type of attack that needs to be taken care of in the MOBIKE 1142 protocol is also various flooding attacks. See 1143 [I-D.ietf-mip6-ro-sec] and [Aur02] for more information about 1144 flooding attacks. 1146 [EDITOR's NOTE: This section needs more work.] 1148 7. IANA Considerations 1150 This document does not introduce any IANA considerations. 1152 8. Acknowledgments 1154 This document is the result of discussions in the MOBIKE working 1155 group. The authors would like to thank Jari Arkko, Pasi Eronen, 1156 Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, 1157 James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol, Joe Touch, 1158 Udo Schilcher, Tom Henderson and Maureen Stillman for their input. 1160 We would like to particularly thank Pasi Eronen for tracking open 1161 issues on the MOBIKE mailing list. He helped us to make good 1162 progress on the document. 1164 9. Open Issues 1166 This document is not yet complete, the following open issues need to 1167 be addressed in a future version: 1168 o Section 4 needs an example to better illustrate the functionality 1169 of MOBIKE 1170 o Section 6 requires a more detailed discussion about the potential 1171 security vulnerabilities and their solution. 1172 o Some text is need to address the implications of unidirectional 1173 connectivity aspect for MOBIKE (see also issue #19). 1174 o A discussion about the scalability aspects of connectivity tests 1175 would be benefical. 1176 o More details are necessary to describe the implications of NAT 1177 traversal for MOBIKE. 1179 A complete list of issues is available at TBD. 1181 10. References 1183 10.1 Normative references 1185 [I-D.ietf-ipsec-ikev2] 1186 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1187 Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004. 1189 [I-D.ietf-ipsec-rfc2401bis] 1190 Kent, S. and K. Seo, "Security Architecture for the 1191 Internet Protocol", 1192 Internet-Draft draft-ietf-ipsec-rfc2401bis-05, December 1193 2004. 1195 10.2 Informative References 1197 [I-D.arkko-multi6dt-failure-detection] 1198 Arkko, J., "Failure Detection and Locator Selection in 1199 Multi6", 1200 Internet-Draft draft-arkko-multi6dt-failure-detection-00, 1201 October 2004. 1203 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1204 (IKE)", RFC 2409, November 1998. 1206 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1207 Internet Protocol", RFC 2401, November 1998. 1209 [I-D.dupont-mipv6-3bombing] 1210 Dupont, F., "A note about 3rd party bombing in Mobile 1211 IPv6", Internet-Draft draft-dupont-mipv6-3bombing-01, 1212 January 2005. 1214 [I-D.ietf-mip6-ro-sec] 1215 Nikander, P., "Mobile IP version 6 Route Optimization 1216 Security Design Background", 1217 Internet-Draft draft-ietf-mip6-ro-sec-02, October 2004. 1219 [I-D.ietf-hip-mm] 1220 Nikander, P., "End-Host Mobility and Multi-Homing with 1221 Host Identity Protocol", 1222 Internet-Draft draft-ietf-hip-mm-00, October 2004. 1224 [I-D.crocker-celp] 1225 Crocker, D., "Framework for Common Endpoint Locator 1226 Pools", Internet-Draft draft-crocker-celp-00, February 1227 2004. 1229 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, 1230 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1231 Through Network Address Translators (NATs)", RFC 3489, 1232 March 2003. 1234 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1235 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1236 Zhang, L. and V. Paxson, "Stream Control Transmission 1237 Protocol", RFC 2960, October 2000. 1239 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1240 RFC 3753, June 2004. 1242 [I-D.ietf-tsvwg-addip-sctp] 1243 Stewart, R., "Stream Control Transmission Protocol (SCTP) 1244 Dynamic Address Reconfiguration", 1245 Internet-Draft draft-ietf-tsvwg-addip-sctp-10, January 1246 2005. 1248 [I-D.dupont-ikev2-addrmgmt] 1249 Dupont, F., "Address Management for IKE version 2", 1250 Internet-Draft draft-dupont-ikev2-addrmgmt-06, October 1251 2004. 1253 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, 1254 "On the Use of Stream Control Transmission Protocol (SCTP) 1255 with IPsec", RFC 3554, July 2003. 1257 [I-D.ietf-ipv6-optimistic-dad] 1258 Moore, N., "Optimistic Duplicate Address Detection for 1259 IPv6", Internet-Draft draft-ietf-ipv6-optimistic-dad-05, 1260 February 2005. 1262 [I-D.ietf-ipv6-unique-local-addr] 1263 Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 1264 Addresses", 1265 Internet-Draft draft-ietf-ipv6-unique-local-addr-09, 1266 January 2005. 1268 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G. and 1269 E. Lear, "Address Allocation for Private Internets", 1270 BCP 5, RFC 1918, February 1996. 1272 [RFC2367] McDonald, D., Metz, C. and B. Phan, "PF_KEY Key Management 1273 API, Version 2", RFC 2367, July 1998. 1275 [RFC2462] Thomson, S. and T. Narten, "IPv6 Stateless Address 1276 Autoconfiguration", RFC 2462, December 1998. 1278 [RFC2461] Narten, T., Nordmark, E. and W. Simpson, "Neighbor 1279 Discovery for IP Version 6 (IPv6)", RFC 2461, December 1280 1998. 1282 [Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet 1283 Location Management", In Proc. 18th Annual Computer 1284 Security Applications Conference, pages 78-87, Las Vegas, 1285 NV USA, December 2002. 1287 Authors' Addresses 1289 Tero Kivinen 1290 Safenet, Inc. 1291 Fredrikinkatu 47 1292 HELSINKI FIN-00100 1293 FI 1295 Email: kivinen@safenet-inc.com 1297 Hannes Tschofenig 1298 Siemens 1299 Otto-Hahn-Ring 6 1300 Munich, Bavaria 81739 1301 Germany 1303 Email: Hannes.Tschofenig@siemens.com 1304 URI: http://www.tschofenig.com 1306 Intellectual Property Statement 1308 The IETF takes no position regarding the validity or scope of any 1309 Intellectual Property Rights or other rights that might be claimed to 1310 pertain to the implementation or use of the technology described in 1311 this document or the extent to which any license under such rights 1312 might or might not be available; nor does it represent that it has 1313 made any independent effort to identify any such rights. Information 1314 on the procedures with respect to rights in RFC documents can be 1315 found in BCP 78 and BCP 79. 1317 Copies of IPR disclosures made to the IETF Secretariat and any 1318 assurances of licenses to be made available, or the result of an 1319 attempt made to obtain a general license or permission for the use of 1320 such proprietary rights by implementers or users of this 1321 specification can be obtained from the IETF on-line IPR repository at 1322 http://www.ietf.org/ipr. 1324 The IETF invites any interested party to bring to its attention any 1325 copyrights, patents or patent applications, or other proprietary 1326 rights that may cover technology that may be required to implement 1327 this standard. Please address the information to the IETF at 1328 ietf-ipr@ietf.org. 1330 Disclaimer of Validity 1332 This document and the information contained herein are provided on an 1333 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1334 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1335 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1336 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1337 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1338 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1340 Copyright Statement 1342 Copyright (C) The Internet Society (2005). This document is subject 1343 to the rights, licenses and restrictions contained in BCP 78, and 1344 except as set forth therein, the authors retain all their rights. 1346 Acknowledgment 1348 Funding for the RFC Editor function is currently provided by the 1349 Internet Society.