Skip to content

Some adjustments and fixes. #1

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
antonyantony merged 1 commit into from
Dec 16, 2024
Merged

Some adjustments and fixes. #1

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
57 changes: 35 additions & 22 deletions eesp-ikev2.org
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -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]
Expand Down Expand Up @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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.
Expand All @@ -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.
Expand All @@ -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.
Expand All @@ -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
Expand All @@ -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
Expand Down Expand Up @@ -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
Expand All @@ -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
Expand Down
Loading