Hi Paul, > > 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,
Do you want to say, that it's impossible to have two SGWs with multiple networks behind them so, that traffic from some networks will have security labels and traffic from the others won't have? If such a configuration is possible, then it's perfectly OK to have a mix of labelled and non-labelled IPsec SAs created by one IKE SA. Regards, Valery. > 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
