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
