Re: [IPsec] Labeled IPsec options

[Russ Housley <[e-mail]>]

> On Dec 12, 2019, at 4:02 PM, Tero Kivinen <[e-mail]> wrote:
> 
> Valery Smyslov writes:
>> I don't think option 4 is a good idea. If old responder 
>> encounters an unknown payload with Critical bit set in IKE_AUTH, it will
>> return back UNSUPPORTED_CRITICAL_PAYLOAD and IKE SA won't be set up.
>> See section 2.21.2 of RFC7296. This would require initiator to retry from
>> IKE_SA_INIT, doubling the work. Or it can create childless IKE SA
>> and then try CREATE_CHILD_SA - not an optimal solution too.
> 
> Agree fully on that. 
> 
>> I also don't like option 2 since it requires changing the way TSs
>> are handled in IKEv2.
> 
> Also agree.
> 
>> Option 1 looks like the clearest from pure theoretical point of view,
>> however I agree that it could lead to TS types explosion in future.
> 
> Yes, I think option 1 would be most proper way of doing the
> negotiation. I am not sure if we are going to get that many new
> traffic selectors in the future, so I do not think the TS types
> explosion is going to be that big issue.
> 
> Also in most setups I would expect security labels to be either always
> mandatory or always omitted (and that information quite often comes
> directly from configuration). I do not really see that common cases
> where initiator would try to use security labels and responder not
> supporting them.
> 
> I.e., if you do always require security labels, there is no TS
> explosion as you only propose TS with security labels. If you do not
> support them, you use normal TS.
> 
> You would propose both only if you do not care whether other end
> supports security labels, but are willing to use them if it supports,
> but what is the meaning of security labels then? Why even propose them
> if you do not care what they are?

If the initiator wants to use labels but the responder does not support labels, will the initiator move forward anyway?  Doing so would seem surprising to me.  The point of the label is to indicate what handling is needed to adequately protect the data.  Moving forward without the responder agreeing to that handling seems unlikely to me.  Are there situations where moving forward is "the right thing"?

If not, then Option 1 makes the most sense to me.

Russ