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? > >>> > > -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
