Subject: Re: [lisp] New Issue: UDP-TUNNELS inconsistent with 5.4.1 MTU Handling

From: [email-masked] (Noel Chiappa)
Date: Mon, 14 Sep 2009 12:45:49 -0400 (EDT)

> From: Magnus Westerlund <[email-masked]>

    > by deliberate setting the UDP checksum to zero for an IPv6 packet
    > you are actually significantly reducing any hosts capability to
    > filter away corrupted packets.

I'm not understanding something here. How are we any worse off than if we were
using an encapsulation (e.g. GRE) which did not have any checksum at all? (In
fact, we'd probably be using GRE if it were not for other constraint)

There are also potentially applications which _do not_ want the network to
throw away corrupted packets for them - that's the whole reason UDPv4
_allows_ a zero checksum. that IPv6 LISP packet that just got corrupted
might be carrying an IPv4 packet with a UDP zero-checkums packet inside.
So why is the network taking it into its own hands to throw away corrupted
packets?

	Noel

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 14 Sep 2009 13:05:57 -0400

> fact, we'd probably be using GRE if it were not for other constraint)

There is no difference for LISP itself.

The difference comes in when a LISP packet is sent to the wrong  
destination, which will happen more often in IPv6 than IPv4, because  
the IPv6 destination address will not be protected by any checksum.

When an IP/IP or IP/GRE packet arrives at the wrong destination, the  
IP layer of the stack processes the packet and (typically) decides  
that there is nothing useful to do with the packet and throws it away.

When an IP/UDP packet arrives at the wrong destination, the packet is  
passed up the stack to UDP.  UDP does not have any way to tell that  
the packet was misdelivered (if we have checksums turned off), so it  
will look at the destination port to determine where to deliver the  
packet.  In most cases, UDP will decide to throw the packet away, but  
it some cases, it might deliver the packet to an unsuspecting  
application.

There are some things about LISP that make it much _less_ likely that  
the packet will be delivered to an unsuspecting application, the most  
important of which is that _all_ of the tunneled LISP packets are sent  
to a LISP destination port.  We don't have return traffic that goes to  
a random port and may be mistaken for other return traffic.  So, to  
get the problem that Magnus described, and have it effect anything but  
LISP, you'd have to have a different application running on the IANA- 
assigned LISP port.   That isn't very likely, and if those  
applications accidentally receive LISP traffic, perhaps they have  
gotten what they deserve.

> So why is the network taking it into its own hands to throw away  

In IPv6, corruption-tolerant applications are expected to use UDP- 
Lite.  That is how one turns off the data checksum for UDP in IPv6.

Margaret