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
