Subject: Re: Special handling for MaxSequenceNumber

From: Vivek Dubey <[email-masked]>
Date: Wed, 11 Feb 2004 00:58:44 -0000

Sandy,
Point is whether this needs to be addressed by:
1) Change in section 13.1(RFC 2328) - proposed by you.
OR
2) Change in section 13.4/14.1 (RFC 2328).

I am not very convinced with the change in (1) above yet.

Acee - Whether by draft/errata, depends on the solution agreed upon.

-Vivek

On Wed, 11 Feb 2004 Sandy Eng wrote :
>Vivek,
>
>Vivek Dubey wrote:
>>But just changing the order of comparisons (max age check before check sum)doesnt seems to solve the issue. What prevents "someone" from hacking the "age" if that can be done with "sequence number".
>>We'll again end up in same condition.
>
>Agreed with the fact that we are not attempting to prevent all hacks
>with this change. Just changing anything in an LSA content maliciously
>  changes the checksum right away, which by itself can cause a lot of
>damage. However, the adjustment proposed fixes the somewhat broken logic
>for MAXSequenceNumber LSAs by allowing the network to repair the spoof -
>let the MAXSequenceNumber LSA gets flushed first before re-originating a
>new LSA with InitSequenceNumber.
>
>If the age is spoofed, either a fake MAXAGE LSA will override, or a fake
>younger LSA will override (if the age difference between the spoofed and
>existing LSAs is more than MaxAgeDiff). In both cases, the router will
>eventually re-originate a new LSA with a larger sequence number. This
>new LSA should eventually get flooded.
>
>For the MAXSequenceNumber case, we need to make sure we have a way out -
>to allow a new LSA to get re-originated.
>
>Thanks,
>Sandy
>
>
>
>
>>
>>
>>P.S: Pls bear the rich text. I need to migrate my subscription to another ac.
>>
>>-Vivek
>>
>>
>>
>>On Tue, 10 Feb 2004 Acee Lindem wrote :
>>
>>>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
>>>
>>>----- Original Message -----
>>> From: "Sandy Eng" <[email-masked]>
>>>To: <[email-masked]>
>>>Sent: Monday, February 09, 2004 5:56 AM
>>>Subject: Special handling for MaxSequenceNumber
>>>
>>>
>>>
>>>>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: Sandy Eng <[email-masked]>
Date: Wed, 11 Feb 2004 01:10:33 -0800

Vivek,

> 2) Change in section 13.4/14.1 (RFC 2328).

How do you suggest changing 13.4/14.1?

-Sandy