eesp-ikev2.org : re-write Sub SA as problem statement and soltuon. #4
Conversation
Elaborating Sub SA. As problem statement and solution. Valery 2/10
| @@ -66,6 +66,12 @@ in stateful decryption configurations, sharing a common SPI namespace | |||
| 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.
| 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".
| 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.
Elaborating Sub SA. As problem statement and solution.
Valery 2/10