Subject: Special handling for MaxSequenceNumber

From: Sandy Eng <[email-masked]>
Date: Mon, 9 Feb 2004 02:56:07 -0800

Hi all,

A proposal to add special handling to RFC 2328, Section 13.1
"Determining which LSA is newer", for LSAs with MaxSequenceNumber.

Scenario:
=========

Rtr A  -------------- Rtr B

1) Rtr A receives a corrupted self-originated router-LSA, due to attack
or software bug, with MaxSequenceNumber and different LSA content. Rtr A
  thinks it receives an old router-LSA, and tries to wrap the sequence
number and maxages this LSA, before re-originating a new lsa.

2) If Rtr B has already received this corrupted packet, and later
receives the MAXAGE LSA from Rtr A, due to a higher checksum value
(comparison based on Section 13.1, RFC 2328) of the malformed packet, it
thinks its LSA is newer and sends it back to Rtr A.

3) (1) - (2) repeats itself continuously. Meanwhile, Rtr A keeps
retransmitting the MAXAGE lsa as it receives no ACK from its neighbor(s).

Proposed adjustment to Section 13.1, RFC 2328
=============================================

For the above scenario, if both the received and existing LSAs have
MaxSequenceNumber, it would only make sense to compare the age next :

if (both received and existing LSAs have MaxSequenceNumber) {
  if (Both LS ages are different) {
    swap second and third bullet in Section 13.1 :
    - proceed to compare age - third bullet in Section 13.1
    - then compare checksums - second bullet in Section 13.1
    ...
  }
  else
    - proceed as normal with checksums - second bullet in Section 13.1
}

This adjustment is in line with what the RFC intended for a
MaxSequenceNumber LSA to do when wrapping - flush before originating a
new one, which is a special case. This modification is just ensuring
this to be working as intended.

With all the security concerns we face today in the network, I think
customers would appreciate this extra ensurance. Knowing a lot of
networks today do not reach MaxSequenceNumber, tempering with packets by
setting MaxSequenceNumber is too easy a hack to take down a network.

With backward compatibility in mind, we can address this case for
MaxSequenceNumber in our RFC.

Please comment.

Thanks,
Sandy

Acee Lindem wrote:
> Sandy, Peter,
> In thinking about it more, it will really be a pain to
> purge an LSA that isn't actually installed (in this case I'm
> referring to the MaxSequenceNumber LSA received by
> the originator). Hence, it may not be that bad to go with
> your suggestion to change the order of comparisons for
> the case where the sequence number is at MAX. Since it
> broken for this case I don't see this as a severe backward
> compatibility problem.
>
> Can you take it to the list since you (or some testing your
> product) originally discovered the problem.
>
> Thanks,
> Acee
>

---

From: Acee Lindem <[email-masked]>
Date: Tue, 10 Feb 2004 10:08:58 -0500

This is a real situation that can occur is someone spoofs a
MaxSequenceNumber LSA with a higher checksum than
the real one. We discussed alternatives to fixing this. The other  we
discussed was the advertising router purging the errant more recent
LSA prior to re-originating a new one with InitialSequenceNumber.
It seemed more difficult since you'd need to reliably flood an LSA
that you don't install.

Comments?

Irrespective of the solution - should we handle this with RFC
errata or a short draft?

Thanks,
Acee