draft-ietf-bmwg-ipsec-term-06.txt   draft-ietf-bmwg-ipsec-term-07.txt 
Benchmarking Working Group M. Bustos Benchmarking Working Group M. Kaeo
Internet-Draft IXIA Internet-Draft Double Shot Security
Expires: February 2, 2006 T. Van Herck Expires: May 5, 2006 T. Van Herck
Cisco Systems Cisco Systems
M. Kaeo M. Bustos
Double Shot Security IXIA
August 2005 November 2005
Terminology for Benchmarking IPsec Devices Terminology for Benchmarking IPsec Devices
draft-ietf-bmwg-ipsec-term-06 draft-ietf-bmwg-ipsec-term-07
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 February 2, 2006. This Internet-Draft will expire on May 5, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005).
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 . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . 4 2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 5
2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6 2.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 7
2.1.1 Security Associations . . . . . . . . . . . . . . . . 6 2.1.1. Security Associations . . . . . . . . . . . . . . . . 7
2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . 6 2.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 7
3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 8 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 9
4. Definition Format . . . . . . . . . . . . . . . . . . . . . 9 4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 10
5. Key Words to Reflect Requirements . . . . . . . . . . . . . 9 5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 10
6. Existing Benchmark Definitions . . . . . . . . . . . . . . . 9 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 11
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3.1 IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 12 7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 13
7.3.2 IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 13 7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 14
7.3.3 IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 13 7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 14
7.3.4 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 14 7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 15
7.3.5 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 14 7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 15
7.4 Security Association (SA) . . . . . . . . . . . . . . . . 15 7.4. Security Association (SA) . . . . . . . . . . . . . . . . 16
7.5 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 15 7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 16
7.6 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 16 7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 17
7.6.1 Initiator . . . . . . . . . . . . . . . . . . . . . . 17 7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 18
7.6.2 Responder . . . . . . . . . . . . . . . . . . . . . . 17 7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 18
7.6.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . 18 7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 19
7.6.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . 19 7.6.4. IPsec Server . . . . . . . . . . . . . . . . . . . . . 20
7.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.7.1 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 19 7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 20
7.7.2 Configured Tunnel . . . . . . . . . . . . . . . . . . 21 7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 21
7.7.3 Established Tunnel . . . . . . . . . . . . . . . . . . 22 7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 22
7.7.4 Active Tunnel . . . . . . . . . . . . . . . . . . . . 22 7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 22
7.8 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 23 7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 23
7.8.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . 23 7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 23
7.8.2 Transport Adjacency . . . . . . . . . . . . . . . . . 24 7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 24
7.9 Transform protocols . . . . . . . . . . . . . . . . . . . 25 7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 25
7.9.1 Authentication Protocols . . . . . . . . . . . . . . . 26 7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 25
7.9.2 Encryption Protocols . . . . . . . . . . . . . . . . . 26 7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 26
7.10 IPsec Protocols . . . . . . . . . . . . . . . . . . . . 27 7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 27
7.10.1 Authentication Header (AH) . . . . . . . . . . . . . 27 7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 27
7.10.2 Encapsulated Security Payload (ESP) . . . . . . . . 28 7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 28
7.11 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . 29 7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 29
7.12 IP Compression . . . . . . . . . . . . . . . . . . . . . 29 7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 30
7.13 Security Context . . . . . . . . . . . . . . . . . . . . 30 7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 30
8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 33
8.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32 8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 33
8.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33 8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33
8.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 34
8.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 34 9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 34
9. Performance Metrics . . . . . . . . . . . . . . . . . . . . 35 9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 35
9.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 35 9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 35
9.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 36 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 36
9.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 36 10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 36
10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . 37 10.1.1. IKE SA Capacity . . . . . . . . . . . . . . . . . . . 36
10.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . 37 10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 37
10.1.1 IPsec Tunnel Throughput . . . . . . . . . . . . . . 37 10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 37
10.1.2 IPsec Tunnel Encryption Throughput . . . . . . . . . 38 10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 37
10.1.3 IPsec Tunnel Decryption Throughput . . . . . . . . . 38 10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 38
10.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . 39 10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 38
10.2.1 IPsec Tunnel Latency . . . . . . . . . . . . . . . . 39 10.2.4. IPsec Fragmentation Throughput . . . . . . . . . . . . 39
10.2.2 IPsec Tunnel Encryption Latency . . . . . . . . . . 40 10.2.5. IPsec Reassembly Throughput . . . . . . . . . . . . . 40
10.2.3 IPsec Tunnel Decryption Latency . . . . . . . . . . 41 10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 40
10.2.4 Time To First Packet . . . . . . . . . . . . . . . . 41 10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 40
10.3 Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 42 10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 41
10.3.1 IPsec Tunnel Frame Loss . . . . . . . . . . . . . . 42 10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 42
10.3.2 IPsec Tunnel Encryption Frame Loss . . . . . . . . . 43 10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 42
10.3.3 IPsec Tunnel Decryption Frame Loss . . . . . . . . . 44 10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 43
10.3.4 Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . 44 10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 43
10.4 Back-to-back Frames . . . . . . . . . . . . . . . . . . 45 10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 44
10.4.1 IPsec Tunnel Back-to-back Frames . . . . . . . . . . 45 10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 44
10.4.2 IPsec Tunnel Encryption Back-to-back Frames . . . . 46 10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 45
10.4.3 IPsec Tunnel Decryption Back-to-back Frames . . . . 46 10.5. Back-to-back Frames . . . . . . . . . . . . . . . . . . . 46
10.5 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . 47 10.5.1. IPsec Back-to-back Frames . . . . . . . . . . . . . . 46
10.5.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . 47 10.5.2. IPsec Encryption Back-to-back Frames . . . . . . . . . 46
10.5.2 Phase 1 Setup Rate . . . . . . . . . . . . . . . . . 48 10.5.3. IPsec Decryption Back-to-back Frames . . . . . . . . . 47
10.5.3 Phase 2 Setup Rate . . . . . . . . . . . . . . . . . 48 10.6. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 48
10.6 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . 49 10.6.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 48
10.6.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . 49 10.6.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 49
10.6.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . 50 10.6.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 49
10.7 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . 51 10.7. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 50
10.8 IKE DOS Resilience Rate . . . . . . . . . . . . . . . . 51 10.7.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . . 52 10.7.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 51
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 10.8. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 51
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 11. Security Considerations . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 52
14.1 Normative References . . . . . . . . . . . . . . . . . . 52 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.2 Informative References . . . . . . . . . . . . . . . . . 55 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 14.1. Normative References . . . . . . . . . . . . . . . . . . . 52
Intellectual Property and Copyright Statements . . . . . . . 56 14.2. Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56
Intellectual Property and Copyright Statements . . . . . . . . . . 57
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
skipping to change at page 6, line 9 skipping to change at page 7, line 10
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 2.1. IPsec Operation
2.1.1 Security Associations 2.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 6, line 34 skipping to change at page 7, line 35
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 2.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 38 skipping to change at page 9, line 40
parameters. parameters.
3. Document Scope 3. Document Scope
The primary focus of this document is to establish useful performance The primary focus of this document is to establish useful performance
testing terminology for IPsec devices that support manual keying and testing terminology for IPsec devices that support manual keying and
IKEv1. We want to constrain the terminology specified in this IKEv1. We want to constrain the terminology specified in this
document to meet the requirements of the Methodology for Benchmarking document to meet the requirements of the Methodology for Benchmarking
IPsec Devices documented test methodologies. IPsec Devices documented test methodologies.
Both IPv4 and IPv6 addressing will be taken into consideration.
The testing will be constrained to: The testing will be constrained to:
o Devices acting as IPsec gateways whose tests will pertain to both o Devices acting as IPsec gateways whose tests will pertain to both
IPsec tunnel and transport mode. IPsec tunnel and transport mode.
o Devices acting as IPsec end-hosts whose tests will pertain to o Devices acting as IPsec end-hosts whose tests will pertain to both
IPsec transport mode. IPsec tunnel and transport mode.
Any testing involving interoperability and/or conformance issues, Any testing involving interoperability and/or conformance issues,
L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and
anything that does not specifically relate to the establishment and anything that does not specifically relate to the establishment and
tearing down of IPsec tunnels is specifically out of scope. It is tearing down of IPsec tunnels is specifically out of scope. It is
assumed that all relevant networking parameters that facilitate in assumed that all relevant networking parameters that facilitate in
the running of these tests are pre-configured (this includes at a the running of these tests are pre-configured (this includes at a
minimum ARP caches and routing tables). 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:
skipping to change at page 10, line 21 skipping to change at page 11, line 27
BMWG documents. Examples include, but are not limited to: BMWG documents. Examples include, but are not limited to:
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 IPsec or IP Security protocol suite which comprises a set of
standards used to provide security services at the IP layer. standards used to provide security services at the IP layer.
Discussion: Discussion:
IPsec is a framework of protocols that offer authentication, IPsec is a framework of protocols that offer authentication,
integrity and encryption services to the IP and/or upper layer integrity and encryption services to the IP and/or upper layer
skipping to change at page 10, line 44 skipping to change at page 12, line 7
which use the exchanged keys to protect payload traffic. which use the exchanged keys to protect payload traffic.
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Device, IKE, ISAKMP, ESP, AH IPsec Device, IKE, ISAKMP, ESP, AH
7.2 ISAKMP 7.2. ISAKMP
Definition: Definition:
The Internet Security Association and Key Management Protocol, The Internet Security Association and Key Management Protocol,
which provides a framework for authentication and key exchange but which provides a framework for authentication and key exchange but
does not define them. ISAKMP is designed to be key exchange does not define them. ISAKMP is designed to be key exchange
independent; it is designed to support many different key independent; it is designed to support many different key
exchanges. ISAKMP is defined in [RFC2407]. exchanges. ISAKMP is defined in [RFC2407].
Discussion: Discussion:
skipping to change at page 11, line 26 skipping to change at page 12, line 32
Issues: Issues:
When implementations refer to the term 'ISAKMP SA', it refers to When implementations refer to the term 'ISAKMP SA', it refers to
an IKE Phase 1 SA. an IKE Phase 1 SA.
See Also: See Also:
IKE, Security Association IKE, Security Association
7.3 IKE 7.3. IKE
Definition: Definition:
A hybrid key management protocol that provides authentication of A hybrid key management protocol that provides authentication of
the IPsec peers, negotiates IPsec SAs and establishes IPsec keys. the IPsec peers, negotiates IPsec SAs and establishes IPsec keys.
Discussion: Discussion:
A hybrid protocol, defined in [RFC2409], from the following 3 A hybrid protocol, defined in [RFC2409], from the following 3
protocols: protocols:
skipping to change at page 12, line 27 skipping to change at page 13, line 32
During the first IPsec deployment experiences, ambiguities were During the first IPsec deployment experiences, ambiguities were
found in the IKEv1 specification, which lead to interoperability found in the IKEv1 specification, which lead to interoperability
problems. To resolve these issues, IKEv1 is being updated by problems. To resolve these issues, IKEv1 is being updated by
IKEv2. IKEv2.
See Also: See Also:
ISAKMP, IPsec, Security Association 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 The shared policy and key(s) used by negotiating peers to
establish a secure authenticated "control channel" for further IKE establish a secure authenticated "control channel" for further IKE
communications. communications.
Discussion: Discussion:
The IPsec framework mandates that SPI's are used to secure payload The IPsec framework mandates that SPI's are used to secure payload
traffic. If IKE is employed all SPI information will be exchanged traffic. If IKE is employed all SPI information will be exchanged
between the IPsec devices. This has to be done in a secure between the IPsec devices. This has to be done in a secure
fashion and for that reason IKE will set up a secure "control fashion and for that reason IKE will set up a secure "control
channel" over which it can exchange this information. 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 keys 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: See Also:
IKE, ISAKMP 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 Main Mode is an instantiation of the ISAKMP Identity Protect
Exchange, defined in [RFC2409]. Upon successful completion it Exchange, defined in [RFC2409]. Upon successful completion it
results in the establishment of an IKE Phase 1 SA. results in the establishment of an IKE Phase 1 SA.
Discussion: Discussion:
IKE Main Mode use 3 distinct message pairs, for a total of 6 IKE Main Mode use 3 distinct message pairs, for a total of 6
skipping to change at page 13, line 35 skipping to change at page 14, line 39
not their purpose. not their purpose.
Issues: Issues:
N/A N/A
See Also: See Also:
ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode 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 Aggressive Mode is an instantiation of the ISAKMP Aggressive
Exchange, defined in [RFC2409]. Upon successful completion it Exchange, defined in [RFC2409]. Upon successful completion it
results in the establishment of an IKE Phase 1 SA. results in the establishment of an IKE Phase 1 SA.
Discussion: Discussion:
IKE Aggressive Mode uses 3 messages. The first two messages IKE Aggressive Mode uses 3 messages. The first two messages
skipping to change at page 14, line 15 skipping to change at page 15, line 17
Issues: Issues:
For IKEv1 the standard specifies that all implementations use both For IKEv1 the standard specifies that all implementations use both
main and agressive mode, however, it is common to use only main main and agressive mode, however, it is common to use only main
mode. mode.
See Also: See Also:
ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode 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 ISAKMP phase which upon successful completion establishes the
shared keys used by the negotiating peers to set up a secure "data shared keys used by the negotiating peers to set up a secure "data
channel" for IPsec. channel" for IPsec.
Discussion: Discussion:
The main purpose of Phase 2 is to produce the key for the IPsec The main purpose of Phase 2 is to produce the key for the IPsec
tunnel. Phase 2 is also used to regenerate the key being used for tunnel. Phase 2 is also used for exchanging informational
IPsec (called "rekeying"), as well as for exchanging informational
messages. messages.
Issues: Issues:
In other documents also referenced as IPsec SA. In other documents also referenced as IPsec SA.
See Also: See Also:
IKE Phase 1, ISAKMP, IKE 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 Quick Mode is an instanciation of IKE Phase 2. After successful
completion it will result in one or typically two or more IPsec completion it will result in one or typically two or more IPsec
SA's SA's
Discussion: Discussion:
Quick Mode is used to negotiate the SA's and keys that will be Quick Mode is used to negotiate the SA's and keys that will be
skipping to change at page 15, line 20 skipping to change at page 16, line 20
is enabled. is enabled.
Issues: Issues:
N/A N/A
See Also: See Also:
ISAKMP, IKE, IKE Phase 2 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 A set of policy and key(s) used to protect traffic flows that
require authentication and/or encryption services. It is a 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:
skipping to change at page 15, line 46 skipping to change at page 16, line 46
through the use of AH or ESP as defined in [RFC2401]. through the use of AH or ESP as defined in [RFC2401].
Issues: Issues:
N/A N/A
See Also: See Also:
Initiator, Responder Initiator, Responder
7.5 Selectors 7.5. Selectors
Definition: Definition:
A mechanism used for the classification of traffic flows that A mechanism used for the classification of traffic flows that
require authentication and/or encryption services. require authentication and/or encryption services.
Discussion: Discussion:
The selectors are a set of fields that will be extracted from the The selectors are a set of fields that will be extracted from the
network and transport layer headers that provide the ability to network and transport layer headers that provide the ability to
classify the traffic flow and associate it with an SA. classify the traffic flow and associate it with an SA.
skipping to change at page 16, line 33 skipping to change at page 17, line 32
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: Definition:
Any implementation that has the ability to process data flows Any implementation that has the ability to process data flows
according to the IPsec protocol suite specifications. according to the IPsec protocol suite specifications.
Discussion: Discussion:
Implementations can be grouped by 'external' properties (e.g. Implementations can be grouped by 'external' properties (e.g.
software vs. hardware implementations) but more important is the software vs. hardware implementations) but more important is the
skipping to change at page 17, line 20 skipping to change at page 18, line 20
Due to the fragmented nature of the IPsec Protocol Suite RFC's, it Due to the fragmented nature of the IPsec Protocol Suite RFC's, it
is possible that IPsec implementations will not be able to is possible that IPsec implementations will not be able to
interoperate. Therefore it is important to know which features 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 An IPsec device which starts the negotiation of IKE Phase 1 and
IKE Phase 2 SAs. IKE Phase 2 SAs.
Discussion: Discussion:
When a traffic flow is offered at an IPsec device and it is When a traffic flow is offered at an IPsec device and it is
determined that the flow must be protected, but there is no IPsec determined that the flow must be protected, but there is no IPsec
skipping to change at page 17, line 48 skipping to change at page 18, line 48
Issues: Issues:
IPsec devices/implementations can be both an initiator as well as IPsec devices/implementations can be both an initiator as well as
a responder. The distinction is useful from a test perspective. a responder. The distinction is useful from a test perspective.
See Also: See Also:
Responder, IKE, IPsec Responder, IKE, IPsec
7.6.2 Responder 7.6.2. Responder
Definition: Definition:
An IPsec device which replies to incoming IKE Phase 1 and IKE An IPsec device which replies to incoming IKE Phase 1 and IKE
Phase 2 requests and processes these messages in order to 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 When an initiator attempts to establish SA's with another IPsec
device, this peer will need to evaluate the proposals made by the device, this peer will need to evaluate the proposals made by the
skipping to change at page 18, line 28 skipping to change at page 19, line 28
Issues: Issues:
IPsec devices/implementations can usually be both an initiator as IPsec devices/implementations can usually be both an initiator as
well as a responder. The distinction is useful from a test well as a responder. The distinction is useful from a test
perspective. perspective.
See Also: See Also:
Initiator, IKE 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: Discussion:
In some situations it is not needed or prefered to have an IPsec In some situations it is not needed or prefered to have an IPsec
device respond to an inbound IKE SA or IPsec SA request. In the device respond to an inbound IKE SA or IPsec SA request. In the
case of e.g. road warriors or home office scenarios the only case of e.g. road warriors or home office scenarios the only
skipping to change at page 19, line 13 skipping to change at page 20, line 11
to a private network. to a private network.
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec device, IPsec Server, Initiator, Responder 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 IPsec Devices that can both act as an Initiator as well as a
Responder. Responder.
Discussion: Discussion:
IPsec Servers are mostly positioned at private network edges and IPsec Servers are mostly positioned at private network edges and
provide several functions: provide several functions:
skipping to change at page 19, line 42 skipping to change at page 20, line 40
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 The combination of an IKE Phase 1 SA and a pair of IKE Phase 2
SA's. SA's.
Discussion: Discussion:
A 'Tunnel' will be defined as a single (1) Phase 1 SA and a pair An IPsec Tunnel will be defined as a single (1) Phase 1 SA and a
(2) Phase 2 SA's. This construct will allow bidirectional traffic pair (2) Phase 2 SA's. This construct will allow bidirectional
to be passed between two IPsec Devices The AH and ESP protocols traffic to be passed between two IPsec Devices where the traffic
each support two modes of operation: transport mode and tunnel can benefit form the services offered in the IPsec framework.
mode. In transport mode, two hosts provide protection primarily
for upper-layer protocols. The cryptographic endpoints (where the
encryption and decryption take place) are the source and
destination of the data packet. In IPv4, a transport mode
security protocol header appears immediately after the IP header
and before any higher-layer protocols (such as TCP or UDP). In
IPv6, the security protocol header appears after the base IP
header and selected extension headers. It may appear before or
after destination options but must appear before next layer
protocols (e.g., TCP, UDP, SCTP) In the case of AH in transport
mode, security services are provided to selected portions of the
IP header preceding the AH header, selected portions of extension
headers, and selected options (contained in the IPv4 header, IPv6
Hop-by-Hop extension header, or IPv6 Destination extension
headers). Any fields in these headers/extension headers which are
modified in transit are set to 0 before applying the
authentication algorithm. If a field is mutable, but its value at
the receiving IPsec peer is predictable, then that value is
inserted into the field before applying the cryptographic
algorithm. In the case of ESP in transport mode, security
services are provide only for the higher-layer protocols, not for
the IP header or any extension headers preceding the ESP header.
A tunnel is a vehicle for encapsulating packets inside a protocol
that is understood at the entry and exit points of a given
network. These entry and exit points are defined as tunnel
interfaces. Both the AH and ESP protocols can be used in tunnel
mode for data packet endpoints as well as by intermediate security
gateways. In tunnel mode, there is an "outer" IP header that
specifies the IPsec processing destination, plus an "inner" IP
header that specifies the ultimate destination for the packet.
The source address in the outer IP header is the initiating
cryptographic endpoint; the source address in the inner header is
the true source address of the packet. The security protocol
header appears after the outer IP header and before the inner 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, 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 higher-layer protocols). If ESP is employed,
the protection is afforded only to the tunneled packet, not to the
new outer IP header. where the traffic can benefit form the
services offered in the IPsec framework.
Issues: Issues:
Since it is implied that a Phase 1 SA is used, a Tunnel will be by Since it is implied that a Phase 1 SA is used, an IPsec Tunnel
definition a dynamically negotiated secured link. If manual will be by definition a dynamically negotiated secured link. If
keying is used to enable secure data transport, then this link manual keying is used to enable secure data transport, then this
will merely refered to as a pair of IKE Phase 2 SA's. 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 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: Definition:
An IPsec tunnel that is provisioned in the IPsec device's An IPsec tunnel or a pair of IPsec SAs in the case of manual
configuration and SADB. keying that is provisioned in the IPsec device's configuration.
Discussion: Discussion:
Several steps are required before an IPsec Tunnel can be used to Several steps are required before IPsec can be used to actually
actually transport traffic. The very first step is to configure transport traffic. The very first step is to configure the IPsec
the IPsec Tunnel in the IPsec device. In that way packet Tunnel (or IPsec SAs in the case of manual keying) in the IPsec
classification can make a decision if it is required to start device. When using IKE there are no SA's associated with the
negotiating SA's. At this time there are no SA's associated with IPsec Tunnel and no traffic is going through the IPsec device that
the Tunnel and no traffic is going through the IPsec device that
matches the Selectors, which would instantiate the IPsec Tunnel. matches the Selectors, which would instantiate the IPsec Tunnel.
When using either manual keying or IKE, a configured tunnel will
A Configured Tunnel is also an IPsec Tunnel that has relinquished not have a populated SADB.
all it's SA's and is not transmitting data anymore. To be more
specific, when an Established or an Active Tunnel is terminated
due to either an administrative action or an IKE event that
deactivated the IPsec Tunnel, the IPsec Tunnel will be back in a
configured state.
Issues: Issues:
N/A 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: See Also:
Tunnel, Established Tunnel, Active Tunnel IPsec Tunnel, Established Tunnel, Active Tunnel
7.7.3 Established Tunnel 7.7.3. Established Tunnel
Definition: Definition:
An IPsec Tunnel that has completed Phase 1 and Phase 2 SA An IPsec device that has a populated SADB and is ready to provide
negotiations but is otherwise idle. security services to the appropriate traffic.
Discussion: Discussion:
A second step needed to ensure that an IPsec Tunnel can transport When using IKE, a second step needed to ensure that an IPsec
data is to complete the Phase 1 and Phase 2 negotiations. After Tunnel can transport data is to complete the Phase 1 and Phase 2
the packet classification process has asserted that a packet negotiations. After the packet classification process has
requires security services, the negotation is started to obtain asserted that a packet requires security services, the negotation
both Phase 1 and Phase 2 SA's. After this is completed the IPsec is started to obtain both Phase 1 and Phase 2 SAs. After this is
Tunnel is called 'Established'. Note that at this time there is completed and the SADB is populated, the IPsec Tunnel is called
still no traffic flowing through the IPsec Tunnel. Just enough 'Established'. Note that at this time there is still no traffic
packet(s) have been sent to the IPsec device that matched the flowing through the IPsec Tunnel. Just enough packet(s) have been
selectors and triggered the IPsec Tunnel setup. This may also be sent to the IPsec device that matched the selectors and triggered
acomplished by an administrative command to connect the Tunnel, in the IPsec Tunnel setup to result in a populated SADB. In the case
which case the Tunnel is not triggered by any positive packet of manual keying, populating the SADB is accomplished by a
classification. separate administrative command.
Issues: Issues:
In the case of manually keyed Tunnels, there is no distinction N/A
between a Configured Tunnel or an Established Tunnel since there
is no negotiation required with these type of Tunnels and the
Tunnel is Established at time of Configuration since all keying
information is known at that point.
See Also: See Also:
Tunnel, Configured Tunnel, Active Tunnel IPsec Tunnel, Configured Tunnel, Active Tunnel
7.7.4. Active Tunnel
7.7.4 Active Tunnel
Definition: Definition:
An IPsec Tunnel that has completed Phase 1 and Phase 2 SA An IPsec device that is forwarding secured data.
negotiations and is forwarding data.
Discussion: Discussion:
When an IPsec Tunnel is Established and it is transporting When a Tunnel is Established and it is transporting traffic that
traffic, the tunnel is called 'Active'. is authenticated and/or encrypted, the tunnel is called 'Active'.
Issues: Issues:
The distinction between an Active Tunnel and Configured/ 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:
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: Discussion:
The process of nesting tunnels can theoretically be repeated The process of nesting tunnels can theoretically be repeated
multiple times (for example, tunnels can be many levels deep), but multiple times (for example, tunnels can be many levels deep), but
for all practical purposes, most implementations limit the level for all practical purposes, most implementations limit the level
skipping to change at page 24, line 30 skipping to change at page 24, line 22
branch offices. branch offices.
Issues: Issues:
N/A N/A
See Also: See Also:
Transport Adjacency, IPsec Tunnel 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: Discussion:
Transport adjacency is a form of tunnel nesting. In this case two Transport adjacency is a form of tunnel nesting. In this case two
or more transport mode IPsec tunnels are set side by side to or more transport mode IPsec tunnels are set side by side to
enhance applied security properties. enhance applied security properties.
skipping to change at page 25, line 26 skipping to change at page 25, line 18
This is rarely used in the way it is depicted. It is more common, This is rarely used in the way it is depicted. It is more common,
but still not likely, that SA's are established from different but still not likely, that SA's are established from different
gateways as depicted in the Nested Tunnels figure. The packet gateways as depicted in the Nested Tunnels figure. The packet
format in the IP Cloud would remain unchanged. format in the IP Cloud would remain unchanged.
See Also: See Also:
Nested Tunnels, IPsec Tunnel Nested Tunnels, IPsec Tunnel
7.9 Transform protocols 7.9. Transform protocols
Definition: Definition:
Encryption and authentication algorithms that provide Encryption and authentication algorithms that provide cryptograhic
cryptograhical services to the IPsec Protocols. services to the IPsec Protocols.
Discussion: Discussion:
Some algorithms run significantly slower than others. For Some algorithms run significantly slower than others. A decision
example, TripleDES encryption is one third as fast as DES for which algorithm to use is usually based on the tradeoff
encryption. between performance and security strength. For example, 3DES
encryption is generally slower then DES encryption.
Issues: Issues:
N/A N/A
See Also: See Also:
Authentication protocols, Encryption protocols 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 Authentication protocols provide no confidentiality. Commonly
used authentication algorithms/protocols are: used authentication algorithms/protocols are:
skipping to change at page 26, line 29 skipping to change at page 26, line 20
* AES-HMAC * AES-HMAC
Issues: Issues:
N/A N/A
See Also: See Also:
Transform protocols, Encryption protocols 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: Discussion:
Encryption protocols provide no authentication. Commonly used Encryption protocols provide no authentication. Commonly used
encryption algorithms/protocols are: encryption algorithms/protocols are:
* NULL encryption * NULL encryption
* DES-CBC * DES-CBC
* 3DES-CBC * 3DES-CBC
* AES-CBC * AES-CBC
Issues: Issues:
Null option is a valid encryption mechanism although it reverts to The null-encryption option is a valid encryption mechanism to
use of IPsec back to message authenticity but only for upper layer provide an alternative to using AH. There is no confidentiality
protocols. protection with null-encryption. Note also that when using ESP
null-encryption the authentication and integrity services only
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
likely successor of 3DES due to its superior encryption and its successor of 3DES due to its superior encryption and performance
single oparation nature which translates into a speed 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 A suite of protocols which provide a framework of open standards
that provides data confidentiality, data integrity, and data that provides data origin confidentiality, data integrity, and
authenticity between participating peers at the IP layer. The data origin authenticity between participating peers at the IP
IPsec protocol suite set of standards is documented in [RFC2401] layer. The IPsec protocol suite set of standards is documented in
through [RFC2412] and [RFC2451]. [RFC2401] through [RFC2412] and [RFC2451].
Discussion: Discussion:
The IPsec Protocol suite is modular and forward compatible. The The IPsec Protocol suite is modular and forward compatible. The
protocols that comprise the IPsec protocol suite can be replaced protocols that comprise the IPsec protocol suite can be replaced
with new versions of those protocols as the older versions become with new versions of those protocols as the older versions become
obsolete. For example, IKEv2 will soon replace IKEv1. obsolete. For example, IKEv2 will soon replace IKEv1.
Issues: Issues:
N/A N/A
See Also: See Also:
AH, ESP AH, ESP
7.10.1 Authentication Header (AH) 7.10.1. Authentication Header (AH)
Definition: Definition:
Provides authentication and data integrity (including replay Provides data origin authentication and data integrity (including
protection) security services [RFC2402]. replay protection) security services as defined in [RFC2402].
Discussion: Discussion:
The AH protocol supports both modes of operation; tunnel mode and The AH protocol supports two modes of operation i.e. tunnel mode
transport mode. If AH is employed in tunnel mode, portions of the and transport mode.
outer IP header are given protection, as well as all of the
tunneled IP packet (that is, all of the inner IP header is
protected as are the higher-layer protocols). In the case of AH
in transport mode, all upper-layer information is protected, and
all fields in the IPv4 header excluding the fields typically are
modified in transit.
Original IPv4 packet : In transport mode, AH is inserted after the IP header and before a
[IP ORIG][L4 HDR][PAYLOAD] next layer protocol, e.g., TCP, UDP, ICMP, etc. or before any
In transport mode : other IPsec headers that have already been inserted. In the
[IP ORIG][AH][L4 HDR][PAYLOAD] context of IPv4, this calls for placing AH after the IP header
In tunnel mode : (and any options that it contains), but before the next layer
[IP NEW][AH][IP ORIG][L4 HDR][PAYLOAD] protocol. In the IPv6 context, AH is viewed as an end-to-end
payload, and thus should appear after hop-by-hop, routing, and
fragmentation extension headers. The destination options
extension header(s) could appear before or after or both before
and after the AH header depending on the semantics desired.
In tunnel mode, the "inner" IP header carries the ultimate (IP)
source and destination addresses, while an "outer" IP header
contains the addresses of the IPsec "peers," e.g., addresses of
security gateways. In tunnel mode, AH protects the entire inner
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
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: See Also:
Transform protocols, IPsec protocols, Encapsulated Security Transform protocols, IPsec protocols, Encapsulated Security
Payload Payload
7.10.2 Encapsulated Security Payload (ESP) 7.10.2. Encapsulated Security Payload (ESP)
Definition: Definition:
Provides three essential components needed for secure data Provides data origin authentication, data integrity (including
exchange: authentication, integrity (including replay protection) replay protection) and data confidentiality as defined in
and confidentiality as defined in [RFC2406]. [RFC2406].
Discussion: Discussion:
The ESP protocol supports both modes of operation i.e. tunnel mode The ESP protocol supports two modes of operation i.e. tunnel mode
and transport mode. If ESP is employed in tunnel mode, the and transport mode.
protection is afforded only to the tunneled packet, not to the
outer header. In the case of ESP in transport mode, security
services are provided only for the higher-layer protocols, not for
the IP header.
Original IPv4 packet : In transport mode, ESP is inserted after the IP header and before
[IP ORIG][L4 HDR][PAYLOAD] a next layer protocol, e.g., TCP, UDP, ICMP, etc. In the context
In transport mode : of IPv4, this translates to placing ESP after the IP header (and
[IP ORIG][ESP][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] any options that it contains), but before the next layer protocol.
In tunnel mode : In the IPv6 context, ESP is viewed as an end-to-end payload, and
thus should appear after hop-by-hop, routing, and fragmentation
extension headers. Destination options extension header(s) could
appear before, after, or both before and after the ESP header
depending on the semantics desired. However, since ESP protects
only fields after the ESP header, it generally will be desirable
to place the destination options header(s) after the ESP header.
[IP NEW][ESP][IP ORIG][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] In tunnel mode, the "inner" IP header carries the ultimate (IP)
source and destination addresses, while an "outer" IP header
contains the addresses of the IPsec "peers", e.g., addresses of
security gateways. Mixed inner and outer IP versions are allowed,
i.e., IPv6 over IPv4 and IPv4 over IPv6. In tunnel mode, ESP
protects the entire inner IP packet, including the entire inner IP
header. The position of ESP in tunnel mode, relative to the outer
IP header, is the same as for ESP in transport mode.
Issues: Issues:
N/A N/A
See Also: See Also:
Transform protocols, IPsec protocols, Authentication Header 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 The capability to support IPsec functionality in the presence of
NAT devices. NAT devices.
Discussion: Discussion:
NAT-Traversal requires some modifications to IKE as defined in NAT-Traversal requires some modifications to IKE as defined in
[I-D.ietf-ipsec-nat-t-ike]. Specifically, in phase 1, it requires [RFC3947]. Specifically, in phase 1, it requires detecting if the
detecting if the other end supports NAT-Traversal, and detecting other end supports NAT-Traversal, and detecting if there are one
if there are one or more NAT instances along the path from host to or more NAT instances along the path from host to host. In IKE
host. In IKE Quick Mode, there is a need to negotiate the use of Quick Mode, there is a need to negotiate the use of UDP
UDP encapsulated IPsec packets. 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:
skipping to change at page 29, line 42 skipping to change at page 30, line 4
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: See Also:
IKE, ISAKMP, IPsec Device 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 A mechanism as defined in [RFC2393] that reduces the size of the
payload that needs to be encrypted. payload that needs to be encrypted.
Discussion: Discussion:
IP payload compression is a protocol to reduce the size of IP IP payload compression is a protocol to reduce the size of IP
datagrams. This protocol will increase the overall communication datagrams. This protocol will increase the overall communication
performance between a pair of communicating hosts/gateways performance between a pair of communicating hosts/gateways
skipping to change at page 30, line 34 skipping to change at page 30, line 40
compression must be applied before encryption. compression must be applied before encryption.
Issues: Issues:
N/A N/A
See Also: See Also:
IKE, ISAKMP, IPsec Device IKE, ISAKMP, IPsec Device
7.13 Security Context 7.13. Security Context
Definition: Definition:
A security context is a collection of security parameters that A security context is a collection of security parameters that
describe the characteristics of the path that an IPsec Tunnel will describe the characteristics of the path that an IPsec Tunnel will
take, all of the IPsec Tunnel parameters and the effects it has on take, all of the IPsec Tunnel parameters and the effects it has on
the underlying protected traffic. Security Context encompasses the underlying protected traffic. Security Context encompasses
protocol suite and security policy. protocol suite and security policy.
Discussion: Discussion:
In order to fairly compare multiple IPsec devices it is imperative In order to fairly compare multiple IPsec devices it is imperative
that an accurate overview is given of all security parameters that that an accurate overview is given of all security parameters that
were used to establish the IPsec Tunnels and to secure the traffic were used to establish the IPsec Tunnels or manually created SAs
between protected networks. Security Context is not a metric; it and to secure the traffic between protected networks. Security
is included to accurately reflect the test environment variables Context is not a metric; it is included to accurately reflect the
when reporting the methodology results. To avoid listing too much test environment variables when reporting the methodology results.
information when reporting metrics, we have divided the security To avoid listing too much information when reporting metrics, we
context into an IKE context and an IPsec context. have divided the security context into 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, the both and IPsec behavioral characteristics of the IPsec device, in which case both
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:
* Number of IPsec Tunnels or IKE Phase 1 / Phase 2 ratio * Manual Keyed Tunnels versus IKE negotiated Tunnels
* IPsec protocol * Number of IPsec Tunnels or IPsec SA's
* IPsec mode (tunnel or transport) * IPsec protocol (AH or ESP)
* Authentication protocol used by IPsec * IPsec protocol mode (tunnel or transport)
* Encryption protocol used by IPsec (if applicable) * Authentication algorithm used by AH/ESP
* Encryption algoritm used ESP (if applicable)
* IPsec SA lifetime (traffic and time based) * IPsec SA lifetime (traffic and time based)
The IPsec Context MAY also list: The IPsec Context MAY also list:
* Selectors * Selectors
* Fragmentation handling * Fragmentation handling
The IKE Context MUST consist of the following elements: The IKE Context MUST consist of the following elements:
* Number of IKE tunnels. * Number of IPsec Tunnels.
* Authentication protocol used by IKE + IKE Phase 1 SA to IKE Phase 2 SA ratio (if applicable)
* Encryption protocol used by IKE + IKE Phase 1 parameters
- Authentication algorithm
* Key exchange mechanism (pre-shared key, certificate authority, - Encryption algorithm
etc ...)
* Key size (if applicable) - DH-Group
* Diffie-Hellman group - SA lifetime (traffic and time based)
- Authentication mechanism (pre-shared key, RSA-sig,
certificate, etc)
+ IKE Phase 2 parameters
- IPsec protocol (part of IPsec context)
- IPsec protocol mode (part of IPsec context)
- Authentication algorithm (part of IPsec context)
- Encryption algorithm (part of IPsec context)
- DH-Group
- PFS used
- SA Lifetime (part of IPsec context)
* IKE SA lifetime (time based)
* 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]
* PFS Diffie-Hellman group
The IKE context MAY 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 A Security Context will be an important element in describing the
environment where protected traffic is traveling through. environment where protected traffic is traveling through.
See Also: See Also:
IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2, IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2,
Selectors, IPsec Tunnel 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: Discussion:
In relation to IPsec this is the size of the IP header and its In relation to IPsec this is the size of the IP header and its
payload. It SHALL NOT include any encapsulations that MAY be payload. It SHALL NOT include any encapsulations that MAY be
applied before the PDU is processed for encryption. applied before the PDU is processed for encryption.
For example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload. IPv4 example: 46 bytes PDU = 20 bytes IP header + 26 bytes
payload.
Measurement Units: Measurement Units:
Bytes Bytes
Issues: Issues:
N/A N/A
See Also: See Also:
Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2
Encrypted Framesize. Encrypted Framesize.
8.2 Layer3 encrypted framesize 8.2. Layer3 encrypted framesize
Definition: Definition:
The total size of the encrypted L3 PDU. The total size of the encrypted L3 PDU.
Discussion: Discussion:
The size of the IP packet and its payload after encapsulations MAY The size of the IP packet and its payload after encapsulations MAY
be applied and the PDU is being processed by the transform. be applied and the PDU is being processed by the transform.
For example, after a tunnel mode ESP 3DES/SHA1 transform has been For example, in IPv4, after a tunnel mode ESP 3DES/SHA1 transform
applied an unencrypted or clear layer3 framesize of 46 bytes has been applied an unencrypted or clear layer3 framesize of 46
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
skipping to change at page 34, line 5 skipping to change at page 34, line 32
Issues: Issues:
N/A N/A
See Also: See Also:
Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted
Framesize. Framesize.
8.3 Layer2 clear framesize 9. Performance Metrics
9.1. IPsec Tunnels Per Second (TPS)
Definition: Definition:
The total size of the unencrypted L2 PDU. The measurement unit for the IPsec Tunnel Setup Rate tests. The
rate at which IPsec Tunnels are established per second.
Discussion: Discussion:
This is the Layer 3 clear framesize plus all the layer2 overhead. According to [RFC2401] two IPsec Tunnels cannot be established
In the case of Ethernet this would be 18 bytes. between the same gateways with the same selectors. This is to
prevent overlapping IPsec Tunnels. If overlapping IPsec Tunnels
For example, a 46 byte Layer3 clear framesize packet would become are attempted, the error will cause the IPsec Tunnel setup time to
64 Bytes after Ethernet Layer2 overhead is added: take longer than if the IPsec Tunnel setup was successful. For
this reason, a unique pair of selector sets are required for IPsec
6 bytes destination mac address Tunnel Setup Rate testing.
6 bytes source mac address
2 bytes length/type field
46 bytes layer3 (IP) payload
4 bytes FCS
Measurement Units:
Bytes
Issues: Issues:
If it is not mentioned explicitly what kind of framesize is used, A unique pair of selector sets are required for TPS testing.
the layer2 clear framesize will be the default.
See Also: See Also:
Layer3 clear framesize, Layer2 encrypted framesize, Layer2 IPsec Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate, IKE
encrypted framesize. Setup Rate, IPsec Setup Rate
8.4 Layer2 encrypted framesize 9.2. Tunnel Rekeys Per Seconds (TRPS)
Definition: Definition:
The total size of the encrypted L2 PDU. A metric that quantifies the number of IKE Phase 1 or Phase 2
rekeys per seconds a DUT can correctly process.
Discussion: Discussion:
This is the Layer 3 encrypted framesize plus all the layer2 This metric will be will be primary used with Tunnel Rekey
overhead. In the case of Ethernet this would be 18 bytes. behavior tests.
For example, a 96 byte Layer3 encrypted framesize packet would
become 114 bytes after Ethernet Layer2 overhead is added:
6 bytes destination mac address
6 bytes source mac address
2 bytes length/type field
96 bytes layer3 (IPsec) payload
4 bytes FCS
Measurement Units:
Bytes TRPS will provide a metric used to see system behavior under
stressful conditions where large volumes of SA's are being rekeyed
at the same time or in a short timespan.
Issues: Issues:
N/A N/A
See Also: See Also:
Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2 Clear Tunnel Rekey Behavior, Phase 1 Rekey Rate, Phase 2 Rekey Rate
Framesize
9. Performance Metrics
9.1 Tunnels Per Second (TPS) 9.3. IPsec Tunnel Attempts Per Second (TAPS)
Definition: Definition:
The measurement unit for the IPsec Tunnel Setup Rate tests. The A metric that quantifies the number of successful and unsuccessful
rate that IPsec Tunnels are established per second. IPsec Tunnel establishment requests per second.
Discussion: Discussion:
According to [RFC2401] two IPsec Tunnels cannot be established This metric can be used to measure IKE DOS Resilience behavior
between the same gateways with the same selectors. This is to test.
prevent overlapping IPsec Tunnels. If overlapping IPsec Tunnels
are attempted, the error will cause the IPsec Tunnel setup time to TAPS provides an important metric to validate the stability of an
take longer than if the IPsec Tunnel setup was successful. For IPsec device, if stressed with valid (large number of IPsec tunnel
this reason, a unique pair of selector sets are required for IPsec establishments per seconds or TPS) or invalid (IKE DOS attacks of
Tunnel Setup Rate testing. any style) tunnel establishment requests. IPsec Tunnel setups
offered to an IPsec devices can either fail due to lack of
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
latter).
Issues: Issues:
A unique pair of selector sets are required for TPS testing. If the TAPS increases, the TPS usually decreases, due to burdening
of the DUT with the DOS attack traffic.
See Also: See Also:
Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate, IKE Setup N/A
Rate, IPsec Setup Rate
9.2 Tunnel Rekeys Per Seconds (TRPS) 10. Test Definitions
10.1. Capacity
10.1.1. IKE SA Capacity
Definition: Definition:
A metric that quantifies the number of IKE Phase 1 or Phase 2 The maximum number of IKE SA's that can be sustained on an IPsec
rekey's per seconds a DUT can correctly process. Device.
Discussion: Discussion:
This metric will be will be primary used with Tunnel Rekey TBD
behavior tests.
TRPS will provide a metric used to see system behavior under Measurement Units:
stressful conditions where large volumes of tunnels are being
rekeyed at the same time or in a short timespan. IKE SA's
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel Rekey; Phase 1 Rekey Rate, Phase 2 Rekey Rate N/A
9.3 Tunnel Attempts Per Second (TAPS) 10.1.2. IPsec SA Capacity
Definition: Definition:
A metric that quantifies the number of successful and unsuccessful The maximum number of IPsec SA's that can be sustained on an IPsec
IPsec Tunnel establishment requests per second. Device.
Discussion: Discussion:
This metric can be used to measure IKE DOS Resilience behavior TBD
test.
TAPS provides an important metric to validate the stability of an Measurement Units:
IPsec device, if stressed with valid (large number of IPsec tunnel
establishments per seconds or TPS) or invalid (IKE DOS attacks of IPsec SA's
any style) tunnel establishment requests. IPsec Tunnel setups
offered to an IPsec devices can either fail due to lack of
resources in the IPsec device to proces all the requests or due to
an IKE DOS attack (usually the former is a result of the latter).
Issues: Issues:
If the TAPS increases, the TPS usually decreases, due to burdening N/A
of the DUT with the DOS attack traffic.
10. Test Definitions See Also:
10.1 Throughput N/A
10.1.1 IPsec Tunnel Throughput 10.2. Throughput
10.2.1. IPsec Throughput
Definition: Definition:
The maximum rate through an IPsec tunnel at which none of the The maximum rate through an Active Tunnel at which none of the
offered frames are dropped by the device under test. offered frames are dropped by the device under test.
Discussion: Discussion:
The IPsec Tunnel Throughput is almost identically defined as The IPsec Throughput is almost identically defined as Throughput
Throughput in [RFC1242], section 3.17. The only difference is in [RFC1242], section 3.17. The only difference is that the
that the throughput is measured with a traffic flow getting throughput is measured with a traffic flow getting encrypted and
encrypted and decrypted by an IPsec device. IPsec Tunnel decrypted by an IPsec device. IPsec Throughput is an end-to-end
Throughput is an end-to-end measurement. 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. representation and shall be called the IPsec Throughput.
Measurement Units: Measurement Units:
Packets per seconds (pps), Mbps Packets per seconds (pps)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Encryption Throughput, IPsec Decryption Throughput IPsec Encryption Throughput, IPsec Decryption Throughput
10.1.2 IPsec Tunnel Encryption Throughput 10.2.2. IPsec Encryption Throughput
Definition: Definition:
The maximum encryption rate through an IPsec tunnel at which none The maximum encryption rate through an Active Tunnel at which none
of the offered cleartext frames are dropped by the device under of the offered cleartext frames are dropped by the device under
test. test.
Discussion: Discussion:
Since encryption throughput is not necessarily equal to the Since encryption throughput is not necessarily equal to the
decryption throughput, both of the forwarding rates must be 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 tunnels. 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), Mbps Packets per seconds (pps)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Throughput, IPsec Tunnel Decryption Throughput IPsec Throughput, IPsec Decryption Throughput
10.1.3 IPsec Tunnel Decryption Throughput 10.2.3. IPsec Decryption Throughput
Definition: Definition:
The maximum decryption rate through an IPsec tunnel at which none The maximum decryption rate through an Active Tunnel at which none
of the offered encrypted frames are dropped by the device under of the offered encrypted frames are dropped by the device under
test. test.
Discussion: Discussion:
Since encryption throughput is not necessarily equal to the Since encryption throughput is not necessarily equal to the
decryption throughput, both of the forwarding rates must be 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 tunnels. As defined in [RFC1242], measurements IPsec and IKE SA. As defined in [RFC1242], measurements should be
should be taken with an assortment of frame sizes. taken with an assortment of frame sizes.
Measurement Units: Measurement Units:
Packets per seconds (pps), Mbps Packets per seconds (pps)
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also:
IPsec Tunnel Throughput, IPsec Tunnel Encryption Throughput IPsec Throughput, IPsec Encryption Throughput
10.2 Latency 10.2.4. IPsec Fragmentation Throughput
10.2.1 IPsec Tunnel Latency Definition:
The maximum rate through an Active Tunnel at which none of the
offered frames ,which require fragmentation after applying the
transform overhead, are dropped by the device under test.
Discussion:
TBD
Measurement Units:
Packets per seconds (pps)
Issues:
N/A
See Also:
N/A
10.2.5. IPsec Reassembly Throughput
Definition:
The maximum rate through an Active Tunnel at which none of the
offered fragmented frames are dropped by the device under test.
Discussion:
TBD
Measurement Units:
Packets per seconds (pps)
Issues:
N/A
See Also:
N/A
10.3. Latency
10.3.1. IPsec Latency
Definition: Definition:
Time required to propagate a cleartext frame from the input Time required to propagate a cleartext frame from the input
interface of an initiator, through an IPsec Tunnel, to the output interface of an initiator, through an Active Tunnel, to the output
interface of the responder. interface of the responder.
Discussion: Discussion:
The Tunnel Latency is the time interval starting when the end of The IPsec Latency is the time interval starting when the end of
the first bit of the cleartext frame reaches the input interface 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 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 same cleartext frame is detected on the output interface of the
responder. The frame has passed through an IPsec Tunnel between responder. The frame has passed through an Active Tunnel between
an initiator and a responder and has been through an encryption an initiator and a responder and has been through an encryption
and decryption cycle. and decryption cycle.
Measurement Units: Measurement Units:
Time units with enough precision to reflect latency measurement. Time units with enough precision to reflect latency measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Encryption Latency, IPsec Tunnel Decryption Latency IPsec Encryption Latency, IPsec Decryption Latency
10.2.2 IPsec Tunnel Encryption Latency 10.3.2. IPsec Encryption Latency
Definition: Definition:
The IPsec Tunnel Encryption Latency is the time interval starting The IPsec Encryption Latency is the time interval starting when
when the end of the first bit of the cleartext frame reaches the the end of the first bit of the cleartext frame reaches the input
input interface, through an IPsec tunnel, and ending when the interface, through an Active Tunnel, and ending when the start of
start of the first bit of the encrypted output frame is seen on the first bit of the encrypted output frame is seen on the output
the output interface. interface.
Discussion: Discussion:
IPsec Tunnel Encryption latency is the latency introduced when IPsec Encryption Latency is the latency introduced when encrypting
encrypting traffic through an IPsec tunnel. 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 tunnels. 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: Issues:
N/A N/A
skipping to change at page 40, line 44 skipping to change at page 42, line 4
[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: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Latency, IPsec Tunnel Decryption Latency IPsec Latency, IPsec Decryption Latency
10.2.3 IPsec Tunnel Decryption Latency 10.3.3. IPsec Decryption Latency
Definition: Definition:
The IPsec Tunnel decryption Latency is the time interval starting The IPsec decryption Latency is the time interval starting when
when the end of the first bit of the encrypted frame reaches the the end of the first bit of the encrypted frame reaches the input
input interface, through an IPsec tunnel, and ending when the interface, through an Active Tunnel, and ending when the start of
start of the first bit of the decrypted output frame is seen on the first bit of the decrypted output frame is seen on the output
the output interface. interface.
Discussion: Discussion:
IPsec Tunnel decryption latency is the latency introduced when IPsec Decryption Latency is the latency introduced when decrypting
decrypting traffic through an IPsec tunnel. Like encryption/ traffic through an Active Tunnel. Like encryption/decryption
decryption throughput, it is not always the case that encryption throughput, it is not always the case that encryption latency
latency equals the decryption latency. Therefore a distinction equals the decryption latency. Therefore a distinction between
between the two has to be made in order to get a more accurate the two has to be made in order to get a more accurate view of
view of where the latency is the most pronounced. 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 tunnels. 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: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Latency, IPsec Tunnel Encryption Latency IPsec Latency, IPsec Encryption Latency
10.2.4 Time To First Packet 10.3.4. Time To First Packet
Definition: Definition:
The Time To First Packet (TTFP) is the time required process an The Time To First Packet (TTFP) is the time required to process a
cleartext packet when no tunnel is present. cleartext packet from a traffic stream that requires encryption
services when no IPsec Tunnel is present.
Discussion: Discussion:
The TTFP addresses the issue of responsiveness of an IPsec device The Time To First Packet addresses the issue of responsiveness of
by looking how long it take to transmit a packet over a not yet an IPsec device by looking how long it takes to transmit a packet
established tunnel path. The TTFP MUST include the time to set up over Configured Tunnel. The Time To First Packet MUST include the
the tunnel, triggered by the traffic flow (both phase 1 and phase time to set up the established tunnel, triggered by the traffic
2 setup times are included) and the time it takes to encrypt and flow (both phase 1 and phase 2 setup times SHALL be included) and
decrypt the packet on a corresponding peer. In short it is the the time it takes to encrypt and decrypt the packet on a
tunnel setup time plus the propagation delay of the packet through corresponding peer. In short it is the IPsec Tunnel setup time
the Tunnel. plus the propagation delay of the packet 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: Issues:
N/A Only relevant when using IKE for tunnel negotiation.
10.3 Frame Loss 10.4. Frame Loss
10.3.1 IPsec Tunnel Frame Loss 10.4.1. IPsec Frame Loss
Definition: Definition:
Percentage of cleartext frames that should have been forwarded Percentage of cleartext frames that should have been forwarded
through an IPsec Tunnel under steady state (constant) load but through an Active Tunnel under steady state (constant) load but
were dropped before encryption or after decryption. were dropped before encryption or after decryption.
Discussion: Discussion:
The IPsec Tunnel Frame Loss is almost identically defined as Frame The IPsec Frame Loss is almost identically defined as Frame Loss
Loss Rate in [RFC1242], section 3.6. The only difference is that Rate in [RFC1242], section 3.6. The only difference is that the
the IPsec Tunnel Frame Loss Rate is measured with a traffic flow IPsec Frame Loss is measured with a traffic flow getting encrypted
getting encrypted and decrypted by an IPsec device. IPsec Tunnel and decrypted by an IPsec Device. IPsec Frame Loss is an end-to-
Frame Loss Rate is an end-to-end measurement. end measurement.
Measurement Units: Measurement Units:
Percent (%) Percent (%)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Encryption Frame Loss, IPsec Tunnel Decryption Frame IPsec Encryption Frame Loss, IPsec Decryption Frame Loss
Loss
10.3.2 IPsec Tunnel Encryption Frame Loss 10.4.2. IPsec Encryption Frame Loss
Definition: Definition:
Percentage of cleartext frames that should have been encrypted Percentage of cleartext frames that should have been encrypted
through an IPsec Tunnel under steady state (constant) load but through an Active Tunnel under steady state (constant) load but
were dropped. were dropped.
Discussion: Discussion:
DUT's will always have an inherent forwarding limitation. This A DUT will always have an inherent forwarding limitation. This
will be more pronounced when IPsec is employed on the DUT. The will be more pronounced when IPsec is employed on the DUT. There
moment that a Tunnel is established and traffic is offered at a is a possibility that the offered traffic rate at the Active
given rate that will flow through that tunnel, there is a Tunnel is too high to be transported through the Active Tunnel and
possibility that the offered traffic rate at the tunnel is too not all cleartext packets will get encrypted. In that case, some
high to be transported through the IPsec tunnel and not all
cleartext packets will get encrypted. In that case, some
percentage of the cleartext traffic will be dropped. This drop percentage of the cleartext traffic will be dropped. This drop
percentage is called the IPsec Tunnel Encryption Frame Loss. percentage is called the IPsec Encryption Frame Loss.
Measurement Units: Measurement Units:
Percent (%) Percent (%)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Frame Loss, IPsec Tunnel Decryption Frame Loss IPsec Frame Loss, IPsec Decryption Frame Loss
10.3.3 IPsec Tunnel Decryption Frame Loss 10.4.3. IPsec Decryption Frame Loss
Definition: Definition:
Percentage of encrypted frames that should have been decrypted Percentage of encrypted frames that should have been decrypted
through an IPsec Tunnel under steady state (constant) load but through an Active Tunnel under steady state (constant) load but
were dropped. were dropped.
Discussion: Discussion:
A DUT will also have an inherent forwarding limitation when A DUT will also have an inherent forwarding limitation when
decrypting packets. When established tunnel encrypted traffic is 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
Tunnel Decryption Frame Loss. Decryption Frame Loss.
Measurement Units: Measurement Units:
Percent (%) Percent (%)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Frame Loss, IPsec Tunnel Encryption Frame Loss IPsec Frame Loss, IPsec Encryption Frame Loss
10.3.4 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 Phase 2 Number of frames dropped as a result of an inefficient IKE Phase 2
rekey. rekey.
Discussion: Discussion:
Normal operation of an IPsec device would require that a rekey Normal operation of an IPsec Device would require that a rekey
does not create temporary Frame Loss of a traffic stream that is does not create temporary IPsec Frame Loss of a traffic stream
protected by the Phase 2 SA's. Nevertheless there can be that is protected by the IKE Phase 2 SA's (i.e. IPsec SA's).
situations where Frame Loss occurs during the rekey process. Nevertheless there can be situations where IPsec Frame 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: Issues:
N/A N/A
See Also: See Also:
Phase 2 Rekey Rate IKE Phase 2 Rekey Rate
10.4 Back-to-back Frames 10.5. Back-to-back Frames
10.4.1 IPsec Tunnel 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 A burst of cleartext frames, offered at a constant load that can
be sent through an IPsec Tunnel without losing a single cleartext be sent through an Active Tunnel without losing a single cleartext
frame after decryption. frame after decryption.
Discussion: Discussion:
The Tunnel Back-to-back Frames is almost identically defined as The IPsec Back-to-back Frames is almost identically defined as
Back-to-back in [RFC1242], section 3.1. The only difference is Back-to-back in [RFC1242], section 3.1. The only difference is
that the Tunnel Back-to-back Frames is measured with a traffic that the IPsec Back-to-back Frames is measured with a traffic flow
flow getting encrypted and decrypted by an IPsec device. IPsec getting encrypted and decrypted by an IPsec Device. IPsec Back-
Tunnel Back-to-back Frames is an end-to-end measurement. to-back Frames is an end-to-end measurement.
Measurement Units: Measurement Units:
Number of N-octet frames in burst. Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in methodology
methodology document. document.
See Also: See Also:
IPsec Tunnel Encryption Back-to-back frames, IPsec Tunnel IPsec Encryption Back-to-back frames, IPsec Decryption Back-to-
Decryption Back-to-back frames back frames
10.4.2 IPsec Tunnel 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 A burst of cleartext frames, offered at a constant load that can
be sent through an IPsec Tunnel without losing a single encrypted be sent through an Active Tunnel without losing a single encrypted
frame. frame.
Discussion: Discussion:
Encryption back-to-back frames is the measure of the maximum burst IPsec Encryption back-to-back frames is the measure of the maximum
size that a device can handle for encrypting traffic that it burst size that an IPsec Device can handle for encrypting traffic
receives as plaintext. Since it is not necessarily the case that that it receives as plaintext. Since it is not necessarily the
the maximum burst size a DUT can handle for encryption is equal to case that the maximum burst size a DUT can handle for encryption
the maximum burst size a DUT can handle for decryption, both of is equal to the maximum burst size a DUT can handle for
these capabilities must be measured independently. The encryption decryption, both of these capabilities must be measured
back-to-back frame measurement has to be measured with the help of independently. The IPsec Encryption Back-to-back frame
an IPsec aware test device that can decrypt the traffic to measurement has to be measured with the help of an IPsec aware
determine the validity of the encrypted frames. test device that can decrypt the traffic to determine the validity
of the encrypted frames.
Measurement Units: Measurement Units:
Number of N-octet frames in burst. Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also:
IPsec Tunnel Back-to-back frames, IPsec Tunnel Decryption Back-to- IPsec Back-to-back frames, IPsec Decryption Back-to-back frames
back frames
10.4.3 IPsec Tunnel 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 The number of encrypted frames, offered at a constant load, that
can be sent through an IPsec Tunnel without losing a single can be sent through an Active Tunnel without losing a single
cleartext frame. cleartext frame.
Discussion: Discussion:
Decryption back-to-back frames is the measure of the maximum burst IPsec Decryption Back-to-back frames is the measure of the maximum
size that a device can handle for decrypting traffic that it burst size that an IPsec Device can handle for decrypting traffic
receives as encrypted traffic. Since it is not necessarily the that it receives as encrypted traffic. Since it is not
case that the maximum burst size a DUT can handle for decryption 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 decryption is equal to the maximum burst size a DUT can handle
encryption, both of these capabilities must be measured for encryption, both of these capabilities must be measured
independently. The decryption back-to-back frame measurement has independently. The IPsec Decryption Back-to-back frame
to be measured with the help of an IPsec aware test device that measurement has to be measured with the help of an IPsec aware
can determine the validity of the decrypted frames. test device that can determine the validity of the decrypted
frames.
Measurement Units: Measurement Units:
Number of N-octet frames in burst. Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in methodology
methodology document. document.
See Also: See Also:
IPsec Tunnel Back-to-back frames, IPsec Tunnel Encryption back-to- IPsec Back-to-back frames, IPsec Encryption back-to-back frames
back frames
10.5 Tunnel Setup Rate Behavior 10.6. Tunnel Setup Behavior
10.5.1 Tunnel Setup Rate 10.6.1. IPsec Tunnel Setup Rate
Definition: Definition:
The maximum number of tunnels (1 IKE SA + 2 IPsec SA's) per second The maximum number of IPsec Tunnels per second that an IPsec
that an IPsec device can successfully establish. Device can successfully establish.
Discussion: Discussion:
The tunnel setup rate SHOULD be measured at varying number of The Tunnel Setup Rate SHOULD be measured at varying number of
tunnels on the DUT. Several factors may influence Tunnel Setup IPsec Tunnels (1 Phase 1 SA and 2 Phase 2 SA's) on the DUT.
Rate, such as: TAPS rate, Background cleartext traffic load on the Several factors may influence Tunnel Setup Rate, such as: TAPS
secure interface, Already established tunnels, Authentication rate, Background cleartext traffic load on the secure interface,
method such as pre-shared keys, RSA-encryption, RSA-signature, DSS Already established IPsec Tunnels, Authentication method such as
Key sizes used (when using RSA/DSS). pre-shared keys, RSA-encryption, RSA-signature, DSS Key sizes used
(when using RSA/DSS).
Measurement Units: Measurement Units:
Tunnels Per Second (TPS) Tunnels Per Second (TPS)
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 1 Setup Rate, Phase 2 Setup Rate, Tunnel Rekey IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec Tunnel Rekey
Behavior
10.5.2 Phase 1 Setup Rate 10.6.2. IKE Phase 1 Setup Rate
Definition: Definition:
The maximum number of IKE tunnels (1 IKE Phase 1 SA) per second The maximum number of sucessful IKE Phase 1 SA's per second that
that an IPsec device can be observed to successfully establish. an IPsec Device can establish.
Discussion: Discussion:
The Phase 1 Setup Rate is a portion of the Tunnel Setup Rate. In The Phase 1 Setup Rate is a portion of the IPsec Tunnel Setup
the process of establishing a Tunnel, it is interesting to know Rate. In the process of establishing an IPsec Tunnel, it is
what the limiting factor of the IKE Finite State Machine is i.e. interesting to know what the limiting factor of the IKE Finite
is it limited by the Phase 1 processing delays or rather by the State Machine (FSM) is i.e. is it limited by the Phase 1
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: Issues:
N/A N/A
See Also: See Also:
Tunnel Setup Rate, Phase 2 Setup Rate, Tunnel Rekey IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec Tunnel
Rekey Behavior
10.5.3 Phase 2 Setup Rate 10.6.3. IKE Phase 2 Setup Rate
Definition: Definition:
The maximum number of IPsec tunnels (2 IKE Phase 2 SA's) per The maximum number of successfully IKE Phase 2 SA's per second
second that a IPsec device can be observed to successfully that an IPsec Device can Only relevant when using IKE establish.
establish.
Discussion: Discussion:
The Phase 2 Setup Rate is a portion of the Tunnel Setup Rate. For The IKE Phase 2 Setup Rate is a portion of the IPsec Tunnel Setup
identical reasons why it is required to quantify the Phase 1 Setup Rate. For identical reasons why it is required to quantify the
Rate, it is a good practice to know the processing delays involved IKE Phase 1 Setup Rate, it is a good practice to know the
in setting up a Phase 2 SA for each direction of the protected processing delays involved in setting up an IKE Phase 2 SA for
traffic flow. each direction of the protected traffic flow.
Note that once you have the Tunnel Setup Rate and either the Phase IKE Phase 2 Setup Rates will ALWAYS be measured for multiples of
1 or the Phase 2 Setup Rate data, you can extrapolate the two IKE Phase 2 SA's.
unmeasured metric, although it is RECOMMENDED to measure all three
metrics. 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
extrapolate the unmeasured metric. It is however highly
RECOMMENDED to measure all three metrics.
Measurement Units: Measurement Units:
Tunnels Per Second (TPS) Tunnels Per Second (TPS)
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel Setup Rate, Phase 1 Setup Rate, Tunnel Rekey IPsec Tunnel Setup Rate, IKE Phase 1 Setup Rate, IPsec Tunnel
Rekey Behavior
10.6 Tunnel Rekey 10.7. IPsec Tunnel Rekey Behavior
10.6.1 Phase 1 Rekey Rate 10.7.1. IKE Phase 1 Rekey Rate
Definition: Definition:
The number of Phase 1 SA's that can be succesfully re-establish The number of IKE Phase 1 SA's that can be succesfully re-
per second. establish per second.
Discussion: Discussion:
Although the Phase 1 Rekey Rate has less impact on the forwarding Although the IKE Phase 1 Rekey Rate has less impact on the
behavior of traffic that requires security services then the Phase forwarding behavior of traffic that requires security services
2 Rekey Rate, it can pose a large burden on the CPU or network then the IKE Phase 2 Rekey Rate, it can pose a large burden on the
processor of the IPsec Device. Due to the highly computational CPU or network processor of the IPsec Device. Due to the highly
nature of a Phase 1 exchange, it may impact the stability of computational nature of a Phase 1 exchange, it may impact the
Active Tunnels in the network when the IPsec Device fails to stability of Active Tunnels in the network when the IPsec Device
properly rekey an IKE Tunnel. fails to properly rekey an IKE Phase 1 SA.
Measurement Units: Measurement Units:
Rekey's per second Tunnel Rekeys per second (TRPS)
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 2 Rekey Rate IKE Phase 2 Rekey Rate
10.6.2 Phase 2 Rekey Rate 10.7.2. IKE Phase 2 Rekey Rate
Definition: Definition:
The number of Phase 2 SA's that can be succesfully re-negotiated The number of IKE Phase 2 SA's that can be succesfully re-
per-second. negotiated per second.
Discussion: Discussion:
Although many implementations will usually derive new keying Although many implementations will usually derive new keying
material before the old keys expire, there may still be a period material before the old keys expire, there may still be a period
of time where frames get dropped before the phase 2 tunnels are of time where frames get dropped before the IKE Phase 2 tunnels
successfully re-established. There may also be some packetloss are successfully re-established. There may also be some packet
introduced when the handover of traffic is done from the expired loss introduced when the handover of traffic is done from the
SA to the newly negotiated SA. To measure the phase 2 rekey rate, expired IPsec SA's to the newly negotiated IPsec SA's. To measure
the measurement will require an IPsec aware test device to act as the IKE Phase 2 rekey rate, the measurement will require an IPsec
a responder when negotiating the new phase 2 keying material. aware test device to act as a responder when negotiating 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:
Rekey's per second Tunnel Rekeys per second (TRPS)
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 1 Rekey Rate IKE Phase 1 Rekey Rate
10.7 Tunnel Failover Time (TFT)
Definition:
Time required to recover all tunnels on a stanby IPsec device,
after a catastrophic failure occurs on the active IPsec device.
Discussion:
Recovery time required to re-establish all tunnels and reroute all
traffic on a standby node or other failsafe system after a failure
has occurred. Failure can include but are not limited to a
catastrophic IPsec Device failure, a encryption engine failure,
link outage. The recovery time is delta between the point of
failure and the time the first packet is seen on the last restored
tunnel on the backup device.
Measurement Units:
Time units with enough precision to reflect Tunnel Failover Time.
Issues:
N/A
10.8 IKE DOS Resilience Rate 10.8. IPsec Tunnel Failover Time
Definition: Definition:
The IKE Denial Of Service (DOS) Resilience Rate provides a rate of Time required to recover all IPsec Tunnels on a stanby IPsec
invalid or mismatching IKE tunnels setup attempts at which it is Device, after a catastrophic failure occurs on the active IPsec
no longer possible to set up a valid IKE tunnel. Device.
Discussion: Discussion:
The IKE DOS Resilience Rate will provide a metric to how robust Recovery time required to re-establish all IPsec Tunnels and
and hardened an IPsec device is against malicious attempts to set reroute all traffic on a standby node or other failsafe system
up a tunnel. after a failure has occurred in the DUT/SUT. Failure can include
but are not limited to a catastrophic IPsec Device failure, a
IKE DOS attacks can pose themselves in various forms and do not encryption engine failure, link outage. The recovery time is
necessarily have to have a malicious background. It is sufficient delta between the point of failure and the time the first packet
to make a typographical error in a shared secret in an IPsec is seen on the last restored IPsec Tunnel on the backup device.
aggregation 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 a non-negligible time an a
CPU in the IPsec device.
Depending on how many of these messages have to be processed, a
system might end up in a state that it is only doing key exchanges
and burdening the CPU for any other processes that might be
running in the IPsec device. At this point it will be no longer
possible to process a valid IKE tunnel setup request and thus IKE
DOS is in effect.
Measurement Units: Measurement Units:
Tunnel Attempts Per Seconds (TAPS) Time units with enough precision to reflect IPsec Tunnel Failover
Time.
Issues: Issues:
N/A 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
skipping to change at page 52, line 41 skipping to change at page 52, line 45
document: Debby Stopp, Ixia. document: Debby Stopp, Ixia.
13. Contributors 13. Contributors
The authors would like to acknowledge the following individual for The authors would like to acknowledge the following individual for
their significant help, guidance, and contributions to this document: their significant help, guidance, and contributions to this document:
Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI. Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI.
14. References 14. References
14.1 Normative References 14.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 14 skipping to change at page 54, line 20
March 1999. March 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
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,
"Negotiation of NAT-Traversal in the IKE", RFC 3947,
January 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-nat-t-ike]
Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
draft-ietf-ipsec-nat-t-ike-08 (work in progress),
February 2004.
[I-D.ietf-ipsec-udp-encaps]
Huttunen, A., "UDP Encapsulation of IPsec Packets",
draft-ietf-ipsec-udp-encaps-09 (work in progress),
May 2004.
[I-D.ietf-ipsec-nat-reqts]
Aboba, B. and W. Dixon, "IPsec-NAT Compatibility
Requirements", draft-ietf-ipsec-nat-reqts-06 (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 14.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
Michele Bustos Merike Kaeo
IXIA Double Shot Security
26601 W. Agoura Rd. 520 Washington Blvd #363
Calabasas, CA 91302 Marina Del Rey, CA 90292
US US
Phone: +1 (818)444-3244 Phone: +1 (310)866-0165
Email: mbustos@ixiacom.com Email: kaeo@merike.com
Tim Van Herck Tim Van Herck
Cisco Systems Cisco Systems
170 West Tasman Dr. 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
US US
Phone: +1 (408)527-2461
Email: herckt@cisco.com Email: herckt@cisco.com
Merike Kaeo Michele Bustos
Double Shot Security IXIA
520 Washington Blvd #363 26601 W. Agoura Rd.
Marina Del Rey, CA 90292 Calabasas, CA 91302
US US
Phone: +1 (310)866-0165 Phone: +1 (818)444-3244
Email: kaeo@merike.com Email: mbustos@ixiacom.com
Intellectual Property Statement Intellectual Property Statement
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
 End of changes. 233 change blocks. 
665 lines changed or deleted 648 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/