IETF Logo Mail Archive

Re: [tcpm] draft-eggert-tcpm-historicize-00

<L.Wood@surrey.ac.uk> Mon, 28 June 2010 08:35 UTC

Return-Path: <L.Wood@surrey.ac.uk>
X-Original-To: tcpm@core3.amsl.com
Delivered-To: tcpm@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 028053A69A2 for <tcpm@core3.amsl.com>; Mon, 28 Jun 2010 01:35:32 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.821
X-Spam-Level:
X-Spam-Status: No, score=-5.821 tagged_above=-999 required=5 tests=[AWL=0.778, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id weQIcpNj1eTt for <tcpm@core3.amsl.com>; Mon, 28 Jun 2010 01:35:30 -0700 (PDT)
Received: from mail72.messagelabs.com (mail72.messagelabs.com [193.109.255.147]) by core3.amsl.com (Postfix) with ESMTP id 533D13A67E3 for <tcpm@ietf.org>; Mon, 28 Jun 2010 01:35:30 -0700 (PDT)
X-VirusChecked: Checked
X-Env-Sender: L.Wood@surrey.ac.uk
X-Msg-Ref: server-6.tower-72.messagelabs.com!1277714138!3945149!1
X-StarScan-Version: 6.2.4; banners=-,-,-
X-Originating-IP: [131.227.200.31]
Received: (qmail 1294 invoked from network); 28 Jun 2010 08:35:38 -0000
Received: from unknown (HELO EXHT011P.surrey.ac.uk) (131.227.200.31) by server-6.tower-72.messagelabs.com with AES128-SHA encrypted SMTP; 28 Jun 2010 08:35:38 -0000
Received: from EXMB01CMS.surrey.ac.uk ([169.254.1.69]) by EXHT011P.surrey.ac.uk ([131.227.200.31]) with mapi; Mon, 28 Jun 2010 09:35:38 +0100
From: L.Wood@surrey.ac.uk
To: touch@ISI.EDU
Date: Mon, 28 Jun 2010 09:35:37 +0100
Thread-Topic: [tcpm] draft-eggert-tcpm-historicize-00
Thread-Index: AcsWnOK8q7Ic9XFdTySujVfZa7tw3w==
Message-ID: <A3A73BD7-045B-4C56-ACCF-7D996D110BA5@surrey.ac.uk>
References: <20100609151532.8E75E28C0D0@core3.amsl.com><33D3BDE9-7E8D-4DF0-B8D5-BFFC66CF9C99@nokia.com><2262C708-DF9A-4DD9-9378-D84C5AF330AC@nokia.com><C304DB494AC0C04C87C6A6E2FF5603DB48105A5A82@NDJSSCC01.ndc.nasa.gov> <0C53DCFB700D144284A584F54711EC580A0CE306@xmb-sjc-21c.amer.cisco.com> <5FDC413D5FA246468C200652D63E627A0935F804@LDCMVEXC1-PRD.hq.netapp.com> <4C24F73F.9060402@isi.edu> <87877965-FBC4-4A67-917A-EB48BED2CBB1@surrey.ac.uk> <4C26424F.3020005@isi.edu> <9858250F-96F1-427A-A211-004A9FE3FE82@surrey.ac.uk> <4C264F64.4010908@isi.edu> <AE08BDBD-CD39-4BE0-9E93-DA669C67BE0D@surrey.ac.uk> <4C265435.3010601@isi.edu>
In-Reply-To: <4C265435.3010601@isi.edu>
Accept-Language: en-US, en-GB
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US, en-GB
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: tcpm@ietf.org, ananth@cisco.com, Anumita.Biswas@netapp.com, L.Wood@surrey.ac.uk
Subject: Re: [tcpm] draft-eggert-tcpm-historicize-00
X-BeenThere: tcpm@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <tcpm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/tcpm>
List-Post: <mailto:tcpm@ietf.org>
List-Help: <mailto:tcpm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/tcpm>, <mailto:tcpm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Jun 2010 08:35:32 -0000

On 26 Jun 2010, at 20:25, Joe Touch wrote:
> The only way a packet is accepted erroneously at a receiver, but would cause an
> problem, would be:
> 	link check OK
> 	TCP (1s compl) checksum OK
> 	new checksum FAIL
> 
> I.e., the only reason a new TCP checksum would be useful is in this case. If
> either of the link or existing TCP checks succeed, there's no new problem.

An example of that scenario is an echo server:
http://en.wikipedia.org/wiki/Echo_protocol
http://www.faqs.org/rfcs/rfc862.html
http://www.faqs.org/rfcs/rfc2075.html

which swaps source and destination addresses. These are covered by the pseudo-header
check; the 1's complement checksum is oblivious to the byte swapping, and the
echoed packet is still considered valid, even though it has been altered.
A stronger TCP checksum would detect this modification, and have to be recomputed.
much as payload checksums are recomputed through NAT boxes.


Lloyd Wood
L.Wood@surrey.ac.uk
http://sat-net.com/L.Wood

v2.23.0 | Report a Bug | By Email