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 -----邮件原件----- 发件人: [email protected] [mailto:[email protected]] 代表 Les Ginsberg (ginsberg) 发送时间: 2025年2月18日 9:18 收件人: David Mandelberg <[email protected]>; [email protected] 抄送: [email protected]; [email protected]; [email protected] 主题: [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 <[email protected]> > Sent: Monday, February 17, 2025 5:04 PM > To: Les Ginsberg (ginsberg) <[email protected]>; [email protected] > Cc: [email protected]; [email protected]; > [email protected] > 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) <[email protected]> > >> Sent: Friday, February 14, 2025 3:25 PM > >> To: David Mandelberg <[email protected]>; [email protected] > >> Cc: [email protected]; [email protected]; > >> [email protected] > >> 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 <[email protected]> > >>> Sent: Friday, February 14, 2025 2:22 PM > >>> To: [email protected] > >>> Cc: [email protected]; [email protected]; > >>> [email protected] > >>> 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 -- [email protected] To unsubscribe send an email to [email protected] _______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
