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

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

Yoshifumi,

Thank you very much for the careful review. We have reviseddraft-ietf-ippm-encrypted-pdmv2 to address all eight points.  A new version of the draft (15) has been submitted.

Our responses are inline below.
   
   - 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.

Agreed. This was confusing and has been corrected.

Section 7 now explicitly states that PDMv2 does not reusethe PDM Option Type 0x0F assigned by RFC 8250. References to fields orsemantics adopted from RFC 8250 do not imply reuse of its Option Type.

Section 7.3 now specifies the PDMv2 Option Type as TBD1,pending IANA allocation.

Section 11.1 requests a new allocation from the IPv6"Destination Options and Hop-by-Hop Options" registry and explicitlystates that the new PDMv2 allocation is independent of the RFC 8250 value 0x0Fand does not modify or redefine that allocation.
   
   - Section 7. Option length '0x22'   
 This indicates option length is 34 bytes, however, actual length of the   
 header format looks 22 bytes.

Agreed. The previous value was incorrect.

The unprotected format in Section 7.1 now has an OptionLength of 22 decimal (0x16). As defined for IPv6 options, this excludes theOption Type and Option Length octets, so the complete unprotected PDMv2 optionis 24 octets.

We also added a field table with offsets and lengths so thelength calculation is explicit.
   
   - 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 metriccontents 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 ?

You are correct. The two formats should not have had thesame length, and relying on local policy or registration context to determinethe received wire format was ambiguous.

We have replaced the single-format description with twoexplicitly distinguishishable wire formats.

The unprotected form has:
   
   - Option Length = 22 decimal (0x16)
   - Total option size = 24 octets

The protected form has:
   
   - Option Length = 38 decimal (0x26)
   - Total option size = 40 octets
   - A 16-octet protected metric block
   - A 16-octet authentication tag

The Option Length now distinguishes the protected andunprotected formats on the wire. Section 7 explicitly states that animplementation MUST NOT determine whether a received PDMv2 option is protectedsolely from local policy or registration context.

Registration context is still required to authenticate,decrypt, and interpret protected content, but it is not required merely toidentify the protected or unprotected wire format.

For the protected form, Option Type, Option Length, Version,Epoch, and PSNTP are clear and authenticated as associated data.
   
   - Section 7.   
 "Epoch field is used to indicate the valid SessionTemporaryKey."

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

Agreed.

We expanded Section 5.1 and added Section 5.4,"Registration Output and SessionTemporaryKey."

A SessionTemporaryKey is now defined as cryptographic keyingmaterial used to protect PDMv2 metric blocks during a bounded key epoch.

The registration mechanism or protection-suite specificationMUST define:
   
   - how the SessionTemporaryKey is derived or provisioned;
   - the cryptographic algorithm and key length;
   - the endpoints, flows, or measurement domain to which the key applies;
   - the associated Epoch;
   - the lifetime of the key;
   - the rekey procedure;
   - how authorized measurement systems obtain the required security context; and
   - how expiration and revocation are handled.

If the SessionTemporaryKey is derived from a master secret,the derivation MUST use a cryptographically secure KDF and a PDMv2-specificpurpose label, with cryptographic separation from keys used by other protocols.

The draft also explicitly prohibits using TLS, QUIC, IPsec,or other application or transport traffic keys as a PDMv2 SessionTemporaryKey.

Section 7.5 now defines Epoch as a 12-bit selector for theapplicable PDMv2 security context and SessionTemporaryKey rather than as secretmaterial itself.
   
   - 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.

Agreed. Referring generically to a 5-tuple was inappropriatefor protocols that do not have transport-layer ports.

Section 7.6 now defines PDMv2 flow identificationexplicitly.

For TCP and UDP, the flow uses the IPv6 source address, IPv6destination address, upper-layer protocol number, source port, and destinationport.

For ICMPv6, the flow uses the IPv6 source address, IPv6destination address, ICMPv6 Next Header value, Type, and Code. When anIdentifier field is present, such as for Echo Request and Echo Reply, it SHOULDalso be used to distinguish concurrent exchanges.

ICMPv6 error messages are classified using their outer IPv6and ICMPv6 headers rather than the quoted packet.

For another upper-layer protocol without port numbers, aprotocol specification or registration context can define an equivalent stablediscriminator. If none is available, the IPv6 source address, destinationaddress, and upper-layer protocol number identify the PDMv2 flow.

We also added explicit reverse-direction correspondence. TCPand UDP exchange source/destination addresses and ports. ICMPv6 request/replyflows exchange the IPv6 addresses and associate the applicable request Typewith its corresponding reply Type, retaining the same Identifier when present.
   
   - 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.

Yes. We have made this explicit in Section 7.7.

PSNTP is initialized to a pseudorandom value when PDMv2state is created for a flow and is incremented modulo 2^32 for each packetprocessed as a new transmission at the sender's PDMv2 processing point.

The revised text explicitly states:

"A TCP retransmission presented to the PDMv2 module asa new packet is a new transmission and receives a new PSNTP value."

We also clarify that PSNTP counts packet-processing eventsvisible to the PDMv2 module rather than application data units, TCP sequencespace, or unique transport payloads.
   
   - 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?

Yes. We added Sections 7.12 and 7.13 to make this behaviorexplicit.

PDMv2 may operate at a processing point before transmitsegmentation or after receive aggregation. Consequently, packets observed bythe PDMv2 module do not necessarily have a one-to-one relationship with packetstransmitted or received at a physical interface.

TSO, GSO, or equivalent processing below the PDMv2processing point may therefore create several packets carrying identical PDMv2values, including the same PSNTP. This is acceptable.

Similarly, GRO, LRO, or equivalent receive-side processingmay combine multiple received packets before they become visible to PDMv2.

The draft does not require the PDMv2 module to disableoffload, inspect the outgoing interface MTU solely for PDMv2 purposes, orrewrite PDMv2 separately in packets created below its processing point.

A repeated PSNTP by itself is therefore not evidence ofpacket loss, retransmission, malformed PDMv2 data, or sender nonconformance.

For reconstruction, other available evidence such as TCPsequence-number ranges, payload lengths, timestamps, IPv6 fragmentationinformation, and surrounding PDMv2 observations SHOULD be considered. If theevidence is insufficient, the result SHOULD be reported as ambiguous ratherthan as a protocol error.

For the protected form, Section 7.13 also clarifies thatcopying an already protected PDMv2 option during segmentation is not a newauthenticated-encryption invocation. Repetition of the identical ciphertext andauthentication tag therefore does not by itself constitute cryptographic noncereuse.
   
   - 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 youmean Section 5.1 ('Registration Objectives'). however, 5.1's bullets are high-level enough that it's unclear what 'satisfies' means in the sentence.

Agreed on both points.

Appendix A now says:

"This appendix illustrates one possible registrationmechanism that can meet the registration objectives listed in Section 5.1 andprovide the security context described in Section 5.4. The example isinformative. Conformance with this document depends on satisfying theapplicable normative requirements in the main body and does not depend on usingRADIUS or EAP."

Section 5.1 has also been expanded to describe theregistration objectives more concretely, and Section 5.4 now defines therequired registration output and SessionTemporaryKey security context.

We also clarified Appendix A.6 so that the illustrativeRADIUS/EAP example does not imply that key derivation or protectionrequirements are merely implementation-specific. The appendix now states thatits specific mechanisms are outside the scope of the example, while remainingsubject to the normative requirements of Section 5.4 and the selectedregistration mechanism or protection-suite specification.

This avoids claiming that the illustrative RADIUS/EAPexample itself defines or proves conformance.

Thank you again for the review. Your comments resulted insubstantial improvements to the wire-format definition, registration/keycontext, flow identification, retransmission semantics, and treatment ofsegmentation and aggregation.

Thanks,
Nalini Elkins
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 10:12:42 PM GMT-8, 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]