Internet DRAFT - draft-suresh-ipsecme-ikev2-multihoming-support
draft-suresh-ipsecme-ikev2-multihoming-support
Individual N. Suresh Kumar
Internet-Draft Samsung Electronics
Intended status: Standards Track February 06, 2016
Expires: August 05, 2016
IKEv2 Multihoming support
draft-suresh-ipsecme-ikev2-multihoming-support-00
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 August 3, 2016.
Copyright and License Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
Suresh Expires August 05, 2016 [Page 1]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 2]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 3]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 4]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 5]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 6]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 7]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 8]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 9]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 10]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 11]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 12]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 13]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 14]
Internet-Draft IKEv2 Multihoming support February 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Add Connections> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 August 05, 2016 [Page 15]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 16]
Internet-Draft IKEv2 Multihoming support February 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Delete Connections> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 August 05, 2016 [Page 17]
Internet-Draft IKEv2 Multihoming support February 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ <Confirm Connections> ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 13: Confirm Connection Payload
Suresh Expires August 05, 2016 [Page 18]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 19]
Internet-Draft IKEv2 Multihoming support February 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 August 05, 2016 [Page 20]
Internet-Draft IKEv2 Multihoming support February 2016
6. IANA Considerations
This document defines a new payload in the "IKEv2 Payload Types"
registry:
<TBA> Multihoming support - Initiator
<TBA> 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 August 05, 2016 [Page 21]
Internet-Draft IKEv2 Multihoming support February 2016
8. References
8.1. Normative References
[RFC2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, March 1997,
<http://www.rfc-editor.org/info/rfc2119>.
[IKEv2] C. Kaufman, P. Hoffman, Y. Nir, P. Eronen, and T. Kivinen,
"Internet Key Exchange (IKEv2) Protocol", RFC 7296,
October 2014.
<http://www.rfc-editor.org/info/rfc7296>.
8.2. Informative References
[IKE] D. Harkins, and D. Carrel, "The Internet Key Exchange (IKE)",
RFC 2409, November 1998,
<http://www.rfc-editor.org/info/rfc2409>.
[RFC6824] Ford, A., Raiciu, C., Handley, M., and O. Bonaventure,
"TCP Extensions for Multipath Operation with Multiple
Addresses", RFC 6824, January 2013,
<http://www.rfc-editor.org/info/rfc6824>.
Authors' Address
N. Suresh Kumar
Bangalore, Karnataka,
India
Email: suresh.n@samsung.com
Suresh Expires August 05, 2016 [Page 22]
