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
