| Internet-Draft | draft-ietf-ippm-encrypted-pdmv2 | July 2026 |
| Elkins, et al. | Expires 22 January 2027 | [Page] |
RFC 8250 defines an IPv6 Destination Option that carries Performance and Diagnostic Metrics (PDM) such as sequence numbers and timing information. While useful for measurement and troubleshooting, clear-text PDM data may expose operational characteristics of endpoints and networks.¶
This document defines PDMv2, a revised version of PDM that introduces a registration-based security model. Instead of specifying cryptographic algorithms or inline key negotiation, PDMv2 relies on a prior registration process to authenticate entities, authorize participation, and establish shared secrets. These secrets are then used by endpoints and authorized analyzers to protect and interpret PDMv2 data according to local policy.¶
This document specifies the PDMv2 semantics, header structure, and operational model. Cryptographic algorithms, key derivation functions, and cipher negotiation are explicitly out of scope.¶
This note is to be removed before publishing as an RFC.¶
The latest revision of this draft can be found at https://ameyand.github.io/PDMv2/draft-elkins-ippm-encrypted-pdmv2.html. Status information for this document may be found at https://datatracker.ietf.org/doc/draft-ietf-ippm-encrypted-pdmv2/.¶
Discussion of this document takes place on the IP Performance Measurement Working Group mailing list (mailto:ippm@ietf.org), which is archived at https://mailarchive.ietf.org/arch/browse/ippm/. Subscribe at https://www.ietf.org/mailman/listinfo/ippm/.¶
Source for this draft and an issue tracker can be found at https://github.com/ameyand/PDMv2.¶
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 22 January 2027.¶
Copyright (c) 2026 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.¶
The Performance and Diagnostic Metrics (PDM) Destination Option defined in RFC 8250 provides packet sequence numbers and timing information to support performance measurement and diagnostics. While effective, transmitting such information in clear text can reveal details about endpoint behavior, processing capability, and network characteristics.¶
PDMv2 enhances PDM by enabling secure operation through a registration-first architecture. Security-sensitive material is established out of band, prior to data transmission, and is not negotiated inline with PDMv2 traffic. This approach preserves the lightweight nature of PDM while avoiding tight coupling to transport-layer security protocols.¶
PDMv2 operates entirely at the IPv6 layer and applies uniformly to TCP, UDP, ICMP, QUIC, and other upper-layer protocols. Intermediate devices are not required to decrypt or interpret PDMv2 contents.¶
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.¶
PDMv2 is designed with the following goals:¶
Maintain compatibility with the operational model of RFC 8250¶
Avoid inline cryptographic handshakes at the IP layer¶
Support heterogeneous transport protocols and non-transport flows¶
Enable offline analysis by authorized entities¶
Integrate cleanly with existing authentication and authorization infrastructures¶
PDMv2 adheres to the following foundational principles:¶
Registration-First Security: All security context used by PDMv2 is established during a prior registration phase. No cryptographic negotiation occurs during PDMv2 packet exchange.¶
IP-Layer Independence: PDMv2 security does not depend on TCP, TLS, QUIC, or any specific transport protocol.¶
Minimal On-Path Impact: Routers and intermediate nodes forward PDMv2 packets without decryption or inspection.¶
Offline Decryption and Analysis: PDMv2 data MAY be collected and analyzed after transmission. Real-time interpretation is optional and deployment-specific.¶
Separation of Specification Scope: This document defines protocol behavior and data formats, not cryptographic algorithms.¶
Explicit Authorization: Only registered and authorized entities may emit, receive, or analyze protected PDMv2 data.¶
PDMv2 relies on an external registration system to establish trust and shared context between participating entities.¶
A registration system used with PDMv2 MUST:¶
The following logical roles are assumed:¶
Client : An endpoint that initiates communication and emits PDMv2 data¶
Server : An endpoint that receives communication and emits PDMv2 data¶
Authentication Server (AS) : A trusted entity that performs authentication and authorization¶
Analyzer : An authorized entity that interprets collected PDMv2 data¶
An implementation MAY combine roles within a single system.¶
The registration exchange MUST be protected by a secure channel. The choice of transport and security protocol is out of scope for this document.¶
PDMv2 is carried as an IPv6 Destination Option within the Destination Options Header as defined in RFC 8200. Processing rules from RFC 8250 continue to apply unless explicitly updated by this document.¶
PDMv2 supports the following metrics:¶
Packet Sequence Number (This Packet)¶
Packet Sequence Number (Last Received)¶
Delta Time Last Received¶
Delta Time Last Sent¶
Global Pointer¶
These metrics have the same semantics as in RFC 8250, with the addition of the Global Pointer.¶
The Global Pointer provides a coarse indicator of packet transmission activity by an endpoint. Separate counters are maintained for link-local and global unicast source addresses.¶
PDMv2 uses a single header format. Whether metric contents are protected or unprotected is determined by local policy and registration context.¶
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | Version | Epoch |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Sequence Number (This) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Packet Sequence Number (Last) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Global Pointer |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ScaleDTLR | ScaleDTLS | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Delta Time Last Received | Delta Time Last Sent |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
¶
0x0F¶
8-bit unsigned integer. The Option Type is adopted from RFC 8250 [RFC8250].¶
0x22: Unencrypted PDM¶
0x22: Encrypted PDM¶
8-bit unsigned integer. Length of the option, in octets, excluding the Option Type and Option Length fields.¶
0x2¶
4-bit unsigned number.¶
12-bit unsigned number.¶
Epoch field is used to indicate the valid SessionTemporaryKey.¶
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.¶
32-bit unsigned number.¶
This field is the PSNTP of the last received packet on the 5-tuple.¶
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.¶
8-bit unsigned number.¶
This is the scaling value for the Delta Time Last Sent (DELTATLS) field.¶
8-bit unsigned number.¶
This is the scaling value for the Delta Time Last Sent (DELTATLS) field.¶
16-bits.¶
Reserved bits for future use. They MUST be set to zero on transmission and ignored on receipt per [RFC3552].¶
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))¶
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))¶
Prior to sending PDMv2 data:¶
PDMv2 reduces exposure of sensitive operational metadata by ensuring that only registered and authorized entities can meaningfully interpret measurement data.¶
This document intentionally does not specify cryptographic mechanisms. Security strength therefore depends on the chosen registration system, its authentication methods, and its key management practices.¶
Implementations SHOULD support:¶
PDMv2 metrics may reveal traffic patterns or operational characteristics. Registration-based authorization limits access to such data to approved entities. Deployments SHOULD consider enabling PDMv2 on multiple flows to reduce metadata distinguishability.¶
This document requests the allocation of a new IPv6 Destination Options Header Option Type from the "Destination Options and Hop-by- Hop Options" registry maintained by the Internet Assigned Numbers Authority.¶
The requested allocation is for the Performance and Diagnostic Metrics Version 2 (PDMv2) option. This option is distinct from and independent of the Performance and Diagnostic Metrics option defined in RFC 8250.¶
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.¶
This appendix illustrates one possible registration mechanism that satisfies the requirements defined in Section 4. Other mechanisms may be used.¶
This appendix describes an example registration system for PDMv2 based on RADIUS with Extensible Authentication Protocol (EAP). This approach has been implemented and validated in a prototype environment and demonstrates that a shared master secret can be established prior to PDMv2 operation without introducing inline cryptographic negotiation at the IP layer.¶
RADIUS and EAP are widely deployed for Authentication, Authorization, and Accounting (AAA) in enterprise, service provider, and federated environments (e.g., eduroam). Their use here is illustrative and leverages existing infrastructure and operational experience.¶
The following entities participate in this example:¶
PDMv2 Endpoint¶
A Client or Server that will emit or receive PDMv2 data.¶
Authentication Server (AS)¶
A RADIUS server that performs authentication and authorization using EAP.¶
Analyzer¶
An authorized entity that may interpret or decrypt collected PDMv2 data using registration-derived context.¶
An implementation MAY combine multiple roles within a single system.¶
A typical registration flow proceeds as follows:¶
Secure Channel Establishment The PDMv2 endpoint establishes a secure exchange with the Authentication Server. In many deployments this occurs implicitly as part of an EAP method protected by TLS (e.g., EAP-TLS or PEAP).¶
Endpoint Authentication The endpoint authenticates using credentials appropriate to the deployment, such as certificates, credentials, tokens, or federated identity.¶
Authorization Decision The Authentication Server determines whether the endpoint is authorized to:¶
Master Secret Establishment Upon successful authentication, EAP produces keying material (e.g., a Master Session Key). This keying material is made available to the endpoint and retained by the Authentication Server according to local policy.¶
Provisioning of Context The endpoint associates the received master secret with local PDMv2 policy, such as permitted peers, scope, and lifetime.¶
Analyzer Enablement (Optional) If offline analysis is required, the Authentication Server provisions appropriate authorization or keying context to approved analyzers.¶
The following diagram illustrates the example flow. It is provided for clarity only and does not define protocol behavior.¶
PDMv2 Endpoint Authentication Server Analyzer | | | |--- EAP Authentication -----> | | |<-- EAP Success / Keys ------ | | | | | | (Registration Complete) | | | | | |====== PDMv2 Data Flow =====> | (out of path) | | | | | |------- Authorized Access ---->| | |<------ Analysis Results ------|¶
After registration:¶
PDMv2 packets are sent without any inline authentication or negotiation.¶
Endpoints locally derive any session-specific context needed to protect or interpret PDMv2 metrics.¶
Intermediate routers forward packets without modification or inspection.¶
Analyzers use registration-derived context to interpret collected data.¶
The registration system is not involved in the PDMv2 data path.¶
In this example, the RADIUS/EAP infrastructure can support:¶
Periodic re-registration to refresh secrets¶
Revocation of authorization by disabling credentials¶
Federation across administrative domains¶
Separation of endpoint and analyzer privileges¶
Specific key derivation, transformation, or protection mechanisms are implementation-specific and intentionally outside the scope of this document.¶
In federated environments such as global research and education networks, RADIUS is commonly deployed in a hierarchical or proxy-based architecture. An endpoint authenticates using credentials issued by its home organization, while authorization decisions may be enforced by visited or intermediate domains.¶
This model maps naturally to PDMv2 registration:¶
Endpoints authenticate using existing institutional credentials¶
Authorization for PDMv2 usage can be scoped by domain, role, or policy¶
Registration secrets are derived without requiring bilateral agreements between all participating domains¶
This example demonstrates that PDMv2 registration can scale across organizational and administrative boundaries.¶
It may appear attractive to reuse TLS session keys for protecting PDMv2 metrics. However, this approach is not suitable for PDMv2 for several reasons:¶
Layering : PDMv2 operates at the IPv6 layer, while TLS is bound to transport-layer protocols such as TCP or QUIC.¶
Protocol Coverage : PDMv2 applies equally to UDP, ICMP, and other non-TLS-capable protocols.¶
Multiplicity of Flows : A single endpoint may emit PDMv2 data for multiple concurrent flows that do not share a common TLS session.¶
Analyzer Access : Offline analyzers may require access to PDMv2 data without participating in live TLS sessions.¶
Operational Simplicity : Registration decouples security establishment from traffic patterns and avoids inline negotiation complexity.¶
For these reasons, PDMv2 adopts a registration-based security model rather than reusing transport-layer session keys.¶
This appendix demonstrates that a RADIUS/EAP-based registration system can satisfy the PDMv2 registration requirements defined in this document. The example shows that secure, scalable, and federated registration can be achieved using existing AAA infrastructure, without constraining PDMv2 to a specific authentication or cryptographic technology.¶
Note to RFC Editor: if this document does not obsolete an existing RFC, please remove this appendix before publication as an RFC.¶
Note to RFC Editor: please remove this appendix before publication as an RFC.¶