diff --git a/eesp-ikev2.org b/eesp-ikev2.org index b66243c..17c4b5d 100644 --- a/eesp-ikev2.org +++ b/eesp-ikev2.org @@ -13,7 +13,7 @@ #+RFC_XML_VERSION: 3 #+RFC_CONSENSUS: true -#+TITLE: IKEv2 negotiation for Enhanced Encapsulating +#+TITLE: IKEv2 negotiation for Enhanced Encapsulating Security Payload #+RFC_SHORT_TITLE: EESP IKEv2 negotiation #+AUTHOR: Steffen Klassert #+EMAIL: steffen.klassert@secunet.com @@ -46,7 +46,7 @@ Encapsulating Security Payload (ESP) defined in [RFC4303]. These improvements address evolving requirements in modern IPsec deployments. EESP offers increased flexibility for hardware offloads at the packet level. It supports carrying inner packet flow -identifiers used by ECMP, RSS hardware, and IPsec peers prior to +identifiers foe the use with ECMP, RSS hardware, and IPsec peers prior to decryption. EESP also enables the establishment of Sub Child SAs with independent sequence number spaces. Additionally, it supports the use of 64-bit sequence numbers in each packet or the omission of sequence @@ -104,7 +104,7 @@ This document uses the following terms defined in * EESP SA IKEv2 negotiation EESP IKEv2 is an extension to IKEv2 [[RFC7296]] to negotiate on EESP SA specified in [[I-D.klassert-ipsecme-eesp]]. -An EESP SA can be negotiated using IKEv2 either IKE_AUTH or +An EESP SA can be negotiated using IKEv2 either with the IKE_AUTH or CREATE_CHILD_SA new SA, exchange. IKEv2 Notify Message Status Type USE_WESP_MODE, [[RFC5840]], is not @@ -118,10 +118,10 @@ If this notification is received it MUST be discarded. ** Negotiating an EESP SA using IKE_AUTH or CREATE_CHILD_SA To negotiate an EESP Child SA, use the IKEv2 IKE_AUTH or -CREATE_CHILD_SA New SA exchange. The SA Payload, Poropsal -MUST have Security Protocol Identifier, Proto Id = EESP. - -which is specified in/ ~EESP~, as specified in this document, and uses the +CREATE_CHILD_SA new SA exchange. The SA Payload, Proposal +MUST have Security Protocol Identifier, Proto Id = EESP +which is specified in [[I-D.klassert-ipsecme-eesp]], +as specified in this document, and uses the EESP Transform attributes defined in [[EESP SA Transforms]]. ** Rekeying an EESP SA with the CREATE_CHILD_SA Exchange @@ -170,22 +170,25 @@ the original EESP SA. #+end_src ** Anti-Replay Service -EESP provides optional Anti-Replay protection using an -Extended Sequence Number (ESN) carried in the packet. +EESP provides an optional Anti-Replay service using a +64 bit Sequence Number, carried in the packet. To enable Anti-Replay service the initiator SHOULD propose SNP Transforms SNP = (1, Name 64 bit ESN) in Substructure of the Proposal Substructure inside the Security Association (SA) payload in the IKEv2 Exchange. When the responder select 64 bit -ESN a receiver MAY enable Antir-Reply. +ESN a receiver MUST enable Anti-Reply. +# NOTE STK: I'd say MUST above as we want to negotiate Anti-Replay service +# and not just the presense of the seq nr field. When the Transform Type [[IKEv2-SNP]] is not present in initiator's Child SA proposal during negotiation of an EESP Child SA, the Sequence Number field MUST NOT be transmitted in the EESP packet. -When SNP is not negotiated, i.e., when ESN is not carried in the +When SNP is not negotiated, i.e., when the 64 bit sequence number is +not carried in the EESP packet, an EESP receiver should not act on address or port changes. It should not initiate a dynamic address update without the -use of IKEv2 Mobility [[RFC4555]]. Since ARP is disabled, an attacker +use of IKEv2 Mobility [[RFC4555]]. Since the Anti-Replay service is disabled, an attacker could replay packets with a different source address. Otherwise, an attacker could disrupt the connection by capturing and replaying a single packet with different source address or port number. @@ -204,8 +207,8 @@ IIV transforms specified in [[IKEv2-Enc]] MUST be used. Additionally, [[Anti-Replay Service]] MUST be negotiated to carry a 64-bit ESN in the EESP packet. -** EESP Version: -Each SA need an EESB Base Header version which is specified +** EESP Version +Each SA need an EESP Base Header version which is specified [[I-D.klassert-ipsecme-eesp]]. ** EESP Flow Identifier @@ -213,7 +216,7 @@ Each SA need an EESB Base Header version which is specified EESP Flow Identifier (EESPFID) Options are used to carry characteristic information of the inner flow and SHOULD NOT change on per packet basis inside any inner flow to avoid packet reordering. -The Flow Identifier SHOULD be negotiated by when creating EESP SA. +The Flow Identifier SHOULD be negotiated when creating EESP SA. ** Sub SAs @@ -221,18 +224,21 @@ Advantages of Sub SAs compared Child SAs with different keys - Possiblity for unidirectional SA. Compared to [[RFC9611]] when per resource SA is brought up it is bidirectional. However, both SA MAY - not be in use. When using CREATE_CHILD_SA Unidirectional SAis not + not be in use. When using CREATE_CHILD_SA Unidirectional SAs not possible. - No extra setup time, a.k.a. zero round trip time to setup additional Sub SAs. Even though using IKE window size specified in [[RFC7296]] Section 2.3 would aliviate setup this would be quicker. +# Note STK: What do you mean by aliviate? - Creating Sub SA is more efficient while creating as well as rekeying and deleting, life cycle management of Sub SA is simple. There are two types of Sub SAs, ~Session ID as Replay Subspace ID~ specified in [[I-D.klassert-ipsecme-eesp]], and Sub SA Independent keys. +# I don't think there are two types, we always need to encode +# the Replay Subspace ID on the Session ID. To negotiate Session ID as Replay Subspace ID use transform Session ID, SUB_SA_SN. @@ -242,7 +248,7 @@ ID, SUB_SA_SN. [[RFC7296]] section 2.17 specifies Child SA key generation. When the EESP SA is negotiated with a Sub SA Keys (SUB_SA_K), each Sub SA need to derive its own unique key. This allows each Sub SA -it's of Sequence Number space or IV space when using AEAD counter +its own Sequence Number space, or IV space when using AEAD counter mode algorithm. This section specifies two methods for Sub SA key derivation. @@ -267,10 +273,10 @@ of this CREATE_CHILD_SA exchange (represented as an octet string in big endian order padded with zeros in the high-order bits if necessary to make it the length of the modulus). -For example for Sub SA ID n, use nth set of keys from the KEYMAT +For example for Sub SA ID n, use nth set of keys from the KEYMAT. The order is specified in Section 2.17 of [[RFC7296]]. -With existing prf+ function the keymat length rather limited. +With existing prf+ function the keymat length is rather limited. [[RFC7296]] limit the iteration to 256. However, with modern prf+, more specifically XOF, functions, such as KMAC specified in [[NIST800-185 ]], or HopMAC/TurboSHAKE @@ -288,11 +294,16 @@ about 9 Mega Bytes. An XOF differs from a traditional hash function in that it is designed generate very long, and variable length output. Unlike the IKEv2 prf+ an XOF can generate longer outputs directly -without iterative call. +without iterative call. Additionally to that, the KEYMAT +for the Sub SAs can be generated on the fly if available +memory is limited. This is usually the case if such an algorithm is +implemented in hardware. **** Hierarchical key derivation KEYMAT = prf+(SK_child, FLOWID) +# Note STK: We encodes the Subspace ID on the Session ID, +# so I think that's the needed input here. Where SK_child is the key derived for the Child SA as specified in [[RFC7296]] section 2.17 @@ -324,7 +335,8 @@ INVALID_SESSION_ID error message, indicating a supported value. * UDP Encapsulation for EESP - +# Note STK: With the Verion in front, we likely need +# a new port number. UDP encapsulation is similar to ESP UDP encapsulation, specified in [[RFC3948]], with one difference on source port. The EESP @@ -339,7 +351,8 @@ This option is typically used for within one Datacenter use case such as [[PSP]]. To negotiate, the initiator sends USE_CRYPTOFFSET together with USE_TRANSPORT_MODE and the responder respond with the same. USE_EESP_CRYPTOFFSET is not supported in Tunnel mode or BEET mode. - +# Note STK: This needs discussion +# ~NOTE~ Add EESP draft section reference. * IANA Considerations