Subject: [lisp] Resolving Issues #9, #10 and #12? (UDP Checksums)

From: Margaret Wasserman <[email-masked]>
Date: Tue, 25 Aug 2009 10:40:41 -0400

Now that the UDP checksum issues have been entered into the tracker, I
think we can try to agree to a resolution for the following issues:

Issue #9 Sending UDP Zero Checksums Violates RFC 2460
Issue #10 Sending UDP Zero Checksums not Universally Implemented
Issue #12 Not Checking Inbound Non-Zero Checksums not Universally  
Implemented

Sam had proposed some wording earlier, and Dino had offered to put it
in the -04 draft.  I then suggested that we add a normative reference
to Marshall Eubanks' IPv6 zero UDP checksum draft to allow sending
zero UDP checksums in IPv6.  Noel objected to making it optional to
ignore UDP checksums because of concerns that widely-deployed NATs
would corrupt a zero UDP checksum and packets could be black-holed.
Since then, we have determined that those NATs change the UDP checksum
to a correct checksum value, so that concern has been eliminated.

So, at this point, I think we may have agreement on the following
changes:

OLD (-03 version):

UDP Checksum: this field MUST be transmitted as 0 and ignored on
               receipt by the ETR. Note, even when the UDP checksum is
               transmitted as 0 an intervening NAT device can
               recalculate the checksum and rewrite the UDP checksum
               field to non-zero. For performance reasons, the ETR MUST
               ignore the checksum and MUST not do a checksum
               computation.

NEW (proposed -04 version):

UDP Checksum: this field MAY be transmitted as 0 in both IPv4 and IPv6
               packets [draft-eubanks-chimento-6man-00.txt], and MAY be
               ignored by the ETR.

+ Add a normative reference to draft-eubanks-chimento-6man-00.

Does anyone object to making the change shown above to resolve issues
#9, #10 and #12?

Margaret

---

From: Lars Eggert <[email-masked]>
Date: Tue, 25 Aug 2009 16:59:20 +0200

Hi,

this is overstating things. Here is what Darrel wrote:

> Many commercial (netgear and linksys being two that come to mind)  
> NATs do
> indeed recalculate the checksum regardless of its initial value.

I understand this to mean that some Netgear and Linksys models behaved  
OK in testing. It's not clear which models (all?). It's also not clear  
if any NATs were tested that had a different behavior. Is there more  
data from these tests available?

One lesson we learned in BEHAVE is that there is *no* regularity in  
what deployed NATs do. (Ask Cullen for war stories.) To close this  
issue, I believe we need to convince ourselves that most NATs out  
there have this behavior, and not just some models from two vendors.

Lars

---

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

Hi Lars,

On Aug 25, 2009, at 10:59 AM, Lars Eggert wrote:
> I understand this to mean that some Netgear and Linksys models  
> behaved OK in testing. It's not clear which models (all?). It's also  
> not clear if any NATs were tested that had a different behavior. Is  
> there more data from these tests available?

The only reason that we even considered the issue of NATs that change  
zero (IPv4) UDP checksums to non-zero values was that we were told, by  
folks from Cisco, that there were widely deployed NATs (from Linksys  
and Netgear) that would modify IPv4 zero UDP checksums to non-zero  
values.    Both Noel and I made the (mistaken) assumption that those  
NATs would modify the values to _incorrect_ UDP checksum values, and  
we ran off from there.  It turns out that those NATs modify the  
checksums to _correct_ UDP checksum values, so all of our discussion  
about what would happen if they included incorrect values was moot.

So, no, we haven't gone and tested any significant number of NATs.   
But, I don't understand why we would need do so, as our discussion  
about NATs that change zero checksums into bad checksums was entirely  
based on a misunderstanding.

This is all entirely separate from any discussion of how/if existing  
hardware and software will handle IPv6 zero UDP checksums.   
Presumably, 6man (with help from transport folks) will need to  
consider that question in their discussions of the eubanks-chimento  
draft.  If the 6man group decides to go forward with the eubanks- 
chimento draft, then LISP can use it.  Otherwise, LISP will have to  
use whatever the 6man group recommends instead, I guess...

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 25 Aug 2009 08:54:47 -0700

> in the -04 draft.

My proposed changes will be posted by end of week.

Dino

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 25 Aug 2009 11:57:19 -0400

Hi Lars,

On Aug 25, 2009, at 11:25 AM, Margaret Wasserman wrote:
> about NATs that change zero checksums into bad checksums was  
> entirely based on a misunderstanding.

Just to make something clearer here...

The issues that I suggested we resolve are _not_ the issues with LISP  
working through NAT boxes in general.  There is ongoing discussion of  
whether LISP needs to work through NAT boxes, and if we do want LISP  
to work through NATs, I have mentioned several ways in which the  
current LISP spec would not work through IPv4 NAT boxes.  Those issues  
have not been resolved.  That discussion has not been reflected in the  
issue tracker yet, but I assume it will be.

I am only suggesting that we close three of the UDP checksum-related  
issues.  Two checksum-related issues would remain open:

Issue #11: Not Checking Inbound Non-Zero UDP Checksums Violates RFC  
[1812] and RFC 2460
Issue #13: Use of Zero UDP Checksums (in IPv4 and IPv6) Requires  
Analysis

Also, the resolution I suggested adds a normative reference to draft- 
eubanks-chimento..., so LISP could only proceed with the use of UDP  
zero checksums in IPv6 if that draft is adopted in 6man (or elsewhere)  
and published as a standards-track RFC.

Margaret

---

From: Marshall Eubanks <[email-masked]>
Date: Tue, 25 Aug 2009 12:47:17 -0400

On Aug 25, 2009, at 11:57 AM, Margaret Wasserman wrote:

> The issues that I suggested we resolve are _not_ the issues with  
> LISP working through NAT boxes in general.  There is ongoing  
> discussion of whether LISP needs to work through NAT boxes, and if  
> we do want LISP to work through NATs, I have mentioned several ways  
> in which the current LISP spec would not work through IPv4 NAT  
> boxes.  Those issues have not been resolved.  That discussion has  
> not been reflected in the issue tracker yet, but I assume it will be.
>
> zero checksums in IPv6 if that draft is adopted in 6man (or  
> elsewhere) and published as a standards-track RFC.
>

Dear Margaret;

At present, draft-eubanks-chimento... effectively deals with Issue 13  
not Issue 11. Are you proposing that it
deal with # 11 as well ? As something informational or as a MUST ?

Regards
Marshall

> Margaret
>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp
>

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 25 Aug 2009 13:40:06 -0400

On Aug 25, 2009, at 12:47 PM, Marshall Eubanks wrote:
>>
>> I am only suggesting that we close three of the UDP checksum- 
>> related issues.  Two checksum-related issues would remain open:
>>
>> Also, the resolution I suggested adds a normative reference to  
>> draft-eubanks-chimento..., so LISP could only proceed with the use  
>> of UDP zero checksums in IPv6 if that draft is adopted in 6man (or  
> At present, draft-eubanks-chimento... effectively deals with Issue  
> 13 not Issue 11. Are you proposing that it

I did not say that a reference to draft-eubanks-chimento would resolve  
issue #13.  In fact, I explictly stated (as shown above) that #13  
would remain open.

As to whether draft-eubanks-chimento... _should_ include the ability  
to ignore non-zero checksums:

First, let me say that I am not sure that we should publish draft- 
eubanks-chimento...  at all, because I do not think that the use of  
IPv6 UDP checksums should be optional.

On the technical purity side, I'd say:  If protocols need an  
encapsulation that doesn't include full-packet integrity checking,  
they should use something other than UDP.  IPv6 load balancers should  
be built to use the flow label as one input for their hash, and  
protocols that are using the UDP header only for load balancing,  
should put their per-flow hash into the flow label.  Hardware that  
can't calculate UDP checksums efficiently should be replaced with  
hardware that can.

But, it seems like there is a large group of people in the IETF who  
don't like that answer, some of them for pretty compelling reasons...

If we _do_  decide to allow zero UDP checksums in IPv6 it will be for  
three reasons:
        (1) We understand that there is equipment that cannot calculate
              UDP checksums efficiently.
        (2) We accept that it is important to use a UDP/IPv6  
encapsulation in many cases
              (as opposed to UDP-Lite or direct IP encapsulation), to  
be compatible with deployed
              IPv6 LAG/ECMP equipment and/or IPv6 firewalls.
         (3) We believe that there are protocols for which integrity  
protection of the IP and
               UDP headers is unnecessary.

I am somewhat skeptical that there is enough IPv6 LAG/ECMP equipment  
deployed that will not be upgraded in the time it takes to reach wide  
deployment of a new protocol that we should consider this.  Perhaps we  
should right an RFC about how to achieve IPv6 LAG/ECMP using the flow  
label instead?  Others seem to think that this is something we should  
consider, however.

The third point is key, and it is the place where I think draft- 
eubanks-chimento... needs work.  Exactly what properties does a  
protocol need to have to fall into this category?  What type of  
analysis is needed to determine that it would be safe to run a given  
protocol without integrity checking for the outer headers?  Does this  
include protocols (like LISP) that introduce their own header between  
the outer and inner IP headers?  Or only to mechanisms, like IPv6-in- 
IPv4 tunneling mechanisms, that tunnel IP directly in UDP/IP?

If we _do_ decide that it is okay for protocols to send zero IPv6 UDP  
checksums in some cases for the reasons stated above, what would be  
the benefit of forcing those same protocols to calculate non-zero  
received checksums?  The other end would, most likely, run on the same  
type of hardware (the hardware that can't calculate full-packet  
checksums efficiently).  And, the protocol would be the same protocol  
(the one that wouldn't benefit from end-to-end integrity checking).   
So, what would be the point of requiring the receiving end to check  
all non-zero checksums if we don't require the sending end to send non- 
zero checksums?

So, I guess it would make sense to include the option for the  
receiving end to ignore non-zero UDP checksums in the same cases where  
we allow the sender to send zero IPv6 UDP checksums.  I am just not  
sure that there are any cases where we should do that.

Margaret

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 25 Aug 2009 13:48:01 -0400

Hi Marshall,

On Aug 25, 2009, at 1:40 PM, Margaret Wasserman wrote:
> I did not say that a reference to draft-eubanks-chimento would  
> resolve issue #13.  In fact, I explictly stated (as shown above)  
> that #13 would remain open.

I'm sorry, I meant that issue #11 would remain open if we adopt my  
proposed change, because it is not (currently) resolved by draft- 
eubanks-chimento...:

> deployed that will not be upgraded in the time it takes to reach  
> wide deployment of a new protocol that we should consider this.   
> Perhaps we should right an RFC about how to achieve IPv6 LAG/ECMP  
> using the flow label instead?  Others seem to think that this is  
> something we should consider, however.

s/right an RFC/write an RFC

I really should try to hit send a little less quickly...

Margaret