| Internet-Draft | DSCP Notify Payload | October 2023 |
| Migault, et al. | Expires 8 April 2024 | [Page] |
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.¶
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.¶
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.¶
[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.¶
[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:¶
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}
¶
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.¶
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 ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The fields Next Payload, Critical Bit, RESERVED, and Payload Length are defined in [RFC7296]. Specific fields defined in this document are:¶
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¶
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.¶
We would like to thank Scott Fluhrer for his useful comments; Valery Smyslov, Tero Kivinen for their design suggestions we carefully followed.¶