Hi Roger, If R3 is able to modify R1’s LSA repeatedly, the rules for determining which instance is newer are moot. Other than MaxAging a LSA that times out, an OSPF router should never modify another router’s LSA. And this wouldn’t impact the checksum since the age isn’t included in the computation. Thanks, Acee
> On Apr 23, 2025, at 7:30 AM, Roger David <[email protected]> wrote: > > 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] <mailto:[email protected]> > > To unsubscribe send an email to [email protected] > > <mailto:[email protected]> > > _______________________________________________ > > Lsr mailing list -- [email protected] <mailto:[email protected]> > > To unsubscribe send an email to [email protected] > > <mailto:[email protected]>
_______________________________________________ Lsr mailing list -- [email protected] To unsubscribe send an email to [email protected]
