Fast MAC algorithms?

[james hughes]

On Jul 24, 2009, at 1:30 PM, Peter Gutmann wrote:

> [I realise this isn't crypto, but it's arguably security-relevant  
> and arguably
> interesting :-)].

As long as we think this is interesting, (although I respectfully  
disagree that there are any inherent security problems with TOE. Maybe  
there are insecure implementation...).

> James Hughes <hughejp at mac.com> writes:
>
>> TOEs that are implemented in a slow processor in a NIC card have  
>> been shown
>> many times to be ineffective compared to keeping TCP in the fastest  
>> CPU
>> (where it is now).
>
> The problem with statements like this is that they smack of the Linux
> religious zealotry against TCP offload support in the kernel, "TOE's  
> are bad
> because we say they are, and we'll keep asserting this until you go  
> away".

There were a dozen or so protocol offload research projects that the  
US government funded in the 90s. All failed. Is the people who say  
"TOE's are bad"  because of zealotry or standing on the shoulders of  
the people that ran those projects. At Network Systems, we partnered  
with HT Kung of CMU at the time to move TCP out of a really slow  
Decstation. Result? A accelerator that cost as much as the workstation  
that was faster until the next processor version was available. Yes,  
we could have reduced it to a chip but it wasn't. The take away was  
that improving the software is the gift that keeps on giving. Moore's  
law means you get a faster TCP every time the clock ticks.
	http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.41.1138

BTW, I am not a Linux bigot, just someone that got caught up in this  
issue more than a decade ago. I do not agree with your assertion or  
the Wikipedia page that this is linux bigotry. I find that page  
horribly inaccurate and self serving to the TOE manufacturing community.

What I learned from participating in a project that spent $5M of tax  
payer money was that "The protocol itself is a small fraction of the  
problem".

> A
> decade ago, during the Win2K development, Microsoft were measuring a  
> 1/3
> reduction in CPU usage just from TCP checksum offload.  Given the  
> time frame
> this was probably on 300MHz PII's, but then again it'd be with  
> late-90s
> vintage NICs.  On the other hand I've seen even more impressive  
> figures with
> their more recent TCP chimney offload (which just moves more of the  
> NDIS stack
> onto the NIC, I think it came out around Server 2003).
>
> Does this mean that MS have figured out (a decade or so ago) how to  
> make TOE
> work while the OSS community has been too occupied telling everyone  
> it doesn't
> to do anything about it?  There must be some reason for the  
> difference between
> the two camps.

Offloading features like checksumming, fragmentation/reassembly (aka  
Large Segment Offload), packet categorization, slitting flows to  
different threads, etc. is not TOE.

TOE is offloading of the TCP stack. The thin line that is crossed is  
"where is the TCP state kept". If the state is kept in the card, then  
the protocol to get the data reliably to the application is has more  
corner cases (hence complexity) since the IP layer can be lossy and  
the socket layer can not. In all the research, this has always been  
the case.

If there is something windows has not learned could be that processing  
TCP should be simple and quick. Since the source code is not  
available, I don't know if their software falls into the "too  
complicated" camp or not... In the case of Chimney partial stack  
offload, the state is in both places. Sounds simple straight forward,  
right?

The case of iSCSI where a complete protocol conversion is done (the  
card looks like a SCSI card, but the data goes out over TCP/IP) it is  
a different story (which is also arguably still about solving the OS  
vendor's lack of software agility with hardware), but that is not the  
intent of this discussion.

I fully agree that offloading features that makes the TCP processing  
easier is a good thing.

Back to crypto?

> Peter.

Jim

---------------------------------------------------------------------
The Cryptography Mailing List
Unsubscribe by sending "unsubscribe cryptography" to majordomo at metzdowd.com