Les, Again, you are wholly incorrect. I see no point in reiterating. Please stop.
Regards, Tony > On Oct 12, 2025, at 7:53 PM, Les Ginsberg (ginsberg) - ginsberg at cisco.com > <[email protected]> wrote: > > Tony - > > I am motivated to send an additional response because I believe there are a > set > of facts on which we should be able to agree - but the words which have thus > far > been used to characterize behaviors are misleading - in particular your > statement that HSNP hash collisions are: > > "exactly analogous to the situation with CSNPs". > > As we have both discussed in this thread, it is possible (though unlikely) > that > during LSP transmission an LSP is received which matches that in the > receiver’s > database i.e., same (LSPID, sequence #, checksum) but has different data. > This could occur because > of corruption during transmission which does not alter (LSPID, sequence #) > but (unluckily) leaves the same checksum as still valid for the corrupted > data. > > It might also occur if a node restarts, generates a new version of an LSP > which matches that of a stale LSP from its previous incarnation in > (LSPID, sequence #, checksum) but differs in some portion of the data. > (This latter case is limited to small LSP sequence numbers). > > But neither of these unlikely events has anything to do with CSNPs (or > HSNPs). The collision is a vulnerability in the LSP flooding procedure which > cannot be detected or corrected by CSNPs or HSNPs. > > (NOTE: More on how to close this vulnerability below.) > > What is introduced by the use of HSNPs is something quite different. A new > hash calculation is introduced which summarizes the (LSPID. Sequence #, > checksum) tuples for (a portion of) the LSPDB. This introduces > the possibility that the hash calculated over a range of LSPs by two > neighbors might match even though the state of the > LSPDB on the neighbors for that range differs. This (admittedly unlikely) > possibility exists with HSNPs - does not exist with CSNPs as they do not such > hash calculation. > > We may have different opinions on the significance of this - but we should be > able to agree that this is a new vulnerability introduced by HSNPs. > > I hope we have agreement on the above. > > My original post was only meant to express my opinion as regards whether > HSNPs are a desirable solution. Given the added vulnerability and the > likelihood that at scale the compression benefits of HSNPs will not be > realized > (see my original post for more details on that) I am not enthused about > the HSNP proposal. I understand that you feel differently. > > Thanx for continuing to listen. > > Les > > Additional note: If we wanted to eliminate the LSP flooding vulnerability, > we would need to amend the procedures to be followed when receiving an > LSP that matches an existing LSP in the receiver’s database (i.e., same > (LSPID, sequence #, checksum). > > ISO 10589 7.3.16.2 would need to be amended to say something like: > > <snip> > If (LSPID, Sequence #, checksum) match the receiver should perform > a comparison of the data in the received LSP to that in the matching LSP > currently stored in the receiver’s database. If there is any difference the > receiver should: > > o purge the LSP if the originator of the LSP is some other system > o increment the sequence # and flood a new version of the LSP if the > receiver is the originator of the LSP, > <end snip> > > If you want to further discuss whether such an amendment to the spec is worth > doing, please start a separate thread. I am open to the idea of doing so … > > From: Tony Li <[email protected] <mailto:[email protected]>> On > Behalf Of Tony Li > Sent: Monday, October 6, 2025 10:54 PM > To: Les Ginsberg (ginsberg) <[email protected] <mailto:[email protected]>> > Cc: Tony Przygienda <[email protected] <mailto:[email protected]>>; > [email protected] > <mailto:[email protected]>; lsr <[email protected] > <mailto:[email protected]>> > Subject: Re: [Lsr] Further Comments on draft-prz-lsr-hierarchical-snps > > > Les, > > > When an LSP is received, the receiving IS validates the checksum. If the > checksum is invalid, the LSP is discarded – which means the transmitter will > be forced to retransmit (SRM bit is not cleared). > > > True, but irrelevant. > > > > So an LSP with invalid checksum will never be placed in the receiver’s > database. ISO 10589 7.3.14.2e. > > > True, but also irrelevant. > > > > Which means if a CSNP entry with that invalid checksum is received the > receiver will not find a match in its database and will follow ISO 10589 > 7.3.16.2. > > > We are not discussing CSNPs with invalid checksums. > > > If an LSP is received, checksum is validated, but the data in the LSP is in > some way different than what is in the LSP in the transmitters DB, then we > still have the actual TLV content which is in some way corrupted. In a robust > implementation the corrupt information would be detected and not used. > > > We are not discussing LSP corruption here. > > > > Now, you seem to be trying to equate this last case with a hash collision in > an HSNP where the range of LSPs covered by an HSNP advertisement incorrectly > collides with the hash calculated by the receiver over the same range. But in > such a case, we have one or more LSPs which have not been synced between the > two systems. Either an LSP doesn’t exist at all in one database or a > different version of that LSP exists – and you are trying to say that lack of > an entire LSP is equivalent to having the same LSP in both databases when > some bits in the data are different. > > > No. That’s not what I’m saying at all. Please reread my mail. The point is > simple: CSNP’s are not 100% reliable. There can be checksum collisions. > > > > But I am not warming to the idea of introducing new ways to compromise > flooding integrity in the name of efficiency. > > > Your opinion is duly noted. We are not compromising flooding integrity at > all, but if you will not discuss reality, I cannot help you. > > Regards, > Tony
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
