Subject: [lisp] Checksum-related issues for the tracker

From: Margaret Wasserman <[email-masked]>
Date: Tue, 11 Aug 2009 16:24:36 -0400

I believe that (at least) seven separate issues have been raised in  
the thread(s) about zero UDP checksums that should be added to the  
LISP tracker, so that we can track their resolution.  These are all  
issues regarding text in document version -03.

#1:  Sending UDP Zero Checksums Violates RFC 2460

The use of zero UDP checksums in IPv6 is forbidden by RFC 2460.  This  
issue could be addressed in one of two ways:  (1) move to any  
standards-compliant encapsulation, or (2) include a normative  
reference to a standards-track document that updates RFC 2460 to allow  
UDP zero checksums.

#2: Sending UDP Zero Checksums not Universally Implemented

Current TCP/IP stacks do not always implement the ability to turn off  
UDP checksum calculation for outbound traffic.  In some cases, this  
could be corrected by a software change.  In other cases, the checksum  
may be calculated in hardware.  It may not be possible to turn off UDP  
checksum calculation for outbound LISP traffic, without turning off  
UDP checksum calculation for all outbound traffic.  This issue could  
be resolved by changing the text that indicates that LISP ITRs "MUST"  
send zero UDP checksums to a "MAY".

#3:  Not Checking Inbound Non-Zero UDP Checksums Violates RFC 1122 and  
RFC 2460

Not checking non-zero UDP checksums on inbound traffic (at the ETR in  
LISP) violates RFC 1122 (for IPv4) and RFC 2460 (for IPv6).  There is  
concern that checking the checksums would cause two problems:   
performance issues for existing routers that lacks the ability to  
perform the checksum efficiently, and problems when the zero UDP
checksums themselves are corrupted en route (particularly by poorly  
implemented NAT boxes).  This issue could be addressed in one of two  
ways:  (1) require standards-compliant behavior in LISP ETRs, or  
include a normative reference to a standards-track RFC that updates  
RFC 1122 and RFC 2460 to allow receiving nodes to ignore non-zero UDP  
checksums.

#4: Not Checking Inbound Non-Zero Checksums not Universally Implemented.

There are TCP/IP stacks that do not have any way to turn off checking  
of non-zero UDP checksums on receipt.  If this functionality can be  
turned off, it may not be possible to turn it off for LISP traffic  
only , while it remains enabled for other traffic.  Also, the checksum  
may be checked in hardware before the software sees the packet.  This  
issue could be resolved by changing the text that indicates that LISP  
ETRs "MUST" ignore incoming UDP checksums to a "MAY".

#5: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires Analysis

Research (the Stone/Partridge paper) and prior experience (with NFS  
and IS-IS, among others) have indicated that it is (at least  
sometimes) a very bad idea to disable and/or bypass UDP or IP  
checksums.  References:

Stone/Partridge Paper on Internet Checksums:  http://conferences.sigcomm.org/sigcomm/2000/conf/abstract/9-1.htm
IS-IS Optional Checksum:  http://www.rfc-editor.org/rfc/rfc3358.txt

We have proposed disabling the IPv4 UDP checksum and effectively  
disabling both the IPv6 header and UDP checksum in IPv6.  As part of  
making this decision in a responsible manner, we need to perform (and  
document) an analysis of the implications of that choice, both on LISP  
itself and on other nodes and applications that have to co-exist with  
LISP.

#6:  LAG/ECMP Requirements Not Well-Explained

The LAC/ECMP requirements that drive some LISP design choices are not  
well-explained in the draft.  This issue was raised by Sam Hartman,  
and Dino agreed to add additional text.

#7: Limits on "Gleaned" Map Entries Not Clear

The current specification does not make it clear how long gleaned map  
entries should be retained in the cache, nor does it make it clear how/ 
when they will be validated.  The LISP spec should, at the very least,  
include a (short) default lifetime for gleaned entries, require that  
they be validated within a short period of time, and state that a new  
gleaned entry should never overwrite an entry that was obtained from  
the mapping system.   The security implications of storing "gleaned"  
entries should also be explored in detail.

Document editors, could you please add these issues to the LISP  
tracker, so that we can keep track of their resolutions?

Thanks,
Margaret

---

From: Sam Hartman <[email-masked]>
Date: Sun, 23 Aug 2009 15:07:04 -0400

>>>>> "Margaret" == Margaret Wasserman <[email-masked]> writes:

    Margaret> I believe that (at least) seven separate issues have
    Margaret> been raised in the thread(s) about zero UDP checksums
    Margaret> that should be added to the LISP tracker, so that we can
    Margaret> track their resolution.  These are all issues regarding
    Margaret> text in document version -03.

I have entered these issues.  Sorry about the delay: we were having
trouble with the tracker.  It's also being indecisive about whether it
wants to e-mail the list.

    Margaret> #1: Sending UDP Zero Checksums Violates RFC 2460

This is #9

    Margaret> #2: Sending UDP Zero Checksums not Universally
    Margaret> Implemented

This is #10
    Margaret> #3: Not Checking Inbound Non-Zero UDP Checksums Violates
    Margaret> RFC 1122 and RFC 2460

This is #11

    Margaret> #4: Not Checking Inbound Non-Zero Checksums not
    Margaret> Universally Implemented.

This is #12

    Margaret> #5: Use of Zero UDP Checksums (in IPv4 and IPv6)
    Margaret> Requires Analysis

This is #13

    Margaret> #6: LAG/ECMP Requirements Not Well-Explained

This is #14
    Margaret> #7: Limits on "Gleaned" Map Entries Not Clear

This is #8

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Aug 2009 08:56:16 +0200

Sam,

I have a problem with the approach being taken by the chairs on this
matter.  Opening four issues on what amounts to substantially the same
topic is a DOS attack on the WG and its time.  Most egregious examples
are 9 and 11.  If one is expected to 0 checksums, then one should be
expected to handle 0 checksums.  I take Margaret's point that perhaps
there might be some kernel implications in that perhaps an ioctl may
needed to be added in some cases for participating implementations, but
that has never been a serious consideration for holding back a change. 
Many people are going to be flying a long way to Hiroshima.  Let's not
burn it all on this, which yes, is the logical outcome of what you are
doing.

Eliot

On 8/23/09 9:07 PM, Sam Hartman wrote:
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>
>

---

From: Sam Hartman <[email-masked]>
Date: Tue, 25 Aug 2009 06:48:16 -0400

Your concern is noted. I respectfully disagree.  I'm going to respond
to the technical part of your concern because I think getting in a
long process discussion would be more of a DOS than opening any four
issues in a database.  I absolutely agree that discussing each of
Margaret's seven issues in turn, giving them equal time, would be a
bad way to run a meeting.  If we're still needing to send any face to
face time on this at IETF 76, I'll have already clawed out my eyes and
removed my ears in frustration:-).

Fixing this is definitely not about adding a kernel IOCTL.  There are
significant architectural, political and hardware issues to
implementing ignore UDP checksums.

Architectural: So, let's assume you want to add this mythical IOCTL to
enable receiving checksums.  It would be either a socket option or a
sysctl, not an ioctl.  A global sysctl is bad: you don't want to
ignore UDP checksums for all applications.  Even LISP cares about
checksums for the control plane.  However in most OSes the UDP
checksum is verified before the kernel demultiplexes the packet and
determines what to do with it.  So, you need to reorganize the kernel
code for the UDP stack for the entire operating system in order to
implement this feature.  It's possible to do certainly, but it's a
kind of major change.

hardware: As we've discussed there are a huge number of NICs that
offload IPV6 checksum processing.  I don't know how easy it is to
ignore checksum errors on these; accepting 0 checksums for IPV6 may be
even more challenging.

political: Linux has just gotten done removing the ability to send 0
checksums because we (the IETF) have spent the last 10 years
convincing the world that's a bad idea.  Windows is in a similar
place.  I have enough information about the political situation within
Linux, Apple and microsoft to strongly guess that LISP is not a big
enough consumer to motivate changes in this area.

So, no, I definitely don't think this is all about an IOCTL.  I do
think it is all doable;I do think that if we get to a point where the
WG has consensus behind the LAG and NAT traversal requirements that a
solution will be achieved quickly.

---

From: Eliot Lear <[email-masked]>
Date: Tue, 25 Aug 2009 14:40:28 +0200

Sam,

> removed my ears in frustration:-).

Then if it's bad way to run the meeting, it's a bad way, period.  It's
still a process DOS attack.

> implementing ignore UDP checksums.

Margaret made a claim that it would be difficult separate certain types
of traffic for the check, and I just don't believe that is technically
true.  That is what I responded to.

> ignore UDP checksums for all applications.

Right.

>   Even LISP cares about
> checksums for the control plane.

Right.

>   However in most OSes the UDP

Order of magnitude effort to make that change?  Reorder how many lines
of code?  1 (assuming a function, perhaps inline).

> ignore checksum errors on these; accepting 0 checksums for IPV6 may be

That's a fair point (thus far the only one).  But just as there is a lot
of h/w that doesn't support IPv6, there could be h/w that doesn't
support LISP.

> enough consumer to motivate changes in this area.

It's a matter of who does the work, and what the motivations are.  I
also think you speak quite loosely and authoritatively for those
organizations.  If there is value in LISP to those groups and vendors,
they'll make the change.  If there is value in the OpenSource world to
consumers making the change, the consumer will make the change.  I take
your point about politics, but one thing we've learned is that perhaps
nuance is something that has been lacking All of This.

Eliot

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 25 Aug 2009 10:45:29 -0400

> ignore checksum errors on these; accepting 0 checksums for IPV6 may be

Is there any operational experience with v6 LISP and zero UDP  
checksums ?

I would be curious how difficult it is to pass these around in practice.

Regards
Marshall

---

From: Sam Hartman <[email-masked]>
Date: Wed, 26 Aug 2009 09:01:03 -0400

>>>>> "Marshall" == Marshall Eubanks <[email-masked]> writes:

Marshall> Is there any operational experience with v6 LISP and zero UDP
    Marshall> checksums ?

It's my personal opinion that there is no significant operational
experience involving LISP interoperability where one of the
implementations is a stock UDP stack.

Someone could disagree with my definition of significant, stock or
interoperability and come to a different conclusion.