Skip to content

Clarify enabling replay protection and add notify for maximum crypt offset #14

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 2 commits into from
Aug 22, 2025
Merged

Clarify enabling replay protection and add notify for maximum crypt offset #14

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
3bd3cb6
Make replay protection mandatory if SNs are negotiated
tobiasbrunner Aug 5, 2025
59288a4
Add notification to announce the maximum Crypt Offset
tobiasbrunner Aug 5, 2025
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
125 changes: 79 additions & 46 deletions eesp-ikev2.org
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -51,8 +51,9 @@ prior to decryption. EESP also enables the establishment of Sub SAs
with independent keys and sequence number spaces. Additionally, it
supports the use of 64-bit sequence numbers transmitted in each
packet or the omission of sequence numbers when the Replay Protection
service is not needed. EESP packets carry a version number, enabling
easier support for future extensions.
service is not needed or cannot be achieved (e.g. in some multicast
scenarios). EESP packets carry a version number, enabling easier
support for future extensions.

This document specifies the negotiation of EESP Security
Associations (SAs) within the Internet Key Exchange Protocol
Expand Down Expand Up @@ -234,15 +235,15 @@ Use of Sub SAs is optional in EESP and can be negotiated using IKEv2.

** EESP Sequence Numbers

Unlike ESP, EESPv0 header allows to transmit 64-bit sequence numbers.
In addition, the Sequence Number field in the EESPv0 header is
optional and can be omitted from the packet if replay protection
service is not needed. Note that while possible, disabling the
replay protection service is generally NOT RECOMMENDED and should
only be done if the upper level protocol provides this service. See
[[Security Considerations]] for details.
Unlike ESP, the EESPv0 header transmits 64-bit sequence numbers if
replay protection is used. In addition, the Sequence Number field in
the EESPv0 header is optional and can be omitted from the packet if
replay protection is not needed. Note that while possible, disabling
Comment thread
tobiasbrunner marked this conversation as resolved.
replay protection is generally NOT RECOMMENDED and should only
be done in case of multicast scenarios or if the upper level protocol
provides this service. See [[Security Considerations]] for details.

# [VS] I believe this is covered below in the discssion about
# [VS] I believe this is covered below in the discussion about
# [VS] restrictions on negotiated parameters

# ** Explicit Initialization Vector
Expand Down Expand Up @@ -343,21 +344,18 @@ The type of the Sub SA Key Derivation Function transform is <TBA2>.
*** New Transform IDs for Sequence Numbers Transform Type

This document defines two new Transform IDs for the Sequence Numbers
transform type: ~64-bit Sequential Numbers~ (<TBD4>) and ~None~ (<TBD5>).
transform type: ~64-bit Sequential Numbers~ (<TBD5>) and ~None~ (<TBD6>).

To enable presence of sequence numbers in the EESP header the
initiator MUST propose SN = (64-bit Sequential Numbers) in the
Proposal Substructure inside the Security Association (SA) payload.
When the responder selects 64-bit Sequential Numbers, the Sequence Number
field is included into the EESP header, that allows peers to
achieve replay protection.

# 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.
To enable the presence of sequence numbers in the EESP header and
enabling replay protection, the initiator MUST propose SN = (64-bit
Sequential Numbers) in the Proposal Substructure inside the Security
Association (SA) payload. When the responder selects 64-bit Sequential
Numbers, the Sequence Number field MUST be included into the EESP
header and peers MUST perform replay protection.

To disable sequence numbering, and thus replay protection based on
sequence numbers, the initiator MUST propose SN=None (<TBD5>).
When the responder selects None, Sequence Number field is omitted
sequence numbers, the initiator MUST propose SN=None (<TBD6>).
When the responder selects None, the Sequence Number field is omitted
from the EESP header.

** Transforms Consistency
Expand Down Expand Up @@ -399,15 +397,15 @@ Sequence Numbers transform type (32-bit Sequential Numbers and
Partially Transmitted 64-bit Sequential Numbers)
are unspecified for EESPv0 and MUST NOT be used in EESPv0 proposals.

Implemenattions MUST ignore transforms containing invalid
Implementations MUST ignore transforms containing invalid
values for the current proposal (as if they are unrecognized,
in accordance with Section 3.3.6 of [[RFC7296]]).

The use of the None Transform ID for the SN transform
The use of the ~None~ Transform ID for the SN transform
if further limited by the ENCR transform. In particular,
if the selected ENCR transform defines use of implicit IV
(as transforms defined in [[RFC8750]]), then the value None MUST NOT
be selected for the SN transform.
(as transforms defined in [[RFC8750]]), then the value ~None~ MUST
NOT be selected for the SN transform.

** Example of SA Payload Negotiating EESP

Expand Down Expand Up @@ -464,17 +462,6 @@ If this notification is received it MUST be ignored.
# procedure as deleting Child SA using IKEv2 INFORMATIONAL exchange as
# specified in Section 1.4.1 [[RFC7296]]

# * EESP SA Transforms
# EESP introduces several transform properties that are negotiated
# during the establishment of an EESP SA. These properties MUST be
# identical for the duration of the SA. When the SA is rekeyed,
# the new SA MUST inherit all EESP transform properties negotiated for
# the original EESP SA.
#
# | Type | Description | Used In | Reference |
# |------+---------------------------+---------+-----------------+
# | TBD6 | EESP Session ID(EESPSID) | (EESP) | [this document] |

** Announcing Maximum Sub SA ID

In the process of establishing the EESP SA, each peer MAY inform the
Expand All @@ -498,8 +485,8 @@ A new notify status type EESP_MAX_SUB_SA_ID (<TBD3>) is defined by
this document. The format of the Notify payload for this notification
is shown below.

#+caption: Sub SA Notifier
#+name: sub-sa-notifier
#+caption: Maximum Sub SA Notification
#+name: max-sub-sa-notify
#+begin_src
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
Expand Down Expand Up @@ -537,6 +524,51 @@ that Sub SA IDs not repeat).
If no SSKDF transform was negotiated, this notification MUST be
ignored by peers.

** Announcing Maximum Crypt Offset

Each peer MAY inform the other side about the maximum offset they
accept in the EESP ~Crypt Offset~ option. The other side MUST NOT
use a Crypt Offset exceeding this value (inclusive).

Note that this is not a negotiation: each side can indicate its own
value for the maximum Crypt Offset. If a valid EESP packet is
received where the Crypt Offset exceeds the announced maximum, it
MUST be dropped, and the Child SA SHOULD be deleted.

A new notify status type EESP_MAX_CRYPT_OFFSET (<TBD4>) is defined by
this document. The format of the Notify payload for this notification
is shown below.

#+caption: Maximum Crypt Offset Notification
#+name: max-crypto-offset-notify
#+begin_src
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-----------------------------+-------------------------------+
! Next Payload !C! RESERVED ! Payload Length !
+---------------+---------------+-------------------------------+
! Protocol ID ! SPI Size ! Notify Message Type !
+---------------+---------------+-------------------------------+
! Maximum C. O. |
+---------------+
#+end_src
Comment thread
tobiasbrunner marked this conversation as resolved.

- Protocol ID (1 octet) - MUST be 0. MUST be ignored if not 0.
- SPI Size (1 octet) - MUST be 0. MUST be ignored if not 0.
- Notify Status Message Type (2 octets) - set to EESP_MAX_CRYPT_OFFSET (<TBD4>).
- Maximum Crypt Offset (1 octet)
-- specifies the maximum value for the CryptOffset field in the
EESP Crypt Offset option the sender of this notification is
accepting (measured in 4-octet units). Note that the field in the
option is only 6 bits wide.

If a peer doesn't allow the use of the Crypt Offset option, instead
of sending the value 0, the notification SHOULD be omitted entirely.
That is, if this notification was not received by a peer, that peer
MUST not use a Crypt Offset when sending EESP packets. If a packet
with Crypt Offset option is still received, it MUST be dropped, and
the Child SA SHOULD be deleted.

Copy link
Copy Markdown
Collaborator

@smyslov smyslov Aug 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, what to do with packets violating this "MUST"? Or violating the maximum Crypt Offset value? Perhaps this should be specified in the core EESP document, but some rules should be given.
This is actually a difficult question. On one hand, if the peer sends a packet with Crypt Offset greater maximum announced value (including 0), then the possible harm (if any) has already done, so why the packet should be dropped? On the other hand, this is a violation of a host's policy, so why we expressed it if we do not enforce it?
Opinions?

Copy link
Copy Markdown
Collaborator Author

@tobiasbrunner tobiasbrunner Aug 5, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, I first had "MUST drop the packet" in the second paragraph of this section (where I now just recommend terminating the IKE SA). But like you, I wondered why, because it's a valid packet and the damage is already done so why drop it.

Copy link
Copy Markdown
Collaborator Author

@tobiasbrunner tobiasbrunner Aug 12, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

After discussing it with Antony and Steffen, I've added that the packet MUST be dropped and only the Child SA SHOULD be deleted. I've added the same text here at the bottom of the section.

* Key Derivation for Sub SAs

When an EESP SA is using Sub SAs, each Sub SA (including the one
Expand Down Expand Up @@ -628,14 +660,15 @@ document.
| Value | Notify Message Status Type | Reference |
|--------+----------------------------+-----------------+
| <TBD3> | EESP_MAX_SUB_SA_ID | [this document] |
| <TBD4> | EESP_MAX_CRYPT_OFFSET | [this document] |

# *** Extending ESP with EESP
#Several tables in [[IKEv2-IANA]] that specify ESP as protocol
#should be extended with EESP. Should we list each table one by one or
#specify as replace ESP, with ESP, EESP.e.g in the Transform Type Values,
#replace 'IKE and ESP' with 'IKE, ESP, and EESP'
# Several tables in [[IKEv2-IANA]] that specify ESP as protocol
# should be extended with EESP. Should we list each table one by one or
# specify as replace ESP, with ESP, EESP.e.g in the Transform Type Values,
# replace 'IKE and ESP' with 'IKE, ESP, and EESP'
#
#Changes the "Used In" column for the existing allocations as follows;
# Changes the "Used In" column for the existing allocations as follows;

*** Sequence Number

Expand All @@ -644,8 +677,8 @@ This document defines two new values in the IKEv2 "Transform Type 5

| Value | Name | Reference |
|---------+-------------------------------+-----------------+
| <TBD4> | 64-bit Sequential Numbers | [this document] |
| <TBD5> | None | [this document] |
| <TBD5> | 64-bit Sequential Numbers | [this document] |
| <TBD6> | None | [this document] |

** New IKEv2 Registries

Expand Down
Loading