Subject: Re: [lisp] IPv6 UDP checksum issue

From: Gorry Fairhurst <[email-masked]>
Date: Thu, 30 Jul 2009 21:18:45 +0200

Thanks,

As promised in 6man, I'll make a longer email on why I think setting the 
IPv6 UDP Checksum to zero is *not* the same as for IPv4 and what the 
implications are. We touched on this briefly in TSV today, but I'd like 
to take a little time to check the arguments - it seems there are many 
views here and it would be good to get to the bottom of this.

A few other comments in-line,

Gorry

Gorry Fairhurst wrote:
> On Jul 29, 2009, at 8:02 AM, Dino Farinacci wrote:
> 
>  >> >> This is a reminder that  draft-fairhurst-6man-tsvwg-udptt and
>  >> >>
>  >> >> http://tools.ietf.org/html/draft-eubanks-chimento-6man-00
>  >> >>
>  >> >> are still open and will be discussed at the 6man meeting Wednesday.
>  >> >>
>  >> >> Basically, one prescribes no checksum for the "outer" packet in
>  >> >> IPv6 encapsulations, the other a fixed checksum per flow. My
>  >> >> understanding is that this matter is relevant to LISP.
>  >> >>
>  >> >> If you are interested, please try to attend as a decision may be
>  >> >> made soon.
>  > >
>  > > Sorry, I have a conflict right now. But here is the position of one
>  > > LISP implementor and a coauthor of the LISP specifications:
>  > >
>  > > From a practical perspective, we prefer that a LISP encapsulator
>  > > (ITR and PTR) not incurred additional work when encapsulating
>  > > packets. The main LISP spec indicates:
>  > >
>  > > (1) The UDP checksum in the outer header MUST be set to 0 by an
>  > > encapsulator.
>  > > (2) The decapsulator MUST ignore the UDP checksum.
>  > >
>  > > We stand by this text and see no reason to change it.
> 
> Are you using "we" to refer to yourself as both an implementor and a
> co-author?   ;-)
> 
> FWIW, I have serious concerns about draft-fairhurst-6man-tsvwg-udptt,
> as it involves overloading the UDP "next-header" value to refer to two
> different header types (real UDP and UDP-TT).
> 
One thing that was discussed in 6man was why thsi was different to 
UDP-Lite (which needed a separate protocol number), for the record there 
were two important differences here:

1) UDP-Lite implies very different semantics for the payload - i.e. 
error-tolerant data. Con fusing this with UDP data would not be good.
2) UDP-Lite needs to signal the link-driver that it is a UDP-Lite packet 
to atke advantage of the partial coverage feature. The header value 
currently provides this way.

I do however, suggest we discuss this after discussing the UDP checksum 
issue. I'd be most happy to withdraw my draft if the decision is to 
preserve standard IPv6 UDP Checksum behaviour.

> However, I also have serious concerns about using zero UDP checksums
> with IPv6.
>  > >
>  > > There are no practical reasons to use outer header UDP checksums
>  > > regardless of the 4 combinations of packet types (v4-in-v4, v6-in-
>  > > v6, v6-in-v4, or v4-or-v6) being forwarded by LISP routers.
> 
> I think that this statement is answering the wrong question...
> 
> Since we have standards-track protocols that indicate that UDP
> checksums must not be zero in IPv6 (for good reasons), I believe that
> we should use valid UDP checksums in IPv6 outer headers, unless we can
> provide practical (and compelling) reasons why _not_ to do so.  So,
> what are those reasons?
> 
> If we do manage to achieve consensus that it makes sense to zero-out
> the UDP checksum in IPv6 outer headers, there are a number of
> questions we will have to answer...
> 
> The problem with eliminating the UDP checksum in UDP over IPv6 is that
> (unlike in IPv4) the IPv6 source and destination addresses are not
> protected.  So, the packet may be corrupted such that it is sent to
> the wrong destination.  When it arrives at the wrong destination, it
> may be processed by an IP stack that is unaware of LISP.
> 
Agreed.

> We need to consider what will happen if one of these packets is
> received by a non-LISP node.  Are you assuming that non-LISP stacks
> will simply throw away these packets, because they have zero (and
> therefore invalid) UDP checksums?  That's only a good assumption if we
> assume that LISP is the _only_ protocol that will allow the use of
> zero checksums.  If the packet is processed by the stack, there
> shouldn't be a non-LISP application on port 4342, so the packet should
> be dropped.  We should define, however, how the sending LISP node will
> deal with an ICMPv6 "port unreachable" error, so that an error
> received from the wrong destination does not interfere with
> communication with the right destination.
> 
I suggest LISP is unlikely to be the only application to use this. AMT 
has already suggested a use in hosts. I suggest there will be others, 
especially once this is in the end-stack.

> We also need to consider the possibility that a packet will be
> received by a different LISP node than the one for which it was
> intended, or that it will arrive at the correct LISP destination with
> the wrong source address in the external header.  What happens in
> those cases?
> 
> Margaret
> 

I'd be keen to continue this later (sorry, but I will be disappearing 
from email for the next week after the IETF).

best wishes,

Gorry

---

From: Benny Amorsen <[email-masked]>
Date: Fri, 31 Jul 2009 20:17:52 +0200

[email-masked] (Noel Chiappa) writes:

> The UDP checksum in the outer header on LISP user-data does nothing, is
> expensive/impossible to compute (depending on the hardware), and therefore the
> correct practical engineering choice is to not compute it.

You will probably eventually see PC-based routers which verify all
checksums and drop invalid ones before letting the CPU see them, if the
IPv6 specs allow it. PC NIC's are optimized for host use, not for
routing, and therefore they look at the whole packets anyway. Most of
them probably don't do much for IPv6 yet, but that is only a matter of
time.

Now such routers may forever be sufficiently rare on the open Internet
that it is not a concern for LISP deployment. It seems prudent to try to
get a formal exception from the usual UDP checksum rules if you really
want to go for the no-checksum option.

Personally I would drop zero checksum UDP packets with a rate-limited
ICMP error when doing the LISP encapsulation. I would expect the number
of zero-checksum UDP packets to drop as more NIC's get the checksum
feature.

/Benny