IPsecme D. Migault Internet-Draft J. Halpern Updates: RFC4301 (if approved) S. Preda Intended status: Standards Track D. Liu Expires: 4 September 2025 U. Parkholm Ericsson 3 March 2025 Differentiated Services Field Codepoints Internet Key Exchange version 2 Notification draft-mglt-ipsecme-dscp-np-02 Abstract This document outlines the DSCP Notification Payload, which, during a CREATE_CHILD_SA Exchange, explicitly indicates the DSCP code points that will be encapsulated in the newly established 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 4 September 2025. Copyright Notice Copyright (c) 2025 IETF Trust and the persons identified as the document authors. All rights reserved. Migault, et al. Expires 4 September 2025 [Page 1] Internet-Draft DSCP Notify Payload March 2025 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 2. RFC4301 clarification . . . . . . . . . . . . . . . . . . . . 3 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 4 4. Protocol Description . . . . . . . . . . . . . . . . . . . . 5 5. Payload Description . . . . . . . . . . . . . . . . . . . . . 6 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 7 7. Security Considerations . . . . . . . . . . . . . . . . . . . 7 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 7 9.1. Normative References . . . . . . . . . . . . . . . . . . 7 9.2. Informative References . . . . . . . . . . . . . . . . . 8 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 1. Introduction In the ESP Header Compression Profile Diet-ESP [I-D.ietf-ipsecme-diet-esp], two communicating peers can reach an agreement on DSCP values as part of a compression context. Within this context, DSCP values serve not only as classifiers but are also compressed by the sending peer and subsequently decompressed by the receiving peer for both incoming and outgoing traffic. This process necessitates a mutual agreement on DSCP values for a specific pair of Security Associations (SAs). The DSCP Notification Payload outlined in this specification facilitates the negotiation of these DSCP values for a pair of SAs during the CREATE_CHILD_SA Exchange. Furthermore, the explicit negotiation of DSCP values enhances the "classifier" mechanism, allowing for the establishment of this mechanism and the agreement on various clusters of DSCP values to be considered for each pair of SAs. [RFC4301], Section 4.1 recognizes that aggregating traffic with multiple DSCP values over a single SA may lead to the inappropriate discarding of lower-priority packets due to the windowing mechanism employed by this feature. To mitigate this issue, [RFC4301], Section 4.1 advises that the sender implement a "classifier" mechanism to distribute traffic across multiple SAs. While [RFC4301], Section 4.4.2.1 refers to the "DSCP values" fields in the Security Association Database (SAD), [RFC7296] does not Migault, et al. Expires 4 September 2025 [Page 2] Internet-Draft DSCP Notify Payload March 2025 provide a way for peers to indicate which classification is ongoing nor which "DSCP values" are linked to the created SA. This document addresses that deficiency by specifying the DSCP Notification Payload, which explicitly identifies the DSCP code points that will be tunneled in the newly established tunnel during a CREATE_CHILD_SA Exchange. It is essential to recognize that in a standard "classifier" context, there is no necessity for the same cluster of DSCP values to be linked to both the inbound and outbound Security Associations (SAs) of a specific pair. Typically, one peer may employ one pair of SAs, while the other peer may choose a different pair. This flexibility arises because DSCP values are applied exclusively by the sending node, rather than the receiving node. Although the use of the DSCP Notification Payload does not inhibit such configurations, it is likely to diminish their occurrence. Conversely, we anticipate that the explicit negotiation of DSCP values and pairs of SAs will facilitate the management of these "classifiers." 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: * 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. In case of multiple matches a preference to the most selective list DSCP value could be implemented by the peer's policy. If the DSCP value of the packet does not match any of the DSCP values provided by the associated matching SAs and there is at least one SA with no DSCP-specific filtering, then, one of these SA SHOULD be selected. On the other hand, if all SAs have a DSCP filtering, then, any of the matching SAs can be selected. Note that these values MUST NOT be checked against inbound traffic arriving on the SA. Migault, et al. Expires 4 September 2025 [Page 3] Internet-Draft DSCP Notify Payload March 2025 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. Migault, et al. Expires 4 September 2025 [Page 4] Internet-Draft DSCP Notify Payload March 2025 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. Migault, et al. Expires 4 September 2025 [Page 5] Internet-Draft DSCP Notify Payload March 2025 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: * Protocol ID (1 octet): Set to zero. * Security Parameter Index (SPI) Size (1 octet): Set to zero. * Notify Message Type (2 octets): Specifies the type of notification message. It is set to DSCP_VALUES (see Section 6). * Notification Data (variable length): lists the DSCP values that are considered for the SA. Each value is encoded over a single byte. Migault, et al. Expires 4 September 2025 [Page 6] Internet-Draft DSCP Notify Payload March 2025 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. References 9.1. Normative References Migault, et al. Expires 4 September 2025 [Page 7] Internet-Draft DSCP Notify Payload March 2025 [RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, . [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, October 2014, . 9.2. Informative References [I-D.ietf-ipsecme-diet-esp] Migault, D., Hatami, M., Cespedes, S., Atwood, J. W., Liu, D., Guggemos, T., Bormann, C., and D. Schinazi, "ESP Header Compression Profile", Work in Progress, Internet- Draft, draft-ietf-ipsecme-diet-esp-05, 14 February 2025, . Authors' Addresses Daniel Migault Ericsson Email: daniel.migault@ericsson.com Joel Halpern Ericsson Email: joel.halpern@ericsson.com Stere Preda Ericsson Email: stere.preda@ericsson.com Daiying Liu Ericsson Email: harold.liu@ericsson.com U. Parkholm Ericsson Email: ulf.x.parkholm@ericsson.com Migault, et al. Expires 4 September 2025 [Page 8]