[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: IPSec still too slow?


Again, is it IPsec or IPSec? remember it should be IPsec?...


-----Original Message-----
From: Steven M. Bellovin [mailto:smb@research.att.com]
Sent: Saturday, October 06, 2001 7:17 AM
To: Alex Alten
Cc: Joel M Snyder; ipsec@lists.tislabs.com
Subject: Re: IPSec still too slow? 


In message <3.0.3.32.20011005212527.00e7b4e8@mail>, Alex Alten writes:
>
>Joel are you willing to post all the raw test results to the IPSEC
>mailing list?  It's really hard to understand what the numbers really
>mean in your article.  I for one wouldn't mind if you change
vendor/product
>names to something like vendor A/product X (although some indication of
>processor speed would help here).
>
>What I'm looking for is raw throughput (various packet sizes), latency
(SA 
>setup costs), error rates (%dropped packets, lost fragments), timing
delays.
>
>BTW, did you test with various legacy protocol/apps?  For example did
anything
>break if they didn't get the expected TCP segement handed to them in
the app
>layer?


Since TCP always hands a simple stream to upper layers -- error or 
missing packets retransmitted -- and this happens above IPsec (and 
regardless of its presence), any flaw there would be indicative of a 
bug in TCP, and would have nothing to do with IPsec.

As for the question of performance -- from Joel's article, it sounds 
like that hardware-based implemeentation doesn't have a large enough 
cache of security associations.  This isn't a surprising result for a 
low-end hardware implementation.  A lot may depend on the test setup.  
For some comparatively casual measurements of the requirements for 
cache size, see http://www.research.att.com/~smb/talks/key-agility.ps
(or http://www.research.att.com/~smb/talks/key-agility.pdf).  Also see 
a text version of the analysis at
http://www.research.att.com/~smb/talks/key-agility.email.txt,
which was posted to the IPsec mailing list several years ago.  Although 
I was mostly concerned with the cache size requirements for the 
encryption engine, the measurements would apply equally well to any 
other per-SA data.

		--Steve Bellovin, http://www.research.att.com/~smb
		Full text of "Firewalls" book now at
http://www.wilyhacker.com