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

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

Hi Chris,

Thank you for the review. We agree that the document needsclearer normative guidance in these areas.

We will replace the existing 0x0F value with anIANA-assigned placeholder throughout the document. PDMv2 is intended to receivea new Option Type and is distinct from the PDM option defined by RFC 8250.

We also agree that the protected and unprotected formats arenot distinguished clearly enough. We will correct the Option Length values andrevise the header description so that the receiver can unambiguously determinethe applicable format. The revised text will explicitly define the fieldscarried on the wire and how protection status is indicated, rather than relyingon two identical length values.

Finally, we will add normative receiver behavior formalformed options, unsupported versions or lengths, missing or expiredregistration context, unauthorized senders, and authentication or decryptionfailures. The revised document will specify when the PDMv2 contents must beignored and will describe policy-controlled actions such as continuing toprocess the upper-layer packet, discarding the packet, logging, rate-limitedalerting, or blocking repeated unauthorized traffic.

The external registration mechanism remains responsible forestablishing authentication, authorization, and security context. However, weagree that PDMv2 packet-processing and exception behavior must be specified inthis document rather than left entirely to the registration mechanism.

We will incorporate these changes in the next revision andwould appreciate your review of the resulting text.

Thanks,

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 05:40:39 AM PDT, 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]