Change the document structure (first cut) #9

smyslov · 2025-02-14T16:11:41Z

This is the first (and very raw!) cut in an attempt to change the document structure. My intention was to change the structure in the following way:

first describe EESP features that need negotiation in IKEv2
then describe how these features are negotiated
then clarify inter-dependanciess and limitations of the EESP parameters

tobiasbrunner · 2025-02-17T10:49:34Z

eesp-ikev2.org

+EESP Sub SA is an unidirectional SA derived from
+the same-direction Child SA from a pair of Child SAs negotiated using


My understanding is that it's rather a "pair of EESP SAs" (one in each direction) that are part of an IKEv2 Child SA. Not a pair of Child SAs, and a Child SA is also bidirectional (via its two IPsec SAs, in this case its two EESP SAs). So maybe something like this:

Suggested change

EESP Sub SA is an unidirectional SA derived from

the same-direction Child SA from a pair of Child SAs negotiated using

An EESP Sub SA is an unidirectional SA derived from the same-direction

EESP SA of the pair of SAs negotiated as a Child SA using

But I'm not entirely sure whether "derived" is the right term here, though.

Otherwise your text is fine (better than mine). I can live with "derived" too.

I can live with it too. I just feel it implies that we first create that EESP SA and then derive the Sub SAs from it. But as I understand it, all the Sub SAs, including the one with Session ID 0, which I guess would be that EESP SA, are basically equal. There is no parent-child relationship (in particular not in regards to the key material). They just all share the negotiated properties, but all have their own key material and state.

I think this concept is bit hard to explain. We can try to improve it. Still I think :
Derived SA – creating new SA based on existing ones, using information from an initial SA negotiation is what we are doing. And new SA's life cycle is connected to the old one. Inherited may mean different lifcyle. end/rekey separately.

Agree. Will try to make it more clear.
Jut want to check that our understanding is the same:

Sub SAs are used in EESP SA to actually protect traffic.

At least one Sub SA (with ID 0) always exists (it is assumed when EESP SA is created). This will influence the semantics of the EESP_MAX_SUB_SAS notify. I think that it should in this case contain the maximum Sub SA ID the incoming Sub SAs can have. Thus, value 0 would mean that incoming Sub SAs ID cannot be other than 0 (meaning only one Sub SA is allowed).

In this case the negotiation of SSKDF should be mandatory (otherwise key material fo traffic protection cannot be derived).

My understanding so far was that if Sub SAs are not used (i.e. the EESP_MAX_SUB_SAS is not sent by the initiator or not returned by the responder, or if no SSKDF is negotiated), the key derivation is the same as for ESP. Kinda like a legacy mode to not complicate implementations if they don't support Sub SAs.

This is OK too (although it creates more choices and more code pathes).

eesp-ikev2.org

tobiasbrunner · 2025-02-17T10:57:16Z

eesp-ikev2.org

+# [VS] I wonder whether we need to reference PSP for this
+# [VS] If we do, then PSP should be a normative reference
+# [VS] I think we'd rather to avoid this and re-define these things
+# [VS] here. BTW, VNI is not used in the text


Depends on whether we actually end up defining anything related to it. But if we move it to a separate document, there is no need to mention it at all.

I think that it first should be defined in the core EESP draft and then evaluated whether IKEv2 can be used to negotiate PSP-like mode of EESP.

eesp-ikev2.org

tobiasbrunner · 2025-02-17T11:33:54Z

eesp-ikev2.org

+
+# [VS] The Sub SA key derivation stuff should be moved to the eesp 
+# [VS] draft. This key derivation is done inside EESP and is opaque 
+# [VS] for IKE


Yes, makes sense to move it there. The other things we can discuss.

I would prefer to it keep it here. As a Child SA key derivation is part of IKE.
Also, just like RFC 4303 does not specify nothing about the keys. While IKEv1, IKEv2 and G-IKE specified their own KDF for ESP packets format specified in 4303.

Child SA key derivation is part of IKE, but Sub SA key derivation is not. Sub SAs are created on the fly by kernel subsystem, and the keys for them are calculated there. IKE is unaware of this process and does not care about it. IKE's role here is to negotiate SSKDF and provide the kernel subsystem with the "root" EESP SA key, that in case od Sub SAs will be the key for the SSKDF taken from KEYMAT (well, in fact two "root" keys for each EESP SA in different directions).
My point here is to place relevant things into the relevant documents. Most probably (at least with my experience) kernel and userland parts of the IPsec will be implemented by different persons. These persons will look at the relevant documents to see, what to do. EESP kernel person will most probably read only core eesp draft and IKE person will read only eesp-ikev2 draft (well, implementers are lazy, me included, and try not to read extra stuff). If we keep Sub SAs key derivation in this draft, then kernel person will have to read this draft and to filter out all the IKE-related things that he/she is not needed.

I agree with Valery. The IKE implementation is not concerned with the key derivation for individual Sub SAs. Its job is to derive the root keys and negotiating an SSKDF. The rest is handled by the EESP implementation. The public interface of the latter is similar to that for ESP in that a key is passed when installing an SA. And as with RFC 4303, it's not described in detail how that's derived, it could even be configured manually e.g. via ip xfrm. But additionally there is an optional SSKDF. So how that is employed to derive Sub SA keys from the root key (instead of directly using that key if no Sub SAs are used) should be defined in the EESP document.

antonyantony

thanks @smyslov for the changes. I would like to merge them once you feel it is ready.

eesp-ikev2.org

antonyantony · 2025-02-17T10:23:11Z

eesp-ikev2.org

+# EESP provides an optional Replay service using
+# 64-bit sequence numbers carried in the packet.
+
+# [VS] This should go to the Security Considerations


can we have these two paragraphs, that you propose to move to Security Consideartions, in both sections?
I understand it is necessary to mention them in Security Considerations. However, I find that section alone will not give the full context of these text. Here we can elaborate and has more context. Let me propose a how to add it in both sections.

Perhaps some words can be left here.

antonyantony · 2025-02-17T10:31:25Z

eesp-ikev2.org

-
+This document uses a notation and conventions from IKEv2 [RFC7296].
+
+# [VS] Well, this list is for sure not complete


I agree this list will be incomplete! I prefer to have more here than none. However, if most of us feel 7296 and 4303 are a must and no need to restate terms from there I would be fine too.

tobiasbrunner

Nice, thanks Valery. Added some comments.

eesp-ikev2.org

tobiasbrunner · 2025-02-18T16:21:21Z

eesp-ikev2.org

+Each Sub SA is identified by a Sub SA Id, which is a number in the 
+range from zero up to the maximum Sub SA ID indicated by the 
+receiver of the Sub SA during EESP SA negotiation via IKEv2 (see  
+[[Announcing Maximum Number of Sub SAs]]). The Sub SA ID is carried 


Maybe the notify should be renamed? Because according to this definition (and other text), it does not designate the maximum number of SAs (the one with ID 0 counts towards that), but the maximum ID that's accepted (max. number of SAs - 1).

How about EESP_MAX_SUB_SA_ID?

eesp-ikev2.org

tobiasbrunner · 2025-02-18T16:38:35Z

eesp-ikev2.org

+Sub SA IDs greater than zero. Both peers MAY independently select
+different source ports for the same Sub SA ID.


I feel the last sentence is more confusing than helpful. There is no correlation at all between the Sub SA IDs of two distinct EESP SAs, which the in- and outbund SAs are (there might not even be the same number of IDs). The MAY seems to indicate that there is some link between them and the natural behavior is to then to use the same ports for the same Sub SA ID. I don't think that's the case. Maybe just remove it?

I think this is Antony's text. I also don't quite understand it. I've commented it out for now, perhaps Antony can clarify what was the intent and then we can re-phrase it.

eesp-ikev2.org

tobiasbrunner · 2025-02-18T16:56:25Z

eesp-ikev2.org

+The maximum number of Sub SAs the sender of this notification can 
+handle as a receiver is the value of the Maximum Sub SA ID 
+field plus 1. For example, value 0 in the Maximum Sub SA ID field 
+means that only one Sub SA (with Subs SA ID = 0) can be handled.


Hm, OK, this now is a bit different than the other text :) And it's problematic because sending 0 would indicate that the maximum accepted Sub SA Id is -1 by this definition. On the other hand, if the value was just the maximum accepted Sub SA Id (not the number of SAs), 0 would be a valid value and indicate that traffic is only accepted on the Sub SA with ID 0.

How so? Perhaps I poorly choose the words, but the intention was to emphasize, that to get maximum number of Sub SAs one should take the value from the Maximum Sub SA ID field and add 1. So, if the value there is 0, then the number of maximum Sub SAs is 1. And so on. Perhaps the text as follows:

The maximum number of Sub SAs the sender of this notification can
handle as a receiver can be calculated as the value of the Maximum
Sub SA ID field plus 1.

You're absolutely right. Not sure what I was thinking :) Maybe I was too focused on the old name of the notify still and somehow read that as the calculation for the maximum SA ID. The proposed text might be a bit clearer.

Anyway, the start of the section is still a bit confusing as it says: "each peer MAY inform the
other side about the maximum number of Sub SAs that it can handle as a receiver". However, it's not exactly the "maximum number of Sub SAs", but the "maximum Sub SA ID". And the documentation of the field currently also says "specifies maximum value for the EESP Sub SAs", it should probably say "specifies maximum value for the EESP Sub SA ID".

Fixed and added more clarifications.

tobiasbrunner · 2025-02-18T16:59:02Z

eesp-ikev2.org

+Sub SAs, then it MAY omit sending this notification. As a consequence 
+- if no this notification was received by a peer, that peer can 
+assume that it create as many outgoing Sub SAs as it needs (provided 
+that Sub SA IDs not repeat).


Nice, I like that the SSKDF and not the notify is used to enable the Sub SA feature. As this definition could open up some potential use cases where the Sub SA IDs are not sequential.

Reformatting to honor 69 characters margin. Fixing abstract Second cut Text polishing Clarification for the EESP_MAX_SUB_SA_ID notify

tobiasbrunner reviewed Feb 17, 2025

View reviewed changes

antonyantony reviewed Feb 17, 2025

View reviewed changes

smyslov force-pushed the main branch 2 times, most recently from 46a37ea to 73161e7 Compare February 18, 2025 14:35

tobiasbrunner reviewed Feb 18, 2025

View reviewed changes

smyslov force-pushed the main branch from 65ca5d9 to d5f4bfc Compare February 19, 2025 08:45

Change the document structure (first cut)

f666701

Reformatting to honor 69 characters margin. Fixing abstract Second cut Text polishing Clarification for the EESP_MAX_SUB_SA_ID notify

smyslov force-pushed the main branch from e567294 to f666701 Compare February 19, 2025 11:56

antonyantony merged commit db38ac4 into klassert:main Feb 20, 2025
1 check failed

		EESP Sub SA is an unidirectional SA derived from
		the same-direction Child SA from a pair of Child SAs negotiated using


		This document uses a notation and conventions from IKEv2 [RFC7296].

		# [VS] Well, this list is for sure not complete

		Sub SA IDs greater than zero. Both peers MAY independently select
		different source ports for the same Sub SA ID.

Change the document structure (first cut) #9

Change the document structure (first cut) #9

Uh oh!

Conversation

smyslov commented Feb 14, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

antonyantony left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

tobiasbrunner left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Reviewers