eesp-ikev2.org : re-write Sub SA as problem statement and soltuon. #4
Conversation
eesp-ikev2.org
Outdated
| while introducing new capabilities to enhance IPsec’s performance | ||
| and versatility in modern use cases. | ||
|
|
||
| EESP Sub SAs provide a unidirectional SA instead of conventional |
There was a problem hiding this comment.
THis part could be argued by others. Conventional Child SAs are unidirectional too, they are just always creted in pairs by IKEv2. But this is not EESP limitation - this is IKEv2 limitation. More accurate wording is needed.
eesp-ikev2.org
Outdated
| monotonically increasing order to meet cryptographic requirements. | ||
| * Sub SA | ||
| Existing mechanisms for establishing Child SAs, as described in | ||
| [[RFC7296]], yield bidirectional SAs. When using |
There was a problem hiding this comment.
See above about "bidirectionalness".
eesp-ikev2.org
Outdated
| same traffic selectors [[RFC7296]], [[RFC9611]]. | ||
|
|
||
| Each Sub SA is identified by a Sub SA ID, which MUST be carried in | ||
| each EESP packet—either in the Session ID field or in the Flow ID |
There was a problem hiding this comment.
This is a bit complicated. Can we choose a single place to Sub SA ID (e.g. Session ID)? If not, then a justification would be needed.
| on large IKE windows [[RFC7296]]. This allows rapid provisioning | ||
| of extra flows without introducing round-trip delays. | ||
|
|
||
| - Simplified Lifecycle Management**: Sub SAs are more efficient |
There was a problem hiding this comment.
This text is not clear for me. I've been thinking that Sub SAs live only in the context of their parent SA. Thus, they cannot be individually rekeyed or deleted. They can be created "on demand" but only if "parent" SA were created with support for Sub SAs and only up to the limit that was set when "parent" SA was created. So, in my opinion, the lifecycle management is not a good term here.
| narrow scope streamlines both key management and policy | ||
| enforcement. | ||
|
|
||
| - On-the-Fly Key Derivation: Implementations using hierarchical |
There was a problem hiding this comment.
I think this implies PSP-like use of EESP. But in PSP per-packet keys are derived from IV and not from Sub SA ID (that is limited in size). If keys are derived from Sub SA ID, then what is IV for? It can be fixed then :-) Perhaps I'm missing something here.
add the negotation part using Sub SA notifier.
antonyantony
force-pushed
the
antony/edit-2-sub-sa-rewrite
branch
from
2d7fb7f to
040a621
Compare
| Sub SAs are negotiated during the creation of an EESP Child SA, such | ||
| as in the IKE_AUTH or CREATE_CHILD_SA new SA exchanges. To propose | ||
| Sub SA support, the initiator MUST include a USE_EESP_SUB_SA | ||
| notification, which specifies the "Minimum Number of Sub SAs" |
There was a problem hiding this comment.
Isn't it the maximum number this particular peer accepts as well?
There was a problem hiding this comment.
It should be maximum number. Each side indicates the upper limit for Sub SAs it can handle as a receiver. THere is no negotiation, just announcement. The actual number of Sub SAs may differ in different directions.
| of Sub SAs for the Child SA MUST be the minimum value between | ||
| these two numbers. |
There was a problem hiding this comment.
So the peers have to agree on the maximum number of Sub SAs? So an asymmetric configuration isn't possible? (As suggested by some other text that mentions the directionality and such a possibility.) Definitely possible that that would be too complex anyway.
There was a problem hiding this comment.
Please see my comment to the other PR. There seems to be some misunderstanding. I believed that the concept of Sub SAs is close to the concept of STREAMs in QUIC - any peer is free to create as many Sub SAs as it wants (as a sender), but not more than the maximum number, the other side announced during Child SA establishment. THere is no negotiation, the maximum numbers can be different and the actual number of Sub SAs can differ in different directions.
Are we on the same page?
There was a problem hiding this comment.
Yes, that was my understanding as well.
| complies with the negotiated limit. If at any point a peer attempts | ||
| to exceed the agreed number, the implementation MUST reject such an | ||
| attempt and log an appropriate error. |
There was a problem hiding this comment.
How would that attempt look like? An out-of-bounds Session ID?
There was a problem hiding this comment.
I believe so. If the Session ID is sequential (as we seemed to agree, but now I am not sure :-)), then it is very easy to check.
| attempt and log an appropriate error. | ||
|
|
||
| If the response does not include USE_EESP_SUB_SA or the responder | ||
| indicates a lower "Maximum Number of Sub SAs" than proposed, the |
There was a problem hiding this comment.
Shouldn't lower be fine? (And this seems to indicate that the initiator also sent it's maximum number of Sub SAs it can handle.)
| - Minimum number of Sub SAs (2 octets). MUST be greater than 0. | ||
| - Notify Status Message Type (2 octets) - set to [TBD1] | ||
| - Minimum number of Sub SAs (2 octets). MUST be greater than 0, | ||
| If 0 is received, it MUST be interpreted as 1. |
There was a problem hiding this comment.
I don't think this is good idea to treat 0 as 1. But let us first synchronize our understanding of Sub SAs :-)
|
after restructuring this mostly addressed. |
Elaborating Sub SA. As problem statement and solution.
Valery 2/10