Re: [lisp] IPv6 UDP checksum issue

[Gorry Fairhurst <[e-mail]>]

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