Re: [tcpm] draft-anumita-tcpm-stronger-checksum

"Scheffenegger, Richard" <> Thu, 10 June 2010 09:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A262D3A6939 for <>; Thu, 10 Jun 2010 02:53:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.742
X-Spam-Status: No, score=-4.742 tagged_above=-999 required=5 tests=[AWL=-0.557, BAYES_40=-0.185, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8YyB9tLip6m3 for <>; Thu, 10 Jun 2010 02:53:46 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 4C6B83A69FB for <>; Thu, 10 Jun 2010 02:53:46 -0700 (PDT)
X-IronPort-AV: E=Sophos;i="4.53,397,1272870000"; d="scan'208";a="160467484"
Received: from ([]) by with ESMTP; 10 Jun 2010 02:53:42 -0700
Received: from ( []) by (8.13.1/8.13.1/NTAP-1.6) with ESMTP id o5A9q90R029976; Thu, 10 Jun 2010 02:53:06 -0700 (PDT)
Received: from ([]) by with Microsoft SMTPSVC(6.0.3790.3959); Thu, 10 Jun 2010 10:52:28 +0100
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 10 Jun 2010 10:52:27 +0100
Message-ID: <>
In-Reply-To: <>
Thread-Topic: [tcpm] draft-anumita-tcpm-stronger-checksum
Thread-Index: AcsINqcWi7HEDNWTRp+2J6IlXJSSAwASjW+A
References: <><> <20100609173556.GA5338@nuttenaction> <><> <> <> <>
From: "Scheffenegger, Richard" <>
To: Joe Touch <>
X-OriginalArrivalTime: 10 Jun 2010 09:52:28.0533 (UTC) FILETIME=[A319AA50:01CB0882]
Cc:, "Anantha Ramaiah (ananth)" <>
Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: TCP Maintenance and Minor Extensions Working Group <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Jun 2010 09:53:47 -0000

Hi Joe,

I think you mentioned that a checksum violation in TLS will cause the
connection to be aborted - rather than the corrupted packet to be

If keeping the standard TCP CRC intact (and covering TCP header & data)
and having an RFC1146 alternate checksum that works differently than
defined therein, perhaps it would be better to make it a new TCP option

During handshake, the CRC-32C capable sender would need to do the proper
think (retry one or two times with all options, and then retry with the
minimum options); For agnostic middleboxes (and NAT/PAT routers
currently deployed), not covering the pseudo-header seems to me to be
the only option, to make this feature work with existing gear... 

Again, if the group feels that this is better not called "Alternative
Checksum" (re-using preexisting TCP options), but rather "TCP Stronger
Data Checksum", that's fine :).

The key is to keep the TCP state and retransmission behaviour intact, as
re-negotiating a new, TLS-protected TCP stream after corruption might
not be good enough these days (too high latency impact). 

As there exist HW that implements SCTP checksum offloading (as well as
segmentation) nowadays, new appliactions could probably make use of
that. However, applications would have to revert back to TCP (with small
segments), if the other side wouldn't support SCTP.

Richard Scheffenegger

> -----Original Message-----
> From: Joe Touch [] 
> Sent: Donnerstag, 10. Juni 2010 02:46
> To: Scheffenegger, Richard
> Cc: Lars Eggert;; Anantha Ramaiah (ananth)
> Subject: Re: [tcpm] draft-anumita-tcpm-stronger-checksum
> Some notes below...
> Scheffenegger, Richard wrote:
> > To further this discussion:
> > 
> > I believe the suggestion using Alternate Checksum Option has the 
> > highest
> > merits:
> > 
> > O) no new tcp option number would be needed
> > O) only an additional checksum option type would need to be defined 
> > (and there are still plenty left; I found no evidence so 
> far, that any 
> > other value than 0 and 1 were ever used - scanning though 
> the I-D archives).
> > 
> > To make this proposal compatible with existing middleboxes, which 
> > might not understand the option, but choose to simply 
> forward it, my 
> > suggestion would be to *NOT* include the TCP pseudo-header in that 
> > alternate checksum, but *only* cover the data section. This 
> would make 
> > it also possible to traverse NAT/PAT gateways, which are 
> agnostic to 
> > this option.
> Middleboxes will be a problem no matter what you do.
> Some will drop the segment simply because it has an option 
> they don't understand.
> Some will drop the option, which will result in drops at the receiver.
> Many (most) will try to validate the TCP checksum, which is 
> zero or contains part of the alternate checksum when the 
> alternate checksum is present, so they'll drop the segment in 
> that case.
> As a result, it's not particularly useful to tailor this 
> option to work through middleboxes.
> Further, RFC 1146 defines the option to work over the same 
> fields as the TCP checksum; I don't think it would be 
> appropriate to use that option with merely a different 
> algorithm and redefine the bits covered.
> Finally, if the TCP header isn't protected, it's no longer a 
> TCP checksum - it's a data checksum, at which point TLS is 
> probably more appropriate.
> I don't think the other suggestions (two checksums, issues of 
> how many bits are covered, etc.) are important. If the above 
> doesn't work, the rest is moot anyway.
> Joe