Hi Acee and Robert, Lots of thanks for your valuable responses. I will try to present my learnings with a simple ring topology of 3 nodes: R1, R2, R3
1. R1 generates an LSA with seq 1 and checksum x and sends it to both of its neighbors: R2, R3. 2. R3 receives this LSA directly from R1. This LSA instance has checksum x. It passes the checksum check and installed in database. 3. R2 receives this LSA from R1 and is expected to flood it to R3. But there is a problem in R3 (SW bug or intentional) due to which R3 modifies some content of this LSA in such a way that LSA ID and sequence number is unchanged but checksum changes to y (where y > x). It then sends this new LSA instance to R3 4. R3 receive this new LSA instance from R2. It also passes the checksum check. But now it must decide which one of two LSA instance to consider as recent. Based on below, it chooses LSA with checksum y 4. R3 would also flood this new LSA instance back to R1 5. R1 has now received back self-originated LSA and as per section 13.4,R1 should re-originate this LSA with seq to 2 6. Hoping R3 works correctly now, we should have all network nodes using LSA with seq 2. But in case R3 keeps doing this nuisance, this LSA would never be stable in network Pls. help to confirm. Thanks Roger -----Original Message----- From: Acee Lindem <[email protected]> Sent: Wednesday, April 23, 2025 7:14 PM To: Robert Raszuk <[email protected]> Cc: Roger David <[email protected]>; lsr <[email protected]> Subject: [EXTERNAL] Re: [Lsr] OSPF RFC 2328 | Tiebreaker based on LSAs checksum I agree with Robert. Thanks, Acee > On Apr 23, 2025, at 8:47 AM, Robert Raszuk <[email protected]> wrote: > > Hi Roger, > > > But lets say some intermediate router (with a non-pleasant > > intention) modifies the checksum to a larger value before flooding it. > > My understanding is that both OSPF and ISIS do not have any protection from > insider's attacks. They are completely vulnerable protocols (modulo > authentication). That means that once you let a bad guy into the pool the > game is over. > > If I recall that check you quote in selecting which flooded LSA with the same > sequence number should be used is there just for area computational > consistency (ie. to make sure the very same LSA is used by all nodes in a > flooding scope). > > Thx, > Robert > > > On Wed, Apr 23, 2025 at 2:27 PM Roger David > <[email protected]> wrote: > Dear Authors, > Greetings ! > I have a question on the highlighted text of the RFC (see snip below) where > it clarifies that Router should select the LSA with larger checksum as the > most recent one. > As I know, originator router is the one that initializes the checksum of the > LSA and this shall not be modified by any intermediate routers during > flooding. > So in an ideal situation, all routers in the network would receive this LSA > with the exact same checksum. > But lets say some intermediate router (with a non-pleasant intention) > modifies the checksum to a larger value before flooding it. It could cause > entire network to believe that this instance of the LSA is the most recent > one. > Could you pls. clarify or correct my incorrect understanding. > <image001.png> Roger David > Architect, Verification Engineering > Reliable Tech Park | Navi Mumbai, India > Mobile: +91 8308227212 > <image002.png> > > Disclaimer > This e-mail together with any attachments may contain information of Ribbon > Communications Inc. and its Affiliates that is confidential and/or > proprietary for the sole use of the intended recipient. Any review, > disclosure, reliance or distribution by others or forwarding without express > permission is strictly prohibited. If you are not the intended recipient, > please notify the sender immediately and then delete all copies, including > any attachments. > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected] > _______________________________________________ > Lsr mailing list -- [email protected] > To unsubscribe send an email to [email protected]
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
