Internet-Draft DSCP Notify Payload October 2023
Migault, et al. Expires 8 April 2024 [Page]
Workgroup:
IPsecme
Internet-Draft:
draft-mglt-ipsecme-dscp-np-00
Updates:
RFC4301 (if approved)
Published:
Intended Status:
Standards Track
Expires:
Authors:
D. Migault
Ericsson
J. Halpern
Ericsson
U. Parkholm
Ericsson
D. Liu
Ericsson

Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification

Abstract

IPsec supports "classifier" mechanism to send traffic with specific Differentiated Services Field Codepoints (DSCP) over different tunnels. However, such classification is not explicitly notified to the other peer. This document specifies the DSCP Notification Payload, which, in a CREATE_CHILD_SA Exchange, explicitly mentions which DSCP code points will be tunneled in the newly created tunnel.

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 8 April 2024.

Table of Contents

1. Introduction

[RFC4301], Section 4.1 acknowledges that aggregating traffic with multiple DSCP over the same SA may result in inappropriate discarding of lower priority packets due to the windowing mechanism used by this feature. To address such concern, [RFC4301], Section 4.1 recommends the sender implements a "classifier" mechanism which dispatches the traffic over multiple SAs. However, the peer is not able to indicate the other peer it is classifying traffic according to its DSCP values, nor how DSCP values are classified.

While [RFC4301], Section 4.4.2.1 mentions the "DSCP values" fields in the Security Association Database (SAD), [RFC7296] does not provides a way to for peers to indicate which "DSCP values" are associated to the created SA. This document fills that gap and specifies the DSCP Notification Payload, which, in a CREATE_CHILD_SA Exchange, explicitly mentions which DSCP code points will be tunneled in the newly created tunnel.

2. RFC4301 clarification

[RFC4301], Section 4.4.2.1 mentions

    o DSCP values -- the set of DSCP values allowed for packets carried
      over this SA.  If no values are specified, no DSCP-specific
      filtering is applied.  If one or more values are specified, these
      are used to select one SA among several that match the traffic
      selectors for an outbound packet.  Note that these values are NOT
      checked against inbound traffic arriving on the SA.

The text does not clearly specify what happens when the DSCP of a packet does not match any of the corresponding DSCP values. This document proposes the following text:

3. Protocol Overview

The illustrative example of this section considers Expedited Forwarding (EF) with low latency traffic has its own IPsec tunnel, Assured Forward (AF) classes with different drop precedence and may take a different route have their own tunnel and all remaining DSCP values are put in another tunnel.
This section details how a peer uses the DSCP Notify Payload to classify traffic carrying the DSCP values AF11 or AF3 in one tunnel, traffic carrying a DSCP value of EF in another tunnel and traffic with other DSCP values a third tunnel. This latest SA is designated as the default no-DSCP specific SA. It is RECOMMENDED to configure the Security Policy Data Base (SPD), so that such a default no-DSCP specific SA is created and it is RECOMMENDED its creation happens prior the SA with specific DSCP values. Note that according to Section 2, there is no specific ordering, but starting with the no-DSCP specific SA ensures compatibility with IPsec implementation that would for example discard or create a new SA when the DSCP do not match.

Generally, it is recommended that the outer DSCP value matches the inner DSCP value so that the tunneled packet be treated similarly to the inner packet. Such behavior is provided by setting the Bypass DSCP to True. If the initiator prefers for example every tunneled packet being treated similarly, then, an explicit mapping needs to be indicated. Typically, the initiator may be willing to prevent reordered traffic to fall outside the anti-replay windows. Note that such policy is implemented by each peer.

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {IDi, [CERT,] [CERTREQ,]
       [IDr,] AUTH, SAi2,
       TSi, TSr}  -->

                                <--  HDR, SK {IDr, [CERT,] AUTH,
                                         SAr2, TSi, TSr}

Once the no-DSCP specific SA is created, all traffic with any DSCP value is steered to that SA. The initiator then creates the child SA associated with specific DSCP values. In this example, it creates the SA associated with the DSCP value AF11 or AF3, followed by the one associated with value of EF, but this does not follow any specific ordering. The initiator specifies the DSCP values being classified in that SA with a DSCP Notify Payload that carries the DSCP values.

If the responder supports the DSCP Notify Payload, it SHOULD respond with a Notify Payload that indicates the DSCP values selected for that tunnel. By default these values SHOULD be the ones specified by the initiator, but the responder's policy MAY select other values. If the responder does not want to perform DSCP filtering, the responder SHOULD send a empty DSCP Notify Payload in order to at least indicate the support of the DSCP Notify Payload.

As specified in [RFC7296], Section 3.10.1, Notify Payload with status type MUST be ignored if not recognized. The absence of a DSCP Notify Payload by the responder may be due to the responder not supporting the notification or not advertising the application of DSCP filtering. We do not consider that the absence of classification by the responder prevents the SA to be created. The classification is at least performed for the outbound stream, which is sufficient to justify the creation of the additional SA. Note also that DSCP values are not agreed, and the responder cannot for example narrow down the list of DSCP values being classified. If that would cause a significant issue, the responder can create another SA with the narrow down list of DSCP values. The responder may also REKEY_SA the previously SA to redefine the DSCP values to be considered.

When multiple DSCP values are indicated, and the initiator is mapping the outer DSCP value, the outer DSCP value is expected to be one of these values.

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {SA, Ni, KEi, N(DSCP, AF11, AF3)} -->

                                <--  HDR, SK {SA, Nr, KEr,
                                          N(DSCP, AF11, AF3)}

The initiator may then create additional child SAs specifying other DSCP values.

   Initiator                         Responder
   -------------------------------------------------------------------
   HDR, SK {SA, Ni, KEi, N(DSCP, EE)} -->

                                <--  HDR, SK {SA, Nr, KEr}

4. Protocol Description

During the CREATE_CHILD_SA exchange, the initiator or the responder MAY indicate to the other peer the DSCP filtering policy applied to the SA. This is done via the DSCP Notify Payload indicating the DSCP values being considered for that SA.

The initiator MAY send an empty DSCP Notify Payload to indicate support of the DSCP Notify Payload as well as an indication the negotiated SA as a no-DSCP specific SA. This SA MAY be followed by the creation of DSCP specific SA.

Upon receiving a DSCP Notify Payload, if the responder supports the notification it SHOULD respond with a DSCP Notify Payload. The value indicated SHOULD be the one selected by the initiator.

There is no specific error handling.

5. Payload Description

The DSCP Notify Payload is based on the format of the Notify Payload as described in [RFC7296], Section 3.10 and represented in Figure 1.

                     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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Next Payload  |C|  RESERVED   |         Payload Length        |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol ID  |   SPI Size    |      Notify Message Type      |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                                                               |
~                       Notification Data                       ~
|                                                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Notify Payload

The fields Next Payload, Critical Bit, RESERVED, and Payload Length are defined in [RFC7296]. Specific fields defined in this document are:

6. IANA Considerations

IANA is requested to allocate one value in the "IKEv2 Notify Message Types - Status Types" registry: (available at https://www.iana.org/assignments/ikev2-parameters/ikev2-parameters.xhtml#ikev2-parameters-16) with the following definition:

  Value    Notify Messages - Status Types
-----------------------------------------
  TBD      DSCP

7. Security Considerations

As the DSCP value field is already defined by [RFC4301] in the SA structure. As such security considerations of [RFC4301] apply. The DSCP Notification Payload communicates clearly the DSCP value field to the responder.

When the tunnel mode is used, the communication of the DSCP value field could be easily interpreted by monitoring the received DSCP values of the inner traffic when that traffic is encapsulated, and so no secret information is revealed. When the transport mode is used, that value may be changed by the network and eventually, the value of the field could be unknown to the other peer. However, this cannot be considered as a protection mechanism, and the communication of the DSCP value cannot be considered as revealing information that was previously not revealed.

The ability to indicate the other peer to set the DSCP value does not lead to the consumption of additional resources nor additional constraints. First, these SAs are anyway created either with DSCP values or without. Then, the responder may also ignore the DSCP Notification Payload and the fact that the SA has set a DSCP value field to specific values does not prevent the responder to send traffic with a different DSCP value over that SA.

8. Acknowledgements

We would like to thank Scott Fluhrer for his useful comments; Valery Smyslov, Tero Kivinen for their design suggestions we carefully followed.

9. Normative References

[RFC4301]
Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, , <https://www.rfc-editor.org/info/rfc4301>.
[RFC7296]
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, , <https://www.rfc-editor.org/info/rfc7296>.

Authors' Addresses

Daniel Migault
Ericsson
Joel Halpern
Ericsson
U. Parkholm
Ericsson
Daiying Liu
Ericsson