Hi Chris, ISIS core code can be pretty robust, safe and pretty well control what LSPs are advertised and when. Of course everyone should protect ISIS domain from any external influence too.
But here MP-TLV is really a special widening of the above original limits with pushing this responsibility to in some cases not routing applications. So I am of the opinion that extra precautions would not hurt if we expose those to operator's. I have no shadow of a doubt that few solid ISIS implementations will have internal checks to keep it safe. But I also do not see harm in explicitly allowing operators a bit more control to the expected number of fragments of given TLV. In any case I just wanted to voice how I read Med's comments. Regards, R. On Fri, Mar 28, 2025 at 11:28 PM 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
