draft-ietf-bmwg-ipsec-term-09.txt   draft-ietf-bmwg-ipsec-term-10.txt 
Benchmarking Working Group M. Kaeo Benchmarking Working Group M. Kaeo
Internet-Draft Double Shot Security Internet-Draft Double Shot Security
Expires: January 9, 2008 T. Van Herck Expires: September 2, 2008 T. Van Herck
Cisco Systems Cisco Systems
M. Bustos M. Bustos
IXIA IXIA
July 8, 2007
Terminology for Benchmarking IPsec Devices Terminology for Benchmarking IPsec Devices
draft-ietf-bmwg-ipsec-term-09 draft-ietf-bmwg-ipsec-term-10
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 9, 2008. This Internet-Draft will expire on September 2, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This purpose of this document is to define terminology specific to This purpose of this document is to define terminology specific to
measuring the performance of IPsec devices. It builds upon the measuring the performance of IPsec devices. It builds upon the
tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF
Benchmarking Methodology Working Group (BMWG) documents used for Benchmarking Methodology Working Group (BMWG) documents used for
benchmarking routers and switches. This document seeks to extend benchmarking routers and switches. This document seeks to extend
these efforts specific to the IPsec paradigm. The BMWG produces two these efforts specific to the IPsec paradigm. The BMWG produces two
major classes of documents: Benchmarking Terminology documents and major classes of documents: Benchmarking Terminology documents and
Benchmarking Methodology documents. The Terminology documents Benchmarking Methodology documents. The Terminology documents
present the benchmarks and other related terms. The Methodology present the benchmarks and other related terms. The Methodology
documents define the procedures required to collect the benchmarks documents define the procedures required to collect the benchmarks
cited in the corresponding Terminology documents. cited in the corresponding Terminology documents.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 4
3. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 6 3. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 4
3.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 7 3.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6
3.1.1. Security Associations . . . . . . . . . . . . . . . . 7 3.1.1. Security Associations . . . . . . . . . . . . . . . . 6
3.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 8 3.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 7
4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 10 4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 9
5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 10 5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 9
6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 11 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 9
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 13 7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 12
7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 13 7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 12
7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 13 7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 12
7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 14 7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 13
7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 14 7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 13
7.4. Security Association (SA) . . . . . . . . . . . . . . . . 15 7.4. Security Association (SA) . . . . . . . . . . . . . . . . 14
7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 14
7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 15 7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 14
7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 16 7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 15
7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 17 7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 16
7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 17 7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 16
7.6.4. IPsec Server . . . . . . . . . . . . . . . . . . . . . 17 7.6.4. IPsec Server . . . . . . . . . . . . . . . . . . . . . 16
7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 18 7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 17
7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 18 7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 17
7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 18 7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 17
7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 19 7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 18
7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 19 7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 18
7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 20 7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 19
7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 20 7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 19
7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 21 7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 20
7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 21 7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 20
7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 22 7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 21
7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 22 7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 21
7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 23 7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 22
7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 23 7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 22
7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 24 7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 23
7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 25 7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 24
7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 25 7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 24
7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 26 7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 25
8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 27
8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 28 8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 27
8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 29 8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 28
9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 30 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 29
9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 30 9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 29
9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 30 9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 29
9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 31 9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 29
10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 31 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 30
10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 30
10.1.1. IKE SA Capacity . . . . . . . . . . . . . . . . . . . 31 10.1.1. IPsec Tunnel Capacity . . . . . . . . . . . . . . . . 30
10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 32 10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 30
10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 32 10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 31
10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 32 10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 31
10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 33 10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 31
10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 34 10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 32
10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 33
10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 34 10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 33
10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 35 10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 33
10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 35 10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 34
10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 36 10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 35
10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 37 10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 35
10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 37 10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 35
10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 37 10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 36
10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 37 10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 36
10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 38 10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 37
10.5. Back-to-back Frames . . . . . . . . . . . . . . . . . . . 38 10.5. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 37
10.5.1. IPsec Back-to-back Frames . . . . . . . . . . . . . . 38 10.5.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 37
10.5.2. IPsec Encryption Back-to-back Frames . . . . . . . . . 39 10.5.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 38
10.5.3. IPsec Decryption Back-to-back Frames . . . . . . . . . 39 10.5.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 38
10.6. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 40 10.6. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 39
10.6.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 40 10.6.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 39
10.6.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 40 10.6.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 39
10.6.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 41 10.7. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 40
10.7. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 41 10.8. DoS Attack Resiliency . . . . . . . . . . . . . . . . . . 40
10.7.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 41 10.8.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . 40
10.7.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 42 10.8.2. Phase 2 Hash Mismatch DoS Resiliency Rate . . . . . . 41
10.8. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 42 10.8.3. Phase 2 Anti Replay Attack DoS Resiliency Rate . . . . 41
10.9. DoS Attack Resiliency . . . . . . . . . . . . . . . . . . 43 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
10.9.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . 43 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
10.9.2. Phase 2 DoS Resiliency Rate . . . . . . . . . . . . . 43 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42
11. Security Considerations . . . . . . . . . . . . . . . . . . . 44 13.1. Normative References . . . . . . . . . . . . . . . . . . . 42
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . . 44
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44
13.1. Normative References . . . . . . . . . . . . . . . . . . . 44 Intellectual Property and Copyright Statements . . . . . . . . . . 46
13.2. Informative References . . . . . . . . . . . . . . . . . . 47
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 47
Intellectual Property and Copyright Statements . . . . . . . . . . 48
1. Introduction 1. Introduction
Despite the need to secure communications over a public medium there Despite the need to secure communications over a public medium there
is no standard method of performance measurement nor a standard in is no standard method of performance measurement nor a standard in
the terminology used to develop such hardware and software solutions. the terminology used to develop such hardware and software solutions.
This results in varied implementations which challenge This results in varied implementations which challenge
interoperability and direct performance comparisons. Standardized interoperability and direct performance comparisons. Standardized
IPsec terminology and performance test methodologies will enable IPsec terminology and performance test methodologies will enable
users to determine if the IPsec device they select will withstand users to determine if the IPsec device they select will withstand
loads of secured traffic that meet their requirements. loads of secured traffic that meet their requirements.
To appropriately define the parameters and scope of this document, To appropriately define the parameters and scope of this document,
this section will give a brief overview of the IPsec standard: this section will give a brief overview of the IPsec standard.
2. Document Scope 2. Document Scope
The primary focus of this document is to establish useful performance The primary focus of this document is to establish useful performance
testing terminology for IPsec devices that support manual keying and testing terminology for IPsec devices that support manual keying and
IKEv1. We want to constrain the terminology specified in this IKEv1. A seperate document will be written specifically to address
document to meet the requirements of the Methodology for Benchmarking testing using the updated IKEv2 specification. The terminology
IPsec Devices documented test methodologies. specified in this document is constrained to meet the requirements of
the Methodology for Benchmarking IPsec Devices documented test
methodologies.
Both IPv4 and IPv6 addressing will be taken into consideration. Both IPv4 and IPv6 addressing will be taken into consideration.
The testing will be constrained to: The testing will be constrained to:
o Devices acting as IPsec gateways whose tests will pertain to both o Devices acting as IPsec gateways whose tests will pertain to both
IPsec tunnel and transport mode. IPsec tunnel and transport mode.
o Devices acting as IPsec end-hosts whose tests will pertain to both o Devices acting as IPsec end-hosts whose tests will pertain to both
IPsec tunnel and transport mode. IPsec tunnel and transport mode.
Any testing involving interoperability and/or conformance issues, Any testing involving interoperability and/or conformance issues,
L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and
anything that does not specifically relate to the establishment and anything that does not specifically relate to the establishment and
tearing down of IPsec tunnels is specifically out of scope. It is tearing down of IPsec tunnels is specifically out of scope. It is
assumed that all relevant networking parameters that facilitate in assumed that all relevant networking parameters that facilitate in
the running of these tests are pre-configured (this includes at a the running of these tests are pre-configured (this includes at a
minimum ARP caches, routing tables, neighbor tables, etc ...). minimum ARP caches, routing tables, neighbor tables, etc ...).
A separate document will be written specifically to address testing
using the updated IKEv2 specification. Due to the dependency on
IKEv2 of the updated IPsec architecture document [RFC4301], this
document and the companion IPsec Benchmarking Methodology document
will be based on the older IPsec architecture standard [RFC2401].
3. IPsec Fundamentals 3. IPsec Fundamentals
IPsec is a framework of open standards that provides data IPsec is a framework of open standards that provides data
confidentiality, data integrity, and data origin authenticity between confidentiality, data integrity, and data origin authenticity between
participating peers. IPsec provides these security services at the participating peers. IPsec provides these security services at the
IP layer. IPsec uses IKE to handle negotiation of protocols and IP layer. IPsec uses IKE to handle negotiation of protocols and
algorithms based on local policy, and to generate the encryption and algorithms based on local policy, and to generate the encryption and
authentication keys to be used. IPsec can be used to protect one or authentication keys to be used. IPsec can be used to protect one or
more data flows between a pair of hosts, between a pair of security more data flows between a pair of hosts, between a pair of security
gateways, or between a security gateway and a host. The IPsec gateways, or between a security gateway and a host. The IPsec
skipping to change at page 8, line 9 skipping to change at page 7, line 5
The concept of a Security Association (SA) is fundamental to IPsec. The concept of a Security Association (SA) is fundamental to IPsec.
An SA is a relationship between two or more entities that describes An SA is a relationship between two or more entities that describes
how the entities will use security services to communicate. The SA how the entities will use security services to communicate. The SA
includes: an encryption algorithm, an authentication algorithm and a includes: an encryption algorithm, an authentication algorithm and a
shared session key. shared session key.
Because an SA is unidirectional, two SA's (one in each direction) are Because an SA is unidirectional, two SA's (one in each direction) are
required to secure typical, bidirectional communication between two required to secure typical, bidirectional communication between two
entities. The security services associated with an SA can be used entities. The security services associated with an SA can be used
for AH or ESP, but not for both. If both AH and ESP protection is for AH or ESP, but not for both. If both AH and ESP protection are
applied to a traffic stream, two (or more) SA's are created for each applied to a traffic stream, two (or more) SA's are created for each
direction to protect the traffic stream. direction to protect the traffic stream.
The SA is uniquely identified by the Security Parameter Index (SPI) The SA is uniquely identified by the Security Parameter Index (SPI)
[RFC2406]. When a system sends a packet that requires IPsec [RFC2406]. When a system sends a packet that requires IPsec
protection, it looks up the SA in its database and applies the protection, it looks up the SA in its database and applies the
specified processing and security protocol (AH/ESP), inserting the specified processing and security protocol (AH/ESP), inserting the
SPI from the SA into the IPsec header. When the IPsec peer receives SPI from the SA into the IPsec header. When the IPsec peer receives
the packet, it looks up the SA in its database by destination the packet, it looks up the SA in its database by destination
address, protocol, and SPI and then processes the packet as required. address, protocol, and SPI and then processes the packet as required.
3.1.2. Key Management 3.1.2. Key Management
IPsec uses cryptographic keys for authentication, integrity and IPsec uses cryptographic keys for authentication, integrity and
encryption services. Both manual provisioning and automatic encryption services. Both manual provisioning and automatic
distribution of keys is supported. IKE is specified as the public- distribution of keys are supported. IKE is specified as the public-
key-based approach for automatic key management. key-based approach for automatic key management.
IKE authenticates each peer involved in IPsec, negotiates the IKE authenticates each peer involved in IPsec, negotiates the
security policy, and handles the exchange of session keys. IKE is a security policy, and handles the exchange of session keys. IKE is a
hybrid protocol, combining parts of the following protocols to hybrid protocol, combining parts of the following protocols to
negotiate and derive keying material for SA's in a secure and negotiate and derive keying material for SA's in a secure and
authenticated manner: authenticated manner:
1. ISAKMP [RFC2408] (Internet Security Association and Key 1. ISAKMP [RFC2408] (Internet Security Association and Key
Management Protocol), which provides a framework for Management Protocol), which provides a framework for
skipping to change at page 10, line 33 skipping to change at page 9, line 31
Definition: The specific definition for the term. Definition: The specific definition for the term.
Discussion: A brief discussion of the term, its application, or Discussion: A brief discussion of the term, its application, or
other information that would build understanding. other information that would build understanding.
Issues: List of issues or conditions that affect this term. This Issues: List of issues or conditions that affect this term. This
field can present items the may impact the term's related field can present items the may impact the term's related
methodology or otherwise restrict its measurement procedures. methodology or otherwise restrict its measurement procedures.
[Measurement units:] Units used to record measurements of this term. Measurement units: (OPTIONAL) Units used to record measurements of
This field is mandatory where applicable. This field is optional this term. This field is mandatory where applicable. This field
in this document. is optional in this document.
[See Also:] List of other terms that are relevant to the discussion See Also: (OPTIONAL) List of other terms that are relevant to the
of this term. This field is optional in this document. discussion of this term. This field is optional in this document.
5. Key Words to Reflect Requirements 5. Key Words to Reflect Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. RFC 2119 document are to be interpreted as described in RFC 2119. RFC 2119
defines the use of these key words to help make the intent of defines the use of these key words to help make the intent of
standards track documents as clear as possible. While this document standards track documents as clear as possible. While this document
uses these keywords, this document is not a standards track document. uses these keywords, this document is not a standards track document.
skipping to change at page 12, line 17 skipping to change at page 11, line 13
the term 'IKE', which is an implementation of ISAKMP. the term 'IKE', which is an implementation of ISAKMP.
Issues: When implementations refer to the term 'ISAKMP SA', it Issues: When implementations refer to the term 'ISAKMP SA', it
refers to an IKE Phase 1 SA. refers to an IKE Phase 1 SA.
See Also: IKE, Security Association See Also: IKE, Security Association
7.3. IKE 7.3. IKE
Definition: A hybrid key management protocol that provides Definition: A hybrid key management protocol that provides
authentication of the IPsec peers, negotiates IPsec SAs and authentication of the IPsec peers, negotiates IPsec SA's and
establishes IPsec keys. establishes IPsec keys.
Discussion: A hybrid protocol, defined in [RFC2409], from the Discussion: A hybrid protocol, defined in [RFC2409], from the
following 3 protocols: following 3 protocols:
* ISAKMP (Internet Security Association and Key Management * ISAKMP (Internet Security Association and Key Management
Protocol), which provides a framework for authentication and Protocol), which provides a framework for authentication and
key exchange but does not define them. ISAKMP is designed to key exchange but does not define them. ISAKMP is designed to
be key exchange independent; it is designed to support many be key exchange independent; it is designed to support many
different key exchanges. different key exchanges.
skipping to change at page 12, line 39 skipping to change at page 11, line 35
* Oakley, which describes a series of key exchanges, called * Oakley, which describes a series of key exchanges, called
modes, and details the services provided by each (for example, modes, and details the services provided by each (for example,
perfect forward secrecy for keys, identity protection, and perfect forward secrecy for keys, identity protection, and
authentication). [RFC2412] authentication). [RFC2412]
* [SKEME] (Secure Key Exchange Mechanism for Internet), which * [SKEME] (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that provides describes a versatile key exchange technique that provides
anonymity, reputability, and quick key refreshment. anonymity, reputability, and quick key refreshment.
Note that IKE is an optional protocol within the IPsec framework. Note that IKE is an optional protocol within the IPsec framework.
IPsec SAs may also be manually configured. Manual keying is the IPsec SA's may also be manually configured. Manual keying is the
most basic mechanism to establish IPsec SAs between two IPsec most basic mechanism to establish IPsec SA's between two IPsec
devices. However, it is not a scalable solution and often devices. However, it is not a scalable solution and often
manually configured keys are not changed on a periodic basis which manually configured keys are not changed on a periodic basis which
reduces the level of protection since the keys are effectively reduces the level of protection since the keys are effectively
static and as a result are more prone to various attacks. When static and as a result are more prone to various attacks. When
IKE is employed as a key management protocol, the keys are IKE is employed as a key management protocol, the keys are
automatically renegotiated on a user-defined basis (time and/or automatically renegotiated on a user-defined basis (time and/or
traffic volume based) as part of the IKE rekeying mechanism. traffic volume based) as part of the IKE rekeying mechanism.
Issues: During the first IPsec deployment experiences, ambiguities Issues: During the first IPsec deployment experiences, ambiguities
were found in the IKEv1 specification, which lead to were found in the IKEv1 specification, which lead to
skipping to change at page 16, line 30 skipping to change at page 15, line 30
Issues: Due to the fragmented nature of the IPsec Protocol Suite Issues: Due to the fragmented nature of the IPsec Protocol Suite
RFC's, it is possible that IPsec implementations will not be able RFC's, it is possible that IPsec implementations will not be able
to interoperate. Therefore it is important to know which features to interoperate. Therefore it is important to know which features
and options are implemented in the IPsec Device. and options are implemented in the IPsec Device.
See Also: IPsec See Also: IPsec
7.6.1. Initiator 7.6.1. Initiator
Definition: An IPsec device which starts the negotiation of IKE Definition: An IPsec device which starts the negotiation of IKE
Phase 1 and IKE Phase 2 SAs. Phase 1 and IKE Phase 2 SA's.
Discussion: When a traffic flow is offered at an IPsec device and it Discussion: When a traffic flow is offered at an IPsec device and it
is determined that the flow must be protected, but there is no is determined that the flow must be protected, but there is no
IPsec tunnel to send the traffic through, it is the responsibility IPsec tunnel to send the traffic through, it is the responsibility
of the IPsec device to start a negotiation process that will of the IPsec device to start a negotiation process that will
instantiate the IPsec tunnel. This process will establish an IKE instantiate the IPsec tunnel. This process will establish an IKE
Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's, Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's,
eventually resulting in secured data transport. The device that eventually resulting in secured data transport. The device that
takes the action to start this negotiation process will be called takes the action to start this negotiation process will be called
an Initiator. an Initiator.
skipping to change at page 18, line 26 skipping to change at page 17, line 26
See Also: IPsec Device, IPsec Client, Initiator, Responder See Also: IPsec Device, IPsec Client, Initiator, Responder
7.7. Tunnels 7.7. Tunnels
The term "tunnel" is often used in a variety of contexts. To avoid The term "tunnel" is often used in a variety of contexts. To avoid
any discrepancies, in this document, the following distinctions have any discrepancies, in this document, the following distinctions have
been defined: been defined:
7.7.1. IPsec Tunnel 7.7.1. IPsec Tunnel
Definition: The combination of an IKE Phase 1 SA and a pair of IKE Definition: The combination of an IKE Phase 1 SA and a single pair
Phase 2 SA's. of IKE Phase 2 SA's.
Discussion: An IPsec Tunnel will be defined as a single (1) Phase 1 Discussion: An IPsec Tunnel will be defined as a single (1) Phase 1
SA and a pair (2) Phase 2 SA's. This construct will allow SA and a pair (2) Phase 2 SA's. This construct will allow
bidirectional traffic to be passed between two IPsec Devices where bidirectional traffic to be passed between two IPsec Devices where
the traffic can benefit form the services offered in the IPsec the traffic can benefit form the services offered in the IPsec
framework. framework.
Issues: Since it is implied that a Phase 1 SA is used, an IPsec Issues: Since it is implied that a Phase 1 SA is used, an IPsec
Tunnel will be by definition a dynamically negotiated secured Tunnel will be by definition a dynamically negotiated secured
link. If manual keying is used to enable secure data transport, link. If manual keying is used to enable secure data transport,
skipping to change at page 19, line 4 skipping to change at page 18, line 4
It is very likely that more then one pair of Phase 2 SA's are It is very likely that more then one pair of Phase 2 SA's are
associated with a single Phase 1 SA. Also in this case, the IPsec associated with a single Phase 1 SA. Also in this case, the IPsec
Tunnel definition WILL NOT apply. Instead the ratio between Phase Tunnel definition WILL NOT apply. Instead the ratio between Phase
1 SA's and Phase 2 SA's MUST be explictly stated. The umbrella 1 SA's and Phase 2 SA's MUST be explictly stated. The umbrella
term of "IPsec Tunnel" MUST NOT be used in this context. term of "IPsec Tunnel" MUST NOT be used in this context.
See Also: IKE Phase 1, IKE Phase 2 See Also: IKE Phase 1, IKE Phase 2
7.7.2. Configured Tunnel 7.7.2. Configured Tunnel
Definition: An IPsec tunnel or a pair of IPsec SAs in the case of Definition: An IPsec tunnel or a pair of IPsec SA's in the case of
manual keying that is provisioned in the IPsec device's manual keying that is provisioned in the IPsec device's
configuration. configuration.
Discussion: Several steps are required before IPsec can be used to Discussion: Several steps are required before IPsec can be used to
actually transport traffic. The very first step is to configure actually transport traffic. The very first step is to configure
the IPsec Tunnel (or IPsec SAs in the case of manual keying) in the IPsec Tunnel (or IPsec SA's in the case of manual keying) in
the IPsec device. When using IKE there are no SA's associated the IPsec device. When using IKE there are no SA's associated
with the IPsec Tunnel and no traffic is going through the IPsec with the IPsec Tunnel and no traffic is going through the IPsec
device that matches the Selectors, which would instantiate the device that matches the Selectors, which would instantiate the
IPsec Tunnel. When using either manual keying or IKE, a IPsec Tunnel. When using either manual keying or IKE, a
configured tunnel will not have a populated SADB. configured tunnel will not have a populated SADB.
Issues: When using IKE, a configured tunnel will not have any SA's Issues: When using IKE, a configured tunnel will not have any SA's
while with manual keying, the SAs will have simply been configured while with manual keying, the SA's will have simply been
but not populated in the SADB. configured but not populated in the SADB.
See Also: IPsec Tunnel, Established Tunnel, Active Tunnel See Also: IPsec Tunnel, Established Tunnel, Active Tunnel
7.7.3. Established Tunnel 7.7.3. Established Tunnel
Definition: An IPsec device that has a populated SADB and is ready Definition: An IPsec device that has a populated SADB and is ready
to provide security services to the appropriate traffic. to provide security services to the appropriate traffic.
Discussion: When using IKE, a second step needed to ensure that an Discussion: When using IKE, a second step needed to ensure that an
IPsec Tunnel can transport data is to complete the Phase 1 and IPsec Tunnel can transport data is to complete the Phase 1 and
Phase 2 negotiations. After the packet classification process has Phase 2 negotiations. After the packet classification process has
asserted that a packet requires security services, the negotation asserted that a packet requires security services, the negotation
is started to obtain both Phase 1 and Phase 2 SAs. After this is is started to obtain both Phase 1 and Phase 2 SA's. After this is
completed and the SADB is populated, the IPsec Tunnel is called completed and the SADB is populated, the IPsec Tunnel is called
'Established'. Note that at this time there is still no traffic 'Established'. Note that at this time there is still no traffic
flowing through the IPsec Tunnel. Just enough packet(s) have been flowing through the IPsec Tunnel. Just enough packet(s) have been
sent to the IPsec device that matched the selectors and triggered sent to the IPsec device that matched the selectors and triggered
the IPsec Tunnel setup to result in a populated SADB. In the case the IPsec Tunnel setup to result in a populated SADB. In the case
of manual keying, populating the SADB is accomplished by a of manual keying, populating the SADB is accomplished by a
separate administrative command. separate administrative command.
Issues: N/A Issues: N/A
skipping to change at page 26, line 20 skipping to change at page 25, line 20
Definition: A security context is a collection of security Definition: A security context is a collection of security
parameters that describe the characteristics of the path that an parameters that describe the characteristics of the path that an
IPsec Tunnel will take, all of the IPsec Tunnel parameters and the IPsec Tunnel will take, all of the IPsec Tunnel parameters and the
effects it has on the underlying protected traffic. Security effects it has on the underlying protected traffic. Security
Context encompasses protocol suite and security policy. Context encompasses protocol suite and security policy.
Discussion: In order to fairly compare multiple IPsec devices it is Discussion: In order to fairly compare multiple IPsec devices it is
imperative that an accurate overview is given of all security imperative that an accurate overview is given of all security
parameters that were used to establish the IPsec Tunnels or parameters that were used to establish the IPsec Tunnels or
manually created SAs and to secure the traffic between protected manually created SA's and to secure the traffic between protected
networks. Security Context is not a metric; it is included to networks. Security Context is not a metric. It is included to
accurately reflect the test environment variables when reporting accurately reflect the test environment variables when reporting
the methodology results. To avoid listing too much information the methodology results. To avoid listing too much information
when reporting metrics, we have divided the security context into when reporting metrics, the Security Context is divided into an
an IKE context and an IPsec context. IKE context and an IPsec context.
When merely discussing the behavior of traffic flows through IPsec When merely discussing the behavior of traffic flows through IPsec
devices, an IPsec context MUST be provided. In other cases the devices, an IPsec context MUST be provided. In other cases the
scope of a discussion or report may focus on a more broad set of scope of a discussion or report may focus on a more broad set of
behavioral characteristics of the IPsec device, in which case both behavioral characteristics of the IPsec device, in which case both
an IPsec and an IKE context MUST be provided. an IPsec and an IKE context MUST be provided.
The IPsec context MUST consist of the following elements: The IPsec context MUST consist of the following elements:
* Manual Keyed Tunnels versus IKE negotiated Tunnels * Manual Keyed Tunnels versus IKE negotiated Tunnels
skipping to change at page 27, line 4 skipping to change at page 25, line 48
* IPsec protocol (AH or ESP) * IPsec protocol (AH or ESP)
* IPsec protocol mode (tunnel or transport) * IPsec protocol mode (tunnel or transport)
* Authentication algorithm used by AH/ESP * Authentication algorithm used by AH/ESP
* Encryption algoritm used ESP (if applicable) * Encryption algoritm used ESP (if applicable)
* IPsec SA lifetime (traffic and time based) * IPsec SA lifetime (traffic and time based)
* Anti Replay Window Size (Assumed to be 64 packets if not
specified)
The IPsec Context MAY also list: The IPsec Context MAY also list:
* Selectors * Selectors
* Fragmentation handling * Fragmentation handling (assumed to be post-encryption when not
mentioned)
* PMTUD (assumed disabled when not mentioned)
The IKE Context MUST consist of the following elements: The IKE Context MUST consist of the following elements:
* Number of IPsec Tunnels. * Number of IPsec Tunnels.
+ IKE Phase 1 SA to IKE Phase 2 SA ratio (if applicable) + IKE Phase 1 SA to IKE Phase 2 SA ratio (if applicable)
+ IKE Phase 1 parameters + IKE Phase 1 parameters
- Authentication algorithm - Authentication algorithm
skipping to change at page 27, line 41 skipping to change at page 26, line 44
- IPsec protocol (part of IPsec context) - IPsec protocol (part of IPsec context)
- IPsec protocol mode (part of IPsec context) - IPsec protocol mode (part of IPsec context)
- Authentication algorithm (part of IPsec context) - Authentication algorithm (part of IPsec context)
- Encryption algorithm (part of IPsec context) - Encryption algorithm (part of IPsec context)
- DH-Group - DH-Group
- PFS used - PFS Group used
- SA Lifetime (part of IPsec context) - SA Lifetime (part of IPsec context)
* Keepalive or DPD values as defined in [I-D.ietf-ipsec-dpd] * Use of IKE Keepalive or DPD, as defined in
[I-D.ietf-ipsec-dpd], and its interval and retry values
(assumed disabled when not mentioned).
* IP Compression [RFC2393] * IP Compression [RFC2393]
The IKE context MUST also list: The IKE context MUST also list:
* Phase 1 mode (main or aggressive) * Phase 1 mode (main or aggressive)
* Available bandwidth and latency to Certificate Authority server * Available bandwidth and latency to Certificate Authority server
(if applicable) (if applicable)
Issues: A Security Context will be an important element in Issues: A Security Context will be an important element in
describing the environment where protected traffic is traveling describing the environment where protected traffic is traveling
through. through.
skipping to change at page 28, line 28 skipping to change at page 27, line 31
8. Framesizes 8. Framesizes
8.1. Layer3 clear framesize 8.1. Layer3 clear framesize
Definition: The total size of the unencrypted L3 PDU. Definition: The total size of the unencrypted L3 PDU.
Discussion: In relation to IPsec this is the size of the IP header Discussion: In relation to IPsec this is the size of the IP header
and its payload. It SHALL NOT include any encapsulations that MAY and its payload. It SHALL NOT include any encapsulations that MAY
be applied before the PDU is processed for encryption. be applied before the PDU is processed for encryption.
IPv4 example: 46 bytes PDU = 20 bytes IP header + 26 bytes IPv4 example: For a 64 byte Ethernet packet, the IPv4 Layer3 PDU
payload. is calculated as:
The following table represents the min/max packet sizes for a
variety of IP packet types, including raw IPv6, IPv6 with typical
transport headers, and IPv6 with IPsec.
MIN MAX
IPv6 40 1500*
IPv6+UDP 48
IPv6+TCP 60
ICMPv6 88
IPv6+AH+C 64 (transport mode compressed)
IPv6+ESP+C 74 (transport mode compressed
IPv6+T+AH+C 70 (tunnel mode compressed)
IPv6+T+ESP+C 80 (tunnel mode compressed)
Given robust header compression (ROHC), the minimum packet size is L3 PDU = 64 bytes - L2 Ethernet Header (18 bytes)
derived as follows, e.g., for tunnel mode ESP: = 46 bytes PDU
= 20 bytes IPv4 header + 26 bytes payload.
IPv6 40 bytes IPv6 example: For a 64 byte Ethernet packet, the IPv6 Layer3 PDU
IPsec 34 (ESP, 192-bit ICV) is calculated as:
-+
IPv6 |- 6 byte ROHC of tunnel and transport headers
TCP |
-+
total -----------------
80 bytes
This 80 bytes assumes that the TCP payload is 0 bytes; it may be 1 L3 PDU = 64 bytes - L2 Ethernet Header (18 bytes)
byte (e.g., data sent reliably but with "NAGLE" off). Similar = 46 bytes PDU
ROHC sizes result from UDP sources. = 40 bytes IPv6 base header + 6 bytes payload.
Measurement Units: Bytes Measurement Units: Bytes
Issues: N/A Issues: N/A
See Also: Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 See Also: Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2
Encrypted Framesize. Encrypted Framesize.
8.2. Layer3 encrypted framesize 8.2. Layer3 encrypted framesize
Definition: The total size of the encrypted L3 PDU. Definition: The total size of the encrypted L3 PDU.
Discussion: The size of the IP packet and its payload after Discussion: The size of the IP packet and its payload after
encapsulations MAY be applied and the PDU is being processed by encapsulations MAY be applied and the PDU is being processed by
the transform. the transform.
skipping to change at page 29, line 46 skipping to change at page 28, line 15
Encrypted Framesize. Encrypted Framesize.
8.2. Layer3 encrypted framesize 8.2. Layer3 encrypted framesize
Definition: The total size of the encrypted L3 PDU. Definition: The total size of the encrypted L3 PDU.
Discussion: The size of the IP packet and its payload after Discussion: The size of the IP packet and its payload after
encapsulations MAY be applied and the PDU is being processed by encapsulations MAY be applied and the PDU is being processed by
the transform. the transform.
For example, in IPv4, after a tunnel mode ESP 3DES/SHA1 transform For example, when using a tunnel mode ESP 3DES/SHA1 transform to
has been applied an unencrypted or clear layer3 framesize of 46 protect an unencrypted IPv4 L3 PDU of 46 bytes, the L3 encrypted
bytes Becomes 96 bytes: framesize becomes 96 bytes:
20 bytes outer IP header (tunnel mode) 20 bytes outer IPv4 header (Tunnel mode)
4 bytes SPI (ESP header) 4 bytes SPI (ESP Header)
4 bytes Sequence (ESP Header) 4 bytes Sequence (ESP Header)
8 bytes IV (IOS ESP-3DES) 8 bytes IV (IOS ESP-3DES)
46 bytes payload 46 bytes payload (Original IPv4 L3 PDU)
0 bytes pad (ESP-3DES 64 bit)
1 byte Pad length (ESP Trailer)
1 byte Next Header (ESP Trailer)
12 bytes ESP-HMAC SHA1 96 digest
For the same example but protecting an unencrypted IPv6 L3 PDU of
46 bytes, the L3 framesize becomes 116 bytes:
40 bytes outer IPv6 header (Tunnel mode)
4 bytes SPI (ESP Extension Header)
4 bytes Sequence (ESP Extension Header)
8 bytes IV (IOS ESP-3DES)
46 bytes payload (Original IPv6 L3 PDU)
0 bytes pad (ESP-3DES 64 bit) 0 bytes pad (ESP-3DES 64 bit)
1 byte Pad length (ESP Trailer) 1 byte Pad length (ESP Trailer)
1 byte Next Header (ESP Trailer) 1 byte Next Header (ESP Trailer)
12 bytes ESP-HMAC SHA1 96 digest 12 bytes ESP-HMAC SHA1 96 digest
Measurement Units: Bytes Measurement Units: Bytes
Issues: N/A Issues: N/A
See Also: Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 See Also: Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2
skipping to change at page 31, line 40 skipping to change at page 30, line 23
Issues: If the TAPS increases, the TPS usually decreases, due to Issues: If the TAPS increases, the TPS usually decreases, due to
burdening of the DUT with the DOS attack traffic. burdening of the DUT with the DOS attack traffic.
See Also: N/A See Also: N/A
10. Test Definitions 10. Test Definitions
10.1. Capacity 10.1. Capacity
10.1.1. IKE SA Capacity 10.1.1. IPsec Tunnel Capacity
Definition: The maximum number of IKE SA's that can be sustained on Definition: The maximum number of Active IPsec Tunnels that can be
an IPsec Device. sustained on an IPsec Device.
Discussion: This metric will represent the quantity of peer a given Discussion: This metric will represent the quantity of IPsec Tunnels
IPsec device can establish. It is the maximum number of Active that can be establish on an IPsec Device that can forward traffic
Tunnels that can be sustained by an IPsec Device. i.e. Active Tunnels. It will be a measure that indicates how
many remote peers an IPsec Device can establish a secure
connection with.
Measurement Units: IKE SA's Measurement Units: IPsec Tunnels
Issues: N/A Issues: N/A
See Also: IPsec SA Capacity See Also: IPsec SA Capacity
10.1.2. IPsec SA Capacity 10.1.2. IPsec SA Capacity
Definition: The maximum number of IPsec SA's that can be sustained Definition: The maximum number of IPsec SA's that can be sustained
on an IPsec Device. on an IPsec Device.
Discussion: This metric will represent the quantity of traffic flows Discussion: This metric will represent the quantity of traffic flows
a given IPsec Device can protect. In contrast with the IKE SA a given IPsec Device can protect. In contrast with the IPsec
Capacity, the emphasis for this test lies on the number of IPsec Tunnel Capacity, the emphasis for this test lies on the number of
SA's that can be established in the worst case scenario. This IPsec SA's that can be established in the worst case scenario.
scenario would be a case where 1 IKE SA is used to negotiate This scenario would be a case where 1 IKE SA is used to negotiate
multiple IPsec SA's. It is the maximum number of Active Tunnels multiple IPsec SA's. It is the maximum number of Active Tunnels
that can be sustained by an IPsec Device where only 1 IKE SA is that can be sustained by an IPsec Device where only 1 IKE SA is
used to exchange keying material. used to exchange keying material.
Measurement Units: IPsec SA's Measurement Units: IPsec SA's
Issues: N/A Issues: N/A
See Also: IKE SA Capacity See Also: IPsec Tunnel Capacity
10.2. Throughput 10.2. Throughput
10.2.1. IPsec Throughput 10.2.1. IPsec Throughput
Definition: The maximum rate through an Active Tunnel at which none Definition: The maximum rate through an Active Tunnel at which none
of the offered frames are dropped by the device under test. of the offered frames are dropped by the device under test.
Discussion: The IPsec Throughput is almost identically defined as Discussion: The IPsec Throughput is almost identically defined as
Throughput in [RFC1242], section 3.17. The only difference is Throughput in [RFC1242], section 3.17. The only difference is
skipping to change at page 38, line 43 skipping to change at page 37, line 26
This metric should be ideally zero but this may not be the case on This metric should be ideally zero but this may not be the case on
IPsec Devices where IPsec funtionality is not a core feature. IPsec Devices where IPsec funtionality is not a core feature.
Measurement Units: Number of N-octet frames Measurement Units: Number of N-octet frames
Issues: N/A Issues: N/A
See Also: IKE Phase 2 Rekey Rate See Also: IKE Phase 2 Rekey Rate
10.5. Back-to-back Frames 10.5. Tunnel Setup Behavior
10.5.1. IPsec Back-to-back Frames
Definition: A burst of cleartext frames, offered at a constant load
that can be sent through an Active Tunnel without losing a single
cleartext frame after decryption.
Discussion: The IPsec Back-to-back Frames is almost identically
defined as Back-to-back in [RFC1242], section 3.1. The only
difference is that the IPsec Back-to-back Frames is measured with
a traffic flow getting encrypted and decrypted by an IPsec Device.
IPsec Back-to-back Frames is an end-to-end measurement.
Measurement Units: Number of N-octet frames in burst.
Issues: Recommended test frame sizes will be addressed in
methodology document.
See Also: IPsec Encryption Back-to-back frames, IPsec Decryption
Back-to-back frames
10.5.2. IPsec Encryption Back-to-back Frames
Definition: A burst of cleartext frames, offered at a constant load
that can be sent through an Active Tunnel without losing a single
encrypted frame.
Discussion: IPsec Encryption back-to-back frames is the measure of
the maximum burst size that an IPsec Device can handle for
encrypting traffic that it receives as plaintext. Since it is not
necessarily the case that the maximum burst size a DUT can handle
for encryption is equal to the maximum burst size a DUT can handle
for decryption, both of these capabilities must be measured
independently. The IPsec Encryption Back-to-back frame
measurement has to be measured with the help of an IPsec aware
test device that can decrypt the traffic to determine the validity
of the encrypted frames.
Measurement Units: Number of N-octet frames in burst.
Issues: Recommended test frame sizes will be addressed in future
methodology document.
See Also: IPsec Back-to-back frames, IPsec Decryption Back-to-back
frames
10.5.3. IPsec Decryption Back-to-back Frames
Definition: The number of encrypted frames, offered at a constant
load, that can be sent through an Active Tunnel without losing a
single cleartext frame.
Discussion: IPsec Decryption Back-to-back frames is the measure of
the maximum burst size that an IPsec Device can handle for
decrypting traffic that it receives as encrypted traffic. Since
it is not necessarily the case that the maximum burst size a DUT
can handle for decryption is equal to the maximum burst size a DUT
can handle for encryption, both of these capabilities must be
measured independently. The IPsec Decryption Back-to-back frame
measurement has to be measured with the help of an IPsec aware
testdevice that can determine the validity of the decrypted
frames.
Measurement Units: Number of N-octet frames in burst.
Issues: Recommended test frame sizes will be addressed in
methodology document.
See Also: IPsec Back-to-back frames, IPsec Encryption back-to-back
frames
10.6. Tunnel Setup Behavior
10.6.1. IPsec Tunnel Setup Rate 10.5.1. IPsec Tunnel Setup Rate
Definition: The maximum number of IPsec Tunnels per second that an Definition: The maximum number of IPsec Tunnels per second that an
IPsec Device can successfully establish. IPsec Device can successfully establish.
Discussion: The Tunnel Setup Rate SHOULD be measured at varying Discussion: The Tunnel Setup Rate SHOULD be measured at varying
number of IPsec Tunnels (1 Phase 1 SA and 2 Phase 2 SA's) on the number of IPsec Tunnels (1 Phase 1 SA and 2 Phase 2 SA's) on the
DUT. Several factors may influence Tunnel Setup Rate, such as: DUT. Several factors may influence Tunnel Setup Rate, such as:
TAPS rate, Background cleartext traffic load on the secure TAPS rate, Background cleartext traffic load on the secure
interface, Already established IPsec Tunnels, Authentication interface, Already established IPsec Tunnels, Authentication
method such as pre-shared keys, RSA-encryption, RSA-signature, DSS method such as pre-shared keys, RSA-encryption, RSA-signature, DSS
Key sizes used (when using RSA/DSS). Key sizes used (when using RSA/DSS).
Measurement Units: Tunnels Per Second (TPS) The Tunnel Setup Rate is an important factor to understand when
designing networks using statless failover of IPsec tunnels to a
standby chassis. At the same time it can be important to set
Connection and Admission control paramters in an IPsec device to
prevent overloading the IPsec Device.
Measurement Units: Tunnels Per Second (TPS)
Issues: N/A Issues: N/A
See Also: IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec See Also: IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec
Tunnel Rekey Behavior Tunnel Rekey Behavior
10.6.2. IKE Phase 1 Setup Rate 10.5.2. IKE Phase 1 Setup Rate
Definition: The maximum number of sucessful IKE Phase 1 SA's per Definition: The maximum number of sucessful IKE Phase 1 SA's per
second that an IPsec Device can establish. second that an IPsec Device can establish.
Discussion: The Phase 1 Setup Rate is a portion of the IPsec Tunnel Discussion: The Phase 1 Setup Rate is a portion of the IPsec Tunnel
Setup Rate. In the process of establishing an IPsec Tunnel, it is Setup Rate. In the process of establishing an IPsec Tunnel, it is
interesting to know what the limiting factor of the IKE Finite interesting to know what the limiting factor of the IKE Finite
State Machine (FSM) is i.e. is it limited by the Phase 1 State Machine (FSM) is i.e. is it limited by the Phase 1
processing delays or rather by the Phase 2 processing delays. processing delays or rather by the Phase 2 processing delays.
Measurement Units: Tunnels Per Second (TPS) Measurement Units: Tunnels Per Second (TPS)
Issues: N/A Issues: N/A
See Also: IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec See Also: IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec
Tunnel Rekey Behavior Tunnel Rekey Behavior
10.6.3. IKE Phase 2 Setup Rate 10.5.3. IKE Phase 2 Setup Rate
Definition: The maximum number of successfully IKE Phase 2 SA's per Definition: The maximum number of successfully IKE Phase 2 SA's per
second that an IPsec Device can Only relevant when using IKE second that an IPsec Device can Only relevant when using IKE
establish. establish.
Discussion: The IKE Phase 2 Setup Rate is a portion of the IPsec Discussion: The IKE Phase 2 Setup Rate is a portion of the IPsec
Tunnel Setup Rate. For identical reasons why it is required to Tunnel Setup Rate. For identical reasons why it is required to
quantify the IKE Phase 1 Setup Rate, it is a good practice to know quantify the IKE Phase 1 Setup Rate, it is a good practice to know
the processing delays involved in setting up an IKE Phase 2 SA for the processing delays involved in setting up an IKE Phase 2 SA for
each direction of the protected traffic flow. each direction of the protected traffic flow.
IKE Phase 2 Setup Rates will ALWAYS be measured for multiples of IKE Phase 2 Setup Rates will ALWAYS be measured for multiples of
two IKE Phase 2 SA's. two IKE Phase 2 SA's.
Note that once you have the IPsec Tunnel Setup Rate and either the Note that once you have the IPsec Tunnel Setup Rate and either the
IKE Phase 1 or the IKE Phase 2 Setup Rate data, you can IKE Phase 1 or the IKE Phase 2 Setup Rate data, you can
extrapolate the unmeasured metric. It is however highly extrapolate the unmeasured metric. It is however highly
RECOMMENDED to measure all three metrics. RECOMMENDED to measure all three metrics since the IKE and IPsec
SA establishment are two distinct and decoupled phases in the
establishment of a Tunnel.
Measurement Units: Tunnels Per Second (TPS) Measurement Units: Tunnels Per Second (TPS)
Issues: N/A Issues: N/A
See Also: IPsec Tunnel Setup Rate, IKE Phase 1 Setup Rate, IPsec See Also: IPsec Tunnel Setup Rate, IKE Phase 1 Setup Rate, IPsec
Tunnel Rekey Behavior Tunnel Rekey Behavior
10.7. IPsec Tunnel Rekey Behavior 10.6. IPsec Tunnel Rekey Behavior
10.7.1. IKE Phase 1 Rekey Rate 10.6.1. IKE Phase 1 Rekey Rate
Definition: The number of IKE Phase 1 SA's that can be succesfully Definition: The number of IKE Phase 1 SA's that can be succesfully
re-establish per second. re-establish per second.
Discussion: Although the IKE Phase 1 Rekey Rate has less impact on Discussion: Although the IKE Phase 1 Rekey Rate has less impact on
the forwarding behavior of traffic that requires security services the forwarding behavior of traffic that requires security services
then the IKE Phase 2 Rekey Rate, it can pose a large burden on the then the IKE Phase 2 Rekey Rate, it can pose a large burden on the
CPU or network processor of the IPsec Device. Due to the highly CPU or network processor of the IPsec Device. Due to the highly
computational nature of a Phase 1 exchange, it may impact the computational nature of a Phase 1 exchange, it may impact the
stability of Active Tunnels in the network when the IPsec Device stability of Active Tunnels in the network when the IPsec Device
fails to properly rekey an IKE Phase 1 SA. fails to properly rekey an IKE Phase 1 SA.
Measurement Units: Tunnel Rekeys per second (TRPS) Measurement Units: Tunnel Rekeys per second (TRPS)
Issues: N/A Issues: N/A
See Also: IKE Phase 2 Rekey Rate See Also: IKE Phase 2 Rekey Rate
10.7.2. IKE Phase 2 Rekey Rate 10.6.2. IKE Phase 2 Rekey Rate
Definition: The number of IKE Phase 2 SA's that can be succesfully Definition: The number of IKE Phase 2 SA's that can be succesfully
re-negotiated per second. re-negotiated per second.
Discussion: Although many implementations will usually derive new Discussion: Although many implementations will usually derive new
keying material before the old keys expire, there may still be a keying material before the old keys expire, there may still be a
period of time where frames get dropped before the IKE Phase 2 period of time where frames get dropped before the IKE Phase 2
tunnels are successfully re-established. There may also be some tunnels are successfully re-established. There may also be some
packet loss introduced when the handover of traffic is done from packet loss introduced when the handover of traffic is done from
the expired IPsec SA's to the newly negotiated IPsec SA's. To the expired IPsec SA's to the newly negotiated IPsec SA's. To
skipping to change at page 42, line 43 skipping to change at page 40, line 11
The test methodology report must specify if PFS is enabled in The test methodology report must specify if PFS is enabled in
reported security context. reported security context.
Measurement Units: Tunnel Rekeys per second (TRPS) Measurement Units: Tunnel Rekeys per second (TRPS)
Issues: N/A Issues: N/A
See Also: IKE Phase 1 Rekey Rate See Also: IKE Phase 1 Rekey Rate
10.8. IPsec Tunnel Failover Time 10.7. IPsec Tunnel Failover Time
Definition: Time required to recover all IPsec Tunnels on a stanby Definition: Time required to recover all IPsec Tunnels on a stanby
IPsec Device, after a catastrophic failure occurs on the active IPsec Device, after a catastrophic failure occurs on the active
IPsec Device. IPsec Device.
Discussion: Recovery time required to re-establish all IPsec Tunnels Discussion: Recovery time required to re-establish or to engage all
and reroute all traffic on a standby node or other failsafe system IPsec Tunnels and reroute all traffic on a standby node or other
after a failure has occurred in the DUT/SUT. Failure can include failsafe system after a failure has occurred in the original
but are not limited to a catastrophic IPsec Device failure, a active DUT/SUT. Failure can include, but are not limited to, a
encryption engine failure, link outage, etc ... . The recovery catastrophic IPsec Device failure, a encryption engine failure,
time is delta between the point of failure and the time the first protocol failures and link outages. The recovery time is delta
packet is seen on the last restored IPsec Tunnel on the backup between the point of failure and the time the first packet is seen
device. on the last restored IPsec Tunnel on the backup device.
Measurement Units: Time units with enough precision to reflect IPsec Measurement Units: Time units with enough precision to reflect IPsec
Tunnel Failover Time. Tunnel Failover Time.
Issues: N/A Issues: N/A
10.9. DoS Attack Resiliency 10.8. DoS Attack Resiliency
10.9.1. Phase 1 DoS Resiliency Rate 10.8.1. Phase 1 DoS Resiliency Rate
Definition: The Phase 1 Denial of Service (DoS) Resilience Rate Definition: The Phase 1 Denial of Service (DoS) Resilience Rate
quantifies the rate of invalid or malicious IKE tunnels that can quantifies the rate of invalid or malicious IKE tunnels that can
be directed at a DUT before the Responder stops accepting valid be directed at a DUT before the Responder stops accepting valid
tunnel attempts. tunnel attempts.
Discussion: Phase 1 DoS attacks can present themselves in various Discussion: Phase 1 DoS attacks can present themselves in various
forms and do not necessarily have to have a malicious background. forms and do not necessarily have to have a malicious background.
It is sufficient to make a typographical error in a shared secret It is sufficient to make a typographical error in a shared secret
in an IPsec Device to be susceptible to a large number of IKE in an IPsec Device to be susceptible to a large number of IKE
attempts that need to be turned down. Due to the intense attempts that need to be turned down. Due to the intense
computational nature of an IKE exchange every single IKE tunnel computational nature of an IKE exchange every single IKE tunnel
attempt that has to be denied will take non-negligible CPU cycles attempt that has to be denied will take non-negligible CPU cycles
in the IPsec Device. in the IPsec Device.
Depending on the quantity of these messages that have to be Depending on the quantity of these messages that have to be
processed, a system might end up in a state that the burden on the processed, a system might end up in a state that the burden on
CPU of doing key exchanges is high enough that the entire CPU is system resource performing key exchanges is high enough that all
consumed by this process. At this point it will be no longer resources are consumed by this process. At this point it will be
possible to process a valid IKE tunnel setup request and thus a no longer possible to process a valid IKE tunnel setup request and
Phase 1 DoS Attack is in effect. thus a Phase 1 DoS Attack is in effect.
The scope of the attack profile for this test will include The scope of the attack profile for this test will include
mismatched pre-shared keys as well as invalid digital mismatched pre-shared keys as well as invalid digital
certificates. certificates.
Measurement Units: Tunnel Attempts Per Seconds (TAPS) Measurement Units: Tunnel Attempts Per Seconds (TAPS)
Issues: N/A Issues: N/A
10.9.2. Phase 2 DoS Resiliency Rate 10.8.2. Phase 2 Hash Mismatch DoS Resiliency Rate
Definition: The Phase 2 Denial of Service (DoS) Resilience Rate
quantifies the rate of invalid ESP/AH packets that a DUT can drop Definition: The Phase 2 Hash Mismatch Denial of Service (DoS)
without affecting the traffic flow of valid ESP/AH packets. Resilience Rate quantifies the rate of invalid ESP/AH packets that
a DUT can drop without affecting the traffic flow of valid ESP/AH
packets.
Discussion: Phase 2 DoS attacks can present themselves in various Discussion: Phase 2 DoS attacks can present themselves in various
forms and do not necessarily have to have a malicious background, forms and do not necessarily have to have a malicious background,
but usually are. A well know case where there is no malicious but usually are. Typical are cases where there is a true
intent is when packets are dropped due to anti-replay errors,
which can be caused by applying a queueing mechanism after
encryption. More typical are cases where there is a true
malicious intent in the ESP/AH traffic flow by e.g. having an malicious intent in the ESP/AH traffic flow by e.g. having an
invalid hash in the IPsec data packets. invalid hash in the IPsec data packets.
Depending on the quantity of these packets that have to be Depending on the quantity of these packets that have to be
processed, a system might end up in a state that the burden on the processed, a system might end up in a state that the burden on the
IPsec Device becomes large enough that it will impact valid IPsec Device becomes large enough that it will impact valid
traffic flows. At this point it will be no longer possible to traffic flows. At this point it will be no longer possible to
forward valid IPsec payload without packetloss and thus a Phase 2 forward valid IPsec payload without packetloss and thus a Phase 2
DoS Attack is in effect. DoS Attack is in effect.
Measurement Units: Packets per seconds (pps) Measurement Units: Packets per seconds (pps)
Issues: N/A Issues: N/A
10.8.3. Phase 2 Anti Replay Attack DoS Resiliency Rate
Definition: The Phase 2 Anti Replay Attack Denial of Service (DoS)
Resilience Rate quantifies the rate of replayed ESP/AH packets
that a DUT can drop without affecting the traffic flow of valid
ESP/AH packets.
Discussion: Anti Replay protection is a cornerstone feature of the
IPsec framework and can be found in both the AH as well as the ESP
protocol. To better understand what the impact is of a replay
attack on an IPsec device, a valid IPsec stream will be replayed
and each packet of the stream will appear twice on the wire at
different times where the second instance will be outside of the
Anti Replay Window.
Measurement Units: Replayed Packets per seconds (pps)
Issues: N/A
11. Security Considerations 11. Security Considerations
As this document is solely for the purpose of providing test As this document is solely for the purpose of providing test
benchmarking terminology and describes neither a protocol nor a benchmarking terminology and describes neither a protocol nor a
protocol's implementation; there are no security considerations protocol's implementation; there are no security considerations
associated with this document. associated with this document.
12. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the following individual for The authors would like to acknowledge the following individual for
skipping to change at page 48, line 7 skipping to change at page 46, line 7
IXIA IXIA
26601 W. Agoura Rd. 26601 W. Agoura Rd.
Calabasas, CA 91302 Calabasas, CA 91302
USA USA
Phone: +1(818)444-3244 Phone: +1(818)444-3244
Email: mbustos@ixiacom.com Email: mbustos@ixiacom.com
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
 End of changes. 61 change blocks. 
284 lines changed or deleted 232 lines changed or added

This html diff was produced by rfcdiff 1.34. The latest version is available from http://tools.ietf.org/tools/rfcdiff/