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? > Option 3 looks like a compromise from practical point of view. Agree on that too. Either option 1 or 3 would be acceptable for me, with slight preference on option 1 because it would be proper way of doing things. > 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 > 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. I am not sure we need that. I mean if initiator do require security labels and sends security labels notification, but responder does not reply to them, what can it do next? There isn't going to be any communications between the peers in that case, so it should simply tear down the SA anyways. If it gets same information during IKE_SA_INIT (missing SECLABELS_SUPPORTED), it cannot trust that thing yet as other end is not authenticated, so it will need to run IKE_AUTH to the end anyways to make sure that there was no attack removing that SECLABELS_SUPPORTED notification. So it will detect that error at the end of IKE_AUTH always. In that case there is no point of adding notification to the IKE_SA_INIT. -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
