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

Joe Touch <touch@isi.edu> Mon, 28 June 2010 16:40 UTC

Return-Path: <touch@isi.edu>
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 106BC3A6A71 for <tcpm@core3.amsl.com>; Mon, 28 Jun 2010 09:40:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.599
X-Spam-Level:
X-Spam-Status: No, score=-2.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599]
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 hQeH8FH6Vvg0 for <tcpm@core3.amsl.com>; Mon, 28 Jun 2010 09:40:39 -0700 (PDT)
Received: from vapor.isi.edu (vapor.isi.edu [128.9.64.64]) by core3.amsl.com (Postfix) with ESMTP id 2C1243A6A7F for <tcpm@ietf.org>; Mon, 28 Jun 2010 09:40:39 -0700 (PDT)
Received: from [75.212.154.146] (146.sub-75-212-154.myvzw.com [75.212.154.146]) (authenticated bits=0) by vapor.isi.edu (8.13.8/8.13.8) with ESMTP id o5SGSsDh012682 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 28 Jun 2010 09:29:07 -0700 (PDT)
Message-ID: <4C28CDC6.4020907@isi.edu>
Date: Mon, 28 Jun 2010 09:28:54 -0700
From: Joe Touch <touch@isi.edu>
User-Agent: Thunderbird 2.0.0.24 (Windows/20100228)
MIME-Version: 1.0
To: L.Wood@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> <A3A73BD7-045B-4C56-ACCF-7D996D110BA5@surrey.ac.uk>
In-Reply-To: <A3A73BD7-045B-4C56-ACCF-7D996D110BA5@surrey.ac.uk>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="------------enigC8ED7236631A2A8E1BFABC87"
X-ISI-4-43-8-MailScanner: Found to be clean
X-MailScanner-From: touch@isi.edu
Cc: tcpm@ietf.org, ananth@cisco.com, Anumita.Biswas@netapp.com
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 16:40:41 -0000


L.Wood@surrey.ac.uk wrote:
> 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

This RFC defines TCP and UDP echo services. Both loop data back to the source,
but at "layer 7" to the transport protocols. Both create new transport packets
to send data back - in fact, the TCP variant might have different segment
boundaries, e.g., if the return path MTU is different. Both thus compute a new
transport checksum, so errors in either would not be detected by a stronger
transport checksum per se.

> http://www.faqs.org/rfcs/rfc2075.html
> 
> which swaps source and destination addresses. These are covered by the pseudo-header
> check; 
...
> A stronger TCP checksum would detect this modification, and have to be
> recomputed. much as payload checksums are recomputed through NAT boxes.

The pseudoheader is not covered by the current proposal, specifically to support
NAT traversal. Any device that recomputes the checksum on traversal (explicitly,
or because that calculation is buried in the NIC and done automatically) will
defeat the ability of the checksum to detect errors inside that node.

The only L7-L7 protection would be a full transfer checksum, which is not being
proposed.

Joe