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 also don't like option 2 since it requires changing the way TSs are handled in IKEv2. 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 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. Regards, Valery. > Hi, > > As agreed at IETF 106, we would write up the options for negotiating > Labeled IPsec that we have discussed, with their PROs and CONs, so > that the working group can make a final decision. > > > > Option 1) TS_IPV4_ADDR_RANGE_SECLABEL and TS_IPV6_ADDR_RANGE_SECLABEL > https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-00 > > This option introduced a new Traffic Selector type that is similar > to the core IKEv2 RFC S_IPV4_ADDR_RANGE and TS_IPV6_ADDR_RANGE, but > also contain a Security Label field > > PROs: > - Early failure during IKE_AUTH when mismatched. No IPsec SA establishes > - Does not otherwise change the Traffic Selector processing > CONs: > - A bit ugly to have sort of duplicate Traffic Selector types > - All new TS types in the future would need to get a seclabel and > non-seclabel version. > > > > > Option 2) TS_SECLABEL > https://tools.ietf.org/html/draft-ietf-ipsecme-labeled-ipsec-02 > > PROs: > - No copies of TS TYPE's with/without seclabel > CONs: > - Error handling is less nice. Responder might setup an IPsec SA > narrowed to without security label (unsupported TStypes can be > ignored according to RFC 7296), and the initiator has to refuse > it by sending a Delete SA message (as security labels are typically > mandatory) > - Changes Traffic Selector processing, as now one is told that > if you pick TS_SECLABEL you must also pick a TS_IPV{46}_ADDR_RANGE. > Thus updates RFC 7296 with "sub typing" of TS TYPEs. > > > > > Option 3) Use NOTIFY payloads > (not specified in a draft) > > PROs: > - No changes to Traffic Selector code or specification. Easiest to > implement. > CONs: > - Error handling is less nice. Responder might setup an IPsec SA > without supporting the NOTIFY, and initiator has to Delete SA it. > > > > Option 4) A new payload type like NOTIFY but now we can set Critical Flag > (not specified in a draft) > PROs: > - No changes to Traffic Selector code or specification. Easiest to > implement. > - Can use payload with Critical Flag, so exchange fails if not > configured or supported for security label type payload > - Error handling already done as part of standard IKEv2 > CONs: > - Takes up a new payload number. > - Old Implementations might ignore Critical Flag and new payload type > and setup IPsec SA without Security Label? New implementations not > receiving the new payload type must also send Delete SA to prevent > non-label IPsec SA on responder to linger. > > > Please let us know on the list which solution you prefer and why, so we > can make a final decision and move on :) > > Paul & Sahana > > _______________________________________________ > IPsec mailing list > IPsec@ietf.org > https://www.ietf.org/mailman/listinfo/ipsec _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
