The unlimited boundaries of current MP-TLV proposal MUST be solved before forwarding this document, or else, STOP its forwarding.
It brings the most challenge for the receiver’s parsing of these indefinite multiple pieces. For example, when to stop parsing? when to stop to expect the future piece? There is no clue on the receiver. The traditional IS-IS encoding have no such dilemmas. Aijun Wang China Telecom > On Mar 29, 2025, at 06:30, Christian Hopps <cho...@chopps.org> wrote: > > > >> On Mar 28, 2025, at 17:59, Robert Raszuk <rob...@raszuk.net> wrote: >> >> Hi Les, >> >>> we now have to do an upgrade >> >> The way I understand Mohamed's suggestion is not to have a static >> implementation constant, but a configurable limit by an operator. If you >> prefer the default to be infinity so be it. If this is just a config no >> upgrade would be necessary. >> >> But how do you protect the network from malicious or accidental injection of >> MP-TLV consisting of 1000s of pieces ? And it seems better to ignore the TLV >> exceeding such limit as opposed to break entire level. >> >> So let's assume there is no limit ... how do you protect from such attack >> vectors or just bugs especially if what is exceeded is just a link state >> opaque value simply carried by ISIS for convenience of other upper level >> apps ? >> >> Ideally such a limit would need to be set per each MP capable TLV. > > This simply isn't what IS-IS is built for. We don't have defenses against an > inside attackers. > > As far as accidental, IS-IS has a built in limit; there is only so much room > in an router's LSP. But, more importantly, there's nothing special about > multi-tlv compared with regular TLVs here. > > Thanks, > Chris. > >> >> Thx, >> R. >> >> >> On Fri, Mar 28, 2025 at 9:47 PM Les Ginsberg (ginsberg) >> <ginsberg=40cisco....@dmarc.ietf.org> wrote: >> Med – >> V13 of the draft has been posted which addresses the logging text and the >> Security section text. >> There is then one open issue: >>>>> # Section 5 (*) >>>>> >>>>> CURRENT: >>>>> When processing MP-TLVs, implementations MUST NOT impose a >>>> minimum >>>>> length check. >>>>> >>>>> Agree... however, should we have a max of MP-TLVs to be used as a >>>>> guard for splitting the information into a large numbers of TLVs? >>>> >>>> [LES:] I see no reason to impose a maximum. Any number chosen would be >>>> arbitrary and risks becoming "too small" in the future. >>> >>> [Med] I'm not asking to pick a random max value, but to have a knob for >>> Operators to control a max based on their local policy. We need some guards >>> here. >>> [LES:] I am not comfortable specifying (or even suggesting) a max value. >> [Med] As I said earlier, I’m not asking for that. The exact value will be up >> to the taste of the operation. My request here is to give that control. >> It isn’t needed and I think introduces additional issues. >> [Med] misbehaviors from within networks happen, bugs and misconfiguration >> happen as well, etc. I still think the guard does not bring any issue, but >> fix them. >> The only reason an excessively large number of TLVs for the same object >> would be sent are: >> a)They are actually needed because of the amount if information required in >> a given deployment >> b)The sending implementation has a bug >> c)There is an attacker >> Regardless of the reason, the receiver has to deal with this. Specifying an >> arbitrary max isn’t going to help when the need is legitimate - and it >> obviously won’t help prevent the pathological cases. >> Note that Section 5 (last paragraph) provides guidance on how to deal with >> duplicated information. >> [Med] I’m afraid that para does not cover this point. >> [LES2:] Let’s dig a bit deeper here. >> You propose that each implementation locally choose a maximum value for the >> number of MP-TLVs it supports for a given object. >> Suppose that Node A chooses “2” and Node B chooses “3”. >> Both of them receive advertisements which have 3 MP-TLVs for a given object. >> What will happen? >> Node A will use 2 of the TLVs – Node B will use all 3 of the TLVs. >> Which means we are in an equivalent situation to having a node which doesn’t >> support MP-TLVs at all in the network. >> And we are vulnerable to the same problems – forwarding loops/black holes. >> One way of dealing with this would be to specify a global maximum instead of >> leaving it to individual nodes to choose a maximum. >> But this means if the number proves too small over time, we now have to do >> an upgrade and get all nodes to support a larger number. >> And even with a consistent maximum, receivers still have to deal with what >> ever they receive i.e., nodes cannot simply ignore the additional TLVs. Even >> if they don’t actively use the information in those TLVs they have to track >> all of the TLVs associated with a given object so that they become aware >> when that number falls into the acceptable range – noting that you don’t >> know which of the TLVs may be withdrawn in the next update. >> I appreciate the concern that you have – but imposing a limit isn’t going to >> help – it is only going to create additional problems. >> Les >> _______________________________________________ >> Lsr mailing list -- lsr@ietf.org >> To unsubscribe send an email to lsr-le...@ietf.org > > _______________________________________________ > Lsr mailing list -- lsr@ietf.org > To unsubscribe send an email to lsr-le...@ietf.org _______________________________________________ Lsr mailing list -- lsr@ietf.org To unsubscribe send an email to lsr-le...@ietf.org
