Internet DRAFT - draft-mglt-ipsecme-ts-dscp
draft-mglt-ipsecme-ts-dscp
IPsecme D. Migault
Internet-Draft J. Halpern
Intended status: Standards Track U. Parkholm
Expires: 20 October 2023 D. Liu, Ed.
Ericsson
18 April 2023
Traffic Selector for Internet Key Exchange version 2 to add support
Differentiated Services Field Codepoints (DSCP)
draft-mglt-ipsecme-ts-dscp-02
Abstract
This document defines a new Traffic Selector for Internet Key
Exchange version 2 to add support Differentiated Services Field
Codepoints (DSCP) as a traffic selector of the Security Policy
Database (SPD). The new Traffic Selector type TS_DSCP consists of
DSCP values associated to the negotiated SA.
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 20 October 2023.
Copyright Notice
Copyright (c) 2023 IETF Trust and the persons identified as the
document authors. All rights reserved.
Migault, et al. Expires 20 October 2023 [Page 1]
Internet-Draft TS_DSCP April 2023
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. TS_DSCP Traffic Selector Type . . . . . . . . . . . . . . . . 3
2.1. TS_DSCP payload format . . . . . . . . . . . . . . . . . 3
2.2. TS_DSCP properties . . . . . . . . . . . . . . . . . . . 4
3. Traffic Selector negotiation . . . . . . . . . . . . . . . . 4
4. IPsec encapsulation . . . . . . . . . . . . . . . . . . . . . 5
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
6. Security Considerations . . . . . . . . . . . . . . . . . . . 6
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 7
8.1. Normative References . . . . . . . . . . . . . . . . . . 7
8.2. Informative References . . . . . . . . . . . . . . . . . 7
Appendix A. Illustrative Example . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 7
1. Introduction
[RFC4301] does not include Differentiated Services Field Codepoints
(DSCP) as Traffic Selectors (TS). [RFC4301], Section 4.1
acknowledges that aggregating traffic with mutliple DSCP over the
same SA may result in inappropriate discarding of lower priority
packets due to the windowing mechanism used by this feature.
However, to address such concern, [RFC4301], Section 4.1 recommends
the sender implements a "classifier" mechanism which dispatches the
traffic over multiple SAs.
Such "classifier" results in inbound and outbound traffic may take SA
negotiated via different IKEv2 sessions and thus makes SA management
more complex with an unnecessary SAs. This causes both a resource
issue - especially with hardware implementations that are designed
with a limited number of SAs - as well operational and management
issues.
Typically, if the DSCP values are negotiated the initiator and the
responder can agree to send a set of DSCP value over one SA and
another set of DSCP value over a second channel. If DSCP values are
not agreed and between (for example) 2 SAs, it is unlikely the
initiator and the responder miraculously select the same subset of
Migault, et al. Expires 20 October 2023 [Page 2]
Internet-Draft TS_DSCP April 2023
DSCP values over the same SAs. Instead each peer is likely that
inbound and outbound traffic take different SA and as such does not
solve the issue of discarding lower priority packets associated to
different class of traffic sharing a given SA. This makes traffic
management at least much harder as if not impossible. Increasing the
number of SAs as to lower the traffic rate over each of these SA
might reduce the probability of packet being dropped, but is not
deterministic and as such cannot be considered as a solution
especially when considering hardware with a hard limitation on the
number of SAs.
This document specifies a new Traffic Selector Type TS_DSCP for IKEv2
that can be used to negotiate DSCP as additional selectors for the
Security Policy Database (SPD) to further restrict the type of
traffic allowed to be sent and received over the IPsec SA.
This document follows the clarification between Traffic Selector and
Traffic Selector payload (TS) described in
[I-D.ietf-ipsecme-labeled-ipsec], Section 1.2 and uses TS only to
designate the TSi/TSr payload. This document uses TS_DSCP to
designates the TS_TYPE value of the Traffic Selector payload with a
specific TS_TYPE set to TS_DSCP.
2. TS_DSCP Traffic Selector Type
This document defines a new TS_TYPE, TS_DSCP that contains a list of
opaque DSCP value.
2.1. TS_DSCP payload format
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
+---------------+---------------+-------------------------------+ |
TS Type | Reserved | Selector Length |
+---------------+---------------+-------------------------------+ | |
~ List of DSCP Values ~ | |
+---------------------------------------------------------------+
As mentioned in [RFC7296], Section 3.13.1, All fields other than TS
Type and Selector Length depend on the TS Type.
* TS Type (one octet) - Set to TBD1 for TS_DSCP
* Selector Length (2 octets, unsigned integer) - Specifies the
length of this Traffic Selector substructure including the header.
* Reserved (one octet): MUST be set to zero by the sender and MUST
be ignored by the receiver.
Migault, et al. Expires 20 October 2023 [Page 3]
Internet-Draft TS_DSCP April 2023
* List of DSCP Values: The concatenation of the DSCP values
associated to the SA. Each value is coded over one octet and
considered as opaque value by the SAD. DSCP values are ordered in
an increasing number.
2.2. TS_DSCP properties
A TS MUST NOT contain more than one TS_DSCP. Values contained in the
TS_DSCP MUST be unique and ordered in increasing number. If these
conditions are not met, an TS_UNACCEPTABLE Error Notify message MUST
be returned.
The absence of the TS_DSCP indicates that all DSCP values will match
the SA. A TS_DSCP MUST explicitly contain all DSCP values that a
valid IP packet MUST match.
A zero length list of DSCP Values indicates that no DSCP values are
associated to the SA. In other words, no traffic qualifies. Upon
receiving such a TS_DSCP a TS_UNACCEPTABLE Error Notify message MUST
be returned by the IKEv2 responder.
A responder that understandsMAY respond with a TS_DSCP that contains
a subset of the set of values sent by the initiator. In any other
cases, a TS_UNACCEPTABLE Error Notify message MUST be returned by the
IKEv2 responder.
If the presence and values of the TS_DSCP provided by the responder
does not exactly matches the presence and the values of the TS_DSCP
provided by the initiator, the initiator MUST NOT create Child SAs
and SHOULD send a Delete notification for the Child SA so the
responder can uninstall its Child SA.
3. Traffic Selector negotiation
TS_DSCP MUST MUST be used along with an IP address selector type such
as TS_IPV4_ADDR_RANGE and/or TS_IPV6_ADDR_RANGE. If this condition
is not met an TS_UNACCEPTABLE Error Notify message MUST be returned.
If the TS contains a TS_DSCP along with another TS_TYPE, the
responder MUST create each TS response for the Traffic Selector of
TS_TYPE TS_IPV4_ADDR_RANGE or TS_IPV6_ADDR_RANGE, using its normal
rules specified for each of those TS_TYPE. The responder includes
the acceptable DSCP values. These values will apply to all Traffic
Selectors mentioned in the resulting TS. If this is not possible, it
MUST return a TS_UNACCEPTABLE Error Notify payload.
Migault, et al. Expires 20 October 2023 [Page 4]
Internet-Draft TS_DSCP April 2023
The responder MAY respond select a subset of the DSCP values sent by
the initiator and send a TS_DSCP payload or omit that TS_DSCP
payload. If the responder provides the TS_DSCP, the initiator
creates the SA with the specified subset of DSCP values.
If the subset of DSCP values do no match those of the initiator, this
may indicate the responder's policy might be stricter regarding DSCP
values. The initiator created the Child SA with the subset of DSCP
values. The initiator SHOULD (upon local configuration) try to
negotiate a separate SA associated to the missing DSCP values. The
other selectors of different TS_TYPE SHOULD take the same values as
the initial ones.
If the TS_DSCP is omitted the initiator (upon local configuration)
MAY accept the response in which case DSCP is not considered as a
traffic selector, that is to say all DSCP values are considered
matching the policy. On the other hand, the initiator (upon local
configuration) MAY also reject the offer and send a Delete Notify
Payload.
If the responder returns a TS_UNACCEPTABLE Error Notify Payload, this
might result in the responder not supporting TS_DSCP - though
discarding the TS_DSCP would have been more appropriated. The
initiator (upon local configuration) MAY restart the IKE negotiation
with the same TSi/Tsr but removing the TS_DSCP.
4. IPsec encapsulation
This document creates the DSCP traffic selector which complements
those defined by [RFC4301].
A IP packet match the DSCP selector when its DSCP value matches the
one (or one of those) specified by the DSCP selector. When DSCP is
not specified or is an empty list, it is understood as bypassing the
DSCP values, which means that all DSCP values will result in a match.
In other words, the non existing DSCP can be replaced by the DSCP
array 0 - 255. These various representations are matching the the
description of "DSCP values" in the SA. However TS_DSCP does not
accept an empty list and an implementation MUST omit the TS_DSCP to
be sent - sending 256 possible values is not RECOMMENDED for obvious
reasons.
In the SPD, the PFP flags applies to the DSCP selector and means that
a new SA is created when a SDP match occurs without any existing SA
matching the specific DSCP value of the IP header.
The SAD defines "DSCP values" to indicate the specific values that
matche the SA (see [RFC4301] Section 4.4.2.1.. When used in
conjunction of the traffic selector DSCP, this field MUST either take
Migault, et al. Expires 20 October 2023 [Page 5]
Internet-Draft TS_DSCP April 2023
the same values as those of the DSCP traffic selector or be left
emtpy. Note that the difference between the DSCP traffic selector
and the "DSCP values" is that values specified by the DSCP traffic
selector MUST be checked against inbound traffic arriving on the SA,
while values specified by the "DSCP values" MUST NOT be checked.
"Bypass DSCP" remains unchanged. However, when the tunnel mode is
used, it is RECOMMENDED to map the inner DSCP value to the outer DSCP
value of the header.
5. IANA Considerations
IANA is requested to allocate two values in the "IKEv2 Traffic
Selector Types" registry (available at
https://www.iana.org/assignments/ikev2-parameters/
ikev2-parameters.xhtml#ikev2-parameters-16) with the following
definition:
+=======+======================+
| Value | TS Type | REFERENCE |
+=======+ =====================+
| TBD1 | TS_DSCP | This-RFC |
+-------+----------------------+
6. Security Considerations
A packet that matches an SPD entry for all components except the DSCP
values would be treated as "not matching". If no other SPD entries
match, the traffic might end up being transmitted in the clear.
It is not different from ensuring that IP traffic is not sent in
clear text and it is presumed that the IPsec subsystem itself would
install a REJECT/DISCARD rule in the SPD to prevent that traffic from
being transmitted without IPsec protection.
To avoid such situation, it is RECOMMENDED to introduce a SP to does
not consider the DSCP values after those SP specifying the DSCP.
This is very similar to placing a default SP that protects all
traffic by default.
Upon receiving a TS_UNACCEPTABLE Error Notify or an incorrect
response, the initiator MAY retry the IKEv2 negotiation without
specifying the DSCP values. The initiator MAY handle the DSCP value
on its own for outbound traffic, but MUST be prepared to receive any
DSCP values from the responder.
7. Acknowledgements
Migault, et al. Expires 20 October 2023 [Page 6]
Internet-Draft TS_DSCP April 2023
8. References
8.1. 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>.
8.2. Informative References
[I-D.ietf-ipsecme-labeled-ipsec]
Wouters, P. and S. Prasad, "Labeled IPsec Traffic Selector
support for IKEv2", Work in Progress, Internet-Draft,
draft-ietf-ipsecme-labeled-ipsec-11, 10 April 2023,
<https://datatracker.ietf.org/doc/html/draft-ietf-ipsecme-
labeled-ipsec-11>.
Appendix A. Illustrative Example
The example shows a negotiation where each TSi / TSr are negotiating
different values of DSCP. The purpose of this example is to show
this is theoretically feasible, but we currently expect that
TS_DSCP_LIST1 and TS_DSCP_LIST2 have the same values.
``` Initiator Responder
-------------------------------------------------------------------
HDR, SK {N(REKEY_SA), SA, Ni, [KEi,] TSi, TSr} --> with: TSi = (
TS_IPV6_ADDR_RANGE, TS_DSCP_LIST1 ) TSr = ( TS_IPV6_ADDR_RANGE,
TS_DSCP_LIST2 )
<-- HDR, SK {SA, Nr, [KEr,]
TSi, TSr}
with:
TSi = ( TS_IPV6_ADDR_RANGE, TS_DSCP_LIST1 )
TSr = ( TS_IPV6_ADDR_RANGE, TS_DSCP_LIST2 ) ```
Authors' Addresses
Daniel Migault
Ericsson
Email: daniel.migault@ericsson.com
Migault, et al. Expires 20 October 2023 [Page 7]
Internet-Draft TS_DSCP April 2023
Joel Halpern
Ericsson
Email: joel.halpern@ericsson.com
U. Parkholm
Ericsson
Email: ulf.x.parkholm@ericsson.com
Daiying Liu (editor)
Ericsson
Email: harold.liu@ericsson.com
Migault, et al. Expires 20 October 2023 [Page 8]
