reddy-tsvwg-explcit-signal-01.txt

Internet DRAFT - draft-reddy-tsvwg-explcit-signal

draft-reddy-tsvwg-explcit-signal

Last Version:	draft-reddy-tsvwg-explcit-signal-01.txt	Tracker Entry
Date:	`09-Jul-2023`
Disposition:	expired
Previous Versions:	draft-reddy-tsvwg-explcit-signal-00.txt (diff) - 10-Feb-2023

TSVWG WG T. Reddy
Internet-Draft Nokia
Intended status: Standards Track D. Wing
Expires: 8 January 2024 Citrix
M. Boucadair
Orange
7 July 2023

An Approach for Encrypted Transport Protocol Path Explicit Signals
draft-reddy-tsvwg-explcit-signal-01

Abstract

This document defines a mechanism for endpoints to explicitly signal
encrypted metadata to the network, and the network to signal its
ability to accommodate that metadata back to the endpoints. This
mechanism can be used where the endpoints desire that some 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 8 January 2024.

Reddy, et al. Expires 8 January 2024 [Page 1]

Internet-Draft Encrypted Explicit Signals to network July 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) . . . . . . . . . . . . . . . . 10
7.2. Encrypted MetaData (EMD) . . . . . . . . . . . . . . . . 10
8. Provisioning Endpoints . . . . . . . . . . . . . . . . . . . 12
9. System Operation . . . . . . . . . . . . . . . . . . . . . . 12
10. Security Considerations . . . . . . . . . . . . . . . . . . . 12
11. Privacy Considerations . . . . . . . . . . . . . . . . . . . 13
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 14
14. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14
15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
15.1. Normative References . . . . . . . . . . . . . . . . . . 14
15.2. Informative References . . . . . . . . . . . . . . . . . 15
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 16

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 8 January 2024 [Page 2]

Internet-Draft Encrypted Explicit Signals to network July 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 8 January 2024 [Page 3]

Internet-Draft Encrypted Explicit Signals to network July 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 8 January 2024 [Page 4]

Internet-Draft Encrypted Explicit Signals to network July 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]).

An 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:

Metadata conveyance and associated random identifier assignment to
network elements: An endpoint conveys the metadata it would like to
convey to the network elements (for specific flows) to a network
orchestrator and receives a random unique identifier (128-bit, for
example) for each of the metadata. The endpoints then conveys the

Reddy, et al. Expires 8 January 2024 [Page 5]

Internet-Draft Encrypted Explicit Signals to network July 2023

random unique identifiers in an UDP option and only authorized
network elements will be able to correlate the metadata. For
instance, a network orchestrator can push the metadata and
corresponding random unique identifiers to authorized network
elements to process the random unique identifiers shared by
endpoints. If the application knows all the possible metadata it
would like to convey to a 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.

Symmetric key encryption and decryption of metadata: The endpoint
gets a symmetric key from the network orchestrator and uses it to
encrypt the metadata in an explicit signal. 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.

This design approach has some drawbacks in comparison with the
previous approach as it would require the endpoint to encrypt the
metadata conveyed in the packet. Network elements would have to
decrypt the metadata present in the packet.

Hybrid public-key encryption (HPKE) and decryption of metadata: 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's 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.
Asymmetric cryptographic computation per packet is more
computationally expensive compared to the first and second
mechanisms.

Reddy, et al. Expires 8 January 2024 [Page 6]

Internet-Draft Encrypted Explicit Signals to network July 2023

An optimization might be to not generate the ephemeral public/
private key pair on each UDP packet conveying the explicit signal.
However, using static public/private key pair for multiple packets
will result in weaker data origination of the metadata.

The last mechanism is not further elaborated due to the significant
overhead in comparison with the first two mechanisms. Note that care
must be taken to ensure that adding the obfuscated or encrypted
metadata to the UDP option does not result in a datagram size that
exceeds the Path MTU.

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 shown in Figure 1 depicts the general architecture and
message flow for mechanism proposed in the document.

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

Reddy, et al. Expires 8 January 2024 [Page 7]

Internet-Draft Encrypted Explicit Signals to network July 2023

Figure 1

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

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

Endpoints send the HTTP PUT request to an orchestrator to convey the
metadata to be shared with the network. The orchestrator indicates
in a response whether it is able to parse the metadata or not. For
example, if an 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] or Concise Binary Object Representation (CBOR) [RFC8949]
payloads are used to convey the explicit signal payload messages and
response information, such as errors, random unique identifiers, etc.

6.2. Key Establishment

Endpoints and network orchestrators can choose to use
Representational State Transfer (REST) API over HTTPS to establish a
symmetric key. HTTPS can 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 8 January 2024 [Page 8]

Internet-Draft Encrypted Explicit Signals to network July 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
}

Figure 2

An 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.

Reddy, et al. Expires 8 January 2024 [Page 9]

Internet-Draft Encrypted Explicit Signals to network July 2023

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.

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

Figure 3: 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 4 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 4: Integrity-protected and Encrypted UDP options

Reddy, et al. Expires 8 January 2024 [Page 10]

Internet-Draft Encrypted Explicit Signals to network July 2023

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

Figure 5: 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 8 January 2024 [Page 11]

Internet-Draft Encrypted Explicit Signals to network July 2023

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. System Operation

By signaling metadata as a UDP trailer, the metadata can survive
across the Internet and still be received, unaltered, at a remote
network where the metadata can assist with network management,
debugging, or the ability of networks to optimize their services.
The integrity of conveyed signal is ensured by the relevant UDP
options.

This metadata is not expected to be processed across transit networks
where there is little -- if any -- opportunity for differentiated
packet treatment anyway. For example, a transit network is unlikely
to make a decision for a packet (or a flow of packets) to take a
terrestrial link or a (high latency) satellite link. Rather, such a
decision is more likely to occur at the network near the sender --
which can process the metadata signaled with this specification.

10. 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.

Reddy, et al. Expires 8 January 2024 [Page 12]

Internet-Draft Encrypted Explicit Signals to network July 2023

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
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 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 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.

11. 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.

Reddy, et al. Expires 8 January 2024 [Page 13]

Internet-Draft Encrypted Explicit Signals to network July 2023

12. 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)

13. 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

14. Acknowledgments

TODO

15. References

15.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-22,
9 June 2023, <https://datatracker.ietf.org/doc/html/draft-
ietf-tsvwg-udp-options-22>.

[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>.

Reddy, et al. Expires 8 January 2024 [Page 14]

Internet-Draft Encrypted Explicit Signals to network July 2023

[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>.

[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>.

15.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>.

Reddy, et al. Expires 8 January 2024 [Page 15]

Internet-Draft Encrypted Explicit Signals to network July 2023

[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>.

[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>.

[RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object
Representation (CBOR)", STD 94, RFC 8949,
DOI 10.17487/RFC8949, December 2020,
<https://www.rfc-editor.org/info/rfc8949>.

[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

Reddy, et al. Expires 8 January 2024 [Page 16]

Internet-Draft Encrypted Explicit Signals to network July 2023

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

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

Reddy, et al. Expires 8 January 2024 [Page 17]