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

Re: IPSec still too slow?

Steve is correct on the TCP issue.  One additional minor issue to TCP&IPSec is
the connection set-up delay/retransmission related to SA negotiation.

As for degradation seen with increased number of SAs, I can think of a few possible
explanations...
1. granularity of resource locks on SADB or similar data structs
2. SADB (input and output) management scheme
3. timer system issues
4. size of hardware context memory on the crypto board itself
5. size of `hardware session' memory on the host

#4/#5 above may be the cache issue that Steve referred to.

--Wei Jen

"Steven M. Bellovin" wrote:
> 
> 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

-- 
Wei-Jen Yeh
weijyeh@nortelnetworks.com	Nortel, RTP, NC
Office Phone: (919) 991-2707,	ESN: 35-12707
Fax: (919) 991-8073
References: