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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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 <noreply@xxxxxxxx>
> Sent: Monday, May 22, 2023 9:12 AM
> To: secdir@xxxxxxxx
> Cc: draft-ietf-lsr-rfc8920bis.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx
> 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."
> 

-- 
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call



[Index of Archives]     [IETF Annoucements]     [IETF]     [IP Storage]     [Yosemite News]     [Linux SCTP]     [Linux Newbies]     [Mhonarc]     [Fedora Users]

  Powered by Linux