Hi Les & Chris, Sorry if I was not very clear but my point was that MP-TLV may be coming in multiple LSPs - something which to the best of my understanding is not the case today with any TLV type. On that basis as LSP length natural boundary is gone it seems sky is the limit now.
Many thx, R. On Sat, Mar 29, 2025 at 1:03 AM Les Ginsberg (ginsberg) <ginsb...@cisco.com> wrote: > Robert – > > > > Respectfully, it is obvious that the memory used to store the LSPDB is not > altered by what portions of the LSPDB are actively used by the protocol. > > > > Your comment on duplicates seems to completely forget why MP-TLV is needed. > > > > Les > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Friday, March 28, 2025 4:35 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* mohamed.boucad...@orange.com; The IESG <i...@ietf.org>; > draft-ietf-lsr-multi-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; > yingzhen.i...@gmail.com > *Subject:* Re: [Lsr] Re: Mohamed Boucadair's Yes on > draft-ietf-lsr-multi-tlv-11: (with COMMENT) > > > > Hi Les, > > > > As has been stated multiple times before…there is nothing today – without > MP-TLV support – that prevents an attacker from sending many TLVs for the > same object. Introduction of MP-TLV does not alter that attack vector. > > > > I am not sure about that. Tell me what I am missing ... > > > > If I get 5 TLVs today without MP-TLV I still store only the latest. > > > > If I however get 5 MP-TLVs tomorrow with MP-TLV I need to store all 5 > chunks of it. > > > > In both cases I need to reflood all so from that perspective you are right > this is no different. But I was not concerned about reflooding but local > node resources to store then in LSDB. > > > > As was discussed in this thread with Med, if anything the addition of > MP-TLV support makes an implementation better equipped to handle such > attacks since MP-TLVs are recognized and not treated as duplicates. > > > > To me, treating as duplicates is actually safer node wise, while same > network wide. > > > > R. > > > > > > Les > > > > *From:* Robert Raszuk <rob...@raszuk.net> > *Sent:* Friday, March 28, 2025 2:59 PM > *To:* Les Ginsberg (ginsberg) <ginsb...@cisco.com> > *Cc:* mohamed.boucad...@orange.com; The IESG <i...@ietf.org>; > draft-ietf-lsr-multi-...@ietf.org; lsr-cha...@ietf.org; lsr@ietf.org; > yingzhen.i...@gmail.com > *Subject:* Re: [Lsr] Re: Mohamed Boucadair's Yes on > draft-ietf-lsr-multi-tlv-11: (with COMMENT) > > > > 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. > > > > 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
