Subject: [bmwg] Terminology for Benchmarking IPSec Devices Work Proposal

From: Michele Bustos <[email-masked]>
Date: Wed, 15 Jan 2003 16:42:47 -0800

BMWG New Work Proposal 

We are proposing that the BMWG accept the following workplan proposal.

This email is a brief abstract which reflects rationale, scope of work, and
insight as to why the authors conclude that Terminology for Benchmarking
IPSec Devices is a relevant topic for the BMWG.

The following are the authors for this document:

Michele Bustos, Ixia

Tim Van Herck, Cisco Systems

Merike Kaeo, Merike, Inc.

Sunil Kalidindi, Ixia

Despite the increased requirement for secure network communications over a
public medium and the rapid rise in IPSec device deployment, no standard
methodology exists to obtain direct performance measurements or comparisons
for these devices. Furthermore, there is no standardized terminology for
these essential benchmarks, and the various interpretations of a term as
widely used as the word "tunnel", for example, make it near impossible to
derive meaningful comparisons of device performance. These factors hinder
the development of hardware/software solutions and results in varied
implementations which challenge interoperability. As more IPSec devices are
deployed and expected to perform at relatively high speed, users currently
have no method to determine which product will endure today's heavy IPSec
traffic loads. Standardized IPSec terminology and performance test
methodologies will enable users to decide if the IPSec device they select
will withstand relatively heavy loads of secured traffic.

****************************************************************************
**********

The proposed scope for this document is as follows:

The primary focus of this document is to enable useful performance testing
terminology for IPSec VPN devices. As such we want to constrain the
terminology specified in this document to meet the requirements of the
testing methodology. The testing will be constrained to devices acting as
IPSec VPN gateways and will therefore mostly pertain to IPSec tunnel mode
although IPSec transport mode tests will be defined for some cases. 

At this time, any testing that pertains to IPv6 is out of scope, however,it
is expected that future subsequent work will specify IPv6 and IPSec
performance test methodologies. Also it is out of scope to deal with
anything that does not specifically relate to the establishment and tearing
down of IPSec tunnels. It is assumed that all relevant networking parameters
that facilitate in the running of these tests are pre-configured (this
includes at a minimum ARP caches and routing tables).

L2TP, GRE, and 2547 (MPLS VPN) are excluded from this document.

****************************************************************************
**********

Here is the proposed TOC for the Terminology Document (only the main
sections comprising of the term definitions and test terminology are listed
here):

	Table of Contents

	5. Term Definitions 10

	5.1. IPSec Device 10

	5.2. IPSec 10

	5.3. ISAKMP 10

	5.4. IKE 10

	5.5. IKEv2 10

	5.6. Initiator 11

	5.7. Responder 11

	5.8. Security Association (SA) 11

	5.9. IKE SA / IKE Tunnel 11

	5.10. Phase 1 Main Mode 11

	5.11. Phase 1 Aggressive Mode 11

	5.12. Phase 1 NAT Traversal 11

	5.13. IPSec SA / IPSec Tunnel 12

	5.14. Phase 2 Quick Mode 12

	5.15. Nested Tunnels 12

	5.16. Transport Adjacency 13

	5.17. Transform Protocols 13

	5.18. Selectors 13

	5.19. IPSec Protocols 14

	5.19.1. Authentication Header (AH) 14

	5.19.2. Encapsulated Security Payload (ESP) 15

	5.20. Authentication protocols 15

	5.20.1. MD5-HMAC 15

	5.20.2. SHA-HMAC 15

	5.20.3. AES-HMAC 15

	5.21. Encryption protocols 15

	5.21.1. NULL encryption 16

	5.21.2. DES-CBC 16

	5.21.3. 3DES-CBC 16

	5.21.4. AES-CBC 16

	5.22. Security Context 16

	6. Test Terminology 17

	6.1. Framesize 17

	6.1.1. Layer3 clear framesize 17

	6.1.2. Layer3 encrypted framesize 18

	6.1.3. Layer2 clear framesize 18

	6.1.4. Layer2 encrypted framesize 19

	6.2. Internet Mix Traffic (IMIX) 19

	6.3. Throughput 20

	6.3.1. IPSec Tunnel Throughput 20

	6.3.2. Encryption / Decryption Throughput 20

	6.4. Latency 20

	6.4.1. IPSec Tunnel Latency 20

	6.4.2. Time To First Packet 20

	6.4.3. Encryption / Decryption Latency 20

	6.5. Frame Loss Rate 21

	6.5.1. IPSec Tunnel Frame Loss Rate 21

	6.5.2. Encryption / Decryption Frame Loss Rate 21

	6.6. Back 2 Back 21

	6.6.1. IPSec Back 2 Back Frames 21

	6.6.2. Encryption / Decryption Back 2 Back Frames 21

	6.7. Tunnel Setup Rate Behavior 21

	6.7.1. Tunnel Setup Rate 21

	6.7.2. Phase 1 Setup Rate 22

	6.7.3. Phase 2 Setup Rate 22

	6.7.4. Rekey Behavior 22

	6.7.5. Failover Behavior 22

	6.7.6. IKE DOS Resilience Behavior 22

	6.8. Tunnel Flapping 22

	Please send all comments to the Benchmark Working Group Mailing List
[email-masked] <mailto:[email-masked]> 

Kind Regards, 

Michele Bustos 
(818) 444-3244 

IXIA 
26601 West Agoura Road 
Calabasas CA 91302 
Tel: 818 871 1800 (US) 
+1 818 871 1800 (international) 

[email-masked] 
http://www.ixiacom.com <http://www.ixiacom.com>  

"Because Performance Counts"

---

From: Russ White <[email-masked]>
Date: Thu, 16 Jan 2003 12:32:45 -0500 (EST)

I think it's valuable work, and we shoudl accept it.

:-)

Russ

> will withstand relatively heavy loads of secured traffic.

__________________________________
[email-masked] CCIE <>< Grace Alone

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

---

From: Russ White <[email-masked]>
Date: Thu, 16 Jan 2003 12:32:45 -0500 (EST)

:-)

Russ

---

From: "tmartin" <[email-masked]>
Date: Fri, 17 Jan 2003 14:49:09 -0800

I agree also 

It looks like it could bring some value

Terry Martin
GVNW Consulting INC
[email-masked]
503-612-4400

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Russ
White
Sent: Thursday, January 16, 2003 9:33 AM
To: Michele Bustos
Cc: [email-masked]'
Subject: Re: [bmwg] Terminology for Benchmarking IPSec Devices Work
Proposal

:-)

Russ

> will withstand relatively heavy loads of secured traffic.
************************************************************************
****
************************************************************************
****

---

From: "tmartin" <[email-masked]>
Date: Fri, 17 Jan 2003 14:49:09 -0800

I agree also 

Terry Martin
GVNW Consulting INC
[email-masked]
503-612-4400

-----Original Message-----

:-)

Russ