Subject: [lisp] Judging Consensus on the UDP Checksum Issue

From: Sam Hartman <[email-masked]>
Date: Wed, 05 Aug 2009 09:21:06 -0400

Folks, as you have no doubt noticed, the issue of what the LISP spec
should say about IPV6 UDP checksums has been raised in force.

It's tied up in a lot of other issues.

Lars has made it absolutely clear that when the process completes, we
need to be consistent with the current IETF consensus at the time our
documents are published.  One of the jobs of the chairs will be to
check the documents for that sort of consistency before forwarding to
the IESG.

Trying to convince the rest of the IETF to change their consensus and
having the LISP specs reflect that consensus is definitely something
we can do.  You've seen a lot of discussion that includes both the
6man working group and the LISP working group lately as members of our
community have tried to do that and others have asked questions or
disagreed.

It's clear from the traffic so far that the broader discussion--the
one including 6man--is not over yet.

so, we here in the LISP working group are faced with the question of
what should the LISP spec say while that discussion is ongoing.  I'd
like to solicit opinions from this community about what goes in the
current LISP spec.  Hopefully, the narrow consensus within LISP is
more clear so that we can focus on other things within this working
group.

Here are options as I see them:

1) We can use 0 checksums with UDP, adding a normative reference to a
standards track document updating RFC 2460.  Our spec will block
behind this standards track document and will move no faster than it
does.  If the IETF chooses to go a different route, we will be faced
with having to make incompatible changes to LISP late in the process.
If that happens, individuals can come to the personal conclusion that
they are no longer interested in spending effort on the IETF LISP
spec, but they will not have the option of publishing a LISP spec
through the IETF that disagrees with IETF consensus.

2) We can change LISP to use UDP-light.

3) We can make more significant changes to the LISP encapsulation.

I want to stress that if we choose option 1, the only way we will be
successful is if members of this community spend the necessary energy
in 6man and the IETF at large to build an IETF-wide consensus behind
the proposed change.  No matter how strongly felt and unified feelings
are in the LISP working group, that alone will not make an IETF
consensus.

Thanks for your input,

Sam Hartman
LISP Co-chair

---

From: Dino Farinacci <[email-masked]>
Date: Sat, 8 Aug 2009 18:01:22 -0700

> through the IETF that disagrees with IETF consensus.

I vote for this. So we can use the same encapsulation for all 4  
combinations and keep a clean design thank you.

> 2) We can change LISP to use UDP-light.

Doesn't solve the problem. It's more work that doesn't buy you anything.

Plus you want full UDP checksums for control packets.

Right now we use the same header encapsulation for destination port  
4341 and 4342. This keeps it clean so you can use common parsers.

> 3) We can make more significant changes to the LISP encapsulation.

We are doing all this for an experimental protocol?

Folks, please believe in data-link CRCs. They do error correction to  
10^-13 these days.

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 11 Aug 2009 11:07:52 -0400

Hi Sam,

> more clear so that we can focus on other things within this working

I think it may be a bit early for a formal consensus call on this  
topic, as people are still learning facts that are pertinent to this  
discussion, and some people are proposing additional solutions.

Facts we are still learning include:

How often does UDP packet corruption happen in real world  
deployments?  The one fact we have (1 in ~7000 packets) seems  
consistent with the research papers I've seen on this topic.

How do widely deployed systems deal with IPv4 UDP packets that use  
zero checksums?  I've been told, for example, that recent Microsoft  
OSes (XP and Vista) will silently discard any IPv4 packets that they  
receive with a UDP checksum of zero, which is RFC-compliant behavior.   
I have asked some Microsoft folks to confirm this and will let the  
list know what I find out.  I don't know if any other operating  
systems do the same.

I have heard that there are firewalls that drop all IPv4 UDP packets  
with zero checksums.  I don't even know who to ask about that...  Are  
there any firewall vendors on this list who could comment?

There is widely deployed hardware that will calculate and insert a  
valid UDP checksum in packets that are transmitted by the TCP/IP stack  
with zero UDP checksums.  In some cases, it may not be practical (or  
desirable) to disable this functionality.

There seem to be several NAT boxes that "correct" zero UDP checksums  
in packets that they forward, thus resulting in packets with bad non- 
zero checksums.

To avoid problems with zero UDP checksums that are changed to non-zero  
values in transit, Dino has proposed that we hack the IP stack on  
every LISP-capable device to ignore all UDP checksums, not just zero  
ones.  This is non-RFC compliant and is a second way in which the LISP  
spec would need to request a change to existing RFCs.  It is not clear  
to me how/if a stack could be designed to do this _only_ for LISP  
packets, and not other types of packets tunneled in UDP/IP...

> through the IETF that disagrees with IETF consensus.

To support the current LISP specification, the standards track RFC you  
reference above would have to do two things:  (1) allow the use of  
zero UDP checksums in IPv6, and (2) allow stacks to ignore non-zero  
UDP checksums (in both IPv4 and IPv6) on receipt.  This is a fairly  
significant extension to Marshall's proposed document, and for me this  
is a non-starter.

> 2) We can change LISP to use UDP-light.

I would reluctantly support this choice, even though I understand that  
it would require IPv6 router updates to support UDP-Lite ports and/or  
the IPv6 flow label in their hash calculation.  I consider it far  
better than the zero checksum alternative.  In fact, I would prefer  
that we use UDP-Lite for both IPv4 and IPv6, and not use zero UDP  
checksums at all.

> 3) We can make more significant changes to the LISP encapsulation.

I prefer this choice.  I'd like to see if we could come up with a  
solution _other than_ the use of UDP zero checksums that would work  
with the LAG/ECMP feature in legacy routers _and_ work on widely  
deployed host TCP/IP stacks without the need to modify the stack.   
Along these lines, I would like to understand why the idea of using  
different IIDs for different LISP flows for IPv6 was rejected.  In  
fact, if we remove the "gleaning" feature from LISP, the source IPv4  
address of the outer header could potentially be used for this  
purpose, as well.

> are in the LISP working group, that alone will not make an IETF

I don't think there is any real chance of convincing the rest of the  
IETF that it is okay to ignore non-zero UDP checksums on receipt.  So,  
I don't think this is a real option.

Margaret