Internet DRAFT - draft-mglt-ipsecme-dscp-np
draft-mglt-ipsecme-dscp-np
IPsecme D. Migault
Internet-Draft J. Halpern
Updates: RFC4301 (if approved) U. Parkholm
Intended status: Standards Track D. Liu
Expires: 8 April 2024 Ericsson
6 October 2023
Differentiated Services Field Codepoints Internet Key Exchange version 2
Notification
draft-mglt-ipsecme-dscp-np-00
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.
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
Migault, et al. Expires 8 April 2024 [Page 1]
Internet-Draft DSCP Notify Payload October 2023
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 . . . . . . . . . . . . . . . . . . . . 2
3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 3
4. Protocol Description . . . . . . . . . . . . . . . . . . . . 5
5. Payload Description . . . . . . . . . . . . . . . . . . . . . 5
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 7
9. Normative References . . . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
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.
Migault, et al. Expires 8 April 2024 [Page 2]
Internet-Draft DSCP Notify Payload October 2023
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.
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.
Migault, et al. Expires 8 April 2024 [Page 3]
Internet-Draft DSCP Notify Payload October 2023
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.
Migault, et al. Expires 8 April 2024 [Page 4]
Internet-Draft DSCP Notify Payload October 2023
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.
Migault, et al. Expires 8 April 2024 [Page 5]
Internet-Draft DSCP Notify Payload October 2023
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.
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.
Migault, et al. Expires 8 April 2024 [Page 6]
Internet-Draft DSCP Notify Payload October 2023
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,
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>.
Authors' Addresses
Daniel Migault
Ericsson
Email: daniel.migault@ericsson.com
Joel Halpern
Ericsson
Email: joel.halpern@ericsson.com
Migault, et al. Expires 8 April 2024 [Page 7]
Internet-Draft DSCP Notify Payload October 2023
U. Parkholm
Ericsson
Email: ulf.x.parkholm@ericsson.com
Daiying Liu
Ericsson
Email: harold.liu@ericsson.com
Migault, et al. Expires 8 April 2024 [Page 8]
