idnits 2.17.1 draft-mglt-mif-security-requirements-01.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 == Line 280 has weird spacing: '...channel i.e. ...' -- The document date (March 29, 2012) is 4411 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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: September 30, 2012 MCSR Labs 6 March 29, 2012 8 Multiple Interfaces IPsec Security Requirements 9 draft-mglt-mif-security-requirements-01.txt 11 Abstract 13 ISPs wants to take advantage of MIF Transport protocols like SCTP, 14 MPTCP to enhance their End User's experience when the End User has 15 been offloaded on WLAN. In addition, WLAN are untrusted so ISPs MUST 16 Secure at least some of their End Users's communications. For 17 various reasons IPsec is the protocol they choose to secure the 18 communications. Currently, IPsec is not adapted to Multiple 19 Interfaces Environment. IPsec can hardly be configured in a proper 20 way which may result in breaking End Users' communications. At 21 least, it makes it very hard for the End Users to combine Security 22 with MIF enhancements. MOBIKE partly address the problem for a 23 single Interface. This draft provides the problem statement and 24 defines the IPsec Security Requirements for MIF. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 30, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 61 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3 63 3.1. Adding Interfaces Dynamically . . . . . . . . . . . . . . 3 64 3.2. Removing Interfaces Dynamically . . . . . . . . . . . . . 4 65 3.3. Multihoming . . . . . . . . . . . . . . . . . . . . . . . 5 66 3.4. Hard Handover Mobility . . . . . . . . . . . . . . . . . . 5 67 3.5. Soft Handover Mobility . . . . . . . . . . . . . . . . . . 5 68 3.6. Selecting Traffic . . . . . . . . . . . . . . . . . . . . 6 69 3.7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4. Multiple Interfaces Offload Security Requirements . . . . . . 7 71 5. Position toward MOBIKE . . . . . . . . . . . . . . . . . . . . 9 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 74 8. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 10 75 9. Normative References . . . . . . . . . . . . . . . . . . . . . 10 76 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 78 1. Requirements notation 80 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 81 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 82 document are to be interpreted as described in [RFC2119]. 84 2. Introduction 86 Current Radio Access Network (RAN) infrastructure will not be able to 87 deal with the next future traffic increase. Consequently ISPs are 88 willing to offload the RAN traffic on alternate networks like WLAN. 89 RAN and WLAN have different characteristics, and compared to RAN, 90 WLAN may be untrusted, unreliable and the Network Interface 91 management is performed by the End User (EU). As a consequence, when 92 a EU switches a non-secured communication from RAN to WLAN, it MUST 93 be able to secure it. Then communications on WLAN takes advantage of 94 Multiple Interfaces to enhance the EU experience on WLAN. Thus, such 95 communications MUST have their security appropriately configured to 96 keep the communication secured and avoid that Security breaks the 97 communication. 99 Section Section 3 describes the Problem Statement: an IPsec secured 100 communication cannot benefit from MIF features. Then, section 101 Section 4 provides the IPsec Security Requirements for Multiple 102 Interfaces, Mobility and Multihoming. Section Section 5 positions 103 MOBIKE [RFC4555] toward the Security Requirements, and provides the 104 additional features MUST be defined for MOBIKE. 106 3. Problem Statement 108 3.1. Adding Interfaces Dynamically 110 The EU may be connected through multiple WLAN Access Points for 111 bandwidth aggregation. Eventually, splitting flows among various 112 Access Points may also be one way to overcome WLAN Access Points 113 unreliability. The EU may be able to add or remove an Interface on a 114 given communication. Protocols like SCTP or MPTCP have especially 115 been designed for that purpose. In fact, SCTP through AS-CONF 116 message is able to dynamically add Interfaces to a given SCTP 117 association. 119 When the EU is being offloaded, the communication may be secured with 120 IPsec. In this draft we consider two scenarios: (1) One where the 121 communication is encapsulated to a Security Gateway through multiple 122 IPsec tunnels (one per Interface). This scenarios may not require 123 the Server to see the EU with Multiple Interfaces. (2) The other 124 scenario considers a communication where the EU is connected via 125 Multiple Interfaces directly to the Server. In that case, the 126 communication is secured with IPsec transport mode. The main 127 motivation for using End-to-End security is to limit Security Gateway 128 latencies and limit the security overhead. 130 When the nodes discovers a new Interface, we expect that IPsec adds 131 this Interface. From the existing IPsec Security Associations 132 related to the communication, IPsec MUST be able to derive for both 133 the EU and the Server the IPsec configuration for the ADDed 134 Interface. More specifically, if the EU is connected to a Security 135 Gateway, the EU MUST configure a new IPsec Tunnel so that the 136 communication can be tunnelled from the new Interface to the Security 137 Gateway. With communication, we mean that the EU may send or receive 138 packets related to the communication. If the EU is directly 139 connected to the Server, the EU MUST configure IPsec so that the 140 communication can be also protected by using the new Interface. Note 141 that IPsec does not define which interface SHOULD be used. IPsec is 142 configured so that other protocols in charge of carrying the traffic 143 may be able to choose one or the other Interface. 145 Currently IPsec does not provide such mechanisms. This means that 146 any time the EU discovers an Interface, it will have to initiate an 147 IKEv2 negotiation that authenticates the EU and the Server and 148 derives the key material. We want to avoid multiple negotiations for 149 a given communication. 151 An alternative would be to use MOBIKE Multihoming, which provides the 152 opportunity to the EU to add the new Interface with the 153 ADDITIONAL_IP*_ADDRESS Notify Payload. This would make the new 154 Interface being considered as an Alternate Interface. In other 155 words, this Interface could be used only if the EU would become 156 unreachable on the running Interface. This does not provide Multiple 157 Interfaces. A single Interface is used at a time, and this is what 158 MOBIKE has been designed for. Furthermore MOBIKE only considers the 159 Tunnel mode, which would only address the Security Gateway scenario. 161 3.2. Removing Interfaces Dynamically 163 The EU may use Multiple connections on WLAN, section Section 3.1 164 explains why the EU may be able to dynamically ADD interfaces to a 165 given communication. Similarly, this section shows that the EU MUST 166 also be able to REMOVE Interfaces from a communication. There may be 167 multiple reasons to REMOVE an Interface. The Interface may not be 168 reachable, the EU may not want to use this Interface anymore... On a 169 security point of view, when an Interface is not used for a secure 170 communication, IPsec MUST explicitly DISCARD all traffic on that 171 Interface. 173 Currently IKEv2 provides the possibility to DELETE a Security 174 Association. However, this requires a per Security Association 175 Negotiation. With frequent Interface changes, and the Multiple 176 Interfaces of the EU, this negotiations require too many Notify 177 Payload. The EU, simply wants to advertise the Server to REMOVE an 178 Interface with a single Notify Payload. 180 MOBIKE overcomes this management issue by using a single Interface. 181 Consequently there is only one active Interface. 183 3.3. Multihoming 185 Multihoming is the ability to provision Interfaces in case the 186 running Interface is not reachable anymore. For a secure 187 communication, the EU wants to provide one or a range of Alternate IP 188 addresses that MUST be used in case the Primary Interface is not 189 reachable. The difference with ADDing an interface to an given 190 communication is that with Multihoming the Alternate MUST be used 191 only if the Primary Interface is not reachable. On an IPsec point of 192 view, it means that IPsec MUST be configured to DISCARD any packets 193 of the communication unless the Primary Interface is not reachable. 194 When the Primary Interface is not reachable, then IPsec MUST be 195 configured to PROTECT or BYPASS the traffic for the given 196 communication. 198 Currently MOBIKE provides Multihoming. However, MOBIKE does not make 199 possible to assign a list of Alternate Interfaces to a specific 200 communication. The reason is that MOBIKE only considers a single 201 working interface. 203 3.4. Hard Handover Mobility 205 Hard Handover Mobility is the ability for a host to update an 206 Interface with another. This generates the packets of the Network to 207 be discarded. In an IPsec point of view, updating the Security 208 Association results in DISCARDing packets sent or received on the new 209 Interface, and accepting (BYPASSing or PROTECTing) packets on the old 210 Interface not anymore used. 212 IPsec with MOBIKE provides this facility. However, it is only 213 provided for the Tunnel mode. 215 3.5. Soft Handover Mobility 217 Soft Handover is the ability to switch from an old Interface to the a 218 new Interface with a state where both old and new Interfaces can send 219 or receive traffic so to avoid loosing the packets in the network. 220 Soft Handover can be done with a combination of ADD and REMOVE 221 operations described in section Section 3.1 and section Section 3.2 223 As mentioned in section Section 3.1 and section Section 3.2, they are 224 currently NOT handled by MOBIKE. 226 3.6. Selecting Traffic 228 The EU MUST be able to ADD / REMOVE an Interface, to provide 229 Alternate Interface for Multihoming, or perform some Mobility with 230 Soft Handover or Hard Handover. However in the previous sections 231 such operations have been considered as a global policy for the EU. 232 In fact the EU may not have the same policy for all its traffic. 233 Thus such operations MUST be provided for a given traffic. 234 Motivations may be that the EU may keep some corporate traffic inside 235 a corporate network (private IP addresses, confidentiality...) 236 whereas Internet traffic can use any Interface and especially the one 237 providing the highest bandwidth. 239 MOBIKE does not provide this kind of facility since it considered a 240 single Interface in use. 242 3.7. Conclusion 244 This section address common scenario for an EU being offloaded on the 245 a WLAN. The EU may be connected to a Security Gateway or directly 246 connected to the Service. In both cases, the EU MUST be able to: 247 - ADD an Interface: When the EU has discovered a new Interface, it 248 MUST be able to add this Interface to its current 249 configuration. This means, that IPsec MUST be configured to be 250 able to receive or send traffic on all its interfaces. 251 - REMOVE an Interface: When the EU notice that one Interface is not 252 active, it MUST be able to remove this Interface to its current 253 configuration. This means that IPsec MUST NOT PROTECT any 254 traffic on this Interface. 255 - Mobility: The EU MUST be able to perform Hard Handover as well as 256 Soft Handover. 257 - Multihoming: When one link fails, the EU MUST be able to 258 automatically switch the traffic to an Alternate IP address. 259 This means that IPsec MUST be configured to be able to receive 260 or send traffic on that Interface. 261 - Traffic Selectors: The EU MUST be able to perform all the above 262 operations globally or for a given traffic. Thus, it MUST be 263 able to indicate which traffic the operation MUST be applied 264 to. 266 4. Multiple Interfaces Offload Security Requirements 268 Then follows the Multiple Interfaces Offload Security Requirements. 269 Note they only concern the Security layer. The only purpose of those 270 Requirements is to properly configure the EU Security Layer so that 271 the Security Layer does not stall or affect the EU communication. 272 Since this draft considers IPsec [RFC4301] and IKEv2 [RFC5998], 273 Multiple Interfaces, Multihoming and Mobility address two different 274 channels: 275 - The DATA channel: i.e. EU communication. In that case, Security 276 Requirements means how to secure properly the IPsec Security 277 Policy Database and Security Association Database, so that 278 IPsec do not block the EU communication. This is like 279 configuring a firewall. 280 - IKEv2 channel i.e. IKEv2 application. IKEv2 is the IPsec 281 application that configures the IPsec Databases. The 282 application MUST be Multiple Interfaces, Multihoming and 283 Mobility aware so to configure properly the IPsec Databases for 284 the DATA channel. 286 Here are the following Security Requirements: 287 - Multiple Interfaces: 288 - DATA channel: For the DATA channel, Multiple Interfaces 289 means that the EU MUST be able to ADD or REMOVE an IP 290 address to a given secured communication. Suppose an EU 291 has established a communication with a Server using an 292 Interface I_OLD. When it detects an new Interface I_NEW, 293 the EU MUST be able to configure IPsec Databases so that 294 the communication can go through I_OLD or I_NEW without 295 being discarded. Note that how the DATA traffic is 296 handled and effectively routed on one or the other or 297 both Interfaces is out of scope of the draft. Similarly, 298 when the EU is communicating to the Server with Multiple 299 Interfaces, it MUST be able to configure IPsec Databases 300 so that one or multiple interfaces MUST NOT accept / 301 handle any traffic. 302 - IKEv2 channel: For the IKEv2 channel, we suppose using one 303 interface is sufficient. The IKEv2 channel only carries 304 signalization messages. If the EU wants to change the 305 Interface for IKEv2, then it SHOULD perform a Mobility. 306 - Multihoming: 307 - DATA channel: For the DATA channel, Multihoming means that 308 the EU MUST be able to provide Alternate Interfaces to 309 the Server. In the case the Primary (or running) 310 Interface fails, the communication with the Server MUST 311 be able to go on on the Alternate Interface. More 312 specifically, this means that when the Primary Interface 313 is detected as being down, the EU and the Server MUST 314 configure the IPsec Databases so that the communication 315 can use the Alternate Interface. The difference with 316 ADDing and Interface in the Multiple Interfaces case is 317 that until the Primary Interface is down, the Alternate 318 Interface does not receive or transmit any traffic. 319 Alternate Interfaces DISCARD such traffic. 320 - IKEv2 channel: For the IKEv2 channel, Multihoming means that 321 when the Primary Interface is down, IKEv2 MUST be able to 322 switch to the Alternate Interface to send IKEv2 323 signalization messages to the Server. Once IKEv2 has 324 recovered from the Primary Interface crash-down, it can 325 proceed to the DATA channel IPsec configuration. 326 - Mobility: 327 - DATA channel: For the DATA channel, Mobility means that the 328 EU MUST be able to UPDATE the IPsec Databases and change 329 an old Interface (I_OLD) by a new Interface (I_NEW). 330 There are two ways to do so. With a Hard Handover, I_OLD 331 is replaced by I_NEW. Packets that are in the network or 332 in the network stack of the Server and EU when the update 333 occurs will be DISCARDED by the EU. With Soft Handover, 334 the EU ADDs I_NEW and configures its IPsec Databases to 335 receive / send traffic on both I_OLD and I_NEW. Then it 336 REMOVEs I_OLD when no traffic is anymore expected on that 337 Interface. Note that Soft Handover is performed 338 according to the Multiple Interfaces Requirements. 339 - IKEv2 channel: For the IKEv2 channel, as mentioned in the 340 Multiple Interfaces item, Hard Handover may be 341 sufficient, since the channel only carries signalization 342 messages. Once IKEv2 has moved the IKEv2 channel, it 343 configures IPsec Databases for the DATA channel. 344 - Traffic Selector: 345 - DATA channel: For DATA channel Traffic Selector MUST specify 346 which traffic the Mobility, Multihoming, Multiple 347 Interface action MUST be performed. 348 - IKEv2 channel: For the IKEv2, Mobility and Multiple 349 Interface operation may be done with a Hard Handover. 350 However, for Multihoming the channel SHOULD be consider 351 as a specific traffic. 353 Note that when this draft considers Mobility, Multiple Interfaces or 354 Mobility, only the IPsec configuration is affected. However, in some 355 cases, the configuration of the IPsec Databases may affect the 356 communication of the EU. In fact, if the EU is securing its 357 communication with IPsec and the Tunnel mode, a modification of the 358 outer Interface results in moving the communication. In that case, 359 communication mobility results as a side effect of IPsec Database 360 configuration and this is what is used in MOBIKE [RFC4555]. This 361 case does not happen with the IPsec Transport mode, and the 362 communication mobility MUST be handled by other protocols then IPsec 363 (application, SHIM6, SCTP, MPTCP... 365 5. Position toward MOBIKE 367 Multihoming Security Requirements are partly handled by IPsec MOBIKE 368 [RFC4555] extension. MOBIKE has been designed for the VPN Mobility 369 and Multihoming use case with a single interface. Thus MOBIKE only 370 addresses the Security Gateway, with the IPsec Tunnel mode. More 371 specifically, MOBIKE does neither address the Transport mode, nor the 372 case of Multiple Interfaces. 374 Here are the Mobility and Multihoming MOBIKE features: 375 - MOBIKE Mobility: MOBIKE provides Mobility by UPDATING the outer IP 376 address. Because MOBIKE considers a single interface, the 377 UPDATE occurs for both the IKEv2 channel and the DATA channel. 378 Furthermore, Because MOBIKE only considers the Tunnel mode, 379 UPDATing the IPsec Databases results in moving the 380 communication as a side effect. Because the EU has a single 381 interface, Mobility is always a Hard Handover. 382 - MOBIKE Multihoming: MOBIKE provides Multihoming mechanism. The 383 two peers are able to exchange Alternate IP addresses. In case 384 the the Primary IP address is not reachable, IKEv2 tests the 385 Alternate IP address is still reachable with a COOKIE2 386 exchange. If the Alternate IP address is still reachable, 387 MOBIKE triggers a MOBILITY and UPDATEs the Primary Address by 388 the Alternate IP address. Because the EU has only a single 389 interface, both DATA and IKEv2 channels are updated. Because 390 MOBIKE only considers the Tunnel mode, only communications with 391 Tunnel mode will be updated. 393 MOBIKE provides Mobility and Multihoming features. However, MOBIKE 394 currently partly addresses the Security Requirements: 395 - Multiple Interfaces: This is NOT addressed by MOBIKE. This means 396 that currently EU with communications involving Multiple 397 Interfaces will need to establish an IKE channel on each 398 Interface. This also means that there is no Security Interface 399 Management facilities, and for example Soft Handover is NOT 400 possible. 401 - Mobility: MOBIKE addresses Mobility only for Hard Handover with 402 IPsec Tunnel mode protection. As a result the Security Gateway 403 Scenario is partly addressed. To completely address it with 404 Soft Handover, MOBIKE needs to be extended for Multiple 405 Interfaces. Furthermore, to address End-to-End security with 406 the Server, MOBIKE also needs to be extended for the Transport 407 mode. 409 - Multihoming: MOBIKE Multihoming features currently address the 410 Security Requirements at least for the IKEv2 channel. For the 411 DATA channel, Multihoming may be extended for Multiple 412 Interface by providing Alternate IP addresses for each 413 Interface. 415 A a result, MOBIKE requires the following extensions: 416 - Mobility for Transport: to support all offload architecture, 417 especially those with End-to-End Security. 418 - Mobility for Soft Handover: to make possible Soft Handover for 419 both Transport and Tunnel mode. Note that Soft Handover is 420 related to Multiple Interfaces Management. 421 - Multihoming for Multiple Interfaces: Multihoming SHOULD be 422 provided with different Alternate IP addresses depending on the 423 network the connection is currently working. Note that it is also 424 related to Multiple Interface Management. 425 - Multiple Interfaces Management: MOBIKE MUST consider Multiple 426 Interfaces Management for operations it has been designed for like 427 Mobility and Multihoming. It MUST also provide generic extension 428 to make Multiple Interface Management, such as ADDing or REMOVing 429 an Interface. 430 - Traffic Selector: the EU MUST be able to explicitly specify which 431 traffic the operation applies. 433 6. Security Considerations 435 The whole draft is about security. 437 7. IANA Considerations 439 There is no IANA consideration here. 441 8. Acknowledgment 443 We would like to thank Daniel Palomares, Pierrick Seite, Brian 444 Carpenter, Hui Deng and Jong-Hyouk Lee for their useful comments. 446 9. Normative References 448 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 449 Requirement Levels", BCP 14, RFC 2119, March 1997. 451 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 452 Internet Protocol", RFC 4301, December 2005. 454 [RFC4555] Eronen, P., "IKEv2 Mobility and Multihoming Protocol 455 (MOBIKE)", RFC 4555, June 2006. 457 [RFC5998] Eronen, P., Tschofenig, H., and Y. Sheffer, "An Extension 458 for EAP-Only Authentication in IKEv2", RFC 5998, 459 September 2010. 461 Authors' Addresses 463 Daniel Migault 464 Francetelecom - Orange 465 38 rue du General Leclerc 466 92794 Issy-les-Moulineaux Cedex 9 467 France 469 Phone: +33 1 45 29 60 52 470 Email: mglt.ietf@gmail.com 472 Carl Williams 473 MCSR Labs 474 Philadelphia, PA 19103 475 USA 477 Phone: 650-279-5903 478 Email: carlw@mcsr-labs.org