Re: [IPsec] draft-ietf-ipsecme-ikev2-sa-ts-payloads-opt-01 update

[Paul Wouters <[e-mail]>]

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