Skip to main content

Last Call Review of draft-ietf-ippm-ioam-conf-state-05
review-ietf-ippm-ioam-conf-state-05-secdir-lc-lonvick-2022-09-30-00

Request Review of draft-ietf-ippm-ioam-conf-state
Requested revision No specific revision (document currently at 10)
Type Last Call Review
Team Security Area Directorate (secdir)
Deadline 2022-10-06
Requested 2022-09-22
Authors Xiao Min , Greg Mirsky , Lei Bo
I-D last updated 2022-09-30
Completed reviews Rtgdir Last Call review of -10 by Donald E. Eastlake 3rd
Secdir Last Call review of -05 by Chris M. Lonvick (diff)
Genart Last Call review of -06 by Gyan Mishra (diff)
Assignment Reviewer Chris M. Lonvick
State Completed
Request Last Call review on draft-ietf-ippm-ioam-conf-state by Security Area Directorate Assigned
Posted at https://mailarchive.ietf.org/arch/msg/secdir/Z2N6WrS6BVyHce24VqHg8JhWmqI
Reviewed revision 05 (document currently at 10)
Result Has issues
Completed 2022-09-30
review-ietf-ippm-ioam-conf-state-05-secdir-lc-lonvick-2022-09-30-00
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 Ready with Issues.

The Security Considerations section doesn't give any guidance regarding errors,
boundaries, or limits. For example, the specification requires that certain
fields MUST be set to 0, but no guidance is given of what a receiver is to do
if it receives a packet with that field not set to 0. Similarly, the
specification requires that a list of IOAM Namespace-IDs be transmitted. What
should a receiver do if the list includes duplicate entries, or if it receives
a Namespace-ID that is not defined? Please add some bounds checking and limits
in the Security Considerations section.

The specification frequently references RFC 9197, which appears to have a
well-developed Security Considerations section. It would be appropriate if the
Security Considerations section of this ID were to reference that Security
Considerations section and require that implementations of this specification
follow the guidance given there.

Other than those issues, I found the document to be understandable and well
written. I found no nits.

Regards,
Chris