]> Inside Products, Inc.

United States nalini.elkins@insidethestack.com

BCBS Michigan

United States mackermann@bcbsm.com

NITK Surathkal/Google

India ameyanrd@gmail.com

University of Florence

Italy tommaso.pecorella@unifi.it

Politecnico di Bari

Italy adnan.rashid@poliba.it

University of Florence

Italy lorenzo.fedi3@edu.unifi.it

Transport Internet Engineering Task Force Extension Headers IPv6 PDMv2 Performance Diagnostic RFC8250 describes an optional Destination Option (DO) header embedded in each packet to provide sequence numbers and timing information as a basis for measurements. As this data is sent in clear-text, this may create an opportunity for malicious actors to get information for subsequent attacks. This document defines PDMv2 which has a lightweight handshake (registration procedure) and encryption to secure this data. Additional performance metrics which may be of use are also defined. About This Document The latest revision of this draft can be found at . Status information for this document may be found at . Discussion of this document takes place on the IP Performance Measurement Working Group mailing list (), which is archived at . Subscribe at . Source for this draft and an issue tracker can be found at .

Introduction The current Performance and Destinations Metrics (PDM) is an IPv6 Destination Options header which provides information based on the metrics like Round-trip delay and Server delay. This information helps to measure the Quality of Service (QoS) and to assist in diagnostics. However, there are potential risks involved transmitting PDM data during a diagnostics session. PDM metrics can help an attacker understand about the type of machine and its processing capabilities. For example, the operational capabilities of either the client or server end hosts such as processing speed -- that is, if the system in question is very fast system or an older, slower device. Inferring from the PDM data, the attack can launch a timing attack. For example, if a cryptographic protocol is used, a timing attack may be launched against the keying material to obtain the secret. PDM metrics may also help the attacker find out about the network speed or capabilities of the network path. For example, are there delays or blockages? Are there alternate or multiple paths? Along with this, PDM does not provide integrity. It is possible for a Machine-In-The-Middle (MITM) node to modify PDM headers leading to incorrect conclusions. For example, during the debugging process using PDM header, it can mislead by showing there are no unusual server delays. PDMv2 is an IPv6 Destination Options Extension Header that enhances PDM by adding confidentiality, integrity, and authentication to its measurement data. PDMv2 introduces optional encryption mechanisms to secure the collected data. PDMv2 extends the capabilities of the original PDM by enabling per-session encryption, thereby ensuring data confidentiality and integrity. This encryption is built on the principle of offline decryption, where encrypted data is collected and analyzed after transmission. Real-time or online decryption is possible but not the focus of this specification and is not further analyzed here. PDMv2’s packet format supports per-session encryption with key rotation, where keys are derived from a shared secret established between parties via the base key registration process. All PDMv2 packets are intended to be processed without decryption by intermediate network devices. These encrypted packets can be collected at the client or server end and decrypted offline for diagnostic analysis. This architecture removes the need for real-time decryption at measurement points, improving scalability and deployment simplicity. The procedures specified in RFC8250 for header placement, implementation, security considerations and so on continue to apply for PDMv2.

PDMv2 Foundational Principles The design of PDMv2 adheres to a set of foundational principles which guide its architecture and operational model:

1. Offline Decryption: All decryption of data occurs offline, eliminating the computational overhead of real-time decryption on network devices.
2. Speed of Handshake Processing: The goal of PDMv2 is to have as little time spent in handshake processing as possible.
3. Handshake at IP Layer: The establishment of session keys is at the IP layer not at the transport or session layers. However, keys will be changed when there is a change in the 5-tuple. For ICMP and IPsec, sender-destination IP pair defines the session for key rotation purposes.
4. Separation of Encryption Layers: Encryption at the extension header level is designed to be independent of encryption in higher-layer protocols (e.g., TLS, QUIC). This avoids bootstrapping problems where key negotiation at one layer (IP) is dependent on information from another layer (TCP / TLS).
5. Key Reuse Avoidance: Keys are not reused between sessions. Each session uses a freshly derived key to enhance security and forward secrecy.
6. Base Key Registration: Master keys and device authentication are established through a registration process with an Authentication Server. A complementary draft will detail the full registration procedure and the operation of the Decryption Server that handles offline decryption.
7. Sequential Field for Key Derivation: Each packet may include a sequential field (in cleartext), which serves as input to a key derivation function (KDF). This supports dynamic keying mechanisms such as those used in Hybrid Public Key Encryption (HPKE).
8. Sample Key Derivation Implementation: A sample implementation using HPKE will be included to illustrate how these principles can be applied in practice. Alternative KDFs may be used, based on implementation needs.
9. Optional Sequential Field Usage: A field which may be used as a nonce and is sent in the clear will be provided. Usage of this sequential field is optional and can be omitted if not required for the cryptographic scheme in use. It is required for HPKE but the implementor may choose another scheme.

Conventions used in 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.

PDMv2 Destination Options

Destinations Option Header The IPv6 Destination Options extension header is used to carry optional information that needs to be examined only by a packet's destination node(s). The Destination Options header is identified by a Next Header value of 60 in the immediately preceding header and is defined in RFC 8200 . The IPv6 PDMv2 destination option is implemented as an IPv6 Option carried in the Destination Options header.

Metrics information in PDMv2 The IPv6 PDMv2 destination option contains the following base fields:

• SCALEDTLR: Scale for Delta Time Last Received
• SCALEDTLS: Scale for Delta Time Last Sent
• GLOBALPTR: Global Pointer
• PSNTP: Packet Sequence Number This Packet
• PSNLR: Packet Sequence Number Last Received
• DELTATLR: Delta Time Last Received
• DELTATLS: Delta Time Last Sent

PDMv2 adds a new metric to the existing PDM called the Global Pointer. The existing PDM fields are identified with respect to the identifying information called a "5-tuple". The 5-tuple consists of:

• SADDR: IP address of the sender
• SPORT: Port for the sender
• DADDR: IP address of the destination
• DPORT: Port for the destination
• PROTC: Upper-layer protocol (TCP, UDP, ICMP, etc.)

Unlike PDM fields, Global Pointer (GLOBALPTR) field in PDMv2 is defined for the SADDR type for the node. Two SADDR address types are used:

1. Link-Local
2. Global Unicast

Hence, there are two Global Pointers. The Global Pointer is treated as a common entity over all the 5-tuples with the same SADDR type. It is initialised to the value 1 and increments for every packet sent. Global Pointer provides a measure of the amount of IPv6 traffic sent by the PDMv2 node. When the SADDR type is Link-Local, the PDMv2 node sends Global Pointer defined for Link-Local addresses, and when the SADDR type is Global Unicast, it sends the one defined for Global Unicast addresses. The reason for the Global Pointers is to provide a rough estimation
of the load on the node in question. That is, if the node is sending
many other packets to other destinations at the same time as this
particular session. Given that goal, if we combine the Link Local
and Global Unicast, the traffic traversing the path over the LAN or
VLAN (Link Local) would be combined with the traffic traversing the
path over the internet or wide area network. The nature of Link-
Local and Global Unicast traffic is quite different, hence the two
separate counters.

PDMv2 Layout PDMv2 has two different header formats corresponding to whether the metric contents are encrypted or unencrypted. The difference between the two types of headers is determined from the Options Length value. Following is the representation of the unencrypted PDMv2 header: Following is the representation of the encrypted PDMv2 header:

• Option Type 0x0F 8-bit unsigned integer. The Option Type is adopted from RFC 8250 .
• Option Length 0x22: Unencrypted PDM 0x22: Encrypted PDM 8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields.
• Version Number 0x2 4-bit unsigned number.
• Epoch 12-bit unsigned number. Epoch field is used to indicate the valid SessionTemporaryKey.
• Packet Sequence Number This Packet (PSNTP) 32-bit unsigned number. This field is initialized at a random number and is incremented sequentially for each packet of the 5-tuple. This field + Epoch are used in the Encrypted PDMv2 as the encryption nonce. The nonce MUST NOT be reused in different sessions.
• Packet Sequence Number Last Received (PSNLR) 32-bit unsigned number. This field is the PSNTP of the last received packet on the
  5-tuple.
• Global Pointer 32-bit unsigned number. Global Pointer is initialized to 1 for the different source address types and incremented sequentially for each packet with
  the corresponding source address type. This field stores the Global Pointer type corresponding to the SADDR type of the packet.
• Scale Delta Time Last Received (SCALEDTLR) 8-bit unsigned number. This is the scaling value for the Delta Time Last Sent (DELTATLS) field.
• Scale Delta Time Last Sent (SCALEDTLS) 8-bit unsigned number. This is the scaling value for the Delta Time Last Sent (DELTATLS) field.
• Reserved Bits 16-bits. Reserved bits for future use. They MUST be set to zero on transmission and ignored on receipt per .
• Delta Time Last Received (DELTATLR) 16-bit unsigned integer. The value is set according to the scale in SCALEDTLR. Delta Time Last Received = (send time packet n - receive time packet (n - 1))
• Delta Time Last Sent (DELTATLS) 16-bit unsigned integer. The value is set according to the scale in SCALEDTLS. Delta Time Last Sent = (receive time packet n - send time packet (n - 1))

Terminology

• Endpoint Node: Creates cryptographic keys in collaboration with a partner.
• Client: An Endpoint Node which initiates a session with a listening port on another Endpoint Node and sends PDM data.
• Server: An Endpoint Node which has a listening port and sends PDM data to another Endpoint Node.

Note: a client may act as a server (have listening ports).

• Public and Private Keys: A pair of keys that is used in asymmetric cryptography. If one is used for encryption, the other is used for decryption. Private Keys are kept hidden by the source of the key pair generator, but the Public Key may be known to everyone. In this document, the Public Key is represented as pkX and the Private Key as skX (where X can be any client or server).
• Pre-shared Key (PSK): A symmetric key. Uniformly random bitstring, shared between any Client or any Server or a key shared between an entity that forms client-server relationship. This could happen through an out-of band mechanism: e.g., a physical meeting or use of another protocol.
• Shared Secret: A piece of data, known only to the parties involved.
• SessionTemporaryKey: A temporary key used to secure data for
  only the current session.

Protocol Flow The protocol will proceed in 2 steps.

1. Creation of cryptographic secrets between Server and Client. This includes the creation of pkX and skX.
2. PDM data flow between Client and Server.

These steps MAY be in the same session or in separate sessions. That is, the cryptographic secrets MAY be created beforehand and used in the PDM data flow at the time of the "real" data session. After-the-fact (or real-time) data analysis of PDM flow may occur by network diagnosticians or network devices. The definition of how this is done is out of scope for this document.

Client - Server Negotiation The two entities exchange a set of data to ensure the respective identities. This could be done via a TLS or other session. The exact nature of the identity verification is out-of-scope for this document. They use Hybrid Public-Key Encryption scheme (HPKE) Key Encapsulation Mechanism (KEM) to negotiate a "SharedSecret". Each Client and Server derive a "SessionTemporaryKey" by using HPKE Key Derivation Function (KDF), using the following inputs:

• The "SharedSecret".
• The 5-tuple (SrcIP, SrcPort, DstIP, DstPort, Protocol) of the communication.
• An Epoch.

The Epoch SHOULD be initialized to zero. A change in the Epoch indicates that the SessionTemporaryKey has been rotated. The Epoch MUST be incremented when the Packet Sequence Number This Packet (PSNTP) is rolled over. It MAY be incremented earlier, depending on the implementation and the security considerations. The sender MUST NOT create two packets with identical PSNTP and Epoch. When the Epoch overflows, then collection of PDM data for this session will be stopped. An error message MUST be sent as per
: MessageLimitReachedError: Context AEAD sequence number
overflow.

Implementation Guidelines How should a network administrator decide whether a client should use PDM, unencrypted PDMv2, or encrypted PDMv2? This decision is a network policy issue. The administrator must be aware that PDM or unencrypted PDMv2 might expose too much information to malicious parties. That said, if the network administrator decides that taking such a risk within their network is acceptable, then they should make the decision that is appropriate for their network. Alternatively, the network administrator might choose to create a policy that prohibits the use of PDM or unencrypted PDMv2 on their network. The implementation SHOULD provide a way for the network administrator to enforce such a policy. The server and client implementations SHOULD support PDM, unencrypted PDMv2, and encrypted PDMv2. If a client chooses a certain mechanism (e.g., PDM), the server MAY respond with the same mechanism, unless the network administrator has selected a policy that only allows certain mechanisms on their network.

Use Case 1: Server does not understand PDM or PDMv2 If a client sends a packet with PDM or PDMv2 and the server does not have code which understands the header, the packet is processed according to the Option Type which is defined in RFC8250 and is in accordance with RFC8200. The Option Type identifiers is coded to skip over this option and
continue processing the header.

Use Case 2: Server does not allow PDM Option (PDM or PDMv2) If a client sends a packet with a PDM option which does not match the network policy, then the PDM option MUST be ignored and processing continue normally. The server SHOULD log such occurrences. Filtering at routers per on filtering of IPv6 extension headers may impact the receipt of PDM / PDMv2.

Security Goals As discussed in the introduction, PDM data can represent a serious data leakage in presence of a malicious actor. In particular, the sequence numbers included in the PDM header allows correlating the traffic flows, and the timing data can highlight the operational limits of a server to a malicious actor. Moreover, forging PDM headers can lead to unnecessary, unwanted, or dangerous operational choices, e.g., to restore an apparently degraded Quality of Service (QoS). Due to this, it is important that the confidentiality and integrity of the PDM headers is maintained. PDM headers can be encrypted and authenticated using the methods discussed in Section 5.4, thus ensuring confidentiality and integrity. However, if PDM is used in a scenario where the integrity and confidentiality is already ensured by other means, they can be transmitted without encryption or authentication. This includes, but is not limited to, the following cases:

1. PDM is used over an already encrypted medium (For example VPN tunnels).
2. PDM is used in a link-local scenario.
3. PDM is used in a corporate network where there are security measures strong enough to consider the presence of a malicious actor a negligible risk.

Security Goals for Confidentiality PDM data MUST be kept confidential between the intended parties, which includes (but is not limited to) the two entities exchanging PDM data, and any legitimate party with the proper rights to access such data.

Security Goals for Integrity An implementation SHOULD attempt to detect if PDM data is forged or modified by a malicious entity. In other terms, the implementation should attempt to detect if a malicious entity has generated a valid PDM header impersonating an endpoint or modified a valid PDM header.

Security Goals for Authentication An unauthorized party MUST NOT be able to send PDM data and MUST NOT be able to authorize another entity to do so. Alternatively, if authentication is done via any of the following, this requirement MAY be considered to be met.

1. PDM is used over an already authenticated medium (For example, TLS session).
2. PDM is used in a link-local scenario.
3. PDM is used in a corporate network where security measures are strong enough to consider the presence of a malicious actor a negligible risk.

Cryptographic Algorithm Symmetric key cryptography has performance benefits over asymmetric cryptography; asymmetric cryptography is better for key management. Encryption schemes that unite both have been specified in , and have been participating practically since the early days of public-key cryptography. The basic mechanism is to encrypt the symmetric key with the public key by joining both yields. Hybrid public-key encryption schemes (HPKE) used a different approach that generates the symmetric key and its encapsulation with the public key of the receiver. It is RECOMMENDED to use the HPKE framework that incorporates key encapsulation mechanism (KEM), key derivation function (KDF) and authenticated encryption with associated data (AEAD). These multiple schemes are more robust and significantly more efficient than other schemes. While the schemes may be negotiated between communicating parties, it is RECOMMENDED to use default encryption algorithm for HPKE AEAD as AES-128-GCM.

Security Considerations PDMv2 carries metadata, including information about network characteristics and end-to-end response time. This metadata is used to optimize communication. However, in the context of passive attacks, the information contained within PDMv2 packets can be intercepted by an attacker, and in the context of active attacks the metadata can be modified by an attacker. In the following we will briefly outline the threat model and the associated security risks, using RFC3552 terminology and classification.

Limited Threat Model We assume that the attacker does not control the endpoints, but it does have a limited control of the network, i.e., it can either monitor the communications (leading to passive attacks), or modify/forge packets (active attacks).

Passive attacks with unencrypted PDMv2 Passive Attack Scenario: In a passive attack, the attacker seeks to obtain information that the sender and receiver of the communication would prefer to keep private. In this case, the attacker is not altering the packets but is intercepting and analyzing them. Here's how this can happen in the context of unencrypted PDMv2:

1. Being on the same LAN: The simplest way for an attacker to launch a passive attack is to be on the same Local Area Network (LAN) as the victim. Many LAN configurations, such as Ethernet, 802.3, and FDDI, allow any machine on the network to read all traffic destined for any other machine on the same LAN. This means that if PDM packets are sent over the LAN, the attacker can capture them.
2. Control of a Host in the Communication Path: If the attacker has control over a host that lies in the communication path between two victim machines, they can intercept PDM packets as they pass through this compromised host. This allows the attacker to collect metadata without being on the same LAN as the victim.
3. Compromising Routing Infrastructure: In some cases, attackers may actively compromise the routing infrastructure to route traffic through a compromised machine. This can facilitate a passive attack on victim machines. By manipulating routing, the attacker can ensure that PDMv2 packets pass through their controlled node.
4. Wireless Networks: Wireless communication channels, such as those using 802.11 (Wi-Fi), are particularly vulnerable to passive attacks. Since data is broadcast over well-known radio frequencies, an attacker with the ability to receive those transmissions can intercept PDMv2 packets. Weak or ineffective cryptographic protection in wireless networks can make it easier for attackers to capture this data.

Goal of Passive Attack: In a passive attack, the attacker's goal is to obtain sensitive information from intercepted packets. In the case of PDMv2, this information may include network characteristics, end-to-end response times, and potentially any other metadata that is transmitted. This information can be valuable to the attacker for various purposes, such as analyzing network performance or gaining insights into communication patterns. In summary, within the limited Internet threat model described in RFC3552, attackers with the ability to intercept packets can conduct passive attacks to capture metadata carried in IPv6 unencrypted PDMv2 packets. This information can be useful for the attacker, even without actively altering the communication. Security measures, such as encryption and network segmentation, are important countermeasures to protect against such passive attacks.

Passive attacks with encrypted PDMv2 Passive Attack Scenario: An attacker is trying to seek useful information from encrypted PDMv2 packets happening between two different entities. Encrypted PDMv2 has most of the metadata fields encrypted except for PSNTP which is also used as a nonce in HPKE AEAD. Goal of Passive Attack: In this attack, the attacker is trying to obtain the order in which the packets were sent from the sender to the receiver for different flows. The amount of information gathered by the attacker is similar, to some extent, to the ones available by inspecting the TTCP sequence number, which is also usually not protected. Therefore, we consider this information leak acceptable. Nevertheless, this point should be noted if complete traffic obfuscation (including packet reordering) is necessary. In these cases it is suggested to use IPSec ESP in tunnel mode (in which case the PDMv2 can be used unencrypted).

Active attacks with unencrypted PDMv2 There are also active attacks within the context of the limited Internet threat model defined in . In this model, active attacks involve an attacker writing data to the network, and the attacker can forge packets and potentially manipulate the behavior of devices or networks. Let's break down how message modification, deletion, or insertion by attackers using the unencrypted IPv6 Performance and Destination option v2 (PDMv2) fits into this threat model:

1. Message Modification Attack: In a message modification attack, the attacker intercepts a message, modifies its content, and then reinserts it into the network. This attack is significant because it allows the attacker to tamper with the integrity of the data being transmitted. Example: Suppose an attacker intercepts an IPv6 packet containing unencrypted PDMv2 information that includes network and end-to-end response time metadata. The attacker modifies this information, such as altering the response time data or inserting false information. When this modified packet reaches its destination, the receiving device or network may act based on this malicious information, potentially leading to degraded performance, incorrect network management decisions, wrong performance data collection, etc. A direct consequence of modifying the performance data could be, for example, to hide an ongoing QoS violation, or to create a fake QoS violation, with consequences on the violation of Service Level Agreements.
2. Message Deletion Attack: In a message deletion attack, the attacker removes a message from the network. This attack can be used in conjunction with other attacks to disrupt communication or achieve specific objectives. Example: Consider a scenario where an attacker deletes certain IPv6 packets that contain unencrypted PDMv2 information, or deletes the PDM header from the packet. If the PDMv2 is used for network monitoring or quality of service (QoS) management, the deletion of these packets can cause the monitoring system to miss critical data, potentially leading to inaccurate network performance analysis or decisions.
3. Message Insertion Attack: In a message insertion attack, the attacker forges a message and injects it into the network. Example: An attacker could forge IPv6 packets containing unencrypted PDMv2 data with fake source addresses and inject them into the network. If PDM is used for making routing or resource allocation decisions, these injected packets can influence the network's behavior, potentially causing it to take suboptimal routes or allocate resources incorrectly.

All these attacks are considered active attacks because the attacker actively manipulates network traffic, and they can potentially spoof the source address to disguise their identity. In the limited Internet threat model defined in , it is assumed that attackers can forge packets and carry out such active attacks. These attacks highlight the importance of securing network protocols, authenticating messages, and implementing proper security measures to protect against them.

Active attacks with encrypted PDMv2 Encrypted PDMv2 provides inherent protection against active attacks like Message Modification by providing integrity. If either of the sequence number or encrypted PDMv2 contents are modified then decryption will fail. Message Deletion Attack can be performed for encrypted PDMv2 similarly to unencrypted PDMv2. Impersonation Attack: Encrypted PDMv2 relies on a shared secret negotiated by an external protocol (e.g., TLS). If key exchange does have authentication check, then an adversary who impersonates the host can derive a key with the destination client and potentially perform all the above active attacks even on encrypted PDMv2.

Topological considerations The same topological considerations highlighted in applies in this context. Passive attacks and active attacks where the messages need to be modified or deleted are more likely if the attacker is on-path, while message insertion attacks are more likely when the attacker is off-path but can happen also when the attacker is on-path. Link-local attacks can be considered as a special case of on-path for PDM, i.e., for PDM a link-local attacker has no special privileges with respect to an on-path attacker.

Further mitigations PDM includes cryptographic mechanisms to mitigate passive and active attacks. As a further security mechanism to protect from active attacks, it is possible for an implementation to include logging of anomalous events, e.g.:

• Missing PDM header when expected (counteracts the Message Deletion).
• Unusual variations of the PDM data (counteracts the Message Modification)
• Accept the PDM data only if the application level accepts the packet payload (counteracts the Message Insertion)
• Monitor repeated or unexpected PDM data (counteracts replay attacks).

Security considerations about HPKE are addressed in RFC 9180. Security considerations about PDM are addressed in RFC 8250. Security considerations about destination objects are addressed in RFC 8200.

Privacy Considerations Encryption plays a crucial role in providing privacy as defined by , especially when metadata sniffing is a concern. , titled "Privacy Considerations for Internet Protocols," outlines the importance of protecting users' privacy in the context of various Internet protocols, including IPv6. When metadata like network and end-to-end response time is at risk of being observed by attackers, eavesdroppers, or observers, encryption can help mitigate the privacy risks. Here's how encryption achieves this:

1. Confidentiality: Encryption ensures that the actual content of the communication remains confidential. Even if attackers or observers intercept the data packets, they won't be able to decipher the information without the encryption key. In the case of IPv6 Performance and Destination Option (PDM), the still-visible, non-encrypted metadata is still visiblenegligible, and does not poses confidentiality
2. Content Protection: Metadata, such as network and end-to-end response time, may reveal sensitive information about the communication. By encrypting the content, encryption mechanisms help protect this sensitive data from being exposed. Observers may still see that communication is happening, but they won't be able to glean meaningful information from the metadata.
3. Integrity: Encryption often includes mechanisms to ensure data integrity. It allows the recipient to verify that the received data has not been tampered with during transit. This helps protect against attackers who might try to manipulate the metadata.

It's important to note that while encryption enhances privacy by protecting the content of communication, metadata still poses some challenges. Metadata, such as the fact that communication is occurring and the parties involved, can be revealing. To address this, additional techniques, like traffic obfuscation, may be used to hide metadata patterns. However, complete metadata privacy can be challenging to achieve, especially when communication protocols inherently require some level of metadata exchange. Specifically, enabling PDM only for a specific set of flows can pose a risk of highlighting their presence between two parties. As a mitigation technique, it is suggested to obfuscate the events, for example by enabling PDM on more flows than strictly necessary.

IANA Considerations No action is needed by IANA.

Contributors The authors wish to thank NITK Surathkal for their support and assistance in coding and review. In particular Dr. Mohit Tahiliani and Abhishek Kumar (now with Google). Thanks also to Priyanka Sinha for her comments. Thanks to the India Internet Engineering Society (iiesoc.in), in particular Dhruv Dhody, for his comments and for providing the funding for servers needed for protocol development. Thanks to Balajinaidu V, Amogh Umesh, and Chinmaya Sharma of NITK for developing the PDMv2 implementation for testing.

References Normative References All RFCs are required to have a Security Considerations section. Historically, such sections have been relatively weak. This document provides guidelines to RFC authors on how to write a good Security Considerations section. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. To assess performance problems, this document describes optional headers embedded in each packet that provide sequence numbers and timing information as a basis for measurements. Such measurements may be interpreted in real time or after the fact. This document specifies the Performance and Diagnostic Metrics (PDM) Destination Options header. The field limits, calculations, and usage in measurement of PDM are included in this document. This document specifies version 6 of the Internet Protocol (IPv6). It obsoletes RFC 2460. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Informative References This document describes a scheme for hybrid public key encryption (HPKE). This scheme provides a variant of public key encryption of arbitrary-sized plaintexts for a recipient public key. It also includes three authenticated variants, including one that authenticates possession of a pre-shared key and two optional ones that authenticate possession of a key encapsulation mechanism (KEM) private key. HPKE works for any combination of an asymmetric KEM, key derivation function (KDF), and authenticated encryption with additional data (AEAD) encryption function. Some authenticated variants may not be supported by all KEMs. We provide instantiations of the scheme using widely used and efficient primitives, such as Elliptic Curve Diffie-Hellman (ECDH) key agreement, HMAC-based key derivation function (HKDF), and SHA2. This document is a product of the Crypto Forum Research Group (CFRG) in the IRTF. This document describes an updated version of the Encapsulating Security Payload (ESP) protocol, which is designed to provide a mix of security services in IPv4 and IPv6. ESP is used to provide confidentiality, data origin authentication, connectionless integrity, an anti-replay service (a form of partial sequence integrity), and limited traffic flow confidentiality. This document obsoletes RFC 2406 (November 1998). [STANDARDS-TRACK] This document defines message encryption and authentication procedures, in order to provide privacy-enhanced mail (PEM) services for electronic mail transfer in the Internet. [STANDARDS-TRACK] This document offers guidance for developing privacy considerations for inclusion in protocol specifications. It aims to make designers, implementers, and users of Internet protocols aware of privacy-related design choices. It suggests that whether any individual RFC warrants a specific privacy considerations section will depend on the document's content. This document analyzes the security implications of IPv6 Extension Headers and associated IPv6 options. Additionally, it discusses the operational and interoperability implications of discarding packets based on the IPv6 Extension Headers and IPv6 options they contain. Finally, it provides advice on the filtering of such IPv6 packets at transit routers for traffic not directed to them, for those cases where such filtering is deemed as necessary.

Sample Implementation of Registration

Overall summary In the Registration phase, the objective is to generate a shared secret that will be used in encryption and decryption during the Data Transfer phase. How this is to be done is left to the implementation.

High level flow The following steps describe the protocol flow:

1. Client initiates a request to the Server. The request contains a list of available ciphersuites for KEM, KDF, and AEAD.
2. Server responds to the Client with one of the available ciphersuites and shares its pkX.
3. Client generates a secret and its encapsulation. The Client sends the encapsulation and a salt to the Server. The salt is required during KDF in the Data Transfer phase.
4. Server generates the secret with the help of the encapsulation and responds with a status message.

Change Log Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC.

Open Issues Note to RFC Editor: please remove this appendix before publication as an RFC.