Individual N. Suresh Kumar Internet-Draft Samsung Electronics Intended status: Standards Track August 03, 2016 Expires: February 02, 2017 IKEv2 Multihoming support draft-suresh-ipsecme-ikev2-multihoming-support-02 Abstract Multihoming provides devices the ability to connect to multiple networks and thus, provide higher throughput and improved resilience to network failure(s). This document describes enhancement of Internet Key Exchange version 2 protocol [IKEv2] to support multihoming to avoid redundant IKE negotiations to create and maintain tunnel for multiple connections possible between the tunnel peers. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 02, 2017. Copyright and License Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. Suresh Expires February 02, 2017 [Page 1] Internet-Draft IKEv2 Multihoming support August 2016 This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Usage Scenarios . . . . . . . . . . . . . . . . . . . . . . 4 1.1.1. Security Gateway to Security Gateway . . . . . . . . . 4 1.1.2. Endpoint to Endpoint . . . . . . . . . . . . . . . . . 5 1.1.3. Endpoint to Security Gateway . . . . . . . . . . . . . 6 1.1.4. Other Scenarios . . . . . . . . . . . . . . . . . . . . 7 1.2. Real life usage scenarios . . . . . . . . . . . . . . . . . 7 1.2.1. Gateway perspective . . . . . . . . . . . . . . . . . . 7 1.2.2. End-point perspective . . . . . . . . . . . . . . . . . 8 1.3. Multihoming Connection Management . . . . . . . . . . . . . 8 1.4. The Multihoming Support payload . . . . . . . . . . . . . . 9 1.4.1. Initiator only supports . . . . . . . . . . . . . . . . 9 1.4.2. Responder only supports . . . . . . . . . . . . . . . . 10 1.4.3. Both peers supports . . . . . . . . . . . . . . . . . . 10 1.5. The Add connection payload . . . . . . . . . . . . . . . . 10 1.5.1. Connection addition - CREATE_CHILD_SA exchange . . . . 10 1.5.2. Connection addition - INFORMATIONAL exchange . . . . . 11 1.6. The Delete connection payload . . . . . . . . . . . . . . . 12 1.7. The Confirm Connection payload . . . . . . . . . . . . . . 13 1.8. KEY management across connections . . . . . . . . . . . . . 13 1.9. Re-key mechanism across connections . . . . . . . . . . . . 13 2. Multihoming header formats . . . . . . . . . . . . . . . . . . 13 2.1. Critical bit handling . . . . . . . . . . . . . . . . . . . 13 2.2. Exchange Types . . . . . . . . . . . . . . . . . . . . . . 14 2.3. Payload Types . . . . . . . . . . . . . . . . . . . . . . . 14 2.4. Add Connection Payload . . . . . . . . . . . . . . . . . . 15 2.4.1. Add Connections substructure . . . . . . . . . . . . . 15 2.5. Delete Connection Payload . . . . . . . . . . . . . . . . . 17 2.5.1. Delete Connections substructure . . . . . . . . . . . . 17 2.6. Confirm Connection Payload . . . . . . . . . . . . . . . . 18 Suresh Expires February 02, 2017 [Page 2] Internet-Draft IKEv2 Multihoming support August 2016 2.6.1. Confirm Connections substructure . . . . . . . . . . . 19 3. Keep-alive and dead peer detection . . . . . . . . . . . . . . 20 4. Performance considerations . . . . . . . . . . . . . . . . . . 20 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 20 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 21 7. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 21 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 8.1. Normative References . . . . . . . . . . . . . . . . . . . . 22 8.2. Informative References . . . . . . . . . . . . . . . . . . . 22 Authors' Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 1. Introduction Multihoming has been a mechanism by which various sites can provide satisfactory services for high-level requirements. With increase in mobile equipments, multihoming is no longer a mechanism of sites for providing better services. Mobile equipments with multiple network connectivity; cellular, and Wi-Fi are explicitly harness multihoming capabilities at client side as well. Multihoming is fast becoming an important component of every connected device due to enhanced throughput delivery at client side. Multipath TCP [RFC6824] utilizes multihoming to provide improved user experience through higher throughput and improved resilience to network failure. Internet Key Exchange protocol version 2 [IKEv2], defines a method to perform mutual authentication between two parties, and establish and maintain Security Associations (SAs). IKE_SA_INIT and IKE_AUTH exchanges establish IKE SA; subsequent IKE exchange CREATE_CHILD_SA to establish child SAs and INFORMATIONAL exchanges for management (deletion of an SA, reporting error conditions, or perform other housekeeping). In general, totally 4 exchanges (single IKE_SA_INIT exchange and a single IKE_AUTH exchange) are required to establish the IKE SA and the first Child SA per connection of device. In case of multihoming devices, 4 such exchanges are required per connection even though the end devices are same. This results in increase of negotiations and in some cases memory for maitaining SAs, which are major limitations of IKEv2 for supporting multihoming devices. This document proposes IKEv2 enhancements to support multihoming, to overcome the above limitations; in general - Suresh Expires February 02, 2017 [Page 3] Internet-Draft IKEv2 Multihoming support August 2016 o a total of 4 negotiations if Initiator requests connection addition during initial negotiation o a total of 5 negotiations if Responder requests connection addition during initial negotiation o a total of 2 negotiations for connection addition at any stage after initial negotiation (irresepctive of Initiator or responder) o no additional memory for SAs Additionally, Dead-Peer-Detection or Keep-Alive message handling is also improved. Single connection's Keep-Alive messages can govern Dead-Peer-Detection. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 1.1. Usage Scenarios Multihoming mechanism MAY be available at both peers, peers MAY or utilize multihoming capability to establish secured communication with each other. There are a number of different scenarios, each with its own set of special requirements. 1.1.1. Security Gateway to Security Gateway +-+-+-+-+-+ +-+-+-+-+-+ | | | | | |<--------------->| | Protected |Tunnel | IPsec |Tunnel | Protected Subnet <-->|Endpoint | |Endpoint |<--> Subnet | | tunnel(s) | | | |<--------------->| | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 1: Security Gateway to Security Gateway Suresh Expires February 02, 2017 [Page 4] Internet-Draft IKEv2 Multihoming support August 2016 +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | ------------>| | Protected |Tunnel | | IPsec |Tunnel | Protected Subnet <-->|Endpoint |<---| |Endpoint |<--> Subnet | | | tunnel(s) | | | | ------------>| | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 2: Security Gateway to Security Gateway In this scenario, Security Gateways with Multihoming capabilities can utilize the capability of multiple connections to provided improved throughput and improved resilience to network failure(s). Either both or a single Security Gateway can establish IPsec tunnel(s) with each other utilizing its available multiple connections. 1.1.2. Endpoint to Endpoint +-+-+-+-+-+ +-+-+-+-+-+ | | | | | |<------------------------------------>| | |Protected| IPsec transport |Protected| |Endpoint | or |Endpoint | | | tunnel mode SA(s) | | | |<------------------------------------>| | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 3: Endpoint to Endpoint Suresh Expires February 02, 2017 [Page 5] Internet-Draft IKEv2 Multihoming support August 2016 +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | ------------------------------>| | |Protected| | IPsec transport |Protected| |Endpoint |<------| or |Endpoint | | | | tunnel mode SA(s) | | | | ------------------------------>| | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 4: Endpoint to Endpoint In this scenario, Protected Endpoint(s) with Multihoming capabilities can utilize the capability of multiple connections to provided improved throughput. Either both or a single Protected Endpoint can establish IPsec tunnel(s) with each other utilizing its available multiple connections. 1.1.3. Endpoint to Security Gateway +-+-+-+-+-+ +-+-+-+-+-+ | | | | | |<------------------------>| | Protected |Protected| |Tunnel | Subnet |Endpoint | IPsec tunnel(s) |Endpoint |<--- and/or | | | | Internet | |<------------------------>| | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 5: Endpoint to Security Gateway Tunnel +-+-+-+-+-+ +-+-+-+-+-+ | | | | | |<-------------------- | | Protected |Protected| | |Tunnel | Subnet |Endpoint | IPsec tunnel(s) |---->|Endpoint |<--- and/or | | | | | Internet | |<-------------------- | | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 6: Endpoint to Security Gateway Tunnel Suresh Expires February 02, 2017 [Page 6] Internet-Draft IKEv2 Multihoming support August 2016 +-+-+-+-+-+ +-+-+-+-+-+ | | | | | | ---------------------| | Protected |Protected| | |Tunnel | Subnet |Endpoint |<----| IPsec tunnel(s) |Endpoint |<--- and/or | | | | | Internet | | ---------------------| | | | | | +-+-+-+-+-+ +-+-+-+-+-+ Figure 7: Endpoint to Security Gateway Tunnel In this scenario, Protected Endpoint with Multihoming capabilities can utilize the capability of multiple connections to provided improved throughput. Security Gateway can also utilize Multihoming capability to provide improved resilience to network failure(s) along with improved throughput. 1.1.4. Other Scenarios Other scenarios are possible, as are nested combinations of 1.1.1 - 1.1.3. 1.2. Real life usage scenarios Most of the real life scenarios can utilize the benefits of this specification. Some of the scenarios are explained below. 1.2.1. Gateway perspective Gateways with multihoming capability utilize available connections between each other to provide better throughput through load sharing and/or resilience against network failure(s). In case of establishing tunnel between the gateways, multiple IKE transactions are a MUST for each possible tunnel(s) between the peer connections. For example, if there are 2 conections at each peer then there are 4 possible tunnels between the peers; hence the total number of IKE transactions would be 12 to ensure that all the 4 tunnels between the peers are established. This specification would reduce the load on network for IKE transactions required to establish multiple tunnels. Suresh Expires February 02, 2017 [Page 7] Internet-Draft IKEv2 Multihoming support August 2016 1.2.2. End-point perspective End-points with multihoming capability utilize available connections improve overall throughput and sustain mobility of tunnel. For example, a mobile device can utilize Wi-Fi connection alongwith cellular connection to improve throughput. In this case, 2 tunnels need to be established with the same gateway/peer (assuming there is no multihoming support at the other end for simplicity) to ensure that data is always tunnel irrespective of the path taken. In another example, soft handover across Cellular and Wi-Fi connections would need a make and break of tunnel unless there is an additional protocol executing at the network. This specification ensures that the load on network and bandwidth usage at end-point is reduced for multiple tunnel establishment. Also soft handover across Cellular and Wi-Fi connections would not require either any make and break mechanism or additional protocol at the network. 1.3. Multihoming Connection Management Peers advertise available support for Multihoming during IKE_SA_INIT Exchange. Peers can add and remove connections only if both peers support Multihoming. Either of the peers MAY request for addition of connection(s) to an on-going Security session or request for deletion of connection(s) from an on-going Security session. Connection(s) added would share the same IKE and Child SAs as the default IKE SAs and Child SAs. Multihoming support is conveyed using MCi and MCr payload; Connection addition, confirmation and deletion are requested through ACi, CCi and DCi payloads respectively for Initiator (ACr, CCr and [DCr] payloads respectively for Responder). In the following descriptions, the payloads contained in the message are indicated by names as listed below. Suresh Expires February 02, 2017 [Page 8] Internet-Draft IKEv2 Multihoming support August 2016 Notation Payload ------------------------------------------- AUTH Authentication ACi Add Connection - Initiator ACr Add Connection - Responder CCi Confirm Connection - Initiator CCr Confirm Connection - Responder CERT Certificate CERTREQ Certificate Request CP Configuration D Delete DC Delete Connection EAP Extensible Authentication HDR IKE header (not a payload) IDi Identification - Initiator IDr Identification - Responder IP Internet Protocol address KE Key Exchange MSi Multihoming support - Initiator MSr Multihoming support - Responder Ni, Nr Nonce N Notify SA Security Association SK Encrypted and Authenticated 1.4. The Multihoming Support payload Any peer supporting this standard MUST send MS payload to convey Multihoming support availability to the peer. MS payload MUST be sent in IKE_SA_INIT Excahnge by each peer. 1.4.1. Initiator only supports There is a possibility that only Initiator supports Multihoming as shown - Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni [,MSi] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] Suresh Expires February 02, 2017 [Page 9] Internet-Draft IKEv2 Multihoming support August 2016 1.4.2. Responder only supports There is a possibility that only Responder supports Multihoming as shown below - Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] [,MSr] 1.4.3. Both peers support There is a possibility that both the peers support Multihoming as shown below - Initiator Responder ------------------------------------------------------------------- HDR, SAi1, KEi, Ni [,MSi] --> <-- HDR, SAr1, KEr, Nr, [CERTREQ] [,MSr] Multihoming can be supported only in case of 1.4.3., when both peers have support for Multihoming. 1.5. The Add connection payload Connection addition is requested through ACi payload (ACr payload for Responder). There MAY be multiple connection requested to be added in single Add connection payload. There MUST be single Add connection payload within a single Exchange (CREATE_CHILD_SA or INFORMATION Exchange). Connection can be added at any point of time after IKE_SA_INIT Exchange is successfully completed. 1.5.1. Connection addition - CREATE_CHILD_SA exchange Peers can initiate add connection during tunnel establishment phase, ADD_CONN payload SHOULD be part of CREATE_CHILD_SA exchange in this case. If add connection is requested by Initiator then Responder can reply back in CREATE_CHILD_SA response with CCr payload. Suresh Expires February 02, 2017 [Page 10] Internet-Draft IKEv2 Multihoming support August 2016 Initiator Responder ------------------------------------------------------------------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr [,ACi]} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr [,CCr]} If add connection is requested by Responder then Initiator MUST reply back in additional CREATE_CHILD_SA response with only CCi payload. Initiator Responder ------------------------------------------------------------------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr [,ACr]} HDR, SK {[,CCi]} --> This is a special case, wherein 5 exchanges are required to complete tunnel establishment. Both Initiator and Responder can request add connection resulting in 5 exchanges to complete tunnel establishment. Initiator Responder ------------------------------------------------------------------- HDR, SK {IDi, [CERT,] [CERTREQ,] [IDr,] AUTH, SAi2, TSi, TSr [,ACi]} --> <-- HDR, SK {IDr, [CERT,] AUTH, SAr2, TSi, TSr [,ACr] [,CCr]} HDR, SK {[,CCi]} --> 1.5.2. Connection addition - INFORMATIONAL exchange Peers can initiate add connection anytime after tunnel establishment phase, ADD_CONN payload MUST be part of CREATE_CHILD_SA exchange in this case. Suresh Expires February 02, 2017 [Page 11] Internet-Draft IKEv2 Multihoming support August 2016 If add connection is requested by Initiator then Responder can reply back in CCr payload. Initiator Responder ------------------------------------------------------------------- HDR, SK {[N,] [D,] [CP,] [ACi,] ...} --> <-- HDR, SK {[N,] [D,] [CP,] CCr...} If add connection is requested by Responder then Initiator can reply back in CCi payload. Initiator Responder ------------------------------------------------------------------- <-- HDR, SK {[N,] [D,] [CP,] ACr...} HDR, SK {[N,] [D,] [CP,] [CCi,] ...} --> 1.6. The Delete connection payload Connection deletion is requested through DCi payload ([DCr] payload for Responder). There MAY be multiple connection requested to be deleted in single Delete connection payload. Delete connection payload MUST be part of an INFORMATIONAL exchange. There MUST be single Delete connection payload within a single INFORMATION Exchange. If delete connection is requested by Initiator then Responder MUST reply back CCr payload. Initiator Responder ------------------------------------------------------------------- HDR, SK {[N,] [D,] [CP,] [DCi,] ...} --> <-- HDR, SK {[N,] [D,] [CP,] CCr...} If delete connection is requested by Responder then Initiator MUST reply back CCi payload. Initiator Responder ------------------------------------------------------------------- <-- HDR, SK {[N,] [D,] [CP,] ACr...} HDR, SK {[N,] [D,] [CP,] [CCi,] ...} --> In case DCi is sent with invalid Connection ID information, then peer MUST discard the request and reply back with Confirmation payload. Suresh Expires February 02, 2017 [Page 12] Internet-Draft IKEv2 Multihoming support August 2016 1.7. The Confirm Connection payload Confirm Connection MUST be sent as response by peer for Add or Delete connection request. 1.8. KEY management across connections All connections of a single device MUST share IKE and CHILD SA KEYs. This would reduce KEY Exchange negotiations during initial tunnel establishment and during re-keying of IKE and CHILD SAs. Each peer is responsibile to choose a connection for future re-keying Exchanges. 1.9. Re-key mechanism across connections Re-keying responsibility (both IKE and Child SAs) MAY be requested during connection addition. ACi payload (ACr for Responder) provide a Flag to specify re-keyinging responsibility of the newly added connection. Latest added connection's re-keying configuration MUST be preferred over previously added connection(s). For example, if 3 connections are added; conn1, conn2 and conn3 (in same order). conn2 and conn3 request for re-keying responsibility, then conn3 MUST be considered as re-keying connection. Delete connection MUST indicate alternative connection for re-key responsibility in case the deleted connection was responsibile for re-keying. In case peer fails to provide a valid connection for re- keying responsibility in delete connection, then the connection MUST be terminated. 2. Multihoming header formats 2.1. Critical bit handling 0 1 2 3 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 8: Generic Payload Header Suresh Expires February 02, 2017 [Page 13] Internet-Draft IKEv2 Multihoming support August 2016 Critical bit define in Generic Payload Header MUST be set to zero for payload types defined in this document. The reasoning behind not setting the critical bit for payloads defined in this document is to ensure that implementations that do not understand the payload MAY ignore the payload. Skipped payloads are expected to have valid Next Payload and Payload Length fields as defined in Section 3.2 of [IKEv2]. 2.2. Exchange Types Exchange Types CREATE_CHILD_SA and INFORMATIONAL defined in [IKEv2] are used for connection addition, confirmation and deletion operation defined in this document. Connection addition MAY be requested as part of CREATE_CHILD_SA exchange type or INFORMATIONAL exchange type based on when the peer actually requests for connection addition as described in Section 1.3. Connection deletion MUST be requested only in INFORMATIONAL exchange as described in Section 1.4. Confirm Connection MUSt be sent as a reply for Add Connection and Delete Connection requests. 2.3. Payload Types Aci and Acr, CCi and CCr and Dci and DCr payload types are defined for connection addition, confirmation and deletion operation. Next Payload Type Notation Value ------------------------------------------------------ Add Connection - Initiator ACi 49 Add Connection - Responder ACr 50 Delete Connection - Initiator DCi 51 Delete Connection - Responder DCr 52 Confirm Connection - Initiator CCi 53 Confirm Connection - Responder CCr 54 (Payload type values 1-32 should not be assigned in the future so that there is no overlap with the code assignments for IKEv1 [IKE]. Payload type values 33-48 are dedicated for IKEv2 [IKEv2].) Suresh Expires February 02, 2017 [Page 14] Internet-Draft IKEv2 Multihoming support August 2016 2.4. Add Connection Payload The Add Connection Payload, denoted as ACi (and ACr) in this document is used to add a connection to a Security Association. There MUST be single Add connection payload for a single Exchange. There MAY be multiple connections within each Add connection payload. Each connection is differentiated through unique Connection ID, defined for a pair of MAC and IP address combination. Peer MUST discard multiple Add connection payloads sent within a single Exchange and reply back with INVALID_SYNTAX Notification sent as a response. 0 1 2 3 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 9: Add Connection Payload Peers not supporting this standard MUST only send this payload and peer not supporting MUST ignore the payload if received. 2.4.1. Add Connections substructure 0 1 2 3 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Last Connection| Flags | RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection ID | Connection Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MAC address | Address Type | Address Length| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ IP address ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: Add Connections substructure Suresh Expires February 02, 2017 [Page 15] Internet-Draft IKEv2 Multihoming support August 2016 o Last Connection (1 octet) - Indicates if that this substructure is the last in the list of connections. This field has a value of 0 if this was the last Connection Substructure, and a value of 1 if there are more Connection Substructures. o Flags (1 octet) - Indicates specific options that are set for the message. Presence of options is indicated by the appropriate bit in the flags field being set. The bits are as follows: +-+-+-+-+-+-+-+-+ |X|X|X|X|K|X|X|X| +-+-+-+-+-+-+-+-+ In the description below, a bit being 'set' means its value is '1', while 'cleared' means its value is '0'. 'X' bits MUST be cleared when sending and MUST be ignored on receipt. * K (Keying) - This bit indicates re-keying control. This bit MUST be set, if future IKE and CHILD SA re-keying would be initiated through this connection. o RESERVED (2 octets) - MUST be sent as zero; MUST be ignored on receipt. o Connection ID (2 octets, unsigned integer) - Unique identifier of a connection to identify the connection being added. Connection ID MUST start from '1' and grow increasely, '0' MUST be dedicated to the default connection on which IKE negotiation begins. o Connection Length (2 octets, unsigned integer) - Length of this Connection. o MAC Address (6 octets) - MAC address of the Connection. To provide added security for incoming/outgoing packet(s). o MAC Address (6 octets) - MAC address of the Connection. To provide added security for incoming/outgoing packet(s). o Address Type (1 octet) - Identifier for Type of address. Suresh Expires February 02, 2017 [Page 16] Internet-Draft IKEv2 Multihoming support August 2016 o Address Length (1 octet, unsigned integer) - Length in octets of Connection address. The values in table below define Address Type and Address Length. Address Type Value Address Length ------------------------------------------------------------ ADDRESS_TYPE_IP4 1 0 or 4 octets ADDRESS_TYPE_IP6 2 0 or 17 octets o IP Address (variable length, 0 - 17 octests) - IP address of Connection. 2.5. Delete Connection Payload The Delete Connection Payload, denoted as DEL_CONN in this document, is used to delete a connection from a Security Association. There MAY be multiple DEL_CONN payloads, one for each connection. Peer MUST discard the payload if multiple DEL_CONN is received for same connection. 0 1 2 3 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 11: Delete Connections Payload 2.5.1. Delete Connections substructure 0 1 2 3 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Last Connection| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection ID | Re-Key Connection ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 12: Delete Connections substructure Suresh Expires February 02, 2017 [Page 17] Internet-Draft IKEv2 Multihoming support August 2016 o Last Connection (1 octet) - Indicates if that this substructure is the last in the list of connections. This field has a value of 0 if this was the last Connection Substructure, and a value of 1 if there are more Connection Substructures. o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on receipt. o Connection ID (2 octets, unsigned integer) - Unique identifier of a connection to identify the connection being deleted. Connection ID '0' MUST delete the default connection on which IKE negotiation started. o Re-Key Connection ID (2 octets, unsigned integer) - In case the deleted Connection ID is responsible for re-key then re-Key Connection ID MUST provide a valid Connection ID to be considered for future re-keys; else this field MUST be set to 'zeros' and ignored. 2.6. Confirm Connection Payload 0 1 2 3 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Next Payload |C| RESERVED | Payload Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ~ ~ | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Confirm Connection Payload Suresh Expires February 02, 2017 [Page 18] Internet-Draft IKEv2 Multihoming support August 2016 2.6.1. Confirm Connections substructure 0 1 2 3 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 0 1 2.4.4 5 6 7 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Last Connection| RESERVED | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Connection ID | Confirm Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 14: Confirm Connections substructure o Last Connection (1 octet) - Indicates if that this substructure is the last in the list of connections. This field has a value of 0 if this was the last Connection Substructure, and a value of 1 if there are more Connection Substructures. o RESERVED (3 octets) - MUST be sent as zero; MUST be ignored on receipt. o Connection ID (2 octets, unsigned integer) - Confirmed connection ID; Connection ID MUST be greater than '1'. Confirm Connection Payload for Connection ID '0' MUST NOT be sent, peer needs to discard the payload with Connection ID '0'. o Confirm Status (2 octets) - Confirmation status for the Connection ID. Peer not supporting this The values in table below define Confirm Status. Confirm Status Value -------------------------------------- ADD_CONFIRM_SUCCESS 1 DELETE_CONFIRM_SUCCESS 2 ADD_CONFIRM_FAIL 3 DELETE_CONFIRM_FAIL 4 In case of ADD_CONFIRM_FAIL, request Initiator MUST NOT retry to add the connection again within the lifetime of present tunnel. In case of DELETE_CONFIRM_FAIL, request Initiator MUST retry again before clearly resoruces. Suresh Expires February 02, 2017 [Page 19] Internet-Draft IKEv2 Multihoming support August 2016 3. Keep-alive and dead peer detection Monitoring and signalling of Keep-Alive MUST be through restricted to single connection with re-keying responsibility. Dead-Peer-Detection procedure MUST NOT be initiated when there is active data exchange at least on one of the connections. On detection of dead peer, all connections to specific destination MUST be terminated and resources cleared. Previously added connections for the specifc peer MUST NOT be considered during re- establishment of tunnel with the same peer. 4. Performance considerations This specification targets to improving UE performance by providing higher throughput and improved resilience to network failure(s). Increase in multihoming devices would require additional support at Security framework to enhance performance and reduce redundancy. 5. Security Considerations New payloads in present sepecificcation would be transacted within encrypted payload based on IKE keys hence intruders would not be aware of the new set of connections added and/or deleted. This would ensure that no tresspassing occurs through external intrussions. Also the specification considers utilizing common IKE and Child SAs for multiple connections from a single peer. This would avoid new Key creation per connection leading to possible security loop-holes; at the time it can also lead to loop-holes due to usage of same set of keys across multiple connections. But considering present state of art in cryptographic algorithms, this SHOULD NOT be a major bottleneck. Nevertheless, specification can be evolved to consider independant Child SAs per connection as well with minor changes. Suresh Expires February 02, 2017 [Page 20] Internet-Draft IKEv2 Multihoming support August 2016 6. IANA Considerations This document defines a new payload in the "IKEv2 Payload Types" registry: Multihoming support - Initiator Multihoming support - Initiator 49 Add Connection - Initiator 50 Add Connection - Responder 51 Delete Connection - Initiator 52 Delete Connection - Responder 53 Confirm Connection - Initiator 54 Confirm Connection - Responder 7. Conclusion This specification provides a solution to harness the advantages of multihoming capabilities of UE by providing higher throughput and improved resilience to network failure(s), while avoiding redundancy and reduced network over-head. This solution ensures that end-point and gateways benefit alike by utilizing their multihoming capability. Additionally, mobility with continuity across multi-domain is guaranteed for UE. Suresh Expires February 02, 2017 [Page 21] Internet-Draft IKEv2 Multihoming support August 2016 8. References 8.1. Normative References [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", RFC 2119, March 1997, . [IKEv2] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen, "Internet Key Exchange (IKEv2) Protocol", RFC 7296, October 2014. . 8.2. Informative References [IKE] D. Harkins, and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998, . [RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure, "TCP Extensions for Multipath Operation with Multiple Addresses", RFC 6824, January 2013, . Authors' Address N. Suresh Kumar Bangalore, Karnataka, India Email: suresh.n@samsung.com Suresh Expires February 02, 2017 [Page 22]