Re: Labeled IPsec options

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
> [email protected]
> https://www.ietf.org/mailman/listinfo/ipsec