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

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:

>
> On Aug 11, 2009, at 12:18 PM, Noel Chiappa wrote:
>>
>>> 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).
>
> 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
>
>
> _______________________________________________
> lisp mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lisp

---

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

> the ETR MUST ignore the checksum and MUST not do a checksum  

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

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

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: 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: Rémi Després <[email-masked]>
Date: Thu, 13 Aug 2009 17:13:30 +0200

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

> For a full agreement, it would however be appropriate IMHO to be  
> more precise:

---

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: Rémi Després <[email-masked]>
Date: Thu, 13 Aug 2009 19:20:07 +0200

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

---

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

---

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:

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