[Last-Call] Secdir last call review of draft-ietf-lsr-rfc8920bis-03

[Scott Kelly via Datatracker <[e-mail]>]

Reviewer: Scott Kelly
Review result: Has Nits

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 "almost ready"

Quoting the abstract,
   Existing traffic-engineering-related link attribute advertisements
   have been defined and are used in RSVP-TE deployments.  Since the
   original RSVP-TE use case was defined, additional applications (e.g.,
   Segment Routing Policy and Loop-Free Alternates) that also make use
   of the link attribute advertisements have been defined.  In cases
   where multiple applications wish to make use of these link
   attributes, the current advertisements do not support application-
   specific values for a given attribute, nor do they support indication
   of which applications are using the advertised value for a given
   link.  This document introduces new link attribute advertisements in
   OSPFv2 and OSPFv3 that address both of these shortcomings.

The security considerations seem complete, but I had one minor concern with
this sentence:

   Implementations must ensure that if any of the TLVs and sub-TLVs
   defined in this document are malformed, they are detected and do not
   facilitate a vulnerability for attackers to crash the OSPF router or
   routing process.

This is correct, but we are not just concerned with crashing. It might be
better to say something like "...to crash or otherwise compromise the OSPF
router or routing process."