draft-ietf-bmwg-ipsec-term-08.txt   draft-ietf-bmwg-ipsec-term-09.txt 
Benchmarking Working Group M. Kaeo Benchmarking Working Group M. Kaeo
Internet-Draft Double Shot Security Internet-Draft Double Shot Security
Expires: September 6, 2006 T. Van Herck Expires: January 9, 2008 T. Van Herck
Cisco Systems Cisco Systems
M. Bustos M. Bustos
IXIA IXIA
March 5, 2006 July 8, 2007
Terminology for Benchmarking IPsec Devices Terminology for Benchmarking IPsec Devices
draft-ietf-bmwg-ipsec-term-08 draft-ietf-bmwg-ipsec-term-09
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 37
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 September 6, 2006. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 5 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 7 3. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 6
2.1.1. Security Associations . . . . . . . . . . . . . . . . 7 3.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 7
2.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 7 3.1.1. Security Associations . . . . . . . . . . . . . . . . 7
3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 9 3.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 8
4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 10 4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 10
5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 10 5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 10
6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 11 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 11
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 13 7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 13
7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 14 7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 13
7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 14 7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 13
7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 15 7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 14
7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 15 7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 14
7.4. Security Association (SA) . . . . . . . . . . . . . . . . 16 7.4. Security Association (SA) . . . . . . . . . . . . . . . . 15
7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 16 7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 15
7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 17 7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 15
7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 18 7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 16
7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 18 7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 17
7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 19 7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 17
7.6.4. IPsec Server . . . . . . . . . . . . . . . . . . . . . 20 7.6.4. IPsec Server . . . . . . . . . . . . . . . . . . . . . 17
7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 20 7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 18
7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 21 7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 18
7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 22 7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 19
7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 22 7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 19
7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 23 7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 20
7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 23 7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 20
7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 24 7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 21
7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 25 7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 21
7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 25 7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 22
7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 26 7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 22
7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 27 7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 23
7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 27 7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 23
7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 28 7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 24
7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 29 7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 25
7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 30 7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 25
7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 30 7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 26
8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 33 8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 28
8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33 8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 29
9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 34 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 30
9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 34 9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 30
9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 35 9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 30
9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 35 9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 31
10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 36 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1.1. IKE SA Capacity . . . . . . . . . . . . . . . . . . . 36 10.1.1. IKE SA Capacity . . . . . . . . . . . . . . . . . . . 31
10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 37 10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 32
10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 37 10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 32
10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 37 10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 32
10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 38 10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 33
10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 39 10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 34
10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 40 10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 40 10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 34
10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 41 10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 35
10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 41 10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 35
10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 42 10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 36
10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 43 10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 37
10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 43 10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 37
10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 44 10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 37
10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 44 10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 37
10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 45 10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 38
10.5. Back-to-back Frames . . . . . . . . . . . . . . . . . . . 46 10.5. Back-to-back Frames . . . . . . . . . . . . . . . . . . . 38
10.5.1. IPsec Back-to-back Frames . . . . . . . . . . . . . . 46 10.5.1. IPsec Back-to-back Frames . . . . . . . . . . . . . . 38
10.5.2. IPsec Encryption Back-to-back Frames . . . . . . . . . 46 10.5.2. IPsec Encryption Back-to-back Frames . . . . . . . . . 39
10.5.3. IPsec Decryption Back-to-back Frames . . . . . . . . . 47 10.5.3. IPsec Decryption Back-to-back Frames . . . . . . . . . 39
10.6. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 48 10.6. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 40
10.6.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 48 10.6.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 40
10.6.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 49 10.6.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 40
10.6.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 49 10.6.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 41
10.7. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 50 10.7. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 41
10.7.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 50 10.7.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 41
10.7.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 51 10.7.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 42
10.8. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 51 10.8. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 42
11. Security Considerations . . . . . . . . . . . . . . . . . . . 52 10.9. DoS Attack Resiliency . . . . . . . . . . . . . . . . . . 43
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52 10.9.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . 43
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52 10.9.2. Phase 2 DoS Resiliency Rate . . . . . . . . . . . . . 43
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 53 11. Security Considerations . . . . . . . . . . . . . . . . . . . 44
14.1. Normative References . . . . . . . . . . . . . . . . . . . 53 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 44
14.2. Informative References . . . . . . . . . . . . . . . . . . 54 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 13.1. Normative References . . . . . . . . . . . . . . . . . . . 44
Intellectual Property and Copyright Statements . . . . . . . . . . 57 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. IPsec Fundamentals 2. Document Scope
The primary focus of this document is to establish useful performance
testing terminology for IPsec devices that support manual keying and
IKEv1. We want to constrain the terminology specified in this
document to meet the requirements of the Methodology for Benchmarking
IPsec Devices documented test methodologies.
Both IPv4 and IPv6 addressing will be taken into consideration.
The testing will be constrained to:
o Devices acting as IPsec gateways whose tests will pertain to both
IPsec tunnel and transport mode.
o Devices acting as IPsec end-hosts whose tests will pertain to both
IPsec tunnel and transport mode.
Any testing involving interoperability and/or conformance issues,
L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and
anything that does not specifically relate to the establishment and
tearing down of IPsec tunnels is specifically out of scope. 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, 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
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
protocol suite set of standards is documented in RFC's [RFC2401] protocol suite set of standards is documented in RFC's [RFC2401]
through [RFC2412] and [RFC2451]. The reader is assumed to be through [RFC2412] and [RFC2451]. At this time [RFC4301] updates
familiar with these documents. Some Internet Drafts supersede these [RFC2401] (IPsec Architecture), [RFC4302] updates [RFC2402] (AH) and
RFC's and will be taken into consideration. [RFC4303] updates [RFC2406] (ESP) and [RFC4306] updates [RFC2409]
(IKE).The reader is assumed to be familiar with these documents.
IPsec itself defines the following: IPsec itself defines the following:
Authentication Header (AH): A security protocol, defined in Authentication Header (AH): A security protocol, defined in
[RFC2402], which provides data authentication and optional anti- [RFC4302], which provides data authentication and optional anti-
replay services. AH ensures the integrity and data origin replay services. AH ensures the integrity and data origin
authentication of the IP datagram as well as the invariant fields in authentication of the IP datagram as well as the invariant fields in
the outer IP header. the outer IP header.
Encapsulating Security Payload (ESP): A security protocol, defined in Encapsulating Security Payload (ESP): A security protocol, defined in
[RFC2406], which provides confidentiality, data origin [RFC4303], which provides confidentiality, data origin
authentication, connectionless integrity, an anti-replay service and authentication, connectionless integrity, an anti-replay service and
limited traffic flow confidentiality. The set of services provided limited traffic flow confidentiality. The set of services provided
depends on options selected at the time of Security Association (SA) depends on options selected at the time of Security Association (SA)
establishment and on the location of the implementation in a network establishment and on the location of the implementation in a network
topology. ESP authenticates only headers and data after the IP topology. ESP authenticates only headers and data after the IP
header. header.
Internet Key Exchange (IKE): A hybrid protocol which implements Internet Key Exchange (IKE): A hybrid protocol which implements
Oakley [RFC2412] and SKEME [SKEME] key exchanges inside the ISAKMP Oakley [RFC2412] and SKEME [SKEME] key exchanges inside the ISAKMP
framework. While IKE can be used with other protocols, its initial framework. While IKE can be used with other protocols, its initial
skipping to change at page 7, line 10 skipping to change at page 7, line 44
The security protocol header appears after the outer IP header and The security protocol header appears after the outer IP header and
before the inner IP header. before the inner IP header.
If AH is employed in tunnel mode, portions of the new outer IP header If AH is employed in tunnel mode, portions of the new outer IP header
are given protection (those same fields as for transport mode, are given protection (those same fields as for transport mode,
described earlier in this section), as well as all of the tunneled IP described earlier in this section), as well as all of the tunneled IP
packet (that is, all of the inner IP header is protected as are the packet (that is, all of the inner IP header is protected as are the
higher-layer protocols). If ESP is employed, the protection is higher-layer protocols). If ESP is employed, the protection is
afforded only to the tunneled packet, not to the new outer IP header. afforded only to the tunneled packet, not to the new outer IP header.
2.1. IPsec Operation 3.1. IPsec Operation
2.1.1. Security Associations 3.1.1. Security Associations
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
skipping to change at page 7, line 35 skipping to change at page 8, line 21
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.
2.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 is 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
skipping to change at page 8, line 16 skipping to change at page 8, line 50
2. Oakley [RFC2412], which describes a series of key exchanges, 2. Oakley [RFC2412], which describes a series of key exchanges,
called modes, and details the services provided by each (for called modes, and details the services provided by each (for
example, perfect forward secrecy for keys, identity protection, example, perfect forward secrecy for keys, identity protection,
and authentication). and authentication).
3. [SKEME] (Secure Key Exchange Mechanism for Internet), which 3. [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.
IKE creates an authenticated, secure tunnel between two entities and IKE creates an authenticated, secure tunnel between two entities and
then negotiates the security association for IPsec. This is then negotiates the security association for IPsec. In the original
performed in two phases. IKE specification [RFC2409], this is performed in two phases.
In Phase 1, the two unidirectional SA's establish a secure, In Phase 1, the two unidirectional SA's establish a secure,
authenticated channel with which to communicate. Phase 1 has two authenticated channel with which to communicate. Phase 1 has two
distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1 distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1
provides identity protection. When identity protection is not provides identity protection. When identity protection is not
needed, Aggressive Mode can be used. The completion of Phase 1 is needed, Aggressive Mode can be used. The completion of Phase 1 is
called an IKE SA. called an IKE SA.
The following attributes are used by IKE and are negotiated as part The following attributes are used by IKE and are negotiated as part
of the IKE SA: of the IKE SA:
skipping to change at page 9, line 32 skipping to change at page 10, line 17
In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's
will be called IPsec SA's. These IPsec SA's use a different shared will be called IPsec SA's. These IPsec SA's use a different shared
key than that used for the IKE_SA. The IPsec SA shared key can be key than that used for the IKE_SA. The IPsec SA shared key can be
derived by using Diffie-Hellman again or by refreshing the shared key derived by using Diffie-Hellman again or by refreshing the shared key
derived from the original Diffie-Hellman exchange that generated the derived from the original Diffie-Hellman exchange that generated the
IKE_SA by hashing it with nonces. Once the shared key is derived and IKE_SA by hashing it with nonces. Once the shared key is derived and
additional communication parameters are negotiated, the IPsec SA's additional communication parameters are negotiated, the IPsec SA's
are established and traffic can be exchanged using the negotiated are established and traffic can be exchanged using the negotiated
parameters. parameters.
3. Document Scope
The primary focus of this document is to establish useful performance
testing terminology for IPsec devices that support manual keying and
IKEv1. We want to constrain the terminology specified in this
document to meet the requirements of the Methodology for Benchmarking
IPsec Devices documented test methodologies.
Both IPv4 and IPv6 addressing will be taken into consideration.
The testing will be constrained to:
o Devices acting as IPsec gateways whose tests will pertain to both
IPsec tunnel and transport mode.
o Devices acting as IPsec end-hosts whose tests will pertain to both
IPsec tunnel and transport mode.
Any testing involving interoperability and/or conformance issues,
L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and
anything that does not specifically relate to the establishment and
tearing down of IPsec tunnels is specifically out of scope. 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, routing tables, neighbor tables, etc ...).
4. Definition Format 4. Definition Format
The definition format utilized by this document is described in The definition format utilized by this document is described in
[RFC1242], Section 2. [RFC1242], Section 2.
Term to be defined. Term to be defined.
Definition: Definition: The specific definition for the term.
The specific definition for the term.
Discussion:
A brief discussion of the term, its application, or other
information that would build understanding.
Issues:
List of issues or conditions that affect this term. This field
can present items the may impact the term's related methodology or
otherwise restrict its measurement procedures.
[Measurement units:] Discussion: A brief discussion of the term, its application, or
other information that would build understanding.
Units used to record measurements of this term. This field is Issues: List of issues or conditions that affect this term. This
mandatory where applicable. This field is optional in this field can present items the may impact the term's related
document. methodology or otherwise restrict its measurement procedures.
[See Also:] [Measurement units:] Units used to record measurements of this term.
This field is mandatory where applicable. This field is optional
in this document.
List of other terms that are relevant to the discussion of this [See Also:] List of other terms that are relevant to the discussion
term. This field is optional in this document. 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 11, line 29 skipping to change at page 11, line 27
Throughput [RFC 1242, section 3.17] Throughput [RFC 1242, section 3.17]
Latency [RFC 1242, section 3.8] Latency [RFC 1242, section 3.8]
Frame Loss Rate [RFC 1242, section 3.6] Frame Loss Rate [RFC 1242, section 3.6]
Forwarding Rates [RFC 2285, section 3.6] Forwarding Rates [RFC 2285, section 3.6]
Loads [RFC 2285, section 3.5] Loads [RFC 2285, section 3.5]
7. Definitions 7. Definitions
7.1. IPsec 7.1. IPsec
Definition: Definition: IPsec or IP Security protocol suite which comprises a
set of standards used to provide security services at the IP
IPsec or IP Security protocol suite which comprises a set of layer.
standards used to provide security services at the IP layer.
Discussion:
IPsec is a framework of protocols that offer authentication,
integrity and encryption services to the IP and/or upper layer
protocols. The major components of the protocol suite are IKE,
used for key exchanges, and IPsec protocols such as AH and ESP,
which use the exchanged keys to protect payload traffic.
Issues:
N/A Discussion: IPsec is a framework of protocols that offer
authentication, integrity and encryption services to the IP and/or
upper layer protocols. The major components of the protocol suite
are IKE, used for key exchanges, and IPsec protocols such as AH
and ESP, which use the exchanged keys to protect payload traffic.
See Also: Issues: N/A
IPsec Device, IKE, ISAKMP, ESP, AH See Also: IPsec Device, IKE, ISAKMP, ESP, AH
7.2. ISAKMP 7.2. ISAKMP
Definition: Definition: The Internet Security Association and Key Management
Protocol, which provides a framework for authentication and key
The Internet Security Association and Key Management Protocol, exchange but does not define them. ISAKMP is designed to be key
which provides a framework for authentication and key exchange but exchange independent; it is designed to support many different key
does not define them. ISAKMP is designed to be key exchange
independent; it is designed to support many different key
exchanges. ISAKMP is defined in [RFC2407]. exchanges. ISAKMP is defined in [RFC2407].
Discussion: Discussion: Though ISAKMP is only a framework for the IPsec standard
key management protocol, it is often misused and interchanged with
Though ISAKMP is only a framework for the IPsec standard key the term 'IKE', which is an implementation of ISAKMP.
management protocol, it is often misused and interchanged with the
term 'IKE', which is an implementation of ISAKMP.
Issues:
When implementations refer to the term 'ISAKMP SA', it refers to
an IKE Phase 1 SA.
See Also: Issues: When implementations refer to the term 'ISAKMP SA', it
refers to an IKE Phase 1 SA.
IKE, Security Association See Also: IKE, Security Association
7.3. IKE 7.3. IKE
Definition: Definition: A hybrid key management protocol that provides
authentication of the IPsec peers, negotiates IPsec SAs and
A hybrid key management protocol that provides authentication of establishes IPsec keys.
the IPsec peers, negotiates IPsec SAs and establishes IPsec keys.
Discussion:
A hybrid protocol, defined in [RFC2409], from the following 3 Discussion: A hybrid protocol, defined in [RFC2409], from the
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.
* 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
skipping to change at page 13, line 21 skipping to change at page 12, line 49
IPsec SAs may also be manually configured. Manual keying is the IPsec SAs 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 SAs 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: Issues: During the first IPsec deployment experiences, ambiguities
were found in the IKEv1 specification, which lead to
During the first IPsec deployment experiences, ambiguities were interoperability problems. To resolve these issues, IKEv1 is
found in the IKEv1 specification, which lead to interoperability being updated by IKEv2.
problems. To resolve these issues, IKEv1 is being updated by
IKEv2.
See Also:
ISAKMP, IPsec, Security Association See Also: ISAKMP, IPsec, Security Association
7.3.1. IKE Phase 1 7.3.1. IKE Phase 1
Definition: Definition: The shared policy and key(s) used by negotiating peers
to establish a secure authenticated "control channel" for further
The shared policy and key(s) used by negotiating peers to IKE communications.
establish a secure authenticated "control channel" for further IKE
communications.
Discussion:
The IPsec framework mandates that SPI's are used to secure payload Discussion: The IPsec framework mandates that SPI's are used to
traffic. If IKE is employed all SPI information will be exchanged secure payload traffic. If IKE is employed all SPI information
between the IPsec devices. This has to be done in a secure will be exchanged between the IPsec devices. This has to be done
fashion and for that reason IKE will set up a secure "control in a secure fashion and for that reason IKE will set up a secure
channel" over which it can exchange this information. "control channel" over which it can exchange this information.
Note that IKE is an optional protocol within the IPsec framework Note that IKE is an optional protocol within the IPsec framework
and that SPI information can also be manually configured. and that SPI information can also be manually configured.
Issues: Issues: In some documents often referenced as ISAKMP SA or IKE SA.
In some documents often referenced as ISAKMP SA or IKE SA.
See Also:
IKE, ISAKMP See Also: IKE, ISAKMP
7.3.2. IKE Phase 1 Main Mode 7.3.2. IKE Phase 1 Main Mode
Definition: Definition: Main Mode is an instantiation of the ISAKMP Identity
Protect Exchange, defined in [RFC2409]. Upon successful
Main Mode is an instantiation of the ISAKMP Identity Protect completion it results in the establishment of an IKE Phase 1 SA.
Exchange, defined in [RFC2409]. Upon successful completion it
results in the establishment of an IKE Phase 1 SA.
Discussion:
IKE Main Mode use 3 distinct message pairs, for a total of 6
messages. The first two messages negotiate policy; the next two
represent Diffie-Hellman public values and ancillary data (e.g.
nonces); and the last two messages authenticate the Diffie-Hellman
Exchange. The authentication method negotiated as part of the
initial IKE Phase 1 influence the composition of the payloads but
not their purpose.
Issues:
N/A Discussion: IKE Main Mode use 3 distinct message pairs, for a total
of 6 messages. The first two messages negotiate policy; the next
two represent Diffie-Hellman public values and ancillary data
(e.g. nonces); and the last two messages authenticate the Diffie-
Hellman Exchange. The authentication method negotiated as part of
the initial IKE Phase 1 influence the composition of the payloads
but not their purpose.
See Also: Issues: N/A
ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode See Also: ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode
7.3.3. IKE Phase 1 Aggressive Mode 7.3.3. IKE Phase 1 Aggressive Mode
Definition: Definition: Aggressive Mode is an instantiation of the ISAKMP
Aggressive Exchange, defined in [RFC2409]. Upon successful
Aggressive Mode is an instantiation of the ISAKMP Aggressive completion it results in the establishment of an IKE Phase 1 SA.
Exchange, defined in [RFC2409]. Upon successful completion it
results in the establishment of an IKE Phase 1 SA.
Discussion:
IKE Aggressive Mode uses 3 messages. The first two messages Discussion: IKE Aggressive Mode uses 3 messages. The first two
negotiate policy, exchange Diffie-Hellman public values and messages negotiate policy, exchange Diffie-Hellman public values
ancillary data necessary for the exchange, and identities. In and ancillary data necessary for the exchange, and identities. In
addition the second message authenticates the Responder. The addition the second message authenticates the Responder. The
third message authenticates the Initiator and provides proof of third message authenticates the Initiator and provides proof of
participation in the exchange. participation in the exchange.
Issues: Issues: For IKEv1 the standard specifies that all implementations
use both main and agressive mode, however, it is common to use
For IKEv1 the standard specifies that all implementations use both only main mode.
main and agressive mode, however, it is common to use only main
mode.
See Also:
ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode See Also: ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode
7.3.4. IKE Phase 2 7.3.4. IKE Phase 2
Definition: Definition: ISAKMP phase which upon successful completion
establishes the shared keys used by the negotiating peers to set
ISAKMP phase which upon successful completion establishes the up a secure "data channel" for IPsec.
shared keys used by the negotiating peers to set up a secure "data
channel" for IPsec.
Discussion:
The main purpose of Phase 2 is to produce the key for the IPsec
tunnel. Phase 2 is also used for exchanging informational
messages.
Issues:
In other documents also referenced as IPsec SA. Discussion: The main purpose of Phase 2 is to produce the key for
the IPsec tunnel. Phase 2 is also used for exchanging
informational messages.
See Also: Issues: In other documents also referenced as IPsec SA.
IKE Phase 1, ISAKMP, IKE See Also: IKE Phase 1, ISAKMP, IKE
7.3.5. Phase 2 Quick Mode 7.3.5. Phase 2 Quick Mode
Definition: Definition: Quick Mode is an instanciation of IKE Phase 2. After
successful completion it will result in one or typically two or
Quick Mode is an instanciation of IKE Phase 2. After successful more IPsec SA's
completion it will result in one or typically two or more IPsec
SA's
Discussion:
Quick Mode is used to negotiate the SA's and keys that will be Discussion: Quick Mode is used to negotiate the SA's and keys that
used to protect the user data. Three different messages are will be used to protect the user data. Three different messages
exchanged, which are protected by the security parameters are exchanged, which are protected by the security parameters
negotiated by the IKE phase 1 exchange. An additional Diffie- negotiated by the IKE phase 1 exchange. An additional Diffie-
Hellman exchange may be performed if PFS (Perfect Forward Secrecy) Hellman exchange may be performed if PFS (Perfect Forward Secrecy)
is enabled. is enabled.
Issues: Issues: N/A
N/A
See Also:
ISAKMP, IKE, IKE Phase 2 See Also: ISAKMP, IKE, IKE Phase 2
7.4. Security Association (SA) 7.4. Security Association (SA)
Definition: Definition: A set of policy and key(s) used to protect traffic flows
that require authentication and/or encryption services. It is a
A set of policy and key(s) used to protect traffic flows that
require authentication and/or encryption services. It is a
negotiation agreement between two IPsec devices, specifically the negotiation agreement between two IPsec devices, specifically the
Initiator and Responder. Initiator and Responder.
Discussion: Discussion: A simplex (unidirectional) logical connection that links
a traffic flow to a set of security parameters. All traffic
A simplex (unidirectional) logical connection that links a traffic traversing an SA is provided the same security processing and will
flow to a set of security parameters. All traffic traversing an be subjected to a common set of encryption and/or authentication
SA is provided the same security processing and will be subjected algorithms. In IPsec, an SA is an Internet layer abstraction
to a common set of encryption and/or authentication algorithms. implemented through the use of AH or ESP as defined in [RFC2401].
In IPsec, an SA is an Internet layer abstraction implemented
through the use of AH or ESP as defined in [RFC2401].
Issues:
N/A
See Also: Issues: N/A
Initiator, Responder See Also: Initiator, Responder
7.5. Selectors 7.5. Selectors
Definition: Definition: A mechanism used for the classification of traffic flows
that require authentication and/or encryption services.
A mechanism used for the classification of traffic flows that
require authentication and/or encryption services.
Discussion:
The selectors are a set of fields that will be extracted from the Discussion: The selectors are a set of fields that will be extracted
network and transport layer headers that provide the ability to from the network and transport layer headers that provide the
classify the traffic flow and associate it with an SA. ability to classify the traffic flow and associate it with an SA.
After classification, a decision can be made if the traffic needs After classification, a decision can be made if the traffic needs
to be encrypted/decrypted and how this should be done depending on to be encrypted/decrypted and how this should be done depending on
the SA linked to the traffic flow. Simply put, selectors classify the SA linked to the traffic flow. Simply put, selectors classify
IP packets that require IPsec processing and those packets that IP packets that require IPsec processing and those packets that
must be passed along without any intervention of the IPsec must be passed along without any intervention of the IPsec
framework. framework.
Selectors are flexible objects that can match on ranges of source Selectors are flexible objects that can match on ranges of source
and destination addresses and ranges of source and destination and destination addresses and ranges of source and destination
ports. ports.
Issues: Issues: Both sides must agree exactly on both the networks being
Both sides must agree exactly on both the networks being
protected, and they both must agree on how to describe the protected, and they both must agree on how to describe the
networks (range, subnet, addresses). This is a common point of networks (range, subnet, addresses). This is a common point of
non-interoperability. non-interoperability.
7.6. IPsec Device 7.6. IPsec Device
Definition: Any implementation that has the ability to process data
flows according to the IPsec protocol suite specifications.
Definition: Discussion: Implementations can be grouped by 'external' properties
(e.g. software vs. hardware implementations) but more important is
Any implementation that has the ability to process data flows the subtle differences that implementations may have with relation
according to the IPsec protocol suite specifications. to the IPsec Protocol Suite. Not all implementations will cover
all RFC's that encompass the IPsec Protocol Suite, but the
Discussion: majority will support a large subset of features described in the
suite, nor will all implementations utilize all of the
Implementations can be grouped by 'external' properties (e.g. cryptographic functions listed in the RFC's.
software vs. hardware implementations) but more important is the
subtle differences that implementations may have with relation to
the IPsec Protocol Suite. Not all implementations will cover all
RFC's that encompass the IPsec Protocol Suite, but the majority
will support a large subset of features described in the suite,
nor will all implementations utilize all of the cryptographic
functions listed in the RFC's.
In that context, any implementation, that supports basic IP layer In that context, any implementation, that supports basic IP layer
security services as described in the IPsec protocol suite shall security services as described in the IPsec protocol suite shall
be called an IPsec Device. be called an IPsec Device.
Issues: Issues: Due to the fragmented nature of the IPsec Protocol Suite
RFC's, it is possible that IPsec implementations will not be able
Due to the fragmented nature of the IPsec Protocol Suite RFC's, it to interoperate. Therefore it is important to know which features
is possible that IPsec implementations will not be able 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: See Also: IPsec
IPsec
7.6.1. Initiator 7.6.1. Initiator
Definition: Definition: An IPsec device which starts the negotiation of IKE
Phase 1 and IKE Phase 2 SAs.
An IPsec device which starts the negotiation of IKE Phase 1 and
IKE Phase 2 SAs.
Discussion:
When a traffic flow is offered at an IPsec device and it is Discussion: When a traffic flow is offered at an IPsec device and it
determined that the flow must be protected, but there is no IPsec is determined that the flow must be protected, but there is no
tunnel to send the traffic through, it is the responsibility of IPsec tunnel to send the traffic through, it is the responsibility
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.
Issues: Issues: IPsec devices/implementations can be both an initiator as
well as a responder. The distinction is useful from a test
IPsec devices/implementations can be both an initiator as well as perspective.
a responder. The distinction is useful from a test perspective.
See Also:
Responder, IKE, IPsec See Also: Responder, IKE, IPsec
7.6.2. Responder 7.6.2. Responder
Definition:
An IPsec device which replies to incoming IKE Phase 1 and IKE Definition: An IPsec device which replies to incoming IKE Phase 1
Phase 2 requests and processes these messages in order to and IKE Phase 2 requests and processes these messages in order to
establish an IPsec tunnel. establish an IPsec tunnel.
Discussion: Discussion: When an initiator attempts to establish SA's with
another IPsec device, this peer will need to evaluate the
When an initiator attempts to establish SA's with another IPsec proposals made by the initiator and either accept or deny them.
device, this peer will need to evaluate the proposals made by the In the former case, the traffic flow will be decrypted according
initiator and either accept or deny them. In the former case, the to the negotiated parameters. Such a device will be called a
traffic flow will be decrypted according to the negotiated Responder.
parameters. Such a device will be called a Responder.
Issues:
IPsec devices/implementations can usually be both an initiator as
well as a responder. The distinction is useful from a test
perspective.
See Also: Issues: IPsec devices/implementations can usually be both an
initiator as well as a responder. The distinction is useful from
a test perspective.
Initiator, IKE See Also: Initiator, IKE
7.6.3. IPsec Client 7.6.3. IPsec Client
Definition: Definition: IPsec Devices that will only act as an Initiator.
IPsec Devices that will only act as an Initiator.
Discussion:
In some situations it is not needed or prefered to have an IPsec Discussion: In some situations it is not needed or prefered to have
device respond to an inbound IKE SA or IPsec SA request. In the an IPsec device respond to an inbound IKE SA or IPsec SA request.
case of e.g. road warriors or home office scenarios the only In the case of e.g. road warriors or home office scenarios the
property needed from the IPsec device is the ability to securely only property needed from the IPsec device is the ability to
connect to a remote private network. The IPsec Client will securely connect to a remote private network. The IPsec Client
initiate one or more IPsec tunnels to an IPsec Server on the will initiate one or more IPsec tunnels to an IPsec Server on the
network that needs to be accessed and to provide the required network that needs to be accessed and to provide the required
security services. An IPsec client will silently drop and ignore security services. An IPsec client will silently drop and ignore
any inbound IPsec tunnel requests. IPsec clients are generally any inbound IPsec tunnel requests. IPsec clients are generally
used to connect remote users in a secure fashion over the Internet used to connect remote users in a secure fashion over the Internet
to a private network. to a private network.
Issues: Issues: N/A
N/A
See Also:
IPsec device, IPsec Server, Initiator, Responder See Also: IPsec device, IPsec Server, Initiator, Responder
7.6.4. IPsec Server 7.6.4. IPsec Server
Definition: Definition: IPsec Devices that can both act as an Initiator as well
as a Responder.
IPsec Devices that can both act as an Initiator as well as a
Responder.
Discussion:
IPsec Servers are mostly positioned at private network edges and Discussion: IPsec Servers are mostly positioned at private network
provide several functions: edges and provide several functions:
* Responds to IPsec tunnel setup request from IPsec Clients. * Responds to IPsec tunnel setup request from IPsec Clients.
* Responds to IPsec tunnel setup request from other IPsec devices * Responds to IPsec tunnel setup request from other IPsec devices
(Initiators). (Initiators).
* Initiate IPsec tunnels to other IPsec servers inside or outside * Initiate IPsec tunnels to other IPsec servers inside or outside
the private network. the private network.
Issues: Issues: IPsec Servers are also sometimes referred to as 'VPN
IPsec Servers are also sometimes referred to as 'VPN
Concentrators'. Concentrators'.
See Also: See Also: IPsec Device, IPsec Client, Initiator, Responder
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: Definition: The combination of an IKE Phase 1 SA and a pair of IKE
Phase 2 SA's.
The combination of an IKE Phase 1 SA and a pair of IKE Phase 2
SA's.
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 bidirectional
traffic to be passed between two IPsec Devices where the traffic
can benefit form the services offered in the IPsec framework.
Issues: 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
bidirectional traffic to be passed between two IPsec Devices where
the traffic can benefit form the services offered in the IPsec
framework.
Since it is implied that a Phase 1 SA is used, an IPsec Tunnel Issues: Since it is implied that a Phase 1 SA is used, an IPsec
will be by definition a dynamically negotiated secured link. If Tunnel will be by definition a dynamically negotiated secured
manual keying is used to enable secure data transport, then this link. If manual keying is used to enable secure data transport,
link will merely be referred to as a pair of IPsec SA's. then this link will merely be referred to as a pair of IPsec SA's.
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: See Also: IKE Phase 1, IKE Phase 2
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
manual keying that is provisioned in the IPsec device's
configuration.
Definition: Discussion: Several steps are required before IPsec can be used to
actually transport traffic. The very first step is to configure
An IPsec tunnel or a pair of IPsec SAs in the case of manual the IPsec Tunnel (or IPsec SAs in the case of manual keying) in
keying that is provisioned in the IPsec device's configuration. the IPsec device. When using IKE there are no SA's associated
with the IPsec Tunnel and no traffic is going through the IPsec
Discussion: device that matches the Selectors, which would instantiate the
IPsec Tunnel. When using either manual keying or IKE, a
Several steps are required before IPsec can be used to actually configured tunnel will not have a populated SADB.
transport traffic. The very first step is to configure the IPsec
Tunnel (or IPsec SAs in the case of manual keying) in the IPsec
device. When using IKE there are no SA's associated with the
IPsec Tunnel and no traffic is going through the IPsec device that
matches the Selectors, which would instantiate the IPsec Tunnel.
When using either manual keying or IKE, a configured tunnel will
not have a populated SADB.
Issues:
When using IKE, a configured tunnel will not have any SAs while
with manual keying, the SAs will have simply been configured but
not populated in the SADB.
See Also: Issues: When using IKE, a configured tunnel will not have any SA's
while with manual keying, the SAs will have simply been configured
but not populated in the SADB.
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: Definition: An IPsec device that has a populated SADB and is ready
to provide security services to the appropriate traffic.
An IPsec device that has a populated SADB and is ready to provide
security services to the appropriate traffic.
Discussion:
When using IKE, a second step needed to ensure that an IPsec Discussion: When using IKE, a second step needed to ensure that an
Tunnel can transport data is to complete the Phase 1 and Phase 2 IPsec Tunnel can transport data is to complete the Phase 1 and
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 SAs. 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: Issues: N/A
N/A
See Also:
IPsec Tunnel, Configured Tunnel, Active Tunnel See Also: IPsec Tunnel, Configured Tunnel, Active Tunnel
7.7.4. Active Tunnel 7.7.4. Active Tunnel
Definition: Definition: An IPsec device that is forwarding secured data.
An IPsec device that is forwarding secured data.
Discussion:
When a Tunnel is Established and it is transporting traffic that
is authenticated and/or encrypted, the tunnel is called 'Active'.
Issues: Discussion: When a Tunnel is Established and it is transporting
traffic that is authenticated and/or encrypted, the tunnel is
called 'Active'.
The distinction between an Active Tunnel and Configured/ Issues: The distinction between an Active Tunnel and Configured/
Established Tunnel is made in the context of manual keyed Tunnels. Established Tunnel is made in the context of manual keyed Tunnels.
In this case it would be possible to have an Established tunnel on In this case it would be possible to have an Established tunnel on
an IPsec device which has no counterpart on it's corresponding an IPsec device which has no counterpart on it's corresponding
peer. This will lead to encrypted traffic flows which will be peer. This will lead to encrypted traffic flows which will be
discarded on the receiving peer. Only if both peers have an discarded on the receiving peer. Only if both peers have an
Established Tunnel that shows evidence of traffic transport, it Established Tunnel that shows evidence of traffic transport, it
may be called an Active Tunnel. may be called an Active Tunnel.
See Also: See Also: IPsec Tunnel, Configured Tunnel, Established Tunnel
IPsec Tunnel, Configured Tunnel, Established Tunnel
7.8. Iterated Tunnels 7.8. Iterated Tunnels
Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. Iterated Tunnels are a bundle of transport and/or tunnel mode SA's.
The bundles are divided into two major groups : The bundles are divided into two major groups :
7.8.1. Nested Tunnels 7.8.1. Nested Tunnels
Definition: Definition: An SA bundle consisting of two or more 'tunnel mode'
SA's.
An SA bundle consisting of two or more 'tunnel mode' SA's.
Discussion:
The process of nesting tunnels can theoretically be repeated Discussion: The process of nesting tunnels can theoretically be
multiple times (for example, tunnels can be many levels deep), but repeated multiple times (for example, tunnels can be many levels
for all practical purposes, most implementations limit the level deep), but for all practical purposes, most implementations limit
of nesting. Nested tunnels can use a mix of AH and ESP the level of nesting. Nested tunnels can use a mix of AH and ESP
encapsulated traffic. encapsulated traffic.
[GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
| | | | | | | |
| | | | | | | |
| +----{SA1 (ESP tunnel)}----+ | | +----{SA1 (ESP tunnel)}----+ |
| | | |
+--------------{SA2 (AH tunnel)}---------------+ +--------------{SA2 (AH tunnel)}---------------+
In the IP Cloud a packet would have a format like this : In the IP Cloud a packet would have a format like this :
[IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH] [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH]
Nested tunnels can be deployed to provide additional security on Nested tunnels can be deployed to provide additional security on
already secured traffic. A typical example of this would be that already secured traffic. A typical example of this would be that
the inner gateways (GW2 and GW3) are securing traffic between two the inner gateways (GW2 and GW3) are securing traffic between two
branch offices and the outer gateways (GW1 & GW4) add an branch offices and the outer gateways (GW1 & GW4) add an
additional layer of security between departments within those additional layer of security between departments within those
branch offices. branch offices.
skipping to change at page 24, line 14 skipping to change at page 21, line 6
In the IP Cloud a packet would have a format like this : In the IP Cloud a packet would have a format like this :
[IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH] [IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH]
Nested tunnels can be deployed to provide additional security on Nested tunnels can be deployed to provide additional security on
already secured traffic. A typical example of this would be that already secured traffic. A typical example of this would be that
the inner gateways (GW2 and GW3) are securing traffic between two the inner gateways (GW2 and GW3) are securing traffic between two
branch offices and the outer gateways (GW1 & GW4) add an branch offices and the outer gateways (GW1 & GW4) add an
additional layer of security between departments within those additional layer of security between departments within those
branch offices. branch offices.
Issues: Issues: N/A
N/A
See Also:
Transport Adjacency, IPsec Tunnel See Also: Transport Adjacency, IPsec Tunnel
7.8.2. Transport Adjacency 7.8.2. Transport Adjacency
Definition: Definition: An SA bundle consisting of two or more transport mode
SA's.
An SA bundle consisting of two or more transport mode SA's.
Discussion:
Transport adjacency is a form of tunnel nesting. In this case two Discussion: Transport adjacency is a form of tunnel nesting. In
or more transport mode IPsec tunnels are set side by side to this case two or more transport mode IPsec tunnels are set side by
enhance applied security properties. side to enhance applied security properties.
Transport adjacency can be used with a mix of AH and ESP tunnels Transport adjacency can be used with a mix of AH and ESP tunnels
although some combinations are not preferred. If AH and ESP are although some combinations are not preferred. If AH and ESP are
mixed, the ESP tunnel should always encapsulate the AH tunnel. mixed, the ESP tunnel should always encapsulate the AH tunnel.
The reverse combination is a valid combination but doesn't make The reverse combination is a valid combination but doesn't make
cryptographical sense. cryptographical sense.
[GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
| | | | | | | |
| | | | | | | |
skipping to change at page 25, line 4 skipping to change at page 21, line 31
mixed, the ESP tunnel should always encapsulate the AH tunnel. mixed, the ESP tunnel should always encapsulate the AH tunnel.
The reverse combination is a valid combination but doesn't make The reverse combination is a valid combination but doesn't make
cryptographical sense. cryptographical sense.
[GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
| | | | | | | |
| | | | | | | |
| +------{SA1 (ESP transport)}--------+ | | +------{SA1 (ESP transport)}--------+ |
| | | |
+-------------{SA2 (AH transport)}--------------+ +-------------{SA2 (AH transport)}--------------+
In the IP Cloud a packet would have a format like this : In the IP Cloud a packet would have a format like this :
[IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH]
Issues: Issues: This is rarely used in the way it is depicted. It is more
common, but still not likely, that SA's are established from
This is rarely used in the way it is depicted. It is more common, different gateways as depicted in the Nested Tunnels figure. The
but still not likely, that SA's are established from different packet format in the IP Cloud would remain unchanged.
gateways as depicted in the Nested Tunnels figure. The packet
format in the IP Cloud would remain unchanged.
See Also:
Nested Tunnels, IPsec Tunnel See Also: Nested Tunnels, IPsec Tunnel
7.9. Transform protocols 7.9. Transform protocols
Definition: Definition: Encryption and authentication algorithms that provide
cryptograhic services to the IPsec Protocols.
Encryption and authentication algorithms that provide cryptograhic
services to the IPsec Protocols.
Discussion:
Some algorithms run significantly slower than others. A decision
for which algorithm to use is usually based on the tradeoff
between performance and security strength. For example, 3DES
encryption is generally slower then DES encryption.
Issues:
N/A Discussion: Some algorithms run significantly slower than others. A
decision for which algorithm to use is usually based on the
tradeoff between performance and security strength. For example,
3DES encryption is generally slower then DES encryption.
See Also: Issues: N/A
Authentication protocols, Encryption protocols See Also: Authentication protocols, Encryption protocols
7.9.1. Authentication Protocols 7.9.1. Authentication Protocols
Definition: Definition: Algorithms which provide data integrity and data source
Algorithms which provide data integrity and data source
authentication. authentication.
Discussion: Discussion: Authentication protocols provide no confidentiality.
Commonly used authentication algorithms/protocols are:
Authentication protocols provide no confidentiality. Commonly
used authentication algorithms/protocols are:
* MD5-HMAC * MD5-HMAC
* SHA-HMAC * SHA-HMAC
* AES-HMAC * AES-HMAC
Issues: Issues: N/A
N/A
See Also:
Transform protocols, Encryption protocols See Also: Transform protocols, Encryption protocols
7.9.2. Encryption Protocols 7.9.2. Encryption Protocols
Definition: Definition: Algorithms which provide data confidentiality.
Algorithms which provide data confidentiality.
Discussion:
Encryption protocols provide no authentication. Commonly used Discussion: Encryption protocols provide no authentication.
encryption algorithms/protocols are: Commonly used encryption algorithms/protocols are:
* NULL encryption * NULL encryption
* DES-CBC * DES-CBC
* 3DES-CBC * 3DES-CBC
* AES-CBC * AES-CBC
Issues: Issues: The null-encryption option is a valid encryption mechanism
to provide an alternative to using AH. There is no
The null-encryption option is a valid encryption mechanism to confidentiality protection with null-encryption. Note also that
provide an alternative to using AH. There is no confidentiality when using ESP null-encryption the authentication and integrity
protection with null-encryption. Note also that when using ESP services only apply for the upper layer protocols and not for the
null-encryption the authentication and integrity services only IP header itself.
apply for the upper layer protocols and not for the IP header
itself.
DES has been officially deprecated by NIST, though it is still DES has been officially deprecated by NIST, though it is still
mandated by the IPsec framework and is still commonly implemented mandated by the IPsec framework and is still commonly implemented
and used due to it's speed advantage over 3DES. AES will be the and used due to it's speed advantage over 3DES. AES will be the
successor of 3DES due to its superior encryption and performance successor of 3DES due to its superior encryption and performance
advantage. advantage.
See Also: See Also: Transform protocols, Authentication protocols
Transform protocols, Authentication protocols
7.10. IPsec Protocols 7.10. IPsec Protocols
Definition: Definition: A suite of protocols which provide a framework of open
standards that provides data origin confidentiality, data
A suite of protocols which provide a framework of open standards integrity, and data origin authenticity between participating
that provides data origin confidentiality, data integrity, and peers at the IP layer. The original IPsec protocol suite set of
data origin authenticity between participating peers at the IP standards is documented in [RFC2401] through [RFC2412] and
layer. The IPsec protocol suite set of standards is documented in [RFC2451]. At this time [RFC4301] updates [RFC2401] (IPsec
[RFC2401] through [RFC2412] and [RFC2451]. Architecture), [RFC4302] updates [RFC2402] (AH) and [RFC4303]
updates [RFC2406] (ESP)
Discussion:
The IPsec Protocol suite is modular and forward compatible. The
protocols that comprise the IPsec protocol suite can be replaced
with new versions of those protocols as the older versions become
obsolete. For example, IKEv2 will soon replace IKEv1.
Issues:
N/A Discussion: The IPsec Protocol suite is modular and forward
compatible. The protocols that comprise the IPsec protocol suite
can be replaced with new versions of those protocols as the older
versions become obsolete. For example, IKEv2 will soon replace
IKEv1.
See Also: Issues: N/A
AH, ESP See Also: AH, ESP
7.10.1. Authentication Header (AH) 7.10.1. Authentication Header (AH)
Definition: Definition: Provides data origin authentication and data integrity
(including replay protection) security services as defined in
Provides data origin authentication and data integrity (including [RFC4302].
replay protection) security services as defined in [RFC2402].
Discussion:
The AH protocol supports two modes of operation i.e. tunnel mode Discussion: The AH protocol supports two modes of operation i.e.
and transport mode. tunnel mode and transport mode.
In transport mode, AH is inserted after the IP header and before a In transport mode, AH is inserted after the IP header and before a
next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any
other IPsec headers that have already been inserted. In the other IPsec headers that have already been inserted. In the
context of IPv4, this calls for placing AH after the IP header context of IPv4, this calls for placing AH after the IP header
(and any options that it contains), but before the next layer (and any options that it contains), but before the next layer
protocol. In the IPv6 context, AH is viewed as an end-to-end protocol. In the IPv6 context, AH is viewed as an end-to-end
payload, and thus should appear after hop-by-hop, routing, and payload, and thus should appear after hop-by-hop, routing, and
fragmentation extension headers. The destination options fragmentation extension headers. The destination options
extension header(s) could appear before or after or both before extension header(s) could appear before or after or both before
and after the AH header depending on the semantics desired. and after the AH header depending on the semantics desired.
In tunnel mode, the "inner" IP header carries the ultimate (IP) In tunnel mode, the "inner" IP header carries the ultimate (IP)
source and destination addresses, while an "outer" IP header source and destination addresses, while an "outer" IP header
contains the addresses of the IPsec "peers," e.g., addresses of contains the addresses of the IPsec "peers," e.g., addresses of
security gateways. In tunnel mode, AH protects the entire inner security gateways. In tunnel mode, AH protects the entire inner
IP packet, including the entire inner IP header. The position of IP packet, including the entire inner IP header. The position of
AH in tunnel mode, relative to the outer IP header, is the same as AH in tunnel mode, relative to the outer IP header, is the same as
for AH in transport mode. for AH in transport mode.
Issues: Issues: AH is rarely used to secure traffic over the Internet.
AH is rarely used to secure traffic over the Internet.
See Also:
Transform protocols, IPsec protocols, Encapsulated Security See Also: Transform protocols, IPsec protocols, Encapsulated
Payload Security Payload
7.10.2. Encapsulated Security Payload (ESP) 7.10.2. Encapsulated Security Payload (ESP)
Definition: Definition: Provides data origin authentication, data integrity
(including replayprotection) and data confidentiality as defined
Provides data origin authentication, data integrity (including in [RFC4303].
replay protection) and data confidentiality as defined in
[RFC2406].
Discussion:
The ESP protocol supports two modes of operation i.e. tunnel mode Discussion: The ESP protocol supports two modes of operation i.e.
and transport mode. tunnel mode and transport mode.
In transport mode, ESP is inserted after the IP header and before In transport mode, ESP is inserted after the IP header and before
a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context
of IPv4, this translates to placing ESP after the IP header (and of IPv4, this translates to placing ESP after the IP header (and
any options that it contains), but before the next layer protocol. any options that it contains), but before the next layer protocol.
In the IPv6 context, ESP is viewed as an end-to-end payload, and In the IPv6 context, ESP is viewed as an end-to-end payload, and
thus should appear after hop-by-hop, routing, and fragmentation thus should appear after hop-by-hop, routing, and fragmentation
extension headers. Destination options extension header(s) could extension headers. Destination options extension header(s) could
appear before, after, or both before and after the ESP header appear before, after, or both before and after the ESP header
depending on the semantics desired. However, since ESP protects depending on the semantics desired. However, since ESP protects
skipping to change at page 29, line 14 skipping to change at page 24, line 48
In tunnel mode, the "inner" IP header carries the ultimate (IP) In tunnel mode, the "inner" IP header carries the ultimate (IP)
source and destination addresses, while an "outer" IP header source and destination addresses, while an "outer" IP header
contains the addresses of the IPsec "peers", e.g., addresses of contains the addresses of the IPsec "peers", e.g., addresses of
security gateways. Mixed inner and outer IP versions are allowed, security gateways. Mixed inner and outer IP versions are allowed,
i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP
protects the entire inner IP packet, including the entire inner IP protects the entire inner IP packet, including the entire inner IP
header. The position of ESP in tunnel mode, relative to the outer header. The position of ESP in tunnel mode, relative to the outer
IP header, is the same as for ESP in transport mode. IP header, is the same as for ESP in transport mode.
Issues: Issues: N/A
See Also: Transform protocols, IPsec protocols, Authentication
N/A Header
See Also:
Transform protocols, IPsec protocols, Authentication Header
7.11. NAT Traversal (NAT-T) 7.11. NAT Traversal (NAT-T)
Definition: Definition: The capability to support IPsec functionality in the
presence of NAT devices.
The capability to support IPsec functionality in the presence of
NAT devices.
Discussion:
NAT-Traversal requires some modifications to IKE as defined in Discussion: NAT-Traversal requires some modifications to IKE as
[RFC3947]. Specifically, in phase 1, it requires detecting if the defined in [RFC3947]. Specifically, in phase 1, it requires
other end supports NAT-Traversal, and detecting if there are one detecting if the other end supports NAT-Traversal, and detecting
or more NAT instances along the path from host to host. In IKE if there are one or more NAT instances along the path from host to
Quick Mode, there is a need to negotiate the use of UDP host. In IKE Quick Mode, there is a need to negotiate the use of
encapsulated IPsec packets. UDP encapsulated IPsec packets.
NAT-T also describes how to transmit the original source and NAT-T also describes how to transmit the original source and
destination addresses to the corresponding IPsec Device. The destination addresses to the corresponding IPsec Device. The
original source and destination addresses are used in transport original source and destination addresses are used in transport
mode to incrementally update the TCP/IP checksums so that they mode to incrementally update the TCP/IP checksums so that they
will match after the NAT transform (The NAT cannot do this, will match after the NAT transform (The NAT cannot do this,
because the TCP/IP checksum is inside the UDP encapsulated IPsec because the TCP/IP checksum is inside the UDP encapsulated IPsec
packet). packet).
Issues: Issues: N/A
N/A
See Also:
IKE, ISAKMP, IPsec Device See Also: IKE, ISAKMP, IPsec Device
7.12. IP Compression 7.12. IP Compression
Definition: Definition: A mechanism as defined in [RFC2393] that reduces the
size of the payload that needs to be encrypted.
A mechanism as defined in [RFC2393] that reduces the size of the
payload that needs to be encrypted.
Discussion:
IP payload compression is a protocol to reduce the size of IP Discussion: IP payload compression is a protocol to reduce the size
datagrams. This protocol will increase the overall communication of IP datagrams. This protocol will increase the overall
performance between a pair of communicating hosts/gateways communication performance between a pair of communicating hosts/
("nodes") by compressing the datagrams, provided the nodes have gateways ("nodes") by compressing the datagrams, provided the
sufficient computation power, through either CPU capacity or a nodes have sufficient computation power, through either CPU
compression coprocessor, and the communication is over slow or capacity or a compression coprocessor, and the communication is
congested links. over slow or congested links.
IP payload compression is especially useful when encryption is IP payload compression is especially useful when encryption is
applied to IP datagrams. Encrypting the IP datagram causes the applied to IP datagrams. Encrypting the IP datagram causes the
data to be random in nature, rendering compression at lower data to be random in nature, rendering compression at lower
protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) protocol layers (e.g., PPP Compression Control Protocol [RFC1962])
ineffective. If both compression and encryption are required, ineffective. If both compression and encryption are required,
compression must be applied before encryption. compression must be applied before encryption.
Issues: Issues: N/A
N/A
See Also:
IKE, ISAKMP, IPsec Device See Also: IKE, ISAKMP, IPsec Device
7.13. Security Context 7.13. Security Context
Definition: Definition: A security context is a collection of security
parameters that describe the characteristics of the path that an
A security context is a collection of security parameters that IPsec Tunnel will take, all of the IPsec Tunnel parameters and the
describe the characteristics of the path that an IPsec Tunnel will effects it has on the underlying protected traffic. Security
take, all of the IPsec Tunnel parameters and the effects it has on Context encompasses protocol suite and security policy.
the underlying protected traffic. Security Context encompasses
protocol suite and security policy.
Discussion:
In order to fairly compare multiple IPsec devices it is imperative Discussion: In order to fairly compare multiple IPsec devices it is
that an accurate overview is given of all security parameters that imperative that an accurate overview is given of all security
were used to establish the IPsec Tunnels or manually created SAs parameters that were used to establish the IPsec Tunnels or
and to secure the traffic between protected networks. Security manually created SAs and to secure the traffic between protected
Context is not a metric; it is included to accurately reflect the networks. Security Context is not a metric; it is included to
test environment variables when reporting the methodology results. accurately reflect the test environment variables when reporting
To avoid listing too much information when reporting metrics, we the methodology results. To avoid listing too much information
have divided the security context into an IKE context and an IPsec when reporting metrics, we have divided the security context into
context. an 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 32, line 34 skipping to change at page 28, line 4
- DH-Group - DH-Group
- PFS used - PFS 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] * Keepalive or DPD values as defined in [I-D.ietf-ipsec-dpd]
* IP Compression [RFC2393] * IP Compression [RFC2393]
The IKE context MUST also list:
The IKE context MAY 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: Issues: A Security Context will be an important element in
describing the environment where protected traffic is traveling
A Security Context will be an important element in describing the through.
environment where protected traffic is traveling through.
See Also:
IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2, See Also: IPsec Protocols, Transform Protocols, IKE Phase 1, IKE
Selectors, IPsec Tunnel phase 2, Selectors, IPsec Tunnel
8. Framesizes 8. Framesizes
8.1. Layer3 clear framesize 8.1. Layer3 clear framesize
Definition: Definition: The total size of the unencrypted L3 PDU.
The total size of the unencrypted L3 PDU.
Discussion:
In relation to IPsec this is the size of the IP header and its Discussion: In relation to IPsec this is the size of the IP header
payload. It SHALL NOT include any encapsulations that MAY be and its payload. It SHALL NOT include any encapsulations that MAY
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: 46 bytes PDU = 20 bytes IP header + 26 bytes
payload. payload.
Measurement Units: 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.
Bytes 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)
Issues: Given robust header compression (ROHC), the minimum packet size is
derived as follows, e.g., for tunnel mode ESP:
N/A IPv6 40 bytes
IPsec 34 (ESP, 192-bit ICV)
-+
IPv6 |- 6 byte ROHC of tunnel and transport headers
TCP |
-+
total -----------------
80 bytes
See Also: This 80 bytes assumes that the TCP payload is 0 bytes; it may be 1
byte (e.g., data sent reliably but with "NAGLE" off). Similar
ROHC sizes result from UDP sources.
Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 Measurement Units: Bytes
Encrypted Framesize.
8.2. Layer3 encrypted framesize Issues: N/A
Definition: See Also: Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2
Encrypted Framesize.
The total size of the encrypted L3 PDU. 8.2. Layer3 encrypted framesize
Discussion: Definition: The total size of the encrypted L3 PDU.
The size of the IP packet and its payload after encapsulations MAY Discussion: The size of the IP packet and its payload after
be applied and the PDU is being processed by the transform. encapsulations MAY be applied and the PDU is being processed by
the transform.
For example, in IPv4, after a tunnel mode ESP 3DES/SHA1 transform For example, in IPv4, after a tunnel mode ESP 3DES/SHA1 transform
has been applied an unencrypted or clear layer3 framesize of 46 has been applied an unencrypted or clear layer3 framesize of 46
bytes Becomes 96 bytes: bytes Becomes 96 bytes:
20 bytes outer IP header (tunnel mode) 20 bytes outer IP 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
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: Measurement Units: Bytes
Bytes
Issues:
N/A
See Also: Issues: N/A
Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted See Also: Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2
Framesize. Encrypted Framesize.
9. Performance Metrics 9. Performance Metrics
9.1. IPsec Tunnels Per Second (TPS) 9.1. IPsec Tunnels Per Second (TPS)
Definition: Definition: The measurement unit for the IPsec Tunnel Setup Rate
tests. The rate at which IPsec Tunnels are established per
The measurement unit for the IPsec Tunnel Setup Rate tests. The second.
rate at which IPsec Tunnels are established per second.
Discussion:
According to [RFC2401] two IPsec Tunnels cannot be established
between the same gateways with the same selectors. This is to
prevent overlapping IPsec Tunnels. If overlapping IPsec Tunnels
are attempted, the error will cause the IPsec Tunnel setup time to
take longer than if the IPsec Tunnel setup was successful. For
this reason, a unique pair of selector sets are required for IPsec
Tunnel Setup Rate testing.
Issues:
A unique pair of selector sets are required for TPS testing. Discussion: According to [RFC2401] two IPsec Tunnels cannot be
established between the same gateways with the same selectors.
This is to prevent overlapping IPsec Tunnels. If overlapping
IPsec Tunnels are attempted, the error will cause the IPsec Tunnel
setup time to take longer than if the IPsec Tunnel setup was
successful. For this reason, a unique pair of selector sets are
required for IPsec Tunnel Setup Rate testing.
See Also: Issues: A unique pair of selector sets are required for TPS testing.
IPsec Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate, IKE See Also: IPsec Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate,
Setup Rate, IPsec Setup Rate IKE Setup Rate, IPsec Setup Rate
9.2. Tunnel Rekeys Per Seconds (TRPS) 9.2. Tunnel Rekeys Per Seconds (TRPS)
Definition: Definition: A metric that quantifies the number of IKE Phase 1 or
Phase 2 rekeys per seconds a DUT can correctly process.
A metric that quantifies the number of IKE Phase 1 or Phase 2
rekeys per seconds a DUT can correctly process.
Discussion:
This metric will be will be primary used with Tunnel Rekey Discussion: This metric will be will be primary used with Tunnel
behavior tests. Rekey behavior tests.
TRPS will provide a metric used to see system behavior under TRPS will provide a metric used to see system behavior under
stressful conditions where large volumes of SA's are being rekeyed stressful conditions where large volumes of SA's are being rekeyed
at the same time or in a short timespan. at the same time or in a short timespan.
Issues: Issues: N/A
N/A
See Also:
Tunnel Rekey Behavior, Phase 1 Rekey Rate, Phase 2 Rekey Rate See Also: Tunnel Rekey Behavior, Phase 1 Rekey Rate, Phase 2 Rekey
Rate
9.3. IPsec Tunnel Attempts Per Second (TAPS) 9.3. IPsec Tunnel Attempts Per Second (TAPS)
Definition: Definition: A metric that quantifies the number of successful and
unsuccessful IPsec Tunnel establishment requests per second.
A metric that quantifies the number of successful and unsuccessful
IPsec Tunnel establishment requests per second.
Discussion:
This metric can be used to measure IKE DOS Resilience behavior Discussion: This metric can be used to measure IKE DOS Resilience
test. behavior test.
TAPS provides an important metric to validate the stability of an TAPS provides an important metric to validate the stability of an
IPsec device, if stressed with valid (large number of IPsec tunnel IPsec device, if stressed with valid (large number of IPsec tunnel
establishments per seconds or TPS) or invalid (IKE DOS attacks of establishments per seconds or TPS) or invalid (IKE DOS attacks of
any style) tunnel establishment requests. IPsec Tunnel setups any style) tunnel establishment requests. IPsec Tunnel setups
offered to an IPsec devices can either fail due to lack of offered to an IPsec devices can either fail due to lack of
resources in the IPsec device to process all the requests or due resources in the IPsec device to process all the requests or due
to an IKE DOS attack (usually the former is a result of the to an IKE DOS attack (usually the former is a result of the
latter). latter).
Issues: Issues: If the TAPS increases, the TPS usually decreases, due to
burdening of the DUT with the DOS attack traffic.
If the TAPS increases, the TPS usually decreases, due to 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. IKE SA Capacity
Definition: Definition: The maximum number of IKE SA's that can be sustained on
an IPsec Device.
The maximum number of IKE SA's that can be sustained on an IPsec
Device.
Discussion:
This metric will represent the quantity of peer a given IPsec
device can establish. It is the maximum number of Active Tunnels
that can be sustained by an IPsec Device.
Measurement Units:
IKE SA's
Issues: Discussion: This metric will represent the quantity of peer a given
IPsec device can establish. It is the maximum number of Active
Tunnels that can be sustained by an IPsec Device.
N/A Measurement Units: IKE SA's
See Also: Issues: N/A
IPsec SA Capacity See Also: IPsec SA Capacity
10.1.2. IPsec SA Capacity 10.1.2. IPsec SA Capacity
Definition: Definition: The maximum number of IPsec SA's that can be sustained
on an IPsec Device.
The maximum number of IPsec SA's that can be sustained on an IPsec
Device.
Discussion:
This metric will represent the quantity of traffic flows a given
IPsec Device can protect. In contrast with the IKE SA Capacity,
the emphasis for this test lies on the number of IPsec SA's that
can be established in the worst case scenario. 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 that can be
sustained by an IPsec Device where only 1 IKE SA is used to
exchange keying material.
Measurement Units:
IPsec SA's
Issues: Discussion: This metric will represent the quantity of traffic flows
a given IPsec Device can protect. In contrast with the IKE SA
Capacity, the emphasis for this test lies on the number of IPsec
SA's that can be established in the worst case scenario. 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
that can be sustained by an IPsec Device where only 1 IKE SA is
used to exchange keying material.
N/A Measurement Units: IPsec SA's
See Also: Issues: N/A
IKE SA Capacity See Also: IKE SA Capacity
10.2. Throughput 10.2. Throughput
10.2.1. IPsec Throughput 10.2.1. IPsec Throughput
Definition: Definition: The maximum rate through an Active Tunnel at which none
of the offered frames are dropped by the device under test.
The maximum rate through an Active Tunnel at which none of the
offered frames are dropped by the device under test.
Discussion:
The IPsec Throughput is almost identically defined as Throughput Discussion: The IPsec Throughput is almost identically defined as
in [RFC1242], section 3.17. The only difference is that the Throughput in [RFC1242], section 3.17. The only difference is
throughput is measured with a traffic flow getting encrypted and that the throughput is measured with a traffic flow getting
decrypted by an IPsec device. IPsec Throughput is an end-to-end encrypted and decrypted by an IPsec device. IPsec Throughput is
measurement. an end-to-end measurement.
The metric can be represented in two variantions depending on The metric can be represented in two variantions depending on
where measurement is taken in the SUT. One can look at throughput where measurement is taken in the SUT. One can look at throughput
from a cleartext point of view i.e. find the maximum rate where from a cleartext point of view i.e. find the maximum rate where
clearpackets no longer get dropped. This resulting rate can be clearpackets no longer get dropped. This resulting rate can be
recalculated with an encrypted framesize to represent the recalculated with an encrypted framesize to represent the
encryption throughput rate. The latter is the preferred method of encryption throughput rate. The latter is the preferred method of
representation and shall be called the IPsec Throughput. representation and shall be called the IPsec Throughput.
Measurement Units: Measurement Units: Packets per seconds (pps)
Packets per seconds (pps)
Issues:
N/A
See Also: Issues: N/A
IPsec Encryption Throughput, IPsec Decryption Throughput See Also: IPsec Encryption Throughput, IPsec Decryption Throughput
10.2.2. IPsec Encryption Throughput 10.2.2. IPsec Encryption Throughput
Definition: Definition: The maximum encryption rate through an Active Tunnel at
which none of the offered cleartext frames are dropped by the
The maximum encryption rate through an Active Tunnel at which none device under test.
of the offered cleartext frames are dropped by the device under
test.
Discussion:
Since encryption throughput is not necessarily equal to the Discussion: Since encryption throughput is not necessarily equal to
decryption throughput, both of the forwarding rates must be the decryption throughput, both of the forwarding rates must be
measured independently. The independent forwarding rates have to measured independently. The independent forwarding rates have to
measured with the help of an IPsec aware test device that can measured with the help of an IPsec aware test device that can
originate and terminate IPsec and IKE SA. As defined in originate and terminate IPsec and IKE SA. As defined in
[RFC1242], measurements should be taken with an assortment of [RFC1242], measurements should be taken with an assortment of
frame sizes. frame sizes.
Measurement Units: Measurement Units: Packets per seconds (pps)
Packets per seconds (pps)
Issues:
In some cases packets are offered to an IPsec Device that have a Issues: In some cases packets are offered to an IPsec Device that
framesize that is larger then the MTU of the ingress interface of have a framesize that is larger then the MTU of the ingress
the IPsec Tunnel that is transporting the packet. In this case interface of the IPsec Tunnel that is transporting the packet. In
fragmentation will be required before IPsec services are applied. this case fragmentation will be required before IPsec services are
applied.
In other cases, the packet is of a size very close to the MTU of In other cases, the packet is of a size very close to the MTU of
the egress interface of the IPsec Tunnel. Here, the mere addition the egress interface of the IPsec Tunnel. Here, the mere addition
of the IPsec header will create enough overhead to make the IPsec of the IPsec header will create enough overhead to make the IPsec
packet larger then the MTU of the egress interface. In such packet larger then the MTU of the egress interface. In such
instance, the original payload packet must be fragmented either instance, the original payload packet must be fragmented either
before or after the IPsec overhead is applied. before or after the IPsec overhead is applied.
Note that the two aforementioned scenario's can happen Note that the two aforementioned scenario's can happen
simultaniously on a single packet, creating multiple small simultaniously on a single packet, creating multiple small
skipping to change at page 39, line 26 skipping to change at page 34, line 8
When measuring the IPsec Encryption Throughput, one has to When measuring the IPsec Encryption Throughput, one has to
consider that when probing with packets of a size near MTU's consider that when probing with packets of a size near MTU's
associated with the IPsec Tunnel, fragmentation may accor and the associated with the IPsec Tunnel, fragmentation may accor and the
decrypting IPsec Device (either a tester or a corresponding IPsec decrypting IPsec Device (either a tester or a corresponding IPsec
peer) has to reassemble the IPsec and/or payload fragments to peer) has to reassemble the IPsec and/or payload fragments to
validate its content. validate its content.
The end points (i.e. hosts, subnets) should NOT see any fragments The end points (i.e. hosts, subnets) should NOT see any fragments
at ANY time. Only on the IPsec link, fragments MAY occur. at ANY time. Only on the IPsec link, fragments MAY occur.
See Also: See Also: IPsec Throughput, IPsec Decryption Throughput
IPsec Throughput, IPsec Decryption Throughput
10.2.3. IPsec Decryption Throughput 10.2.3. IPsec Decryption Throughput
Definition: Definition: The maximum decryption rate through an Active Tunnel at
which none of the offered encrypted frames are dropped by the
The maximum decryption rate through an Active Tunnel at which none device under test.
of the offered encrypted frames are dropped by the device under
test.
Discussion:
Since encryption throughput is not necessarily equal to the Discussion: Since encryption throughput is not necessarily equal to
decryption throughput, both of the forwarding rates must be the decryption throughput, both of the forwarding rates must be
measured independently. measured independently.
The independent forwarding rates have to be measured with the help The independent forwarding rates have to be measured with the help
of an IPsec aware test device that can originate and terminate of an IPsec aware test device that can originate and terminate
IPsec and IKE SA. As defined in [RFC1242], measurements should be IPsec and IKE SA. As defined in [RFC1242], measurements should be
taken with an assortment of frame sizes. taken with an assortment of frame sizes.
Measurement Units: Measurement Units: Packets per seconds (pps)
Packets per seconds (pps)
Issues:
When measuring the IPsec Decryption Throughput, one has to Issues: When measuring the IPsec Decryption Throughput, one has to
consider that it is likely that the encrypting IPsec Device has to consider that it is likely that the encrypting IPsec Device has to
fragment certain packets that have a frame size near MTU's fragment certain packets that have a frame size near MTU's
associated with the IPsec Tunnel. associated with the IPsec Tunnel.
The decrypting IPsec Device has to reassemble the IPsec and/or The decrypting IPsec Device has to reassemble the IPsec and/or
payload fragments to validate its content. payload fragments to validate its content.
The end points (i.e. hosts, subnets) should NOT see any fragments The end points (i.e. hosts, subnets) should NOT see any fragments
at ANY time. Only on the IPsec link, fragments MAY occur. at ANY time. Only on the IPsec link, fragments MAY occur.
See Also: See Also: IPsec Throughput, IPsec Encryption Throughput
IPsec Throughput, IPsec Encryption Throughput
10.3. Latency 10.3. Latency
10.3.1. IPsec Latency 10.3.1. IPsec Latency
Definition: Definition: Time required to propagate a cleartext frame from the
input interface of an initiator, through an Active Tunnel, to the
Time required to propagate a cleartext frame from the input output interface of the responder.
interface of an initiator, through an Active Tunnel, to the output
interface of the responder.
Discussion:
The IPsec Latency is the time interval starting when the end of
the first bit of the cleartext frame reaches the input interface
of the initiator and ending when the start of the first bit of the
same cleartext frame is detected on the output interface of the
responder. The frame has passed through an Active Tunnel between
an initiator and a responder and has been through an encryption
and decryption cycle.
Measurement Units:
Time units with enough precision to reflect latency measurement.
Issues: Discussion: The IPsec Latency is the time interval starting when the
end of the first bit of the cleartext frame reaches the input
interface of the initiator and ending when the start of the first
bit of the same cleartext frame is detected on the output
interface of the responder. The frame has passed through an
Active Tunnel between an initiator and a responder and has been
through an encryption and decryption cycle.
N/A Measurement Units: Time units with enough precision to reflect
latency measurement.
See Also: Issues: N/A
IPsec Encryption Latency, IPsec Decryption Latency See Also: IPsec Encryption Latency, IPsec Decryption Latency
10.3.2. IPsec Encryption Latency 10.3.2. IPsec Encryption Latency
Definition: Definition: The IPsec Encryption Latency is the time interval
starting when the end of the first bit of the cleartext frame
The IPsec Encryption Latency is the time interval starting when reaches the input interface, through an Active Tunnel, and ending
the end of the first bit of the cleartext frame reaches the input when the start of the first bit of the encrypted output frame is
interface, through an Active Tunnel, and ending when the start of seen on the output interface.
the first bit of the encrypted output frame is seen on the output
interface.
Discussion:
IPsec Encryption Latency is the latency introduced when encrypting Discussion: IPsec Encryption Latency is the latency introduced when
traffic through an IPsec tunnel. encrypting traffic through an IPsec tunnel.
Like encryption/decryption throughput, it is not always the case Like encryption/decryption throughput, it is not always the case
that encryption latency equals the decryption latency. Therefore that encryption latency equals the decryption latency. Therefore
a distinction between the two has to be made in order to get a a distinction between the two has to be made in order to get a
more accurate view of where the latency is the most pronounced. more accurate view of where the latency is the most pronounced.
The independent encryption/decryption latencies have to be The independent encryption/decryption latencies have to be
measured with the help of an IPsec aware test device that can measured with the help of an IPsec aware test device that can
originate and terminate IPsec and IKE SA. As defined in originate and terminate IPsec and IKE SA. As defined in
[RFC1242], measurements should be taken with an assortment of [RFC1242], measurements should be taken with an assortment of
frame sizes. frame sizes.
Measurement Units: Measurement Units: Time units with enough precision to reflect
latency measurement.
Time units with enough precision to reflect latency measurement.
Issues:
N/A
See Also: Issues: N/A
IPsec Latency, IPsec Decryption Latency See Also: IPsec Latency, IPsec Decryption Latency
10.3.3. IPsec Decryption Latency 10.3.3. IPsec Decryption Latency
Definition:
The IPsec decryption Latency is the time interval starting when Definition: The IPsec decryption Latency is the time interval
the end of the first bit of the encrypted frame reaches the input starting when the end of the first bit of the encrypted frame
interface, through an Active Tunnel, and ending when the start of reaches the input interface, through an Active Tunnel, and ending
the first bit of the decrypted output frame is seen on the output when the start of the first bit of the decrypted output frame is
interface. seen on the output interface.
Discussion:
IPsec Decryption Latency is the latency introduced when decrypting Discussion: IPsec Decryption Latency is the latency introduced when
traffic through an Active Tunnel. Like encryption/decryption decrypting traffic through an Active Tunnel. Like encryption/
throughput, it is not always the case that encryption latency decryption throughput, it is not always the case that encryption
equals the decryption latency. Therefore a distinction between latency equals the decryption latency. Therefore a distinction
the two has to be made in order to get a more accurate view of between the two has to be made in order to get a more accurate
where the latency is the most pronounced. view of where the latency is the most pronounced.
The independent encryption/decryption latencies have to be The independent encryption/decryption latencies have to be
measured with the help of an IPsec aware test device that can measured with the help of an IPsec aware test device that can
originate and terminate IPsec and IKE SA's. As defined in originate and terminate IPsec and IKE SA's. As defined in
[RFC1242], measurements should be taken with an assortment of [RFC1242], measurements should be taken with an assortment of
frame sizes. frame sizes.
Measurement Units: Measurement Units: Time units with enough precision to reflect
latency measurement.
Time units with enough precision to reflect latency measurement.
Issues:
N/A
See Also: Issues: N/A
IPsec Latency, IPsec Encryption Latency See Also: IPsec Latency, IPsec Encryption Latency
10.3.4. Time To First Packet 10.3.4. Time To First Packet
Definition: Definition: The Time To First Packet (TTFP) is the time required to
process a cleartext packet from a traffic stream that requires
The Time To First Packet (TTFP) is the time required to process a encryption services when no IPsec Tunnel is present.
cleartext packet from a traffic stream that requires encryption
services when no IPsec Tunnel is present.
Discussion:
The Time To First Packet addresses the issue of responsiveness of Discussion: The Time To First Packet addresses the issue of
an IPsec device by looking how long it takes to transmit a packet responsiveness of an IPsec device by looking how long it takes to
over Configured Tunnel. The Time To First Packet MUST include the transmit a packet over Configured Tunnel. The Time To First
time to set up the established tunnel, triggered by the traffic Packet MUST include the time to set up the established tunnel,
flow (both phase 1 and phase 2 setup times SHALL be included) and triggered by the traffic flow (both phase 1 and phase 2 setup
the time it takes to encrypt and decrypt the packet on a times SHALL be included) and the time it takes to encrypt and
corresponding peer. In short it is the IPsec Tunnel setup time decrypt the packet on a corresponding peer. In short it is the
plus the propagation delay of the packet through the Active IPsec Tunnel setup time plus the propagation delay of the packet
Tunnel. through the Active Tunnel.
It must be noted that it is highly unlikely that the first packet It must be noted that it is highly unlikely that the first packet
of the traffic flow will be the packet that will be used to of the traffic flow will be the packet that will be used to
measure the TTFP. There MAY be several protocol layers in the measure the TTFP. There MAY be several protocol layers in the
stack before the tunnel is formed and the traffic is forwarded, stack before the tunnel is formed and the traffic is forwarded,
hence several packets COULD be lost during negotiation, for hence several packets COULD be lost during negotiation, for
example, ARP and/or IKE. example, ARP and/or IKE.
Measurement Units: Measurement Units: Time units with enough precision to reflect a
TTFP measurement.
Time units with enough precision to reflect a TTFP measurement.
Issues:
Only relevant when using IKE for tunnel negotiation. Issues: Only relevant when using IKE for tunnel negotiation.
10.4. Frame Loss 10.4. Frame Loss
10.4.1. IPsec Frame Loss 10.4.1. IPsec Frame Loss
Definition: Definition: Percentage of cleartext frames that should have been
forwarded through an Active Tunnel under steady state (constant)
Percentage of cleartext frames that should have been forwarded load but were dropped before encryption or after decryption.
through an Active Tunnel under steady state (constant) load but
were dropped before encryption or after decryption.
Discussion:
The IPsec Frame Loss is almost identically defined as Frame Loss
Rate in [RFC1242], section 3.6. The only difference is that the
IPsec Frame Loss is measured with a traffic flow getting encrypted
and decrypted by an IPsec Device. IPsec Frame Loss is an end-to-
end measurement.
Measurement Units:
Percent (%)
Issues: Discussion: The IPsec Frame Loss is almost identically defined as
Frame Loss Rate in [RFC1242], section 3.6. The only difference is
that the IPsec Frame Loss is measured with a traffic flow getting
encrypted and decrypted by an IPsec Device. IPsec Frame Loss is
an end-to-end measurement.
N/A Measurement Units: Percent (%)
See Also: Issues: N/A
IPsec Encryption Frame Loss, IPsec Decryption Frame Loss See Also: IPsec Encryption Frame Loss, IPsec Decryption Frame Loss
10.4.2. IPsec Encryption Frame Loss 10.4.2. IPsec Encryption Frame Loss
Definition: Definition: Percentage of cleartext frames that should have been
encrypted through an Active Tunnel under steady state (constant)
Percentage of cleartext frames that should have been encrypted load but were dropped.
through an Active Tunnel under steady state (constant) load but
were dropped.
Discussion:
A DUT will always have an inherent forwarding limitation. This
will be more pronounced when IPsec is employed on the DUT. There
is a possibility that the offered traffic rate at the Active
Tunnel is too high to be transported through the Active Tunnel and
not all cleartext packets will get encrypted. In that case, some
percentage of the cleartext traffic will be dropped. This drop
percentage is called the IPsec Encryption Frame Loss.
Measurement Units:
Percent (%)
Issues: Discussion: A DUT will always have an inherent forwarding
limitation. This will be more pronounced when IPsec is employed
on the DUT. There is a possibility that the offered traffic rate
at the Active Tunnel is too high to be transported through the
Active Tunnel and not all cleartext packets will get encrypted.
In that case, some percentage of the cleartext traffic will be
dropped. This drop percentage is called the IPsec Encryption
Frame Loss.
N/A Measurement Units: Percent (%)
See Also: Issues: N/A
IPsec Frame Loss, IPsec Decryption Frame Loss See Also: IPsec Frame Loss, IPsec Decryption Frame Loss
10.4.3. IPsec Decryption Frame Loss 10.4.3. IPsec Decryption Frame Loss
Definition: Percentage of encrypted frames that should have been
decrypted through an Active Tunnel under steady state (constant)
load but were dropped.
Definition: Discussion: A DUT will also have an inherent forwarding limitation
when decrypting packets. When Active Tunnel encrypted traffic is
Percentage of encrypted frames that should have been decrypted
through an Active Tunnel under steady state (constant) load but
were dropped.
Discussion:
A DUT will also have an inherent forwarding limitation when
decrypting packets. When Active Tunnel encrypted traffic is
offered at a costant load, there might be a possibility that the offered at a costant load, there might be a possibility that the
IPsec Device that needs to decrypt the traffic will not be able to IPsec Device that needs to decrypt the traffic will not be able to
perfom this action on all of the packets due to limitations of the perfom this action on all of the packets due to limitations of the
decryption performance. The percentage of encrypted frames that decryption performance. The percentage of encrypted frames that
would get dropped under these conditions is called the IPsec would get dropped under these conditions is called the IPsec
Decryption Frame Loss. Decryption Frame Loss.
Measurement Units: Measurement Units: Percent (%)
Percent (%)
Issues:
N/A
See Also: Issues: N/A
IPsec Frame Loss, IPsec Encryption Frame Loss See Also: IPsec Frame Loss, IPsec Encryption Frame Loss
10.4.4. IKE Phase 2 Rekey Frame Loss 10.4.4. IKE Phase 2 Rekey Frame Loss
Definition: Definition: Number of frames dropped as a result of an inefficient
IKE Phase 2 rekey.
Number of frames dropped as a result of an inefficient IKE Phase 2
rekey.
Discussion:
Normal operation of an IPsec Device would require that a rekey Discussion: Normal operation of an IPsec Device would require that a
does not create temporary IPsec Frame Loss of a traffic stream rekey does not create temporary IPsec Frame Loss of a traffic
that is protected by the IKE Phase 2 SA's (i.e. IPsec SA's). stream that is protected by the IKE Phase 2 SA's (i.e. IPsec
Nevertheless there can be situations where IPsec Frame Loss occurs SA's). Nevertheless there can be situations where IPsec Frame
during this rekey process. Loss occurs during this rekey process.
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: Measurement Units: Number of N-octet frames
Number of N-octet frames
Issues:
N/A
See Also: Issues: N/A
IKE Phase 2 Rekey Rate See Also: IKE Phase 2 Rekey Rate
10.5. Back-to-back Frames 10.5. Back-to-back Frames
10.5.1. IPsec Back-to-back Frames 10.5.1. IPsec Back-to-back Frames
Definition: Definition: A burst of cleartext frames, offered at a constant load
that can be sent through an Active Tunnel without losing a single
A burst of cleartext frames, offered at a constant load that can cleartext frame after decryption.
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: 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.
Recommended test frame sizes will be addressed in methodology Measurement Units: Number of N-octet frames in burst.
document.
See Also: Issues: Recommended test frame sizes will be addressed in
methodology document.
IPsec Encryption Back-to-back frames, IPsec Decryption Back-to- See Also: IPsec Encryption Back-to-back frames, IPsec Decryption
back frames Back-to-back frames
10.5.2. IPsec Encryption Back-to-back Frames 10.5.2. IPsec Encryption Back-to-back Frames
Definition: Definition: A burst of cleartext frames, offered at a constant load
that can be sent through an Active Tunnel without losing a single
A burst of cleartext frames, offered at a constant load that can encrypted frame.
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 Discussion: IPsec Encryption back-to-back frames is the measure of
burst size that an IPsec Device can handle for encrypting traffic the maximum burst size that an IPsec Device can handle for
that it receives as plaintext. Since it is not necessarily the encrypting traffic that it receives as plaintext. Since it is not
case that the maximum burst size a DUT can handle for encryption necessarily the case that the maximum burst size a DUT can handle
is equal to the maximum burst size a DUT can handle for for encryption is equal to the maximum burst size a DUT can handle
decryption, both of these capabilities must be measured for decryption, both of these capabilities must be measured
independently. The IPsec Encryption Back-to-back frame independently. The IPsec Encryption Back-to-back frame
measurement has to be measured with the help of an IPsec aware measurement has to be measured with the help of an IPsec aware
test device that can decrypt the traffic to determine the validity test device that can decrypt the traffic to determine the validity
of the encrypted frames. of the encrypted frames.
Measurement Units: Measurement Units: Number of N-octet frames in burst.
Number of N-octet frames in burst.
Issues:
Recommended test frame sizes will be addressed in future Issues: Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also: IPsec Back-to-back frames, IPsec Decryption Back-to-back
frames
IPsec Back-to-back frames, IPsec Decryption Back-to-back frames
10.5.3. IPsec Decryption Back-to-back Frames 10.5.3. IPsec Decryption Back-to-back Frames
Definition: Definition: The number of encrypted frames, offered at a constant
load, that can be sent through an Active Tunnel without losing a
The number of encrypted frames, offered at a constant load, that single cleartext frame.
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 Discussion: IPsec Decryption Back-to-back frames is the measure of
burst size that an IPsec Device can handle for decrypting traffic the maximum burst size that an IPsec Device can handle for
that it receives as encrypted traffic. Since it is not decrypting traffic that it receives as encrypted traffic. Since
necessarily the case that the maximum burst size a DUT can handle it is not necessarily the case that the maximum burst size a DUT
for decryption is equal to the maximum burst size a DUT can handle can handle for decryption is equal to the maximum burst size a DUT
for encryption, both of these capabilities must be measured can handle for encryption, both of these capabilities must be
independently. The IPsec Decryption Back-to-back frame measured independently. The IPsec Decryption Back-to-back frame
measurement has to be measured with the help of an IPsec aware measurement has to be measured with the help of an IPsec aware
test device that can determine the validity of the decrypted test device that can determine the validity of the decrypted
frames. frames.
Measurement Units: Measurement Units: Number of N-octet frames in burst.
Number of N-octet frames in burst.
Issues:
Recommended test frame sizes will be addressed in methodology
document.
See Also: Issues: Recommended test frame sizes will be addressed in
methodology document.
IPsec Back-to-back frames, IPsec Encryption back-to-back frames See Also: IPsec Back-to-back frames, IPsec Encryption back-to-back
frames
10.6. Tunnel Setup Behavior 10.6. Tunnel Setup Behavior
10.6.1. IPsec Tunnel Setup Rate 10.6.1. IPsec Tunnel Setup Rate
Definition: Definition: The maximum number of IPsec Tunnels per second that an
IPsec Device can successfully establish.
The maximum number of IPsec Tunnels per second that an IPsec
Device can successfully establish.
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 DUT.
Several factors may influence Tunnel Setup Rate, such as: TAPS
rate, Background cleartext traffic load on the secure interface,
Already established IPsec Tunnels, Authentication method such as
pre-shared keys, RSA-encryption, RSA-signature, DSS Key sizes used
(when using RSA/DSS).
Measurement Units:
Tunnels Per Second (TPS)
Issues: 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
DUT. Several factors may influence Tunnel Setup Rate, such as:
TAPS rate, Background cleartext traffic load on the secure
interface, Already established IPsec Tunnels, Authentication
method such as pre-shared keys, RSA-encryption, RSA-signature, DSS
Key sizes used (when using RSA/DSS).
N/A Measurement Units: Tunnels Per Second (TPS)
See Also: Issues: N/A
IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec Tunnel Rekey See Also: IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec
Behavior Tunnel Rekey Behavior
10.6.2. IKE Phase 1 Setup Rate 10.6.2. IKE Phase 1 Setup Rate
Definition: Definition: The maximum number of sucessful IKE Phase 1 SA's per
second that an IPsec Device can establish.
The maximum number of sucessful IKE Phase 1 SA's per second that
an IPsec Device can establish.
Discussion:
The Phase 1 Setup Rate is a portion of the IPsec Tunnel Setup Discussion: The Phase 1 Setup Rate is a portion of the IPsec Tunnel
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: Measurement Units: Tunnels Per Second (TPS)
Tunnels Per Second (TPS)
Issues:
N/A
See Also: Issues: N/A
IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec Tunnel See Also: IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec
Rekey Behavior Tunnel Rekey Behavior
10.6.3. IKE Phase 2 Setup Rate 10.6.3. IKE Phase 2 Setup Rate
Definition: Definition: The maximum number of successfully IKE Phase 2 SA's per
second that an IPsec Device can Only relevant when using IKE
The maximum number of successfully IKE Phase 2 SA's per second establish.
that an IPsec Device can Only relevant when using IKE establish.
Discussion:
The IKE Phase 2 Setup Rate is a portion of the IPsec Tunnel Setup Discussion: The IKE Phase 2 Setup Rate is a portion of the IPsec
Rate. For identical reasons why it is required to quantify the Tunnel Setup Rate. For identical reasons why it is required to
IKE Phase 1 Setup Rate, it is a good practice to know the quantify the IKE Phase 1 Setup Rate, it is a good practice to know
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.
Measurement Units: Measurement Units: Tunnels Per Second (TPS)
Tunnels Per Second (TPS)
Issues:
N/A
See Also: Issues: N/A
IPsec Tunnel Setup Rate, IKE Phase 1 Setup Rate, IPsec Tunnel See Also: IPsec Tunnel Setup Rate, IKE Phase 1 Setup Rate, IPsec
Rekey Behavior Tunnel Rekey Behavior
10.7. IPsec Tunnel Rekey Behavior 10.7. IPsec Tunnel Rekey Behavior
10.7.1. IKE Phase 1 Rekey Rate 10.7.1. IKE Phase 1 Rekey Rate
Definition: Definition: The number of IKE Phase 1 SA's that can be succesfully
re-establish per second.
The number of IKE Phase 1 SA's that can be succesfully re-
establish per second.
Discussion:
Although the IKE Phase 1 Rekey Rate has less impact on the Discussion: Although the IKE Phase 1 Rekey Rate has less impact on
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: Measurement Units: Tunnel Rekeys per second (TRPS)
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.7.2. IKE Phase 2 Rekey Rate
Definition: Definition: The number of IKE Phase 2 SA's that can be succesfully
re-negotiated per second.
The number of IKE Phase 2 SA's that can be succesfully re-
negotiated per second.
Discussion:
Although many implementations will usually derive new keying Discussion: Although many implementations will usually derive new
material before the old keys expire, there may still be a period keying material before the old keys expire, there may still be a
of time where frames get dropped before the IKE Phase 2 tunnels period of time where frames get dropped before the IKE Phase 2
are successfully re-established. There may also be some packet tunnels are successfully re-established. There may also be some
loss introduced when the handover of traffic is done from the packet loss introduced when the handover of traffic is done from
expired IPsec SA's to the newly negotiated IPsec SA's. To measure the expired IPsec SA's to the newly negotiated IPsec SA's. To
the IKE Phase 2 rekey rate, the measurement will require an IPsec measure the IKE Phase 2 rekey rate, the measurement will require
aware test device to act as a responder when negotiating the new an IPsec aware test device to act as a responder when negotiating
IKE Phase 2 keying material. the new IKE Phase 2 keying material.
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: Measurement Units: Tunnel Rekeys per second (TRPS)
Tunnel Rekeys per second (TRPS)
Issues:
N/A
See Also: Issues: N/A
IKE Phase 1 Rekey Rate See Also: IKE Phase 1 Rekey Rate
10.8. IPsec Tunnel Failover Time 10.8. IPsec Tunnel Failover Time
Definition: Definition: Time required to recover all IPsec Tunnels on a stanby
IPsec Device, after a catastrophic failure occurs on the active
Time required to recover all IPsec Tunnels on a stanby IPsec IPsec Device.
Device, after a catastrophic failure occurs on the active IPsec
Device.
Discussion:
Recovery time required to re-establish all IPsec Tunnels and Discussion: Recovery time required to re-establish all IPsec Tunnels
reroute all traffic on a standby node or other failsafe system and reroute all traffic on a standby node or other failsafe system
after a failure has occurred in the DUT/SUT. Failure can include after a failure has occurred in the DUT/SUT. Failure can include
but are not limited to a catastrophic IPsec Device failure, a but are not limited to a catastrophic IPsec Device failure, a
encryption engine failure, link outage, etc ... . The recovery encryption engine failure, link outage, etc ... . The recovery
time is delta between the point of failure and the time the first time is delta between the point of failure and the time the first
packet is seen on the last restored IPsec Tunnel on the backup packet is seen on the last restored IPsec Tunnel on the backup
device. device.
Measurement Units: Measurement Units: Time units with enough precision to reflect IPsec
Tunnel Failover Time.
Time units with enough precision to reflect IPsec Tunnel Failover Issues: N/A
Time.
Issues: 10.9. DoS Attack Resiliency
N/A 10.9.1. Phase 1 DoS Resiliency Rate
Definition: The Phase 1 Denial of Service (DoS) Resilience Rate
quantifies the rate of invalid or malicious IKE tunnels that can
be directed at a DUT before the Responder stops accepting valid
tunnel attempts.
Discussion: Phase 1 DoS attacks can present themselves in various
forms and do not necessarily have to have a malicious background.
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
attempts that need to be turned down. Due to the intense
computational nature of an IKE exchange every single IKE tunnel
attempt that has to be denied will take non-negligible CPU cycles
in the IPsec Device.
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
CPU of doing key exchanges is high enough that the entire CPU is
consumed by this process. At this point it will be no longer
possible to process a valid IKE tunnel setup request and thus a
Phase 1 DoS Attack is in effect.
The scope of the attack profile for this test will include
mismatched pre-shared keys as well as invalid digital
certificates.
Measurement Units: Tunnel Attempts Per Seconds (TAPS)
Issues: N/A
10.9.2. Phase 2 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
without affecting the traffic flow of valid ESP/AH packets.
Discussion: Phase 2 DoS attacks can present themselves in various
forms and do not necessarily have to have a malicious background,
but usually are. A well know case where there is no malicious
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
invalid hash in the IPsec data packets.
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
IPsec Device becomes large enough that it will impact valid
traffic flows. At this point it will be no longer possible to
forward valid IPsec payload without packetloss and thus a Phase 2
DoS Attack is in effect.
Measurement Units: 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
their help and participation of the compilation and editing of this their participation of the compilation and editing of this document
document: Debby Stopp, Ixia. and guidance: Debby Stopp, Paul Hoffman, Sunil Kalidindi, Brian
Talbert.
13. Contributors
The authors would like to acknowledge the following individual for
their significant help, guidance, and contributions to this document:
Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI.
14. References 13. References
14.1. Normative References 13.1. Normative References
[RFC1242] Bradner, S., "Benchmarking terminology for network [RFC1242] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991. interconnection devices", RFC 1242, July 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998. Switching Devices", RFC 2285, February 1998.
skipping to change at page 54, line 29 skipping to change at page 46, line 24
RFC 2661, August 1999. RFC 2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe,
"Negotiation of NAT-Traversal in the IKE", RFC 3947, "Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 2005. January 2005.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005.
[I-D.ietf-ipsec-ikev2] [I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-17 (work in progress), draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004. October 2004.
[I-D.ietf-ipsec-dpd] [I-D.ietf-ipsec-dpd]
Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic- Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic-
Based Method of Detecting Dead IKE Peers", Based Method of Detecting Dead IKE Peers",
draft-ietf-ipsec-dpd-04 (work in progress), October 2003. draft-ietf-ipsec-dpd-04 (work in progress), October 2003.
[I-D.ietf-ipsec-properties] [I-D.ietf-ipsec-properties]
Krywaniuk, A., "Security Properties of the IPsec Protocol Krywaniuk, A., "Security Properties of the IPsec Protocol
Suite", draft-ietf-ipsec-properties-02 (work in progress), Suite", draft-ietf-ipsec-properties-02 (work in progress),
July 2002. July 2002.
[FIPS.186-1.1998] [FIPS.186-1.1998]
National Institute of Standards and Technology, "Digital National Institute of Standards and Technology, "Digital
Signature Standard", FIPS PUB 186-1, December 1998, Signature Standard", FIPS PUB 186-1, December 1998,
<http://csrc.nist.gov/fips/fips1861.pdf>. <http://csrc.nist.gov/fips/fips1861.pdf>.
14.2. Informative References 13.2. Informative References
[Designing Network Security] [Designing Network Security]
Kaeo, M., "Designing Network Security", ISBN: 1578700434, Kaeo, M., "Designing Network Security", ISBN: 1578700434,
Published: May 07, 1999; Copyright: 1999, 1999. Published: May 07, 1999; Copyright: 1999, 1999.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", from IEEE Proceedings of the Mechanism for Internet", from IEEE Proceedings of the
1996 Symposium on Network and Distributed Systems 1996 Symposium on Network and Distributed Systems
Security, Security,
URI http://www.research.ibm.com/security/skeme.ps, 1996. URI http://www.research.ibm.com/security/skeme.ps, 1996.
Authors' Addresses Authors' Addresses
Merike Kaeo Merike Kaeo
Double Shot Security Double Shot Security
520 Washington Blvd #363 3518 Fremont Ave N #363
Marina Del Rey, CA 90292 Seattle, WA 98103
US USA
Phone: +1 (310)866-0165 Phone: +1 (310)866-0165
Email: kaeo@merike.com Email: kaeo@merike.com
Tim Van Herck Tim Van Herck
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
US USA
Phone: +1(408)853-2284
Email: herckt@cisco.com Email: herckt@cisco.com
Michele Bustos Michele Bustos
IXIA IXIA
26601 W. Agoura Rd. 26601 W. Agoura Rd.
Calabasas, CA 91302 Calabasas, CA 91302
US USA
Phone: +1 (818)444-3244 Phone: +1 (818)444-3244
Email: mbustos@ixiacom.com Email: mbustos@ixiacom.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 57, line 29 skipping to change at page 48, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 295 change blocks. 
1231 lines changed or deleted 858 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/