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

Joe Touch <> Thu, 10 June 2010 00:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D33633A69AC for <>; Wed, 9 Jun 2010 17:46:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[BAYES_50=0.001]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id rcAc7WqCkLZN for <>; Wed, 9 Jun 2010 17:46:54 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id E5D8C3A6857 for <>; Wed, 9 Jun 2010 17:46:53 -0700 (PDT)
Received: from [] ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id o5A0jdOf014359 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 9 Jun 2010 17:45:49 -0700 (PDT)
Message-ID: <>
Date: Wed, 09 Jun 2010 17:45:38 -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="------------enig3C6B786E66637220B19FA221"
X-MailScanner-ID: o5A0jdOf014359
X-ISI-4-69-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 00:46:54 -0000

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

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.