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, <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, October
2014, <https://www.rfc-editor.org/info/rfc7296>.
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,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
diet-esp-05>.
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]