Some adjustments and fixes.

Author: klassert

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: [email protected]
@@ -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,35 +207,38 @@ 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
 
 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
 
 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