IPSECME | D. Palomares (Ed) |
Internet-Draft | D. Migault (Ed) |
Intended status: Standards Track | Orange |
Expires: August 16, 2014 | February 12, 2014 |
IKEv2/IPsec Context Definition
draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00
IPsec/IKEv2 cluster are constituted of multiple nodes accessed via a single address by the end user. The traffic is then split between the nodes via specific IP load balancing policies. Once a session is assigned to a given node, IPsec makes it difficult to assign the session to another node. This makes management operations and transparent high availability for end users, difficult to perform within the cluster.
This document describes the contexts for IKEv2 and IPsec that MUST be transfered between two nodes so a session can be restored. This makes possible to tranfer an IPsec session transparently to the end user.
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 16, 2014.
Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved.
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.
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 [RFC2119].
Large clusters may take advantage of the multiple nodes to enhance the peer's Quality of Service by performing among others:
This document addresses transfer of an IPsec session between physically or virtually different nodes within an IKEv2/IPsec cluster. More specifically, the document describes the parameters that SHOULD be transmitted between the IPsec/IKEv2 nodes, so that IKEv2 and IPsec session can be restored on the other node.
Currently IPsec based services can hardly benefit from these features as IPsec Security Associations are bound to a single node and cannot be shared among different cluster members.
This draft describes the parameters that MUST be transferred in order to keep an IKEv2/IPsec session alive in conformance with the Security Architecture for the Internet Protocol [RFC4301] and the Internet Key Exchange (IKEv2) Protocol [RFC5996].
This includes information such as the cryptographic material, the algorithms and the IP addresses, among others parameters.
Note that IKEv2 and IPsec session do not need to be on the same node as IKEv2 and IPsec context are different. Note also that we do not specify in this document how the IKEv2 or IPsec context are transferred between one node to the other. This can be performed via a simple UDP session that MAY be IPsec protected, a SCP session [RFC4251] or using the context transfer protocol [RFC4067].
This document uses the following terminology:
IKE_SA context: the set of parameters composing a single IKE Security Association. A bidirectional communication will need a pair of IKE_SAs, for incoming and outgoing IKE exchanges.
IPsec_SA Context: the set of parameters composing a single IPsec Security Association. A bidirectional communication will need a pair of IPsec_SAs for incoming and outgoing traffic.
ESP: acronym for Encapsulation Security Payload. This header is part of the IPsec Security Architecture to provide origin authenticity, integrity and confidentiality protection of packets.
Considering IKEv2/IPsec sessions as bidirectional, we provide a list of parameters needed to create the IKE_SAs, which are usually stored in the user-land:
Once the IKE_SAs are established for securing further IKEv2 exchanges, a pair of IPsec_SAs are negotiated in order to secure the traffic flow between nodes. The parameters of an IPsec_SA are usually stored within the kernel-land and user-land. The following is a list of the parameters needed to build an IPsec_SA:
There are no IANA consideration for this document.
Transferring an IPsec context between different SG involves sending sensitive information through the network. These pieces of information MUST be sent to an authenticated node via a secure channel.
IPsec cluster management is a joint work between Orange, Universite Pierre et Marie Curie / LIP6 and Institut Telecom / Telcom SudParis.
We would like to thank Maryline Laurent and Tobias Guggemos for their advises.
[RFC2119] | Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. |
[RFC4251] | Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) Protocol Architecture", RFC 4251, January 2006. |
[RFC4301] | Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005. |
[RFC5996] | Kaufman, C., Hoffman, P., Nir, Y. and P. Eronen, "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 5996, September 2010. |
[RFC4067] | Loughney, J., Nakhjiri, M., Perkins, C. and R. Koodli, "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. |
Example of an IKEv2 data structure:
typedef struct _IKEV2CONTEXT { bool *initiator; u_int32_t *ike_spi_i; u_int32_t *ike_spi_r; char *my_host; char *other_host; u_int16_t *enc_alg_ike; u_int16_t *enc_alg_ike_len; u_int16_t *int_alg_ike; u_int16_t *prf_alg; char *nonce_i; char *nonce_r; char *dh_secret } IKEV2CONTEXT;
Example of an IPsec session data structure:
typedef struct _IPSECCONTEXT { bool *initiator; char *my_host; char *other_host; u_int8_t ipsec_mode; u_int16_t *encr_alg_child; u_int16_t *enc_alg_len_child; u_int16_t *int_alg_child; u_int32_t *enc_key_i; u_int32_t *int_key_i; u_int32_t *enc_key_o; u_int32_t *int_key_o; char *child_seq_i; char *child_bit_i; char *child_seq_o; char *child_bit_o; char *child_spi_i; char *child_spi_o; u_int16_t *ts_l_fromport; u_int16_t *ts_l_toport; u_int8_t *ts_l_type; u_int8_t *ts_l_proto; char *ts_l_fromaddress; char *ts_l_toaddress; u_int16_t *ts_r_fromport; u_int16_t *ts_r_toport; u_int8_t *ts_r_type; u_int8_t *ts_r_proto; char *ts_r_fromaddress; char *ts_r_toaddress; } IPSECCONTEXT;
[RFC Editor: This section is to be removed before publication]
-00: First version published.