Let’s analysis the “unlimited boundary attack” issue from another viewpoint:
1) Current IS-IS TLV/sub-TLV/sub-sub-TLV have the length limit of 255 bytes. 2) RFC 7356 wants to solve such issues, define the new extended TLV and sub-TLV with 16-bit Type and Length, but put the newly defined(but has length boundary) TLV/sub-TLV in newly defined PDU(FS-LSP/FS-CSNPs/FS-PSNPs). It seems failed. 3) Then, MP-TLV tries to relax the limitation in 1) of almost all the TLV/sub-TLV/sub-sub-TLV to the Unlimited Length Boundary(let’s call it ULB style TLV/sub-TLV/sub-sub-TLV) in the Existing PDUs, and declare “that support for MP-TLV may result in an implementation being more robust in handling unexpected occurrences of MP-TLV.” No need to change the encoding No need to define the new PDU, No need to define explicitly the ‘key’ that is the core component of the segment/concatenate rules widely used in industry. No cost, All Benefits?-------- That’s may be for the vendors, but not for the operators. Then, let’s focus the unsolved challenges, and potential Amount of Operational Cost to the operators. Best Regards Aijun Wang China Telecom 发件人: [email protected] [mailto:[email protected]] 代表 Aijun Wang 发送时间: 2025年4月18日 6:12 收件人: Les Ginsberg <[email protected]> 抄送: Deb Cooley <[email protected]>; The IESG <[email protected]>; [email protected]; [email protected]; [email protected]; [email protected] 主题: [Lsr] Re: Deb Cooley's No Objection on draft-ietf-lsr-multi-tlv-16: (with COMMENT) 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] <mailto:[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 -- <mailto:[email protected]> [email protected] To unsubscribe send an email to <mailto:[email protected]> [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
