On Fri, 21 Jul 2023, Tobias Brunner wrote:
I tried to formulate and solve the issues discussed at the previous
meeting. There was no clear outcome (based on rereading the minutes)
so please check the changes and let the authors know if you disagree.
Thanks for the updates. Some notes:
* maybe clarify that IPCOMP_SUPPORTED is only sent and a MUST if IPComp
was negotiated in the original Child SA.
I'll see about clarifying text.
RFC 7296 explicitly states "These payloads MUST NOT occur in messages
that do not contain SA payloads." with regards to IPCOMP_SUPPORTED.
Is there any clarification required on that?
Oh. Interesting. Maybe that means this draft must Update: 7296 :P
* maybe add "incompatible proposal" as a reason for initiating a
regular Child SA rekeying of the first SA (if the KE method used
for IKE is not in the Child SA proposal).
However, I'd honestly prefer if that was just the standardized
behavior for the Child SA created with IKE_AUTH as we really don't
know what KE methods the responder has in its Child SA proposal.
I would really like to avoid requiring the regular rekey method in the
protocol. That way, some time in the far future, this could perhaps
become the only rekey method used. If this draft has a requirement
for the old method in it, we will never be able to get rid of the older
one.
Additionally, having a different KE for the initial Child that comes
from the IKE KE and its Child SA rekey is already a questionable/bad
configuration, since you are not rekeying the child under the same
level of protection. I dont mind doing extra work for those who want
such questionable/bad configurations, but would not want to add it to
proper/good configurations that do not need it.
So just blindly assuming the IKE's KE methods will be accepted seems
risky (in particular if multiple key exchanges were involved in
creating the IKE SA). That IKE SA's first KE method can still be
preferred in the Child SA rekeying request if it's in the initiator's
proposal (i.e. use it for the KE payload and list it as first
method in the SA payload). But if there is a mismatch, it seems
easier to recover during a regular rekeying than blindly trying the
IKE KE method, receiving an INVALID_KE_PAYLOAD and then having to
initiate a regular rekeying all over anyway (if that's even an
option, the draft currently doesn't explicitly say).
I think a mismatch really means a bad configuration. You are allowing
a single Child SA to have different KE level protections between REKEYs,
which is definitely violating the spirit of rekey.
* I'm still wondering why the critical bit has to be set for the
OPTIMIZED_REKEY notify. It's a regular Notify payload, so it MUST be
understood by all IKEv2 implementations and setting the bit is
basically redundant (the critical bit only concerns the payload type,
not the contents such as the notify message type - it's also only
allowed to be set in requests so making it an unconditional MUST like
that violates RFC 7296 anyway).
This is a good point. It might be an argument for OPTIMIZED_REKEY not
being a NOTIFY payload but its own new payload type. You are right that
notify payloads cannot have the critical bit set. So if we keep this
as notify that has to be removed. Although we will end up with a weird
situation where we get a successfull IKE message exchange, but the
rekey actually failed. Let's discuss at IETF-117.
Thanks for the feedback.
Paul
_______________________________________________
IPsec mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec
