Hi, Les: > “incorrectly formatted TLVs”. will be discarded directly by the receiver.
But for the unlimited boundaries of MP-TLV, each of them is legitimate, correct formatted, the receiver MUST keep them all in the memory and wait for the next piece with no length indicator of the overall TLV/sub-TLV/sub-sub-TLV. All of these MP-TLV codepoints MUST extend the possible memory usage to one unlimited value, this is the cause of DDoS attack. Before MP-TLV, each TLV/sub-TLV/sub-sub-TLV is bounded by the length field that associated with each of them. Aijun Wang China Telecom > On Apr 18, 2025, at 00:50, Les Ginsberg (ginsberg) > <[email protected]> wrote: > > > Deb – > > > > Section 10: The ability to add multiple TLVs to an IS-IS session (possibly > > not > > the right word) may increase the ability to cause a denial of service via > > resource exhaustion. If that is a risk, please address this security > > concern. > > Otherwise, please clarify why it isn't a concern. > > > [LES:] There is nothing today that prevents an attacker from inserting > multiple copies of a TLV for a given object (with or without varying content). > Implementations which support MP-TLV are likely to be more resilient in the > face of such attacks. > This point was discussed in the context of Mohammed's review of V11 and the > following text was added to the Security section: > > " Note that support for MP-TLV may result in an implementation being more > robust in handling unexpected occurrences of MP-TLV." > > [DC] Just to be sure I understand, a system that supports MP-TLV can discard > extraneous TLV copies more efficiently than older systems? Or is there more > to it than that? [I did see that sentence, and without the context of a > possible DOS via a resource exhaustion attack, I wasn't sure if that was the > point.] > [LES:] In the absence of MP-TLV support, when a system receives two TLVs for > the same object, the results are unpredictable. > The receiver might prefer one over the other and ignore the less preferred > one. > It might try to combine the two in unpredictable ways. > It might use both “by accident” simply because when walking the LSPDB it > encounters a particular TLV type and doesn’t “remember” that it processed a > previous TLV for that same object. > Many variants are possible. > > With MP-TLV support, the implementation has been enhanced to handle multiple > TLVs for the same object – so there should be a predictable outcome if that > occurs. > > Also, just to clarify the resource exhaustion topic, if an attacker is > capable of spoofing IGP authentication, it can then send any number of LSPs > with any variant of content. It could be multiple TLVs for a single object. > It could be many TLVs for different objects. Probably the most dangerous is > to send incorrectly formatted TLVs, which might expose a bug in the receiver > which could produce a crash. > None of this is enhanced/altered by introduction of MP-TLVs. > > Les > > > Les > > > > > > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
