[secdir] Re: [ippm] draft-ietf-ippm-encrypted-pdmv2-14 early Secdir review

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

Chris,

Thank you very much for the review. We agree that the draftneeded to define the operational failure and exception behavior in the basePDMv2 specification rather than relying on an external registration mechanismto supply that behavior.

We have revised the draft accordingly.  The latest draft is v15.

Our responses are inline below.

The draft defines a PDMv2 header to be used within theDestination Options
Header as defined in RFC 8200 (IPv6). That part is straightforward and
understandable. My list of nits for this are: - The ID defines 0x0F as the
option type in Section 7. This is the option type already used for the TLV for
PDM as defined in RFC 8250. This ID should use "TBD" in this sectionor
otherwise indicate that the option type will be assigned by IANA. The ID does
say that in Section 11.

Agreed.

PDMv2 no longer uses 0x0F.

Section 7 now explicitly states that PDMv2 does not reusethe PDM Option Type 0x0F assigned by RFC 8250. References to fields adoptedfrom RFC 8250 describe their semantics and do not indicate reuse of the RFC8250 Option Type.

Section 7.3 now uses 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 PDMv2 allocation is independent of RFC 8250's 0x0F allocationand does not modify or redefine it.
   
   - The ID uses the same value for the length for   
 encrypted and unencrypted PDM option length (0x22). By itself, this will lead   
 to confusion by the recipient and the document provides no further guidance for   
 this possible confusion.

Agreed. The lengths were incorrect and the format-selectionmechanism was ambiguous.

We now define two unambiguous wire formats.

The unprotected format in Section 7.1 has:
   
   - Option Length = 22 decimal (0x16)
   - Total option size = 24 octets

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

Option Length now distinguishes the protected andunprotected formats on the wire.

Section 7 explicitly states that a receiver can determinefrom the PDMv2 option itself whether the metric block is protected and that animplementation MUST NOT determine the received format solely from local policyor registration context.

For the protected format, Option Type, Option Length,Version, Epoch, and PSNTP are clear and cryptographically authenticated asassociated data.
   
   - The ID provides no guidance for misconfigurations,   
 errors, or operational exceptions. For example, what should a receiver do if it   
 receives a malformed PDMv2 message, or if it receives a PDMv2 message from a   
 sender that is not authorized to send those messages?

Agreed. This was the major missing operational behavior inthe previous version.

We added a new normative Section 7.14, "ReceiverValidation and Exception Handling."

A receiver MUST validate the PDMv2 Option Type, OptionLength, Version, and identified format before interpreting dependent PDMv2fields.

A protected PDMv2 option is invalid for PDMv2 processing if:
   
   - authentication fails;
   - the indicated Epoch is unknown or expired;
   - the Epoch cannot be mapped to an applicable security context;
   - the required security context is unavailable;
   - the sender is not authorized by that security context; or
   - the option is malformed or inconsistent with its declared format.

The central state-protection rule is now:

"An invalid, unauthenticated, or unauthorized PDMv2option MUST NOT be used for measurement, reconstruction, or updating PDMv2state."

Failure of a registration service or inability to obtain theapplicable security context MUST fail closed with respect to protected PDMv2content. The protected content MUST NOT be decrypted, interpreted, or used toupdate measurement state.

Unsupported versions are also explicitly handled: they MUSTbe processed according to the action bits in the PDMv2 Option Type, and thereceiver MUST NOT interpret the remaining fields using the Version 2 format.

The ID appears to say that the operational aspects ofeverything will be
handled out of band, presumably by something like the exemplary registration
process of Appendix A. However, that appendix does not provide guidance for
fully handling the operations of PDMv2 exchanges. For example, RFC 8250
provides guidance in Section 4.3 that a receiver may block traffic, discard
packets, or send an alert for certain conditions. There is no guidance in this
ID for any of these conditions or actions.

Agreed. We have changed the division of responsibility sothat the base PDMv2 document defines this behavior.

Section 5.4 now states:

"This document specifies the PDMv2 on-wire formats andthe processing and exception-handling requirements for those formats. Aregistration mechanism supplies the security context described in this sectionbut does not redefine receiver behavior for malformed, unauthenticated, orunauthorized PDMv2 options."

Section 7.14 then defines the operational actions.

Failure to process PDMv2 information does not by itselfrequire discarding the enclosing IPv6 packet.

Unless local security policy requires otherwise, failure toprocess PDMv2 information SHOULD NOT cause the receiver to discard theenclosing packet's upper-layer payload. The receiver MAY ignore the PDMv2information and continue normal IPv6 processing, subject to the processingbehavior encoded in the IPv6 Option Type action bits.

A deployment MAY impose stricter policy and discard or blockpackets carrying invalid or unauthorized PDMv2 options.

The text also warns that packet dropping or blocking canaffect connectivity and can be exploited for denial of service. Therefore, whenthe IPv6 Option Type action bits permit it, implementations SHOULD default toignoring invalid PDMv2 measurement information rather than discarding theenclosing packet.

We also added the alerting and diagnostic behavior youidentified.

Implementations SHOULD count, log, or alert onauthentication failures, unknown or expired Epoch values, unavailable securitycontexts, unauthorized senders, malformed options, unsupported versions, andother anomalous PDMv2 conditions.

Such reporting SHOULD be aggregated or rate-limited so thatdiagnostics cannot themselves become a logging-based denial-of-service vector.

Implementations SHOULD provide configurable policies forignoring invalid PDMv2 data, generating an alert, discarding an enclosingpacket, or blocking a source.

If this ID is to be a standalone RFC, then guidance foroperational conditions
and exceptions must be provided in it. If this ID is a component in a system
that relies upon registrations to provide operational support, then the other
documents need to be identified and completed.

Agreed.

We have revised the draft so that the PDMv2 on-wireformat and normative receiver-processing and exception-handling behavior arespecified in this document rather than delegated to the registration mechanism.

The registration mechanism supplies the security contextrequired for a particular deployment: authentication and authorizationinformation, protection-suite selection, key establishment or provisioning,Epoch assignment, security-context scope and lifetime, nonce/associated-datacontext, and expiration/replacement/revocation.

Registration does not define how a PDMv2 receiver handlesmalformed, unauthenticated, unauthorized, unsupported, or otherwise unusablePDMv2 options. Those rules are now normative requirements of the base documentin Section 7.14.

Appendix A remains only an informative example of onepossible RADIUS/EAP-based registration mechanism. It explicitly states thatconformance with PDMv2 does not depend on using RADIUS or EAP.

We also clarified Appendix A.6. The specific key derivation,transformation, and protection mechanisms used by that illustrative RADIUS/EAPexample are outside the scope of the appendix, but they remain subject to theapplicable normative requirements in Section 5.4 and to the selectedregistration mechanism or protection-suite specification.

Finally, we substantially expanded Section 9, SecurityConsiderations, to summarize and cross-reference the normative receiverbehavior. It now addresses authentication and authorization failures, unknownor expired Epochs, unavailable security context, contamination of measurementstate by forged or malformed data, nonce-reuse prevention, repeated protectedoptions caused by segmentation or duplication, denial-of-service risks frompacket dropping, and denial-of-service risks from excessive logging or alerting.

Thank you again for the review. In particular, your commentscaused us to make the operational exception handling part of the base PDMv2specification rather than leaving that responsibility implicit in theregistration architecture.


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 04:40:39 AM GMT-8, Chris Lonvick via Datatracker <[e-mail]> wrote:  
 
 Document: draft-ietf-ippm-encrypted-pdmv2
Title: IPv6 Performance and Diagnostic Metrics Version 2 (PDMv2) Destination
Option Reviewer: Chris Lonvick Review result: Not Ready

Hi,

I have reviewed this document as part of the security directorate's ongoing
effort to review all IETF documents being processed by the IESG. These comments
were written primarily for the benefit of the security area directors. Document
editors and WG chairs should treat these comments just like any other last call
comments.

The summary of the review is Not Ready.

The draft defines a PDMv2 header to be used within the Destination Options
Header as defined in RFC 8200 (IPv6). That part is straightforward and
understandable. My list of nits for this are: - The ID defines 0x0F as the
option type in Section 7. This is the option type already used for the TLV for
PDM as defined in RFC 8250. This ID should use "TBD" in this section or
otherwise indicate that the option type will be assigned by IANA. The ID does
say that in Section 11. - The ID uses the same value for the length for
encrypted and unencrypted PDM option length (0x22). By itself, this will lead
to confusion by the recipient and the document provides no further guidance for
this possible confusion. - The ID provides no guidance for misconfigurations,
errors, or operational exceptions. For example, what should a receiver do if it
receives a malformed PDMv2 message, or if it receives a PDMv2 message from a
sender that is not authorized to send those messages?

The ID appears to say that the operational aspects of everything will be
handled out of band, presumably by something like the exemplary registration
process of Appendix A. However, that appendix does not provide guidance for
fully handling the operations of PDMv2 exchanges. For example, RFC 8250
provides guidance in Section 4.3 that a receiver may block traffic, discard
packets, or send an alert for certain conditions. There is no guidance in this
ID for any of these conditions or actions.

If this ID is to be a standalone RFC, then guidance for operational conditions
and exceptions must be provided in it. If this ID is a component in a system
that relies upon registrations to provide operational support, then the other
documents need to be identified and completed.

Best regards,
Chris


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