Internet-Draft TS_DSCP March 2023
Migault, et al. Expires 11 September 2023 [Page]
Intended Status:
Standards Track
D. Migault
J. Halpern
U. Parkholm

Traffic Selector for Internet Key Exchange version 2 to add support Differentiated Services Field Codepoints (DSCP)


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.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 11 September 2023.

Table of Contents

1. Introduction

[RFC4301] does not include Differentiated Services Field Codepoints (DSCP) as Traffic Selectors (TS). [RFC4301], Section 4.1 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, [RFC4301], Section 4.1 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 [I-D.ietf-ipsecme-labeled-ipsec], Section 1.2 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.

2. TS_DSCP Traffic Selector Type

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

2.1. 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 [RFC7296], Section 3.13.1, 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.

2.2. 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.

3. 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.

4. IANA Considerations

IANA is requested to allocate two values in the "IKEv2 Traffic Selector Types" registry (available at with the following definition:

| Value | TS Type  | REFERENCE |
+=======+ =====================+
| TBD1  | TS_DSCP  | This-RFC  |

5. 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.

6. Acknowledgements

7. References

7.1. Normative References

Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, , <>.
Kaufman, C., Hoffman, P., Nir, Y., Eronen, P., and T. Kivinen, "Internet Key Exchange Protocol Version 2 (IKEv2)", STD 79, RFC 7296, DOI 10.17487/RFC7296, , <>.

7.2. Informative References

Wouters, P. and S. Prasad, "Labeled IPsec Traffic Selector support for IKEv2", Work in Progress, Internet-Draft, draft-ietf-ipsecme-labeled-ipsec-09, , <>.

Appendix A. 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 )

                            <--  HDR, SK {SA, Nr, [KEr,]
                                     TSi, TSr}
  TSr = ( TS_IPV6_ADDR_RANGE ) ```

Authors' Addresses

Daniel Migault
Joel Halpern
U. Parkholm