Subject: Re: junk checksum and next LSA are not processed properly

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

----- Original Message -----
From: "Acee Lindem" <[email-masked]>
To: "Mailing List" <[email-masked]>
Sent: Wednesday, October 20, 2004 4:03 PM
Subject: Re: junk checksum and next LSA are not processed properly

> 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).

And even if the errors are logged with the LSA is identified (as I remembered
that I do ;^), reducing the impact of  the error by allowing any valid subsequent
LSAs to be be flooded and used by other OSPF routers in the OSPF routing
domain is a good thing.

>
> 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
>
> ----- Original Message -----
> From: "Erblichs" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, October 18, 2004 2:52 PM
> Subject: Re: junk checksum and next LSA are not processed properly
>
>
>> 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
>>        ----------------
>>
>> Acee Lindem wrote:
>>>
>>> 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
>>>
>>> ----- Original Message -----
>>> From: "Michael J Barnes" <[email-masked]>
>>> To: <[email-masked]>
>>> Sent: Sunday, October 17, 2004 9:18 PM
>>> Subject: Re: junk checksum and next LSA are not processed properly
>>>
>>> >> Michael J Barnes wrote:
>>> >>
>>> >>>Hi Mitchell,
>>> >>>
>>> >>>Erblichs wrote:
>>> >>>
>>> >>>>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 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.
>>> >>>
>>> >>         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?
>>> >
>>> > 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: Michael J Barnes <[email-masked]>
Date: Wed, 20 Oct 2004 13:14:05 -0700

Right on! ;-)