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

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 https://datatracker.ietf.org/drafts/current/.¶

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 27 January 2024.¶

Copyright Notice

Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

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 implementations that are designed with a limited number of SAs - as well operational and management issues.
Typically, if the DSCP values are negotiated the initiator and the responder can agree to send a set of DSCP value over one SA and another set of DSCP value over a second channel. If DSCP values are not agreed and between (for example) 2 SAs, it is unlikely the initiator and the responder miraculously select the same subset of DSCP values over the same SAs. Instead each peer is likely that inbound and outbound traffic take different SA and as such does not solve the issue of discarding lower priority packets associated to different class of traffic sharing a given SA. This makes traffic management at least much harder as if not impossible. Increasing the number of SAs as to lower the traffic rate over each of these SA might reduce the probability of packet being dropped, but is not deterministic and as such cannot be considered as a solution especially when considering hardware with a hard limitation on the number of SAs.¶

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

 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                      ~
|                                                               |
+---------------------------------------------------------------+

3. Traffic Selector negotiation

When DSCP are specified, a single TS_DSCP MUST be included in the TSi. If more than one TS_DSCP is found across the TSi/TSr an TS_UNACCEPTABLE Error Notify message MUST be returned.¶

TS_DSCP MUST be used along with an IP address selector type such as TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE. If this condition is not met an TS_UNACCEPTABLE Error Notify message MUST be returned.¶

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 specified for each of those TS_TYPE. TS_DSCP refines the DSCP values to that resulting TS. If refining the DSCP values is not possible, it MUST return a TS_UNACCEPTABLE Error Notify payload.¶

The responder supporting TS_DSCP selects a subset of the DSCP values sent by the initiator and MUST send a TS_DSCP payload or omit that TS_DSCP payload. If the responder provides the TS_DSCP, the initiator creates the SA with the specified subset of DSCP values. This results in the creation of the Child SA associated with the specific DSCP values. If the TS_DSCP values provided by the responder do not include some values provided by the initiator, The initiator SHOULD (upon local configuration) try to negotiate a separate SA associated to the missing DSCP values. The other selectors of different TS_TYPE SHOULD take the same values as the initial ones.¶

If the responder does not support TS_DCSP, according to [RFC5996], Section 2.9, TS_DSCP will be ignored and as such not provided by the responder in its TSi.
A missing TS_DSCP indicates that DSCP is not considered as a traffic selector, that is to say all DSCP values are considered matching the policy. If this is not acceptable to the initiator, the initiator MUST send a Delete Notify Payload.¶

If the TS_DSCP is omitted the initiator (upon local configuration) MAY accept the response in which case DSCP is not considered as a traffic selector, that is to say all DSCP values are considered matching the policy. If that is acceptable to the initiator, this results in the creation of the Child SA associated with the specific DSCP values. On the other hand, the initiator (upon local configuration) MAY also reject the offer and send a Delete Notify Payload.¶

If the responder returns a TS_UNACCEPTABLE Error Notify Payload, this might result in the responder not supporting TS_DSCP - though discarding the TS_DSCP would have been more appropriated. The initiator (upon local configuration) MAY restart the IKE negotiation with the same TSi/Tsr but removing the TS_DSCP.¶

4. IPsec encapsulation

This document creates the DSCP traffic selector which complements those defined by [RFC4301].¶

A IP packet match the DSCP selector when its DSCP value matches the one (or one of those) specified by the DSCP selector. When DSCP is not specified or is an empty list, it is understood as bypassing the DSCP values, which means that all DSCP values will result in a match. In other words, the non existing DSCP can be replaced by the DSCP array 0 - 255. These various representations are matching the the description of "DSCP values" in the SA. However TS_DSCP does not accept an empty list and an implementation MUST omit the TS_DSCP to be sent - sending 256 possible values is not RECOMMENDED for obvious reasons.¶

In the SPD, the PFP flags applies to the DSCP selector and means that a new SA is created when a SDP match occurs without any existing SA matching the specific DSCP value of the IP header.
The SAD defines "DSCP values" to indicate the specific values that match the SA (see [RFC4301] Section 4.4.2.1.. When used in conjunction of the traffic selector DSCP, this field MUST either take the same values as those of the DSCP traffic selector or be left emtpy. Note that the difference between the DSCP traffic selector and the "DSCP values" is that values specified by the DSCP traffic selector MUST be checked against inbound traffic arriving on the SA, while values specified by the "DSCP values" MUST NOT be checked.¶

"Bypass DSCP" remains unchanged. However, when the tunnel mode is used, it is RECOMMENDED to map the inner DSCP value to the outer DSCP value of the header.¶

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

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

6. Security Considerations

One needs to consider that the DSCP field is a mutable field which means that the IP Authentication Header (AH) does not protect it.¶

As a result, DSCP is only used in the Tunnel mode where the DSCP value considered for the traffic selectors - and specified in the SA - is in the inner packet and thus protected.¶

In addition, DSCP values is not commonly used for access control policies as it values indicates how a packet is transit as opposed where that packet comes from / to.¶

As a result, security policies must ensure that a different DSCP value cannot be used to escape a security policy. When security policies are set with DSCP values, all DSCP values SHOULD be associated with the same rule to prevent confidential traffic from being sent in clear or discarded.  In particular, when a specific traffic associated with specific DSCP values is PROTECTed, traffic with other DSCP values SHOULD be PROTECTed.    Eventually, it MAY be DISCARed but that traffic SHOULD NOT be BYPASSed. To do so, as the SPD is an ordered data base, it is RECOMMENDed to introduce a SP that does not consider the DSCP values after those SP specifying the DSCP. This is very similar to placing a default SP that protects all traffic by default.¶

Upon receiving a TS_UNACCEPTABLE Error Notify or an incorrect response, the initiator MAY retry the IKEv2 negotiation without specifying the DSCP values. In that case, the initiator MAY handle the DSCP value on its own for outbound traffic, but MUST be prepared to receive any DSCP values from the responder.¶

7. Acknowledgements

Appendix A. Illustrative Example

The example shows a negotiation where each TSi / TSr are agreeing on DSCP values. The TS_DSCP could have been placed in TSr as well but not in both TS.¶

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


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

Authors' Addresses