<?xml version="1.0" encoding="US-ASCII"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc linefile="1:/tmp/CGI11956.1"?>
<?rfc toc="yes"?>
<!-- generate a table of contents -->
<?rfc symrefs="yes"?>
<!-- use anchors instead of numbers for references -->
<?rfc sortrefs="yes" ?>
<!-- alphabetize the references -->
<?rfc compact="yes" ?>
<!-- conserve vertical whitespace -->
<?rfc subcompact="no" ?>
<!-- but keep a blank line between list items -->

<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc4067 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4067.xml">
<!ENTITY rfc4251 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4251.xml">
<!ENTITY rfc4301 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4301.xml">
<!ENTITY rfc5996 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5996.xml">
]>

<rfc category="info"
     docName="draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01"
     ipr="trust200902">
  <front>
    <title abbrev="IKEv2 and IPsec Context Definition">IKEv2/IPsec Context Definition</title>
    <author fullname="Daniel Palomares" initials="D." surname="Palomares (Ed)">
      <organization>Orange</organization>
      <address>
        <postal>
          <street>38 rue du General Leclerc</street>
          <city>92794 Issy-les-Moulineaux Cedex 9</city>
          <country>France</country>
        </postal>
        <phone>+33 1 45 29 51 16</phone>
        <email>danielpalomares.ietf@gmail.com</email>
      </address>
    </author>

    <author fullname="Daniel Migault" initials="D." surname="Migault (Ed)">
      <organization>Orange</organization>
      <address>
        <postal>
          <street>38 rue du General Leclerc</street>
          <city>92794 Issy-les-Moulineaux Cedex 9</city>
          <country>France</country>
        </postal>
        <phone>+33 1 45 29 60 52</phone>
        <facsimile/>
        <email>daniel.migault@orange.com</email>
        <uri/>
      </address>
    </author>

    <!--
    <date month="December" year="2013"/>-->
    <date/>
    <area>INTERNET</area>

    <workgroup>IPSECME</workgroup>
   
    <abstract>
    <t>IKEv2/IPsec clusters 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.</t>
    <t>This document describes the IKEv2 and IPsec contexts that MUST be transferred between nodes within a cluster so a session can be restored. This makes possible to transfer an IPsec session between different nodes.</t>
    </abstract>
 
  </front>

  <middle>
    <section title="Requirements notation">
    <t>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 <xref target="RFC2119"/>.</t>
    </section>
    
    <section title="Introduction">
    <t>Large clusters may take advantage of the multiple nodes to enhance the peer's Quality of Service by performing among others:</t>
    <t>
    <list hangIndent="3" style="hanging">
        <t hangText="1)">Fail-over with high availability.</t>
        <t hangText="2)">Load balancing among cluster members.</t>
        <t hangText="3)">Scalability for overloaded IPsec platforms.</t>
        <t hangText="4)">Compatibility for IKEv2/IPsec context transfers among different constructors.</t>
    </list>
    </t>

    <t>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 MUST be transmitted between the IPsec/IKEv2 nodes, so that IKEv2 and IPsec session can be restored on the other node.</t>

    <t>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.</t>

    <t>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 <xref target="RFC4301"/> and the Internet Key Exchange (IKEv2) Protocol <xref target="RFC5996"/>.</t>

    <t>This includes information such as the cryptographic material, the algorithms and the IP addresses, among others parameters. </t>                       

    <t>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 <xref target="RFC4251"/> or using the context transfer protocol <xref target="RFC4067"/>.</t>
    </section>

    <section title="Terminology">
    <t>This document uses the following terminology:</t>
    <t>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.</t>
    <t>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. </t>
    </section>
    
    <section title="Parameters level definition">
    <t>Information related to the IKEv2 and IPsec contexts can be defined within three different levels: mandatory, optional or vendor specific. This allows classification of the parameters considering their relevance and susceptibility to be transferred in order to maintain an IKEv2/IPsec session alive.</t>
    
    <t>
    <list hangIndent="3" style="hanging">
        <t hangText="1) Mandatory (M):">Those parameters identified with a Mandatory flag (M) are considered absolutely relevant and necessary in order to maintain an IKE_SA or an IPsec_SA alive. The absence of a parameter with a mandatory flag, results in the loss of the IKE_SA or IPsec_SA.</t>
        <t hangText="2) Optional (O):">Those parameters identified with an optional flag (O) are considered as additional information but are NOT absolutely necessary to maintain an IKEv2/IPsec session alive.</t>
        <t hangText="3) Vendor Specific (V):">Those parameters identified with a vendor's specific flag (V) are considered as the information related to some specific constructor. It ensures enhancement provided by certain proprietary solutions when transmitting IKEv2/IPsec contexts, however, this MUST NOT interfere the interoperability with other IKEv2 and IPsec implementations and standards.</t>
    </list>
    </t>
    </section>
    
    <section anchor="sec:keys-management" title="IKEv2 key management">
        <t>Implementations might decide to manage sending cryptographic material (a.k.a. IKEv2/IPsec session keys) in different fashions; especially IKEv2 session keys. This document specifies three different ways to exchange IKEv2 keying information as follows:</t>
                <t>   
                <list hangIndent="3" style="hanging">
                   <t hangText="1) Case 1:"> The node sends the private Diffie-Hellman key, the peer's KE content and nonces. In this case, the node receiving these information will recalculate all keys from the very beginning as it usually does during any initial IKEv2 exchange. The main drawback for this case is that recalculating keys is computational expensive, especially if thousands of session keys has to be calculated (e.g. during rush hours).</t>
                   <t hangText="2) Case 2:"> A cluster member sends the SKEYSEED and nonces. In such case, the node receiving the information might not recalculate all the keys since the very beginning, but it still has to compute SK_* (SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr).</t>
                   <t hangText="3) Case :"> The cluster member sends all computed keys (SK_* = SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr). In this case, the node receiving the keys wont need to recalculate keys from the beginning. However, this case demands more data to be sent between cluster members. Note that sending SK_pi/SK_pr may be omitted, as these keys are only used during authentication.</t>
                </list>
                </t>
    </section>
    
    <section title="IKEv2 Session parameters">
    <t>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. </t>
    
        <section title="MANDATORY - IKEv2 Session parameters">
        <t>   
    <list hangIndent="3" style="hanging">
        <t hangText="1)">Version of IKE: in this draft we only consider version 2.</t>
        <t hangText="2)">The initiator flag and the responder flag for the IKE_SAs.</t>
        <t hangText="3)">Local host address and remote host address (IPv4 or IPv6).</t>  
        <t hangText="4)">The IKE_SA's SPI of both initiator and responder.</t>
        <t hangText="5)">The outgoing and incoming Message ID's.</t> 
        <t hangText="7)">The cryptographic material for the IKE_SA (see section <xref target="sec:keys-management"/> for details).</t>
        <t hangText="8)">The [SA] proposal information: encryption algorithm, length of the encryption key, integrity algorithm, length of the integrity key and the pseudo random function (prf).</t>
        <t hangText="9)">The extensions and condition of the IKE_SA (NAT, EAP, MOBIKE...).</t>
        <t hangText="10)">The IDs of the initiator and responder (ID_IPV4_ADDR, ID_IPV6_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_DER_ASN1_DN, ID_DER_ASN1_GN or ID_KEY_ID).</t>
        <t hangText="11)">Credentials: pre-shared keys or digital certificates.</t>
        <t hangText="12)">The windows bitmap value.</t>
    </list>
        </t>
        </section>
        
        <section title="OPTIONAL - IKEv2 Session parameters">
        <t>   
        <list hangIndent="3" style="hanging">
        <t hangText="1)">The IKE lifetime.</t>
        <t hangText="2)">Vendors ID: when a vendors ID payload has been sent during IKE_SA negotiation, it is part of the IKE_SA parameters.</t>
        </list>
        </t>
        </section>
        
        <section title="VENDOR SPECIFIC - IKEv2 Session parameters">
            <t>For now, there are no vendor specific parameters for IKEv2.</t>
        </section>
        
    </section>
    
    <section title="IPsec Session parameters">

    <t>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. The following list includes the parameters needed to build an IPsec_SA:</t>
    
            <section title="MANDATORY - IPsec Session parameters">
            <t>
            <list hangIndent="3" style="hanging">
        <t hangText="1)">Local host and remote host addresses (IPv4 or IPv6).</t>
        <t hangText="2)">The inbound and outbound IPsec_SA Security Parameter Indexes (SPIs).</t>
        <t hangText="3)">The IP compression information: flag for IPcomp. If active, The IPcomp Compression Parameter Index values (CPI IN, CPI OUT) and the the IPcomp algorithm.</t>
        <t hangText="4)">The sequence number values: SN counter and SN overflow flag</t>
        <t hangText="5)">The anti-replay window value.</t>  
        <t hangText="6)">IPsec mode: transport or tunnel mode.</t>
        <t hangText="7)">The SA Lifetime: a time interval or byte count after which an SA must be replaced with a new SA (and new SPI).</t>
        <t hangText="8)">Path MTU: maximum size of an IPsec packet that can be transmitted without fragmentation.</t>
        <t hangText="9)">Upperspec: upper-layer protocol to be used.</t>
        <t hangText="10)">Source IP/Destination IP addresses and ports of the protected traffic.</t>
        <t hangText="11)">The IPsec protocol ESP and/or AH, their encryption/integrity algorithms and the key lengths.</t>
        <t hangText="12)">The cryptograhic material: KEYMAT (encryption and/or authentication keys).</t>    
            </list>
            </t>
            </section>
            
            <section title="OPTIONAL - IPsec Session parameters">
            <t>For now, there are no optional parameters for IPsec sessions.</t>
            </section>
            
            <section title="VENDOR SPECIFIC - IPsec Session parameters">
            <t>
            <list hangIndent="3" style="hanging">
        <t hangText="1)">Instance-id or flow-id: helps a node to identify which packet processing unit will process some IPsec traffic or which IPsec instance out of multiple IPsec processing units will process the IPsec traffic.</t>  
            </list>
            </t>            
            </section>
    
    
    </section>
    
    <section title="IANA Considerations">
    <t> There are no IANA consideration for this document.</t>
    </section>
    
    <section title="Security Considerations">
    <t>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.</t> 
    </section>

    <section title="Acknowledgment">
    <t>IPsec cluster management is a joint work between Orange, Universite Pierre et Marie Curie / LIP6 and Institut Telecom / Telcom SudParis.</t>
    <t>We would like to thank Maryline Laurent and Tobias Guggemos for their advises.</t> 
    </section>
  </middle>

  <back>
    <references title="Normative References">
        &rfc2119; <!--Key words for use in RFCs to Indicate Requirement Levels-->
        &rfc4251; <!--The Secure Shell (SSH) Protocol Architecture-->
        &rfc4301; <!--Security Architecture for the Internet Protocol-->
        &rfc5996; <!--Internet Key Exchange Protocol Version 2 (IKEv2)-->
    </references>
    <references title="Informative References">
        &rfc4067; <!--Context Transfer Protocol (CXTP)-->        
    </references>

<section title="ANNEX A: Data structure example"> 
      
    <t>Example of an IKEv2 data structure:</t>
    <figure>
        <artwork><![CDATA[
  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;
                 u_int16_t message_id;
                 char *cert;
        } IKEV2CONTEXT;
        ]]></artwork>
      </figure>
      
      
    <t>Example of an IPsec session data structure:</t>
    <figure>
        <artwork><![CDATA[
  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;
                 bool ipcomp_flag;
                 u_int32_t ipcom_algo;
                 char *ipcomp_cpi_i;
                 char *ipcomp_cpi_o;
        } IPSECCONTEXT;
        ]]></artwork>
      </figure>
    </section>

    <section title="Document Change Log">
      <t>[RFC Editor: This section is to be removed before publication]</t>
      
          <t><eref target="http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01">draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01</eref><vspace blankLines="0" />
          Added missing information as part of the IPsec and IKEv2 contexts<vspace blankLines="0" />
          Worked on the text<vspace blankLines="0" />
          Include mandatory, optional and vendor specific flags<vspace blankLines="0" />
          Added three different ways send keys session keys</t>
    
          <t><eref target="http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00">draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00</eref><vspace blankLines="0" />
              initial draft.</t>
          
    </section>
  </back>
</rfc>
