idnits 2.17.1 draft-mglt-ipsec-mm-requirements-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RFC4555]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 946 has weird spacing: '...on HITs d Che...' -- The document date (Sep 2009) is 5330 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) == Missing Reference: 'KEi' is mentioned on line 770, but not defined == Missing Reference: 'KEr' is mentioned on line 773, but not defined ** Obsolete normative reference: RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) ** Obsolete normative reference: RFC 3775 (Obsoleted by RFC 6275) ** Obsolete normative reference: RFC 4306 (Obsoleted by RFC 5996) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) -- Unexpected draft version: The latest known version of draft-grewal-ipsec-traffic-visibility is -01, but you're referring to -02. == Outdated reference: A later version (-13) exists of draft-ietf-mext-rfc3775bis-04 -- Obsolete informational reference (is this intentional?): RFC 4423 (Obsoleted by RFC 9063) -- Obsolete informational reference (is this intentional?): RFC 4718 (Obsoleted by RFC 5996) -- Obsolete informational reference (is this intentional?): RFC 5201 (Obsoleted by RFC 7401) -- Obsolete informational reference (is this intentional?): RFC 5202 (Obsoleted by RFC 7402) -- Obsolete informational reference (is this intentional?): RFC 5206 (Obsoleted by RFC 8046) Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME Working Group D. Migault 3 Internet-Draft Orange Labs R&D 4 Intended status: Standards Track Sep 2009 5 Expires: March 5, 2010 7 IPsec mobility and multihoming requirements : Problem statement 8 draft-mglt-ipsec-mm-requirements-00.txt 10 Status of this Memo 12 This Internet-Draft is submitted to IETF in full conformance with the 13 provisions of BCP 78 and BCP 79. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as Internet- 18 Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 5, 2010. 33 Copyright Notice 35 Copyright (c) 2009 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents in effect on the date of 40 publication of this document (http://trustee.ietf.org/license-info). 41 Please review these documents carefully, as they describe your rights 42 and restrictions with respect to this document. 44 Abstract 46 Currently IPsec mobility is the purpose of MOBIKE [RFC4555] which is 47 the IKEv2 multihoming and mobility extension. More specifically, 48 MOBIKE mobility support provides the ability to change the outer IP 49 address of a tunnel mode Security Association. On the other hand 50 MOBIKE multihoming support provides the ability of a peer to inform 51 its correspondent that alternate IP addresses may be used if the 52 current IP address does not work any more. This draft presents 53 requirements to extend mobility and multihoming facilities. This 54 includes the use of simultaneous IP addresses as well as other IPsec 55 mode like transport mode. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 62 4. Mobility Scenarios . . . . . . . . . . . . . . . . . . . . . . 5 63 4.1. Move and Re-connect Scenario . . . . . . . . . . . . . . . 6 64 4.2. Pre-connect and Move Scenario . . . . . . . . . . . . . . 6 65 5. Multihoming Scenarios . . . . . . . . . . . . . . . . . . . . 7 66 5.1. Different Multihoming, Different Layers . . . . . . . . . 7 67 5.2. Asymmetric Communications . . . . . . . . . . . . . . . . 8 68 5.3. Multihoming Scenario : Simultaneous IP Addresses . . . . . 9 69 5.4. Multihoming Scenario : Alternate IP addresses . . . . . . 11 70 6. The Case of IKEv2 . . . . . . . . . . . . . . . . . . . . . . 11 71 7. Multihoming for Mobility actions . . . . . . . . . . . . . . . 13 72 8. Mobility and Multihoming : complementary actions . . . . . . . 13 73 9. Related work . . . . . . . . . . . . . . . . . . . . . . . . . 15 74 9.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 9.2. IKEv2 . . . . . . . . . . . . . . . . . . . . . . . . . . 16 76 9.3. MOBIKE . . . . . . . . . . . . . . . . . . . . . . . . . . 18 77 9.4. MIPv6 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 78 9.5. MIPv6 and MOBIKE . . . . . . . . . . . . . . . . . . . . . 20 79 9.6. SHIM6 . . . . . . . . . . . . . . . . . . . . . . . . . . 20 80 9.7. SCTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 81 9.8. mtcp . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 9.9. HIP . . . . . . . . . . . . . . . . . . . . . . . . . . . 20 83 10. Mobility / Multihoming with IKEv2/IPsec mechanisms . . . . . . 23 84 10.1. Possible Mobility Scenarios . . . . . . . . . . . . . . . 23 85 10.1.1. Analyze . . . . . . . . . . . . . . . . . . . . . . . 23 86 10.1.2. Requirements . . . . . . . . . . . . . . . . . . . . 24 87 10.2. Possible Multihoming Scenarios . . . . . . . . . . . . . . 24 88 10.2.1. Analyze . . . . . . . . . . . . . . . . . . . . . . . 24 89 10.2.2. Requirements . . . . . . . . . . . . . . . . . . . . 25 90 10.3. MOBIKE and our Scenarios . . . . . . . . . . . . . . . . . 25 91 10.3.1. Analyze . . . . . . . . . . . . . . . . . . . . . . . 25 92 10.3.2. Requirements . . . . . . . . . . . . . . . . . . . . 26 93 11. Mobility Rejected by the Responder? . . . . . . . . . . . . . 27 94 12. Scope and Restrictions . . . . . . . . . . . . . . . . . . . . 28 95 13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 29 96 14. Security Considerations . . . . . . . . . . . . . . . . . . . 30 97 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 30 98 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 30 99 16.1. Normative References . . . . . . . . . . . . . . . . . . . 30 100 16.2. Informative References . . . . . . . . . . . . . . . . . . 31 101 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 31 103 1. Requirements notation 105 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 106 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 107 document are to be interpreted as described in [RFC2119]. 109 2. Introduction 111 This draft presents the scenarios we consider. For sake of 112 simplicity, we spitted the scenarios into three different categories 113 by considering mobility-only scenarios with non multihomed peers, 114 multihoming-only scenarios without mobility, and then scenarios were 115 mobility and multihoming are combined together. The latter category 116 is in fact more a discussion on interaction between mobility and 117 multihoming. 119 Secondly, we present a state of the art of different protocols 120 related to IPsec, mobility and multihoming. This section presents 121 briefly the protocols, and specific points related either to 122 mobility, multihoming or IPsec. This section should be considered 123 more like a key note section then a normative section. 125 At last, we derive the requirements to fit our scenarios. From the 126 scenarios section and the state of the art section, we present the 127 existing mechanisms that best match our scenarios, and figure out 128 what is required to match them completely. Thus we consider the 129 mobility scenarios, then the multihoming scenarios, and for each of 130 them derive requirements. We added a special section with MOBIKE 131 [RFC4555]. In fact the scenarios of this draft are using the IPsec 132 transport mode, and MOBIKE [RFC4555] is the IKEv2 [RFC4306] extension 133 that deals with mobility and multihoming with the tunnel mode. We 134 point out how MOBIKE is related and what lakes to MOBIKE so that it 135 matches our scenarios. 137 We assume the reader is familiar with IPsec [RFC4301], IKEv2 138 [RFC4306] and with MOBIKE [RFC4555]. 140 3. Terminology 142 - Mobile Node (MN) : In this draft the Mobile Node is the peer that 143 performs the mobility action. The Mobile Node does not have to 144 be understood as in MIPv6. 146 - Initiator : The Initiator is the peer that initiates the 147 exchange. It sends a message to the Responder. It is 148 important to note that if two peers are connected, the 149 Initiator of one exchange can be the Responder of another 150 exchange. When a mobility action is performed then the 151 Initiator is also the Mobile Node. 152 - Responder : The Responder is the peer receiving a message. The 153 message is sent from the Initiator. 154 - Alternate IP Address : The alternate IP address of a peer is the 155 IP address a peer is not currently using but that might be used 156 latter. An alternate IP address should used only if the 157 current IP address does not work anymore. 159 4. Mobility Scenarios 161 This section shows mobility scenarios that motivated this draft. 162 They consider two peers directly connected between each other. The 163 communication is protected using IPsec with a transport mode -- the 164 tunnel mode has already be considered in [RFC4555]. 166 Mobility scenarios with transport mode do not provide seamless 167 mobility -- at least without multihoming considerations -- and so is 168 not transparent to the application. Thus it should not be used with 169 any applications. In fact, we consider two peers directly connected 170 with a single IP address -- i.e. not multihomed -- and their 171 connection is protected by an IPsec Security Association using the 172 transport mode. A mobility action requires the Mobile Node (MN) to 173 change its IP address, to inform the other peer so that the already 174 negotiation can still be used with the new IP address. This 175 interrupts the communication and data lost might occurs. This kind 176 of mobility can then only apply to certain use cases. 178 Typical examples can be UDP connections protected via IPsec. The 179 peer decides to move, and packets that do not reach their destination 180 are lost. The faster the connection is reestablished the fewer 181 packets we loose. Another example can be TCP connections with very 182 few packets transfer compared to the connection time. Web surfing is 183 a good example for this case. Suppose an end user is connected, for 184 example to a web server, and the communication is protected by IPsec 185 using the transport mode. The time between sending a request and 186 receiving the web page is very low compared to the time the end user 187 spend on the web server to read the data. Furthermore end users are 188 used to reload a web page when the download is not performed 189 correctly. When the peer decides to move, if a web page is being 190 downloaded, the connection is broken, and once mobility is performed, 191 the user reloads the page. On the other hand, if the peer moves 192 while the end user reads a web page, than the end user does not even 193 notice the mobility. Of course this mobility can be used if mobility 194 actions are not too frequent, and if the peer changes its IP address 195 every second then it is highly probable the end user will be affected 196 by the mobility. In other words, walking speed is probably the 197 considered speed for mobile and non-multihomed peers. 199 End users connected for example to a ftp server for heavy file 200 transfer is not a use case that matches the mobile and non multihomed 201 peer. In that specific case, unless the application deals with 202 connection interruption, the transfer needs to be restarted each time 203 a the peer change its IP address. 205 4.1. Move and Re-connect Scenario 207 This scenario considers two peers connected via an IPsec Security 208 Association using transport mode, and using only one IP address. One 209 peer loses its connectivity, manages to attach on another network, to 210 get a new IP address, and send inform the other peer the 211 communication can go on a new IP address. Signaling messages are 212 sent via the IKEv2 protected channel, since this channel has already 213 been negotiated. The MN updates its Security Associations before 214 sending the message to the other peer. When the other peer receives 215 the message, it checks the new IP address matches the local policies, 216 the IPsec Security Policies, eventually performs some Return 217 Routability Check before updating the Security Association Database. 218 Once the SAD are updated on both peers, the communication can go on. 219 The previously negotiated IPsec / IKEv2 security parameters remain 220 the same. Particularly, authentication do not need to be replayed. 222 In this scenario, the MN has no guarantee that the new IP address 223 will match either the Security Policies or the local policies of the 224 peer. If the new IP address is not accepted, a CREATE_CHILD_SA or an 225 IKE_INIT exchange MAY be performed. 227 4.2. Pre-connect and Move Scenario 229 This scenario considers two peers connected via an IPsec Security 230 Association using transport mode. Each peer only uses one IP 231 address. Unlike in the previous scenario, the Mobile Node (MN) knows 232 the IP address it will use before performing the mobility action. 233 How the MN knows the IP address is beyond the scope of this paper, 234 and we call it the new IP address as opposed to the current IP 235 address. The MN checks with the other peer if a mobility action can 236 be performed with this new IP address. This involves checking the 237 local policies, the Security Policy Database. 239 As mentioned in the multihoming section, the MN may eventually, 240 before moving, informs the other peer that the new IP address is an 241 alternate IP address. If the MN is multihomed checking the new IP 242 address can eventually include reachability test with the Return 243 Routability Check exchange. In this scenario this test cannot be 244 performed since the MN has only one interface. 246 The MN moves as described in the previous scenario. It informs the 247 Responder it has changed its IP address. 249 Motivation for preparing the mobility action are : 251 - Helps the MN to choose the next IP address to use : The Responder 252 can check the IP address matches the local policies and send an 253 error message if the IP address does not match the local 254 policies. With an error message, the MN knows that using this 255 IP address will require to re-negotiate an IPsec Security 256 Association. If the MN can choose between a set of IP address 257 then it might choose an IP address that does not require 258 negotiating a new IPsec Security Association. 259 - Fasten Mobility action : When the MN moves, it can either send a 260 message with the old IP address or the new IP address. If the 261 MN knows the new IP address does not matches local policies of 262 the Responder, than it might directly initiate an IKEv2 263 negotiation. If the MN knows the IP address matches the 264 Responder's local policies, then it might avoid such a 265 negotiation. 267 5. Multihoming Scenarios 269 5.1. Different Multihoming, Different Layers 271 Multihoming is the ability of a peer to handle with more than one IP 272 address. It can have different meanings, and this section defines 273 the different multihoming we consider in this paper. Multihoming 274 depends on the layer that deals with multihoming. We consider two 275 layers in this paper the Networks or the Application layers. 276 Networks Layers are all layers below the application layer. 277 Multihoming can also consider different strategies. We consider the 278 use of Simultaneous IP Addresses (SM) as opposed to the use of 279 Alternate IP Addresses (AM). Alternate IP address SHOULD NOT be used 280 unless the current IP address does not work anymore. 282 - Multihomed Application : An application is multihomed if it can 283 take advantage of multiple IP addresses. If the application 284 considers SM, then the peer has to deal with multiple IP 285 addresses, for example by having multiple interfaces. If the 286 application considers AM, then the peer can be singled homed. 287 If application deals directly with multihoming, there MUST be a 288 channel between the two applications that enables one peer to 289 provide multihoming information to the other peer. This 290 channel can be established by the application itself, but 291 application can also decide to use an already existing channel, 292 or protocol. In fact an application could use the IKEv2 293 channel to carry multihoming information. This would require 294 in that case a communication channel between IKEv2 and the 295 application. 296 - Multihomed Networks Layer : Multihoming can also be transparent to 297 the application. SHIM6 [RFC5533] or HIP [RFC4423], [RFC5201] 298 are protocols that provide an additional layer between the IP 299 and the application layer. As a result the application only 300 sees one fix IP address. This IP address might be a non 301 routable IP address, and application packets can be routed 302 using different IP addresses. In those cases, the networks 303 layers deals with multihoming. We say Network(s) to include 304 the transport layer. In fact it is still not clear which layer 305 should consider multihoming, and multipath tcp are looking at 306 the transport layer. So do SCTP. Unless the application 307 requires a specific multihoming strategy, Multihomed Networks 308 Layer brings simplicity for application developers. On the 309 other hand the application completely relies on the network 310 layer multihoming management facilities. 311 - Simultaneous IP addresses Multihoming (SM): We call Simultaneous 312 IP Addresses Multihoming (SM) the ability to use more than one 313 IP address. This means that an application sends / receives 314 data from / to multiple IP addresses. If Multihoming is 315 considered at the Network layer, then it means a peer receives 316 / sends data from two distinct IP addresses. Of course we mean 317 routable IP addresses! Usual motivations for SM are bandwidth 318 aggregation, data duplication, traffic engineering, interface 319 selection... 320 - Alternate IP addresses Multihoming (AM): We call Alternate IP 321 Address Multihoming (AM) the ability to have alternate IP 322 addresses, that is to say IP addresses that SHOULD be used only 323 if the current IP address is not working anymore. The main 324 motivation for using the AM mode is to enhance reachability. 325 Providing multiple alternate IP addresses also enhance 326 connectivity. If the peer provides more than one IP address, 327 and the connection is lost, then the other peer can choose the 328 best IP address. 330 5.2. Asymmetric Communications 332 This section considers use cases when peers communication benefit 333 from multihoming. We need to consider the following definitions : 335 - A peer is multihomed : if it has multiple IP addresses. 336 - A peer supports multihoming : if it has all multihoming 337 facilities, that is to say if has the ability to deal with 338 different IP address at the "network layer" -- that is to say 339 network or transport layer. 340 - An application supports multihoming : if the application handles 341 multihoming properly. We assume in this paper that when an 342 application handles with multihoming, network layer multihoming 343 abilities are skipped. 345 When an application supports multihoming and one of the host is 346 multihomed, then the communication can take advantage of multihoming 347 capabilities. When an application does not support multihoming, to 348 take advantage of the multihoming, both peers network layer MUST 349 support multihoming and one of the host MUST be multihomed. For 350 simplicity, we also assume that applications do not follow the client 351 server model with BYPASS security policy. The table below sums up 352 cases when the communication between applications can take advantage 353 of multihoming. 355 +------------------------------------------------------------+ 356 | Multihoming supported layer | 357 +----------------------------+----------------+--------------+ 358 | | Peer A | Peer B | Benefit | 359 +-----------+---------+------+---------+------+ from | 360 |Application| Network | Host | Network | Host | multihoming | 361 +-----------+---------+------+---------+------+--------------+ 362 | X * X * * X | 363 | X * * * X X | 364 | X * - * - - | 365 | - X - X - - | 366 | - X * X X X | 367 | - X X X * X | 368 | - * * - * - | 369 | - - * * * - | 370 +------------------------------------------------------------+ 372 When do we benefit from Multihoming 374 5.3. Multihoming Scenario : Simultaneous IP Addresses 376 The purpose of using simultaneous IP addresses is to associate a peer 377 with a pool of IP addresses. Each IP address of the pool can be used 378 to reach that peer, and peer A can use simultaneous IP addresses 379 while communication with peer B. 381 How to choose the IP addresses, how to split the different flows 382 among the different IP addresses is beyond the scope of the draft. 383 This draft considers that if peer A decides to use simultaneously 384 multiple IP addresses, then Security Associations between peer A and 385 peer B MUST be set so that traffic can use both of those IP 386 addresses. In the same perspective, if peer A changes its pool of IP 387 address Security Association between peer A and B MUST be updated. 389 Thus the use case to consider here, is peer A and peer B are 390 communicating, and their communication is protected by a transport 391 mode Security Association. Peer A has multiple interfaces and 392 proceeds to an attachment procedure on different networks. Once the 393 attachment procedure is over, peer A has multiple IP addresses, and 394 wants to benefit from them in its communication with peer B. We 395 assume that this communication can take advantage of the multihoming 396 facilities, and that peer A and peer B set their IPsec Security 397 Associations. 399 In our case, setting the IPsec Association means that the already 400 configured SA is being associated multiple IP addresses. Multihoming 401 action consists then to add or remove IP addresses associated to that 402 specific Security Association. 404 When a peer adds an IP address to a given Security Association, it 405 sends a message to inform the other peer. If the IP address matches 406 the local and Security Policies, then it is added to specified SA(s). 407 If the IP address does not match either the local policies or the 408 Security Policies, or both of them, then an error is returned. One 409 can notice that there is no need to check that the IP address matches 410 the local policies or the Security Policies before proceeding to the 411 multihoming action. Event if the IP address is refused, the 412 communication is not affected. This was not the case with mobility. 414 When a peer wants to remove an IP address from an existing SA, it 415 sends a message to the other peer. The other peer updates its IPsec 416 databases. 418 Note : On an IPsec point of view, adding or removing one IP address 419 from Security Associations does not present any difficulties. 420 Nevertheless one should consider its consequences on the IP traffic. 421 Adding an IP address to a given SA do not affect the traffic. On the 422 other hand removing one IP address from an SA might affect the 423 communication between the peers. For now, ULP handle multihoming 424 without any considerations of IPsec -- except for HIP. Once the 425 transport or the 3.5 layer agrees on removing the IP address, then 426 IPsec databases can be updated, and the IP address removed from the 427 SA(s). One possibility is to initiate an IKEv2 exchange. Another 428 possibility is the ULP proceed directly to the IPsec update without 429 proceeding the IKEv2 exchange. This would at least avoid one 430 exchange. There is also another way to consider how the different 431 layers can interact between each other. We can consider that 432 mobility and multihoming signalization should be protected and uses 433 an IKEv2 channel. In that case, the multihoming or mobility action 434 could be transmitted to the upper layers. 436 5.4. Multihoming Scenario : Alternate IP addresses 438 A peer provides an Alternate IP Address to the other peer so that if 439 the peer is not anymore reachable on one of the currently used IP 440 addresses, than it might still be reachable on one of the Alternate 441 IP Address. An Alternate IP Address should not be used in addition 442 to the currently IP addresses. 444 Suppose peer B reaches peer A through 2 IP addresses, and peer A has 445 provided a pool of Alternate IP Addresses to peer B. Peer A happens 446 not to be reachable on one of the IP address. Peer B can still reach 447 peer A through one IP address. It is up to peer B's local policies 448 to define whether or not it should add and use an Alternate IP 449 Address. 451 The IPsec layer does not deal directly with reachability statement. 452 This means that Alternate IP Addresses MUST be provided either to the 453 application, or the entity that is in charge of the multihoming. 454 Thus Alternate IP Addresses are useful for IKEv2 as an application or 455 if IKEv2 is used as a channel to carry multihoming information that 456 are provided to the Upper Layer Protocol. 458 The Alternate IP Address mechanism for the IKEv2 application is 459 described in MOBIKE [RFC4555]. 461 6. The Case of IKEv2 463 IKEv2 is a special case. On the one hand that is a regular 464 application and it has its own strategy to handle multihoming. On 465 the other hand IKEv2 is the application we consider to carry mobility 466 and multihoming information. Most of the time this information is 467 expected to affect other applications connections then IKEv2's 468 connections. In other words, IKEv2 is to be considered as a secure 469 channel that is used to carry signaling information. 471 This paper is not especially focused on how IKEv2, as an application 472 deals with mobility and multihoming. The scope of this paper is to 473 elaborate on how peers can deal with mobility and multihoming. In 474 that sense peers need to exchange messages which affect the Security 475 Associations of their communications. Such messages are exchanged 476 via the IKEv2 channel. Thus we MUST define what kind of message need 477 to be exchanged. On the other hand, to be exchanged, we need to 478 provide mechanisms so that the IKEv2 channel can also survive to 479 mobility and multihoming actions. In that sense we MUST also specify 480 how IKEv2 deals with mobility and multihoming. 482 As an application IKEv2 has specific IPsec security policies. 483 Packets are not filtered and are sent by the network layer to the 484 IKEv2 application. IKEv2 binds the message to its IKE_SA thanks to 485 the SPI. This means that by using different IP addresses, one peer 486 SHOULD be able to reach the other. The way IKEv2 works allows the 487 Initiator to use multiple IP addresses, it will receive the answer 488 from the Responder on the same IP address used for the query. 490 Nevertheless we cannot say IKEv2 is using the Simultaneous IP Address 491 Multihoming. IKEv2 works like a server and send the response to 492 source IP address of the query. In that sense peer A can use various 493 IP addresses to send IKEv2 message to peer B. But peer B will always 494 use the IP address associated to the IKE_SA to reach peer B. 496 For now, IKEv2 even with the MOBIKE extension associates only one IP 497 address to the IKE_SA. So IKEv2 even with the MOBIKE extension do 498 not consider Simultaneous IP Addresses Multihoming. If it would, 499 then it would mean that peer A and peer B could have been associated 500 a pool of IP address. Each time one of the peer want to reach the 501 other it would be able to choose one the IP address of the pool. 502 More specifically, this is different from receiving one packet on one 503 IP address and sending the response on another IP address. 505 Considering the previous example, where peer A uses different IP 506 addresses that are not associated to the IKE_SA. Automatically 507 adding those IP address to the IKE_SA is a bad idea. In fact it 508 would note consider that peer A may use IP address it may be not or 509 it does not want to be reach with. This means that multihoming and 510 IKEv2 SHOULD NOT be performed automatically. 512 If one peer changes its IP address, it MUST explicitly inform the 513 IKEv2 application. MOBIKE [RFC4555] deals with this by sending an 514 UPDATE_SA_ADDRESSES message, that indicates the IP address of the 515 sender has changed. This is want mobility occurs, but for now IKEv2 516 uses only one IP address, so adding or removing an IP address is not 517 considered. 519 The way IKEv2 considers multihoming is described in MOBIKE [RFC4555], 520 and uses the Alternate IP address Multihoming. Alternate IP 521 addresses are sent from one peer to the other by using 522 ADDITIONAL_IP4_ADDRESS or ADDITIONAL_IP6_ADDRESS Notify Payloads. 524 7. Multihoming for Mobility actions 526 Until now, mobility and multihoming have been treated as different 527 actions, but one can easily see that multihoming can also be used for 528 a seamless mobility. This section analyzes when mobility is 529 performed with multihoming actions. 531 Multihoming provides the ability to perform a smooth transition from 532 one IP address to another IP address without interrupting the 533 traffic. One peer is connected to the other via a pool of IP 534 addresses. When the peer moves, it can get a new pool of IP 535 addresses. If the intersection between the two pools is not void, 536 then a smooth transition can occur by using both multihoming and 537 eventually mobility mechanisms. 539 Suppose peer A and peer B are communicating using a pool of IP 540 addresses. Peer A moves and is attached to other different networks. 541 It proceeds to a multihoming add action and add all new IP addresses. 542 When some of the old IP addresses become less reliable -- less power 543 on the signal for example -- then peer A decides to remove them from 544 the communication. To perform this action peer A has two 545 possibilities. It can use a multihoming remove action or proceed to 546 a mobility action replacing the IP address to be removed by newly 547 acquired IP address. 549 On a cross layer point of view, as long as it is coordinated, it does 550 not make any difference whereas the peer update or remove IP 551 addresses. This means that ULP MUST be involved. In fact, ULP can 552 proceed to the IKEv2 exchanges once the multihoming actions has been 553 performed at the IP and transport layer. On the other hand, IPsec 554 multihoming signalization can also be forwarded to ULP. In both 555 cases, proceeding to mobility or multihoming remove message does not 556 change anything. 558 On IPsec point of view it is recommended to perform multihoming 559 remove action. In fact multihoming remove message are expected to be 560 shorter than mobility message. Mobility action may need to specify 561 the replacing and the replaced IP address whereas multihoming remove 562 message only require the IP address to be removed. 564 8. Mobility and Multihoming : complementary actions 566 The actions we consider in this paper are Mobility and 567 Multihoming(s). The previous section exposes how mobility can be 568 performed with multihoming actions. So why do we need mobility? 569 This section exposes the differences between mobility and 570 multihoming. 572 Some of the different uses between Multihoming and Mobility are 573 listed below : 575 - Mobility (or update) action can, in some cases, be replaced by 576 two Multihoming actions (add followed by a delete). Thus the 577 main advantage of Mobility is that only one request is required 578 whereas two are required with the use of Multihoming action. 579 - Multihoming can be used to perform mobility action. 580 Considering the IPsec layer only is not the most efficient way, 581 but nothing can prevent a peer from doing it. On a cross layer 582 point of view, this might require the peer or the application 583 supports multihoming. 584 - Multihoming does not necessarily affect the current 585 communication. An application can communicate via one pair of 586 IP address and make independent tests with another pair to 587 check for example if the new IP address matches the local 588 policies, or is still reachable. Such tests can be useful 589 before proceeding to a Mobility action for example. The 590 Mobility has a best effort approach. It changes the IP 591 address, if that's possible. If that is not possible, and the 592 peer has to change its IP address, than the connection is 593 interrupted. This best effort approach can be mitigated with 594 the mobility checks. 595 - If an IPsec connection is broken, Mobility has a specific 596 mechanism to re-establish this connection. This can happen 597 when a host has to move, initiates a Mobility action that 598 fails. It then has to wait to get a new IP address that 599 enables the Mobility action. Multihoming SHOULD NOT be used 600 for a Security Association that is not in an active state. In 601 fact implementations might refuse to add an IP address to an 602 non-active SA. This is beyond the scope of IPsec management, 603 since IPsec databases are independent of the transport layer, 604 and thus does not have any state regarding to the transport 605 layer. Nevertheless, with Multihoming and Mobility, we believe 606 mobility / multihoming / IPsec management will occur at the 607 same level, and thus IPsec will be handled in conjunction of 608 connections states. 609 - Mobility is very Initiator-centric. The Initiator informs the 610 Responder that an IP address is no more in use and another one 611 MUST be used instead. Multihoming can be used to check an IP 612 address matches a connection without affecting the current 613 connection, it can also provide an IP address that MAY be used 614 by the Responder. The Initiator can send a set of IP addresses 615 to inform the Responder that in case the current connection 616 fails. This is the purpose of Alternate IP Addresses. The 617 Responder MUST only use them when at least one of the current 618 IP address does not work. The Responder can then choose which 619 IP address it prefers to use. How the Responder choose the IP 620 addresses to reach the Initiator is beyond the scope of this 621 document, but the decision can be based on Responders local 622 policies as well as information provided by the Initiator on 623 the IP addresses (like preferences for example.). 625 9. Related work 627 This section is not normative and only stands here for clarification. 629 9.1. IPsec 631 [RFC4301] describes the IPsec architecture and the three associated 632 databases : the Security Association Database (SAD), the Security 633 Policy Database (SPD) et the Peer Authorization Database (PAD). 635 Section 5.1 describes how outbound packets MUST be processed. For 636 any outbound packet, a SPD lookup occurs first, then a SPD-Cache 637 lookup is performed. The SPD-Cache defines whereas the packet should 638 be BYPASS, DISCARD or PROTECT with the associated index of the SAD. 639 The packet is then sent to a forwarding function that sends the 640 packet on the wire or performs a loop back to the protected interface 641 in the case of nested SA. 643 Section 5.2 describes how inbound packets are handled. If packet are 644 not IPsec protected, then a SPD-I lookup is performed and the SPD-I 645 defines whether the packet should be DISCARD or BYPASS. If the 646 inbound packet seems to be IPsec protected with protocol AH or ESP, 647 then an SAD lookup is performed. The ESP/ AH process is done 648 according to the SAD entry. Once performed, traffic selector MUST 649 match the packet header's. If no match is found, then the packet 650 MUST be discarded. After ESP/AH process, checking the traffic 651 selectors can be performed by a SPD lookup. [RFC4301] mentions on 652 p.61. 654 "This processing includes using the packet's SPI, etc., to look 655 up the SA in the SAD, which forms a cache of the SPD for 656 inbound packets (except for cases noted in Sections 4.4.2 and 657 5)." 659 The SA contains all security material to perform the IPsec 660 processing. The SPD lookup is required to check that SAD are 661 coherent with the SPD, that defines the Security Policy of the 662 system, and can be changed. 664 SAD lookup is defined in section 4.1 and MUST consider the longest 665 match. The lookup considers then a match with the SPI, source and 666 destination address, if no match occurs then a match for SPI and 667 destination address is considered. If no match occurs, then only the 668 SPI match is considered. 670 Section 4.4.3 provides a description and interaction between the PAD 671 and other IPsec databases. The PAD is involved during the IKE_AUTH 672 exchange, and provides instruction on which IKE_ID have to be 673 considered and how IKE_ID should be authenticated. During the 674 CREATE_CHILD_SA, the peers are authenticated but the PAD provides 675 instruction on how the SPD should be lookup, that is to say either 676 considering the IKE_ID or the Traffic Selector as an entry to the 677 SPD. An interesting thread provides clarification on the PAD 678 http://www.nabble.com/PAD-and-IKEv2-td13123521.html#a13130457 680 "The PAD is an artifact of the description of the processing 681 model, but implementations will need something like it, because 682 the SPD by itself does not provide enough information to IKE 683 (one possible implementation might be to augment the SPD with 684 data that would belong in the PAD in the nominal model). The 685 PAD does two crucial things: it describes how to authenticate 686 peers, and it specifies constraints on the traffic selectors 687 that peers will be allowed in their child SA proposals. --Nico" 688 "The PAD gives a mapping/relation/binding between certain 689 pieces of information. It's a local matter how this mapping/ 690 relation/binding is realized. I'm aware of at least one 691 implementation, where the PAD is implemented as a table/ 692 database. -- Christian" 694 Section 6 provides a description on how ICMP interacts with IPsec. 695 When ICMP message are not protected, it is recommended for network 696 administration purpose to accept and response to them. 698 In our case, during mobility or multihoming action, a Security 699 Association is derived from an existing Security Association. We 700 MUST first check with the PAD is the selector can be used by the ID, 701 then check what Security Policy of the system requires for this new 702 IP address associated to this Identity. If the current SA matches 703 the security policy, then the new SA can be derived. Otherwise, a 704 new SA MAY be negotiated. 706 9.2. IKEv2 708 [RFC4306] defines IKEv2 and [RFC4718] provides clarification mainly 709 for implementation purposes. When an IKE negotiation is initiated, 710 it starts with an IKE_INIT exchange. The IKE_INIT exchange aims at 711 defining a secure channel for IKE negotiation and management of SA. 712 All actions such as creating a child SA, rekeying an IKE SA, rekeying 713 child SA is performed through the CREATE_CHILD_SA exchange. The 714 IKE_INIT exchange is a four packets exchange that can be spitted into 715 two exchanges : the IKE_SA_INIT that establish an IKE_SA, and the 716 IKE_AUTH which authenticates the peers. The IKE_AUTH exchange is 717 also used to create the first CHILD_SA. This is mainly to avoid 718 another exchange that would introduce more network latency. When an 719 SA is created either via the IKE_AUTH or CREATE_IKE_SA exchange, 720 Traffic Selectors (TS) are specified. Such selectors are used to 721 match the SPD to negotiate and create the SA(s). TS range can be 722 narrowed by the Responder. The Responder can also accept for the 723 given SA some subsets of the TSi. There are some situations were two 724 different SA SHOULD be created rather then a single SA. In that 725 case, the Responder should send a NOTIFY message with 726 ADDITIONAL_TS_POSSIBLE. It indicates that additional selectors would 727 be accepted but would required a separate SA (section 2.9 and section 728 3.10.1 RFC4306). 730 COOKIES exchange can be used as a way to test return routability 731 verification. COOKIES are sent in Notify Payloads. Routing 732 verification can be done at two different levels. COOKIE can check 733 the IKE_SA is still valid, and the host is still reachable with the 734 new IP address. When the peer changes its IP address, a successful 735 COOKIE exchange means peers are still reachable and the IKE_SA is 736 still valid. If ICMP should not be used to check reachability, 737 combination of the two tests can lead to the following conclusion : 738 peers are not IP reachable, peers have no more valid IKE_SA, peers 739 are IP reachable with valid IKE_SA channel. Peer can have no more 740 valid IKE_SA channel when for example, the new network filters IKE 741 traffic. 743 CREATE_CHILD_SA exchange is used to rekey an existing SA, rekey an 744 IKE_SA, rekey a CHILD_SA, or create new CHILD_SA. As specified in 745 section 2.8 of [RFC4306], CREATE_CHILD_SA exchange is optional and 746 implementations MUST NOT support this exchange. [RFC4718] describes 747 the exchanged payloads in the following cases : 749 We provides the exchanges only for illustration purposes, and 750 complete description are provided in [RFC4718]. 752 Initiator Responder 753 ----------- ----------- 754 HDR, SK {SA, Ni, [KEi]} --> 755 <-- HDR, SK {SA, Nr, [KEr]} 757 Rekeying IKE_SA 759 Initiator Responder 760 ----------- ----------- 761 HDR, SK {N(REKEY_SA), [N+], SA, 762 Ni, [KEi], TSi, TSr} --> 763 <-- HDR, SK {[N+], SA, Nr, 764 [KEr], TSi, TSr} 766 Rekeying CHILD_SA 768 Initiator Responder 769 ----------- ----------- 770 HDR, SK {[N+], SA, Ni, [KEi], 771 TSi, TSr} --> 772 <-- HDR, SK {[N+], SA, Nr, 773 [KEr], TSi, TSr} 775 Creating New CHILD_SA 777 Section 3.11 in [RFC4306] describes a DELETE payload that enables to 778 delete SA. SA are identified by their SPI. 780 Reauthentication without generating a new CHILD_SA is described in 781 [RFC4478]. 783 IKEv2 is the negotiation protocol peers use to setup Security 784 Associations. This application needs to check coherence between the 785 IPsec databases. The negotiation protocol is designed in a query / 786 response manner, and it allows extensions such as MOBIKE [RFC4555]. 788 9.3. MOBIKE 790 MOBIKE is defined in [RFC4555]. It provides an extension of IKEv2 791 for mobility and multihoming. MOBIKE considers mobility and 792 multihoming in one specific scenario : peer is connected to its home 793 network using a IPsec tunnel mode, the peer is using only one 794 interface, and the peer changes the address of the tunnel. MOBIKE 795 also considers some cases of NAT, and it is recommended to run MOBIKE 796 on port 4555. 798 The mobility initiative is performed by the client. This is the only 799 case the peer can try to reach the other peer without being notified 800 of any mobility action, is when the peers cannot reach each other. 801 Since only one IP address is used at a time, this active IP address 802 is always the one in the IKEv2 message header. 804 The main messages involved in MOBIKE are the MOBIKE_SUPPORTED Notify 805 message to indicate the peer supports MOBIKE. The 806 ADDITIONAL_IP4_ADDRESS and ADDITIONAL_IP6_ADDRESS Notify message 807 enable an Initiator to provide the Responder the IP addresses that he 808 might be used. The Responder does not have the ability to choose 809 which IP address is going too be used to reach the Initiator except 810 if the Initiator cannot be reached with its former IP address. In 811 that specific case, the Responder can try addresses from the list. 812 By providing different IP addresses, the Responder has the 813 possibility to choose which IP address fits best its local policies 814 to reach the Initiator. 816 On the other hand, the Initiator can also get a list of IP address 817 and choose which one best fits its local policies. The mechanisms 818 used to select the IP addresses are beyond the scope of MOBIKE, but 819 MOBIKE provides means for the Initiator to redirect the traffic to 820 another IP address. Mobility is performed with the 821 UPDATE_SA_ADDRESSES Notify payload. Since only one IP address is 822 used at a time, the address to be considered is the one inside the 823 IKEv2 IP header. There is no need to provision the IP address before 824 performing the mobility. MOBIKE also provides a COOKIE2 Notify 825 payload that provides return routability check. Whether this check 826 should be performed or not and when it is defined by local policies. 828 9.4. MIPv6 830 MIPv6 is described in [RFC3775] or in [I-D.ietf-mext-rfc3775bis], and 831 the tunneling technique is specified in [RFC2473]. Its main purpose 832 is to provide a permanent IP address, which is usually hosted in the 833 DNS : the Home of Address (HoA). When the Mobile Node (MN) cannot 834 have its HoA as its active IP address, it uses a Care of Address 835 (CoA) and sets up a tunnel between the MN and the Home Agent (HA) 836 with the CoA and the IP address of the HA. This tunnel enables 837 packets with HoA as IP destination to be routed to the HA and 838 tunneled to the MN. In return, the HA routes packets with HoA as a 839 source address to the CN. Mobile IP requires IPsec to secure the 840 messages between the MN and the HA. IPsec and MIPv6 is specified in 841 [RFC3776] and in [RFC4877]. The Security Association are negotiated 842 between the HoA and the HA. Signaling messages with MIPv6 are 843 identified by the protocol selector. To match the SAD, a special 844 action MUST be performed for inbound and outbound Binding Update (BU) 845 packets : lookup in SPD and SAD MUST be done by replacing the CoA by 846 the HoA, which is mentioned in the routing header extension. This is 847 to make the SA independent of the CoA. On the other hand the IKE_SA 848 is negotiated with the CoA. When changing CoA, one can indicate with 849 the K bit, that the used IP address in the header is a new CoA and 850 the IKE_SA MUST be updated. 852 Routing optimization is described in [RFC3775], and enables message 853 to be directly routed to the CN rather then going through the HA. 855 9.5. MIPv6 and MOBIKE 857 The purpose of MIPv6 is to provide the MN a permanent IP address. A 858 tunnel is created between the MN and the HoA. When the CoA changes, 859 a Binding Update (BU) with a K bit asks the Tunnel to be updated. 860 There are different flows to consider : The tunnel between the CoA 861 and the HA, the MIPv6 signaling channel, and the IPsec signaling 862 channel. The tunnel between the CoA and the HA might be secured with 863 IPsec, but this is not required. The MIPv6 signaling channel is 864 secured with IPsec in transport mode. The associated Security 865 Associations are based on the HoA and the HA IP address. The IPsec 866 signaling channel (IKEv2) is secured by the IKE_SA. This is the 867 value that is updated with the K bit. The new IP address to be used 868 is provided by the BU message. 870 MOBIKE uses the UPDATE_SA_ADDRESSES message as an update request. 871 The new IP address to consider is found in the IKE message. Since 872 MOBIKE works only in tunnel mode, updating the SA requires changing 873 not its selector, but one parameter of the SA, that is to say the 874 outer IP address of the tunnel. The IKE_SA is also the SA that needs 875 to be updated by changing the traffic selectors. The 876 UPDATE_SA_ADDRESSES is sent with the new IP address, which means even 877 with a new unknown IP address the packet will be analyzed. 879 9.6. SHIM6 881 To be done. 883 9.7. SCTP 885 To be done. 887 9.8. mtcp 889 To be done. 891 9.9. HIP 893 Host Identity Protocol (HIP) is defined in [RFC4423] and [RFC5533]. 894 The mobility and multihoming extension is described in [RFC5206]. 895 HIP is taking advantage of the separation of Host Identifier (HI) and 896 the locator (LOC). This means that that the application are 897 presented a Host Identity Tag (HIT) which is independent from the IP 898 addresses. HIP requires an ESP Security Association between the 899 HITs, and [RFC5202] describes how the ESP association is established 900 and maintained. Security Association are negotiated between HIs or 901 HITs, packets are sent using IP addresses that are respectively bound 902 to HITs. [RFC5202] provides two examples on how the ESP processing 903 of HIP packet can rely on standards compliant IPsec implementations. 905 - Transport : The processing is represented by figure "ESP 906 processing : Transport". In that case, the HIP layer maintains 907 the SAD and SPD with IP addresses that are associated with the 908 different HITs. The HIP layer proceeds to replacement of HITs 909 by IP addresses. 910 - Tunnel : The ESP processing is representing by figure "ESP 911 processing : Tunnel". The tunnel mode refers to the BEET mode 912 described in [I-D.nikander-esp-beet-mode]. It works like in 913 the tunnel mode except that the inner header is removed. 915 +-------------+ + 916 | Application | | HIT_s - HIT_d 917 +-------------+ o 918 | u 919 +-------------+ t 920 | ULP | b HIT_s - HIT_d 921 +-------------+ o checksum(HIT) 922 | u 923 +-------------+ n HIT_s -> IP_s HIP <-> {IP1, IPi, IPn} 924 | HIP | d HIT_d -> IP_d 925 +-------------+ | 926 | p SAD, SPD based on IP addresses 927 +-------------+ a 928 | IPsec | c 929 +-------------+ k ESP processing 930 | e 931 +-------------+ t send IP packet 932 | IP | | on wire 933 +-------------+ v 935 ESP processing : Transport 937 +-------------+ + ^ 938 | Application | | HIT_s - HIT_d | 939 +-------------+ o | 940 | u i 941 +-------------+ t n 942 | ULP | b HIT_s - HIT_d b 943 +-------------+ o checksum(HIT) o 944 | u u 945 +-------------+ n n 946 | IPsec | d SAD SPD based on HITs d Check IP, tunnel header 947 | | | ESP processing | ESP processing 948 | BEET mode | p HIT_s -> IP_s p IP_s -> HIT_s 949 | | a HIT_d -> IP_d a IP_d -> HIT_d 950 | | c c 951 +-------------+ k k 952 | e e 953 +-------------+ t send IP packet t 954 | IP | | on wire | 955 +-------------+ v | 957 ESP processing : Tunnel 959 HIP provides mobility and multihoming facilities. Security 960 association are negotiated between HIT, and the HIP layer binds the 961 HIT with the corresponding IP address table and more specifically 962 updates the corresponding SAD and SPD. 964 HIP Provides the transport mode facilities MOBIKE is missing. In 965 fact a HIP communication involves a IPsec transport mode, and 966 signaling messages to add or change IP addresses. Nevertheless, the 967 goal of this paper is to provide IPsec facilities for Multihoming and 968 mobility so that an host can rely on an IPsec security. This means 969 that the IPsec layer should support any possible IPsec configuration 970 due to mobility and multihoming scenarios. More precisely, we expect 971 that mobility and multihoming can be performed by an IPsec host using 972 the IPsec tunnel mode or the IPsec transport mode. Furthermore we 973 would like IPsec to keep the IP granularity. This means that a 974 multihomed host can have different Security Association depending on 975 the path. In other words, we are looking for finer granularity then 976 HIP, and Security Association should still be negotiated by peers on 977 a per "selector" base. With HIP Security Associations are negotiated 978 between HITs. Although next versions of HIP might supports those 979 facilities, we are looking to extend the already existing mobility 980 and multihoming IKEv2 extension. Developments SHOULD consider 981 providing a neat API that might be used by other Upper Layer 982 Protocols 984 10. Mobility / Multihoming with IKEv2/IPsec mechanisms 986 This section describes how mobility and multihoming can be considered 987 with IPsec and IKEv2 mechanisms, how they differ from mechanisms 988 exposed in the Scenarios description, as well as how those 989 differences impact mobility and multihoming. In this section we only 990 consider transport mode between the Initiator and the Responder. 992 10.1. Possible Mobility Scenarios 994 10.1.1. Analyze 996 The move and reconnect scenario consists of the Initiator changing 997 its IP address, creating the corresponding Security Association, and 998 deleting the previous one. 1000 Section 1.3, 1.17 and 1.18 of [RFC4306] provide descriptions of 1001 rekeying exchanges. Different configurations include creation of a 1002 new SA, rekeying an already existing SA and rekeying an IKE_SA. In 1003 our case, the Initiator wants to notify the IP address has changed. 1004 We do not rekey an already existing SA since the traffic selectors 1005 are changed. The required action is to create a new CHILD_SA with 1006 the corresponding traffic selectors. The Initiator rekey request 1007 MUST omit the REKEY_SA Notify Payloads that identifies the SA to be 1008 rekeyed. Once the new SA has been created, then the Initiator MUST 1009 delete the old CHILD_SA, which is done thanks to the Delete Notify 1010 Payload described in section 3.11 of [RFC4555]. 1012 Current IPsec / IKEv2 do not provide any mechanisms so that the 1013 Initiator can check if an IP address matches SPD and local policies 1014 of the peer. Reachability tests can be provided through the Return 1015 Routability Check mechanism of MOBIKE described in [RFC4555], but the 1016 test requires that the tested IP address is used to send the Notify 1017 Payload. In other words, this mechanism can only be useful if the 1018 Initiator is Multihomed. 1020 As a conclusion : 1022 For a single homed Initiator : The only scenario to be considered 1023 is the "Move and Reconnect". The Initiator proceeds to a 1024 CREATE_CHILD_SA, followed by a DELETE exchange. This means 1025 that the mobility action requires two message exchanges to be 1026 performed. 1027 For a multi homed Initiator : The "Move and Reconnect" scenario can 1028 be considered similarly as for a singled homed Initiator. The 1029 multihomed Initiator can proceed to the "Preconnect and Move" 1030 scenario, in the sense that it can check reachability with the 1031 COOKIE2 mechanism. 1033 10.1.2. Requirements 1035 Requirements on the Mobility and Multihoming extension are : 1037 - The Initiator MUST be able to UPDATE a Security Association, 1038 that is to say, change the IP address of an SA. 1039 - The Initiator MUST be able to check before the mobility action 1040 is performed whether or not the new IP address matches the SPD 1041 or the local policies. This means the tested IP address for 1042 the mobility can be specified as an argument and MUST NOT be in 1043 the Initiator IP address of the IP header. 1044 - When a Responder receives a request to check the validity of a 1045 mobility action it MUST be able to provide the Initiator 1046 relevant pieces of information why the IP address is not 1047 accepted. Possible reasons might be the IP address does not 1048 match the local policies, or the SPD. 1049 - Mobility MUST be performed with a single message exchange. 1051 10.2. Possible Multihoming Scenarios 1053 At the current time, multihoming is only considered with MOBIKE 1054 [RFC4555]. Multihoming is considered for the IKEv2 application, 1055 which means that IKEv2 supports multihoming. Furthermore IKEv2 1056 supports multihoming means that the Initiator provides the Responder 1057 a range of IP address the Responder might use if the current IP 1058 address happens to be unreachable. 1060 This section does not deal on how IKEv2 deals with multihoming. This 1061 paper exposes how IKEv2 can deal with multihoming of Security 1062 Association. More specifically, how an Initiator can assigned one or 1063 more IP address to a given Security Association, and how can it 1064 removes one or more IP address of a Security Association. 1066 10.2.1. Analyze 1068 As in the "Possible Mobility Scenarios", current IPsec suite 1069 mechanisms provides the Initiator the ability to create new 1070 independent Security Association. With Multihoming this would mean 1071 that the number IKE context would be extremely high. If the 1072 Initiator has m IP addresses, and the Responder n IP addresses, this 1073 would lead to the creating of 2mn CHILD_SA. With the possibility to 1074 add and remove IP address to an already existing Security 1075 Association, the number of IKEv2 CHILD_SA is 2. 1077 As mentioned in the definition section of multihoming, ADD or REMOVE 1078 an IP address is only one aspect of Multihoming. The other aspect is 1079 to provide alternate IP address to a given Security Association. 1080 This means that the Initiator SHOULD be able to inform the Responder 1081 of alternate IP address that should be used if the Initiator is not 1082 reachable with the current IP addresses. 1084 10.2.2. Requirements 1086 Requirements on the Mobility and Multihoming extension are : 1088 - The Initiator MUST be able to ADD an IP address to a given 1089 Security Association. 1090 - The Initiator MUST be able to REMOVE an IP address to a given 1091 Security Association. 1092 - For REMOVE or ADD action the Initiator MUST be able to check if 1093 the action is possible on the Responder side. This means that 1094 Responder MUST be able to provides information whether or not 1095 the action can be performed or not. If the action cannot be 1096 performed, then, the Responder MUST send information such as 1097 the IP address does not match the SPD or the local policies. 1098 - The Initiator MUST be able to provide alternate IP addresses 1099 for a given Security Association. 1101 10.3. MOBIKE and our Scenarios 1103 MOBIKE is already designed to deal with mobility and multihoming. 1104 The purpose of this section is to list the functionalities that 1105 MOBIKE already has and those that MOBIKE is missing. This section 1106 points out MOBIKE properties and how there should be expanded to 1107 match our requirements 1109 10.3.1. Analyze 1111 - Transport mode : Mobility extension for transport mode requires 1112 changes between IKEv2 and IPsec. MOBIKE is already proposing 1113 one solution for tunnel mode mobility. The main difference 1114 with transport and tunnel mode is that in the tunnel mode the 1115 SPD is defined according to the inner IP addresses, when the 1116 outer addresses are changed, only the SAD is changed. In the 1117 transport mode, SAD AND SPD MUST be changed. The PAD MUST also 1118 be checked to see if new SA can be created. 1119 - Multiple addresses : MOBIKE considers only one IP address can be 1120 used at a time. The peer has established an IKE_SA to secure 1121 IKE transactions. Sending an UPDATE_SA_ADDRESSES requires some 1122 checks, and then creating new SAD entries, checking Return 1123 Routability before deleting the old ones. Since peers are 1124 using only one IP addresses, mobility parameters are not 1125 explicitly mentioned. In fact, the address to be replaced is 1126 the one the Initiator used to have to carry the tunneled 1127 packets. The replacing IP address is the address located in 1128 the IP header of the IKE message. With a multihomed Initiator, 1129 the Initiator MUST have the ability to explicitly specify the 1130 new IP address and the IP address to be changed. The Initiator 1131 MUST also have ways to specify which SA or IKE_SA the change 1132 applies. 1133 - Alternate IP addresses : MOBIKE already provides a mechanism to 1134 provide alternate IP addresses to the Responder. Those 1135 alternate IP addresses only concerns the IKEv2 application, and 1136 does not apply to the CHILD_SAs. The Initiator SHOULD be able 1137 to specify alternate IP addresses to the different Security 1138 Associations. The main motivation for such functionalities is 1139 to provide IKEv2 the ability to communicate any information 1140 related to mobility or multihoming to Upper Layer Protocols. 1141 - NAT : MOBIKE deals with NAT, and we would like to take advantage 1142 of this work, even though we do not consider NAT. 1143 - Who decides the mobility or multihoming action : MOBIKE actions 1144 concerns only the client IP addresses. This means that the 1145 owner of the different IP address can choose to proceed to 1146 change the IP address. The only situation that excepts this 1147 rule is when a peer is not reachable, in that case, the other 1148 peer may try to use alternate IP address provided previously by 1149 the peer. We keep using this philosophy, the concerned peer 1150 should be the only one that should proceed to a mobility 1151 action. 1152 - The IP the be used : MOBIKE is using only one single IP address 1153 at a time. When sending an UPDATE_SA_ADDRESSES, MOBIKE does 1154 not specify the address to be used. The considered address is 1155 the one provided in the IKE packet header. As explained in the 1156 multiple address bullet, this rule cannot be applied anymore 1157 when more then one IP address is being used. 1159 10.3.2. Requirements 1161 Requirements on the Mobility and Multihoming extension are : 1163 - Mobility and Multihoming MUST be done with IPsec in transport 1164 and in tunnel mode. 1165 - Mobility and Multihoming action, i.e. UPDATE, REMOVE, ADD 1166 action can explicitly specifies which IP address is to be 1167 ADDed, REMOVEd, UPADTEd, and which IP address MUST replaced. 1168 Replacing IP address SHOULD NOT be necessary the one in the IP 1169 header, and the replaced IP address cannot be the "one" 1170 previously used by the Initiator. 1171 - The Initiator MUST be able to provide alternate IP addresses 1172 associated to specific SA 1174 - Ways MUST be provided to the Initiator so that it can 1175 explicitly specifies the SA or IKE_SA the action applies to. 1176 The IKE_SA and CHILD_SA is not the only value. 1178 11. Mobility Rejected by the Responder? 1180 This section describes when a Mobility request might be rejected. 1181 When do the new IP address might be rejected by the local policies or 1182 SPD? 1184 When one peer moves from one public network to another public 1185 network, we believe in most cases the Security Policy will remain the 1186 same on both IP addresses. This means that Security Policies might 1187 change when one a peer moves private IP address to a public IP 1188 address. This leads to consider the following three cases : 1190 - Case 1 : Both peers are on the private network. Peers have 1191 established a connection within a private network, and one peer 1192 moves to the public network. 1193 - Case 2 : One peer is in the public network, the other in the 1194 private network, one peer moves from the public network to the 1195 private network. 1196 - Case 3 : One peer is in the public network, the other peer is in 1197 the private network and the peer moves from the private to the 1198 public network. 1200 For topological reasons, if the peers are both within the private 1201 network and one of the peer wants to move and use a public IP address 1202 instead, specific mechanisms must be used to enable the reachability 1203 between the two hosts. Such mechanisms SHOULD involve a security 1204 gateway or a Home Agent. MIPv6 for example provides means not to 1205 break the communication and establish a tunnel between the Care of 1206 Address and the Home Agent [RFC3775]. Although MIPv6 enables the 1207 connection not to be broken, MIPv6 negotiations are required to set 1208 up the tunnel. Using MIPv6 does not change the Security Association 1209 between the peers, the Security Association is established between 1210 the private IP addresses (eventually HoA). In most cases private 1211 networks are considered as trusted network, and no Security 1212 Association will be established between the two private IP addresses. 1213 The Security Association will be negotiated between the new public IP 1214 address and the gateway to setup a secure tunnel. Since aside 1215 mechanisms MUST be provided to provide reachability of the peers, 1216 this case does not match the Move-and-reconnect scenario as specified 1217 in this section. 1219 Case 2 and case 3 suppose that one peer is in a public network, the 1220 other peer is in a private network, and a connection is established 1221 between them. Reachability between the two different networks can by 1222 provided by NAT, MIPv6, or different proxy / gateway MUST be used. 1223 We can then suppose there is an IKEv2 and a communication channel 1224 established between those two peers. Case 2 and cases 3 differs from 1225 case 1 because the connection between the peers is already 1226 established between heterogeneous networks. Case 2 supposes the peer 1227 on the public network is moving to the private network. It is highly 1228 possible that the Security Association across public and private 1229 network will be "more secured" than required Security Association set 1230 for communications within the private network. Unless internal 1231 network policy for example discards encrypted packets, it is highly 1232 possible that the mobility action can occur. After the moving action 1233 has occurred, the communication between the peers in the private 1234 network will be most probably "over protected", and the renegotiation 1235 of this Security Association might occur. Mobility action is of no 1236 use if the communication between the peers within the private network 1237 does not require any authentication nor protection at any layer. 1238 Even though private networks are considered as trusted networks, most 1239 communication should still be protected by security mechanisms such 1240 as TLS [RFC5246], WESP [I-D.grewal-ipsec-traffic-visibility]... Case 1241 3 considers the other way around, that is to say a peer going from 1242 the private network to the public network. In that case local policy 1243 on the public new IP address might requires first to upgrade security 1244 policies before moving, otherwise the connection will be broken since 1245 security policies do not match. 1247 Note that in this example we considered the private and public 1248 network as two networks that for a peer might have different Security 1249 Policies. We can extend this scenario to any networks A and network 1250 B with different security policies. 1252 The mobility action is independent of the IP protocol. Connectivity 1253 can use IPv6 or IPv4. With one or the other IP version we should use 1254 the proper added mechanism ( MIPv6 [RFC3775]). 1256 12. Scope and Restrictions 1258 Scenarios described in this paper requires extensions of MOBIKE 1259 facilities, and more specifically simultaneous use of IP addresses, 1260 and the use of transport mode. 1262 Nevertheless, one should be aware that this does not represent a 1263 complete solution for mobility, and identified restrictions are 1264 presented below. Some of them are related to the use of transport 1265 mode and upper layer protocols. 1267 - Application : Applications that can take advantage of the use of 1268 mobility and the transport mode must have been designed for in 1269 some ways. First the application should be designed with 1270 multiple short and fast query/responses. In that sense heavy 1271 download application based on one connection should not be 1272 considered. Then the application should be able to easily deal 1273 with non working connections. A typical application that 1274 matches those two requirements is a web browsing application. 1275 A web browser sends a GET message and receives a HTTP/1.1 200 1276 OK response [RFC2616]. Browser are also used to handle with 1277 non reachable server by selecting randomly the IP address from 1278 the DNS response, and that end users are used to retry when it 1279 does not work on the first click. Changing IP address while 1280 browsing the Internet has very few impacts, page downloading 1281 are not requested so continuously, the response should be quite 1282 fast, and if by chance, the mobility occurs while downloading 1283 the page, the user will re-send its request. In the next 1284 future other IP architectures involving 3.5 layers HIP 1285 [RFC4423] , LISP [I-D.farinacci-lisp], SHIM6 [RFC5533] might 1286 overcome some of the restrictions, by avoiding breaking a 1287 connection while changing the IP address... 1288 - Transport : The draft only considers modification of the IPsec 1289 and IP layer. In that sense, changes do not consider 1290 interactions with the transport layer. This means that TCP 1291 connections will be broken when a change of the IP address is 1292 occurring. The application is expected to re-initiate a 1293 connection. In other words no mechanisms are provided in this 1294 draft so to make the mobility transparent to the transport 1295 layer. 1296 - Mobility : This scenario does not consider simultaneous mobility 1297 from the MN and the CN peer. Full mobility management is the 1298 purpose of the MIPv6 [RFC3775]. This draft considers a one end 1299 mobility. The mobility considered in this draft is similar as 1300 the one considered in MOBIKE [RFC4555], except that we provide 1301 mobility for transport mode. The mobility considered in this 1302 draft, with those restrictions, might be better called 1303 "opportunistic mobility" or "nomadism". 1305 13. Acknowledgments 1307 Daniel Migault is partly funded by 3MING, a research project 1308 supported by the French 'National Research Agency'(ANR). We also 1309 thanks for their comments Pierrick Seite, Daniel Palomares and Jean 1310 Michel Combes. 1312 14. Security Considerations 1314 The whole draft is about security. 1316 15. IANA Considerations 1318 There is no IANA consideration here. 1320 16. References 1322 16.1. Normative References 1324 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1325 Requirement Levels", BCP 14, RFC 2119, March 1997. 1327 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 1328 IPv6 Specification", RFC 2473, December 1998. 1330 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 1331 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 1332 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 1334 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1335 in IPv6", RFC 3775, June 2004. 1337 [RFC3776] Arkko, J., Devarapalli, V., and F. Dupont, "Using IPsec to 1338 Protect Mobile IPv6 Signaling Between Mobile Nodes and 1339 Home Agents", RFC 3776, June 2004. 1341 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1342 Internet Protocol", RFC 4301, December 2005. 1344 [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", 1345 RFC 4306, December 2005. 1347 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1348 (MOBIKE)", RFC 4555, June 2006. 1350 [RFC4877] Devarapalli, V. and F. Dupont, "Mobile IPv6 Operation with 1351 IKEv2 and the Revised IPsec Architecture", RFC 4877, 1352 April 2007. 1354 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 1355 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 1357 [RFC5533] Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming 1358 Shim Protocol for IPv6", RFC 5533, June 2009. 1360 16.2. Informative References 1362 [I-D.farinacci-lisp] 1363 Farinacci, D., Fuller, V., Meyer, D., and D. Lewis, 1364 "Locator/ID Separation Protocol (LISP)", 1365 draft-farinacci-lisp-12 (work in progress), March 2009. 1367 [I-D.grewal-ipsec-traffic-visibility] 1368 Grewal, K., "XESP for Traffic Visibility", 1369 draft-grewal-ipsec-traffic-visibility-02 (work in 1370 progress), June 2008. 1372 [I-D.ietf-mext-rfc3775bis] 1373 Johnson, D., Perkins, C., and J. Arkko, "Mobility Support 1374 in IPv6", draft-ietf-mext-rfc3775bis-04 (work in 1375 progress), July 2009. 1377 [I-D.nikander-esp-beet-mode] 1378 Nikander, P. and J. Melen, "A Bound End-to-End Tunnel 1379 (BEET) mode for ESP", draft-nikander-esp-beet-mode-09 1380 (work in progress), August 2008. 1382 [RFC4423] Moskowitz, R. and P. Nikander, "Host Identity Protocol 1383 (HIP) Architecture", RFC 4423, May 2006. 1385 [RFC4478] Nir, Y., "Repeated Authentication in Internet Key Exchange 1386 (IKEv2) Protocol", RFC 4478, April 2006. 1388 [RFC4718] Eronen, P. and P. Hoffman, "IKEv2 Clarifications and 1389 Implementation Guidelines", RFC 4718, October 2006. 1391 [RFC5201] Moskowitz, R., Nikander, P., Jokela, P., and T. Henderson, 1392 "Host Identity Protocol", RFC 5201, April 2008. 1394 [RFC5202] Jokela, P., Moskowitz, R., and P. Nikander, "Using the 1395 Encapsulating Security Payload (ESP) Transport Format with 1396 the Host Identity Protocol (HIP)", RFC 5202, April 2008. 1398 [RFC5206] Nikander, P., Henderson, T., Vogt, C., and J. Arkko, "End- 1399 Host Mobility and Multihoming with the Host Identity 1400 Protocol", RFC 5206, April 2008. 1402 Author's Address 1404 Daniel Migault 1405 Orange Labs R&D 1406 38 rue du General Leclerc 1407 92794 Issy-les-Moulineaux Cedex 9 1408 France 1410 Phone: +33 1 45 29 60 52 1411 Email: mglt.ietf@gmail.com