draft-ietf-bmwg-ipsec-term-04.txt   draft-ietf-bmwg-ipsec-term-05.txt 
Benchmarking Working Group M. Bustos Benchmarking Working Group M. Bustos
Internet-Draft IXIA Internet-Draft IXIA
Expires: January 30, 2005 T. Van Herck Expires: August 22, 2005 T. Van Herck
Cisco Systems Cisco Systems
M. Kaeo M. Kaeo
Double Shot Security Double Shot Security
August 2004 February 18, 2005
Terminology for Benchmarking IPSec Devices Terminology for Benchmarking IPsec Devices
draft-ietf-bmwg-ipsec-term-04 draft-ietf-bmwg-ipsec-term-05
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as other groups may also distribute working documents as
Internet-Drafts. Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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 http:// The list of current Internet-Drafts can be accessed at
www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 30, 2005. This Internet-Draft will expire on August 22, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
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 . . . . . . . . . . . . . . . . . . . . . 8 4. Definition Format . . . . . . . . . . . . . . . . . . . . . 9
5. Key Words to Reflect Requirements . . . . . . . . . . . . . 9 5. Key Words to Reflect Requirements . . . . . . . . . . . . . 10
6. Existing Benchmark Definitions . . . . . . . . . . . . . . . 9 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . 10
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3.1 IKEv1 Phase 1 . . . . . . . . . . . . . . . . . . . . 12 7.3.1 IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 13
7.3.2 IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 12 7.3.2 IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 13
7.3.3 IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 13 7.3.3 IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 14
7.3.4 IKEv2 Phase 1 . . . . . . . . . . . . . . . . . . . . 13 7.3.4 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 15
7.3.5 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 14 7.3.5 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 15
7.3.6 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 15 7.4 Security Association (SA) . . . . . . . . . . . . . . . . 16
7.4 Security Association (SA) . . . . . . . . . . . . . . . . 15
7.5 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 16 7.5 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 16
7.6 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 17 7.6 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 17
7.6.1 Initiator . . . . . . . . . . . . . . . . . . . . . . 17 7.6.1 Initiator . . . . . . . . . . . . . . . . . . . . . . 18
7.6.2 Responder . . . . . . . . . . . . . . . . . . . . . . 18 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 . . . . . . . . . . . . . . . . . . . . . 19
7.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.7.1 IKE Tunnel . . . . . . . . . . . . . . . . . . . . . . 20 7.7.1 IKE Tunnel . . . . . . . . . . . . . . . . . . . . . . 20
7.7.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 20 7.7.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 21
7.7.3 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 21 7.7.3 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 21
7.7.4 Configured Tunnel . . . . . . . . . . . . . . . . . . 22 7.7.4 Configured Tunnel . . . . . . . . . . . . . . . . . . 22
7.7.5 Established Tunnel . . . . . . . . . . . . . . . . . . 22 7.7.5 Established Tunnel . . . . . . . . . . . . . . . . . . 23
7.7.6 Active Tunnel . . . . . . . . . . . . . . . . . . . . 23 7.7.6 Active Tunnel . . . . . . . . . . . . . . . . . . . . 23
7.8 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 24 7.8 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 24
7.8.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . 24 7.8.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . 24
7.8.2 Transport Adjacency . . . . . . . . . . . . . . . . . 25 7.8.2 Transport Adjacency . . . . . . . . . . . . . . . . . 25
7.9 Transform protocols . . . . . . . . . . . . . . . . . . . 25 7.9 Transform protocols . . . . . . . . . . . . . . . . . . . 26
7.9.1 Authentication Protocols . . . . . . . . . . . . . . . 26 7.9.1 Authentication Protocols . . . . . . . . . . . . . . . 26
7.9.2 Encryption Protocols . . . . . . . . . . . . . . . . . 26 7.9.2 Encryption Protocols . . . . . . . . . . . . . . . . . 27
7.10 IPSec Protocols . . . . . . . . . . . . . . . . . . . . 27 7.10 IPsec Protocols . . . . . . . . . . . . . . . . . . . . 27
7.10.1 Authentication Header (AH) . . . . . . . . . . . . . 28 7.10.1 Authentication Header (AH) . . . . . . . . . . . . . 28
7.10.2 Encapsulated Security Payload (ESP) . . . . . . . . 28 7.10.2 Encapsulated Security Payload (ESP) . . . . . . . . 29
7.11 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . 29 7.11 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . 29
7.12 IP Compression . . . . . . . . . . . . . . . . . . . . . 30 7.12 IP Compression . . . . . . . . . . . . . . . . . . . . . 30
7.13 Security Context . . . . . . . . . . . . . . . . . . . . 30 7.13 Security Context . . . . . . . . . . . . . . . . . . . . 31
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 8.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34
8.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 34 8.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 35
9. Performance Metrics . . . . . . . . . . . . . . . . . . . . 35 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . 36
9.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 35 9.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 36
9.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 36 9.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 36
9.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 36 9.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 37
10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . 37 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . 37
10.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . 37 10.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . 37
10.1.1 Tunnel Throughput . . . . . . . . . . . . . . . . . 37 10.1.1 Tunnel Throughput . . . . . . . . . . . . . . . . . 37
10.1.2 IPsec Encryption Throughput . . . . . . . . . . . . 38 10.1.2 IPsec Encryption Throughput . . . . . . . . . . . . 38
10.1.3 IPsec Decryption Throughput . . . . . . . . . . . . 38 10.1.3 IPsec Decryption Throughput . . . . . . . . . . . . 39
10.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . 39 10.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . 40
10.2.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . 39 10.2.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . 40
10.2.2 IPsec Tunnel Encryption Latency . . . . . . . . . . 40 10.2.2 IPsec Tunnel Encryption Latency . . . . . . . . . . 40
10.2.3 IPsec Tunnel Decryption Latency . . . . . . . . . . 41 10.2.3 IPsec Tunnel Decryption Latency . . . . . . . . . . 41
10.2.4 Time To First Packet . . . . . . . . . . . . . . . . 41 10.2.4 Time To First Packet . . . . . . . . . . . . . . . . 42
10.3 Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 42 10.3 Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 43
10.3.1 IPSec Tunnel Frame Loss . . . . . . . . . . . . . . 42 10.3.1 IPsec Tunnel Frame Loss . . . . . . . . . . . . . . 43
10.3.2 IPsec Tunnel Encryption Frame Loss . . . . . . . . . 43 10.3.2 IPsec Tunnel Encryption Frame Loss . . . . . . . . . 43
10.3.3 IPsec Tunnel Decryption Frame Loss . . . . . . . . . 43 10.3.3 IPsec Tunnel Decryption Frame Loss . . . . . . . . . 44
10.3.4 Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . 44 10.3.4 Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . 45
10.4 Back-to-back Frames . . . . . . . . . . . . . . . . . . 45 10.4 Back-to-back Frames . . . . . . . . . . . . . . . . . . 45
10.4.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . 45 10.4.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . 45
10.4.2 Encryption Back-to-back Frames . . . . . . . . . . . 45 10.4.2 Encryption Back-to-back Frames . . . . . . . . . . . 46
10.4.3 Decryption Back-to-back Frames . . . . . . . . . . . 46 10.4.3 Decryption Back-to-back Frames . . . . . . . . . . . 47
10.5 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . 47 10.5 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . 47
10.5.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . 47 10.5.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . 47
10.5.2 Phase 1 Setup Rate . . . . . . . . . . . . . . . . . 47 10.5.2 Phase 1 Setup Rate . . . . . . . . . . . . . . . . . 48
10.5.3 Phase 2 Setup Rate . . . . . . . . . . . . . . . . . 48 10.5.3 Phase 2 Setup Rate . . . . . . . . . . . . . . . . . 49
10.6 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . 49 10.6 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . 49
10.6.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . 49 10.6.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . 49
10.6.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . 49 10.6.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . 50
10.7 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . 50 10.7 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . 51
10.8 IKE DOS Resilience Rate . . . . . . . . . . . . . . . . 51 10.8 IKE DOS Resilience Rate . . . . . . . . . . . . . . . . 51
11. Security Considerations . . . . . . . . . . . . . . . . . . 52 11. Security Considerations . . . . . . . . . . . . . . . . . . 52
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 52 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53
14.1 Normative References . . . . . . . . . . . . . . . . . . . 52 14.1 Normative References . . . . . . . . . . . . . . . . . . 53
14.2 Informative References . . . . . . . . . . . . . . . . . . 54 14.2 Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 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 15 skipping to change at page 7, line 15
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 SAs (one in each direction) are Because an SA is unidirectional, two SA's (one in each direction) are
required to secure typical, bidirectional communication between two required to secure typical, bidirectional communication between two
entities. The security services associated with an SA can be used entities. The security services associated with an SA can be used
for AH or ESP, but not for both. If both AH and ESP protection is for AH or ESP, but not for both. If both AH and ESP protection is
applied to a traffic stream, two (or more) SAs are created for each applied to a traffic stream, two (or more) SA's are created for each
direction to protect the traffic stream. direction to protect the traffic stream.
The SA is uniquely identified by the security parameter index (SPI) The SA is uniquely identified by the Security Parameter Index (SPI)
[RFC2406]. When a system sends a packet that requires IPsec [RFC2406]. When a system sends a packet that requires IPsec
protection, it looks up the SA in its database and applies the protection, it looks up the SA in its database and applies the
specified processing and security protocol (AH/ESP), inserting the specified processing and security protocol (AH/ESP), inserting the
SPI from the SA into the IPsec header. When the IPsec peer receives SPI from the SA into the IPsec header. When the IPsec peer receives
the packet, it looks up the SA in its database by destination the packet, it looks up the SA in its database by destination
address, protocol, and SPI and then processes the packet as required. address, protocol, and SPI and then processes the packet as required.
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 distribution of keys is supported. IKE is specified as the
public-key-based approach for automatic key management. public-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 SAs in a secure and negotiate and derive keying material for SA's in a secure and
authenticated manner: authenticated manner:
1. ISAKMP [RFC2408] (Internet Security Association and Key 1. ISAKMP [RFC2408] (Internet Security Association and Key
Management Protocol), which provides a framework for Management Protocol), which provides a framework for
authentication and key exchange but does not define them. ISAKMP authentication and key exchange but does not define them. ISAKMP
is designed to be key exchange independent; it is designed to is designed to be key exchange independent; it is designed to
support many different key exchanges. support many different key exchanges.
2. Oakley [RFC2412], which describes a series of key exchanges, 2. Oakley [RFC2412], which describes a series of key exchanges,
called modes, and details the services provided by each (for called modes, and details the services provided by each (for
skipping to change at page 8, line 16 skipping to change at page 9, line 16
Note that both digital signature and public-key cryptography require Note that both digital signature and public-key cryptography require
the use of digital certificates to validate the public/private key the use of digital certificates to validate the public/private key
mapping. IKE allows the certificate to be accessed independently or mapping. IKE allows the certificate to be accessed independently or
by having the two devices explicitly exchange certificates as part of by having the two devices explicitly exchange certificates as part of
IKE. Both parties must have a shared session key to encrypt the IKE IKE. Both parties must have a shared session key to encrypt the IKE
tunnel. The Diffie-Hellman protocol is used to agree on a common tunnel. The Diffie-Hellman protocol is used to agree on a common
session key. session key.
In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's
will be called IPsec SAs. These IPsec SA's use a different shared will be called IPsec SA's. These IPsec SA's use a different shared
key than that used for the IKE_SA. The IPsec SA shared key can be key than that used for the IKE_SA. The IPsec SA shared key can be
derived by using Diffie-Hellman again or by refreshing the shared key derived by using Diffie-Hellman again or by refreshing the shared key
derived from the original Diffie-Hellman exchange that generated the derived from the original Diffie-Hellman exchange that generated the
IKE_SA by hashing it with nonces. Once the shared key is derived and IKE_SA by hashing it with nonces. Once the shared key is derived and
additional communication parameters are negotiated, the IPsec SA's additional communication parameters are negotiated, the IPsec SA's
are established and traffic can be exchanged using the negotiated are established and traffic can be exchanged using the negotiated
parameters. Note that for IKEv2, the term CHILD-SA is used for what parameters.
we call an IPsec SA.
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 IKEv1. We want to testing terminology for IPsec devices that support IKEv1. We want to
constrain the terminology specified in this document to meet the constrain the terminology specified in this document to meet the
requirements of the Methodology for Benchmarking IPSec Devices requirements of the Methodology for Benchmarking IPsec Devices
documented test methodologies. The testing will be constrained to documented test methodologies. The testing will be constrained to
devices acting as IPsec gateways and will pertain to both IPsec devices acting as IPsec gateways and will pertain to both IPsec
tunnel and transport mode. 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). This document will encompass minimum ARP caches and routing tables).
updates to AH, ESP and NAT Traversal. Since NAT traversal has been
included in the document, NAT is not included in this document.
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 9, line 47 skipping to change at page 10, line 47
standards track documents as clear as possible. While this document standards track documents as clear as possible. While this document
uses these keywords, this document is not a standards track document. uses these keywords, this document is not a standards track document.
6. Existing Benchmark Definitions 6. Existing Benchmark Definitions
It is recommended that readers consult [RFC1242], [RFC2544] and It is recommended that readers consult [RFC1242], [RFC2544] and
[RFC2285] before making use of this document. These and other IETF [RFC2285] before making use of this document. These and other IETF
Benchmarking Methodology Working Group (BMWG) router and switch Benchmarking Methodology Working Group (BMWG) router and switch
documents contain several existing terms relevant to benchmarking the documents contain several existing terms relevant to benchmarking the
performance of IPsec devices. The conceptual framework established performance of IPsec devices. The conceptual framework established
in these earlier RFCs will be evident in this document. in these earlier RFC's will be evident in this document.
This document also draws on existing terminology defined in other This document also draws on existing terminology defined in other
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]
Note: "DUT/SUT" refers to a metric that may be applicable to a DUT
(Device Under Test) or an SUT (System Under Test).
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:
skipping to change at page 11, line 46 skipping to change at page 12, line 42
* Oakley, which describes a series of key exchanges, called * Oakley, which describes a series of key exchanges, called
modes, and details the services provided by each (for example, modes, and details the services provided by each (for example,
perfect forward secrecy for keys, identity protection, and perfect forward secrecy for keys, identity protection, and
authentication). [RFC2412] authentication). [RFC2412]
* [SKEME] (Secure Key Exchange Mechanism for Internet), which * [SKEME] (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that provides describes a versatile key exchange technique that provides
anonymity, reputability, and quick key refreshment. anonymity, reputability, and quick key refreshment.
Note that IKE is an optional protocol within the IPsec framework. Note that IKE is an optional protocol within the IPsec framework.
Tunnels may also be manually configured i.e. the administrator Tunnels may also be manually configured i.e. the network
will provide keys that will be associated with the Phase 2 SA's as administrator will provide keys that will be associated with the
long as the IPsec Tunnel is configured. This method is the most Phase 2 SA's as long as the IPsec Tunnel is configured. This
basic mechanism to establish an IPsec tunnel between two IPsec method is the most basic mechanism to establish an IPsec tunnel
devices but it also decreases the level of protection since the between two IPsec devices but it also reduces the level of
keys are not changing as they normally would during an IKE phase 2 protection since the keys are static and as a result are more
rekey. prone to various attacks. When IKE is employed as a key
management protocol, the keys will change on a regular basis (time
and/or traffic volume based) as part of the IKE rekeying
mechanism.
Issues: Issues:
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 IKEv1 Phase 1 7.3.1 IKE Phase 1
Definition: Definition:
The shared policy and key(s) used by negotiating peers to set up a The shared policy and key(s) used by negotiating peers to
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
traffic. If IKE is employed all SPI information will be exchanged
between the IPsec devices. This has to be done in a secure
fashion and for that reason IKE will set up a secure "control
channel" over which it can exchange this information.
Note that IKE is an optional protocol within the IPsec framework Note that IKE is an optional protocol within the IPsec framework
and keys can also be manually configured. and keys can also be manually configured.
Issues: Issues:
In other 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
skipping to change at page 13, line 48 skipping to change at page 15, line 5
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 IKEv2 Phase 1 7.3.4 IKE Phase 2
Definition:
IKEv2 calls the IKEv1 Phase 1 the IKEv2 Initial Exchange.
Discussion:
IKEv2 uses 2 exchanges (i.e. four messages) to complete its
initial exchange. The first pair of messages (IKE_SA_INIT)
negotiate cryptographic algorithms, exchange nonces and do a
Diffie-Hellman exchange. The second pair of messages (IKE_AUTH)
authenticate the previous messages, exchange identities and
certificates, and establish the first CHILD_SA. Parts of the
IKE_AUTH messages are encrypted and integrity protected with keys
established through the IKE_SA_INIT exchange.
Issues:
In some scenarios, only a single CHILD_SA is needed between IPsec
endpoints and therefore there would be no additional exchanges.
However, subsequent exchanges (i.e. the CREATE_CHILD_SA exchange)
are often used for re-keying purposes.
See Also:
ISAKMP, IKE, IKEv1 Phase 1, Phase 1 Main Mode
7.3.5 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 to regenerate the key being used for
IPsec (called "rekeying"), as well as for exchanging informational IPsec (called "rekeying"), as well as for exchanging informational
messages. messages.
IKEv2 calls the IKEv1 phase 2 the IKEv2 CREATE_CHILD_SA Exchange.
These messages are used to create additional CHILD_SAs between
IPsec endpoints or to re-key existing CHILD-SAs.
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.6 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
used to protect the user data, i.e. the IPsec SA. Three used to protect the user data, i.e. the IPsec SA. Three
different messages are exchanged, which are protected by the different messages are exchanged, which are protected by the
security parameters negotiated by the IKE phase 1 exchange. An security parameters negotiated by the IKE phase 1 exchange. An
additional Diffie-Hellman exchange may be performed if PFS additional Diffie-Hellman exchange may be performed if PFS
(Perfect Forward Secrecy) is enabled. (Perfect Forward Secrecy) is enabled.
The IKEv2 CREATE_CHILD_SA exchange consists of a single request/
response pair. These messages are cryptographically protected
using the cryptographic algorithms and keys negotiated in the
IKE_SA_INIT messages.
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
require authentication and/or encryption services. It is a
negotiation agreement between two IPsec devices, specifically the
Initiator and Responder.
Discussion:
A simplex (unidirectional) logical connection that links a traffic A simplex (unidirectional) logical connection that links a traffic
flow to a set of security parameters. All traffic traversing an flow to a set of security parameters. All traffic traversing an
SA is provided the same security processing and will be subjected SA is provided the same security processing and will be subjected
to a common set of encryption and/or authentication algorithms. to a common set of encryption and/or authentication algorithms.
In IPsec, an SA is an Internet layer abstraction implemented In IPsec, an SA is an Internet layer abstraction implemented
through the use of AH or ESP as defined in [RFC2401]. through the use of AH or ESP as defined in [RFC2401].
Discussion:
A set of policy and key(s) used to protect information. It is a
negotiation agreement between two IPsec devices, specifically the
Initiator and Responder.
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 encryption and/or authentication 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.
After classification, a decision can be made if the traffic needs After classification, a decision can be made if the traffic needs
to be encrypted/decrypted and how this should be done depending on to be encrypted/decrypted and how this should be done depending on
the SA linked to the traffic flow. Simply put, selectors classify the SA linked to the traffic flow. Simply put, selectors classify
skipping to change at page 17, line 42 skipping to change at page 18, line 9
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 devices which starts the negotiation of IKE Phase 1 and An IPsec device which starts the negotiation of IKE Phase 1 and
Phase 2 tunnels. Phase 2 tunnels.
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
tunnel to send the traffic through, it is the responsibility of tunnel to send the traffic through, it is the responsibility of
the IPsec device to start a negotiation process that will the IPsec device to start a negotiation process that will
instantiate the IPsec tunnel. This process will establish an IKE instantiate the IPsec tunnel. This process will establish an IKE
Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's, Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's,
skipping to change at page 19, line 32 skipping to change at page 19, line 44
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 :
Responds to tunnel setup request from IPSec Clients. Responds to tunnel setup request from IPsec Clients.
Responds to tunnel setup request from other IPsec devices Responds to tunnel setup request from other IPsec devices
(Initiators). (Initiators).
Initiate tunnels to other IPsec servers inside or outside the Initiate tunnels to other IPsec servers inside or outside the
private network. private network.
Issues: Issues:
IPsec Servers are also sometimes referred to as 'VPN IPsec Servers are also sometimes referred to as 'VPN
skipping to change at page 20, line 44 skipping to change at page 21, line 11
Also referred to as an ISAKMP SA or IKE SA or Phase 1 Tunnel. Also referred to as an ISAKMP SA or IKE SA or Phase 1 Tunnel.
See Also: See Also:
Tunnel, IPsec Tunnel, Security Association, IKE, IKE Phase 1 Tunnel, IPsec Tunnel, Security Association, IKE, IKE Phase 1
7.7.2 IPsec Tunnel 7.7.2 IPsec Tunnel
Definition: Definition:
One or more Phase 2 SA's that are negotiated in conjuntion with an One or more Phase 2 SA's that are negotiated in conjunction with
IKE Tunnel. an IKE Tunnel.
Discussion: Discussion:
In the case of simplex communication, a single phase 2 SA. In the case of simplex communication, a single phase 2 SA.
In the more likely case where bidirectional communication is In the more likely case where bidirectional communication is
needed it is a pair (2) Phase 2 SA's. The two SA's are used to needed it is a pair (2) Phase 2 SA's. The two SA's are used to
secure inbound and outbound traffic. secure inbound and outbound traffic.
Not in all situations is it required to have an existing IKE Not in all situations is it required to have an existing IKE
Tunnel in order to negotiate IPsec Tunnel properties and Tunnel in order to negotiate IPsec Tunnel properties and
parameters. Manually keyed tunnels allow the set up of IPsec parameters. Manually keyed tunnels allow the set up of IPsec
Tunnels without the need of the IKE protocol. Tunnels without the need of the IKE protocol.
Issues: Issues:
If not explicitly specified it SHALL be assumed that an IPsec
Tunnel is a pair (2) Phase 2 SA's.
Also referred to as a Phase 2 Tunnel or a Phase 2 SA (may be Also referred to as a Phase 2 Tunnel or a Phase 2 SA (may be
multiple). multiple).
See Also: See Also:
Tunnel, IKE Tunnel, Security Association, IKE, IKE Phase 2 Tunnel, IKE Tunnel, Security Association, IKE, IKE Phase 2
7.7.3 Tunnel 7.7.3 Tunnel
Definition: Definition:
skipping to change at page 22, line 9 skipping to change at page 22, line 20
context." context."
See Also: See Also:
IKE Tunnel, IPsec Tunnel IKE Tunnel, IPsec Tunnel
7.7.4 Configured Tunnel 7.7.4 Configured Tunnel
Definition: Definition:
A tunnel that is present in the IPSec device's configuration but A tunnel that is present in the IPsec device's configuration but
does not have any entries in the SADBi.e. SA's. does not have any entries in the SADB (Security Association
DataBase) i.e. SA's.
Discussion: Discussion:
Several steps are required before a Tunnel can be used to actually Several steps are required before a Tunnel can be used to actually
transport traffic. The very first step is to configure the tunnel transport traffic. The very first step is to configure the tunnel
in the IPsec device. In that way packet classification can make a in the IPsec device. In that way packet classification can make a
decision if it is required to start negotiating SA's. At this decision if it is required to start negotiating SA's. At this
time there are no SA's associated with the Tunnel and no traffic time there are no SA's associated with the Tunnel and no traffic
is going through the IPsec device that matches the Selectors, is going through the IPsec device that matches the Selectors,
which would instantiate the Tunnel. which would instantiate the Tunnel.
A Configured Tunnel is also a tunnel that has relinquished all A Configured Tunnel is also a tunnel that has relinquished all
it's SA's and is not transmitting data anymore. To be more it's SA's and is not transmitting data anymore. To be more
specific, when an Established or an Active Tunnel is terminated specific, when an Established or an Active Tunnel is terminated
due to either an administrative action or an IKE event that teared due to either an administrative action or an IKE event that
down the tunnel, the tunnel will be back in a configured state. deactivated the tunnel, the tunnel will be back in a configured
state.
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel, Established Tunnel, Active Tunnel Tunnel, Established Tunnel, Active Tunnel
7.7.5 Established Tunnel 7.7.5 Established Tunnel
skipping to change at page 23, line 35 skipping to change at page 24, line 7
A tunnel that has completed Phase 1 and Phase 2 SA negotiations A tunnel that has completed Phase 1 and Phase 2 SA negotiations
and is forwarding data. and is forwarding data.
Discussion: Discussion:
When a Tunnel is Established and it is transporting traffic, the When a Tunnel is Established and it is transporting traffic, the
tunnel is called 'Active'. tunnel is called 'Active'.
Issues: Issues:
The distinction between an Active Tunnel and Configured/ The distinction between an Active Tunnel and
Established Tunnel is made in the context of manual keyed Tunnels. Configured/Established Tunnel is made in the context of manual
In this case it would be possible to have an Established tunnel on keyed Tunnels. In this case it would be possible to have an
an IPsec device which has no counterpart on it's corresponding Established tunnel on an IPsec device which has no counterpart on
peer. This will lead to encrypted traffic flows which will be it's corresponding peer. This will lead to encrypted traffic
discarded on the receiving peer. Only if both peers have an flows which will be discarded on the receiving peer. Only if both
Established Tunnel that shows evidence of traffic transport, it peers have an Established Tunnel that shows evidence of traffic
may be called an Active Tunnel. transport, it may be called an Active Tunnel.
See Also: See Also:
Tunnel, Configured Tunnel, Established Tunnel 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 :
skipping to change at page 25, line 32 skipping to change at page 26, line 4
[GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
| | | | | | | |
| | | | | | | |
| +------{SA1 (ESP transport)}--------+ | | +------{SA1 (ESP transport)}--------+ |
| | | |
+-------------{SA2 (AH transport)}--------------+ +-------------{SA2 (AH transport)}--------------+
In the IP Cloud a packet would have a format like this : In the IP Cloud a packet would have a format like this :
[IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH]
Issues: Issues:
This is rarely used. 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
gateways as depicted in the Nested Tunnels figure. The packet
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
skipping to change at page 26, line 37 skipping to change at page 27, line 8
Authentication protocols provide no confidentiality. Commonly Authentication protocols provide no confidentiality. Commonly
used authentication algorithms/protocols are: used authentication algorithms/protocols are:
* MD5-HMAC * MD5-HMAC
* SHA-HMAC * SHA-HMAC
* AES-HMAC * AES-HMAC
Issues: Issues:
SHA-HMAC is thought to be more secure than MD5-HMAC and is often N/A
used. AES-HMAC is still fairly new and not in common use yet.
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.
skipping to change at page 27, line 19 skipping to change at page 27, line 34
* 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 Null option is a valid encryption mechanism although it reverts to
use of IPsec back to message authenticity but only for upper layer use of IPsec back to message authenticity but only for upper layer
protocols, and is commonly used. protocols.
DES has been officially deprecated by NIST, though it is still DES has been officially deprecated by NIST, though it is still
mandated RFC and is still commonly implemented and used due to mandated by the IPsec framework and is still commonly implemented
it's speed advantage over 3DES. 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
single oparation nature which translates into a speed 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 confidentiality, data integrity, and data
authenticity between participating peers at the IP layer. The authenticity between participating peers at the IP layer. The
IPsec protocol suite set of standards is documented in [RFC2401] IPsec protocol suite set of standards is documented in [RFC2401]
through [RFC2412] and [RFC2451]. through [RFC2412] and [RFC2451].
Discussion: Discussion:
skipping to change at page 28, line 32 skipping to change at page 29, line 4
in transport mode, all upper-layer information is protected, and in transport mode, all upper-layer information is protected, and
all fields in the IPv4 header excluding the fields typically are all fields in the IPv4 header excluding the fields typically are
modified in transit. modified in transit.
Original IPv4 packet : Original IPv4 packet :
[IP ORIG][L4 HDR][PAYLOAD] [IP ORIG][L4 HDR][PAYLOAD]
In transport mode : In transport mode :
[IP ORIG][AH][L4 HDR][PAYLOAD] [IP ORIG][AH][L4 HDR][PAYLOAD]
In tunnel mode : In tunnel mode :
[IP NEW][AH][IP ORIG][L4 HDR][PAYLOAD] [IP NEW][AH][IP ORIG][L4 HDR][PAYLOAD]
Issues: Issues:
AH is rarely used/implemented. 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:
skipping to change at page 30, line 11 skipping to change at page 30, line 31
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 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:
skipping to change at page 30, line 41 skipping to change at page 31, line 16
applied to IP datagrams. Encrypting the IP datagram causes the applied to IP datagrams. Encrypting the IP datagram causes the
data to be random in nature, rendering compression at lower data to be random in nature, rendering compression at lower
protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) protocol layers (e.g., PPP Compression Control Protocol [RFC1962])
ineffective. If both compression and encryption are required, ineffective. If both compression and encryption are required,
compression must be applied before encryption. compression must be applied before encryption.
Issues: Issues:
N/A N/A
See Also:
IKE, ISAKMP, IPsec Device
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 a tunnel will take, describe the characteristics of the path that a tunnel will take,
all of the tunnel parameters and the effects it has on the all of the tunnel parameters and the effects it has on the
underlying protected traffic. Security Context encompasses underlying protected traffic. Security Context encompasses
protocol suite and security policy(ies). 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 tunnels and to secure the traffic between were used to establish tunnels and to secure the traffic between
protected networks. Security Context is not a metric; it is protected networks. Security Context is not a metric; it is
included to accurately reflect the test environment variables when included to accurately reflect the test environment variables when
reporting the methodology results. To avoid listing too much reporting the methodology results. To avoid listing too much
information when reporting metrics, we have divided the security information when reporting metrics, we have divided the security
skipping to change at page 41, line 18 skipping to change at page 41, line 41
The IPsec Tunnel decryption Latency is the time interval starting The IPsec Tunnel decryption Latency is the time interval starting
when the end of the first bit of the encrypted frame reaches the when the end of the first bit of the encrypted frame reaches the
input interface, through an IPsec tunnel, and ending when the input interface, through an IPsec tunnel, and ending when the
start of the first bit of the decrypted output frame is seen on start of the first bit of the decrypted output frame is seen on
the output interface. the output interface.
Discussion: Discussion:
IPsec Tunnel decryption latency is the latency introduced when IPsec Tunnel decryption latency is the latency introduced when
decrypting traffic through an IPsec tunnel. Like encryption/ decrypting traffic through an IPsec tunnel. Like
decryption throughput, it is not always the case that encryption encryption/decryption throughput, it is not always the case that
latency equals the decryption latency. Therefore a distinction encryption latency equals the decryption latency. Therefore a
between the two has to be made in order to get a more accurate distinction between the two has to be made in order to get a more
view of where the latency is the most pronounced. 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 tunnels. 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.
skipping to change at page 42, line 10 skipping to change at page 42, line 31
The Time To First Packet (TTFP) is the time required process an The Time To First Packet (TTFP) is the time required process an
cleartext packet when no tunnel is present. cleartext packet when no tunnel is present.
Discussion: Discussion:
The TTFP addresses the issue of responsiveness of an IPsec device The TTFP addresses the issue of responsiveness of an IPsec device
by looking how long it take to transmit a packet over a not yet by looking how long it take to transmit a packet over a not yet
established tunnel path. The TTFP MUST include the time to set up established tunnel path. The TTFP MUST include the time to set up
the tunnel, triggered by the traffic flow (both phase 1 and phase the tunnel, triggered by the traffic flow (both phase 1 and phase
2 setup times are included) and the time it takes to encrypt and 2 setup times are included) and the time it takes to encrypt and
decrypt the packet on a corresponding peer. decrypt the packet on a corresponding peer. In short it is the
tunnel setup time plus the propagation delay of the packet through
the 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 N/A
10.3 Frame Loss 10.3 Frame Loss
10.3.1 IPSec Tunnel Frame Loss 10.3.1 IPsec Tunnel Frame Loss
Definition: Definition:
Percentage of cleartext frames that should have been forwarded Percentage of cleartext frames that should have been forwarded
through a Tunnel under steady state (constant) load but were through a Tunnel under steady state (constant) load but were
dropped before encryption or after decryption. dropped before encryption or after decryption.
Discussion: Discussion:
The IPsec Tunnel Frame Loss is almost identically defined as Frame The IPsec Tunnel Frame Loss is almost identically defined as Frame
skipping to change at page 44, line 37 skipping to change at page 45, line 16
10.3.4 Phase 2 Rekey Frame Loss 10.3.4 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 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 Frame Loss of a traffic stream that is
protected by the Phase 2 SA's. Nevertheless there can be protected by the Phase 2 SA's. Nevertheless there can be
situations where Frame Loss occurs during the rekey process. situations where Frame Loss occurs during the 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
skipping to change at page 47, line 24 skipping to change at page 47, line 48
See Also: See Also:
Tunnel Back-to-back frames, Encryption back-to-back frames Tunnel Back-to-back frames, Encryption back-to-back frames
10.5 Tunnel Setup Rate Behavior 10.5 Tunnel Setup Rate Behavior
10.5.1 Tunnel Setup Rate 10.5.1 Tunnel Setup Rate
Definition: Definition:
The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per second The maximum number of tunnels (1 IKE SA + 2 IPsec SA's) per second
that an IPsec device can successfully establish. that an IPsec 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 tunnels on the DUT. Several factors may influence Tunnel Setup
Rate, such as: TAPS rate, Background cleartext traffic load on the Rate, such as: TAPS rate, Background cleartext traffic load on the
secure interface, Already established tunnels, Authentication secure interface, Already established tunnels, Authentication
method such as pre-shared keys, RSA-encryption, RSA-signature, DSS method such as pre-shared keys, RSA-encryption, RSA-signature, DSS
Key sizes used (when using RSA/DSS). Key sizes used (when using RSA/DSS).
skipping to change at page 52, line 44 skipping to change at page 53, line 25
[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.
[RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP [RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, December Payload Compression Protocol (IPComp)", RFC 2393, December
1998. 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
2402, November 1998. RFC 2402, November 1998.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998. ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within [RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998. ESP and AH", RFC 2404, November 1998.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998. Algorithm With Explicit IV", RFC 2405, November 1998.
skipping to change at page 53, line 27 skipping to change at page 54, line 8
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998. Its Use With IPsec", RFC 2410, November 1998.
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security [RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998. Document Roadmap", RFC 2411, November 1998.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
2412, November 1998. RFC 2412, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
1999. 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
2661, August 1999. RFC 2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March "Generic Routing Encapsulation (GRE)", RFC 2784, March
2000. 2000.
[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-14 (work in progress), June 2004. Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004.
[I-D.ietf-ipsec-dpd] [I-D.ietf-ipsec-dpd]
Huang, G., Beaulieu, S. and D. Rochefort, "A Traffic-Based Huang, G., Beaulieu, S. and D. Rochefort, "A Traffic-Based
Method of Detecting Dead IKE Peers", Method of Detecting Dead IKE Peers",
draft-ietf-ipsec-dpd-04 (work in progress), October 2003. Internet-Draft draft-ietf-ipsec-dpd-04, October 2003.
[I-D.ietf-ipsec-nat-t-ike] [I-D.ietf-ipsec-nat-t-ike]
Kivinen, T., "Negotiation of NAT-Traversal in the IKE", Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
draft-ietf-ipsec-nat-t-ike-08 (work in progress), February Internet-Draft draft-ietf-ipsec-nat-t-ike-08, February
2004. 2004.
[I-D.ietf-ipsec-udp-encaps] [I-D.ietf-ipsec-udp-encaps]
Huttunen, A., "UDP Encapsulation of IPsec Packets", Huttunen, A., "UDP Encapsulation of IPsec Packets",
draft-ietf-ipsec-udp-encaps-09 (work in progress), May Internet-Draft draft-ietf-ipsec-udp-encaps-09, May 2004.
2004.
[I-D.ietf-ipsec-nat-reqts] [I-D.ietf-ipsec-nat-reqts]
Aboba, B. and W. Dixon, "IPsec-NAT Compatibility Aboba, B. and W. Dixon, "IPsec-NAT Compatibility
Requirements", draft-ietf-ipsec-nat-reqts-06 (work in Requirements",
progress), October 2003. Internet-Draft draft-ietf-ipsec-nat-reqts-06, 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", Internet-Draft draft-ietf-ipsec-properties-02,
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, URI http://www.research.ibm.com/security/ Security,
skeme.ps, 1996. URI http://www.research.ibm.com/security/skeme.ps, 1996.
Authors' Addresses Authors' Addresses
Michele Bustos Michele Bustos
IXIA IXIA
26601 W. Agoura Rd. 26601 W. Agoura Rd.
Calabasas, CA 91302 Calabasas, CA 91302
US US
Phone: +1 (818)444-3244 Phone: +1 (818)444-3244
EMail: mbustos@ixiacom.com Email: mbustos@ixiacom.com
Tim Van Herck Tim Van Herck
Cisco Systems Cisco Systems
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134-1706 San Jose, CA 95134-1706
US US
Phone: +1 (408)527-2461 Phone: +1 (408)527-2461
EMail: herckt@cisco.com Email: herckt@cisco.com
Merike Kaeo Merike Kaeo
Double Shot Security Double Shot Security
520 Washington Blvd #363 520 Washington Blvd #363
Marina Del Rey, CA 90292 Marina Del Rey, CA 90292
US US
Phone: +1 (310)866-0165 Phone: +1 (310)866-0165
EMail: kaeo@merike.com Email: merike@doubleshotsecurity.com
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Intellectual Property 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 or other rights that might be claimed to intellectual property 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; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of standards-related documentation can be found in BCP 11. Copies of
claims of rights made available for publication and any assurances of claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to licenses to be made available, or the result of an attempt made to
obtain a general license or permission for the use of such obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 89 change blocks. 
195 lines changed or deleted 190 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/