]> Ericsson

daniel.migault@ericsson.com

Ericsson

joel.halpern@ericsson.com

Ericsson

ulf.x.parkholm@ericsson.com

Security IPsecme Internet-Draft This document defines a new Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP) as a traffic selector of the Security Policy Database (SPD). The new Traffic Selector type TS_DSCP consists of DSCP values associated to the negotiated SA.

Introduction does not include Differentiated Services Field Codepoints (DSCP) as Traffic Selectors (TS). acknowledges that aggregating traffic with mutliple DSCP over the same SA may result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. However, to address such concern, recommends the sender implements a "classifier" mechanism which dispatches the traffic over multiple SAs. Such "classifier" results in inbound and outbound traffic may take SA negotiated via different IKEv2 sessions and thus makes SA management more complex with an unnecessary SAs. This causes both a resource issue - especially with hardware implementation that are designed with a limited number of SAa - as well operational and management issues. This document specifies a new Traffic Selector Type TS_DSCP for IKEv2 that can be used to negotiate DSCP as additional selectors for the Security Policy Database (SPD) to further restrict the type of traffic allowed to be sent and received over the IPsec SA. This document follows the clarification between Traffic Selector and Traffic Selector payload (TS) described in and uses TS only to designate the TSi/TSr payload. This document uses TS_DSCP to designates the TS_TYPE value of the Traffic Selector payload with a specific TS_TYPE set to TS_DSCP.

TS_DSCP Traffic Selector Type This document defines a new TS_TYPE, TS_DSCP that contains a list of opaque DSCP value.

TS_DSCP payload format bash 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +---------------+---------------+-------------------------------+ | TS Type | Reserved | Selector Length | +---------------+---------------+-------------------------------+ | | ~ List of DSCP Values ~ | | +---------------------------------------------------------------+ As mentioned in , All fields other than TS Type and Selector Length depend on the TS Type. TS Type (one octet) - Set to TBD1 for TS_DSCP Selector Length (2 octets, unsigned integer) - Specifies the length of this Traffic Selector substructure including the header. Reserved (one octet): MUST be set to zero by the sender and MUST be ignored by the receiver. List of DSCP Values: The concatenation of the DSCP values associated to the SA. Each value is coded over one octet and considered as opaque value by the SAD.

TS_DSCP properties A TS MUST NOT contain more than one TS_DSCP. Upon receiving more than one TS_DSCP, an TS_UNACCEPTABLE Error Notify message MUST be returned. The absence of the TS_DSCP indicates that all DSCP values will match the SA. A TS_DSCP MUST explicitly contain all DSCP values that a valid IP packet MUST match. The DSCP values contents are opaque to the IKE implementation. That is, the IKE implementation might not have any knowledge of the meaning of this selector, other than as a type and opaque value to pass to the SPD. A zero length list of DSCP Values indicates that no DSCP values are associated to the SA. In other words, no traffic qualifies. Upon receiving such a TS_DSCP a TS_UNACCEPTABLE Error Notify message MUST be returned by the IKEv2 responder. A responder that does not accept any of the proposed DSCP values SHOULD return a zero length list of DSCP Values. This clearly indicates the issue is related to the proposed DSCP values as opposed to the presence of the TS_TYPE TS_DSCP. The responder MAY also send a TS_UNACCEPTABLE Error Notify message. Upon receiving a list of DSCP values, the responder MAY accept the full list or MAY narrow down the list. The responder MUST NOT add new DSCP values and the initiator MUST NOT create the Child SA. When a TS_DSCP is included in the TSi/TSr Payloads.
If the responder replies with TSi/TSr that include the TS_DSCP, than the Child SA MUST be created including the negotiated DSCP values.
If the responder did not include a TS_DSCP in its response, then the initiator will install the Child SA without including any DSCP values. If the initiator required the TS_DSCP, it MUST not install the Child SA and it MUST send a Delete notification for the Child SA so the responder can uninstall its Child SA.

Traffic Selector negotiation If the TS contains a TS_DSCP along with another TS_TYPE, the responder MUST create each TS response for the Traffic Selector of TS_TYPE TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE, using its normal rules specifed for each of those TS_TYPE. The responder includes the acceptable DSCP values. These values will apply to all Traffic Selectors mentioned in the resulting TS - including an empty list of DSCP values. If this is not possible, it MUST return a TS_UNACCEPTABLE Error Notify payload. As TS_DSCP MAY NOT be supported, the initiator SHOULD first try to negotiate the Child SA with the TS payload including the optional TS_DSCP. If such a negotiation results in receiving a TS_UNACCEPTABLE Error Notify, it SHOULD attempt a new Child SA negotiation using the same TS but without TS_DSCP.

IANA Considerations IANA is requested to allocate two values in the "IKEv2 Traffic Selector Types" registry (available at https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16) with the following definition:

Security Considerations A packet that matches an SPD entry for all components except the DSCP values would be treated as "not matching". If no other SPD entries match, the traffic might end up being transmitted in the clear. It is not different from ensuring that IP traffic is not sent in clear text and it is presumed that the IPsec subsystem itself would install a REJECT/DISCARD rule in the SPD to prevent that traffic from being transmitted without IPsec protection.

Acknowledgements

&RFC4301; &RFC7296; &I-D.ietf-ipsecme-labeled-ipsec;

Illustrative Example ``` Initiator Responder ------------------------------------------------------------------- HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] TSi, TSr} --> with: TSi = ( TS_IPV6_ADDR_RANGE, TS_DSCP_LIST1 ) TSr = ( TS_IPV6_ADDR_RANGE )