Re: Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?
Yanping Du <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?
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. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?
On 10/16/07, Yanping Du <[EMAIL PROTECTED]> 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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Will RFC1146 (tcp alternative checksum options) be implemented in Linux tcp stack ?
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 - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
