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

From: [email-masked] (Noel Chiappa)
Date: Tue, 11 Aug 2009 12:18:52 -0400 (EDT)

> From: Margaret Wasserman <[email-masked]>

    > 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.

This is a bit of an aside, but.. if this is really IPv4/UDPv4 you're talking
of, that is _most definitely_ *NOT* RFC-compliant. (And if you don't believe
me, ask Dave Reed! :-)

The spec says: "all zero transmitted checksum value means that the
transmitter generated no checksum ... for higher level protocols that don't
care".

In other words, the OS _cannot_ know whether the higher-level application
wants that field to be zero, or not, and it is a gross error for the OS to
assume that it knows better than the application whether a packet with a zero
in that field is acceptable or not.

     > I don't know if any other operating systems do the same.

I would hope no other OS has made such an egregious error, one which is an
elementary violation of the end-end principle.

    > I have heard that there are firewalls that drop all IPv4 UDP packets
    > with zero checksums.

Ditto previous 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.

That's not necessarily a problem (e.g. it wouldn't be, for LISP). If
something fast computes a checksum for one - hey, one can either use it, if
one wishes, or ignore it, if one wishes; whatever floats one's boat.

The only problem would be if something on the receiving end then either i)
slowed down processing by checking the checksum, even though it was not used,
or ii) (worse) discarded packets which had a bad checksum, _even if_ the
application didn't want the checksums (e.g. packet voice).

    > 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

Let's not forget that this is basically caused by the existence of boxes that
do non-compliant stuff, i.e. tweak zero-checksums to be non-zero. In other
words, this is just trying to deal pragmatically with the fact that there is
stuff out there that does the wrong thing.

Extending this principle, there's probably no perfect solution, because no
matter what you do, there's probably _some_ stuff out there that's busted.
E.g. if we use UDP-Lite, there are probably deployed NAT boxes that don't
forward it, etc, etc.

Saying 'a LISP xTR has to do this non-standard thing' is probably the best of
the evils, because at least that is 'sort of' under the control of the person
doing the xTR - whereas stuff in the middle that does the wrong thing is
something the xTRs have no control over.

    > 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...

The problem is that in checking the UDP checksum _on behalf of the
application_, the OS is trying to do too much, and violating the end-end
principle in the process.

It can't even checksum packets which _appear_ to have a checksum (not
checking only those with a zero checksum). Consider the following case: A
packet is sent with a zero checksum, and is damaged in transit - _in the
checkum field_. That packet is still fine, as far as the application is
concerned, and for the OS to discard it is erroneous.

Sure, not all applications want to have to check checksums, so the UDP
interface should provide two ways to receive packets:
UDP_receive_only_good_packets(), and UDP_receive_any_old_packet().

And yes, the UDPv4 spec is severely under-written. A different age, ya know?
It could probably use a re-write to make the seemingly obvious, well,
explicit.

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

    > I prefer this choice. ... Along these lines, I would like to understand
    > why the idea of using different IIDs for different LISP flows for IPv6
    > was rejected.

What about IPv4? And any proposed new solution would have to work through
deployed IPv4 NAT boxes, which rules out a new protocol. (And no, we aren't
going to encapsulate LISP in HTTP... :-)

    > 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.

If so, that means we're effectively back to my suggestion of a week or two
ago: leave encapsulation _in_ IPv6 (as opposed to _of_ IPv6) out of the spec
altogether.

	Noel

---

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

> application didn't want the checksums (e.g. packet voice).

As written, the LISP spec says:

"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."

This wording would make a LISP ITR that does send a non-zero checksum  
non-compliant, and an ETR that checks non-zero checksums non-compliant.

Your paragraph above would be more reasonably translated as "UDP  
Checksum:  this field MAY be transmitted as 0, and MAY be ignored on  
receipt by the ETR".  So, what you are saying above does not seem to  
agree with the current LISP specification.

If we changed the MUSTs in the spec to MAYs, one could implement a  
compliant (although perhaps not highly performing) LISP ITR or ETR on  
a standard TCP/IP stack, even if I couldn't stop it from computing  
outbound UDP checksums or checking inbound ones.  IMO, this would be  
substantial improvement.

However, the "MAY" wording still wouldn't be compliant with RFC 1122  
(Requirements for Internet Hosts) or RFC 2460 (IPv6).

RFC 1122 requires that all TCP/IP stacks support UDP checksums in both  
direction, and that they check all non-zero checksums on receipt.  So,  
to say "the ETR MUST ignore the checksum" (or even "the ETR MAY ignore  
the checksum") in an IETF document, we would need to get a standards  
track document approved that updates _both_ RFC 1122 and RFC 2460.

If we want to boil this down to the (relatively simpler and more  
tractable) question of getting a document approved that allows zero  
UDP checksums in IPv6, we could change this wording to say:

"UDP Checksums:  this field MAY be transmitted as 0 [normative  
reference to document that makes this okay in IPv6].  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.  To address this concern, LISP ITRs SHOULD be capable of  
calculating UDP checksums on encapsulated packets."  Alternatively,  
you could state that LISP won't work through NAT boxes with this  
property, perhaps in a middlebox considerations section.

If you want LISP to actually _be_ RFC compliant, and not to  
potentially lag behind standards-track RFC updates, you could simply  
indicate that this field contains a valid UDP checksum value (MAY be  
zero for IPv4, MUST NOT be zero for IPv6).  Since there are checksum  
offload chips that can calculate a UDP checksum very quickly, it  
should be possible to build LISP hardware that does calculate UDP  
checksums at the necessary level of performance.

This last choice, which I will summarize as "be RFC 1122 and 2460  
compliant", would include checksum protection for the IPv6 header  
_AND_ would support LAG/ECMP, at the cost of requiring that LISP  
systems (which are the new thing we are building) be capable of  
calculating checksums.  I think this may be the best trade-off  
available, although I understand that it isn't cost-free.

Margaret

---

From: Dino Farinacci <[email-masked]>
Date: Tue, 11 Aug 2009 09:55:19 -0700

Copying [email-masked] for a question.

If we changed the text in the LISP draft from "MUST" to "MAY", would  
we still need to write the accompanying document to RFC 2460?

Maybe Lars can comment on this.

See below for details.

Dino

On Aug 11, 2009, at 9:47 AM, Margaret Wasserman wrote:

> 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."
>
> This wording would make a LISP ITR that does send a non-zero  
> checksum non-compliant, and an ETR that checks non-zero checksums  
> non-compliant.
>
> compliant (although perhaps not highly performing) LISP ITR or ETR  
> on a standard TCP/IP stack, even if I couldn't stop it from  
> computing outbound UDP checksums or checking inbound ones.  IMO,  
> this would be substantial improvement.
>
> RFC 1122 requires that all TCP/IP stacks support UDP checksums in  
> both direction, and that they check all non-zero checksums on  
> receipt.  So, to say "the ETR MUST ignore the checksum" (or even  
> "the ETR MAY ignore the checksum") in an IETF document, we would  
> need to get a standards track document approved that updates _both_  
> RFC 1122 and RFC 2460.
>
> reference to document that makes this okay in IPv6].  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.  To address this concern, LISP ITRs SHOULD be capable of  
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

From: "Joel M. Halpern" <[email-masked]>
Date: Tue, 11 Aug 2009 13:13:44 -0400

Requiring hardware modification of routers in order to support LISP with 
reasonable performance does not seem a good choice.

The problem is that if we try to make all this fit together we end up with:
May transmit UDP checksum as 0.
Note that while the RFCs require the non-zero UDP checksums be verified, 
it is likely that many implementations will not implement this step in 
the processing.

Which is some pretty ugly text to put in an RFC, but is what the real 
world will likely do no matter what we require.

Yours,
Joel

Margaret Wasserman wrote:
> 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."
> 
> compliant (although perhaps not highly performing) LISP ITR or ETR on a 
> standard TCP/IP stack, even if I couldn't stop it from computing 
> tractable) question of getting a document approved that allows zero UDP 
> checksums in IPv6, we could change this wording to say:
> 
> "UDP Checksums:  this field MAY be transmitted as 0 [normative reference 
> to document that makes this okay in IPv6].  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.  To address 
> this concern, LISP ITRs SHOULD be capable of calculating UDP checksums 
> on encapsulated packets."  Alternatively, you could state that LISP 
> won't work through NAT boxes with this property, perhaps in a middlebox 
> considerations section.
> 
> If you want LISP to actually _be_ RFC compliant, and not to potentially 
> lag behind standards-track RFC updates, you could simply indicate that 
> this field contains a valid UDP checksum value (MAY be zero for IPv4, 
> MUST NOT be zero for IPv6).  Since there are checksum offload chips that 
> can calculate a UDP checksum very quickly, it should be possible to 
> build LISP hardware that does calculate UDP checksums at the necessary 
> level of performance.
> 
> compliant", would include checksum protection for the IPv6 header _AND_ 
> would support LAG/ECMP, at the cost of requiring that LISP systems 
> (which are the new thing we are building) be capable of calculating 
> checksums.  I think this may be the best trade-off available, although I 
> understand that it isn't cost-free.
> 
> Margaret
> 
>

---

From: "Darrel Lewis (darlewis)" <[email-masked]>
Date: Tue, 11 Aug 2009 10:25:56 -0700

> I would expect a NAT that saw a zero value to not recalculate the  
> checksum.
> 

Fred,

We found this not to be the case in our testing of LISP.  Many
commercial (netgear and linksys being two that come to mind) NATs do
indeed recalculate the checksum regardless of its initial value.  

Regards,

-Darrel

---

From: Fred Baker <[email-masked]>
Date: Tue, 11 Aug 2009 10:13:31 -0700

I agree that the unilateral change to the UDP protocol built into RFC  
2460 was a bad idea; if you want to change UDP, change UDP. That is  
probably water under the bridge now.

I think that I would word this as:

UDP Checksum: this field MAY be transmitted as zero, and the receiver  
MAY ignore the checksum on receipt.

As to the performance issues, that is an implementation question. You  
can do a full packet checksum at 100 GBPS if you want to, it just has  
a cost implication (very different hardware than the usual store-and- 
forward design). The datagram will likely have to be handled in a flow- 
through manner and the checksum read from a register upon completion.

The argument in favor of this is, I think, that the interior packet  
has checksums on it, so this one is not called for, by the end-to-end  
principle.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Aug 2009 10:39:56 +0300

> Maybe Lars can comment on this.

In my opinion, any change from the MUST in RFC2460 requires updating  
RFC2460.

Lars

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Aug 2009 08:24:27 -0700

> In my opinion, any change from the MUST in RFC2460 requires updating  

 From my text I wrote above, if we changed from MUST to MAY *in the  
LISP draft*, do we have to update RFC2460?

Dino

---

From: Fred Baker <[email-masked]>
Date: Thu, 13 Aug 2009 08:33:25 -0700

that of course begs the question of what a system that forwards  
traffic from an interface to a tunnel-like encapsulation is; I tend to  
think that it did something with a packet not directed to it and is  
therefore a router, but your text below would suggest that it is a host.

On Aug 13, 2009, at 8:13 AM, Rémi Després wrote:

> Fred,
>
> Your proposal seems to me in the best direction.
>
> For a full agreement, it would however be appropriate IMHO to be  
> more precise:
> - A v4 to v6 translator MAY (for efficiency) not recalculate  
> checksums of UDP datagrams received with zero checksums.
> - If it doesn't recalculate them, it SHOULD forward datagrams with  
> their zero checksum
> - An IPv4 host MAY transmit zero-checksum UDP datagrams and MUST  
> accept them
> - An IPv6 host MUST transmit UDP datagrams with non-zero checksums  
> and MAY accept them with zero checksums.
>
> Would this fit with what you wish?
>
> Regards,
> RD
>
>
>
> Le 11 août 09 à 19:13, Fred Baker a écrit :
>> I agree that the unilateral change to the UDP protocol built into  
>> RFC 2460 was a bad idea; if you want to change UDP, change UDP.  
>> That is probably water under the bridge now.
>>
>> UDP Checksum: this field MAY be transmitted as zero, and the  
>> receiver MAY ignore the checksum on receipt.

---

From: Fred Baker <[email-masked]>
Date: Thu, 13 Aug 2009 08:30:59 -0700

> In my opinion, any change from the MUST in RFC2460 requires updating  

No problem. Rip out of 2460-bis anything that is not related to IPv6,  
and say that it MUST be implemented as a change to RFC 768 or whatever  
else. That's what should have happened in the first place.

---

From: Lars Eggert <[email-masked]>
Date: Thu, 13 Aug 2009 19:21:35 +0300

Hi,

yes, because RFC2460 says "MUST use always" and the intent here is to  
loosen that restriction for LISP and AMT.

(And I'm sure Noel will again call this "red-tape legalese", but the  
fact is that this change revises the standing IETF consensus, and  
there's a process for that.)

Lars

---

From: Sam Hartman <[email-masked]>
Date: Thu, 13 Aug 2009 13:50:21 -0400

>>>>> "Lars" == Lars Eggert <[email-masked]> writes:

    Lars> Hi, yes, because RFC2460 says "MUST use always" and the
    Lars> intent here is to loosen that restriction for LISP and AMT.

    Lars> (And I'm sure Noel will again call this "red-tape legalese",
    Lars> but the fact is that this change revises the standing IETF
    Lars> consensus, and there's a process for that.)

Something that apparently isn't obvious to some WG participants who
have contacted me off-list is that it is quite possible to change an
IETF consensus.  When Margaret, Lars and I talk about doing things
like updating RFC 2460, we're not talking about what we think should
be a obstruction once we've done the work to decide what the right
technical direction is.

We've all been on the IESG and are used to these sorts of updates as a
routine matter of IETF business.

In the simplest case, you're talking about writing a potentially short
draft that updates the spec in question.  You then find the
appropriate AD or working group to sponsor the draft and go through
the normal process.

Yes, you do actually have to build consensus.  For some updates,
that's easy, for others it is very difficult.  That's how we all
convince each other that we actually have thought things through and
come to the right decision.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 13 Aug 2009 11:18:15 -0700

Any node (host or router) that configures a tunnel endpoint
is the source of packets that it originates from its tunnel
interface. As such, it may perform host-based fragmentation,
receive ICMP errors, etc. in a way that is typically associated
with a host.

Whether you view it as a router with an embedded host function
or a host with an embedded gateway function is dependent on
specific use cases and/or one's point of view.

Fred
[email-masked]

> -----Original Message-----
> From: Rémi Després [mailto:[email-masked]]
> Sent: Thursday, August 13, 2009 10:20 AM
> To: Fred Baker
> Cc: Margaret Wasserman; [email-masked]; [email-masked]; Dino Farinacci; Noel Chiappa
> Subject: Re: [lisp] Judging Consensus on the UDP Checksum Issue
> 
> 
> Le 13 août 09 à 17:33, Fred Baker a écrit :
> 
> > traffic from an interface to a tunnel-like encapsulation is; I tend
> > to think that it did something with a packet not directed to it and
> > is therefore a router,
> 
> The distinction between a router and a host is not always clear.
> Basically, a node acts "as a host" on packets
> - it receives with a destination address that is one of its own
> addresses
> - it sends with a source address that is one of its own addresses.
> It acts "as a router" on other packets
> 
> Thus, an encapsulating function:
> - acts "as a host" on the link where outer headers are routed.
> - acts as link layer interface module to a "router function" on its
> side where packets have only the inner headers.
> 
> Would this clarify (or make things worth)?
> 
> Regards,
> RD
> 
> 
> 
> 
> > but your text below would suggest that it is a host.
> >
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Aug 2009 12:46:57 -0700

Ack. Thanks for the answer.

Dino

On Aug 13, 2009, at 9:21 AM, Lars Eggert wrote:

> Hi,
>
> yes, because RFC2460 says "MUST use always" and the intent here is  
> to loosen that restriction for LISP and AMT.
>

---

From: Marshall Eubanks <[email-masked]>
Date: Thu, 13 Aug 2009 21:20:25 -0400

On Aug 13, 2009, at 4:54 PM, Brian Haberman wrote:

> Sam Hartman wrote:
> Finally a point that is appropriate to the 6man mailing list...  
> There are two proposals on the table to do just that (modify the  
> handling of UDP as defined in 2460).  The discussion should be on  
> the tradeoffs of those two proposals.
>
> http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 proposes  
> allowing UDP to have a zero checksum in certain conditions (i.e.,  
> outer checksum is zero as long as there is an encapsulated UDP  
> checksum that is valid).
>

We envision draft-eubanks-chimento-6man-00, should it
go through, as explicitly updating RFC2460 and the next version will  
reflect this.

Regards
Marshall

> http://tools.ietf.org/html/draft-fairhurst-6man-tsvwg-udptt-01  
> proposes a "checksum per flow" approach that is applicable for UDP  
> tunneled inside of UDP.
>
> The chairs of 6MAN would like to here feedback on these drafts as  
> they apply to the problem spaces raised (AMT, v4/v6 translators, and  
> LISP).
>
> Regards,
> Brian

---

From: Dino Farinacci <[email-masked]>
Date: Thu, 13 Aug 2009 20:44:33 -0700

> they apply to the problem spaces raised (AMT, v4/v6 translators, and  

 From my perspective, AMT and LISP both have the same requirements in  
terms of performance and having encapsulation work well over LAGs. It  
turns out that there is even a greater performance issue with AMT  
because as you replicate a multicast packet to each gateway tunnel,  
the outer IP addresses are different for each tunnel and therefore  
require a different pseudo-header to be built for each UDP replicated  
encapsulation.

So I am in support of Marshall's draft.

Dino

---

From: Brian Haberman <[email-masked]>
Date: Thu, 13 Aug 2009 16:54:46 -0400

> come to the right decision.

Finally a point that is appropriate to the 6man mailing list... There 
are two proposals on the table to do just that (modify the handling of 
UDP as defined in 2460).  The discussion should be on the tradeoffs of 
those two proposals.

http://tools.ietf.org/html/draft-eubanks-chimento-6man-00 proposes 
allowing UDP to have a zero checksum in certain conditions (i.e., outer 
checksum is zero as long as there is an encapsulated UDP checksum that 
is valid).

http://tools.ietf.org/html/draft-fairhurst-6man-tsvwg-udptt-01 proposes 
a "checksum per flow" approach that is applicable for UDP tunneled 
inside of UDP.

The chairs of 6MAN would like to here feedback on these drafts as they 
apply to the problem spaces raised (AMT, v4/v6 translators, and LISP).

Regards,
Brian