+1 for option4, +0.5 for option3 One factor to consider is the granularity of label, for me it is per CHILD_SA; option1 is per TS (e.g TS with label and TS without label could be mixed in the same payload), option2 is per TS payload (e.g. you could have TSi with label, TSr without label)
Option3 is a bit "abusing" the semantic of notification payload, since a "label notification" is not communicating a status, error or capability. -----Original Message----- From: IPsec <ipsec-boun...@ietf.org> On Behalf Of Paul Wouters Sent: Monday, December 9, 2019 8:58 PM To: ipsec@ietf.org WG <ipsec@ietf.org> Cc: Sahana Prasad <sah...@redhat.com> Subject: [IPsec] Labeled IPsec options 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
