Subject: junk checksum and next LSA are not processed properly

From: Praveen C <[email-masked]>
Date: Fri, 15 Oct 2004 11:55:41 +0530

Hi Group,

    If we have a "update packet with say 3 LSAs", and the 1st LSA in
this packet has a checksum error, should the rest of the LSAs in the
update packet be attempted to be processed ?

    Note:  The check sum error means, there is change in length field of
the first LSA

    RFC 2328 page 142 section 13 says:
   " Validate the LSA's LS checksum.  If the checksum turns out
      to be invalid, discard the LSA and get the next one from
      the Link State Update packet. "

    In this case we could assume that checking the type of the next LSA
could be within a valid LSA type range, and still not  have the correct
beginning of the 2nd or 3rd  LSAs.

    Is this behavior specified anywhere?

    Thanks in advance.

Regards,
Praveen

---

From: Keng <[email-masked]>
Date: Fri, 15 Oct 2004 09:50:54 -0400

Praveen,

I think the answer is "yes. You should continue to process the other lsas
in the packet even when you encounter one or more lsas in the packet that
failed the checksum verification. The text you quoted from the rfc tells
you exactly what the implementation should be doing.

regards,
Keng

---

From: Praveen C <[email-masked]>
Date: Fri, 15 Oct 2004 20:29:18 +0530

Hi ,

    Thanks for the quick reply.

    If the checksum error is because of changes in length field of first LSA,
in  this case we should not process the LSA using the length field or is there
any other alternative ?

Thanks,
Praveen.

---

From: Erblichs <[email-masked]>
Date: Fri, 15 Oct 2004 12:53:22 -0700

Group,

        Interesting...

        First, I question that you actually know what
        the "valid" length of the first LSA is since
        one or more fields are invalid or the chksum
        itself is invalid.

        If the pkt is repeatedly sent that way,
        the recv'd router would ignore all the
        LSAs from the sending router and effectively
        blackhole that router.

        ** Assuming that you ignore that the chksum is
        also a validation of length, type, etc fields.

        If 1 LSA is invalid, the Update pkt needs to be
        resent anyway. The overhead in processing the
        pkt with 1 less LSA is minimal.

        Why would you insert new LSAs into the LSDB
        that has invalid information?

        Additionally, instead of running just 1 SPF
        calc for the valid recieved LSAs, by processing
        two pkts, if they are new LSAs, we will most
        likely need to run 2 SPF calcs.

        This and more, would suggest to at least me
        that upon chksum failure the pkt should be
        discarded.

        The negative effects is that one or more LSAs
        would have to be transmitted. If these LSAs
        the rexmit interval should be small enough
        that it the additional time should be
        insignificant.

        Additional issues reside in what to do if
        you process a fewer number of LSAs than was
        then stated in the Update pkt? Can you/should
        you back out the previously inserted LSAs from
        your LSDB?

        Mitchell Erblich
        -------------------

---

From: Michael J Barnes <[email-masked]>
Date: Sun, 17 Oct 2004 13:34:25 -0700

Hi Mitchell,

>         one or more fields are invalid or the chksum

If the length field turns out to be invalid, then when you try to process
the next LSA and you're not looking at the beginning of that LSA packet,
then you won't get the correct checksum for it either and will skip it
too. You may waste a few cpu cycles this way (as opposed to quitting as
soon as one bad LSA is found) but if it turns out that the length field is
correct you're a lot better off by processing the rest of the LSAs.

>         LSAs from the sending router and effectively

And this is good? I don't think so.

>         pkt with 1 less LSA is minimal.

But the LSA is probably invalid in the sender's memory, if it was
corrupted on the wire then the checksum for the packet would fail. So
unless the sender is checking the checksums before putting the LSAs into
the packet, it will continue to send this bad LSA.

>         that has invalid information?

I don't think anyone is suggesting to do this. I would certainly say this
would be the wrong thing to do.

Regards,
Michael

---

From: Erblichs <[email-masked]>
Date: Sun, 17 Oct 2004 16:09:29 -0700

Group, et al,

        Bottom line..

        The reason for doing a chksum validation is
        to validate the pkts contents.

        If you are still going to process the pkt
        regardless of the chksum, then why spend
        the CPU cycles to check the chksum in the first
        place?

        Mitchell Erblich
        ---------------------

> correct you're a lot better off by processing the rest of the LSAs.

        Wow...
        The Update pkt has a invalid chksum. Their is
        one chksum for the entire Update pkt. Some
        fields you could do some minor validation to
        know if they are out of bounds, however, how do
        you know what that say the router-id is valid?

> the packet, it will continue to send this bad LSA.

        The the sender should be removing this LSA from its
        LSDB/memory when it does a chksum validation.

---

From: Michael J Barnes <[email-masked]>
Date: Sun, 17 Oct 2004 18:18:15 -0700

>         you know what that say the router-id is valid?

No, that's not what I meant. We're talking about the LSAs, not packets. If
the packet has a bad checksum then of course you don't use it. I was
referring to the LSA's checksum, as was Praveen in his question.

Michael

---

From: Acee Lindem <[email-masked]>
Date: Mon, 18 Oct 2004 09:29:09 -0400

I agree totally with Michael and this is also consistent with
RFC 2328. The outcome of the LSA header checksum calculation
should not affect processing of subsequent LSAs in the same
Link State Update packet.

With respect to concerns about a corrupted header length, one
should assure that the LSA header length doesn't exceed the
bounds of the current Link State Update packet (and this
is independent of the LSA header outcome).

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Mon, 18 Oct 2004 11:52:57 -0700

Acee and Michael,

        Yes, same diff. Acee see below.

        After the 16 bit chksum field is the 16 bit
        LSA header length field.

        How do you know that in a series of LSAs
        within a Update pkt, that if #1 has a
        corrupted chksum that the corruption is
        not at the length field?

        You can do some minor age, type, etc
        field validations, but how do you validate
        a LSA header length field? Without knowing
        the value of that field, how do you know the
        begining of the next LSA header???? Only,
        the corrupted LSA, is the last LSA, then you
        can make this length check.

        (Yes, you
        can see if the length or summed LSAs lengths is
        greater, equal, or less than, to what was
        specified in the Update pkt length field. But
        it won't get you anywhere if it was short.
        You can also check LSAs counts.)

        IMO, At that point, the most careful thing is
        to stop processing the LSAs within the
        update packet.

        The worst thing that will happen is a resend
        of the LSAs not acked. Since the overhead is
        in the processing of the pkt and it will
        be needed to be resent anyway (we assumed that
        we had at least 1 bad LSA anyway), making it just
        a we bit shorter by attempting to process additional
        LSAs should be insignificant.

        Their may be minor bandwidth issues with
        wireless links, but I assume that LSDB
        consistency would be a much larger concern.

        So Acee Lindem what do we save/gain when you attempt
        to process later LSAs after you see that one has
        been corrupted???????

        Or what was the motivation to specify this in the
        RFC?

        Mitchell Erblich
        ----------------

---

From: Acee Lindem <[email-masked]>
Date: Wed, 20 Oct 2004 16:03:48 -0400

Hello Mitchell,

At a general level one could argue that attempting to process LSAs
subsequent to the one with the bad checksum is consistent with
Jon Postal's Robustness Principle "be liberal in what  you accept
from others".

Specific OSPF, I think it makes more sense to continue since there
are many ways for a checksum error to be introduced and a bad
length is only one of them. For example, if there is a software bug
in the transfer from the Link State Database to the packet (or the
constuction of a self-originated LSA) continuing processsing LSAs
could help narrow down which LSA is in error (eventually, it will be
the only one on the neighbor's retransmission list).

I'm not sure we are going to come to agreement on this. However,
RFC 2328 is not going to be amended unless there is a clear majority
who believe the current behavior is broken.

Thanks,
Acee

---

From: Erblichs <[email-masked]>
Date: Wed, 20 Oct 2004 17:30:03 -0700

Acee Lindem,

        Let me start off that I first attempted to
        follow the RFC suggested approach without
        checks for validating the LSA length. In
        actuality, the length is also transparently
        validated by the next LSAs chksum computation.

        And my issue is when a length from a early LSA
        is bad when a chksum validation fails.

        First, I see us trying to achieve a Trusted
        Network environment and not relying on
        unverifyable information. We do this with:
           IPvX CRC chks, header chksums,
           v2 and IPv6 authentication, TCP's ISS, TCP's
           Syn attack protection, etc)
        To have made OSPF robust with respect to this
        type of  "rare" event (length and chksum err)
        and being efficient, probably would probably have
        required the ability to Request LSAs in a different
        order, however..

                Acee see the bottom of this email section
                for what I would suggest as a transparent
                change.

        Once we accept a LSA for forwarding, it is
        our responsibility that the the cksum remains
        valid.

        Circular buff error msgs pointing to the first
        LSA with a particular problem would be my
        first thing to look at than rexmit lists. The
        msg could be displayed by the sender upon each
        nbr rexmit and by the recvr's Update processing
        routine.

        IMO, LSDBs are incremntally walked to often,
        LSAs placed on rexmit lists, that trying to
        see one LSA staying on the list would be fairly
        difficult. Maybe in small networks it might
        not be an issue.

        IFF the length was also an issue with the chksum
        failure, I don't see that any further LSAs will
        be processed within the Update. If this occurs
        and every LSA is walked and noted as a msg, you
        would not know the offending LSA. Each LSA would
        still be in the rexmit list. This is NOT robust.

        However, if only the first LSA within a Update
        was noted as an error/msg, you know that at least
        each reported LSA is actually bad with a failed
        chksum. Seeing the same LSA err msg over and over
        is easier to see.

        However to be fair, it probably would still
        be "acceptable" to chk the next LSA in the Update.
        However, if that chksum failed and say the
        LSA type was out of bounds, etc, I would think
        you would want to get a fresh Update because the
        length may be an issue.  If you actually had a
        transient problem with just 1 LSA you would see
        only one msg vs displaying a large number of
        secondary msgs for the other skipped LSAs.
        Remember, we are supposely dealing with a rare
        event. If that nbr chksum "event" was noted
        and you are concerned that 1 or more LSAs may
        be valid behind the bad LSA, you could attempt
        to process them. But the hope was that the bad
        LSA was a transient event that was corrected with
        the rexmit. IMO, if a number of LSAs are repeatedly
        being rexmit'ed, then.....

         Lastly, I thought I was told that under a chksum
        failure the during a LSDB walk, the router would
        reboot. This was discussed when DNA LSAs could
        be sent in Demand Circuits.
        This effectly removes the router from the env.

           Thus, if I were to suggest any changes to the
        RFC, I would suggest that upon each rexmit from
        the nbr rexmit queue, the LSA order be shifted
        by 1 in a circular manner. IMO, this would add
        a level of robustness by preventing a single
        LSA with a bad length preventing later LSAs
        from being accepted.

        Mitchell Erblich

        -----------------------------

---

From: Acee Lindem <[email-masked]>
Date: Wed, 20 Oct 2004 22:38:50 -0400

Hi Mitchell,
I don't think that such an approach is necessary and it
seems that the suggested change to the retransmission processing
is simply a consequence to modifying the LS update LSA
reception to bail out once an LSA with an invalid checksum is
encountered. However, you are welcome to submit a draft documenting
the problem and suggested solution for review by the WG.

Thanks,
Acee