Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?

Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?

[Yanping Du]

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 ?

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



       
____________________________________________________________________________________
Building a website is a piece of cake. Yahoo! Small Business gives you all the tools to get online.
http://smallbusiness.yahoo.com/webhosting 

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

[Ian McDonald]

On 10/16/07, Yanping Du <ypdu2001@yahoo.com> 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 ?
>
> 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
>
>
Yanping,

The way that features get added to Linux is that someone interested
writes it. You can't just say - is this on the roadmap, as there is no
roadmap really!

I have been interested in network features from an academic point of
view and so I wrote what I needed (along with others) and that was
added to the Linux kernel.

So have a go at implementing it if you consider it important and come
back here with some patches. Then others will help review it until the
patches are good.

I will let others comment on whether the checksums are a good idea or not.

Ian
-- 
Web1: http://wand.net.nz/~iam4/
Web2: http://www.jandi.co.nz
Blog: http://iansblog.jandi.co.nz

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

[Stephen Hemminger]

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

You would of course lose all the hardware offload of checksumming since
no hardware supports alternative checksums.

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

[Matti Aarnio]

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

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

[Andi Kleen]

Yanping Du <ypdu2001@yahoo.com> writes:

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

The standard way to solve this problem is to either use
SSL or IPSec.  They both use very strong checksums
and are widely supported unlike this obscure old RFC.

-Andi