idnits 2.17.1 draft-ietf-mobike-design-01.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 1275. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1252. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1259. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1265. ** 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 (December 31, 2004) is 7048 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: A later version (-06) exists of draft-ietf-ipsec-rfc2401bis-05 -- 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-00 == Outdated reference: A later version (-03) exists of draft-ietf-mip6-ro-sec-02 == Outdated reference: A later version (-05) exists of draft-ietf-hip-mm-00 -- 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-09 == Outdated reference: A later version (-08) exists of draft-dupont-ikev2-addrmgmt-06 Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 11 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: July 1, 2005 Siemens 6 December 31, 2004 8 Design of the MOBIKE Protocol 9 draft-ietf-mobike-design-01.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 July 1, 2005. 38 Copyright Notice 40 Copyright (C) The Internet Society (2004). 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 61 3.1 Mobility Scenario . . . . . . . . . . . . . . . . . . . . 6 62 3.2 Multihoming Scenario . . . . . . . . . . . . . . . . . . . 7 63 3.3 Multihomed Laptop Scenario . . . . . . . . . . . . . . . . 8 64 4. Framework . . . . . . . . . . . . . . . . . . . . . . . . . . 9 65 5. Design Considerations . . . . . . . . . . . . . . . . . . . . 12 66 5.1 Indicating Support for MOBIKE . . . . . . . . . . . . . . 12 67 5.2 Changing a Preferred Address and Multihoming Support . . . 12 68 5.2.1 Storing a single or multiple addresses . . . . . . . . 13 69 5.2.2 Indirect or Direct Indication . . . . . . . . . . . . 14 70 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection . . 15 71 5.3 Simultaneous Movements . . . . . . . . . . . . . . . . . . 16 72 5.4 NAT Traversal . . . . . . . . . . . . . . . . . . . . . . 17 73 5.5 Changing addresses or changing the paths . . . . . . . . . 18 74 5.6 Return Routability Tests . . . . . . . . . . . . . . . . . 19 75 5.7 Employing MOBIKE results in other protocols . . . . . . . 21 76 5.8 Scope of SA changes . . . . . . . . . . . . . . . . . . . 22 77 5.9 Zero Address Set . . . . . . . . . . . . . . . . . . . . . 23 78 5.10 IPsec Tunnel or Transport Mode . . . . . . . . . . . . . . 24 79 5.11 Message Representation . . . . . . . . . . . . . . . . . . 24 80 6. Security Considerations . . . . . . . . . . . . . . . . . . . 26 81 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 82 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 28 83 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 84 9.1 Normative references . . . . . . . . . . . . . . . . . . . . 29 85 9.2 Informative References . . . . . . . . . . . . . . . . . . . 29 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 30 87 Intellectual Property and Copyright Statements . . . . . . . . 32 89 1. Introduction 91 IKEv2 is used for performing mutual authentication and establishing 92 and maintaining IPsec security associations (SAs). IKEv2 establishes 93 both cryptographic state (such as session keys and algorithms) as 94 well as non-cryptographic information (such as IP addresses). 96 The current IKEv2 and IPsec documents explicitly say that the IPsec 97 and IKE SAs are created implicitly between the IP address pair used 98 during the protocol execution when establishing the IKEv2 SA. This 99 means that there is only one IP address pair stored for the IKEv2 SA, 100 and this single IP address pair is used as an outer endpoint address 101 for tunnel mode IPsec SAs. After the IKE SA is created there is no 102 way to change them. 104 There are scenarios where this IP address might change, even 105 frequently. In some cases the problem could be solved by rekeying 106 all the IPsec and IKE SAs after the IP address has changed. However, 107 this can be problematic, as the device might be too slow to rekey the 108 SAs that often, and other scenarios the rekeying and required IKEv2 109 authentication might require user interaction (SecurID cards etc). 110 Due to these reasons, a mechanism to update the IP addresses tied to 111 the IPsec and IKEv2 SAs is needed. MOBIKE provides solution to the 112 problem of the updating the IP addresses stored with IKE SAs and 113 IPsec SAs. 115 The charter of the MOBIKE working group requires IKEv2 116 [I-D.ietf-ipsec-ikev2], and as IKEv2 assumes that the RFC2401bis 117 architecture [I-D.ietf-ipsec-rfc2401bis] is used, all protocols 118 developed will use both IKEv2 and RFC2401bis. No effort is to be 119 made to make protocols for IKEv1 [RFC2409] or old RFC2401 120 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 terms in useful 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 This definition is reused from 142 [I-D.arkko-multi6dt-failure-detection] and refers to addresses 143 which are available by an peer. A few conditions must hold before 144 an address in such a state. 146 Locally Operational Address: 148 An available address is said to be locally operational when its 149 use is known to be possible locally. This definition is taken 150 from [I-D.arkko-multi6dt-failure-detection]. 152 Operational address pair: 154 A pair of operational addresses are said to be an operational 155 address pair, iff bidirectional connectivity can be shown between 156 the two addresses. Note that sometimes it is necessary to 157 consider a 5-tuple when connectivity between two endpoints need to 158 be tested. This differentiation might be necessary to address 159 load balancers, certain Network Address Translation types or 160 specific firewalls. This definition is taken from 161 [I-D.arkko-multi6dt-failure-detection] and enhanced to fit the 162 MOBIKE context. Although it is possible to further differentiate 163 unidirectional and bidirectional operational address pairs only 164 bidirectional connectivity is relevant for this document and 165 unidirectional connectivity is out of scope. 167 Path: 169 The route taken by the MOBIKE and/or IPsec packets sent via the IP 170 address of one peer to a specific destination address of the other 171 peer. Note that the path might be effected not only by the source 172 and destination IP addresses but also by the selected transport 173 protocol and transport protocol identifier. Since MOBIKE and 174 IPsec packets have a different appearance on the wire they might 175 be routed along a different path. This definition is taken from 176 [RFC2960] and modified to fit the MOBIKE context. 178 Primary Path: 180 The primary path is the destination and source address that will 181 be put into a packet outbound to the peer by default. This 182 definition is taken from [RFC2960] and modified to fit the MOBIKE 183 context. 185 Preferred Address: 187 An address on which a peer prefers to receive MOBIKE messages and 188 IPsec protected data traffic. A given peer has only one active 189 preferred address at a given point in time (ignoring the small 190 time period where it needs to switch from the old preferred 191 address to a new preferred address). This definition is taken 192 from [I-D.ietf-hip-mm] and modified to fit the MOBIKE context. 194 Peer Address Set: 196 A subset of locally operational addresses that will sent 197 communicated to another peer. A policy available at the peer 198 indicates which addresses to include in the peer address set. 199 Such a policy might be impacted by manual configuration or by 200 interaction with other protocols which indicate newly available 201 addresses. Note that the addresses in the peer address set might 202 change over time. 204 Preferred Address Pair: 206 This address pair taken from the peer address set is used for 207 communication. The preferred address pair is used (1) for MOBIKE 208 communication where only two IP addresses are used and (2) as the 209 outer IP addresses (source and destination IP address) of the 210 IPsec packet in tunnel mode. 212 Terminology for different NAT types, such as Full Cone, Restricted 213 Cone, Port Restricted Cone and Symmetric, can be found in Section 5 214 of [RFC3489]. For mobility related terminology, such as 215 Make-before-break or Break-before-make see [RFC3753]. 217 3. Scenarios 219 The MOBIKE protocol can be used in different scenarios. Three of 220 them are discussed below. 222 3.1 Mobility Scenario 224 Figure 1 shows a break-before-make mobility scenario where a mobile 225 node attaches to, for example a wireless LAN, to obtain connectivity 226 to some security gateway. This security gateway might connect the 227 mobile node to a corporate network, to a UTMS network or to some 228 other network. The initial IKEv2 exchange takes place along the path 229 labeled as 'old path' from the MN using its old IP address via the 230 old access router (OAR) towards the security gateway (GW). The IPsec 231 tunnel mode terminates there but the decapsulated data packet will 232 typically address another destination. Since only MOBIKE is relevant 233 for this discussion the end-to-end communication between the MN and 234 some destination server is not shown in Figure 1. 236 When the MN moves to a new network and obtains a new IP address from 237 a new access router (NAR) it is the responsibility of MOBIKE to avoid 238 restarting the IKEv2 exchange from scratch. As a result, some form 239 of protocol exchange, denoted as 'MOBIKE Address Update', will 240 perform the necessary state update. The protocol messages will 241 travel along a new path whereby the old path and the new path will 242 meet at the cross-over router. 244 Note that in a break-before-make mobility scenario the MN obtains a 245 new IP address after reachability to the old IP address has been 246 lost. MOBIKE is also assumed to work in scenarios where the mobile 247 node is able to establish connectivity with the new IP address while 248 still being reachable at the old IP address. 250 (Initial IKEv2 Exchange) 251 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>v 252 Old IP +--+ +---+ v 253 address |MN|------> |OAR| -------------V v 254 +--+ +---+ Old path V v 255 . +----+ v>>>>> +--+ 256 .move | CR | -------> |GW| 257 . | | >>>>> | | 258 v +----+ ^ +--+ 259 +--+ +---+ New path ^ ^ 260 New IP |MN|------> |NAR|--------------^ ^ 261 address +--+ +---+ ^ 262 >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>^ 263 (MOBIKE Address Update) 265 ---> = Path taken by data packets 266 >>>> = Signaling traffic (IKEv2 and MOBIKE) 267 ...> = End host movement 269 Figure 1: Mobility Scenario 271 3.2 Multihoming Scenario 273 Another scenario where MOBIKE might be used is between two peers 274 equipped with multiple interfaces (and multiple IP addresses). 275 Figure 2 shows two such multi-homed peers. Peer A has two interface 276 cards with two IP addresses IP_A1 and IP_A2. Additionally, Peer B 277 also has two IP addresses, IP_B1 and IP_B2. Each peer selects one of 278 its IP addresses as the preferred address which will subsequently be 279 used for communication. Various reasons, such as problems with the 280 interface card, might require a peer to switch from one IP address to 281 the other one. 283 +------------+ +------------+ 284 | Peer A | *~~~~~~~~~* | Peer B | 285 | |>>>>>>>>>> * Network *>>>>>>>>>>| | 286 | IP_A1 +-------->+ +--------->+ IP_B1 | 287 | | | | | | 288 | IP_A2 +********>+ +*********>+ IP_B2 | 289 | | * * | | 290 +------------+ *~~~~~~~~~* +------------+ 292 ---> = Path taken by data packets 293 >>>> = Signaling traffic (IKEv2 and MOBIKE) 294 ***> = Potential future path through the network 295 (if Peer A and Peer B chance their preferred 296 address) 298 Figure 2: Multihoming Scenario 300 Note, that the load-balancing inside one IKE SA is not provided by 301 the MOBIKE protocol. Each client uses only one of the available IP 302 addresses at a given point in time. 304 3.3 Multihomed Laptop Scenario 306 In the multihomed laptop scenario we consider a laptop, which has 307 multiple interface cards and therefore several ways to connect to a 308 network. It might for example have a fixed Ethernet, WLAN, GPRS, 309 Bluetooth or USB hardware in order to sent IP packets. Some of these 310 interfaces might connected to a network over the time depending on a 311 number of reasons (e.g., cost, availability of certain link layer 312 technologies, user convenience). For example, the user can 313 disconnect himself from the fixed Ethernet, and then use the office 314 WLAN, and then later leave the office and start using GPRS during the 315 trip to home. At home he might again use again WLAN. At a certain 316 point in time multiple interfaces might be connected. As such, the 317 laptop is a multihomed device. In any case, the IP address of the 318 individual interfaces are subject to change. 320 The user desires to keep the established IKE-SA and IPsec SAs alive 321 all time without the need to re-run the initial IKEv2 exchange which 322 could require user interaction as part of the authentication process. 323 Furthermore, even if IP addresses change due to interface switching 324 or mobility, the IP source and destination address obtained via the 325 configuration payloads within IKEv2 and used inside the IPsec tunnel 326 remains unaffected, i.e., applications might not detect any change at 327 all. 329 4. Framework 331 Initially, when a MOBIKE peer starts and executes the initial 332 protocol exchange with its MOBIKE peer it needs to setup a peer 333 address set based on the available addresses. It might want to make 334 this peer address set available to the other peer. The Initiator 335 does not need to explicitly indicate its preferred address since 336 already using its preferred address. The outgoing IKEv2 and MOBIKE 337 messages use this preferred address as the source IP address and 338 expects incoming signaling messages to be addressed to this address. 340 Interaction with other protocols at the MOBIKE host is required to 341 build the peer address set and the preferred address. In some cases 342 the peer address set is available before the initial protocol run and 343 does not change during the lifetime of the IKE-SA. The preferred 344 address might change due to policy reasons. In many other cases, as 345 motivated in Section 3 the peer address set is modified (by adding or 346 deleting addresses) and the preferred address needs to be changed as 347 well. 349 Modifying the peer address set or changing the preferred address is 350 effected by the host's local policy and by the interaction with other 351 protocols (such as DHCP or IPv6 Neighbor Discovery). 353 Figure 3 shows an example protocol interaction at a MOBIKE peer. 354 MOBIKE interacts with the IPsec engine using the PF_KEY interface to 355 create entries in the Security Association and Security Policy 356 Databases. The IPsec engine might also interact with IKEv2 and 357 MOBIKE. Established state at the IPsec databases has an impact on 358 the incoming and outgoing data traffic. MOBIKE receives information 359 from other protocols running in both kernel-mode and user-mode, as 360 previously mentioned. Information relevant for MOBIKE is stored in a 361 database, referred as Trigger database which guides MOBIKE in its 362 decisions regarding the available addresses, peer address set and the 363 preferred address. Policies might affect the selection process. 365 Building and maintaining a peer address set and selecting or changing 366 a preferred address based on locally available information is, 367 however, insufficient. This information needs to be available to the 368 other peer and in order to address various failure cases it is 369 necessary to test connectivity along a path. A number of address 370 pairs might be available for connectivity tests but most important is 371 the source and the destination IP address of the preferred address 372 pair since these addresses are selected for sending and receiving 373 MOBIKE signaling messages and for sending and receiving IPsec 374 protected data traffic. If a problem along this primary path is 375 detected (e.g., due to a router failure) it is necessary to switch to 376 the new preferred address pair. Testing other paths might also be 377 useful to notice when a disconnected path is operational again. 379 +-------------+ +---------+ 380 |User-space | | MOBIKE | 381 |Protocols | +-->>| Daemon | 382 |relevant for | | | | 383 |MOBIKE | | +---------+ 384 +-------------+ | ^ 385 User Space ^ | ^ 386 ++++++++++++++++++++++++++++ API ++++++ API ++++ PF_KEY ++++++++ 387 Kernel Space v | v 388 _______ | v 389 +-------------+ / \ | +--------------+ 390 |Routing | / Trigger \ | | IPsec | 391 |Protocols |<<-->>| Database |<<-+ +>+ Engine | 392 | | \ / | | (+Databases) | 393 +-----+---+---+ \_______/ | +------+-------+ 394 ^ ^ ^ | ^ 395 | +---------------+-------------+--------+-----+ 396 | v | | | 397 | +-------------+ | | | 398 I | |Kernel-space | | | | I 399 n | +-------->+Protocols +<----+-----+ | | n 400 t v v |relevant for | | v v v t 401 e +----+---+-+ |MOBIKE | | +-+--+-----+-+ e 402 r | Input | +-------------+ | | Outgoing | r 403 f | Packet +<--------------------------+ | Interface | f 404 ==a>|Processing|===============================| Processing |=a> 405 c | | | | c 406 e +----------+ +------------+ e 407 s s 409 ===> = IP packets arriving/leaving a MOBIKE node 410 <-> = control and configuration operations 412 Figure 3: Framework 414 Although the interaction with other protocols is important for MOBIKE 415 to operate correctly the working group is chartered to leave this 416 aspect outside the scope. The working group will develop a MOBIKE 417 protocol which needs to perform the following functionality: 418 o Ability to inform a peer about the peer address set 419 o Ability to inform a peer about the preferred address 420 o Ability to test connectivity along a path and thereby to detect an 421 outage situation in order to fall back to another preferred 422 address, if necessary, or to change the peer address set 424 o Ability to deal with Network Address Translation devices 426 In addition to the above-listed functionality security is important 427 to the working group. For example, the ability to prevent flooding 428 attacks based on announcing someone else's address needs to be dealt 429 with. 431 Extensions of the PF_KEY interface required by MOBIKE are also within 432 the scope of the working group. Finally, optimizations in wireless 433 environment will also be covered. 435 Note that MOBIKE is somewhat different compared to, for example, SCTP 436 mobility since both the IKE-SA and the IPsec SA is affected by the 437 change of addresses. 439 5. Design Considerations 441 This section discusses aspects affecting the design of the MOBIKE 442 protocol. 444 5.1 Indicating Support for MOBIKE 446 A node needs to be able to guarantee that its address change messages 447 are understood by its corresponding peer. Otherwise an address 448 change may render the connection useless, and it is important that 449 both sides realize this as early as possible. 451 Ensuring that the messages are understood can in be arranged either 452 by marking some IKEv2 payloads critical so that they are either 453 processed or an error message is returned, by using Vendor ID 454 payloads or via a Notify. 456 The first solution approach is to use Vendor ID payloads during the 457 initial IKEv2 exchange using a specific string denoting MOBIKE to 458 signal the support of the MOBIKE protocol. This ensures that in all 459 cases a MOBIKE capable node knows whether its peer supports MOBIKE or 460 not. 462 The second solution approach uses the Notify payload which is also 463 used for NAT detection (via NAT_DETECTION_SOURCE_IP and 464 NAT_DETECTION_DESTINATION_IP). 466 Both, a Vendor ID and a Notify payload, might be used to indicate the 467 support of certain extensions. 469 Note that the node could also attempt MOBIKE optimistically with the 470 critical bit set to one when a movement has occurred. The drawback 471 of this approach is, however, that the an unnecessary MOBIKE message 472 round is introduced on the first movement. 474 Although Vendor ID payloads and Notifications are technically 475 equivalent Notifications are already used in IKEv2 as a capability 476 negotiation mechanism and is therefore the preferred mechanism. 478 5.2 Changing a Preferred Address and Multihoming Support 480 From MOBIKE's point of view multihoming support is integrated by 481 supporting a peer address set rather than a single address and 482 protocol mechanisms to change to use a new preferred IP address. 483 From a protocol point of view each peer needs to learn the preferred 484 address and the peer address set somehow, implicitly or explicitly. 486 5.2.1 Storing a single or multiple addresses 488 One design decision is whether an IKE-SA should store a single IP 489 address or multiple IP addresses as part of the peer address set. 490 One option is that the other end can provide a list of addresses 491 which can be used as destination addresses. MOBIKE does not include 492 load balancing, i.e., only one IP address is set to a preferred 493 address at a time and changing the preferred address typically 494 requires some MOBIKE signaling. 496 Another option is to only communicate one address towards the other 497 peer and both peers only use that address when communicating. If 498 this preferred address cannot be used anymore then an address update 499 is sent to the other peer changing the primary address. 501 If peer A provides a peer address set with multiple IP addresses then 502 peer B can recover from a failure of the preferred address on its 503 own, meaning that when it detects that the primary path does not work 504 anymore it can either switch to a new preferred address locally 505 (i.e., causing the source IP address of outgoing MOBIKE messages to 506 have a non-preferred address) or to try an IP address from A's peer 507 address set. If peer B only received a single IP address as the A's 508 peer address set then peer B can only change its own preferred 509 address. The other end has to wait for an address update from peer A 510 with a new IP address in order to fix the problem. The main 511 advantage about using a single IP address for the remote host is that 512 it makes retransmission easy, and it also simplifies the recover 513 procedure. The peer, whose IP address changed, must start recovery 514 process and send the new IP address to the other peer. Failures 515 along the path are not well covered with advertising a single IP 516 address. 518 The single IP address approach will not work if both peers happen to 519 loose their IP address at the same time (due to, say, the failure of 520 one of the links that both nodes are connected to). It may also 521 require the IKEv2 window size to be larger than 1, especially if only 522 direct indications are used. This is because the host needs to be 523 able to send the IP address change notifications before it can switch 524 to another address, and depending on the return routability checks, 525 retransmissions policies etc, it might be hard to make the protocol 526 such that it works with window size of 1 too. Furthermore, the 527 single IP address approach does not really benefit much from indirect 528 indications as the peer receiving these indications might not be able 529 to fix the situation by itself (e.g., even if a peer receives an ICMP 530 host unreachable message for the old IP address, it cannot try other 531 IP addresses, since they are unknown). 533 The problems with IP address list are mostly in its complexity. 535 Notification and recovery processes are more complex, as both end can 536 recover from the IP address changes. There is also possibilities 537 that both ends tries to recover at the same time and this must be 538 taken care in the protocol. 540 Please note that the discussed aspect is partially different from the 541 question how many addresses to sent in a single MOBIKE message. A 542 MOBIKE message might be able to carry more than one IP address (with 543 the IP address list approach) or a single address only. The latter 544 approach has the advantage of dealing with NAT traversal in a proper 545 fashion. A NAT cannot change addresses carried inside the MOBIKE 546 message but it can change IP address (and transport layer addresses) 547 in the IP header and Transport Protocol header (if NAT traversal is 548 enabled). Furthermore, a MOBIKE message carrying the peer address 549 set could be idempotent (i.e., always resending the full address 550 list) or does the protocol allow add/delete operations to be 551 specified. [I-D.dupont-ikev2-addrmgmt], for example, offers an 552 approach which defines add/delete operations. The same is true for 553 the dynamic address reconfiguration extension for SCTP 554 [I-D.ietf-tsvwg-addip-sctp]. 556 5.2.2 Indirect or Direct Indication 558 An indication to change the preferred IP address might be either 559 direct or indirect. 561 Direct indication: 563 A direct indication means that the other peer will send an message 564 with the address change. Such a message can, for example, 565 accomplished by having MOBIKE sending an authenticated address 566 update notification with a different preferred address. 568 Indirect indication: 570 An indirect indication to change the preferred address can be 571 obtained by observing the environment. An indirect indication 572 might, for example, be be the receipt of an ICMP message or 573 information of a link failure. This information should be seen as 574 a hint and might not directly cause any changes to the preferred 575 address. Depending on the local policy MOBIKE might decide to 576 perform a dead-peer detection exchange for the preferred address 577 pair (or another address pair from the peer address set). When a 578 peer detects that the other end started to use different source IP 579 address than before, it might want to authorize the new preferred 580 address (if not already authorized). A peer might also start a 581 connectivity test of this particular address.If a bidirectionally 582 operational address pair is selected then MOBIKE needs to 583 communicate this new preferred address to its remote peer. 585 MOBIKE will utilize both mechanisms, direct and indirect indications, 586 to make a more intelligent decision which address pair to select as 587 the preferred address. The more information will be available to 588 MOBIKE the faster a new operational preferred address pair can be 589 selected among the available candiates. 591 5.2.3 Connectivity Tests using IKEv2 Dead-Peer Detection 593 This section discusses the suitability of the IKEv2 dead-peer 594 detection (DPD) mechanism for connectivity tests between address 595 pairs. The basic IKEv2 DPD mechanism is not modified by MOBIKE but 596 it needs to be investigated whether it can be used for MOBIKE 597 purposes as well. 599 The IKEv2 DPD mechanism is done by sending an empty informational 600 exchange packet to the other peer, in which case the other end will 601 respond with an acknowledgement. If no acknowledgement is received 602 after certain timeout (and after couple of retransmissions), the 603 other peer is considered to be not reachable. Note that the receipt 604 of IPsec protected data traffic is also a guarantee that the other 605 peer is alive. 607 When reusing dead-peer detection in MOBIKE for connectivity tests it 608 seems to be reasonable to try other IP addresses (if they are 609 available) in case of unsuccessful connectivity test for a given 610 address pair. Dead-peer detection messages using a different address 611 pair should use the same message-id as the original dead-peer 612 detection message (i.e. they are simply retransmissions of the 613 dead-peer detection packet using different destination IP address). 614 If different message-id is used then it violates constraints placed 615 by the IKEv2 specification on the DPD message with regard to the 616 mandatory ACK for each message-id, causing the IKEv2 SA to be 617 deleted. 619 If MOBIKE strictly follows the guidelines of the dead-peer detection 620 mechanism in IKEv2 then an IKE-SA should be marked as dead and 621 deleted if the connectivity test for all address pairs fails. Note 622 that this is not in-line with the approach used, for example, in SCTP 623 where a failed connectivity test for an address does not lead to (a) 624 the IP address or IP address pair to be marked as dead and (b) delete 625 state. Connectivity tests will be continued for the address pairs in 626 hope that the problem will recover soon. 628 Note, that as IKEv2 implementations might have window size of 1, 629 which prevents to initiate a dead-peer detection exchange while doing 630 another exchange. As a result all other exchanges experience the 631 identical retransmission policy as used for the dead-peer detection. 633 The dead-peer detection for the other IP address pairs can also be 634 executed simultaneously (with a window size larger than 1), meaning 635 that after the initial timeout of the preferred address expires, we 636 send packets simultaneously to all other address pairs. It is 637 necessary to differentiate individual acknowledgement messages in 638 order to determine which address pair is operational. Therefore the 639 source IP address of the acknowledgement should match the destination 640 IP towards the message was previously sent. 642 Also the other peer is most likely going to reply only to the first 643 packet it receives, and that first packet might not be the best (by 644 whatever criteria) address pair. The reason the other peer is only 645 responding to the first packet it receives, is that implementations 646 should not send retransmissions if they have just sent out identical 647 response message. This is to protect the packet multiplication 648 problem, which can happen if some node in the network queues up 649 packets and then send them to the destination. If destination will 650 reply to all of them then the other end will again see multiple 651 packets, and will reply to all of them etc. 653 The protocol should also be nice to the network, meaning, that when 654 some core router link goes down, and a large number of MOBIKE clients 655 notice it, they should not start sending a large number of messages 656 while trying to recover from the problem. This might be especially 657 bad if this happens because packets are dropped because of the 658 congested network. If MOBIKE clients simultaneously try to test all 659 possible address pairs by executing connectivity tests then the 660 congestion problem only gets worse. 662 Also note, that the IKEv2 dead-peer detection is not sufficient for 663 the return routability check. See Section 5.6 for more information. 665 5.3 Simultaneous Movements 667 MOBIKE does not aim to provide a full mobility solution which allows 668 simultaneous movements. Instead, the MOBIKE working group focuses on 669 selected scenarios as described in Section 3. Some of the scenarios 670 assume that one peer has a fixed set of addresses (from which some 671 subset might be in use). Thus it cannot move to the address unknown 672 to the other peer. Situations where both peers move and the movement 673 notifications cannot reach the other peer, is outside the scope of 674 the MOBIKE WG. MOBIKE has not being chartered to deal with the 675 rendezvous problem, or with the introduction of any new entities in 676 the network. 678 Note, that if only a single address is stored in the peer address set 679 (instead of an address list) we might end up in the case where it 680 seems that both peers changed their addresses at the same time. This 681 is something that the protocol must deal with. 683 Three cases can be differentiated: 685 o Two mobile nodes obtain a new address at the same time, and then 686 being unable to tell each other where they are (in a 687 break-before-make scenario). This problem is called the 688 rendezvous problem, and is traditionally solved by introducing 689 another third entity, for example, the home agents (in Mobile 690 IPv4/IPv6) or forwarding agents (in Host Identity Protocol). 691 Essentially, solving this problem requires the existence of a 692 stable infrastructure node somewhere. 694 o Simultaneous changes to addresses such that at least one of the 695 new addresses is known to the other peer before the change 696 occurred. 698 o No simultaneous changes at all. 700 5.4 NAT Traversal 702 IKEv2 has support of legacy NAT traversal built-in. This feature is 703 known as NAT-T which allows IKEv2 to work even if a NAT along the 704 path between the Initiator and the Responder modified the source and 705 possibly the destination IP address. With NAPT even the transport 706 protocol identifiers are modified (which then requires UDP 707 encapsulation for subsequent IPsec protected data traffic). 708 Therefore, the required IP address information is taken from the IP 709 header (if a NAT was detected who rewrote IP header information) 710 rather than from the protected payload. This problem is not new and 711 was discovered during the design of mobility protocol where the only 712 valuable information is IP address information. 714 One of the goals in the MOBIKE protocol is to securely exchange one 715 or more addresses of the peer address set and to securely set the 716 primary address. If not other protocol is used to securely retrieve 717 the IP address and port information allocated by the NAT then it is 718 not possible to tackle all attacks against MOBIKE. Various solution 719 approaches have been presented: 721 o Securely retrieving IP address and port information allocated by 722 the NAT using a protocol different from MOBIKE. This approach is 723 outside the scope of the MOBIKE working group since other working 724 groups, such as MIDCOM and NSIS, already deal with this problem. 725 The MOBIKE protocol can benefit from the interaction with these 726 protocols. 728 o Design a protocol in such a way that NAT boxes are able to inspect 729 (or even participate) in the protocol exchange. This approach was 730 taken with HIP but is not an option for IKEv2 and MOBIKE. 732 o Disable NAT-T support by indicating the desire never to use 733 information from the (unauthenticated) header. While this 734 approach prevents some problems it effectively disallows the 735 protocol to work in certain environments. 737 There is no way to distinguish the cases where there is NAT along the 738 path which modifies the header information in packets or whether an 739 adversary mounts an attack. If NAT is detected in the IKE SA 740 creation, that should automatically disable the MOBIKE extensions and 741 use NAT-T. 743 A design question is whether NAT detection capabilities should be 744 enabled only during the initial exchange or even at subsequent 745 message exchanges. If MOBIKE is executed with no NAT along the path 746 when the IKE SA was created, then a NAT which appears after moving to 747 a new network might cannot be dealt with if NAT detection is enabled 748 only during the initial exchange. Hence, it might be desirable to 749 also support scenario where a MOBIKE peer moves from a network which 750 does not deploy a NAT to a network which uses a private address 751 space. 753 A NAT prevention mechanism can be used to make sure that no adversary 754 can interact with the protocol if no NAT is expected between the 755 Initiator and the Responder. 757 The support for NAT traversal is certainly one of the most important 758 design decisions with an impact on other protocol aspects. 760 5.5 Changing addresses or changing the paths 762 A design decision is whether it is enough for the MOBIKE protocol to 763 detect dead address, or does it need to detect also dead paths. Dead 764 address detection means that we only detect that we cannot get 765 packets through to that remote address by using the local IP address 766 given by the local IP-stack (i.e., local address selected normally by 767 the routing information). Dead path detection means that we need to 768 try all possible local interfaces/IP addresses for each remote 769 addresses, i.e., find all possible paths between the hosts and try 770 them all to see which of them work (or at least find one working 771 path). 773 While performing just an address change is simpler, the existence of 774 locally operational addresses are not, however, a guarantee that 775 communications can be established with the peer. A failure in the 776 routing infrastructure can prevent the sent packets from reaching 777 their destination. Or a failure of an interface on one side can be 778 related to the failure of an interface on the other side, making it 779 necessary to change more than one address at a time. 781 5.6 Return Routability Tests 783 Setting a new preferred address which is subsequently used for 784 communication is associated with an authorization decision: Is a peer 785 allowed to use this address? Does this peer own this address? Two 786 mechanisms have been proposed in the past to allow a peer to compute 787 the answer to this question: 789 o The addresses a peer is using is part of a certificate. [RFC3554] 790 introduced this approach. If the other peer is, for example, a 791 security gateway with a limited set of fixed IP addresses, then 792 the security gateway may have a certificate with all the IP 793 addresses in the certificate. 795 o A return routability check is performed before the address is used 796 to ensure that the peer is reachable at the indicated address. 798 Without performing an authorization decision a malicious peer can 799 redirect traffic towards a third party or a blackhole. 801 An IP address should not be used as a primary address without 802 computing the authorization decision. If the addresses are part of 803 the certificate then it is not necessary execute the weaker return 804 routability test. If multiple addresses are communicated to another 805 peer as part of the peer address set then some of these addresses 806 might be already verified even if the primary address is still 807 operational. 809 Another option is to use the [I-D.dupont-mipv6-3bombing] approach 810 which suggests to do a return routability test only if you have to 811 send an address update from some other address than the indicated 812 preferred address. 814 Finally it would be possible not to execute return routability checks 815 at all. In case of indirect change notifications then we only move 816 to the new preferred address after successful dead-peer detection on 817 the new address, which is already a return routability check. With a 818 direct notifications the authenticated peer may have provided an 819 authenticated IP address, thus we could simply trust the other end. 820 There is no way external attacker can cause any attacks, but we are 821 not protected by the internal attacker, i.e. the authenticated peer 822 forwarding its traffic to the new address. On the other hand we do 823 know the identity of the peer in that case. 825 As such, it sees that there it is also a policy issue when to 826 schedule a return routability test. 828 The basic format of the return routability check could be similar 829 than dead-peer detection, but the problem is that if that fails then 830 the IKEv2 specification requires the IKE SA to be deleted. Because 831 of this we might need to do some kind of other exchange. 833 There are potential attacks if a return routability checks include 834 some kind of nonce. In this attack the valid end points sends 835 address update notification for the third party, trying to get all 836 the traffic to be sent there, causing denial of service attack. If 837 the return routability checks does not contain any cookies or other 838 random information not known by the other end, then that valid node 839 could reply to the return routability checks even when it cannot see 840 the request. This might cause the other end to turn the traffic to 841 there, even when the true original recipient cannot be reached at 842 this address. 844 The IKEv2 NAT-T mechanism does not perform any return routability 845 checks. It simply uses the last seen source IP address used by the 846 other peer where to send response packets. An adversary can change 847 those IP addresses, and can cause the response packets to be sent to 848 wrong IP address. The situation is self-fixing when the adversary is 849 no longer able to modify packets and the first packet with true IP 850 address reaches the other peer. In a certain sense mobility handling 851 makes this attack difficult for an adversary since it needs to be 852 located somewhere along the path where the individual paths ({CoA1, 853 ..., CoAn} towards the destination IP address) have a shared path or 854 if the adversary is located near the MOBIKE client then it needs to 855 follow the users mobility patterns. With IKEv2 NAT-T the genuine 856 client can cause third party bombing by redirecting all the traffic 857 pointed to him to third party. As the MOBIKE protocol tries to 858 provide equal or better security than IKEv2 NAT-T the MOBIKE protocol 859 should protect against these attacks. 861 There might be also return routability information available from the 862 other parts of the system too (as shown in Figure 3), but the checks 863 done might have a different quality. There are multiple levels for 864 return routability checks: 866 o None, no tests 868 o A party willing to answer is on the path to the claimed address. 869 This is the basic form of return routability test. 871 o There is an answer from the tested address, and that answer was 872 authenticated (including the address) to be from our peer. 874 o There was an authenticated answer from the peer, but it is not 875 guaranteed to be from the tested address or path to it (because 876 the peer can construct a response without seeing the request). 878 The basic return routability checks do not protect against 3rd party 879 bombing, if the attacker is along the path, as the attacker can 880 forward the return routability checks to the real peer (even if those 881 packets are cryptographically authenticated). 883 If the address to be tested is inside the MOBIKE packet too, then the 884 adversary cannot forward packets, thus it prevents 3rd party 885 bombings. 887 If the reply packet can be constructed without seeing the request 888 packet (for example, if there is no nonce, challenge or similar 889 mechanism to show liveness), then the genuine peer can cause 3rd 890 party bombing, by replying to those requests without seeing them at 891 all. 893 Other levels might only provide information that there is someone at 894 the IP address which replied to the request. There might not be an 895 indication that the reply was freshly generated or repeated, or the 896 request might have been transmitted from a different source address. 898 Requirements for a MOBIKE protocol for the return routability test 899 might be able to verify that there is same (cryptographically) 900 authenticated node at the other peer and it can now receive packets 901 from the IP address it claims to have. 903 5.7 Employing MOBIKE results in other protocols 905 If MOBIKE has learned about new locations or verified the validity of 906 an address through a return routability test, can this information be 907 useful for other protocols? 909 When considering the basic MOBIKE VPN scenario, the answer is no. 910 Transport and application layer protocols running inside the VPN 911 tunnel have no consideration about the outer addresses or their 912 status. 914 Similarly, IP layer tunnel termination at a gateway rather than a 915 host endpoint limits the benefits for "other protocols" that could be 916 informed -- all application protocols at the other side are running 917 in a node that is unaware of IPsec, IKE, or MOBIKE. 919 However, it is conceivable that future uses or extensions of the 920 MOBIKE protocol make such information distribution useful. For 921 instance, if transport mode MOBIKE and SCTP were made to work 922 together, it would likely be useful for SCTP to learn about the new 923 addresses at the same time as MOBIKE learns them. Similarly, various 924 IP layer mechanisms might make use of the fact that a return 925 routability test of a specific type has already been performed. 926 However, in all of these cases careful consideration should be 927 applied. This consideration should answer to questions such as 928 whether other alternative sources exist for the information, whether 929 dependencies are created between parts that prior to this had no 930 dependencies, and what the impacts in terms of number of messages or 931 latency are. 933 [I-D.crocker-celp] discussed the use of common locator information 934 pools in IPv6 multihoming context; it assumed that both transport and 935 IP layer solutions would be used for providing multihoming, and that 936 it would be beneficial for different protocols to coordinate their 937 results in some manner, for instance by sharing experienced 938 throughput information for address pairs. This may apply to MOBIKE 939 as well, assuming it co-exists with non-IPsec protocols that are 940 faced with the same multiaddressing choices. 942 Nevertheless, all of this is outside the scope of current MOBIKE base 943 protocol design and may be addressed in future work. 945 5.8 Scope of SA changes 947 Most sections of this document discuss design considers for updating 948 and maintaining addresses for the IKE-SA. However, changing the 949 preferred address also has an impact for IPsec SAs. The outer tunnel 950 header addresses (source IP and destination IP addresses) need to be 951 modified according to the preferred address pair to allow the IPsec 952 protected data traffic to travel along the same path as the MOBIKE 953 packets (if we only consider the IP header information). 955 The basic question is that how the IPsec SAs are changed to use the 956 new address pair (the same address pair as the MOBIKE signaling 957 traffic -- the preferred address pair). One option is that when the 958 IKE SA address is changed then automatically all IPsec SAs associated 959 with it are moved along with it to new address pair. Another option 960 is to have separate exchange to move the IPsec SAs separately. 962 If IPsec SAs should be updated separately then a more efficient 963 format than notification payload is needed. A notification payload 964 can only store one SPI per payload. A separate payload which would 965 have list of IPsec SA SPIs and new preferred address. If there are 966 large number of IPsec SAs, those payloads can be quite large unless 967 ranges of SPI values are supported. If we automatically move all 968 IPsec SAs when the IKE SA moves, then we only need to keep track 969 which IKE SA was used to create the IPsec SA, and fetch the IP 970 addresses. Note that IKEv2 [I-D.ietf-ipsec-ikev2] already requires 971 implementations to keep track which IPsec SAs are created using which 972 IKE SA. 974 If we do allow each IPsec SAs address sets to be updated separately, 975 then we can support scenarios, where the machine has fast and/or 976 cheap connections and slow and/or expensive connections, and it wants 977 to allow moving some of the SAs to the slower and/or more expensive 978 connection, and prevents to move the news video stream from the WLAN 979 to the GPRS link. 981 On the other hand, even if we tie the IKE SA update to the IPsec SA 982 update, then we can create separate IKE SAs for this scenario, e.g., 983 we create one IKE SA which have both links as endpoints, and it is 984 used for important traffic, and then we create another IKE SA which 985 have only the fast and/or cheap connection, which is then used for 986 that kind of bulk traffic. 988 5.9 Zero Address Set 990 One of the features which might be useful would be for the peer to 991 announce the other end that it will now disconnect for some time, 992 i.e., it will not be reachable at all. For instance, a laptop might 993 go to suspend mode. In this case the peer could send address 994 notification with zero new addresses, which means that it will not 995 have any valid addresses anymore. The responder of that kind of 996 notification would then acknowledge that, and could then temporarily 997 disable all SAs. If any of the SAs gets any packets they are simply 998 dropped. This could also include some kind of ACK spoofing to keep 999 the TCP/IP sessions alive (or simply set the TCP/IP keepalives and 1000 timeouts large enough not to cause problems), or it could simply be 1001 left to the applications, e.g., allow TCP/IP sessions to notice the 1002 link is broken. 1004 The local policy could then decide how long the peer would allow 1005 other peers to be disconnected, e.g., whether this is only allowed 1006 for few minutes, or do they allow users to disconnect Friday evening 1007 and reconnect Monday morning (consuming resources during weekend too, 1008 but on the other hand not more than is normally used during week 1009 days, but we do not need lots of extra resources on the Monday 1010 morning to support all those people connecting back to network). 1012 From a technical point of view this features addresses two aspects: 1014 o There is no need to transmit IPsec data traffic. IPsec protected 1015 data needs to be dropped which saves bandwidth. This does not 1016 provide a functional benefit i.e, nothing breaks if this feature 1017 is not provided. 1019 o MOBIKE signaling messages are also ignored and need to be 1020 suspended. The IKE-SA must not be deleted and the suspend 1021 functionality (realized with the zero address set) might require 1022 the IKE-SA to be tagged with a lifetime value since the IKE-SA 1023 will not be kept in memory an arbitrary amount of time. Note that 1024 the IKE-SA has no lifetime associated with it. In order to 1025 prevent the IKE-SA to be deleted the dead-peer detection mechanism 1026 needs to be suspended as well. 1028 Due to the enhanced complexity of this extension a first version of 1029 the MOBIKE protocol will not provide this feature. 1031 5.10 IPsec Tunnel or Transport Mode 1033 Current MOBIKE design is focused only on the VPN type usage and 1034 tunnel mode. Transport mode behaviour would also be useful, but will 1035 be discussed in future documents. 1037 5.11 Message Representation 1039 The basic IP address change notifications can be sent either via an 1040 informational exchange already specified in the IKEv2, or via a 1041 MOBIKE specific message exchange. Using informational exchange has 1042 the main advantage that it is already specified in the IKEv2 and 1043 implementations incorporated the functionality already. 1045 Another question is the basic format of the address update 1046 notifications. The address update notifications can include multiple 1047 addresses, which some can be IPv4 and some IPv6 addresses. The 1048 number of addresses is most likely going to be quite small (less than 1049 10). The format might need to indicate a preference value for each 1050 address Furthermore, one of the addresses in the peer address set 1051 must be labeled as the preferred address. The format could either 1052 contain the preference number, giving out the relative order of the 1053 addresses, or it could simply be ordered list of IP addresses in the 1054 order of the most preferred first. While two addresses can have the 1055 same preference value an ordered list avoids this problem. 1057 Even if load balancing is currently outside the scope of MOBIKE, 1058 there might be future work to include this feature. The format 1059 selected needs to be flexible enough to include additional 1060 information (e.g., to enable load balancing). This might be 1061 something like one reserved field, which can later be used to store 1062 additional information. As there is other potential information 1063 which might have to be tied to the address in the future, a reserved 1064 field seems like a prudent design in any case. 1066 There are two basic formats for putting IP address list in to the 1067 exchange, we can include each IP address as separate payload (where 1068 the payload order indicates the preference value, or the payload 1069 itself might include the preference value), or we can put the IP 1070 address list as one payload to the exchange, and that one payload 1071 will then have internal format which includes the list of IP 1072 addresses. 1074 Having multiple payloads each having one IP address makes the 1075 protocol probably easier to parse, as we can already use the normal 1076 IKEv2 payload parsing procedures to get the list out. It also offers 1077 easy way for the extensions, as the payload probably contains only 1078 the type of the IP address (or the type is encoded to the payload 1079 type), and the IP address itself, and as each payload already has 1080 length associated to it, we can detect if there is any extra data 1081 after the IP address. Some implementations might have problems 1082 parsing too long list of IKEv2 payloads, but if the sender sends them 1083 in the most preferred first, the other end can simply only take n 1084 first addresses and use them. 1086 Having all IP addresses in one big MOBIKE specified internal format 1087 provides more compact encoding, and keeps the MOBIKE implementation 1088 more concentrated to one module. 1090 The next choice is which type of payloads to use. IKEv2 already 1091 specifies a notify payload. It includes some extra fields (SPI size, 1092 SPI, protocol etc), which gives 4 bytes of the extra overhead, and 1093 there is the notify data field, which could include the MOBIKE 1094 specific data. 1096 Another option would be to have a custom payload type, which then 1097 includes the information needed for the MOBIKE protocol. 1099 MOBIKE might send the full peer address list once one of the IP 1100 addresses changes (either addresses are added, removed, the order 1101 changes or the preferred address is updated) or an incremental 1102 update. Sending incremental updates provides more compact packets 1103 (meaning we can support more IP addresses), but on the other hand 1104 have more problems in the synchronization and packet reordering 1105 cases, i.e., the incremental updates must be processed in order, but 1106 for full updates we can simply use the most recent one, and ignore 1107 old ones, even if they arrive after the most recent one (IKEv2 1108 packets have message id which is incremented for each packet, thus we 1109 know the sending order easily). 1111 Note that each peer needs to communicate its peer address set to the 1112 other peer. 1114 6. Security Considerations 1116 As all the messages are already authenticated by the IKEv2 there is 1117 no problem that any attackers would modify the actual contents of the 1118 packets. The IP addresses in IP header of the packets are not 1119 authenticated, thus the protocol defined must take care that they are 1120 only used as an indication that something might be different, they 1121 should not cause any direct actions. 1123 Attacker can also spoof ICMP error messages in an effort to confuse 1124 the peers about which addresses are not working. At worst this 1125 causes denial of service and/or the use of non-preferred addresses, 1126 so it is not that serious. 1128 One type of attacks which needs to be taken care of the MOBIKE 1129 protocol is also various flooding attacks. See 1130 [I-D.ietf-mip6-ro-sec] and [Aur02] for more information about 1131 flooding attacks. 1133 7. IANA Considerations 1135 This document does not introduce any IANA considerations. 1137 8. Acknowledgments 1139 This document is the result of discussions in the MOBIKE working 1140 group. The authors would like to thank Jari Arkko, Pasi Eronen, 1141 Francis Dupont, Mohan Parthasarathy, Paul Hoffman, Bill Sommerfeld, 1142 James Kempf, Vijay Devarapalli, Atul Sharma, Bora Akyol and Joe Touch 1143 for their discussion input. 1145 9. References 1147 9.1 Normative references 1149 [I-D.ietf-ipsec-ikev2] 1150 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1151 draft-ietf-ipsec-ikev2-17 (work in progress), October 1152 2004. 1154 [I-D.ietf-ipsec-rfc2401bis] 1155 Kent, S. and K. Seo, "Security Architecture for the 1156 Internet Protocol", draft-ietf-ipsec-rfc2401bis-05 (work 1157 in progress), December 2004. 1159 9.2 Informative References 1161 [I-D.arkko-multi6dt-failure-detection] 1162 Arkko, J., "Failure Detection and Locator Selection in 1163 Multi6", draft-arkko-multi6dt-failure-detection-00 (work 1164 in progress), October 2004. 1166 [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange 1167 (IKE)", RFC 2409, November 1998. 1169 [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the 1170 Internet Protocol", RFC 2401, November 1998. 1172 [I-D.dupont-mipv6-3bombing] 1173 Dupont, F., "A note about 3rd party bombing in Mobile 1174 IPv6", draft-dupont-mipv6-3bombing-00 (work in progress), 1175 February 2004. 1177 [I-D.ietf-mip6-ro-sec] 1178 Nikander, P., "Mobile IP version 6 Route Optimization 1179 Security Design Background", draft-ietf-mip6-ro-sec-02 1180 (work in progress), October 2004. 1182 [I-D.ietf-hip-mm] 1183 Nikander, P., "End-Host Mobility and Multi-Homing with 1184 Host Identity Protocol", draft-ietf-hip-mm-00 (work in 1185 progress), October 2004. 1187 [I-D.crocker-celp] 1188 Crocker, D., "Framework for Common Endpoint Locator 1189 Pools", draft-crocker-celp-00 (work in progress), February 1190 2004. 1192 [RFC3489] Rosenberg, J., Weinberger, J., Huitema, C. and R. Mahy, 1193 "STUN - Simple Traversal of User Datagram Protocol (UDP) 1194 Through Network Address Translators (NATs)", RFC 3489, 1195 March 2003. 1197 [RFC2960] Stewart, R., Xie, Q., Morneault, K., Sharp, C., 1198 Schwarzbauer, H., Taylor, T., Rytina, I., Kalla, M., 1199 Zhang, L. and V. Paxson, "Stream Control Transmission 1200 Protocol", RFC 2960, October 2000. 1202 [RFC3753] Manner, J. and M. Kojo, "Mobility Related Terminology", 1203 RFC 3753, June 2004. 1205 [I-D.ietf-tsvwg-addip-sctp] 1206 Stewart, R., "Stream Control Transmission Protocol (SCTP) 1207 Dynamic Address Reconfiguration", 1208 draft-ietf-tsvwg-addip-sctp-09 (work in progress), June 1209 2004. 1211 [I-D.dupont-ikev2-addrmgmt] 1212 Dupont, F., "Address Management for IKE version 2", 1213 draft-dupont-ikev2-addrmgmt-06 (work in progress), October 1214 2004. 1216 [RFC3554] Bellovin, S., Ioannidis, J., Keromytis, A. and R. Stewart, 1217 "On the Use of Stream Control Transmission Protocol (SCTP) 1218 with IPsec", RFC 3554, July 2003. 1220 [Aur02] Aura, T., Roe, M. and J. Arkko, "Security of Internet 1221 Location Management", In Proc. 18th Annual Computer 1222 Security Applications Conference, pages 78-87, Las Vegas, 1223 NV USA, December 2002. 1225 Authors' Addresses 1227 Tero Kivinen 1228 Safenet, Inc. 1229 Fredrikinkatu 47 1230 HELSINKI FIN-00100 1231 FI 1233 EMail: kivinen@safenet-inc.com 1234 Hannes Tschofenig 1235 Siemens 1236 Otto-Hahn-Ring 6 1237 Munich, Bavaria 81739 1238 Germany 1240 EMail: Hannes.Tschofenig@siemens.com 1241 URI: http://www.tschofenig.com 1243 Intellectual Property Statement 1245 The IETF takes no position regarding the validity or scope of any 1246 Intellectual Property Rights or other rights that might be claimed to 1247 pertain to the implementation or use of the technology described in 1248 this document or the extent to which any license under such rights 1249 might or might not be available; nor does it represent that it has 1250 made any independent effort to identify any such rights. Information 1251 on the procedures with respect to rights in RFC documents can be 1252 found in BCP 78 and BCP 79. 1254 Copies of IPR disclosures made to the IETF Secretariat and any 1255 assurances of licenses to be made available, or the result of an 1256 attempt made to obtain a general license or permission for the use of 1257 such proprietary rights by implementers or users of this 1258 specification can be obtained from the IETF on-line IPR repository at 1259 http://www.ietf.org/ipr. 1261 The IETF invites any interested party to bring to its attention any 1262 copyrights, patents or patent applications, or other proprietary 1263 rights that may cover technology that may be required to implement 1264 this standard. Please address the information to the IETF at 1265 ietf-ipr@ietf.org. 1267 Disclaimer of Validity 1269 This document and the information contained herein are provided on an 1270 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1271 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1272 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1273 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1274 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1275 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1277 Copyright Statement 1279 Copyright (C) The Internet Society (2004). This document is subject 1280 to the rights, licenses and restrictions contained in BCP 78, and 1281 except as set forth therein, the authors retain all their rights. 1283 Acknowledgment 1285 Funding for the RFC Editor function is currently provided by the 1286 Internet Society.