Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

From: <[email-masked]>
Date: Mon, 23 Nov 2015 20:43:49 +0000 (UTC)

> Another recommendation might be to reconsider default coverage length.
> RFC3228 recommends that the default is to checksum over the entire
> packet, but then this basically becomes UDP so why not just use UDP?
Because Lite was designed as an in-situ replacement of UDP, the IESG gotcold feet, and punted it to a different protocol number. It's the safe default.

(Once it was at a different protocol number, it didn't have to look likeUDP at all. But by that time the document was written and approved. Theseare the wonders of the standards process.)

> For the case of tunneling at least, maybe the recommendation should be
> that the UDP-Lite checksum only covers the pseudo header and UDP
> header, i.e. the minimum coverage to compensate for lack of IP header
> checksum in IPv6.

It doesn't cover for the lack of IP header checksum,unless you're suggesting it be checked at each hop.Covering the minimum of UDP-Lite/IP pseudoheader doesnothing for what is carried - a tunneller can argue that,from his perspective, he gains nothing over zero-checksumUDP and doesn't care about polluting other ports, sowhy not simply use UDP and turn off UDP checksums?

Where Lite has an advantage is that it can and shouldalso cover encap headers not otherwise covered end to end(e.g. MPLS stack in MPLS-in-UDP, or a GRE shim withouta GRE checksum, or RTP headers) but that is case-specificand requires engineering judgement to select. And thatalso offers a subtle benefit to the tunneller.
Again, full checksum coverage is the safe default forpeople who don't think about this.

> Besides that, we are
> pushing vendors to get rid of protocol specific offloads

But not for offloading TCP or UDP, eh?

> For instance, when receiving a packet
> we prefer that a device just gives us the checksum as calculated over
> the whole packet, it is then easy for the stack to apply that value to
> verify any UDP, TCP, GRE checksums etc. in the packet (please look at
> http://people.netfilter.org/pablo/netdev0.1/papers/UDP-Encapsulation-in-Linux.pdf).

Tom Herbert, "UDP Encapsulation in Linux" netdev 0.1,Ottawa Canada, Feb 2015.

Your paper doesn't mention Lite - sigh. But hey,different protocol number...

This assumes that other inner one's complement checksumsare good if the outer one is good - imo a bit risky,because one's complement is so weak.And of even less use for assuming stronger tunnelled CRCsare good. (an outer Eth CRC has a different link scope tothe full path of tunnelled devices, so is not that good anindicator the content is safe.)

Lloyd Wood [email-masked] http://about.me/lloydwood

---

From: Tom Herbert <[email-masked]>
Date: Mon, 23 Nov 2015 13:23:49 -0800

> It doesn't cover for the lack of IP header checksum,
> unless you're suggesting it be checked at each hop.
> Covering the minimum of UDP-Lite/IP pseudoheader does
> nothing for what is carried - a tunneller can argue that,
> from his perspective, he gains nothing over zero-checksum
> UDP and doesn't care about polluting other ports, so
> why not simply use UDP and turn off UDP checksums?
>
The UDP or UDP-Lite checksum covers the IP addresses and port numbers
which protects against mis-delivery. In IPv4 we have the IP header
checksum which covers the addresses, but in IPv6 there is no header
checksum since it was assumed that would be redundant to the transport
checksum that includes the pseudo header. This difference between IPv4
and IPv6 and the requirement that UDP checksum must be sent with IPv6
has be the cause of much discussion (RFC6935, RFC6936, UDP checksum
handling in GRE/UDP. MPLS/UDP, and other UDP encapsulations).

Tom

---

From: <[email-masked]>
Date: Mon, 23 Nov 2015 23:46:22 +0000 (UTC)

Because the IPv4 header checksum gets recomputed at each hop,because it covers mutable fields (eg ttl), it is not a goodreplacement for the IPv4 pseudoheader as an endpoint demux check.IPv6 should have been designed with a header checksum
covering only non-mutable fields, which would have helped whentransports don't do the pseudoheader check.

Speaking of which, expecting transports to providethe necessary pseudoheader check in IPv6, and understand why,was too much to expect. Some tangential thoughts on that inhttp://sat-net.com/L.Wood/publications/internet-drafts/draft-wood-tsvwg-saratoga/wood-eddy-checksum-coverage.pdf

Separately to that, tunnellers are selfish and not overlyconcerned with the effects of their traffic on the network(zero checksums lead to port pollution in IPv4 and hostpollution in IPv6 - I made that point for RFC7510.)

Really, this is mistakes compounding mistakes, all the waydown. Our reciting histories at each other doesn't make itmore interesting, and doesn't fix it.

 Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Tom Herbert <[email-masked]>
 To: Lloyd Wood <[email-masked]> 
Cc: Tsvwg IETF List <[email-masked]>
 Sent: Tuesday, 24 November 2015, 8:23
 Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

Tom

---

From: Joe Touch <[email-masked]>
Date: Tue, 24 Nov 2015 09:22:13 -0800

On 11/23/2015 3:46 PM, [email-masked] wrote:
> Because the IPv4 header checksum gets recomputed at each hop,
> because it covers mutable fields (eg ttl), it is not a good
> replacement for the IPv4 pseudoheader as an endpoint demux check.
> IPv6 should have been designed with a header checksum
> covering only non-mutable fields, which would have helped when
> transports don't do the pseudoheader check.

It was designed with the assumption - if not requirement - that
transports DO the check, exactly so routers on the path don't have to.

Joe

---

From: <[email-masked]>
Date: Thu, 26 Nov 2015 06:06:23 +0000 (UTC)

What implementers don't like about IPv4 header checksumswas the recomputing checksum fixup when TTL changed.(And they'd do stupid things in routers like only dofixup on packets leaving the box, so as not to have tocompute it on all received packets that might be dropped,so processing paths became way more complex, it was messedup for recursion, etc. - and didn't serve its purpose asan input sanity check. Slight processing win, maintenancenightmare...)

Removing the header checksum and any hop-by-hop headerverification to avoid the recomputing checksum fixupwas throwing the demultiplexing baby out with thecomputing overhead bathwater.

Assuming that transport designers would do the rightthing when IPv6 designers didn't was in retrospectnaive. Mistakes don't get fixed, they get compounded.
 Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Joe Touch <[email-masked]>
 To: [email-masked]; Tom Herbert <[email-masked]> 
Cc: [email-masked]; Tsvwg IETF List <[email-masked]>
 Sent: Wednesday, 25 November 2015, 4:22
 Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Nov 2015 20:37:28 -0800

> On Nov 25, 2015, at 10:06 PM, <[email-masked]> <[email-masked]> wrote:
> 
> What implementers don't like about IPv4 header checksums
> was the recomputing checksum fixup when TTL changed.
> (And they'd do stupid things in routers like only do
> fixup on packets leaving the box, so as not to have to
> compute it on all received packets that might be dropped,
> so processing paths became way more complex, it was messed
> up for recursion, etc. - and didn't serve its purpose as
> an input sanity check. Slight processing win, maintenance
> nightmare...)

Agreed. 

> Removing the header checksum and any hop-by-hop header
> verification to avoid the recomputing checksum fixup
> was throwing the demultiplexing baby out with the
> computing overhead bathwater.

I don't follow this. How does this affect demuxing?

> Assuming that transport designers would do the right
> thing when IPv6 designers didn't was in retrospect
> naive.

They concluded that the checksum was needed to drop corrupted packets (that link later checks didn't catch) only at the endpoint and that was safe because the endpoint had to do this anyway. 

The didn't assume transport designers would implement checksums - they explicitly required it. 

> Mistakes don't get fixed, they get compounded.
> 
>

---

From: <[email-masked]>
Date: Sat, 28 Nov 2015 05:26:18 +0000 (UTC)

Joe
Routers do demultiplexing, in separating a stream of inputpackets into separate streams of output packets. Withouteven a header check at the router, corrupted headers cansend packets anywhere.

Hosts do demultiplexing, in separating input packetsinto streams going to different ports. Without a headercheck, a corrupted header can pollute any port viamisdelivery if a port number is corrupted. (And inIPv6, with zero UDP checksum, is the packet even deliveredto the right host?) But Joe, you know all this...sanity checking input helps with better output.

That the IPv6 designers thought requiring transportsto do pseudoheader checks as a last-ditch sanity checkon a tight end-to-end path where resends were easy wasnot enough; tunnelers complained about the overheads, we gotthe sophistry and complexity of RFC 6935 and 6936, torelax that checksum requirement and favour the tunnelledtraffic at the expense of any IP traffic on the networkthat didn't protect its own input stream against pollution.

Tunnels are first-class citizens, native IP traffic issecond-class. So rather than easier checksums it addsto a harder security armsrace against injection of unwantedtraffic...

(Still, zero UDP checksums on IPv6 will make IPv6 NATeasier, so hurrah for that particular compounding!)

But encouraging UDP-Lite use is one way out of thisparticular problem. "Think about any use of zero UDPchecksums very carefully" is lost on implementers,who will go 'that's code I don't need to write.'"Use UDP Lite on the IP header and your own headers"can be clearer.
Ohhttp://www.cisco.com/c/en/us/td/docs/wireless/controller/8-0/configuration-guide/b_cg80/b_cg80_chapter_010011110.html

"Implementation of IPv6 mandates complete payload checksum for User Datagram Protocol (UDP) which slows down the performance of the AP and the Controller. To minimize the performance impact, Controller and AP supports UDP Lite that mandates only a header checksum of the datagram, thereby avoiding checksum on the entire packet. Enabling UDP Lite enhances the packet processing time."

Nice to see some commercial adoption of UDP-Lite - I imaginethat TCP/UDP hardware offload is not a factor there.

Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Joe Touch <[email-masked]>
 To: [email-masked] 
Cc: Tom Herbert <[email-masked]>; Tsvwg IETF List <[email-masked]>
 Sent: Saturday, 28 November 2015, 15:37
 Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

Agreed. 

Assuming that transport designers would do the rightthing when IPv6 designers didn't was in retrospectnaive. 

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Nov 2015 21:44:26 -0800

>
>
>
> -------- Forwarded Message --------
> Date: 	Sat, 28 Nov 2015 05:26:18 +0000 (UTC)
> From: 	[email-masked]
> Reply-To: 	[email-masked]
> To: 	Joe Touch <[email-masked]>
> CC: 	Tom Herbert <[email-masked]>, Tsvwg IETF List <[email-masked]>
>
>
>
> Joe
>
> Routers do demultiplexing, in separating a stream of input
> packets into separate streams of output packets. Without
> even a header check at the router, corrupted headers can
> send packets anywhere.

IPv6 makes the assumption that most errors can be caught with link layer
protection.

It requires transport protection because of the E2E argument - that no
amount of hop-by-hop protection can be a substitute for E2E protection
because there can be other sources of error (e.g., routers mangling
correct headers but computing new, valid checksums).

> Hosts do demultiplexing, in separating input packets
> into streams going to different ports. Without a header
> check, a corrupted header can pollute any port via
> misdelivery if a port number is corrupted. (And in
> IPv6, with zero UDP checksum, is the packet even delivered
> to the right host?)

That's exactly why IPv6 requires UDP checksums.

...
> That the IPv6 designers thought requiring transports
> to do pseudoheader checks as a last-ditch sanity check
> on a tight end-to-end path where resends were easy was
> not enough;

That's not what they assumed.

They assumed that link transmission errors would be caught by link
checksums and that an E2E check was needed regardless of any HBH checks.
Given those two, a HBH IP layer check was unnecessary.

> tunnelers complained about the overheads, we got
> the sophistry and complexity of RFC 6935 and 6936, to
> relax that checksum requirement and favour the tunnelled
> traffic at the expense of any IP traffic on the network
> that didn't protect its own input stream against pollution.

A tunnel acts as a link layer, and by the above logic should have needed
its own protection, but again it is assumed that "true link" (the layer
above the physical) is the one that already provides that level of HBH
protection against physical transmission errors.

> Tunnels are first-class citizens, native IP traffic is
> second-class.

I don't understand what you mean.

Tunnels are now supposed to act like IPv6 - assume the layer above the
physical protects against transmission errors and assume that an E2E
layer checksum protects the E2E communication. There is no significant
benefit to protections on each hop at any other layer - that's all that
has been recognized.

> So rather than easier checksums it adds
> to a harder security armsrace against injection of unwanted
> traffic...

Those who inject unwanted traffic compute valid checksums. The issue is
detecting errors - the only errors we gave up detecting were basically
errors between L2 in and L2 out. AFAIR, the studies cited at the time
indicated that most of those were programming errors (i.e., generating
incorrect checksums) rather than catching true errors (e.g., memory or
CPU flaws).

> (Still, zero UDP checksums on IPv6 will make IPv6 NAT
> easier, so hurrah for that particular compounding!)
>
>
> But encouraging UDP-Lite use is one way out of this
> particular problem. "Think about any use of zero UDP
> checksums very carefully" is lost on implementers,
> who will go 'that's code I don't need to write.'
> "Use UDP Lite on the IP header and your own headers"
> can be clearer.

UDPlite helps for realtime audio where getting some bad data is better
than getting no data, but not for tunnels. Tunnels should follow the
same logic as IPv6 - rely on the layer above the physical to detect
transmission errors and rely on E2E protection for other errors.

Using UDPlite to avoid work is incorrect for E2E uses unless the E2E
protocol supports undetected payload errors.

Joe

> Oh
http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-0/configuration-guide/b_cg80/b_cg80_chapter_010011110.html
<http://www.cisco.com/c/en/us/td/docs/wireless/controller/8-0/configuration-guide/b_cg80/b_cg80_chapter_010011110.html>
>
>
> "Implementation of IPv6 mandates complete payload checksum for User
> Datagram Protocol (UDP) which slows down the performance of the AP and
> the Controller. To minimize the performance impact, Controller and AP
> supports UDP Lite that mandates only a header checksum of the datagram,
> thereby avoiding checksum on the entire packet. Enabling UDP Lite
> enhances the packet processing time."
>
>
> Nice to see some commercial adoption of UDP-Lite - I imagine
> that TCP/UDP hardware offload is not a factor there.
>
>
> ------------------------------------------------------------------------
> *From:* Joe Touch <[email-masked]>
> *To:* [email-masked]
> *Cc:* Tom Herbert <[email-masked]>; Tsvwg IETF List <[email-masked]>
> *Sent:* Saturday, 28 November 2015, 15:37
> *Subject:* Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update
>
>
>
> On Nov 25, 2015, at 10:06 PM, <[email-masked]
> <mailto:[email-masked]>> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> They concluded that the checksum was needed to drop corrupted packets
> (that link later checks didn't catch) only at the endpoint and that was
> safe because the endpoint had to do this anyway.
>
>> Lloyd Wood [email-masked] <mailto:[email-masked]>
>> http://about.me/lloydwood
>>
>> ------------------------------------------------------------------------
>> *From:* Joe Touch <[email-masked] <mailto:[email-masked]>>
>> *To:* [email-masked] <mailto:[email-masked]>; Tom
>> Herbert <[email-masked] <mailto:[email-masked]>>
>> *Cc:* [email-masked] <mailto:[email-masked]>; Tsvwg IETF List
>> <[email-masked] <mailto:[email-masked]>>
>> *Sent:* Wednesday, 25 November 2015, 4:22
>> *Subject:* Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update
>>
>>
>>
>>
>>
>> On 11/23/2015 3:46 PM, [email-masked]
>> <mailto:[email-masked]> wrote:

---

From: <[email-masked]>
Date: Sat, 28 Nov 2015 06:14:58 +0000 (UTC)

"That's exactly why IPv6 requires UDP checksums."

RFC6935 is standards track. It changes IPv6. IPv6 no longerrequires UDP checksums.RFC7510 is standards track. It changes IPv6. IPv6 no longerrequires UDP checksums.
Stop saying something absolute that is no longer true. I expectthese 'special cases' to be extended so that theUDP checksum requirement is relaxed further. In each case,the document will be written from the perspective and needsof the special case, rather than from the perspective ofthe Internet as a whole, and host and port pollution frommisdelivered zero-checksum packets will eventually be recognisedas problem side-effects.

IPv6 designers thought an end-to-end check was so importantthey... thought they could leave it up to transport designers.That's not working well.

Do distinguish between a hop-by-hop header check overmutable and non-mutable fields (IPv4) and an end-to-end pseudo-header check of non-mutable fields...

UDP Lite can offer benefits for tunnel headers not checked inpayload checks, e.g. endtoend checking of MPLS stacks thatthe tunnelled payloads don't check. The demultiplexingcheck it provides matters, and complements a payload thatchecks itself - not just a raw errored stream of bits.

I've said pretty much all there is to say about thisproblem. I'll look back in a couple of years to see ifanything has improved.

Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Joe Touch <[email-masked]>
 To: [email-masked] 
Cc: [email-masked]; Tom Herbert <[email-masked]>; Tsvwg IETF List <[email-masked]>
 Sent: Saturday, 28 November 2015, 16:44
 Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

...

Joe

---

From: Joe Touch <[email-masked]>
Date: Fri, 27 Nov 2015 22:28:02 -0800

On 11/27/2015 10:14 PM, [email-masked] wrote:
> RFC6935 is standards track. It changes IPv6. IPv6 no longer
> requires UDP checksums.
> RFC7510 is standards track. It changes IPv6. IPv6 no longer
> requires UDP checksums.
> 
> Stop saying something absolute that is no longer true. 

IPv6 requires E2E transport checksums.

When UDP is used as a tunnel, it isn't an E2E transport anymore - it's a
link layer for some other protocol (e.g., the tunneled packet).

None of this is inconsistent with the original intent of how IPv6 was
designed.

> I expect
> these 'special cases' to be extended so that the
> UDP checksum requirement is relaxed further. In each case,
> the document will be written from the perspective and needs
> of the special case, rather than from the perspective of
> the Internet as a whole, and host and port pollution from
> misdelivered zero-checksum packets will eventually be recognised
> as problem side-effects.

You should consider that both of these special cases have something in
common - that what is used as a "transport" is really just a tunnel
encapsulation protocol, not an E2E transport for a user application.

Will we see more of those? Yes.

Will we see cases where UDP checksums can be ditched for true E2E apps?
I doubt it.

> IPv6 designers thought an end-to-end check was so important
> they... thought they could leave it up to transport designers.
> That's not working well.

It's actually working out exactly as it was intended.

> Do distinguish between a hop-by-hop header check over
> mutable and non-mutable fields (IPv4) and an end-to-end pseudo-
> header check of non-mutable fields...
> 
> 
> UDP Lite can offer benefits for tunnel headers not checked in
> payload checks, e.g. endtoend checking of MPLS stacks that
> the tunnelled payloads don't check. The demultiplexing
> check it provides matters, and complements a payload that
> checks itself - not just a raw errored stream of bits.

UDPlite goes back to IPv4-style protection of network headers. Unless we
think that the L2-above-physical or (true)E2E layers aren't doing the
job IPv6 expects, we (still) won't be needing it for tunnels.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Sat, 28 Nov 2015 10:39:16 -0800

> checks itself - not just a raw errored stream of bits.
The UDP checksum already offers those same benefits already. To me,
the question stills seems to be how would UDP-Lite be an improvement
over that? An example of how UDP-Lite with a partial checksum would be
a applied to a tunneling protocol (such as MPLS/UDP) might be useful
to help answer that question...

Thanks,
Tom

---

From: <[email-masked]>
Date: Sun, 29 Nov 2015 02:19:14 +0000 (UTC)

Joe,
> link layer for some other protocol (e.g., the tunneled packet).

That would make UDP without checksum a link layer without checksumsfor the protocols it carries.
Ethernet is a link layer.Are you advocating that we turn off Ethernet checksums as well? Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Joe Touch <[email-masked]>
 To: [email-masked] 
Cc: [email-masked]; Tom Herbert <[email-masked]>; Tsvwg IETF List <[email-masked]>
 Sent: Saturday, 28 November 2015, 17:28
 Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

Joe

---

From: Joe Touch <[email-masked]>
Date: Sat, 28 Nov 2015 18:22:14 -0800

> On Nov 28, 2015, at 6:19 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Joe,
> 

Correct. 

> 
> Ethernet is a link layer.
> Are you advocating that we turn off Ethernet checksums as well?

If it is not the first layer above physical, yes. Otherwise, no. 

Joe

---

From: <[email-masked]>
Date: Sun, 29 Nov 2015 23:47:25 +0000 (UTC)

As an analogy, that doesn't work well.In practice, that won't work well either.

Bridging frames via e.g. PWE3 rather messes things up.

The Eth frame is tunnelled over part of its path,so doesn't need a checksum by your thinking, because it'snot just above physical layer. Until it's bridged, andit is.

But tunnelling thinking is that reliability is a payloadproblem, so that underlying checksums can be turned offfor performance. Leading to no checksums throughout thestack at any scope.

While collapsing the stack suggests that you should onlyneed error checks just above physical errors and as anend-to-end guarantee, with nothing needed inbetween, ina complex heterogenous world where you can't be sureyou're running over physical and can't trust thereliability of other devices, error insertion andcorrection is never that simple.

 Sent: Sunday, 29 November 2015, 13:22

Joe,

Correct. 

Ethernet is a link layer.Are you advocating that we turn off Ethernet checksums as well?

Joe

Joe

---

From: Greg Shepherd <[email-masked]>
Date: Sun, 29 Nov 2015 16:38:46 -0800

Sent from my iPhone

> On Nov 29, 2015, at 15:47, <[email-masked]> <[email-masked]> wrote:
> 
> As an analogy, that doesn't work well.
> In practice, that won't work well either.
> 
> 
> The Eth frame is tunnelled over part of its path,
> so doesn't need a checksum by your thinking, because it's
> not just above physical layer. Until it's bridged, and
> it is.
> 
> 
> But tunnelling thinking is that reliability is a payload
> problem, so that underlying checksums can be turned off
> for performance. Leading to no checksums throughout the
> stack at any scope.
> 
> 
> While collapsing the stack suggests that you should only
> need error checks just above physical errors and as an
> end-to-end guarantee, with nothing needed inbetween, in
> a complex heterogenous world where you can't be sure
> you're running over physical

In what world will we not be running over physical?

Greg

> and can't trust the
> reliability of other devices, error insertion and
> correction is never that simple.
> 
> 
>

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Nov 2015 10:24:57 -0800

> In practice, that won't work well either.

It works fine.

Packets never go over a physical layer by themselves; a node places them
there.

Any packet placed over a physical layer has to have a checksum (which is
the term I'll use here for any error checking code, sum, CRC< or other)
computed/inserted/added via a wrapper (another protocol layer), to
protect physical layer transit.

Any packet taken from a physical layer has to have that checksum validated.

The protocol name - or conventional layer assignment - is irrelevant. If
you put IPv6 over the wire directly, you would need a layer that adds
that checksum (e.g., PPP). If you put ethernet over a tunnel, its
checksum (CRC) isn't nearly as helpful.

The same is true at the app layer; apps that care about packets being
correct need checksums at that layer, apps that don't do not.

Checksums used at other layers are largely unnecessary overhead. At the
time IPv6 was designed, the claim was that most errors caught by such
intermediate layer checksums were due to programmer error, and that much
of the time the error was in the checksum algorithm itself - i.e., the
checksum became the source of errors, not a way to detect other errors.

You can argue that every layer cares a lot about bad packets and that
errors can happen everywhere; the former may be true, but the latter
hasn't been for a while.

However, unless you have a layer that knows it can use partly corrupt
data (typically only the app layer, i.e., the ultimate user of the
entire packet, knows this), then IF you need to detect errors, you need
protection over the whole packet.

I.e., UDPlite makes sense only for *some* applications. IMO, it has no
use for tunnels (no checksum does, IMO - because I believe that the
assessment of sources of error done during IPv6 has not changed).

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Nov 2015 10:37:27 -0800

> protect physical layer transit.

Let me clarify that by parsing it more clearly:

Just before using a physical layer, do one of the following:

	- compute the checksum and insert
	into an existing header/trailer field
or
	- add another protocol layer that has a field
	where you can put such a checksum

Just as it comes off the physical layer:

	- validate the checksum of the received message

I.e., only devices that actually put messages onto or take messages off
of physical layers NEED to do this.

Others CAN, but the message from the IPv6 discussion was that these are
often more harm than good and likely unnecessary overhead as *hop by
hop* protections.

The same type of rules apply to app layers in the same way, as the E2E.

Every device needs to figure out for itself whether it is intended as
the source/sink of app traffic or just a transit (for the E2E) and
whether it sends/received from a physical link (for the HBH). Only there
are the checks needed.

Joe

---

From: <[email-masked]>
Date: Mon, 30 Nov 2015 23:31:38 +0000 (UTC)

> At the time IPv6 was designed, the claim was that most errors> caught by such intermediate layer checksums were due to> programmer error, and that much of the time the error was> in the checksum algorithm itself - i.e., the checksum became> the source of errors, not a way to detect other errors. 
No, that's observer bias. How the checksum fixup was implementedwas the source of errors, not the algorithm. But not an actualprogrammer error. Let me elaborate on that.

Imagine you're a programmer tasked with making your router runas fast as possible. You can do that by:

- only working on IPv4 header checksums on the way out of the box,because if a packet is dropped, its checksum doesn't need to be worked on. (this is well before checksum offload.)

- doing incremental checksum fixup on the existing checksum whenyou modify TTL. Don't recompute the entire checksum or read bytesyou don't have to, because it's faster. The header is probably good,you've assumed it's good because you've already processed thepacket and it's on the way out to be transmitted, so why would youbother checking it by using the checksum for its intendedpurpose after you've already done all those forwarding lookups?Waste of time.

- not actually using the checksum for checking the header. It'sprobably good, so waste of time, just do the incremental fixupyou have to do as the last thing out of the box, move on. (Yes,I'm repeating myself to ensure this is clear.)

Now, one can argue that that is programmer error, but it's reallyperverse incentives. (Aside: One Major Router had a slowish box.A Genius Programmer rewrote all the slow bits and made ittwice as fast, and it was the staple of their sales for years. Theoriginal dev team was not happy about how this was done or inmaintaining his code, inline assembly checksum fixups and all.But - twice as fast pps! More sales!)

The result is that any packet errors propagate downstream, becausethe first receiving box just did an incremental checksum fixup andmoved the packet on. And the second box just... and so on. So you can'teven diagnose where the errors are being introduced, or theircauses. Blame the checksum. Blame the algorithm.
And corrupted packets cascade onwards.

There's an analogy here with the story about WW2 planes arrivingback from combat with bullet holes, so they strengthened the partsthat weren't holed, on the grounds that if those bits had been holedthe plane wouldn't have survived. They could only see the endof the process, not where the holes were taking place, and they hadto account for observer bias.

So UDP and UDP-Lite in the endhosts become the last defenceagainst smart programmers tasked with making boxes fast. Exceptwe're turning UDP checksums off, so we can't even observe theproblem.

Oh, and errors do happen everywhere; good old radiation and physics.That's why ECC RAM exists - but smart manufacturers save money bynot implementing it...

 Sent: Tuesday, 1 December 2015, 5:24

It works fine.

Joe

---

From: <[email-masked]>
Date: Mon, 30 Nov 2015 23:37:55 +0000 (UTC)

> often more harm than good and likely unnecessary overhead as *hop by
That's because the IPv4 header checksum covered mutable fields, and wasrecomputed quickly - my other email.
On the other hand, if the IP header checksum only covered non-mutable fields(no TTL, no class of service - yes, NAT makes addresses mutable, but recomputingthe checksums afterwards is NAT's problem) then the boxes would have simplystill Not Done Any Checking of the Checksum anyway.
Because... faster! And it's probably good, right?
I'm wondering at what point applications demand we turn off checksum checkingin hosts for speed. We're already there with tunnels - what's next?
L.
your really fast distributed database is going to wind up really corrupt.
Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Joe Touch <[email-masked]>
 To: [email-masked] 
Cc: [email-masked]; Tom Herbert <[email-masked]>; Tsvwg IETF List <[email-masked]>
 Sent: Tuesday, 1 December 2015, 5:37
 Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Nov 2015 15:51:10 -0800

Lloyd,

On 11/30/2015 3:31 PM, [email-masked] wrote:
>> At the time IPv6 was designed, the claim was that most errors
>> caught by such intermediate layer checksums were due to
>> programmer error, and that much of the time the error was
>> in the checksum algorithm itself - i.e., the checksum became
>> the source of errors, not a way to detect other errors.
>  
> 
> No, that's observer bias. 

There were studies that found source code errors and failed to find
checksum errors not linked to those source code errors. That's observation.

> How the checksum fixup was implemented
> was the source of errors, not the algorithm. But not an actual
> programmer error. Let me elaborate on that.

No need, if you're focusing on implementation vs. alg error. I meant to
say that these were implementation bugs that ended up being fixed -
regardless of why there was an implementation error.

The point is that they did NOT find memory errors or line errors that
were not caught by the "link" (i.e., next to physcal-layer) checks.

...
> Oh, and errors do happen everywhere; good old radiation and physics.
> That's why ECC RAM exists - but smart manufacturers save money by
> not implementing it...

While that's true in principle, in practice they're simply not a
significant source of errors vs E2E and link.

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Nov 2015 15:54:09 -0800

On 11/30/2015 3:37 PM, [email-masked] wrote:
> On the other hand, if the IP header checksum only covered non-mutable fields
> (no TTL, no class of service - yes, NAT makes addresses mutable, but
> recomputing
> the checksums afterwards is NAT's problem) then the boxes would have simply
> still Not Done Any Checking of the Checksum anyway.
> 
> I'm wondering at what point applications demand we turn off checksum
> checking
> in hosts for speed. We're already there with tunnels - what's next?

We have hardware assist so that the cost of the checksum is masked
during the DMA from the line card into main memory.

It would be useful to understand how many errors are actually caught by
TCP and UDP checksums, esp. given the prevalence of security that would
likely fail (and drop the packet) in the presence of an error anyway.

Joe

---

From: Tom Herbert <[email-masked]>
Date: Mon, 30 Nov 2015 16:04:52 -0800

> likely fail (and drop the packet) in the presence of an error anyway.
I looked at this at Google about 1 1/2 yrs. ago. The number of
checksum errors being reported throughout the network was non-zero (in
the order of 10's per day). However, there have been instances of
hardware failures where the number of checksum errors would spike on
certain machines. Weak as it is, the transport checksum does provide
some benefit. Given that we basically get the processing for free (all
NICs we would deploy in a DC support offload both TCP and UDP
checksum), I don't really see any reason to turn off for either
applications or tunnels.

Tom

---

From: <[email-masked]>
Date: Tue, 1 Dec 2015 00:02:10 +0000 (UTC)

> checksum errors not linked to those source code errors. That's observation.
Got citation details? Since much router code is closed source, there's bias there... Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Joe Touch <[email-masked]>
 To: [email-masked] 
Cc: [email-masked]; Tom Herbert <[email-masked]>; Tsvwg IETF List <[email-masked]>
 Sent: Tuesday, 1 December 2015, 10:51
 Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update
   
Lloyd,

...

Joe

---

From: <[email-masked]>
Date: Tue, 1 Dec 2015 00:36:25 +0000 (UTC)

> are the checks needed. The assumption there is that the costs of transmissions,resends, and effects of errors are low, with rapid feedbackclosed loops to handle transmission resends.
If the costs are high (satellite, DTN, low rate link)it can pay to check everything.
I think you're giving far too much agency to the devices,and not enough to the programmers...
Lloyd Wood [email-masked] http://about.me/lloydwood 
      From: Joe Touch <[email-masked]>
 To: [email-masked] 
Cc: [email-masked]; Tom Herbert <[email-masked]>; Tsvwg IETF List <[email-masked]>
 Sent: Tuesday, 1 December 2015, 5:37
 Subject: Re: [tsvwg] UDP guidelines draft (5405bis) -07 - update

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Nov 2015 16:55:27 -0800

On 11/30/2015 4:36 PM, [email-masked] wrote:
> The assumption there is that the costs of transmissions,
> resends, and effects of errors are low, with rapid feedback
> closed loops to handle transmission resends.

The primary assumption is that most errors are introduced at the
physical layer.

They can be corrected via FEC or ARQ at the layer just above physical,
or E2E. Other layers of detection, correction, and retransmission can be
useful in specific, targeted environments where a significant number of
errors occur at other layers, but in the typical case that is just a
large amount of mechanism to correct too small a source of errors.

> it can pay to check everything.

Checks at other layers are useful only if those are a significant source
of error. Yes, there are cases where that's true, but when that's the
case there are often other ways in which the packets are protected (ECC
memory for space environments).

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Nov 2015 17:00:35 -0800

On 11/30/2015 4:02 PM, [email-masked] wrote:
> Got citation details? Since much router code is closed source, there's
> bias there...

I recall the discussions at the IETF, such as here:

https://www.ietf.org/mail-archive/web/ipv6/current/msg09077.html

https://www.ietf.org/mail-archive/web/ipv6/current/msg09086.html

Those include citations to a few of the papers that drove some of the
discussion at the time.

Joe

---

From: <[email-masked]>
Date: Tue, 1 Dec 2015 02:55:12 +0000 (UTC)

I attended the Cisco IPv6 'ping party' in 2000.
RFC2460 was published in 1998.

Those emails are from 2008.Hearsay as far as original IPv6 design discussion goes...

 Sent: Tuesday, 1 December 2015, 12:00

Joe

---

From: Joe Touch <[email-masked]>
Date: Mon, 30 Nov 2015 21:23:28 -0800

http://dl.acm.org/citation.cfm?id=294364

> On Nov 30, 2015, at 6:55 PM, <[email-masked]> <[email-masked]> wrote:
> 
> Those emails are from 2008.
> Hearsay as far as original IPv6 design discussion goes...
> 
>

---

From: <[email-masked]>
Date: Tue, 1 Dec 2015 06:04:06 +0000 (UTC)

Yes, Stone's papers and PhD thesis are the usual referenceson errors and reliability for the Internet crowd.ftp://ftp.cis.upenn.edu/pub/mbgreen/papers/ton98.pdf
is an available copy of that paper. 
http://www.tc.faa.gov/its/worldpac/techrpt/tc14-49.pdf
http://checksumcrc.blogspot.com.au/
http://betterembsw.blogspot.com.au/2014/03/random-hardware-faults.html

I'm glad that e.g. the FAA is looking at computer reliability,and that work on better error detection is still ongoing.

 Sent: Tuesday, 1 December 2015, 16:23

Joe

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 1 Dec 2015 07:07:22 +0000 (UTC)

blockquote, div.yahoo_quoted { margin-left: 0 !important; border-left:1px #715FFA solid !important;  padding-left:1ex !important; background-color:white !important; } > I attended the Cisco IPv6 'ping party' in 2000.
the problem with having a celebration for getting two IPv4 routers reprogrammed to start sending IPv6 packets with IPv6 ICMP is that you really shouldn't slice or eat the celebratory cake with 'IPv6' iced on it.
because then there would be IPv6 fragments...

Lloyd [email-masked]

On Tuesday, December 1, 2015, 2:04 PM, [email-masked] <[email-masked]> wrote:

---

From: Lloyd Wood <[email-masked]>
Date: Tue, 1 Dec 2015 07:07:22 +0000 (UTC)