An Approach for Encrypted Transport Protocol Path Explicit Signals

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

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 when, and only when, they appear in all capitals, as shown here. This document uses the following (loosely defined) terms: 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 . 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. It is an path signal of metadata that can be seen by authorized on-path network elements examining transport protocols.

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

This document follows the recommendations given by IAB in 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. 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. 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.

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. 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 ). 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. 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: 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 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. 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. HPKE 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 . 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.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 ). 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 depicts the general architecture and message flow for mechanism proposed in the document.

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

The input to this protocol is an HTTPS URI on the network orchestrator that is assumed to have been securely distributed to the endpoints (). 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.

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) or Concise Binary Object Representation (CBOR) payloads are used to convey the explicit signal payload messages and response information, such as errors, random unique identifiers, etc.

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

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 , 'enc' is defined in Section 4.1.2 of , 'kid' is defined in Section 4.1.4 of , and 'exp' is defined in Section 4.1.4 of . A256GCM and other authenticated encryption algorithms are defined in Section 5.1 of . 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.

UDP options that conform to 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.

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

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

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 and it is positioned after the UDP options in the surplus data that do not require encryption.

+--------+---------+----------------------+------------------+ | 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 ]]> The Encrypted MetaData (EMD, Kind=TBA2) option is defined to allow encryption of UDP options carrying sensitive metadata. The shows the EMD 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: Carries the length of the key identifier in octets. 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. Carries the length of the Nonce. Carries the Nonce for the authenticated encryption operation (Section 3.1 of ). 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 ), 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 . 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 . 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).

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

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.

Security considerations that are applicable to UDP options are discussed in Section 22 of . 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 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.

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.

IANA is requested to assign new kinds from the UDP option registry to be set by IANA as per :

The following individuals have contributed to this document:

TODO