Re: Labeled IPsec options

+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 <[email protected]> On Behalf Of Paul Wouters
Sent: Monday, December 9, 2019 8:58 PM
To: [email protected] WG <[email protected]>
Cc: Sahana Prasad <[email protected]>
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
[email protected]
https://www.ietf.org/mailman/listinfo/ipsec