| Internet-Draft | Encrypted Explicit Signals to network | July 2023 |
| Reddy, et al. | Expires 8 January 2024 | [Page] |
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.¶
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.¶
Copyright (c) 2023 IETF Trust and the persons identified as the document authors. All rights reserved.¶
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.¶
[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, 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.¶
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:¶
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:¶
[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:¶
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 [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.¶
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)
+------------------+
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 (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.¶
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.¶
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).¶
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
}
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.¶
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.¶
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 ~
+----------+----------+----------+----------+
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.¶
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
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:¶
+----------+----------+----------+----------+
| Kind=TBA2| 255 | Extended Length |
+----------+----------+----------+----------+
| Key Id Len | kid ~
+----------+----------+----------+----------+
| Nonce Len | Nonce ~
+----------+----------+----------+----------+
| Encrypted UDP options ~
+----------+----------+----------+----------+
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:¶
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).¶
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.¶
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 [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 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 [I-D.ietf-tsvwg-udp-options]:¶
Kind Length Meaning ---------------------------------------------- TBA1 Variable Obfuscated Metadata (OBM) TBA2 Variable Encrypted MetaData (EMD)¶
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¶
TODO¶