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

["Les Ginsberg (ginsberg)" <[e-mail]>]

Scott -

Thanx for your review.

I have uploaded V4 of the draft with the change you suggested.

   Les


> -----Original Message-----
> From: Scott Kelly via Datatracker <[e-mail]>
> Sent: Monday, May 22, 2023 9:12 AM
> To: [e-mail]
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: Secdir last call review of draft-ietf-lsr-rfc8920bis-03
> 
> 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."
>