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 _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
