Like I said, I'm not too familiar with IS-IS, so I can't really judge
the part about the max size. Assuming that part is right though, then
that's good that the potential memory allocation from this doc is bounded.
As for resolving my concern, it really was just a nit to begin with. I
wanted to bring it up in case it's something that people hadn't thought
about, or in case folks wanted to add a bit to the security
considerations section about memory allocation/bounds to explain why
it's a non-issue and/or to help implementers. At the end of the day
though, if I'm understanding
https://wiki.ietf.org/group/secdir/SecDirReview#purpose correctly, it's
really not up to me. And I don't feel like I understand the context well
enough to push strongly for any one thing or another.
Op 2025-02-17 om 19:41 schreef Les Ginsberg (ginsberg):
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
