Subject: Re: Special handling for MaxSequenceNumber

From: Vivek Dubey <[email-masked]>
Date: Wed, 11 Feb 2004 21:47:09 -0000

1) Rtr A - Restarted.
2) Rtr B - Holds LSA X (MaxSequenceNumber) originated by Rtr A before  
           Rtr A got restarted.
3) Rtr A - Receives self originated LSA X with MaxSequenceNumber.
4) Two cases here:
   a) Rtr A in a new session has already originated LSA X:
      a1) Rtr A flushes the LSA X from routing domain by incrementing  
          the age to MaxAge.
      a2) Originates the new instance.
   b) Rtr A no longer wishes to originate LSA X:
      b1) Rtr A flushes the LSA X from routing domain by incrementing  
          the age to MaxAge.
Till here it is assumed, there is no hack(normal scenario) and checksum of LSA X is same i.e 
Lsa X present in Rtr B and MaxAge LSA X now sent by Rtr A.
So the problem does not occur.
But as pointed out, somehow the checksum of LSA X at Rtr B is higher than that of MaxAge LSA X flooded by Rtr A.

5) Rtr B sends its copy of LSA X to Rtr A.
6) So we again hit case (4) above. And as Sandy pointed out, this loop should be broken.

My thinking is, it would be better if the issue is solved at the senders side (Rtr A) rather than at the receivers side (Rtr B).

7) Rtr A should MaxAge the received LSA, and put this one on the  
   retransmission list removing the one with LSA checksum less, and 
   should flood it out.
8) When Rtr B receives this MaxAge LSA X (checksum anamoly) should be 
   taken care off.

Unless until somebody is repeatedly hacking the LSAs, very unlikely. 
The most likely reason we can hit the problem is because of some software bug. 
Thats one way i can think off, as of now.

-Vivek

---

From: Sandy Eng <[email-masked]>
Date: Wed, 11 Feb 2004 16:33:43 -0800

Vivek,

> 8) When Rtr B receives this MaxAge LSA X (checksum anamoly) should be

Acee and us had exactly the same discussion beforehand. The above will
take a bit more work :

1) Rtr A tries to flush the MaxSequenceNumber LSA first.

2) Rtr B thinks its LSA is newer due to the larger checksum, and sends
it back to Rtr A.

3) Rtr A sees this LSA, it will then flush this newer LSA as you
mentioned above.

If we just adjust the comparison routine, then right at (2) above, Rtr B
knows that it will take the MAXAGE LSA instead. This saves the extra
flooding effort of (2) and (3).

> Thats one way i can think off, as of now.

Imagine the case when Rtr A is replaced with another vendor's router, or
a new version of software, loaded with the same config. Take the
nebulous case when a router in NSSA does not *have* to have the N-bit
set in a router-lsa (perhaps this is something we can re-define as well
for the NSSA draft). This new hardware/software sets this bit in its
router-lsa's option, whereas the old Rtr A didn't - of course we are
assuming a network segment in NSSA here.

An LSA with one bit of difference with the rest of the LSA content the
same yields marked different checksum. In this case, the LSA with option
0x20 (old Rtr A) yeilds a larger checksum than option 0x28 (new Rtr A).

If a bunch of routers in the network are transitioning
hardware/software, you will have a network stuck in this packet storm of
retransmission loops. Here is not an intentional attack. If it were an
attack, it is highly likely the attacker can be maliciously enough to
send malformed packets out repeatedly.

Thanks,
Sandy