Hi, David: I think you raised a good question, maybe ignored by the LSR WGLC.
It is possible that the memory of the receiver be corrupted/comprised by the attacker, because current solution has no length limit for one possible large IS-IS TLV. Les, your answer doesn’t address the issues raised by David. This is another point that we should BLOCK this proposal. Other outstanding unsolved issues are also in discussions. I copy this mail also to IESG for further references of the IESG experts. Aijun Wang China Telecom > On Feb 15, 2025, at 07:35, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > 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? >> > > -- > last-call 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]
