Javascript disabled? Like other modern websites, the IETF Datatracker relies on Javascript. Please enable Javascript for full functionality.

Encrypted Transport Protocol Path Explicit Signals
draft-reddy-tsvwg-explcit-signal-00

Versions:

The information below is for an old version of the document.

Document	Type	This is an older version of an Internet-Draft whose latest revision state is "Expired".
	Authors	Tirumaleswar Reddy.K , Dan Wing , Mohamed Boucadair
	Last updated	2023-02-08
	RFC stream	(None)
	Formats	txt html xml htmlized pdf bibtex bibxml
Stream	Stream state	(No stream defined)
	Consensus boilerplate	Unknown
	RFC Editor Note	(None)
IESG	IESG state	I-D Exists
	Telechat date	(None)
	Responsible AD	(None)
	Send notices to	(None)

Email authors IPR 1 References Referenced by Nits Search email archive

draft-reddy-tsvwg-explcit-signal-00

TSVWG WG T. Reddy
Internet-Draft Nokia
Intended status: Standards Track D. Wing
Expires: 12 August 2023 Citrix
M. Boucadair
Orange
8 February 2023

Encrypted Transport Protocol Path Explicit Signals
draft-reddy-tsvwg-explcit-signal-00

Abstract

This document defines a mechanism for an endpoint to explicitly
signal encrypted metadata to the network, and the network to signal
its ability to accommodate that metadata back to the endpoint. This
mechanism can be used where the endpoints desire that network
elements along the path receive these explicit signals.

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 12 August 2023.

Reddy, et al. Expires 12 August 2023 [Page 1]
Internet-Draft Encrypted Explicit Signals to network February 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Some Use Cases . . . . . . . . . . . . . . . . . . . . . . . 4
4. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
5. Encryption Considerations . . . . . . . . . . . . . . . . . . 5
6. Explict Signals to a Network Orchestrator . . . . . . . . . . 8
6.1. Obfuscated Metadata . . . . . . . . . . . . . . . . . . . 8
6.2. Key Establishment . . . . . . . . . . . . . . . . . . . . 8
7. UDP Options . . . . . . . . . . . . . . . . . . . . . . . . . 9
7.1. Obfuscated Metadata (OBM) . . . . . . . . . . . . . . . . 9
7.2. Encrypted MetaData (EMD) . . . . . . . . . . . . . . . . 10
7.3. HPKE Encrypted Metadata (HEMD) . . . . . . . . . . . . . 12
8. Provisioning Endpoints . . . . . . . . . . . . . . . . . . . 13
9. Security Considerations . . . . . . . . . . . . . . . . . . . 13
10. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 15
13. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 15
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
14.1. Normative References . . . . . . . . . . . . . . . . . . 15
14.2. Informative References . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17

1. Introduction

[RFC8558] defines "path signals" as endpoint signals to or from on-
path network elements. Such path signals used to often be implicit,
e.g., derived from cleartext end-to-end information by examining
transport protocols. For example, TCP's state machine [RFC9293] uses
a set of well-known control messages that are exchanged in the clear.
Because these messages are visible to network elements on the path
between the nodes that are setting up a transport connection, they
are often used as signals by those network elements for various
purposes (e.g., [RFC8517]). Such signals are not visible in
transport schemes that encrypts them. Often, the removal of those
signals is intended by those moving the messages to confidential
channels. Lack of path signalling may limit network management,

Reddy, et al. Expires 12 August 2023 [Page 2]
Internet-Draft Encrypted Explicit Signals to network February 2023

debugging, or the ability of networks to optimize their services. It
might also harm the ability of service providers and third-parties to
observe why problems occur [RFC9075].

There are many cases where elements on the network path can provide
beneficial services, but only if they can coordinate with the
endpoints (e.g., Sections 3.3 and 3.7 of [RFC8517]). Where the
endpoints desire collaborating with network elements along the path
receive these signals, this document defines a mechanism for explicit
signals to be used. This mechanism is based on explicit trust and
coordination between specific entities, endpoints as well as network
path elements. The explicit signals between applications on an
endpoint and network elements is appropriately protected, enabling
explicit signals exchange in both directions between applications and
network elements to improve the quality of experience and network
management.

Given that the main focus of the mechanism targets collaborating with
on path-elements, the mechanism does not require that all
communication endpoints support it.

The document discusses explicit signals for UDP transport but with an
intent to leverage the key building elements of the solution for
other transport schemes. The mechanism is applicable to both IPv4
and IPv6.

The applicability of the proposed UDP options to QUIC will be
discussed in a separate document. Also, the metadata to be sent in
the explicit signals is outside the scope of this document.

2. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP
14 [RFC2119][RFC8174] when, and only when, they appear in all
capitals, as shown here.

This document uses the following (loosely defined) terms:

Fast Path: A path through a forwarding node (e.g., router) that is
optimized for forwarding packets without processing their
payloads. The Fast Path might be supported by Application
Specific Integrated Circuits (ASICS), Network Processor (NP), or
other special purpose hardware. This is the usual processing path
within a router taken by the forwarding plane. See also
Section 4.8 of [RFC9049].

Reddy, et al. Expires 12 August 2023 [Page 3]
Internet-Draft Encrypted Explicit Signals to network February 2023

Slow Path: A path through a forwarding node that is capable of
general purpose processing and is not optimized for any particular
function. This processing path is used for packets that require
special treatment or differ from assumptions made in Fast Path
heuristics (e.g., acceleration engines), or to process router
control protocols used by the control plane.

Explicit signal: It is an path signal of metadata that can be seen
by authorized on-path network elements examining transport
protocols.

3. Some Use Cases

* Endpoints can signal, on a per-packet level, the desired network
treatment of that particular packet, for example to prioritize/
deprioritize delivery of that packet or that the endpoint no
longer has interest in that flow. This cooperation between the
endpoint and the network improves the user experience especially
in constrained network environments, while maintaining integrity
and confidentiality of the information exchanged between the
endpoints.

* The mechanism described in this document balances the users'
desire to improve their experience while still avoiding passive
surveillance [RFC7258]. This is accomplished by only signaling
what is absolutely necessary, and only signaling that information
to the trusted network that needs to receive that information in
order to improve the user experience. Sharing such signals allows
for a collaborative approach where advanced function are triggered
by the information from endpoints.

4. Design Principles

This document follows the recommendations given by IAB in [RFC8558]
to convey the explicit signals only when the signal's originator
intends that it be used by the on-path network elements. For many
flows, this may result in the signal being absent but allows it to be
present when needed.

[I-D.iab-path-signals-collaboration] discusses principles for
designing mechanisms that provide explicit path signals. The
principles are intended as guidance for the design of solution to
provide these explicit path signals. This document adheres to the
following principles:

* Explicit signals exposed to the path should be decoupled from
signals that drive the protocol state machines in endpoints. This
avoids creating opportunities for additional inference.

Reddy, et al. Expires 12 August 2023 [Page 4]
Internet-Draft Encrypted Explicit Signals to network February 2023

* To ensure that explicit signals are shared intentionally, not
accidentally.

* To ensure that explicit signals dissemination is limited to the
intended on-path network elements and establishing trust
relationships between entities on a path.

* To ensure that the information in the explicit signal is encrypted
or obfuscated to avoid pervasive monitoring.

* To ensure that the information in the explicit signal is
integrity-protected to detect any changes by an on-path attacker.

* The endpoint should only share the information that is needed for
the intended on-path network element(s) to perform the task for
which collaboration is desired, and no more.

* Intermediate path elements should not add visible signals that
would identify the user, origin node, or origin network.

5. Encryption Considerations

[I-D.ietf-tsvwg-udp-options] extends UDP to provide a trailer area
for UDP options, located after the UDP user data. UDP options are
possible because UDP includes its own length field, separate from
that of the IP header. [I-D.ietf-tsvwg-udp-options] uses the surplus
area for UDP options. The explicit signals from the endpoint to the
network can be conveyed in the new UDP options defined in this
document. This mechanism requires an explicit trust and coordination
between specific entities, endpoints as well as network path
elements. Authentication and trust is considered in both directions:
how endpoints trust and authenticate signals from network path
elements, and how network path elements trust and authenticate
signals from endpoints (see also Section 2.2 of [RFC9217]).

The endpoint will mutually authenticate and establish a secure
encrypted connection with a network orchestrator. It requires the
endpoint and network orchestrator to have credentials or keys to
mutually authenticate each other. Section 8 discusses some examples
about how an endpoint acquires the required information to identify
an orchestrator. This document proposes three mechanisms to encrypt
or obfuscate the metadata in the explicit signal:

1. The endpoint conveys the metadata it would like to convey to the
network elements (for specific flows) to the network orchestrator
and receives a random unique identifier (128-bit) for each of the
metadata. The endpoints then conveys the random unique
identifiers in an UDP option and only authorized network elements

Reddy, et al. Expires 12 August 2023 [Page 5]
Internet-Draft Encrypted Explicit Signals to network February 2023

will be able to correlate the metadata. For instance, the
network orchestrator can push the metadata and corresponding
random unique identifiers to authorized network elements to
process the random unique identifiers from the endpoints. If the
application knows all the possible metadata it would like to
convey to the network, this approach is suitable. The
identifiers that are generated per requesting node and session
should not be permanent. As such, this approach may lead to some
performance issues at the network side due to additional memory
required to store the random identifiers.

2. The endpoint gets a symmetric key from the network orchestrator
and uses it to encrypt the metadata in an explicit signal. This
design approach has certain drawbacks in comparison with the
above approach as it would require the endpoint to encrypt the
metadata conveyed in every packet. The network element would
have to decrypt the metadata in the Fast Path or punt the packet
to the Slow Path to perform the decryption operation. In
addition, adding the encrypted metadata to the UDP option could
result in a datagram size that exceeds the Path MTU. If the
metadata is small in size not to exceed the Path MTU, this
approach is suitable. If more than one network element were to
process an explicit signal, it would require all the network
elements to get the symmetric key to decrypt the explicit signal.
The endpoint has to convey a key identifier that will be used by
the network element to select the appropriate keying material for
decryption. The network element decrypting the explicit signal
would use the key identifier to retrieve the symmetric key.

3. Hybrid public-key encryption (HPKE) [RFC9180] is a scheme that
provides public key encryption of arbitrary-sized plaintexts
given a recipient's public key. HPKE utilizes a non-interactive
ephemeral-static Diffie-Hellman exchange to establish a shared
secret. The motivation for standardizing a public key encryption
scheme is explained in the introduction of [RFC9180]. It
requires the endpoint to be securely provisioned with the HPKE
key configuration (Key Identifier, KEM ID, HPKE Ephemeral Public
Key and HPKE Symmetric Algorithms) from a network orchestrator.
The endpoint uses HPKE to encrypt the metadata in the explicit
signal. This mechanism would require the sender ephemeral public
key (pkE) to be sent in the UDP option and asymmetric
cryptographic computation will have to be performed on each
packet conveying the metadata.

An optimization might be to not generate the ephemeral public/
private key pair on each UDP packet conveying the explicit
signal. In addition to the "base" mode, "authenticated" variant
is also supported by HPKE. In the "Authentication Using an

Reddy, et al. Expires 12 August 2023 [Page 6]
Internet-Draft Encrypted Explicit Signals to network February 2023

Asymmetric Key" variant, the endpoint will prove the possession
of a key encapsulation mechanism (KEM) private key. It is useful
in scenarios that require the network element to authenticate the
endpoint sending an explicit signal. If this variant is used, it
would require the public key of the sender (pkS) to be sent in
the UDP option and adds additional overhead. This approach has
the same drawbacks as the previous approach and the additional
overhead of asymmetric cryptography.

The out-of-band communication channel between an endpoint and a
network orchestrator can also be used to control the exchange of
information between the involved entities (Section 2.1 of
[I-D.iab-path-signals-collaboration]). The endpoint and network
orchestrator need to advertise and negotiate the metadata they are
capable of processing. Otherwise, an entity can send some unknown
attribute in the metadata that will be ignored and the entity will
not know if an appropriate action was triggered or not.

The diagram below depicts the general architecture and message flow
for mechanism proposed in the draft:

Controller
Request/Response (1) +-----.---------+
+-----------------------------------------------|->'--------' |
| | |REST | |
| . __ . __ . __ . __ . __ . __ . | |Server | |
| | | '--------' |
| . | |
| | +-----------| |
| . | (2) | |
| | | +-----.---------+
| . | |
| (2)| | . Program the
| . v | network devices (2)
| | +------------------+ .
| . | | |
_|______ | | | ____v____ _________
| | ____ v__ | | | Router | ... | Router |
|Endpoint|..|Switch |....| Middlebox |....| | | |
+--------+- |-------|----|------------------|------------------------------------------>
'-------' | | '---------' '---------' Packet + Metadata (3)
+------------------+

A middlebox could be a CPE router, edge router, switch, wireless
access LAN controller or any other flow-aware device.

Reddy, et al. Expires 12 August 2023 [Page 7]
Internet-Draft Encrypted Explicit Signals to network February 2023

6. Explict Signals to a Network Orchestrator

The input to this protocol is an HTTPS URI on the network
orchestrator that is assumed to have been securely distributed to the
endpoints (Section 8). The following subsections describes the
operations that are performed by an endpoint with a network
orchestrator. One or more orchestrator may be exposed per network.

6.1. Obfuscated Metadata

The endpoint sends the HTTP PUT request to the orchestrator to convey
the metadata it would like to convey to the network and the
orchestrator in the response indicates whether it is able to parse
the metadata or not. For example, if the endpoint sends some garbage
metadata or metadata that is not defined in any specification
(unknown metadata), it will be rejected by the orchestrator. If the
network can parse the metadata, it would convey a random unique
identifier and a lifetime of the random unique identifier.
JavaScript Object Notation (JSON) [RFC8259] payloads are used to
convey the explicit signal payload messages and response information,
such as errors, random unique identifier, etc.

6.2. Key Establishment

The endpoint and the network orchestrator would choose to use
Representational State Transfer (REST) API over HTTPS to establish a
symmetric key. HTTPS MUST be used for data confidentiality, and TLS
based on a client certificate can be used for mutual authentication.
To retrieve a new symmetric key, the endpoint sends an HTTP GET
request to the orchestrator. The response is returned with content-
type 'application/json' and consists of a JSON object that contains
the long-term symmetric key (k).

Reddy, et al. Expires 12 August 2023 [Page 8]
Internet-Draft Encrypted Explicit Signals to network February 2023

Request
-------
example:
GET https://www.example.com/.well-known/key-to-encrypt-metadata

Response
--------

k - symmetric key
exp - identifies the time after which the key expires

example:
{
"k" :
"ESIzRFVmd4iZABEiM0RVZgKn6WjLaTC1FXAghRMVTzkBGNaaN496523WIISKerLi",
"exp" : 1300819380,
"kid" :"22BIjxU93h/IgwEb"
"enc" : A256GCM
}

The orchestrator must also signal 'kid' to the endpoint, which will
be used to select the appropriate keying material for decryption.
The parameter 'k' is defined in Section 6.4.1 of [RFC7518], 'enc' is
defined in Section 4.1.2 of [RFC7516], 'kid' is defined in
Section 4.1.4 of [RFC7515], and 'exp' is defined in Section 4.1.4 of
[RFC7519]. A256GCM and other authenticated encryption algorithms are
defined in Section 5.1 of [RFC7518].

Endpoints and network element implementations MUST support A256GCM as
the authenticated encryption algorithm. The endpoint needs to
periodically request a new symmetric key to change the kid sent in
the explicit signal to avoid an attacker from identifying that the
traffic is coming from the same endpoint. Such frequency is a policy
that is local to the implementation. Absent such policy, the default
value is 24 hours.

7. UDP Options

UDP options that conform to [I-D.ietf-tsvwg-udp-options] are defined
for carrying the metadata as a explicit signal. The use of UDP
options is meant to be applicable to both HTTP/3 media and SRTP.

7.1. Obfuscated Metadata (OBM)

The Obfuscated Metadata UDP option carries one or more random
identifiers generated by an orchestrator for the explicit signals as
discussed in Section 5. Each random identifier is of 128-bit length.

Reddy, et al. Expires 12 August 2023 [Page 9]
Internet-Draft Encrypted Explicit Signals to network February 2023

+----------+----------+----------+----------+
| Kind=TBA1| 255 | Extended Length |
+----------+----------+----------+----------+
| One or more Random Identifiers ~
+----------+----------+----------+----------+

Figure 1: UDP Obfuscated Metadata Format

An attacker can spoof or remove the random identifiers in the OBM UDP
option. To prevent the attack, the Authentication (AUTH, Kind=9) UDP
option defined in [I-D.ietf-tsvwg-udp-options] should be used to
integrity-protect both the UDP user data and surplus area. The key
to generate and validate Message Authentication Code can be retrieved
by the endpoint and network elements from the network orchestrator.
The endpoint must include the Timestamp (TIME) UDP option in the UDP
packet to help the network element identify replay attack.

Invalid OBM UDP options are silently discarded by a network element.

7.2. Encrypted MetaData (EMD)

This UDP option is used to encrypt the UDP options carrying sensitive
metadata using the symmetric key (k) received from a network
orchestrator. This UDP option MAY carry other encrypted UDP options
as depicted in Figure 2 and it is positioned after the UDP options in
the surplus data that do not require encryption.

IP transport payload
<------------------------------------------------->
+--------+---------+----------------------+------------------+
| IP Hdr | UDP Hdr | UDP user data |OCS|...|Encrypted |
+--------+---------+----------------------+------------------+
<------------------------------><-------><--------->
UDP Length Surplus Encrypted
area UDP options

<---------------------------------------->
Integrity Protected

OCS: Option Checksum Option defined in draft-ietf-tsvwg-udp-options

Figure 2: Integrity-protected and Encrypted UDP options

The Encrypted MetaData (EMD, Kind=TBA2) option is defined to allow
encryption of UDP options carrying sensitive metadata. The Figure 3
shows the EMD format:

Reddy, et al. Expires 12 August 2023 [Page 10]
Internet-Draft Encrypted Explicit Signals to network February 2023

Figure 3: UDP Encrypted MetaData Format

The UDP EMD option includes an extended length format, where the
option LEN is 255 followed by two bytes of extended length. The
description of the fields in this option is as follows:

Key Id Len: Carries the length of the key identifier in octets.

Key Identifier: Carries a variable-length Key Identifier object used
to identify the symmetric key (k).The key identifier helps to
resolve the problem of synchronization of keying material.

Nonce Length: Carries the length of the Nonce.

Nonce: Carries the Nonce for the authenticated encryption operation
(Section 3.1 of [RFC5116]).

Encrypted UDP options: Carries the encrypted UDP options.

The authenticated encryption process takes four inputs, each of which
is an octet string: a secret key (k), referred to as "K" in
[RFC5116]), a plaintext (P), associated data (A) (which contains the
data to be authenticated but not encrypted), and a nonce (N). A
ciphertext (C) is generated as an output as discussed in Section 2.1
of [RFC5116]. In order to decrypt and verify, the cipher takes
ENC_KEY, N, A, and C as input. The output is either the plaintext or
an error indicating that the decryption failed as described in
Section 2.2 of [RFC5116]. The endpoint must include the Timestamp
(TIME) UDP option in the UDP packet to help the network element
identify replay attack and this UDP option must not be encrypted.
The UDP user data and the unencrypted UDP options before this option
will be included as associated data (A).

Reddy, et al. Expires 12 August 2023 [Page 11]
Internet-Draft Encrypted Explicit Signals to network February 2023

7.3. HPKE Encrypted Metadata (HEMD)

This UDP option is used to encrypt the UDP options carrying sensitive
metadata using HKPE. This UDP option MAY carry other encrypted UDP
options as depicted in Figure 2 and it is positioned after the UDP
options in the surplus data that do not require encryption.

The Encrypted MetaData (HEMD, Kind=TBA3) option is defined to allow
encryption of UDP options carrying sensitive metadata using HPKE.
The Figure 4 shows the HEMD format:

Figure 4: UDP Encrypted MetaData Format

The UDP HEMD option includes an extended length format, where the
option LEN is 255 followed by two bytes of extended length. The
description of the fields in this option is as follows:

Key Identifier: Carries the Key Identifier.

Algorithm: Indicates the algorithm used with HPKE (e.g.,
AES_128_GCM, AES_256_GCM, CHACHA20_POLY1305) listed Section 7.3 of
[RFC9180].

KEM Identifier: Key Encapsulation Mechanism (KEM) Identifier listed
in Section 7.1 of [RFC9180].

KDF Identifier: Key Derivation Function (KDF) Identifier listed in
Section 7.2 of [RFC9180].

Key Len: Length of the public key.

Public Key: Serialized ephemeral public key of the sender (enc).

Encrypted UDP options: Carries the encrypted UDP options (ct).

Reddy, et al. Expires 12 August 2023 [Page 12]
Internet-Draft Encrypted Explicit Signals to network February 2023

The SealBase(pkR, info, aad, pt) function is used to encrypt a
plaintext (pt) to a recipient's public key (pkR). The sender uses an
empty "info" parameter. The recipient uses the OpenBase(enc, skR,
info, aad, ct) function with the enc and ct parameters received from
the sender. The endpoint must include the Timestamp (TIME) UDP
option in the UDP packet to help the network element identify replay
attack and this UDP option must not be encrypted. The UDP user data
and the unencrypted UDP options before UDP HEMD option will be
included as Associated data (aad).

8. Provisioning Endpoints

If a device is managed by an enterprise's IT department, the device
can be configured with the identity of the network orchestrator and
provisioned with a client certificate. This configuration might be
manual or rely upon whatever deployed device management tool in an
Enterprise.

If mobile device management (MDM) (e.g., [MDM-Apple]) secures a
device, MDM can configure the endpoint with the identity of the
network orchestrator. If an endpoint is on-boarded, for example,
using Over-The-Air (OTA) enrollment [OTA] to provision the device
with a certificate and configuration profile, the configuration
profile can include the identity of the network orchestrator. In
this case, MDM is not installed on the device.

Alternatively, an TLV object can be used by the EAP method (e.g.,
TEAP [RFC7170]) or an new IKEv2 Configuration Payload Attribute Type
can be used by the IPsec server to securely convey the identity of
the network orchestrator to the endpoint.

9. Security Considerations

Security considerations that are applicable to UDP options are
discussed in Section 22 of [I-D.ietf-tsvwg-udp-options].

Mutual authentication is required between the endpoint and network
orchestrator and TLS must be used for confidentiality and message
integrity.

The interaction between the endpoints and the network orchestrator
MUST NOT be transmitted in clear since this would completely destroy
the security benefits of the obfuscation and encryption protection
solution defined in this document. The symmetric key (k) must have
an expiration time assigned as the latest point in time before which
the key may be used for encrypting the metadata in the explicit
signal. Prior to the expiration of the symmetric key, all
participating network elements SHOULD have the orchestrator

Reddy, et al. Expires 12 August 2023 [Page 13]
Internet-Draft Encrypted Explicit Signals to network February 2023

distribute a new key identifier and associated keying material so
that when the symmetric key is expired, those nodes are prepared with
the new symmetric key. This allows the network elements to switch to
the new key identifier as soon as necessary. It is RECOMMENDED that
the next key identifier and associated keying material be distributed
by the orchestrator well prior to the symmetric key expiration time.

An network element capable of decrypting EMD or HEMD UDP option can
identify if an on-path attacker has altered the UDP user data or UDP
options. However, it will not be able to detect an on-path attacker
removing the EMD or HEMD UDP option in the surplus area.

If the random identifiers are generated periodically, an attacker
will not be able to correlate the metadata associated with the random
identifiers in the OBM UDP option.

The explicit signals from endpoints to the network elements are
independent from the signals used by endpoints to manage the flow's
state mechanics, they may be falsified by an endpoint without
affecting the peer's understanding of the flow's state. Network
operators should be cautious when processing explicit signals
considering how falsified signals would adversely impact the network
operation.

10. Privacy Considerations

The endpoint should only share the information that is needed for the
on-path network element to perform the task for which collaboration
is desired, and no more. A detailed privacy analysis of the
information in the explicit signal is required to identify any
adverse affect of revealing the metadata to authorized network
elements. Any explicit signal that does not benefit the flow may be
perceived as an attack even if it is processed by a responsible
network element. For instance, applications should not share content
of communications with network elements and network elements should
not share detailed user location in a wireless network with
applications.

11. IANA Considerations

IANA is requested to assign new kinds from the UDP option registry to
be set by IANA as per [I-D.ietf-tsvwg-udp-options]:

Kind Length Meaning
----------------------------------------------
TBA1 Variable Obfuscated Metadata (OBM)
TBA2 Variable Encrypted MetaData (EMD)
TBA3 Variable HPKE Encrypted Metadata (HEMD)

Reddy, et al. Expires 12 August 2023 [Page 14]
Internet-Draft Encrypted Explicit Signals to network February 2023

12. Contributors

The following individuals have contributed to this document:

Sri Gundavelli
Cisco
United States of America
Email: sgundave@cisco.com

John Kaippallimalil
Futurewei
United States of America
Email: john.kaippallimalil@futurewei.com

13. Acknowledgments

TODO

14. References

14.1. Normative References

[I-D.ietf-tsvwg-udp-options]
Touch, J. D., "Transport Options for UDP", Work in
Progress, Internet-Draft, draft-ietf-tsvwg-udp-options-19,
27 December 2022, <https://www.ietf.org/archive/id/draft-
ietf-tsvwg-udp-options-19.txt>.

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.

[RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated
Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008,
<https://www.rfc-editor.org/info/rfc5116>.

[RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web
Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May
2015, <https://www.rfc-editor.org/info/rfc7515>.

[RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)",
RFC 7516, DOI 10.17487/RFC7516, May 2015,
<https://www.rfc-editor.org/info/rfc7516>.

Reddy, et al. Expires 12 August 2023 [Page 15]
Internet-Draft Encrypted Explicit Signals to network February 2023

[RFC7518] Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
DOI 10.17487/RFC7518, May 2015,
<https://www.rfc-editor.org/info/rfc7518>.

[RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
(JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015,
<https://www.rfc-editor.org/info/rfc7519>.

[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data
Interchange Format", STD 90, RFC 8259,
DOI 10.17487/RFC8259, December 2017,
<https://www.rfc-editor.org/info/rfc8259>.

14.2. Informative References

[I-D.iab-path-signals-collaboration]
Arkko, J., Hardie, T., Pauly, T., and M. Kühlewind,
"Considerations on Application - Network Collaboration
Using Path Signals", Work in Progress, Internet-Draft,
draft-iab-path-signals-collaboration-03, 3 February 2023,
<https://datatracker.ietf.org/doc/html/draft-iab-path-
signals-collaboration-03>.

[MDM-Apple]
Apple, "Mobile Device Management",
<https://developer.apple.com/documentation/
devicemanagement>.

[OTA] Apple, "Over-the-Air Profile Delivery Concepts", <https://
developer.apple.com/library/archive/documentation/Networki
ngInternet/Conceptual/iPhoneOTAConfiguration/OTASecurity/
OTASecurity.html>.

[RFC7170] Zhou, H., Cam-Winget, N., Salowey, J., and S. Hanna,
"Tunnel Extensible Authentication Protocol (TEAP) Version
1", RFC 7170, DOI 10.17487/RFC7170, May 2014,
<https://www.rfc-editor.org/info/rfc7170>.

[RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an
Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May
2014, <https://www.rfc-editor.org/info/rfc7258>.

Reddy, et al. Expires 12 August 2023 [Page 16]
Internet-Draft Encrypted Explicit Signals to network February 2023

[RFC8517] Dolson, D., Ed., Snellman, J., Boucadair, M., Ed., and C.
Jacquenet, "An Inventory of Transport-Centric Functions
Provided by Middleboxes: An Operator Perspective",
RFC 8517, DOI 10.17487/RFC8517, February 2019,
<https://www.rfc-editor.org/info/rfc8517>.

[RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals",
RFC 8558, DOI 10.17487/RFC8558, April 2019,
<https://www.rfc-editor.org/info/rfc8558>.

[RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to
Deployment (A Bestiary of Roads Not Taken)", RFC 9049,
DOI 10.17487/RFC9049, June 2021,
<https://www.rfc-editor.org/info/rfc9049>.

[RFC9075] Arkko, J., Farrell, S., Kühlewind, M., and C. Perkins,
"Report from the IAB COVID-19 Network Impacts Workshop
2020", RFC 9075, DOI 10.17487/RFC9075, July 2021,
<https://www.rfc-editor.org/info/rfc9075>.

[RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid
Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180,
February 2022, <https://www.rfc-editor.org/info/rfc9180>.

[RFC9217] Trammell, B., "Current Open Questions in Path-Aware
Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022,
<https://www.rfc-editor.org/info/rfc9217>.

[RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)",
STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022,
<https://www.rfc-editor.org/info/rfc9293>.

Authors' Addresses

Tirumaleswar Reddy
Nokia
India
Email: kondtir@gmail.com

Dan Wing
Citrix Systems, Inc.
4988 Great America Pkwy
Santa Clara, CA 95054
United States of America
Email: danwing@gmail.com

Reddy, et al. Expires 12 August 2023 [Page 17]
Internet-Draft Encrypted Explicit Signals to network February 2023

Mohamed Boucadair
Orange
Rennes 35000
France
Email: mohamed.boucadair@orange.com

Reddy, et al. Expires 12 August 2023 [Page 18]

Encrypted Transport Protocol Path Explicit Signals draft-reddy-tsvwg-explcit-signal-00

Encrypted Transport Protocol Path Explicit Signals
draft-reddy-tsvwg-explcit-signal-00