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]

Reply via email to