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 <nore...@ietf.org> > Sent: Monday, May 22, 2023 9:12 AM > To: sec...@ietf.org > Cc: draft-ietf-lsr-rfc8920bis....@ietf.org; last-c...@ietf.org; lsr@ietf.org > 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." > _______________________________________________ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr
