Implementing encrypted performance metrics in the Linux kernel is a high-stakes engineering feat. During the AIORI-2 Hackathon, team Optimax from Guru Nanak Institute of Technology successfully developed a working prototype for PDMv2 (draft-ietf-ippm-encrypted-pdmv2), bridging the gap between deep network diagnostics and modern privacy requirements.
By moving from the plaintext metrics of PDMv1 (RFC 8250) to an authenticated encryption model using AES-256-GCM, we’ve demonstrated that IPv6 networks can be both measurable and secure.
1. The Security Evolution: From PDMv1 to PDMv2
While PDMv1 allowed for in-band performance tracking (sequence numbers and timestamps), it left that data exposed to any observer on the path. PDMv2 fixes this by encrypting the metric payload while keeping the header authenticated as Additional Authenticated Data (AAD). This ensures that while routers can see the version and flags, they cannot tamper with the metrics.
2. Technical Implementation: The Kernel Approach
We bypassed user-space implementation to avoid costly context switches. Instead, we built a Linux Kernel Module utilizing the Netfilter framework.
- Hook Point: NF_INET_POST_ROUTING – This allows us to intercept outgoing IPv6 UDP packets just before they hit the wire.
- Cryptography: Integrated the Linux Kernel Crypto API using crypto_alloc_aead(“gcm(aes)”, 0, 0).
- Packet Surgery: Used skb_trim() and skb_put() to dynamically resize packets to fit the encryption nonce and authentication tags.
3. Key Performance & Validation Results
Our implementation was validated using tcpdump and Wireshark, confirming that the AES-GCM tags were correctly appended and that UDP checksums were accurately recomputed for IPv6.
| Metric | Observation | Impact |
|---|---|---|
| Processing Overhead | Minimal | Hardware-accelerated (AES-NI) encryption ensures high throughput. |
| Framing Compliance | 100% | Successfully implemented the 16-byte PDMv2 header as AAD. |
| Integrity Protection | Validated | Any tampering with the ciphertext or header results in a failed GCM tag check. |
| Transparency | High | Works for any UDP flow (tested on port 53) without application changes. |
4. Overcoming Implementation Hurdles
- eBPF vs. Kernel Module: We initially explored eBPF/TC, but the verifier’s strictness regarding variable-length packet modifications made a standard kernel module more viable for complex packet “surgery.”
- The Checksum Challenge: Modifying the payload length in IPv6 requires a mandatory recomputation of the UDP checksum using the IPv6 pseudo-header. We utilized csum_ipv6_magic() to ensure packets weren’t dropped by receiving stacks.
5. Roadmap and IETF Contribution
This project serves as a practical validation for the IPPM Working Group. Our next steps include:
- HPKE Integration (RFC 9180): Moving from manual key parameters to an automated, secure key establishment.
- Extended TLVs: Adding support for RTT, Jitter, and Hop Count metrics within the encrypted envelope.
- Mailing List Feedback: Sharing our “implementation experience” report with the IETF community to refine the draft.
“Seeing the PDMv2 encrypted flags light up in Wireshark for the first time was the highlight of the sprint. It proves that privacy doesn’t have to come at the cost of network visibility.” — Aniruddha Roy, Team Lead
Read the full report
