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. Copyright Notice Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved. 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 +----------+----------+----------+----------+ | Kind=TBA2| 255 | Extended Length | +----------+----------+----------+----------+ | Key Id Len | kid ~ +----------+----------+----------+----------+ | Nonce Len | Nonce ~ +----------+----------+----------+----------+ | Encrypted UDP options ~ +----------+----------+----------+----------+ 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: +----------+----------+----------+----------+ | Kind=TBA3| 255 | Extended Length | +----------+----------+----------+----------+ | Key Identifier | Algorithm | +----------+----------+----------+----------+ | KEM Identifier | +----------+----------+----------+----------+ | KDF Identifier | +----------+----------+----------+----------+ | Key Len | Public Key ~ +----------+----------+----------+----------+ | Encrypted UDP options ~ +----------+----------+----------+----------+ 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, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC5116] McGrew, D., "An Interface and Algorithms for Authenticated Encryption", RFC 5116, DOI 10.17487/RFC5116, January 2008, . [RFC7515] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Signature (JWS)", RFC 7515, DOI 10.17487/RFC7515, May 2015, . [RFC7516] Jones, M. and J. Hildebrand, "JSON Web Encryption (JWE)", RFC 7516, DOI 10.17487/RFC7516, May 2015, . 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, . [RFC7519] Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token (JWT)", RFC 7519, DOI 10.17487/RFC7519, May 2015, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, . [RFC8259] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", STD 90, RFC 8259, DOI 10.17487/RFC8259, December 2017, . 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, . [MDM-Apple] Apple, "Mobile Device Management", . [OTA] Apple, "Over-the-Air Profile Delivery Concepts", . [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, . [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an Attack", BCP 188, RFC 7258, DOI 10.17487/RFC7258, May 2014, . 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, . [RFC8558] Hardie, T., Ed., "Transport Protocol Path Signals", RFC 8558, DOI 10.17487/RFC8558, April 2019, . [RFC9049] Dawkins, S., Ed., "Path Aware Networking: Obstacles to Deployment (A Bestiary of Roads Not Taken)", RFC 9049, DOI 10.17487/RFC9049, June 2021, . [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, . [RFC9180] Barnes, R., Bhargavan, K., Lipp, B., and C. Wood, "Hybrid Public Key Encryption", RFC 9180, DOI 10.17487/RFC9180, February 2022, . [RFC9217] Trammell, B., "Current Open Questions in Path-Aware Networking", RFC 9217, DOI 10.17487/RFC9217, March 2022, . [RFC9293] Eddy, W., Ed., "Transmission Control Protocol (TCP)", STD 7, RFC 9293, DOI 10.17487/RFC9293, August 2022, . 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]