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

[Tobias Brunner <[e-mail]>]

Hi Paul,

> 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.

   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?

 * 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.  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'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).

Regards,
Tobias