elaborate SK_sub is directional. #7
Conversation
eesp-ikev2.org
Outdated
| Sub SA ID. If the receiver is pre-populating a Sub SA, it may have | ||
| to install it with a source port set to zero and, upon arrival of a | ||
| packet, update the source port using a mapping change for for this, | ||
| uni-directional Sub SA |
There was a problem hiding this comment.
Hm, how does this relate to SK_sub (as the title suggests)? And aren't all IPsec SAs unidirectional by definition? Why point it out here specifically?
There was a problem hiding this comment.
oh that is not part of this. That was part of UDP encap clarifications.I will move it there. Thanks.
I hope to clarify SK_sub derived from KEYMAT is directional
antonyantony
force-pushed
the
antony/edit-3-sub-sa-kdf-fixes
branch
from
ef5d9cb to
fb9ccff
Compare
| keys, SK_sub, is determined by the key size of the negotiated SSKDF. | ||
| The root key(s) for the initiator-to-responder direction are derivedi | ||
| before those for the responder-to-initiator direction. | ||
|
|
There was a problem hiding this comment.
That's not correct. We only get keys used for SSKDF here, not the individual keys for encryption/integrity algorithms. So this does not depend on the algorithms at all (except for the SSKDF key size). That difference is only relevant when applying SSKDF later to derive KEYMAT_sub using the key we got here.
| Keys for Sub SAs may be derived immediately after IKE negoation of | ||
| the Child SA or on demand when the first packet is processed. Memory |
There was a problem hiding this comment.
Maybe use during IKE negotiation because "after" is a bit confusing.
| negotiation of the EESP Child SA. This Sub SA ID is used to derive | ||
| a unique key, yielding the following benefits: |
There was a problem hiding this comment.
Hm, not sure if these benefits result from that unique key. Some are just benefits of having Sub SAs.
| SAs of [[RFC9611]], which are alwaya a pair of unidirectional SAs, | ||
| Sub SAs MAY be defined strictly in one direction when reverse traffic is |
There was a problem hiding this comment.
Hm, this seems a bit confusing as well. How can they be "defined" in strictly one direction? Do you mean that there could be more Sub SAs in one direction than the other? (One peer just wanting to accept one sub SA with Session ID 0 and the other allowing more.)
There was a problem hiding this comment.
Perhaps there is some misunderstanding of what was agreed upon at the last conference call. My understanding is that each side can create as many Sub SAs (acting as sender) as the other side indicated it is ready to accept (acting as a receiver). There is no requirement that these numbers are equal. During Child SA establishment each side would send a notify, indicating how many Sud SAs it can tolerate as a receiver. There is no negotiation, the values can differ - it is OK that for example when the initiator can handle up to 5 incoming Sub SAs and the responder can handle 20 of them. This is very similar (but simplified) to the concept of STREAMs in QUIC (RFC 9000). In QUIC new streams are created by senders at any time, but the total number of streams they can create is limited by the MAX_STREAMS message, that was sent earlier by the peer. In case of EESP this concept is simplified (no individual deletion of Sub SAs, no dynamic update of the maximum number of Sub SAs, etc.), but the idea is the same.
Are we here on the same page or not?
There was a problem hiding this comment.
yes. Valery. I think this what we are trying write down.
Though I have one further question. In the call, did we clarify the number proposed is in one direction or combined ? I think for one direction. I didn't add that to the notifier.
There was a problem hiding this comment.
Each side informs the other side about what is the maximum number of incoming Sub SAs it is ready to handle. This doesn't include Sub SAs this party would create as a sender (outgoing). Thus, each proposal (in fact, this is not "proposal", this is an "announcement", since there is no negotiation, just an information) counts only incomimg Sub SAs, not both directions.
|
this is moved to the other draft. May be I will bring it there. |
No description provided.