inline w/ [DC] On Thu, Apr 17, 2025 at 10:49 AM Les Ginsberg (ginsberg) <[email protected]> wrote:
> Deb - > > Thanx for your review. > Responses inline. > > > -----Original Message----- > > From: Deb Cooley via Datatracker <[email protected]> > > Sent: Thursday, April 17, 2025 4:57 AM > > To: The IESG <[email protected]> > > Cc: [email protected]; [email protected]; [email protected] > ; > > [email protected]; [email protected] > > Subject: Deb Cooley's No Objection on draft-ietf-lsr-multi-tlv-16: (with > > COMMENT) > > > > Deb Cooley has entered the following ballot position for > > draft-ietf-lsr-multi-tlv-16: No Objection > > > > When responding, please keep the subject line intact and reply to all > > email addresses included in the To and CC lines. (Feel free to cut this > > introductory paragraph, however.) > > > > > > Please refer to > > https://www.ietf.org/about/groups/iesg/statements/handling-ballot- > > positions/ > > for more information about how to handle DISCUSS and COMMENT positions. > > > > > > The document, along with other ballot positions, can be found here: > > https://datatracker.ietf.org/doc/draft-ietf-lsr-multi-tlv/ > > > > > > > > ---------------------------------------------------------------------- > > COMMENT: > > ---------------------------------------------------------------------- > > > > Thank you to David Mandelberg for their secdir reviews. Also for the > detailed > > shepherd review by Yingzhen Qu. > > > > General: I think the definition and explanation of how the term 'key' > as used > > in this context is good. I also agree w/ Ketan's comment on lines > 247-251 for > > how to clarify the wording about where 'key' is defined for a given TLV. > > > [LES:] Ketan's concern was addressed in V15 of the draft. > Whether Ketan is satisfied w the revised wording is unknown since he is > currently away and has not been able to respond - but as the revised > wording is very close to what he suggested I am optimistic. > If you have reviewed the revised wording and still have a concern, please > let me know. > For your convenience, the revised text is: > > " Also note the definition of the "key" is part of the specification(s) > that define(s) the TLV and is therefore outside the scope of this document." > [DC] If Ketan is happy, then I am as well. > > > Section 10: The ability to add multiple TLVs to an IS-IS session > (possibly not > > the right word) may increase the ability to cause a denial of service via > > resource exhaustion. If that is a risk, please address this security > concern. > > Otherwise, please clarify why it isn't a concern. > > > [LES:] There is nothing today that prevents an attacker from inserting > multiple copies of a TLV for a given object (with or without varying > content). > Implementations which support MP-TLV are likely to be more resilient in > the face of such attacks. > This point was discussed in the context of Mohammed's review of V11 and > the following text was added to the Security section: > > " Note that support for MP-TLV may result in an implementation being more > robust in handling unexpected occurrences of MP-TLV." > [DC] Just to be sure I understand, a system that supports MP-TLV can discard extraneous TLV copies more efficiently than older systems? Or is there more to it than that? [I did see that sentence, and without the context of a possible DOS via a resource exhaustion attack, I wasn't sure if that was the point.] > > Les > > > > > >
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
