Subject: Re: Stupid checksum and next LSA begining question

From: "Naidu, Venkata" <[email-masked]>
Date: Thu, 18 Sep 2003 11:58:27 -0400

Hi Acee,

-> As Mitchell points out, the LSA length may be wrong.
-> However, this is no
-> reason to discard the
-> whole packet since there is also a good possibility that the
-> LSA length is correct

  There is a good *probability* that the subsequent LSAs are
  correct. Take for example, a bit in an LSA length field is
  flipped then the Fletcher checksum calculation fails. But that
  LSA length field might have been wrong because of the flip.

  Before going ahead processing the OSPF packet, we first
  authenticate the packet. The probability that an OSPF packet
  getting valid even after some bit-errors in an LSA is very
  very less.

  I agree that OSPF packet checksum is not a strong checksum.
  For example, if any two 16-bit words are swapped then the
  checksum will be still valid.

  Unfortunately, there is no mechanisms defined in routing
  protocols for simple "error corrections" (we worry about
  "error detections" only). This is a good research area. But,
  still, the reason we don't do that is because the corruption
  may not necessarily be on the wire. It could be flooding
  router's database storage may be corrupted.

  That said, It is not just the problem with OSPF. Historically,
  many protocols suffer from this. For example, IPv6 header
  doesn't carry checksum any more. IPv6 trusts lower layer (L2)
  checksum on hop-by-hop packet integrity and higher layer
  (transport protocol) checksum on end-to-end integrity.

  If a bit is flipped in IPv6 destination address, can you
  think what is going to happen ? The packet is going to end
  up some (unwanted) destination. Of course, IPsec is mandated
  in IPv6...etc etc.

  But, what is going to happen if some bit-errors occur in
  IPv6 Next Header. How is IPv6 going to process options
  correctly ?

Venkata.