Subject: Re: [lisp] #7: LISP ETRs ignoring checksum value in LISP UDP outer header on decapsulation

From: [email-masked] (Noel Chiappa)
Date: Fri, 21 Aug 2009 17:20:09 -0400 (EDT)

> From: Sam Hartman <[email-masked]>

    > What data if any do we have about how common these broken forwarding
    > boxes are and to what extent we need to c are about them?

There was this message a few days back:

    >> From: "Darrel Lewis (darlewis)" <[email-masked]>
    >> Subject: RE: [lisp] Judging Consensus on the UDP Checksum Issue
    >> Date: Tue, 11 Aug 2009 10:25:56 -0700
    >> Message-ID: <[email-masked]>

    >>> I would expect a NAT that saw a zero value to not recalculate the checksum.

    >> We found this not to be the case in our testing of LISP. Many
    >> commercial (netgear and linksys being two that come to mind) NATs do
    >> indeed recalculate the checksum regardless of its initial value.

Needless to say, these are both very, very common boxes. Not sure if all models
have this problem, or just some...

	Noel

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Fri, 21 Aug 2009 14:26:19 -0700

>     >> Message-ID: 
> <[email-masked]>
> 

Noel,

I want to be clear above, the IPv4 packet's checksum is changed from 0
to a non-zero (but correct) value on the NAT'd packet.  Sorry if this
was unclear.

-Darrel

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 22 Aug 2009 19:53:09 -0400

Hi Darrel,

> I want to be clear above, the IPv4 packet's [UDP] checksum is  
> changed from 0

Thanks for the clarification.  This makes a _big_ (and very positive)  
difference in the discussions we've been having!

Since these packets will contain a valid UDP checksum value, they will  
not be thrown away by an ETR checks non-zero checksums.  Doesn't this  
remove our justification for forbidding ETRs from checking these  
checksums?

I agree with Noel that this is still a bug, because it gives a false  
assurance of end-to-end integrity, but it is a _much_ less heinous bug  
than I had previously understood.

Margaret