Subject: [Ipsec] IPsec performance drafts

From: Tero Kivinen <[email-masked]>
Date: Wed, 22 Mar 2006 03:33:38 +0200

Merike asked me to forward this email to ipsec-list:
----------------------------------------------------------------------
From: Merike Kaeo <[email-masked]>
Subject: IPsec performance drafts
Date: Tue, 21 Mar 2006 10:50:55 -0800

I've co-authored two documents relating to IPsec performance testing
and as they're now fairly complete I'd like to solicit review and
comments from the IPsec group.  It would be great if people could send
public comments to the bmwg wg ([email-masked]) but if people just want
to send comments to the authors that's ok too [we'll summarize to
bmwg].  Note that only IKEv1 is covered for now - the intent is to
publish what's done and work on an IKEv2 doc in a separate document.

The docs are:
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipsec-term-08.txt
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-ipsec-meth-01.txt

Thanks!

- merike

_______________________________________________
Ipsec mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipsec

---

From: "Stephane Beaulieu \(stephane\)" <[email-masked]>
Date: Wed, 22 Mar 2006 09:22:10 -0500

Is the goal of this draft to have an RFC that different vendors/testing
firms can use to compare one product to another?

Section 6.6.4
- Where's DH 5?

Section 7.1
- If the goal is to measure 'sustained' sessions, why not send constant
traffic through all established tunnels while initiating new tunnels,
rather than just 50 packets.  You should also specify the type and
perhaps size of packets here also.  You'd also need to specify psk vs.
RSA, DH group, PFS, cipher algs, etc...

Section 7.2
- How is 7.2 different than 7.1 test?

Section 11.5
- P2 rekey frame loss?  You aren't supposed to drop any packets during a
P2 rekey, so why would you measure this?

Section 13.1
- It looks like you're trying to serialize session establishment (i.e.
wait until the first is complete before you start the 2nd one).  This
really isn't real world.  If you want to set up 1 P1 with 100 P2's, you
should be able to send 100 pkts as fast as you can and the DUT should
then establish 100 P2's as fast as it can.

Also, n should be the maximum number that the DUT supports.  We've seen
test results where the setup rate is x for the first 100 tunnels, but
x/2 for the last 100 tunnels, when the tunnel counts get in the high
1000's.  In our own internal testing, we don't even start counting the
t.p.s. until we get to half of full capacity.  This is more real-world.

It's also unclear to me here if we're testing P1 or P2 or both.  If we
say n=100, does that mean a single P1 SA, and 100 P2 Sas?  Or 100 P1's
and 100 P2's?  Also, do we need to test with or without PFS?

Section 13.2
Again, this test serializes the session establishements which IMO is not
a valid test.  A better test is to send a single packet on each stream
at an interval of x pps until you reach your max sessions.  Where x is
the t.p.s. that you're testing.  If you reach max without any failures,
then your tunnel setup rate is x.  Try again with x+1.  The highest x
you achieve is your t.p.s.  Again, remember that you must be able to
maintain x t.p.s. even when the box is under heavy load, not just the
first 100 tunnels.

Section 13.3
- same comments as 13.1

Stephane. 

> -----Original Message-----
> From: Tero Kivinen [mailto:[email-masked]] 
> Sent: Tuesday, March 21, 2006 8:34 PM
> To: [email-masked]
> Cc: Michele Bustos; Tim Van Herck (herckt); Merike Kaeo
> Subject: [Ipsec] IPsec performance drafts
> 
> I've co-authored two documents relating to IPsec performance 
> testing and as they're now fairly complete I'd like to 
> solicit review and comments from the IPsec group.  It would 
> be great if people could send public comments to the bmwg wg 
> ([email-masked]) but if people just want to send comments to 
> the authors that's ok too [we'll summarize to bmwg].  Note 
> that only IKEv1 is covered for now - the intent is to publish 
> what's done and work on an IKEv2 doc in a separate document.
> 
> The docs are: