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

Joe Touch <> Thu, 10 June 2010 13:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1ED933A6A24 for <>; Thu, 10 Jun 2010 06:55:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.299
X-Spam-Status: No, score=-1.299 tagged_above=-999 required=5 tests=[AWL=1.300, BAYES_00=-2.599]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8oYd-GnXdWqV for <>; Thu, 10 Jun 2010 06:55:21 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 46DCA3A6A21 for <>; Thu, 10 Jun 2010 06:55:21 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o5ADraXD023142 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 10 Jun 2010 06:53:46 -0700 (PDT)
Message-ID: <>
Date: Thu, 10 Jun 2010 06:53:36 -0700
From: Joe Touch <>
User-Agent: Thunderbird (Windows/20100228)
MIME-Version: 1.0
To: "Scheffenegger, Richard" <>
References: <><> <20100609173556.GA5338@nuttenaction> <><> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 0.96.0
Content-Type: multipart/signed; micalg="pgp-sha1"; protocol="application/pgp-signature"; boundary="------------enig132704103174654E8F49576C"
X-ISI-4-43-8-MailScanner: Found to be clean
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 13:55:22 -0000

Hi, Richard,

Scheffenegger, Richard wrote:
> 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
> resent...

Yes - TLS operates at the application layer, not in conjunction with TCP.

> 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
> then.

Defined therein where? The alternate checksum isn't TLS; TLS is an
application-layer security protocol.

> 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... 

RFC1146 defines a handshake behavior, during which only a short label is
exchanged and confirmed, and the conventional TCP checksum is used. This is more
appropriate for TCP; options in the SYN should not render the rest of the SYN
unintelligible to parties that don't support the option.

As to retry with or without options, that is not typically defined at the level
of a TCP option. That too is application behavior - i.e., to try to open a TCP
connection with certain parameters, and to try a different attempt if the first
fails. Having an option redefine core TCP protocol behavior (such as timeouts,
retries, etc.) seems more than just an option. Options should extend, not
redefine, that core behavior.

> 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.

Yes. But that's what you've described above when the TCP handshake fails - i.e.,
that's no different. It's worth thinking further about that, as a result.