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) <ginsberg=40cisco.com@xxxxxxxxxxxxxx> 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 <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 -- last-call mailing list -- last-call@xxxxxxxx To unsubscribe send an email to last-call-leave@xxxxxxxx
