idnits 2.17.1 draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2014) is 3699 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'SA' is mentioned on line 212, but not defined -- Looks like a reference, but probably isn't: '1' on line 403 -- Looks like a reference, but probably isn't: '2' on line 409 ** Obsolete normative reference: RFC 5996 (Obsoleted by RFC 7296) Summary: 1 error (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPSECME D. Palomares (Ed) 3 Internet-Draft D. Migault (Ed) 4 Intended status: Informational Orange 5 Expires: September 6, 2014 March 5, 2014 7 IKEv2/IPsec Context Definition 8 draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01 10 Abstract 12 IKEv2/IPsec clusters are constituted of multiple nodes accessed via a 13 single address by the end user. The traffic is then split between 14 the nodes via specific IP load balancing policies. Once a session is 15 assigned to a given node, IPsec makes it difficult to assign the 16 session to another node. This makes management operations and 17 transparent high availability for end users difficult to perform 18 within the cluster. 20 This document describes the IKEv2 and IPsec contexts that MUST be 21 transferred between nodes within a cluster so a session can be 22 restored. This makes possible to transfer an IPsec session between 23 different nodes. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on September 6, 2014. 42 Copyright Notice 44 Copyright (c) 2014 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 2 60 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 61 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 4. Parameters level definition . . . . . . . . . . . . . . . . . 3 63 5. IKEv2 key management . . . . . . . . . . . . . . . . . . . . 4 64 6. IKEv2 Session parameters . . . . . . . . . . . . . . . . . . 5 65 6.1. MANDATORY - IKEv2 Session parameters . . . . . . . . . . 5 66 6.2. OPTIONAL - IKEv2 Session parameters . . . . . . . . . . . 5 67 6.3. VENDOR SPECIFIC - IKEv2 Session parameters . . . . . . . 5 68 7. IPsec Session parameters . . . . . . . . . . . . . . . . . . 6 69 7.1. MANDATORY - IPsec Session parameters . . . . . . . . . . 6 70 7.2. OPTIONAL - IPsec Session parameters . . . . . . . . . . . 6 71 7.3. VENDOR SPECIFIC - IPsec Session parameters . . . . . . . 7 72 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 73 9. Security Considerations . . . . . . . . . . . . . . . . . . . 7 74 10. Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . 7 75 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 76 11.1. Normative References . . . . . . . . . . . . . . . . . . 7 77 11.2. Informative References . . . . . . . . . . . . . . . . . 7 78 Appendix A. ANNEX A: Data structure example . . . . . . . . . . 8 79 Appendix B. Document Change Log . . . . . . . . . . . . . . . . 9 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 82 1. Requirements notation 84 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 85 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 86 document are to be interpreted as described in [RFC2119]. 88 2. Introduction 90 Large clusters may take advantage of the multiple nodes to enhance 91 the peer's Quality of Service by performing among others: 93 1) Fail-over with high availability. 95 2) Load balancing among cluster members. 97 3) Scalability for overloaded IPsec platforms. 99 4) Compatibility for IKEv2/IPsec context transfers among different 100 constructors. 102 This document addresses transfer of an IPsec session between 103 physically or virtually different nodes within an IKEv2/IPsec 104 cluster. More specifically, the document describes the parameters 105 that MUST be transmitted between the IPsec/IKEv2 nodes, so that IKEv2 106 and IPsec session can be restored on the other node. 108 Currently IPsec based services can hardly benefit from these features 109 as IPsec Security Associations are bound to a single node and cannot 110 be shared among different cluster members. 112 This draft describes the parameters that MUST be transferred in order 113 to keep an IKEv2/IPsec session alive in conformance with the Security 114 Architecture for the Internet Protocol [RFC4301] and the Internet Key 115 Exchange (IKEv2) Protocol [RFC5996]. 117 This includes information such as the cryptographic material, the 118 algorithms and the IP addresses, among others parameters. 120 Note that IKEv2 and IPsec session do not need to be on the same node 121 as IKEv2 and IPsec context are different. Note also that we do not 122 specify in this document how the IKEv2 or IPsec context are 123 transferred between one node to the other. This can be performed via 124 a simple UDP session that MAY be IPsec protected, a SCP session 125 [RFC4251] or using the context transfer protocol [RFC4067]. 127 3. Terminology 129 This document uses the following terminology: 131 IKE_SA context: the set of parameters composing a single IKE Security 132 Association. A bidirectional communication will need a pair of 133 IKE_SAs, for incoming and outgoing IKE exchanges. 135 IPsec_SA Context: the set of parameters composing a single IPsec 136 Security Association. A bidirectional communication will need a pair 137 of IPsec_SAs for incoming and outgoing traffic. 139 4. Parameters level definition 141 Information related to the IKEv2 and IPsec contexts can be defined 142 within three different levels: mandatory, optional or vendor 143 specific. This allows classification of the parameters considering 144 their relevance and susceptibility to be transferred in order to 145 maintain an IKEv2/IPsec session alive. 147 1) Mandatory (M): Those parameters identified with a Mandatory flag 148 (M) are considered absolutely relevant and necessary in order to 149 maintain an IKE_SA or an IPsec_SA alive. The absence of a 150 parameter with a mandatory flag, results in the loss of the IKE_SA 151 or IPsec_SA. 153 2) Optional (O): Those parameters identified with an optional flag 154 (O) are considered as additional information but are NOT 155 absolutely necessary to maintain an IKEv2/IPsec session alive. 157 3) Vendor Specific (V): Those parameters identified with a vendor's 158 specific flag (V) are considered as the information related to 159 some specific constructor. It ensures enhancement provided by 160 certain proprietary solutions when transmitting IKEv2/IPsec 161 contexts, however, this MUST NOT interfere the interoperability 162 with other IKEv2 and IPsec implementations and standards. 164 5. IKEv2 key management 166 Implementations might decide to manage sending cryptographic material 167 (a.k.a. IKEv2/IPsec session keys) in different fashions; especially 168 IKEv2 session keys. This document specifies three different ways to 169 exchange IKEv2 keying information as follows: 171 1) Case 1: The node sends the private Diffie-Hellman key, the peer's 172 KE content and nonces. In this case, the node receiving these 173 information will recalculate all keys from the very beginning as 174 it usually does during any initial IKEv2 exchange. The main 175 drawback for this case is that recalculating keys is computational 176 expensive, especially if thousands of session keys has to be 177 calculated (e.g. during rush hours). 179 2) Case 2: A cluster member sends the SKEYSEED and nonces. In such 180 case, the node receiving the information might not recalculate all 181 the keys since the very beginning, but it still has to compute 182 SK_* (SK_d, SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr). 184 3) Case : The cluster member sends all computed keys (SK_* = SK_d, 185 SK_ai, SK_ar, SK_ei, SK_er, SK_pi, SK_pr). In this case, the node 186 receiving the keys wont need to recalculate keys from the 187 beginning. However, this case demands more data to be sent 188 between cluster members. Note that sending SK_pi/SK_pr may be 189 omitted, as these keys are only used during authentication. 191 6. IKEv2 Session parameters 193 Considering IKEv2/IPsec sessions as bidirectional, we provide a list 194 of parameters needed to create the IKE_SAs, which are usually stored 195 in the user-land. 197 6.1. MANDATORY - IKEv2 Session parameters 199 1) Version of IKE: in this draft we only consider version 2. 201 2) The initiator flag and the responder flag for the IKE_SAs. 203 3) Local host address and remote host address (IPv4 or IPv6). 205 4) The IKE_SA's SPI of both initiator and responder. 207 5) The outgoing and incoming Message ID's. 209 7) The cryptographic material for the IKE_SA (see section Section 5 210 for details). 212 8) The [SA] proposal information: encryption algorithm, length of the 213 encryption key, integrity algorithm, length of the integrity key 214 and the pseudo random function (prf). 216 9) The extensions and condition of the IKE_SA (NAT, EAP, MOBIKE...). 218 10) The IDs of the initiator and responder (ID_IPV4_ADDR, 219 ID_IPV6_ADDR, ID_FQDN, ID_RFC822_ADDR, ID_DER_ASN1_DN, 220 ID_DER_ASN1_GN or ID_KEY_ID). 222 11) Credentials: pre-shared keys or digital certificates. 224 12) The windows bitmap value. 226 6.2. OPTIONAL - IKEv2 Session parameters 228 1) The IKE lifetime. 230 2) Vendors ID: when a vendors ID payload has been sent during IKE_SA 231 negotiation, it is part of the IKE_SA parameters. 233 6.3. VENDOR SPECIFIC - IKEv2 Session parameters 235 For now, there are no vendor specific parameters for IKEv2. 237 7. IPsec Session parameters 239 Once the IKE_SAs are established for securing further IKEv2 240 exchanges, a pair of IPsec_SAs are negotiated in order to secure the 241 traffic flow. The following list includes the parameters needed to 242 build an IPsec_SA: 244 7.1. MANDATORY - IPsec Session parameters 246 1) Local host and remote host addresses (IPv4 or IPv6). 248 2) The inbound and outbound IPsec_SA Security Parameter Indexes 249 (SPIs). 251 3) The IP compression information: flag for IPcomp. If active, The 252 IPcomp Compression Parameter Index values (CPI IN, CPI OUT) and 253 the the IPcomp algorithm. 255 4) The sequence number values: SN counter and SN overflow flag 257 5) The anti-replay window value. 259 6) IPsec mode: transport or tunnel mode. 261 7) The SA Lifetime: a time interval or byte count after which an SA 262 must be replaced with a new SA (and new SPI). 264 8) Path MTU: maximum size of an IPsec packet that can be transmitted 265 without fragmentation. 267 9) Upperspec: upper-layer protocol to be used. 269 10) Source IP/Destination IP addresses and ports of the protected 270 traffic. 272 11) The IPsec protocol ESP and/or AH, their encryption/integrity 273 algorithms and the key lengths. 275 12) The cryptograhic material: KEYMAT (encryption and/or 276 authentication keys). 278 7.2. OPTIONAL - IPsec Session parameters 280 For now, there are no optional parameters for IPsec sessions. 282 7.3. VENDOR SPECIFIC - IPsec Session parameters 284 1) Instance-id or flow-id: helps a node to identify which packet 285 processing unit will process some IPsec traffic or which IPsec 286 instance out of multiple IPsec processing units will process the 287 IPsec traffic. 289 8. IANA Considerations 291 There are no IANA consideration for this document. 293 9. Security Considerations 295 Transferring an IPsec context between different SG involves sending 296 sensitive information through the network. These pieces of 297 information MUST be sent to an authenticated node via a secure 298 channel. 300 10. Acknowledgment 302 IPsec cluster management is a joint work between Orange, Universite 303 Pierre et Marie Curie / LIP6 and Institut Telecom / Telcom SudParis. 305 We would like to thank Maryline Laurent and Tobias Guggemos for their 306 advises. 308 11. References 310 11.1. Normative References 312 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 313 Requirement Levels", BCP 14, RFC 2119, March 1997. 315 [RFC4251] Ylonen, T. and C. Lonvick, "The Secure Shell (SSH) 316 Protocol Architecture", RFC 4251, January 2006. 318 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the 319 Internet Protocol", RFC 4301, December 2005. 321 [RFC5996] Kaufman, C., Hoffman, P., Nir, Y., and P. Eronen, 322 "Internet Key Exchange Protocol Version 2 (IKEv2)", RFC 323 5996, September 2010. 325 11.2. Informative References 327 [RFC4067] Loughney, J., Nakhjiri, M., Perkins, C., and R. Koodli, 328 "Context Transfer Protocol (CXTP)", RFC 4067, July 2005. 330 11.3. URIs 332 [1] http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2 333 -context-definition-01 335 [2] http://tools.ietf.org/html/draft-plmrs-ipsecme-ipsec-ikev2 336 -context-definition-00 338 Appendix A. ANNEX A: Data structure example 340 Example of an IKEv2 data structure: 342 typedef struct _IKEV2CONTEXT 343 { 344 bool *initiator; 345 u_int32_t *ike_spi_i; 346 u_int32_t *ike_spi_r; 347 char *my_host; 348 char *other_host; 349 u_int16_t *enc_alg_ike; 350 u_int16_t *enc_alg_ike_len; 351 u_int16_t *int_alg_ike; 352 u_int16_t *prf_alg; 353 char *nonce_i; 354 char *nonce_r; 355 char *dh_secret; 356 u_int16_t message_id; 357 char *cert; 358 } IKEV2CONTEXT; 360 Example of an IPsec session data structure: 362 typedef struct _IPSECCONTEXT 363 { 364 bool initiator; 365 char *my_host; 366 char *other_host; 367 u_int8_t ipsec_mode; 368 u_int16_t encr_alg_child; 369 u_int16_t enc_alg_len_child; 370 u_int16_t int_alg_child; 371 u_int32_t enc_key_i; 372 u_int32_t int_key_i; 373 u_int32_t enc_key_o; 374 u_int32_t int_key_o; 375 char *child_seq_i; 376 char *child_bit_i; 377 char *child_seq_o; 378 char *child_bit_o; 379 char *child_spi_i; 380 char *child_spi_o; 381 u_int16_t ts_l_fromport; 382 u_int16_t ts_l_toport; 383 u_int8_t ts_l_type; 384 u_int8_t ts_l_proto; 385 char *ts_l_fromaddress; 386 char *ts_l_toaddress; 387 u_int16_t ts_r_fromport; 388 u_int16_t ts_r_toport; 389 u_int8_t ts_r_type; 390 u_int8_t ts_r_proto; 391 char *ts_r_fromaddress; 392 char *ts_r_toaddress; 393 bool ipcomp_flag; 394 u_int32_t ipcom_algo; 395 char *ipcomp_cpi_i; 396 char *ipcomp_cpi_o; 397 } IPSECCONTEXT; 399 Appendix B. Document Change Log 401 [RFC Editor: This section is to be removed before publication] 403 draft-plmrs-ipsecme-ipsec-ikev2-context-definition-01 [1] 404 Added missing information as part of the IPsec and IKEv2 contexts 405 Worked on the text 406 Include mandatory, optional and vendor specific flags 407 Added three different ways send keys session keys 409 draft-plmrs-ipsecme-ipsec-ikev2-context-definition-00 [2] 410 initial draft. 412 Authors' Addresses 414 Daniel Palomares 415 Orange 416 38 rue du General Leclerc 417 92794 Issy-les-Moulineaux Cedex 9 418 France 420 Phone: +33 1 45 29 51 16 421 Email: danielpalomares.ietf@gmail.com 423 Daniel Migault 424 Orange 425 38 rue du General Leclerc 426 92794 Issy-les-Moulineaux Cedex 9 427 France 429 Phone: +33 1 45 29 60 52 430 Email: daniel.migault@orange.com