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

[Yoshifumi Nishida <[e-mail]>]

Hello Nalini

Thanks for your quick response and addressing my comments. The updates
look good to me. I don't have further comments for now.
--
Yoshi

On Wed, Aug 12, 2026 at 5:12 PM [e-mail] <
[e-mail]> wrote:

> Yoshifumi,
>
> Thank you very much for the careful review. We have revised
> draft-ietf-ippm-encrypted-pdmv2 to address all eight points.  A new version
> of the draft (15) has been submitted.
>
> Our responses are inline below.
>
>    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.
>
> Agreed. This was confusing and has been corrected.
>
> Section 7 now explicitly states that PDMv2 does not reuse the PDM Option
> Type 0x0F assigned by RFC 8250. References to fields or semantics 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 explicitly states that the new PDMv2
> allocation is independent of the RFC 8250 value 0x0F and does not modify or
> redefine that allocation.
>
>    2. 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 Option Length of 22
> decimal (0x16). As defined for IPv6 options, this excludes the Option Type
> and Option Length octets, so the complete unprotected PDMv2 option is 24
> octets.
>
> We also added a field table with offsets and lengths so the length
> calculation is explicit.
>
>    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 ?
>
> You are correct. The two formats should not have had the same length, and
> relying on local policy or registration context to determine the received
> wire format was ambiguous.
>
> We have replaced the single-format description with two explicitly
> 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 and unprotected formats
> on the wire. Section 7 explicitly states that an implementation MUST NOT
> determine whether a received PDMv2 option is protected solely from local
> policy or registration context.
>
> Registration context is still required to authenticate, decrypt, and
> interpret protected content, but it is not required merely to identify 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.
>
>    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.
>
> Agreed.
>
> We expanded Section 5.1 and added Section 5.4, "Registration Output and
> SessionTemporaryKey."
>
> A SessionTemporaryKey is now defined as cryptographic keying material used
> to protect PDMv2 metric blocks during a bounded key epoch.
>
> The registration mechanism or protection-suite specification MUST 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-specific purpose 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 the applicable
> PDMv2 security context and SessionTemporaryKey rather than as secret
> material itself.
>
>    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.
>
> Agreed. Referring generically to a 5-tuple was inappropriate for protocols
> that do not have transport-layer ports.
>
> Section 7.6 now defines PDMv2 flow identification explicitly.
>
> For TCP and UDP, the flow uses the IPv6 source address, IPv6 destination
> address, upper-layer protocol number, source port, and destination port.
>
> For ICMPv6, the flow uses the IPv6 source address, IPv6 destination
> address, ICMPv6 Next Header value, Type, and Code. When an Identifier field
> is present, such as for Echo Request and Echo Reply, it SHOULD also be used
> to distinguish concurrent exchanges.
>
> ICMPv6 error messages are classified using their outer IPv6 and ICMPv6
> headers rather than the quoted packet.
>
> For another upper-layer protocol without port numbers, a protocol
> specification or registration context can define an equivalent stable
> discriminator. If none is available, the IPv6 source address, destination
> address, and upper-layer protocol number identify the PDMv2 flow.
>
> We also added explicit reverse-direction correspondence. TCP and UDP
> exchange source/destination addresses and ports. ICMPv6 request/reply flows
> exchange the IPv6 addresses and associate the applicable request Type with
> its corresponding reply Type, retaining the same Identifier when present.
>
>    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.
>
> Yes. We have made this explicit in Section 7.7.
>
> PSNTP is initialized to a pseudorandom value when PDMv2 state is created
> for a flow and is incremented modulo 2^32 for each packet processed as a
> new transmission at the sender's PDMv2 processing point.
>
> The revised text explicitly states:
>
> "A TCP retransmission presented to the PDMv2 module as a new packet is a
> new transmission and receives a new PSNTP value."
>
> We also clarify that PSNTP counts packet-processing events visible to the
> PDMv2 module rather than application data units, TCP sequence space, or
> unique transport payloads.
>
>    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?
>
> Yes. We added Sections 7.12 and 7.13 to make this behavior explicit.
>
> PDMv2 may operate at a processing point before transmit segmentation or
> after receive aggregation. Consequently, packets observed by the PDMv2
> module do not necessarily have a one-to-one relationship with packets
> transmitted or received at a physical interface.
>
> TSO, GSO, or equivalent processing below the PDMv2 processing point may
> therefore create several packets carrying identical PDMv2 values, including
> the same PSNTP. This is acceptable.
>
> Similarly, GRO, LRO, or equivalent receive-side processing may combine
> multiple received packets before they become visible to PDMv2.
>
> The draft does not require the PDMv2 module to disable offload, inspect
> the outgoing interface MTU solely for PDMv2 purposes, or rewrite PDMv2
> separately in packets created below its processing point.
>
> A repeated PSNTP by itself is therefore not evidence of packet loss,
> retransmission, malformed PDMv2 data, or sender nonconformance.
>
> For reconstruction, other available evidence such as TCP sequence-number
> ranges, payload lengths, timestamps, IPv6 fragmentation information, and
> surrounding PDMv2 observations SHOULD be considered. If the evidence is
> insufficient, the result SHOULD be reported as ambiguous rather than as a
> protocol error.
>
> For the protected form, Section 7.13 also clarifies that copying an
> already protected PDMv2 option during segmentation is not a new
> authenticated-encryption invocation. Repetition of the identical ciphertext
> and authentication tag therefore does not by itself constitute
> cryptographic nonce reuse.
>
>    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.
>
> Agreed on both points.
>
> Appendix A now says:
>
> "This appendix illustrates one possible registration mechanism that can
> meet the registration objectives listed in Section 5.1 and provide the
> security context described in Section 5.4. The example is informative.
> Conformance with this document depends on satisfying the applicable
> normative requirements in the main body and does not depend on using RADIUS
> or EAP."
>
> Section 5.1 has also been expanded to describe the registration objectives
> more concretely, and Section 5.4 now defines the required registration
> output and SessionTemporaryKey security context.
>
> We also clarified Appendix A.6 so that the illustrative RADIUS/EAP example
> does not imply that key derivation or protection requirements are merely
> implementation-specific. The appendix now states that its specific
> mechanisms are outside the scope of the example, while remaining subject to
> the normative requirements of Section 5.4 and the selected registration
> mechanism or protection-suite specification.
>
> This avoids claiming that the illustrative RADIUS/EAP example itself
> defines or proves conformance.
>
> Thank you again for the review. Your comments resulted in substantial
> improvements to the wire-format definition, registration/key context, flow
> identification, retransmission semantics, and treatment of segmentation and
> aggregation.
>
> Thanks,
> Nalini Elkins
>
> Chief Technology Officer
> Outside the Stacks, Inc.
> https://www.outsidethestacks.com
>
> Chief Operating Officer
> Industry Network Technology Council
> https://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]
>