[Tsv-art] Re: [ippm] draft-ietf-ippm-encrypted-pdmv2-14 early Tsvart review

["[e-mail]" <[e-mail]>]

Yoshifumi and TSV-ART,

Thank you for the review of draft-ietf-ippm-encrypted-pdmv2. We found the comments helpful and have prepared revisions addressing all eight points.   We will be posting the revisions soon and look forward to your comments.
   
   -    
Option Type


The new revision will request a new IPv6 Option Type for PDMv2. It does not reuse or redefine the RFC 8250 PDM Option Type 0x0F. We have retained TBD1 in the wire-format diagrams until IANA assigns the value and have clarified that fields “adopted from RFC 8250” retain related semantics but not the RFC 8250 Option Type.
   
   -    
Option Length


We will correct the  unprotected Option Length to 22 decimal, encoded as 0x16. The complete option, including the Option Type and Option Length octets, is 24 octets.
   
   -    
Protected and unprotected formats


We will define separate on-wire formats.

The unprotected format has Option Length 22 decimal (0x16). The protected format has Option Length 38 decimal (0x26) and a total size of 40 octets, assuming the required 16-octet authentication tag.

The Option Length therefore provides an inbound indication of whether the metric block is protected. A receiver does not need to infer the format solely from local policy or registration context. Registration context is still required to decrypt and interpret a protected metric block.
   
   -    
SessionTemporaryKey


We will add a definition of SessionTemporaryKey and specified the security context that a successful registration must provide. The registration mechanism or protection-suite specification must define the key derivation or provisioning procedure, algorithm, key length, Epoch association, scope, lifetime, rekey procedure, and expiration or revocation behavior.

When a key is derived from a master secret, the derivation must use a secure key-derivation function with a PDMv2-specific purpose label. A PDMv2 key must not be a TLS, QUIC, IPsec, or other traffic key.
   
   -    
ICMPv6 flow identification


We will replace the unconditional use of “5-tuple” with a PDMv2 flow definition.

TCP and UDP use the IPv6 addresses, upper-layer protocol number, and port numbers. ICMPv6 uses the IPv6 addresses, ICMPv6 Next Header value, Type, and Code. Where an ICMPv6 Identifier exists, implementations should also use it to distinguish concurrent exchanges.

Other protocols without ports may define an equivalent stable discriminator. If none exists, the IPv6 source address, IPv6 destination address, and upper-layer protocol number identify the PDMv2 flow.
   
   -    
TCP retransmission


We will clarify that PSNTP is incremented for each packet processed as a new transmission at the PDMv2 sender’s processing point. A TCP retransmission presented to the PDMv2 module as a new packet therefore receives a new PSNTP.
   
   -    
TSO/GSO


We will clarify that PDMv2 can operate above transmit segmentation or below receive aggregation and may not have visibility into hardware or lower-layer offload processing.

Packets created below the PDMv2 processing point by TSO, GSO, or an equivalent mechanism may carry the same PSNTP and other PDMv2 values. Such repetition is acceptable and does not, by itself, indicate a protocol error, packet loss, or retransmission.

The draft does not require a PDMv2 implementation to disable offload, inspect the interface MTU, or rewrite the option in each lower-layer segment. A reconstruction system should use available TCP sequence ranges, payload lengths, timestamps, and surrounding PDMv2 observations to distinguish segmentation, duplication, retransmission, and reordering. If the available evidence is insufficient, it should report the result as ambiguous.

For protected PDMv2, copying an already protected option into offload-generated packets is not a new authenticated-encryption operation. The sender is nevertheless prohibited from independently encrypting different plaintext values using the same SessionTemporaryKey and nonce.
   
   -    
Appendix A


We will correct the reference to point to the registration objectives in Section 5.1 and the security-context requirements in the new Section 5.4. We will also clarify that Appendix A is an informative example and that conformance does not depend on using RADIUS or EAP.

Thank you again for the careful review. We believe these changes address the TSV-ART comments and would welcome any further feedback when the new draft is available.

Best regards,

Nalini
For the draft-ietf-ippm-encrypted-pdmv2 authors
Chief Technology OfficerOutside the Stacks, Inc.https://www.outsidethestacks.com

Chief Operating OfficerIndustry Network Technology Councilhttps://www.industrynetcouncil.org 

    On Saturday, August 8, 2026 at 11:12:42 PM PDT, Yoshifumi Nishida via Datatracker <[e-mail]> wrote:  
 
 Document: draft-ietf-ippm-encrypted-pdmv2
Title: IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination Option
Reviewer: Yoshifumi Nishida
Review result: On the Right Track

This document has been reviewed as part of the transport area review team's
ongoing effort to review key IETF documents. These comments were written
primarily for the transport area directors, but are copied to the document's
authors and WG to allow them to address any issues raised and also to the IETF
discussion list for information.

when done at the time of IETF Last Call, the authors should consider this
review as part of the last-call comments they receive. Please always CC
[e-mail] if you reply to or forward this review.

Summary: This document is On the Right Track as a standard track document,
however, I think the following points need to be addressed.

1. Section 7: Option type '0x0F'
  I believe this means this document reuses the option value used for RFC8250
  as it mentions "adopted from RFC 8250".
  However, the document also requests a new option type to use different value.
  This point should be clarified.

2. Section 7. Option length '0x22'
  This indicates option length is 34 bytes, however, actual length of the
  header format looks 22 bytes.

3. Section 7.
  It looks a bit strange to me to have the same length for Unencrypted PDM
  and Encrypted PDM. Is this correct?

  "PDMv2 uses a single header format. Whether metric contents are protected
  or unprotected is determined by local policy and registration context."
  Does this mean there is no inbound mechanism for receiver to know whether
  this is Encrypted PDM or not? Is this design intentional ?

4. Section 7.
  "Epoch field is used to indicate the valid SessionTemporaryKey."

  I think we need to add an explanation for SessionTemporaryKey, such as
  how this key is derived.

5. Section 7.
  Both PSNTP and PSNLR have dependency on 5-tuple. However, I'm not sure
  how we can apply this to ICMP.
  The draft mentions "PDMv2 operates entirely at the IPv6 layer and
  applies uniformly to TCP, UDP, ICMP, QUIC" in Section 1.

6. Section 7.
  "This field is initialized at a random number and is incremented sequentially
  for each packet of the 5-tuple."
  When TCP retransmits packets, should we increase PSNTP or not?
  Please clarify this point.

7. Can this approach work with TSO/GSO? When a packet is split into multiple packets,
  multiple packets would have the same PSNTP.  Is this acceptable?

8. Appendix A
  "This appendix illustrates one possible registration mechanism that satisfies
  the requirements defined in Section 4."

  I think Section 4 doesn't define requirements. I thought you mean Section 5.1
  ('Registration Objectives'). however, 5.1's bullets are high-level enough that
  it's unclear what 'satisfies' means in the sentence.



_______________________________________________
ippm mailing list -- [e-mail]
To unsubscribe send an email to [e-mail]