On 28/01/2014, at 4:19 AM, Simon Perreault wrote:
> Le 2014-01-25 14:40, Richard Procter a écrit :
>> I'm not saying the calculation is bad. I'm saying it's being
>> calculated from the wrong copy of the data and by the wrong
>> device. And it's not just me saying it: I'm quoting the guys
>> who designed TCP.
>
> Those guys didn't envision NAT.
>
> If you want end-to-end checksum purity, don't do NAT.
Let's look at the options.
The world needs more addresses than IPv4 provides and NAT
gives them to us. There's IPv6, which has about a hundred
billion addresses for every bacteria estimated to live on
the planet[0], but it's not looking to replace IPv4 any time
soon. So NAT is here to stay for a good while longer.
Perhaps I can at least stop using NAT on my own network. In
my case I can't but let's assume I do. This eliminates one
source of error. But my TCP streams may still have
now-undetected one-bit errors (at least) if there may be
routers out there regenerating checksums. As long as there
are, good checksums no longer mean as much by themselves and
if I want at least some assurance the network did its job, I
still need some other way (e.g, checking the network path
contains no such routers, either by inspection or
statistically, or by reimplementing an end-to-end checksum
at a higher layer, etc). Regenerated checksums affect me
whether or not I use NAT myself.
Another option is to always update the checksum as versions
prior to version 5.4 did. It's reasonable to ask, well is
any more reliable than recomputing them as 5.4 does?
That is, can the old update code hide payload corruption,
too?
In order to hide payload corruption the update code would
have to modify the checksum to exactly account for it. But
that would have to happen by accident, as it never considers
the payload. It's not impossible, but, on the other hand,
checksum regeneration guarantees to hide any bad data.
So updates are more reliable.
A lot more reliable, in fact, as you'd require precisely
those memory errors necessary to in effect compute the
correct update, or some freak fault in the ALU that did the
same thing, or some combination of both. And as that has
nothing to do with the update code it is in principle
possible for non-NAT connections, too. For the hardware,
updates are just an extra load/modify/store and so the
chances of a checksum update hiding a corrupted payload are
in practical terms equivalent to those of normal forwarding.
So your statement holds only if checksums are being
regenerated. In general, NAT needn't compromise end-to-end
TCP payload checksum integrity, and in versions prior to
5.4, it didn't.
best,
Richard.
[0] "Prokaryotes: The unseen majority"
Proc Natl Acad Sci U S A. 1998 June 9; 95(12): 6578–6583.
https://www.ncbi.nlm.nih.gov/pmc/articles/PMC33863/
2^128 IPv6 addresses = ~ 10^38
~ 10^38 IPv6 addresses / ~ 10^30 bacteria cells
=
~ 10^8 addresses per cell.
[1] RFC1071 "Computing the Internet Checksum" p21
"If anything, [this end-to-end property] is the most powerful
feature of the TCP checksum!". Page 15 is also touches on
the end-to-end preserving properties of checksum update.
