idnits 2.17.1 draft-mglt-mif-security-requirements-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (November 3, 2012) is 4184 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) ** Obsolete normative reference: RFC 4960 (Obsoleted by RFC 9260) ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 MIF Working Group D. Migault 3 Internet-Draft Francetelecom - Orange 4 Intended status: Standards Track C. Williams 5 Expires: May 7, 2013 MCSR Labs 6 November 3, 2012 8 IPsec Multiple Interfaces Problem Statement 9 draft-mglt-mif-security-requirements-03.txt 11 Abstract 13 IKEv2 is the protocol used to set up and negotiate Security 14 Associations between nodes. IKEv2 has not been designed for nodes 15 with multiple interfaces. 17 This document is focused on IKEv2 ability to set up IPsec protected 18 communications between nodes with multiple interfaces. This document 19 states the problems and provides requirements for IKEv2 to ease IPsec 20 for multiple interface communication. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on May 7, 2013. 39 Copyright Notice 41 Copyright (c) 2012 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 4 57 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 3. Use Case 1: VPN with Multiple Interfaces . . . . . . . . . . . 5 59 3.1. Initial MIF IPsec Configuration . . . . . . . . . . . . . 6 60 3.1.1. Description . . . . . . . . . . . . . . . . . . . . . 6 61 3.1.2. Problem Statement . . . . . . . . . . . . . . . . . . 6 62 3.1.3. Requirements . . . . . . . . . . . . . . . . . . . . . 8 63 3.2. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 3.2.1. Description . . . . . . . . . . . . . . . . . . . . . 8 65 3.2.2. Problem Statement . . . . . . . . . . . . . . . . . . 9 66 3.2.3. Requirements . . . . . . . . . . . . . . . . . . . . . 11 67 3.3. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 12 68 3.3.1. Description . . . . . . . . . . . . . . . . . . . . . 12 69 3.3.2. Problem Statement . . . . . . . . . . . . . . . . . . 13 70 3.3.3. Requirements . . . . . . . . . . . . . . . . . . . . . 13 71 3.4. Adding an Interface . . . . . . . . . . . . . . . . . . . 14 72 3.4.1. Description . . . . . . . . . . . . . . . . . . . . . 14 73 3.4.2. Problem Statement . . . . . . . . . . . . . . . . . . 17 74 3.4.3. Requirements . . . . . . . . . . . . . . . . . . . . . 18 75 3.5. Deleting an Interface . . . . . . . . . . . . . . . . . . 18 76 3.5.1. Description . . . . . . . . . . . . . . . . . . . . . 18 77 3.5.2. Problem Statement . . . . . . . . . . . . . . . . . . 18 78 3.5.3. Requirements . . . . . . . . . . . . . . . . . . . . . 18 79 4. Use Case 2: MIF applications and IPsec Tunnel mode . . . . . . 19 80 5. Use Case 3: MIF aware applications with Transport mode . . . . 20 81 5.1. Initial MIF IPsec Configuration . . . . . . . . . . . . . 21 82 5.1.1. Description . . . . . . . . . . . . . . . . . . . . . 21 83 5.1.2. Problem Statement . . . . . . . . . . . . . . . . . . 21 84 5.1.3. Requirements . . . . . . . . . . . . . . . . . . . . . 21 85 5.2. Mobility . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 5.2.1. Description . . . . . . . . . . . . . . . . . . . . . 22 87 5.2.2. Problem Statement . . . . . . . . . . . . . . . . . . 23 88 5.2.3. Requirements . . . . . . . . . . . . . . . . . . . . . 24 89 5.3. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 24 90 5.3.1. Description . . . . . . . . . . . . . . . . . . . . . 24 91 5.3.2. Problem Statement . . . . . . . . . . . . . . . . . . 24 92 5.3.3. Requirements . . . . . . . . . . . . . . . . . . . . . 25 93 5.4. Adding an Interface . . . . . . . . . . . . . . . . . . . 25 94 5.5. Delete an Interface . . . . . . . . . . . . . . . . . . . 25 95 6. Security Considerations . . . . . . . . . . . . . . . . . . . 25 96 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 97 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 25 98 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 26 99 9.1. Normative References . . . . . . . . . . . . . . . . . . . 26 100 9.2. Informational References . . . . . . . . . . . . . . . . . 26 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 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 IPsec protocol suite [RFC4301],[RFC5996] is mainly used to: 112 - Extend a trusted domain over an untrusted network: This typically 113 corresponds to the Virtual Private Network (VPN) use case. A 114 Security Gateway is a trusted entry point to a trusted network. 115 The end user is connected to an untrusted network and tunnels 116 its traffic to the Security Gateway in a encrypted tunnel using 117 the IPsec tunnel mode. The Security Gateway decapsulates the 118 traffic and forwards it on the trusted network. Once the 119 traffic is in the trusted network it is usually not encrypted 120 anymore. In other words, the traffic is protected from the end 121 user terminal to the Security Gateway, that it to say over the 122 untrusted network. 123 - Provide end-to-end security: With end-to-end security, the traffic 124 is protected from the source - or the end user in our case - to 125 the destination. The traffic does not require to be tunneled, 126 and any segments of the network between the end user and the 127 destination is considered as untrusted. With end-to-end 128 security, one does not require encapsulation, and the IPsec 129 transport mode can be used. 131 Currently most devices have multiple interfaces. Mobile phones have 132 most of the time a Wireless LAN (WLAN) and a Radio Access Network 133 (RAN) interface. Laptop can easily have Ethernet / WLAN / RAN with 134 WiMAX interfaces. Furthermore, USB dongle can be plugged to provide 135 additional RAN and WLAN interfaces. Regular PCs, Servers, or CPEs 136 have multiple Ethernet interfaces, with additional WLAN interfaces. 138 Protocols like SCTP [RFC4960] or MOBIKE [RFC4555] have been designed 139 to use these multiple interfaces for multihoming. Only a single 140 interface is used at a time. The interface used to carry the IP 141 datagrams is called the Primary interface and other interfaces are 142 called Secondary or Alternate interfaces. Alternate interfaces are 143 only expected to be used in case the Primary interface fails. 145 However, multihoming does not enable the simultaneous use of multiple 146 interfaces which can provide a better use of the available bandwidth. 147 MPTCP [RFC6182] has been designed for that purpose, and SCTP 148 [RFC4960] can also be used for it. Raiciu and al. [Raiciu] showed 149 how using multiple paths improve the performances and robustness of 150 data centers compared to TCP. Furthermore, a communication may be 151 connected simultaneously to different networks with different 152 technologies and takes advantage of their different characteristics. 153 This is typically the case of Offload when ISPs are offloading their 154 RAN communications to a WLAN network. Motivations for offloading is 155 that RAN cannot support all mobile traffic [Cisco]. As a result, 156 with a RAN and a WLAN interface, Mobile phones and ISPs may balance 157 the communications between an unreliable WLAN with economical 158 bandwidth and always connected RAN with expensive bandwidth. 160 The document focuses on how applications and services protected with 161 IPsec can also take advantage of multiple interfaces. The 162 traditional VPN application with multiple interfaces is the first use 163 case we consider. However, with the offload usage, ISPs are 164 offloading unprotected communications, services from a trusted 165 network - like the RAN - to an untrusted and unreliable network - 166 like the WLAN. This means that the ISP must protect the 167 communications related to these services and applications while being 168 offloaded. IPsec appears to be one way to secure communications 169 transparently to the application. 171 They are two ways to secure the communications with IPsec. One way 172 is to tunnel the communication to a Security Gateway. The other is 173 to provide end to end security. The document will consider both 174 ways. 176 Section 3 considers the specific case of VPN with multiple 177 interfaces. Section 4 extends the previous use case by considering 178 the general case of IPsec protected communications using the Tunnel 179 mode. Finally Section 5 considers the case of IPsec protected 180 communications with the Transport mode. For each case, the document 181 details different scenarios that take advantage of multiple 182 interfaces. Then it positions IKEv2 toward each of these scenarios 183 and points out requirements 185 3. Use Case 1: VPN with Multiple Interfaces 187 This section describes the VPN scenario with connectivity described 188 in figure 1, the End User (EU) has multiple interfaces and figure 1 189 represents 3 interfaces bound to 3 IP addresses EU @IP_outer(i), (i 190 in {1, 2, 3}). 192 End User Security Gateway 194 +---------------------+ +----------+ 195 | | | | 196 | EU @IP_outer1 SG @IP_outer1 | 197 | EU @IP_inner1---====================--------------- 198 | EU @IP_outer2 SG @IP_outer2 | 199 | EU @IP_inner2---====================--------------- 200 | EU @IP_outer3 SG @IP_outer3 | 201 | EU @IP_inner3---====================--------------- 202 | | | | 203 +---------------------+ +----------+ 205 Figure 1: VPN with Multiple Interfaces 207 3.1. Initial MIF IPsec Configuration 209 3.1.1. Description 211 This sections details how the End User with its three interfaces set 212 (EU @IP_outer(i), i in{1, 2, 3}) can set an IPsec configuration as 213 represented in figure 1. We consider the IPsec configuration is set 214 using IKEv2, and that the End User uses only a single IKEv2 channel. 215 In other words, each interface MUST NOT be be considered 216 independently from each other with its own IKEv2 channel an own 217 Security Associations. 219 One of these End User IP addresses is used to set the IKEv2 channel. 220 This IP address is used to set the IKE_SA as well as for all IKEv2 221 exchanges. Suppose EU @IP_outer1 is used for the IKE_SA. 223 Using the IKEv2 channel, the End User requests the inner IP addresses 224 EU @IP_inner(i), i in {1, 2, 3}. If the Security Gateway has 225 multiple interfaces, it advertises the End User, what are the 226 available interfaces. 228 Once the End User has inner and outer IP addresses, it starts 229 negotiating via the IKEv2 channel the different Security 230 Associations. For each Security Association, the End User and the 231 Security Gateway SHOULD be able to agree on the Traffic Selectors 232 (i.e. the inner IP addresses) as well as the outer IP addresses used 233 for the Tunnel. 235 3.1.2. Problem Statement 237 This section positions the current IKEv2 specifications toward the 238 scenario described in Section 3.1.1 239 To request multiple inner IP addresses, the End User can use the 240 IKEv2 with multiple INTERNAL_IP*_ADDRESS Configuration Attributes in 241 the CFG Payload (Section 3.15 [RFC5996]). 243 Currently IKEv2 does not provide ways for the Security Gateway to 244 announce the End User the available outer IP addresses - SG 245 @IP_outer1, SG @IP_outer2 and SG @IP_outer3. 246 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] details how this could 247 be mitigated. Note that in the VPN use case, the initiator - that is 248 to say the End User - is more likely to request the Security Gateway 249 outer IP addresses, then the reverse. In other words, there seems 250 very few interest for the responder to know the different outer IP 251 addresses of the End User. However, as detailed in Section 5 the 252 more general case SHOULD consider that both initiator and responder 253 can advertise the available interface when the IKEv2 negotiation is 254 initiated. 256 IKEv2 makes possible the negotiation of the Security Associations 257 associated to each of the EU @IP_inner(i) IP addresses using a 258 Traffic Selector Payload with one or multiple Traffic Selectors 259 (section 3.13 [RFC5996]). IKEv2 even enables the simultaneous 260 negotiation of Security Associations. However, currently the 261 Security Association negotiation does not specify the outer IP 262 addresses. The outer IP addresses are those used for the IKEv2 263 channel. In other words, current IKEv2 only considers a single 264 working IP address for both the End User and the Security Gateway. 265 Figure 2 illustrates current IKEv2 capabilities in the VPN use case 266 with different Traffic Selectors associated to a single outer IP 267 address. While negotiating a Security Association, IKEv2 SHOULD be 268 able to specify the source and destination IP addresses. 270 Note that the benefits of specifying the outer IP addresses provides 271 the End User or Initiator the ability to use simultaneously multiple 272 interfaces. In the specific case of figure 1, the Security Gateway 273 will most likely have a single IP outer IP address. We considered 274 multiple IP addresses on the Security Gateway for the more general 275 case. 277 Currently, IKEv2 does not provide the ability to negotiate the outer 278 IP addresses of the Tunnel. By default, the outer IP addresses of 279 the Child Security Associations are those used for the IKEv2 channel. 280 This results in the configuration as represented in figure 2. The 281 configuration of figure 1 does not result from an IKEv2 negotiation. 283 End User Security Gateway 285 +---------------------+ +----------+ 286 | | | | 287 | EU @IP_outer1 SG @IP_outer1 | 288 | EU @IP_inner1---====================--------------- 289 | EU @IP_outer2 ^^ SG @IP_outer2 | 290 | EU @IP_inner2---vv 291 | EU @IP_outer3 ^ SG @IP_outer3 | 292 | EU @IP_inner3--- v 293 | | | | 294 +---------------------+ +----------+ 296 Figure 2: VPN with Multiple Interfaces 297 Current IKEv2 negotiation 299 3.1.3. Requirements 301 In order to make the End User set its IPsec configuration as 302 represented in figure 1, IKEv2 SHOULD make possible: 303 - 1. To specify the different outer IP addresses for the tunnel mode 304 in the Security Association negotiation. 305 - 2. Make possible the Responder and Initiator to announce its 306 interfaces. 308 3.2. Mobility 310 3.2.1. Description 312 This section considers how a node with multiple interfaces can modify 313 the value of the outer IP address. In the Tunnel mode, changing the 314 outer IP address results in a mobility, however this should be seen 315 as updating a parameter of the Security Association. Figure 3 316 illustrates a mobility where EU @IP_outer3 in Figure 1 is updated by 317 EU @IP_outer4. 319 In fact, the Security Association associated to EU @IP_inner3 320 includes the outer IP address of the tunnel. The End User and the 321 Security Gateway MUST change this outer IP address from EU 322 @IP_outer3. The End User MUST modify its Security Association so 323 that packets sent to the Security Gateway are using a valid IP 324 address. Similarly, the Security Gateway MUST update its Security 325 Association so that it can send packets to a reachable destination IP 326 address. The notification of the update is performed using the IKEv2 327 channel, that is to say in our case EU @IP_outer1. 329 Figure 3 illustrates the case where EU @IP_outer4 is using the same 330 network hardware interface as EU @IP_outer3. This corresponds to the 331 case where, for example, the End User decides to use EU @IP_outer4 332 instead of EU @IP_outer3 on the same hardware network interface. 333 Other mobility use cases may also consider the EU @IP_outer4 may be 334 associated to a different network hardware, including the one 335 associated to EU @IP_outer(i), i in {1, 2}. Then, EU @IP_outer4 is 336 different from EU @IP_outer3 but may be one of the EU @IP_outer(i), i 337 in {1, 2}. 339 End User Security Gateway 341 +---------------------+ +----------+ 342 | | | | 343 | EU @IP_outer1 SG @IP_outer1 | 344 | EU @IP_inner1---====================--------------- 345 | EU @IP_outer2 SG @IP_outer2 | 346 | EU @IP_inner2---====================--------------- 347 | EU @IP_outer4 SG @IP_outer3 | 348 | EU @IP_inner3---====================--------------- 349 | | | | 350 +---------------------+ +----------+ 352 Figure 3: VPN Mobility 354 3.2.2. Problem Statement 356 Currently IKEv2 proposes different alternative to update a Security 357 Association, and modify the outer IP address of the Tunnel. However 358 none of them really address the description provided in Section 3.2.1 360 3.2.2.1. MOBIKE 362 MOBIKE [RFC4555] provides an UPDATE_SA_ADDRESSES exchange that 363 updates the outer IP address of the tunnel. As explained in this 364 section MOBIKE cannot be used in the general case described in figure 365 3 because the updated IP address is necessarily the one associated to 366 the IKEv2 channel. This limitation is due to the fact that MOBIKE 367 has been designed for a single interface. 369 MOBIKE does not explicitly specify in its message the IP address that 370 has to be updated and the new value for this IP address. The IP 371 address to be updated is the one used by the IKEv2 channel, and the 372 new IP address to consider is the IP address used in the IP header of 373 the UPDATE_SA_ADDRESSES message. 375 If EU @IP_outer1 is equal to to EU @IP_outer3, then sending an 376 UPDATE_SA_ADDRESSES would update the outer tunnel IP address of the 377 Security Associations using the IP address of the IKEv2 channel, that 378 is at least EU @IP_outer1 and EU @IP_outer3, with EU @IP_outer4. 380 This case is only a specific case and is not applicable when the 381 outer IP address to update is different from the IP address used for 382 the IKEv2 channel. 384 If EU @IP_outer3 is different from EU @IP_outer1, then, the only way 385 to use MOBIKE is to move the IKEv2 channel to EU @IP_outer3, that is 386 updating EU @IP_outer1 by EU @IP_outer3, and then updating EU 387 @IP_outer3 by EU @IP_outer4. This is not convenient because all 388 traffic on EU @IP_outer1 has been transferred to EU @IP_outer3, and 389 then to EU @IP_outer4. Furthermore, it is only possible for managed 390 mobility, because we need EU @IP_outer3 to be a valid interface until 391 IKEv2 uses EU @IP_outer3. In other words, if EU @IP_outer3 fails 392 suddenly, moving the IKEv2 channel to EU @IP_outer3 is not possible 393 anymore. 395 As a result MOBIKE cannot be used to handle the mobility described in 396 Section 3.2.1. 398 3.2.2.2. CREATE_CHILD_SA 400 A second alternative is to renegotiates a new Security Association 401 between the End User and the Security Gateway. IKEv2 provides the 402 CREATE_CHILD_SA Exchange (Section 1.3 [RFC5996]) to create a new 403 Security Association. Similarly Section 3.1.2 this exchange does not 404 specify the outer IP address of the Tunnel. By default, the outer IP 405 address of the Tunnel is the IP address used for the IKEv2 channel. 406 This does not address the use case described in Section 3.2.1. 408 If requirements of Section 3.1.3 were fulfilled, that is to say even 409 if the CREATE_CHILD_SA would enable to negotiate the outer IP 410 addresses of the Tunnel, then, using the CREATE_CHILD_SA exchange 411 would be an alternative. However, this alternative would still 412 suffer from several drawbacks: 413 - Not Mandatory: The CREATE_CHILD_SA is not a mandatory IKEv2 414 feature, especially for light implementations. For these 415 implementation, an non reachable interface would require re- 416 negotiating both the IKE_SA and the new Security Association. 417 Furthermore, there is currently no way to advertise whether the 418 implementation supports or not this exchange. 419 - Resource Consuming Exchange: The CREATE_CHILD exchange creates a 420 Security Association from scratch and requires all parameters 421 of the Security Association to be specified. This results in a 422 quite complex exchange, which does not take advantage of the 423 already negotiated parameters, like nonces, Keys, Traffic 424 Selectors, Nonces, SPIs. Instead it requires all these 425 parameters to be renegotiated, generation of nonces, keys, as 426 well as multiple interactions with IPsec databases which 427 requires more resources than updating a single parameter within 428 a Security Association. 429 - Two-Successive Exchange: The CREATE_CHILD exchange creates a new 430 Security Association, however, the previously used Security 431 Association has not been removed from the IPsec databases. As 432 a result, once the new Security Association has been created, a 433 new exchange SHOULD be performed to delete the previous 434 Security Association with the Delete Payload (Section 3.11 435 [RFC5996]. The Delete Payload specifies the Security 436 Associations to Delete. 437 - Per Security Association Exchange: The CREATE_CHILD_SA exchange 438 creates a specific Security Association, which means that there 439 are as many CREATE_CHILD_SA exchanges as Security Association 440 to update. In our case, multiple Security Associations may be 441 bound to a single interface, so the Security Association 442 granularity is not convenient for interface management. 443 Updating an interface implies that all Security Association 444 bound to this interface MUST be updated. In the use case 445 illustrated by figure 3, the End User a single Security 446 Association per interface, so interface and Security 447 Association management have similar granularity. On the other 448 end, for the Security Gateway with a single interface, i.e. 449 (all SG @IP_outer(i), i in{1, 2, 3} are the same), interface an 450 Security Association do not have the same granularity. Note 451 that with a single interface the Security Gateway would be able 452 to use MOBIKE, but not with two interface (i.e. is SG 453 @IP_outer2 and SG @IP_outer3 would be the same). 455 3.2.2.3. One IKE channel per Interface 457 A fourth alternative consists renegotiating an complete independent 458 IKEv2 channel and a new Security Association. This is out of the 459 scope of this document. This may result as having a IKEv2 channel 460 per interface. Furthermore, independent IKEv2 channels may not 461 simplify IPsec configuration and may result in multiple Security 462 Associations matching a given Traffic Selector, which may cause 463 trouble at least for outbound traffic. Furthermore, in this case, 464 the End User and the Security Gateway must proceed to an 465 authentication. 467 3.2.3. Requirements 469 In order to make the End User set its IPsec configuration as 470 represented in figure 3, IKEv2 SHOULD make possible: 471 - 1. To update the outer IP address of the tunnel with a IP address 472 that differs from those used for the IKEv2 channel. The Update 473 is not a per security Association negotiation but SHOULD 474 replace all Security Association associated to the old IP 475 address. For all these Security Associations, the old IP 476 address is replaced by the new IP address. This consists in 477 extending MOBIKE UPDATE_SA_ADDRESSES exchange. 479 3.3. Multihoming 481 3.3.1. Description 483 This section considers how a node can take advantage of multiple 484 interfaces with multihoming. In case one of these interface fails, 485 then another interface can be used instead. Moving the traffic from 486 one interface to the other is called mobility. This section deals 487 with multihoming, that is the two peers agree that in case an 488 interface fails, a mobility should be triggered on the agreed 489 interface. 491 Suppose, as represented in figure 4, EU @IP_outer3 is not reachable 492 anymore. Applications that are multiple interfaces aware, and also 493 bound to the others EU @IP_inner(i) (i in {1, 2}) IP addresses may 494 handle EU @IP_outer3 non reachability. On the other hand non 495 multiple interfaces aware applications (like regular TCP connections) 496 bound to EU @IP_outer3 are stalled and cannot use the other 497 interfaces. 499 One way to recover the EU @IP_inner3 unreachability is to reconfigure 500 the Security Association and replace EU @IP_outer3 by EU @IP_outer(i) 501 (i in {1, 2}). Figure 5 shows that EU @IP_outer3 is replaced by EU 502 @IP_outer2. EU @IP_outer2 has been provided as an Alternate IP 503 address of EU @IP_outer3. This means that when one or the other peer 504 notice EU @IP_outer3 is down, it can trigger a mobility with the 505 appropriated outer IP address. More specifically, the Security 506 Gateway can overcome the failure of EU @IP_outer3, if it detects the 507 failure before the End User. The End User and the Security Gateway 508 can also agree on an ordered list of Alternate IP addresses. 510 End User Security Gateway 512 +---------------------+ +----------+ 513 | | | | 514 | EU @IP_outer1 SG @IP_outer1 | 515 | EU @IP_inner1---====================--------------- 516 | EU @IP_outer2 SG @IP_outer2 | 517 | EU @IP_inner2---====================--------------- 518 | SG @IP_outer3 | 519 | EU @IP_inner3--- --------------- 520 | | | | 521 +---------------------+ +----------+ 523 Figure 4: VPN with Mobility/Multihoming between 524 Multiple Interfaces: EU @IP_outer3 unreachable 526 End User Security Gateway 528 +---------------------+ +----------+ 529 | | | | 530 | EU @IP_outer1 SG @IP_outer1 | 531 | EU @IP_inner1---====================--------------- 532 | EU @IP_outer2 SG @IP_outer2 | 533 | EU @IP_inner2---====================--------------- 534 | |v| |^| SG @IP_outer3 | 535 | EU @IP_inner3---v ^==========--------------- 536 | | | | 537 +---------------------+ +----------+ 539 Figure 5: VPN with Mobility/Multihoming between 540 Multiple Interfaces: EU @IP_outer2 541 replaces EU @IP_outer3 543 3.3.2. Problem Statement 545 Currently Multihoming is handled by MOBIKE with the 546 ADDITIONAL_IP*_ADDRESS Notify Payloads. As with mobility, these 547 payloads are only provided for the interface used by the IKEv2 548 channel. The main reason is that MOBIKE has been designed for a 549 single interface. In our cas,e MOBIKE would only make possible to 550 provide Alternate IP addresses to EU @IP_outer1. 552 What happens to packets when the Security Gateway performs 553 Multihoming and the End User has not updated its Security 554 Association? Both End User and Security Gateway Security 555 Associations are configured to use the EU @IP_outer3 IP address. 556 When the Security Gateway notices EU @IP_outer3 is not reachable it 557 updates its Security Association, triggers a mobility exchange and 558 may start sending packets to EU @IP_outer2 before the End User has 559 proceeded to the update of its Security Associations. The End User 560 receives this packet and performs a Security Association match. 561 Outer IP addresses will not performed a match, and the match occurs 562 with the Security Policy Index (SPI). The packet is checked against 563 the Security Policy Databases Selectors. These selectors are based 564 on the inner IP addresses and have not been modified. As a result, 565 packets will not be discarded. 567 3.3.3. Requirements 569 In order to make the End User set its IPsec configuration as 570 represented in figure 3, IKEv2 SHOULD make possible: 572 - 1. To provide Alternate IP addresses for IP addresses that are 573 different from the one used by the IKEv2 channel. This extends 574 the Multihoming features of MOBIKE to multiple interfaces. 575 - 2. Reduce the complexity of Multihoming. Although a node MUST be 576 able to provide Alternate IP address for a given IP address, it 577 should also be able to provide all its interfaces, and if 578 multihoming is supported on both side, a multihoming rule 579 should be derived by default from this list. 581 3.4. Adding an Interface 583 3.4.1. Description 585 Nodes with multiple interfaces may have some interfaces supporting 586 the VPN whereas other interfaces have not been assigned an IP 587 address. When this interface has been assigned an IP address, the 588 current VPN communication may take advantage of this newly available 589 interface. This section is concerned on how a given communication 590 can take advantage of a newly available interface and set its IPsec 591 settings in an optimal way. 593 Figure 6 represents the End User with multiple interfaces connected 594 to the Security Gateway. We only represented a single interface for 595 the Security Gateway but more interfaces may be also considered. In 596 figure 7, the Security Gateway has an additional interface that 597 becomes active, it advertises the End User this interface is 598 available. The End User may perform some latency and Round Trip Time 599 measurements and decide to use it. In the figure 7, the End User 600 moves the traffic associated to its interface EU @IP_outer3 to the 601 newly available interface SG @IP_outer2 of the Security Gateway. 602 Moving the traffic is performed through a mobility operation as 603 described in Section 3.2. 605 End User Security Gateway 607 +---------------------+ +-------------+ 608 | | | | 609 | EU @IP_outer1 | | 610 | EU @IP_inner1---========== ^| | | 611 | EU @IP_outer2 |v| SG @IP_outer1 | 612 | EU @IP_inner2---====================--------------- 613 | EU @IP_outer3 |^| | | 614 | EU @IP_inner3---========== v| | | 615 | | | | 616 +---------------------+ +-------------+ 618 Figure 6: Security Gateway with a single Interface 619 End User Security Gateway 621 +---------------------+ +-------------+ 622 | | | | 623 | EU @IP_outer1 | | 624 | EU @IP_inner1---========== ^| | | 625 | EU @IP_outer2 |v| SG @IP_outer1 | 626 | EU @IP_inner2---====================--------------- 627 | EU @IP_outer3 SG @IP_outer2 | 628 | EU @IP_inner3---====================--------------- 629 | | | | 630 +---------------------+ +-------------+ 632 Figure 7: Security Gateway adding an Interface 633 New Interface used by the EU @IP_outer3 635 Figure 6 and 7 illustrated the case, where the Security Gateway has 636 an additional active interface. In this case, the Security Gateway 637 let the End User decide which interface they prefer to use. By 638 announcing the newly available interfaces no new Security 639 Associations are created. On the other hand, the End User may also 640 want that any service using the other interfaces can use this newly 641 available interface. This requires to derive the Security 642 Associations associated to the new interface from those associated to 643 the already established interfaces. The Security Associations 644 derived for the newly active interface are not created from scratch 645 with a complete negotiation. This case is illustrated by figure 8 646 and 9. 648 End User Security Gateway 650 +---------------------+ +-------------+ 651 | | | | 652 | EU @IP_outer1 | | 653 | EU @IP_inner1---========== ^| | | 654 | EU @IP_outer2 |v| SG @IP_outer1 | 655 | EU @IP_inner2---====================--------------- 656 | | | 657 | EU @IP_inner3--- | | 658 | | | | 659 +---------------------+ +-------------+ 661 Figure 7: End User with an inactive interface 662 End User Security Gateway 664 +---------------------+ +-------------+ 665 | | | | 666 | EU @IP_outer1 | | 667 | EU @IP_inner1---========== ^| | | 668 | EU @IP_outer2 |v| SG @IP_outer1 | 669 | EU @IP_inner2---====================--------------- 670 | EU @IP_outer3 |^| | | 671 | EU @IP_inner3---===========v | | 672 | | | | 673 +---------------------+ +-------------+ 675 Figure 8: End User with a newly active interface 676 EU @IP_outer3. All traffic associated to 677 EU @IP_outer1 and EU @IP_outer2 is able to 678 use EU @IP_outer3 680 In our case, the End User already had a specific inner IP address 681 associated to the newly available interface EU @IP_outer3. This 682 makes possible the End User to generate the new IPsec Security 683 Associations and new Security Policies associated to EU @IP_outer3. 684 When the Security Gateway receives the request to add the newly 685 available interface, it may set the newly Security Policies and 686 Security Associations. However, the End User may not have an inner 687 IP address EU @IP_inner3, and may combine the request to the Security 688 Gateway to add the new interface, with a request for a EU @IP_inner3 689 address. In that case, the Security Gateway first sets the IPsec 690 databases, and the End User sets the IPsec databases when it receives 691 the inner IP address. 693 When an interface is added, unless otherwise specified, the End User 694 wants that all services, except IKEv2 using the available outer IP 695 addresses (EU @IP_outer1 and @IP_outer2 addresses) may also be 696 configured to use the newly available IP address EU @IP_outer3. By 697 adding an interface the End User is not using a finer granularity 698 than the interface granularity. In other words, it does not want to 699 specify how Security Associations are derived. They should be 700 derived in an automatic way. In return, deriving Security 701 Associations and Security Policies is expect to optimize their 702 creation as opposed to using CREATE_CHILD_SA. 704 In the example of figure 7 and 8, the End User is likely to create 705 Security Associations derived from those established with the 706 interfaces EU @IP_outer1 and EU @IP_outer2. All services using EU 707 @IP_outer1 or EU @IP_outer2 will be able to use EU @IP_outer3 with 708 the inner IP address EU @IP_inner3. 710 The idea is to copy the Security Association associated with EU 711 @IP_outer1 replace EU @IP_outer1 by EU @IP_outer3 and EU @IP_inner1 712 by EU @IP_inner3. SPIs MUST also be changed since there are unique 713 for the Security Association. Then we perform the same with EU 714 @IP_outer2. 716 Note that it is important to specify an ordered list of EU @IP_outer 717 address from which the new SAs are derived, so to guarantee that 718 these new Security Associations are derived the same way on both 719 peers. Then the new Security Association MUST be created only if 720 there are no already existing matching SPD selectors. 722 In the most basic case of VPN, we only have one Security Association 723 per interface. All services using EU @IP_inner(i) are tunneled to EU 724 @IP_outer(i) i in{1,2}. Adding EU @IP_outer3 only requires to derive 725 Security Association from one interface EU @IP_outer1 and EU 726 @IP_outer2. Then, the End User needs to specify the inner and outer 727 IP addresses EU @IP_inner3, EU @IP_outer3 and in the specific case 728 represented on figure 7 the outer IP address of the Security Gateway 729 SG @IP_outer3. The resulting exchange may look something like the 730 exchange represented in figure 10. The mandatory parameters are the 731 IP address used for the traffic selectors, and the outer IP address 732 for the Tunnel on the End User. The destination outer IP address of 733 the Tunnel is optional and, if not specified may be the one used by 734 the IKEv2 channel. The list of interfaces from which are derived the 735 Security Associations and the Security Policies may also be optional. 736 A default value for this list may be the ordered list of associated 737 outer IP addresses of the End User. The nonce may be used to create 738 SPIs. 740 End User Security Gateway 742 request Add Interface (EU @IP_inner3, ---> 743 EU @IP_outer3, [outer-destination] 744 [interface-list] [nonce]) 746 normal case <--- N() 748 error case <--- N(error) 750 Figure 10: Principle of the Adding Interface 751 exchange 753 3.4.2. Problem Statement 755 Currently IPsec does not provide any means for a peer to advertise a 756 new interface is available. MOBIKE makes possible to advertise a 757 Alternate IP address is available. However Alternate IP addresses 758 are only intended to be use in case the Primary Interface is down. 759 In our case, the interface is ready for use. This issue is similar 760 to the one detailed in Section 3.1.2. However, here the announcement 761 corresponds to a dynamic changes, and the list of available IP 762 address does not occurs during the IKE_INIT exchange, but in a 763 regular information exchange. 765 Currently the only way IKEv2 provides to create new Security 766 Associations is the CREATE_CHILD_SA exchange. Disadvantages of this 767 exchange have been described in Section 3.2.2. The key advantage of 768 adding an interface is to provide an optimized interface management 769 exchange instead of a Security Association management exchange. 771 3.4.3. Requirements 773 In order to make the End User set its IPsec configuration as 774 represented in figure 1, IKEv2 SHOULD make possible: 775 - 1. Make possible the Responder and Initiator to announce its 776 interfaces outside the IKE_INIT exchange. This requirements is 777 similar to the one of Section 3.1.3 778 - 1. Make possible the Responder and Initiator to automatically 779 derive Security Associations and Security Policies from the 780 existing interface. 782 3.5. Deleting an Interface 784 3.5.1. Description 786 Nodes with multiple interfaces in dynamic environment may have 787 interfaces that are not reachable anymore. This may trigger mobility 788 or multihoming actions. However, the node may also want to delete 789 the Security Associations bound to this interface either as a Tunnel 790 outer IP address or as a Traffic Selector. 792 3.5.2. Problem Statement 794 Currently IKEv2 does not make possible to delete an interface from 795 multiple Security Associations. IKEv2 provides a Delete Payload 796 (Section 3.11 [RFC5996] that deletes one or multiple specific 797 Security Associations, identified by their SPI. 799 3.5.3. Requirements 801 In order to make the End User set its IPsec configuration as 802 represented in figure 3, IKEv2 SHOULD make possible: 804 - 1. Delete an interface, that is to say all Security Associations 805 associated to that interface. 807 4. Use Case 2: MIF applications and IPsec Tunnel mode 809 This section considers applications that can deal with multiple 810 interfaces. This ability can be done with transport layer protocols 811 like MPTCP or SCTP or with applications using one or multiple UDP / 812 TCP connections over the various interfaces, and that manages how to 813 send the data. 815 The difference between multiple interfaces aware applications and the 816 VPN use case is that the tunnels are established per services, 817 whereas the VPN tunnel all traffic is tunneled to a unique Security 818 Gateway. This may increase the number of Security Associations 819 between the End User and the Security Gateway. This section details 820 motivation for using the IPsec Tunnel mode with multiple interfaces 821 aware applications and position it to the VPN use case of Section 3. 823 Applications may use the tunnel mode for end-to-end security and to 824 benefit from the Mobility features provided by the Tunnel mode. More 825 specifically, using the Tunnel mode provides Mobility without 826 breaking the connectivity, if upper layer is not mobility aware. 828 Other motivations for using the Security Gateway is that the End User 829 chose not to tunnel all its traffic to the Security Gateway, but only 830 the traffic that worth being protected. For example, an End User may 831 chose not to tunnel its "youtube" traffic, as well as some of its 832 "https" traffic (as well as it application layer protected traffic). 833 On the other hand, it may want to tunnel all non-protected "http" (as 834 well as other non protected communications). 836 If each service proposes different Security Gateways, the use case is 837 very similar to the VPN use case, for each service. The main 838 difference is that Security Association are established with 839 different Traffic Selectors. 841 If multiple services are using the same Security Gateway, this will 842 result for each interface, in multiple Security Associations 843 established with the same Security Gateway - one per service. This 844 case is very similar to the VPN use case but with multiple Security 845 Associations. If "s" is the number of Services connected on the 846 Security Gateway the number of Security Associations is at least "s" 847 5services are considered independent). If some applications are 848 using multiple flows, then this number may be even larger. In that 849 case, adding an interface results in at least negotiating "s" new 850 Security Associations. Using the CREATE_CHILD_SA exchange may 851 require "s" exchanges whereas using the Adding interface exchange 852 requires only one exchange. This use case is represented in figure 853 11. 855 End User Security Gateway 857 +----------------------+ +----------+ 858 | Services: S1 - Ss | | | 859 | EU @IP_outer1 SG @IP_outer1 | 860 | P EU @IP_inner1 ---====================--------------- 861 | o EU @IP_outer2 SG @IP_outer2 | 862 | r EU @IP_inner2 ---====================--------------- 863 | t EU @IP_outer3 SG @IP_outer3 | 864 | s EU @IP_inner3 ---====================--------------- 865 | | | | 866 +----------------------+ +----------+ 868 Figure 11: MIF aware applications 870 Requirements of this use case have already been mentioned in the VPN 871 use case. 873 5. Use Case 3: MIF aware applications with Transport mode 875 This Use Case is very similar to the Use Case 2 except that the 876 Transport mode is used instead of the Tunnel mode. The Use Case is 877 illustrated with figure 12. 879 Unlike in the VPN use case in Section 3 or for multiple interfaces 880 aware applications described in Section 4 using IPsec tunnel mode, 881 the IPsec Transport mode does not involves inner IP addresses. 883 With Transport mode, we may consider two types of applications. The 884 applications that can handle multiple interfaces. This can be done 885 with transport protocols like MPTCP or SCTP or with a connection 886 manager at the application layer. These applications may have 887 Security Associations on all interfaces. Other Applications with a 888 single using TCP/UDP and without specific connection managers may 889 only deal with a single interface and may only have an Security 890 Association associated to this interface. 892 End User Server 894 +---------------------+ +----------+ 895 | Applications | | | 896 | EU @IP_outer1 S @IP_outer1 | 897 | MPTCP/TCP -------------------------------------- 898 | EU @IP_outer2 S @IP_outer2 | 899 | -------------------------------------- 900 | EU @IP_outer3 S @IP_outer3 | 901 | -------------------------------------- 902 | | | | 903 +---------------------+ +----------+ 905 Figure 12: MIF aware applications with the 906 Transport mode 908 5.1. Initial MIF IPsec Configuration 910 5.1.1. Description 912 In Figure 12, the End User initiates an IKEv2 negotiation using EU 913 @IP_outer1 and S @IP_outer1. The Server provides the End User the 914 available interfaces (S @IP_outer1 i in {1, 2, 3}). Then the End 915 User negotiates Security Associations between the EU @IP_outer(i) and 916 S @IP_outer(i) i in{1,2,3} using different Traffic Selectors. 918 5.1.2. Problem Statement 920 Currently IKEv2 does not make possible a node to announce its 921 available interfaces. 923 The Transport mode, does not involve tunnel outer IP addresses. 924 Current Security Association exchange enables Traffic Selectors 925 negotiation. These Traffic Selectors are used both for the Security 926 Policy Index (Traffic Selectors) for outgoing traffic and for the 927 Security Association Index for incoming traffic. Current IKEv2 928 specification enables to set IPsec as described in figure 11. 930 5.1.3. Requirements 932 In order to make the End User set its IPsec configuration as 933 represented in figure 1, IKEv2 SHOULD make possible 934 - 1. Make possible the Responder and Initiator to announce its 935 interfaces. This requirement is similar to the requirements 936 for VPNs. 938 5.2. Mobility 940 With regular TCP connection a change of the IP address breaks the 941 connection. Applications may use mobility with the Transport mode 942 with transport protocols that handles with multiple interfaces (like 943 MPTCP or SCTP for example), with multiple independent TCP/UDP 944 connections on the different interfaces. The application manages its 945 connections at the application layer. 947 Mobility with Transport mode MUST be understood as updating an 948 existing Security Association. The purpose of the IPsec Mobility and 949 the Transport mode is to avoid to create a new Security Association 950 when the IP address of an interface is changing. IPsec configures 951 the layer so that the application can securely go on with its 952 communications. TCP connections are restarted, since changing the IP 953 address will most likely break the existing connection. UDP will 954 start sending on the other interface. Mobility is intended to reduce 955 the time IPsec requires to configure its Security Associations. 957 With the Tunnel mode, IPsec was in charge of securing and 958 transporting IP datagrams. With the Transport mode, IPsec only 959 secures the communication. Transport of the IP datagrams is shared 960 between the application and the transport layer. Application and 961 IPsec layers are independent and have their own way to handle with 962 mobility. Synchronization between these two layers MUST be performed 963 to avoid that the application moves the traffic on an interface 964 whereas IPsec DISCARD this traffic. Although we do not intend to 965 provide a complete list of how to synchronize these two layers, the 966 list below provides some example where these two layers are 967 synchronized: 968 - 1. For End Users with two interfaces. In that case, the interface 969 the application may use s determined. 970 - 2. For applications that are configured with two interfaces. 971 - 3. For applications that we know the interface they will choose. 972 Like those setting priority to interfaces. This could be set 973 by using Multihoming and ordering the Alternate IP addresses. 974 - 4. If the Mobility exchange is triggered by the new socket, new 975 packet sent. This case reduces the latency over a 976 CREATE_CHILD_SA exchange, but does not anticipate the decision 977 of the application. 979 5.2.1. Description 981 The mobility scenario we consider in this section is an application 982 using a single interface EU @IP_outer3 for example. As represented 983 in figure 13, this interface is down. Then the End User get assigned 984 a new IP address EU @IP_outer4 and uses this interface as represented 985 in figure 14. Both End User and Server MUST update Security Policies 986 and Security Associations that used EU @IP_outer3 and replace the 987 value with EU @IP_outer4. Unlike the Tunnel mode, Traffic Selectors 988 also need to be updated. 990 End User Server 992 +---------------------+ +----------+ 993 | | | | 994 | EU @IP_outer1 SG @IP_outer1 | 995 | -------------------------------------- 996 | EU @IP_outer2 SG @IP_outer2 | 997 | -------------------------------------- 998 | SG @IP_outer3 | 999 | Application ---x --------------- 1000 | | | | 1001 +---------------------+ +----------+ 1003 Figure 13: Mobility with Transport mode and 1004 Multiple Interfaces: EU @IP_outer3 1005 unreachable. 1007 End User Server 1009 +---------------------+ +----------+ 1010 | | | | 1011 | EU @IP_outer1 SG @IP_outer1 | 1012 | -------------------------------------- 1013 | EU @IP_outer2 SG @IP_outer2 | 1014 | -------------------------------------- 1015 | EU @IP_outer4 SG @IP_outer3 | 1016 | Application -------------------------------------- 1017 | | | | 1018 +---------------------+ +----------+ 1020 Figure 14: Mobility with Transport mode and 1021 Multiple Interfaces: EU @IP_outer4 1022 replaces EU @IP_outer3. 1024 5.2.2. Problem Statement 1026 Currently IKEv2 does not provide extension that perform any mobility 1027 operation. 1029 MOBIKE has only been designed for the Tunnel mode. 1031 The CREATE_CHILD_SA suffers for limitations exposed in Section 3.2.2: 1032 It is not mandatory in IKEv2 implementation, the exchange requires 1033 much resources as updating the Security associations. Most of the 1034 time, it requires an addition Delete exchange and is a per Security 1035 Association exchange. However, because no tunnel IP address requires 1036 to be negotiated, the CREATE_CHILD_SA can set the Security 1037 Associations and Policies as described in figure 14. 1039 5.2.3. Requirements 1041 In order to make the End User set its IPsec configuration as 1042 represented in figure 1, IKEv2 SHOULD make possible 1043 - 1. Extend MOBIKE to the Transport mode 1044 - 2. Extend MOBIKE with Transport mode to multiple interfaces 1045 requirements described in Section 3.2.3. 1047 5.3. Multihoming 1049 Multihoming consists in providing Alternate Interfaces in case a 1050 running interface is down, so peers are aware of the parameters to 1051 update. Multihoming can be seen as pre-configuring an mobility 1052 operation. 1054 5.3.1. Description 1056 With Multihoming, when the End User sets its IPsec configuration as 1057 illustrated in figure 12, the End User also specifies for each 1058 interface the corresponding Alternate IP address. Although this an 1059 be done on a per interface value, we suggest that when multiple 1060 interfaces are provided, Alternate IP addresses can be derived 1061 automatically and assigned to each interface without being explicitly 1062 mentioned. Suppose that in the case of figure 13, for example EU 1063 @IP_outer2 is provisioned as the Alternate IP address of EU 1064 @IP_outer3. 1066 When EU @IP_outer3 is down, then the End User or the Server triggers 1067 a mobility exchange as described in section Section 5.2.1. 1069 5.3.2. Problem Statement 1071 Currently IKEv2 does not make possible to provision Alternate IP 1072 addresses for the Transport mode. MOBIKE has only been designed for 1073 the Tunnel mode, then as mentioned in Section 3.3.2, MOBIKE only 1074 assigns the Alternate IP address for the IP address used by the IKEv2 1075 channel. This is because MOBIKE has been designed for a single 1076 interface. 1078 Note that with the Transport mode, the Alternate Address is provided 1079 to the outer IP address that is also used as a Traffic Selector, 1080 whereas in the Tunnel mode, the Alternate IP address is provided for 1081 the tunnel outer IP address. 1083 Note also that the IKEv2 channel is a special case where Alternate 1084 Address is associated to the Transport mode. In fact the IKEv2 1085 channel uses Transport mode, not the Tunnel mode. 1087 5.3.3. Requirements 1089 In order to make the End User set its IPsec configuration as 1090 represented in figure 1, IKEv2 SHOULD make possible to: 1091 - 1. Extend MOBIKE Multihoming to the Transport mode 1092 - 2. Extend MOBIKE with Transport mode to multiple interfaces 1093 requirements described in Section 3.3.3. Alternate IP address 1094 should be assigned to any interface and can be automatically be 1095 derived. Alternate IP address concerns Traffic Selectors and 1096 Security Association Indexes. 1098 5.4. Adding an Interface 1100 Adding an interface works exactly as described in Section 3.4. The 1101 only difference is that when an interface is added with the Transport 1102 mode, Traffic Selectors will automatically be associated to this 1103 newly added interface, which was not necessarily the case with the 1104 Tunnel mode. 1106 5.5. Delete an Interface 1108 Similarly to the addition of a new interface, Deleting an interface 1109 works exactly as described in Section 3.5. The only difference is 1110 that with the Transport mode, Security Associations and Security 1111 Policies to delete are these where the specified interface appears as 1112 a Traffic Selector rather than as an outer tunnel IP address. 1114 6. Security Considerations 1116 The whole document sets MIF requirements for a security protocol. 1118 7. IANA Considerations 1120 There is no IANA consideration here. 1122 8. Acknowledgment 1124 We would like to thank Daniel Palomares, Pierrick Seite, Brian 1125 Carpenter, Hui Deng, Jong-Hyouk Lee, Juan Carlos Zuniga and 1126 Konstantinos Pentikousis for their useful comments. 1128 9. References 1130 9.1. Normative References 1132 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1133 Requirement Levels", BCP 14, RFC 2119, March 1997. 1135 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 1136 Internet Protocol", RFC 4301, December 2005. 1138 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 1139 (MOBIKE)", RFC 4555, June 2006. 1141 [RFC4960] Stewart, R., "Stream Control Transmission Protocol", 1142 RFC 4960, September 2007. 1144 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 1145 "Internet Key Exchange Protocol Version 2 (IKEv2)", 1146 RFC 5996, September 2010. 1148 9.2. Informational References 1150 [Cisco] "Cisco Visual Networking Index: Global Mobile Data Traffic 1151 Forecast Update, 2010-2015", February 2011. 1153 [I-D.arora-ipsecme-ikev2-alt-tunnel-addresses] 1154 Arora, J. and P. Kumar, "Alternate Tunnel Addresses for 1155 IKEv2", draft-arora-ipsecme-ikev2-alt-tunnel-addresses-00 1156 (work in progress), April 2010. 1158 [RFC6182] Ford, A., Raiciu, C., Handley, M., Barre, S., and J. 1159 Iyengar, "Architectural Guidelines for Multipath TCP 1160 Development", RFC 6182, March 2011. 1162 [Raiciu] Arora, C., Barre, S., Plunkte, C., Greenhalgh, A., 1163 Wischik, D., and M. Handley, "Improving datacenter 1164 performance and robustness with multipath TCP", SIGCOMM 1165 2011 Toronto, Canada, August 2011. 1167 Authors' Addresses 1169 Daniel Migault 1170 Francetelecom - Orange 1171 38 rue du General Leclerc 1172 92794 Issy-les-Moulineaux Cedex 9 1173 France 1175 Phone: +33 1 45 29 60 52 1176 Email: mglt.ietf@gmail.com 1178 Carl Williams 1179 MCSR Labs 1180 Philadelphia, PA 19103 1181 USA 1183 Phone: 650-279-5903 1184 Email: carlw@mcsr-labs.org