Subject: Re: Special handling for MaxSequenceNumber

From: Vivek Dubey <[email-masked]>
Date: Fri, 13 Feb 2004 23:47:31 -0000

Inlined........<vivek>

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.
vivek> Rtr A just flushes its old LSA and then only goes to originate new instance.So checksum anomaly should not occur.
And in case of bug one more retransmission is not a "lot" of traffic.

If it were an attack, it is highly likely the attacker can be maliciously enough to send malformed packets out repeatedly.
vivek> Remember Age field is not checksum protected. By giving it weight over LS checksum we are making OSPF more prone to attack rather than saving it.       
Further, if it is hack, Seq No/Checksum/Age all three can be hacked, so by going for Age check before checksum, security is not enahanced.
But we'll be more vulnerable to software bugs as Age field is not checksum protected.

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).
vivek> I'll say this flooding is not "that" extra.

-Vivek

On Thu, 12 Feb 2004 Sandy Eng wrote :
>Vivek,
>
>Vivek Dubey wrote:
> >
> > 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.
>
>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).
>
>
> >
> > 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.
>
>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
>
>
>
>
> >
> > -Vivek
> >

---

From: Sandy Eng <[email-masked]>
Date: Fri, 13 Feb 2004 17:04:26 -0800

Vivek,

> And in case of bug one more retransmission is not a "lot" of traffic.

Rtr A could not flush its old LSA here. If the old LSA had a larger
checksum, when Rtr A comes up to receive this old self-originated LSA,
its MAXAGE LSA will not be accepted due to the smaller checksum, and the
same loop will happen here.

> But we'll be more vulnerable to software bugs as Age field is not checksum protected.

Again, we are only talking the specific case of MaxSequenceNumber LSAs
here, and as I mentioned in previous email, we are not attempting to
prevent all hacks with this change, but to give MaxSequencNumber LSAs
with MAXAGE a chance to go through the wrapping process, and in many
cases, this could repair the anomaly in the network.

> vivek> I'll say this flooding is not "that" extra.

I would think any extra flooding is an overhead, especially in a large
network with high number of links.

Thanks,
Sandy