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 11 September 2023.¶

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

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

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

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}
with:
  TSi = ( TS_IPV6_ADDR_RANGE, TS_DSCP_LIST1 )
  TSr = ( TS_IPV6_ADDR_RANGE ) ```

Authors' Addresses