Re: Labeled IPsec options

On Thu, 12 Dec 2019, Valery Smyslov wrote:

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

I don't think that matters. Security labels are never optional but
always mandatory. And it seems very unlikely to have a mix of child sa's
with and without label. So they will all have a label, and then failing
the  IKE SA is fine, since no single child sa will be able to be setup
anyway. It's better than the responder setting up an SA that needs to be
torn down by the initiator sending a delete.

> 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.
>
> Option 3 looks like a compromise from practical point of view.
> You can solve the problem of imperfect error handling by adding
> a new SECLABES_SUPPORTED notification, that must be exchanged
> in IKE_SA_INIT. If both peers support seclabels, then

But you really mean SECLABEL_REQUIRED? The "supported"
keyword here is misleading. The problem of doing this in IKE_SA_INIT
is that it could result in a spoofed answers omiting the payload?

> the responder must not ignore seclabel notifications in IKE_AUTH
> and CREATE_CHILD_SA. The drawback is that we need
> one more notification and it must be exchanged in IKE_SA_INIT,
> increasing its message size. Not a big deal.

So I'm not sure I trust this design.

Paul