IETF Logo Mail Archive

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

Joe Touch <touch@isi.edu> Sat, 26 June 2010 19:26 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 7E2333A697F for <tcpm@core3.amsl.com>; Sat, 26 Jun 2010 12:26:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.228
X-Spam-Level:
X-Spam-Status: No, score=-2.228 tagged_above=-999 required=5 tests=[AWL=0.371, 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 Nvn8QKcVKnpe for <tcpm@core3.amsl.com>; Sat, 26 Jun 2010 12:26:37 -0700 (PDT)
Received: from nitro.isi.edu (nitro.isi.edu [128.9.208.207]) by core3.amsl.com (Postfix) with ESMTP id 9E6673A6961 for <tcpm@ietf.org>; Sat, 26 Jun 2010 12:26:37 -0700 (PDT)
Received: from [192.168.1.92] (pool-71-106-88-10.lsanca.dsl-w.verizon.net [71.106.88.10]) (authenticated bits=0) by nitro.isi.edu (8.13.8/8.13.8) with ESMTP id o5QJPfFS003346 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Sat, 26 Jun 2010 12:25:51 -0700 (PDT)
Message-ID: <4C265435.3010601@isi.edu>
Date: Sat, 26 Jun 2010 12:25:41 -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>
In-Reply-To: <AE08BDBD-CD39-4BE0-9E93-DA669C67BE0D@surrey.ac.uk>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig58030F2DC12F95C3CAED116E"
X-MailScanner-ID: o5QJPfFS003346
X-ISI-4-69-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: Sat, 26 Jun 2010 19:26:38 -0000


L.Wood@surrey.ac.uk wrote:
>> The do not seek, nor did they find in the wild, a single packet where the CRC
>> was valid and the TCP checksum was valid, but the packet had changed in
>> contents.
> 
> Before going any further - did you really mean to write that?

Yes. FWIW, the CRC I'm referring to above is the link CRC (CRC32 for Ethernet).

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.

Please see draft-ietf-tcpm-anumita-tcp-stronger-checksum-00, e.g., in the
abstract, or Sec 1. In fact, the case they're considering is where real link
errors occur that are not detectable - not TCP/IP implementation errors or
router memory errors, as were the only ones seen in the wild in the Sigcomm paper.

Joe

v2.23.0 | Report a Bug | By Email