>From owner-misc+M137142=deraadt=cvs.openbsd....@openbsd.org Sat Jan 25
>12:41:53 2014
>DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
>h=content-type:mime-version:subject:from:in-reply-to:date
>:content-transfer-encoding:message-id:references:to;
>bh=utWhBX3niMM2LVtE8mfHlY/ky3wCOdmsmIjoMdLaY5Q=;
>b=EDAHtMzwKNWiAeY56T7Fkl0Q29kOMAMn5QUkTmADQG5qZJ7k9mOWDRnjlN0DLClrDO
>TpAA7OUGMfA55tXh/dEkKgtjb3inl7IMNyhUahJrETz0uHedS9xyZSTKBbDi9zVWfey1
>V3broKdxZP3MA6jmF0aT4jdkaDfC/Hj7UhSX79Qc6zMkr3wZMN6e3sA+31RCnrCj/hwf
>8oDhmqPtNYVGBZMm9hyhX1x/FTp/3Ra6tWzUnDtnKozUq2ZeovgLwG3JjcFooQ5572Ef
>w1uIA4w2em5DRlUSdDtome8dVVewRb25ZeNkPMe8Gul6azVh2zqNNYx7a9b71mLTwGML YXwA==
>X-Received: by 10.68.204.4 with SMTP id ku4mr21464025pbc.66.1390678851934;
>Sat, 25 Jan 2014 11:40:51 -0800 (PST)
>Content-Type: text/plain; charset=us-ascii
>Mime-Version: 1.0 (Apple Message framework v1085)
>Subject: Re: NAT reliability in light of recent checksum changes
>From: Richard Procter <richard.n.proc...@gmail.com>
>In-Reply-To: <20140122061907.gk15...@quigon.bsws.de>
>Date: Sun, 26 Jan 2014 08:40:44 +1300
>Content-Transfer-Encoding: 8bit
>References: <8d493091-c15d-46a2-8004-32dd59395...@gmail.com>
><20140122061907.gk15...@quigon.bsws.de>
>To: misc@openbsd.org
>X-Mailer: Apple Mail (2.1085)
>List-Help: <mailto:majord...@openbsd.org?body=help>
>List-ID: <misc.openbsd.org>
>List-Owner: <mailto:owner-m...@openbsd.org>
>List-Post: <mailto:misc@openbsd.org>
>List-Subscribe: <mailto:majord...@openbsd.org?body=sub%20misc>
>List-Unsubscribe: <mailto:majord...@openbsd.org?body=unsub%20misc>
>X-Loop: misc@openbsd.org
>Precedence: list
>Sender: owner-m...@openbsd.org
>
>On 22/01/2014, at 7:19 PM, Henning Brauer wrote:
>
>> * Richard Procter <richard.n.proc...@gmail.com> [2014-01-22 06:44]:
>>> This fundamentally weakens its usefulness, though: a correct
>>> checksum now implies only that the payload likely matches
>>> what the last NAT router happened to have in its memory
>>
>> huh?
>> we receive a packet with correct cksum -> NAT -> packet goes out with
>> correct cksum.
>> we receive a packet with broken cksum -> NAT -> we leave the cksum
>> alone, i. e. leave it broken.
>
>Christian said it better than me: routers may corrupt data
>and regenerating the checksum will hide it.
>
>That's more than a theoretical concern. The article I
>referenced is a detailed study of real-world traces
>co-authored by a member of the Stanford distributed systems
>group that concludes "Probably the strongest message of this
>study is that the networking hardware is often trashing the
>packets which are entrusted to it"[0].
>
>More generally, TCP checksums provide for an acceptable
>error rate that is independent of the reliability of the
>underlying network[*] by allowing us to verify its workings.
>But it's no longer possible to verify network operation if
>it may be regenerating TCP checksums, as these may hide
>network faults. That's a fundamental change from the scheme
>Cerf and Khan emphasized in their design notes for what
>became known as TCP:
>
>"The remainder of the packet consists of text for delivery
>to the destination and a trailing check sum used for
>end-to-end software verification. The GATEWAY does /not/
>modify the text and merely forwards the check sum along
>without computing or recomputing it."[1]
>
>> It doesn't seem you know what you are talking about. the
>> cksum is dead simple, if we had bugs in claculating or
>> verifying it, we really had a LOT of other problems.
>
>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.
>
>> There is no "undetected error rate", nothing really changes
>> there.
>
>I disagree. Every TCP stream containing aribitrary data may
>have undetected errors as checksums cannot detect all the
>errors networks may make (being shorter than the data they
>cover). The engineer's task is to make network errors
>reliably negligible in practice.
>
>As network regenerated checksums may hide any amount of
>arbitrary data corruption I believe it's correct to say the
>network error rate undetected by TCP is then "unknown and
>unbounded".
>
>best,
>Richard.
>
>[*] Under reasonable assumptions of the error modes most likely
>in practice. And some applications require lower error rates
>than TCP checksums can provide.
>
>[0]
>http://conferences.sigcomm.org/sigcomm/2000/conf/paper/sigcomm2000-9-1.pdf
>
>Jonathan Stone and Craig Partridge. 2000. When the CRC and
>TCP checksum disagree. In Proceedings of the conference on
>Applications, Technologies, Architectures, and Protocols for
>Computer Communication (SIGCOMM '00). ACM, New York, NY,
>USA, 309-319. DOI=10.1145/347059.347561
>http://doi.acm.org/10.1145/347059.347561
>
>[1] "A Protocol for Packet Network Intercommunication"
>V. Cerf, R. Khan, IEEE Trans on Comms, Vol Com-22, No 5 May
>1974 Page 3 in original emphasis.
