[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: IPSEC stress tester?
The tests outlined below I would consider IPSEC compliance tests. I believe
that the Anvil product from Midnight Networks now supports these type of
tests. However, the original question appeared to address performance
metrics for various IPSEC solutions. I agree with Paul that these tests fall
into two main categories, throughput and SAs. Throughput testing is pretty
straight forward. All you need is something to generate traffic (i.e.
SmartBits) at various packet sizes and rates through an SA. The results will
tell you both packet forwarding and bulk encryption limitations.
The max SA test is the tricky one. I am familiar with some larger vendors
that have built rooms with over a hundred PCs each running scripts to
establish 10 to 20 SAs. This is not practical for most organizations.
Therefore, I am forced to take the word of the vendor that a particular box
can handle X number of simultaneous SAs. This is becoming an increasingly
critical issue as service providers look for solutions to support 10s of
thousands of simultaneous encrypted connections. There must be someone out
there who has come up with a reasonably elegant solution to this problem.
Jason Devine, jdevine@technicacorp.com
Manager, Information Systems
Technica Corporation, www.technicacorp.com
> -----Original Message-----
> From: Waters, Stephen [mailto:Stephen.Waters@cabletron.com]
> Sent: Thursday, February 25, 1999 6:43 PM
> To: 'Paul Hoffman'
> Cc: 'ipsec@tis.com'
> Subject: RE: IPSEC stress tester?
>
>
>
> Thanks for all the replies. I guess what I'm looking for is a
> test suite
> that has knowledge of the IPSEC/IKE protocols and tries to expose
> weaknesses.
>
> Some simple examples could be:
>
> - sending ESP/AH packets to various SPI values
> - creating IPSEC-SA with IKE, and then sending corrupted ESP/AH packet
> (man-in-the-middle tests)
> - replay attacks
> - pre-shared key guessing for Phase1 break-in attempts
> - sending in ESP packets that contain IP packets not covered
> by the Phase-2
> negotiation
> - 'exploding' IPCOMP packets
>
> We could probably come up with a fairly long list between us.
> I would like
> to see such a tool so that VPN CPE customers can sleep at
> nights knowing
> their CPE has passed these tests.
>
> So far, I've tried tools intended for firewall testing, and,
> as you would
> expect, they
> don't do much with a router that is armed with IPSEC.
>
> This sounds like an opportunity for someone. From the number
> of holes I've
> had to fix in our IPSEC implementation, this someone probably
> works for a
> company with IPSEC products.
> Steve.
>
>
>
> -----Original Message-----
> From: Paul Hoffman [mailto:paul.hoffman@vpnc.org]
> Sent: Thursday, February 25, 1999 9:41 PM
> To: Waters, Stephen; 'ipsec@tis.com'
> Subject: Re: IPSEC stress tester?
>
>
>
> >I'm looking for a test suite that will stress-test an IPSEC security
> >gateway.
> >Can anyone recommend something? If the product doesn't exist, maybe a
> >service does? I would prefer a product that I can re-use at
> my leisure as
> >part of a regression test program.
>
> Depends on what you mean by "stress test". There are at least two
> orthogonal types of stress tests people have proposed: speed and
> number/type of SAs. Creating software/hardware to test either type of
> stress is easy; creating tests that are useful in the real world is
> probably difficult without discussion from many vendors and customers.
>
> A few companies have suggested that VPNC create some standard
> stress-testing regimen, not so that someone can say "Product
> A runs faster
> under stress than Product B", but so they ca say "if you put
> Product C on
> one end of an Internet connection with a line speed of N, you
> can be sure
> that the line speed will limit you sooner than the processing
> power of
> Product C". Once VPNC gets up and running, I hope that the
> members will
> want to discuss this more, and that we make the results
> public so that
> anyone can run the tests themselves.
>
> --Paul Hoffman, Director
> --VPN Consortium
>
Follow-Ups: