No. " that support for MP-TLV makes a node a bit more resilient" is one FALSE statements. The unlimited MP-TLV length can lead more burden and potential memory crash on the receiver for every possible MP-TLV in https://datatracker.ietf.org/doc/html/draft-ietf-lsr-multi-tlv-09#section-9 And, also the statements of " this is not changed by the presence/absence of MP-TLV "--------There is length limit for the traditional IS-IS TLV, current MP-TLV proposal doesn't consider this point and is one Big Bug. Best Regards Aijun Wang China Telecom -----邮件原件----- 发件人: forwardingalgorithm@xxxxxxxx [mailto:forwardingalgorithm@xxxxxxxx] 代表 Les Ginsberg (ginsberg) 发送时间: 2025年2月18日 9:18 收件人: David Mandelberg <david@xxxxxxxxxxxxxx>; secdir@xxxxxxxx 抄送: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; lsr@xxxxxxxx 主题: [Lsr] Re: Secdir last call review of draft-ietf-lsr-multi-tlv-09 David - Understood. I am just used to having review status resolved. If it helps any, in terms of space consumed, the effect of 100 advertisements for bogus neighbors of 400 bytes each (requiring 2 TLVs/neighbor) is the same as 200 advertisements of 200 bytes each. It could be argued - without much vehemence - that support for MP-TLV makes a node a bit more resilient i.e., less likely to be confused by the 2 TLVs/neighbor. The overriding point here is that if the security measures specified in RFC 5304/5310 are bypassed, an attacker is able to inject as much bogus information as will fit in LSPs, and this is not changed by the presence/absence of MP-TLV. Les > -----Original Message----- > From: David Mandelberg <david@xxxxxxxxxxxxxx> > Sent: Monday, February 17, 2025 5:04 PM > To: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx>; secdir@xxxxxxxx > Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; > lsr@xxxxxxxx > Subject: Re: Secdir last call review of draft-ietf-lsr-multi-tlv-09 > > Like I said, I'm not too familiar with IS-IS, so I can't really judge > the part about the max size. Assuming that part is right though, then > that's good that the potential memory allocation from this doc is bounded. > > As for resolving my concern, it really was just a nit to begin with. I > wanted to bring it up in case it's something that people hadn't > thought about, or in case folks wanted to add a bit to the security > considerations section about memory allocation/bounds to explain why > it's a non-issue and/or to help implementers. At the end of the day > though, if I'm understanding > https://wiki.ietf.org/group/secdir/SecDirReview#purpose correctly, > it's really not up to me. And I don't feel like I understand the > context well enough to push strongly for any one thing or another. > > Op 2025-02-17 om 19:41 schreef Les Ginsberg (ginsberg): > > David - > > > > Please let me know if my response resolves your concern or if > > further > discussion is required. > > > > Thanx. > > > > Les > > > >> -----Original Message----- > >> From: Les Ginsberg (ginsberg) <ginsberg@xxxxxxxxx> > >> Sent: Friday, February 14, 2025 3:25 PM > >> To: David Mandelberg <david@xxxxxxxxxxxxxx>; secdir@xxxxxxxx > >> Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; > >> lsr@xxxxxxxx > >> Subject: RE: Secdir last call review of draft-ietf-lsr-multi-tlv-09 > >> > >> David - > >> > >> Thanx for the review. > >> > >> The amount of information a given IS can advertise at a given level > >> is > bounded > >> by (maximum # of LSPs(256) * LSP-MTU(typical default is 1492)). > >> IS-IS supports two levels. > >> > >> The easiest way to extend this is to use a larger MTU - the caveat > >> being that > all > >> links in the network that are used by IS-IS MUST support the larger > >> MTU as > IS- > >> IS does not support fragmentation of its PDUs. > >> > >> None of this is altered by use of MP-TLV. > >> > >> The driver for needing MP-TLVs are applications like Traffic > >> Engineering/Flex Algo which require additional information to be > >> sent about objects such as Neighbors and Prefixes. > >> > >> So, I think current content of our Security section is accurate and > appropriate. > >> > >> HTH > >> > >> Les > >> > >>> -----Original Message----- > >>> From: David Mandelberg via Datatracker <noreply@xxxxxxxx> > >>> Sent: Friday, February 14, 2025 2:22 PM > >>> To: secdir@xxxxxxxx > >>> Cc: draft-ietf-lsr-multi-tlv.all@xxxxxxxx; last-call@xxxxxxxx; > >>> lsr@xxxxxxxx > >>> Subject: Secdir last call review of draft-ietf-lsr-multi-tlv-09 > >>> > >>> Reviewer: David Mandelberg > >>> Review result: Has Nits > >>> > >>> Looks good, I think. > >>> > >>> The security considerations section doesn't have much detail, but > >>> this doc seems to be an extension of existing practice to > >>> additional TLVs in a way > that > >>> wouldn't change the security considerations at all. > >>> > >>> The only security-relevant thing I could think of is around memory > >>> bounds > >> and > >>> allocation in implementations. When going from limited-size fields > >>> to unlimited-size data across separate TLVs, I could imagine > >>> attacks that try to cause out of memory conditions on a router, or > >>> that try to overflow a fixed-size buffer. But this doc talks about > >>> existing TLVs that already work > the > >>> same way, so I'm guessing that hasn't been an issue in practice, > >>> or has > been > >>> mitigated? Do any of the existing docs talk about this? Or is > >>> there a size limit somewhere else (I'm not very familiar with > >>> IS-IS) that makes this a non-issue? > >>> > > _______________________________________________ Lsr mailing list -- lsr@xxxxxxxx To unsubscribe send an email to lsr-leave@xxxxxxxx -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
