netdev - Re: Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20071016102851.GZ6372@mea-ext.zmailer.org>
Date:	Tue, 16 Oct 2007 13:28:51 +0300
From:	Matti Aarnio <matti.aarnio@...iler.org>
To:	Yanping Du <ypdu2001@...oo.com>
Cc:	netdev@...r.kernel.org
Subject: Re: Will RFC1146 (tcp alternative checksum options) be implemented
	in Linux tcp stack ?

On Mon, Oct 15, 2007 at 06:15:11PM -0700, Yanping Du wrote:
> Hi,
> 
>   We found the standard 16-bit tcp checksum is not
> strong enough in some cases. Is there any roadmap on
> implementing RFC1146 (tcp alternative checksum
> options) in Linux tcp stack ? If yes, how soon will
> that be in ?

If you want to pay to somebody to implement it, possibly soon.
Otherwise it is up to whims of capable kernel coders, who
usually have their hands quite full.

The tcp alternate checksum option does have severe performance
hinderance issue.  It may be implemented by intermingling it
into standard tcp_checksum_and_copy routine, but in cases
where the hardware can do tcp checksum offloading, it definitely
does not improve the performance.

Your alternate approach could be to use a IPSEC VPN tunnel,
which will detect an attempt to alter data ( = transmission
error ) even when the original TCP does not detect anything.

Yet third way could be to do it in application: ssh datastream
as one example - or tunnel via SSH port forward.

Need for alternate checksums does appear to indicate that you
are using bad quality transmission system -- those are not
usually very high speed things, and then hacks like IPSEC or
SSH tunnels are excellent choices.

Nevertheless, adding checksum complexity/size on each packet
does not guarantee error detection, it merely lowers the
probability of error detection failure.  There _will_ happen
an error which wasn't detected, but will it be once a minute
or once a year, or once per billion years..

Bad quality ( = error introducing ) transmission system will
also make speedy data transmission that much more difficult,
thus my presumption that it isn't very fast link...

Anyway, we have seen data corruption on disk, over the network
etc.  Having application level MD5 checksumming of the datastream
every N kilobytes has its own attractions.  Including embedding
those checksums in the stored datastreams.

> Please kindly copy reply to my email address as I've
> not subscribed the netdev@ mailing list at present.
> 
>   http://www.faqs.org/rfcs/rfc1146.html
> 
> Thanks!
> -Yanping

/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html