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

[Chris Lonvick via Datatracker <[e-mail]>]

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