Re: [lisp] IPv6 UDP Checksum Offload Hardware and Software

[Greg Shepherd <[e-mail]>]

On Wed, Aug 12, 2009 at 1:59 PM, Margaret Wasserman<[e-mail]> wrote:
>
> On Aug 12, 2009, at 4:40 PM, Greg Shepherd wrote:
>>>
>>> The current LISP specification requires ETRs to _all_ UDP checksums
>>> received
>>> in the outer header of encapsulated data packets, not just ones that are
>>> set
>>> to zero.  So, even if the ITR did calculate a checksum and insert a
>>> non-zero
>>> value into the UDP checksum field, the receiving ETR would not check it.
>>
>> An ITR won't do that. IF it did it is violating the LISP spec:
>>
>> "UDP Checksum:  this field MUST be transmitted as 0 and ignored on
>>     receipt by the ETR.  Note, even when the UDP checksum is
>>     transmitted as 0 an intervening NAT device can recalculate the
>>     checksum and rewrite the UDP checksum field to non-zero.  For
>>     performance reasons, the ETR MUST ignore the checksum and MUST not
>>     do a checksum computation."
>>
>> So let's limit our assumptions to the possible.
>
> It is certainly possible that a LISP ETR will receive an encapsulated LISP
> data packet with a non-zero UDP checksum.

True, but that's not what you stated above. I'm both reading and
responding in kind.

> The LISP spec documents at least one case where this could happen -- the UDP
> checksum could be changed by a NAT box or otherwise corrupted in transit.

Which is different than the ETR setting a non-zero checksum as I was
addressing above.

> Also, there are a lot of widely-deployed systems that offload the checksum
> to hardware, and on those systems it may not be possible to turn off
> checksum calculation for outbound packets.  So, those systems will send
> encapsulated LISP packets with non-zero checksums.

Show me one such system that has a LISP implementation. Again, let's
stick with the possible here. We're developing the spec now for LISP
implementations to follow.

> Dino has already agreed to change the text for LISP -04 to say:
>
> "An ITR MAY send a zero checksum, an ETR MUST accept a 0 checksum and MAY
> ignore the checksum completely."  (or something similar from Sam)
>
> So, this implies that ITRs may also send non-zero checksums.

Yes, a compromise to put this behind us and move on. :)

> Personally, I would greatly prefer to retain the ability to enable UDP
> checksums in LISP, just in case we ever find out that there are significant
> operational problems caused by our choice to ignore decades of research and
> experience that indicate that it is a bad idea to do so.

Can you please site such research, specifically for zero checksums in
UDP encapsulated headers where the inner header checksum is non-zero?
I clearly need to learn more.

>>>
>>> - Avoid the performance overhead of calculating UDP checksums.  The
>>> current
>>> spec proposes we do this by having ITRs set the UDP checksums in the
>>> outer
>>> headers LISP encapsulated data packets to zero.  This is fine in IPv4,
>>> compliance-wise, but is forbidden by RFC 2460.  Marshall Eubanks has a
>>> draft
>>> out to allow this in IPv6, as well.
>>
>> Yes, I'm aware of Marshall's draft. And the motivation for his draft
>> was not LISP but AMT, so you can see the disallowing of zero checksums
>> of an outer header is not unique to LISP. Clearly RFC 2460 overlooked
>> the needs of the community.
>
> It's quite a bit more complicated that than, if you consider our "community"
> to include all of the end-users of (non-LISP, non-AMT) UDP applications,
> whose applications may be disrupted by corrupted and misdirected LISP or AMT
> packets.

Have you read draft-eubanks-chimento-6man-00? It says nothing of
generic UDP. It is intended to specifically address the UDP
encapsulated outer header where the inner header checksum is in fact
calculated. Please help me understand how this would affect any
application dependent on the inner packet.

>>> - Make LISP work across widely-deployed, buggy NAT boxes that overwrite
>>> zero
>>> UDP checksums with invalid values.
>>
>> Well, since ITRs send packets to ETRs and ITRs are forbidden from
>> writing non-zero checksums any non-zero chechsum received has been
>> tampered with. We can either assume the entire packet is corrupt and
>> drop it or strip off the outer header and let the forwarding process
>> of the inner header determine the validity of the packet. The later
>> seems the better of the two choices.
>
> The problems don't really come in if the packet makes it to the right
> destination with the destination UDP port intact.  They come in when that
> doesn't happen.

And then they are dropped. End of problem.

>>> The proposal in the LISP spec is to
>>> accomplish this by having LISP ETRs ignore all UDP checksums, even
>>> non-zero
>>> ones.
>>
>> I'm not sure if you have a problem with this specifically or just the
>> documentation and IETF process to provide for this. Which is it?
>
> I think that the choice to disable UDP checksum for LISP is technically
> unwise, perhaps even reckless.

I believe you do. I just don't yet understand why. Sorry, but I'm trying.

Greg

> I also think that it violates some RFCs, but that is a lesser consideration.
>  If the WG does decide that sending IPv6 zero checksums and ignoring
> non-zero checksums on receipt is the right thing to do, and if the WG can
> convince the rest of the IETF that they are right, then updating RFCs is a
> fairly trivial matter.  In that case, we'd need Marshall's draft (or
> something similar) and a draft to update RFC 1812 to say it is okay to
> ignore non-zero checksums on receipt.
>
> There are _reasons_, though, why the current RFCs were written the way they
> were.  There is research and experience that has shown that packets that get
> corrupted in transit and misdirected to the wrong host or the wrong
> application cause serious problems.  Those problems won't be constrained to
> LISP or even to nodes that implement LISP.
>
> Margaret
>