> 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
