draft-ietf-bmwg-ipsec-term-00.txt   draft-ietf-bmwg-ipsec-term-01.txt 
Network Working Group Michele Bustos Benchmarking Working Group M. Bustos
INTERNET-DRAFT IXIA Internet-Draft IXIA
Expires in: August 2003 Tim Van Herck Expires: December 30, 2003 T. Van Herck
Cisco Cisco Systems, Inc.
Merike Kaeo M. Kaeo
Merike, Inc. Merike, Inc.
Terminology for Benchmarking IPsec Devices Terminology for Benchmarking IPSec Devices
<draft-ietf-bmwg-ipsec-term-00.txt> draft-ietf-bmwg-ipsec-term-01
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
other groups may also distribute working documents as Internet- groups may also distribute working documents as Internet-Drafts.
Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are draft documents valid for a maximum of six months
months and may be updated, replaced, or obsoleted by other and may be updated, replaced, or obsoleted by other documents at any
documents at any time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts as reference
as reference material or to cite them other than as "work in material or to cite them other than as "work in progress."
progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at http://
http://www.ietf.org/ietf/1id-abstracts.txt 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 December 30, 2003.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). All Rights Reserved.
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 RFC 1242, RFC 2544, RFC 2285 and other IETF tenets set forth in RFC 1242, RFC 2544, RFC 2285 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 these efforts specific to the IPsec paradigm. The BMWG produces two
two major classes of documents: Benchmarking Terminology documents major classes of documents: Benchmarking Terminology documents and
and Benchmarking Methodology documents. The Terminology documents Benchmarking Methodology documents. The Terminology documents present
present the benchmarks and other related terms. The Methodology the benchmarks and other related terms. The Methodology documents
documents define the procedures required to collect the benchmarks define the procedures required to collect the benchmarks cited in the
cited in the corresponding Terminology documents. corresponding Terminology documents.
Table of Contents Table of Contents
1. INTRODUCTION...................................................4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. IPsec Fundamentals...........................................4 2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . 4
1.2. IPsec Operation..............................................6 2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6
1.2.1. Security Associations.....................................6 2.1.1 Security Associations . . . . . . . . . . . . . . . . . . 6
1.2.2. Key Management............................................6 2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . . . 6
1.2.3. Using the term 'Tunnel'...................................8 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . 8
2. DOCUMENT SCOPE.................................................8 4. Definition Format . . . . . . . . . . . . . . . . . . . . 8
5. Key Words to Reflect Requirements . . . . . . . . . . . . 9
3. DEFINITION FORMAT..............................................8 6. Existing Definitions . . . . . . . . . . . . . . . . . . . 9
7. Term Definitions . . . . . . . . . . . . . . . . . . . . . 10
4. KEY WORDS TO REFLECT REQUIREMENTS..............................9 7.1 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.1 Configured Tunnel . . . . . . . . . . . . . . . . . . . . 10
5. EXISTING DEFINITIONS...........................................9 7.1.2 Established Tunnel . . . . . . . . . . . . . . . . . . . . 11
7.1.3 Active Tunnel . . . . . . . . . . . . . . . . . . . . . . 11
6. TERM DEFINITIONS..............................................10 7.1.4 Terminated Tunnel . . . . . . . . . . . . . . . . . . . . 12
6.1. IPsec.......................................................10 7.2 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.2. IPsec Device................................................10 7.3 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 13
6.3. ISAKMP......................................................11 7.3.1 Initiator . . . . . . . . . . . . . . . . . . . . . . . . 14
6.4. IKE.........................................................11 7.3.2 Responder . . . . . . . . . . . . . . . . . . . . . . . . 14
6.5. Initiator...................................................12 7.3.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . . . 15
6.6. Responder...................................................12 7.3.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . . . 16
6.7. Security Association (SA)...................................13 7.4 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 16
6.8. IKE Phase 1.................................................13 7.5 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
6.8.1. Phase 1 Main Mode........................................13 7.6 Security Association (SA) . . . . . . . . . . . . . . . . 18
6.8.2. Phase 1 Aggressive Mode..................................14 7.7 IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . . . 18
6.9. IKE Phase 2.................................................14 7.7.1 Phase 1 Main Mode . . . . . . . . . . . . . . . . . . . . 19
6.9.1. Phase 2 Quick Mode.......................................14 7.7.2 Phase 1 Aggressive Mode . . . . . . . . . . . . . . . . . 19
6.9.2. IPsec Tunnel.............................................15 7.8 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 20
6.10. Compound Tunnels...........................................15 7.8.1 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . . . 20
6.10.1. Nested Tunnels...........................................15 7.8.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . . . 21
6.10.2. Transport Adjacency......................................16 7.9 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 21
6.11. Transform Protocols........................................17 7.9.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . . . 21
6.11.1. Authentication protocols.................................17 7.9.2 Transport Adjacency . . . . . . . . . . . . . . . . . . . 22
6.11.2. Encryption protocols.....................................17 7.10 Transform protocols . . . . . . . . . . . . . . . . . . . 23
6.12. IPsec Protocols............................................18 7.10.1 Authentication Protocols . . . . . . . . . . . . . . . . . 24
6.12.1. Authentication Header (AH)...............................18 7.10.2 Encryption Protocols . . . . . . . . . . . . . . . . . . . 24
6.12.2. Encapsulated Security Payload (ESP)......................18 7.11 IPSec Protocols . . . . . . . . . . . . . . . . . . . . . 25
6.13. Selectors..................................................19 7.11.1 Authentication Header (AH) . . . . . . . . . . . . . . . . 25
6.14. NAT Traversal (NAT-T)......................................19 7.11.2 Encapsulated Security Payload (ESP) . . . . . . . . . . . 26
6.15. IP Compression.............................................20 7.12 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 27
6.16. Security Context...........................................20 7.13 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 27
6.17. Performance Metrics........................................21 7.14 IP Compression . . . . . . . . . . . . . . . . . . . . . . 28
6.17.1. Tunnels Per Second (TPS).................................21 7.15 Security Context . . . . . . . . . . . . . . . . . . . . . 29
6.17.2. Tunnel Flaps Per Second (TFPS)...........................21 8. Performance Metrics . . . . . . . . . . . . . . . . . . . 31
6.17.3. Tunnels Attempted Per Second (TAPS)......................22 8.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 31
7. TEST TERMINOLOGY..............................................22 8.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 31
7.1. Framesizes..................................................22 8.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 32
7.1.1. Layer3 Clear Framesize...................................22 9. Test Definitions . . . . . . . . . . . . . . . . . . . . . 32
7.1.2. Layer3 Encrypted Framesize...............................22 9.1 Framesizes . . . . . . . . . . . . . . . . . . . . . . . . 32
7.1.3. Layer2 Clear Framesize...................................23 9.1.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32
7.1.4. Layer2 encrypted framesize...............................24 9.1.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33
7.2. Internet Mix Traffic (IMIX).................................24 9.1.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34
7.3. Throughput..................................................25 9.1.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 34
7.3.1. IPsec Tunnel Throughput..................................25 9.2 Internet Mix Traffic (IMIX) . . . . . . . . . . . . . . . 35
7.3.2. IPsec Tunnel Encryption Throughput.......................25 9.3 Throughput . . . . . . . . . . . . . . . . . . . . . . . . 36
7.3.3. IPsec Tunnel Decryption Throughput.......................26 9.3.1 IPsec Tunnel Throughput . . . . . . . . . . . . . . . . . 36
7.4. Latency.....................................................26 9.3.2 IPsec Encryption Throughput . . . . . . . . . . . . . . . 37
7.4.1. IPsec Tunnel Encryption Latency..........................26 9.3.3 IPsec Decryption Throughput . . . . . . . . . . . . . . . 37
7.4.2. IPsec Tunnel Decryption Latency..........................27 9.4 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 38
7.4.3. Time To First Packet (TTFP)..............................28 9.4.1 IPsec Tunnel Encryption Latency . . . . . . . . . . . . . 38
7.5. Frame Loss Rate.............................................28 9.4.2 IPsec Tunnel Decryption Latency . . . . . . . . . . . . . 39
7.5.1. IPsec Tunnel Encryption Frame Loss Rate..................28 9.4.3 Time To First Packet . . . . . . . . . . . . . . . . . . . 40
7.5.2. IPsec Tunnel Decryption Frame Loss Rate..................29 9.5 Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . 40
7.6. Back-to-Back................................................29 9.5.1 IPsec Tunnel Encryption Frame Loss Rate . . . . . . . . . 40
7.6.1. Encryption Back-to-Back Frames...........................29 9.5.2 IPsec Tunnel Decryption Frame Loss Rate . . . . . . . . . 41
7.6.2. Decryption Back-to-back frames...........................29 9.6 Back-to-back Frames . . . . . . . . . . . . . . . . . . . 42
7.7. Tunnel Setup Rate Behavior..................................30 9.6.1 Encryption Back-to-back Frames . . . . . . . . . . . . . . 42
7.7.1. Tunnel Setup Rate........................................30 9.6.2 Decryption Back-to-back Frames . . . . . . . . . . . . . . 42
7.7.2. IKE Tunnel Setup Rate....................................30 9.7 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . . 43
7.7.3. IPsec Tunnel Setup Rate..................................31 9.7.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . . . . 43
7.8. Tunnel Rekey................................................31 9.7.2 IKE Setup Rate . . . . . . . . . . . . . . . . . . . . . . 44
7.8.1. Phase 1 Rekey Time.......................................31 9.7.3 IPsec Setup Rate . . . . . . . . . . . . . . . . . . . . . 44
7.8.2. Phase 2 Rekey Time.......................................31 9.8 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . . 45
7.9. Tunnel Flapping.............................................32 9.8.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . . . 45
7.9.1. Tunnel Flap Rate.........................................32 9.8.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . . . 46
7.10. Tunnel Failover Time (TFT).................................33 9.9 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . . 46
7.11. IKE DOS Resilience Rate....................................33 10. IKE DOS Resilience Rate . . . . . . . . . . . . . . . . . 47
8. SECURITY CONSIDERATIONS.......................................34 11. Security Considerations . . . . . . . . . . . . . . . . . 48
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 48
9. ACKNOWLEDGEMENTS..............................................34 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . 48
Normative References . . . . . . . . . . . . . . . . . . . 48
10. CONTRIBUTORS.................................................34 Informative References . . . . . . . . . . . . . . . . . . 50
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 50
11. REFERENCES...................................................34 Intellectual Property and Copyright Statements . . . . . . 52
12. CONTACT INFORMATION..........................................37
13. FULL COPYRIGHT STATEMENT.....................................37
1. Introduction 1. Introduction
Despite the need to secure communications over a public medium Despite the need to secure communications over a public medium there
there is no standard method of performance measurement nor a is no standard method of performance measurement nor a standard in
standard in the terminology used to develop such hardware/software the terminology used to develop such hardware/software solutions.
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. Standarized
IPsec terminology and performance test methodologies will enable IPsec terminology and performance test methodologies will enable
users to decide if the IPsec device they select will withstand users to decide if the IPsec device they select will withstand
relatively heavy loads of secured traffic. relatively heavy loads of secured traffic.
To appropriately define the parameters and scope of this document, To appropriately define the parameters and scope of this
this section will give a brief overview of the IPsec standard. document,this section will give a brief overview of the IPsec
standard:
1.1. IPsec Fundamentals 2. IPsec Fundamentals
IPsec is a framework of open standards that provides data IPsec is a framework of open standards that provides data
confidentiality, data integrity, and data authentication between confidentiality, data integrity, and data authenticity between
participating peers. IPsec provides these security services at the participating peers. IPsec provides these security services at the IP
IP layer. IPsec uses IKE to handle negotiation of protocols and layer. IPsec uses IKE to handle negotiation of protocols and
algorithms based on local policy, and to generate the encryption algorithms based on local policy, and to generate the encryption and
and authentication keys to be used. IPsec can be used to protect authentication keys to be used. IPsec can be used to protect one or
one or more data flows between a pair of hosts, between a pair of more data flows between a pair of hosts, between a pair of security
security gateways, or between a security gateway and a host. The gateways, or between a security gateway and a host. The IPsec
IPsec protocol suite set of standards is documented in RFC's 2401 protocol suite set of standards is documented in RFC's 2401 through
through 2412 and RFC 2451. The reader is assumed to be familiar 2412 and RFC 2451. The reader is assumed to be familiar with these
with these documents. Some Internet Drafts supersede these RFC's documents. Some Internet Drafts supersede these RFC's and will be
and will be taken into consideration. Mainly it will encompass taken into consideration.
current work in progress on NAT Traversal and updates to AH, ESP,
and IKE.
IPsec itself defines the following: IPsec itself defines the following:
Authentication Header (AH): Authentication Header (AH): A security protocol, defined in
A security protocol, defined in RFC 2402, which provides data [RFC2402], which provides data authentication and optional
authentication and optional anti-replay services. AH ensures anti-replay services. AH ensures the integrity and data origin
the integrity and data origin authentication of the IP authentication of the IP datagram as well as the invariant fields in
datagram as well as the invariant fields in the outer IP the outer IP header.
header.
Encapsulating Security Payload (ESP): Encapsulating Security Payload (ESP): A security protocol, defined in
A security protocol, defined in RFC 2406, which provides [RFC2406], which provides confidentiality, data origin
confidentiality, data origin authentication, connectionless authentication, connectionless integrity, an anti-replay service and
integrity, an anti-replay service and limited traffic flow limited traffic flow confidentiality. The set of services provided
confidentiality. The set of services provided depends on depends on options selected at the time of Security Association (SA)
options selected at the time of Security Association (SA) establishment and on the location of the implementation in a network
establishment and on the location of the implementation in a topology. ESP authenticates only headers and data after the IP
network topology. ESP authenticates only headers and data header.
after the IP header.
Internet Key Exchange (IKE): Internet Key Exchange (IKE): A hybrid protocol which implements
A hybrid protocol which implements Oakley and SKEME key Oakley and SKEME key exchanges inside the ISAKMP framework. While IKE
exchanges inside the ISAKMP framework. While IKE can be used can be used with other protocols, its initial implementation is with
with other protocols, its initial implementation is with the the IPsec protocol. IKE provides authentication of the IPsec peers,
IPsec protocol. IKE provides authentication of the IPsec negotiates IPsec security associations, and establishes IPsec keys.
peers, negotiates IPsec security associations, and establishes
IPsec keys. Note that IKE is an optional protocol within the
IPsec framework and keys can also be manually configured.
The AH and ESP protocols each support two modes of operation: The AH and ESP protocols each support two modes of operation:
transport mode and tunnel mode. In transport mode, two hosts transport mode and tunnel mode. In transport mode, two hosts provide
provide protection primarily for upper-layer protocols. The protection primarily for upper-layer protocols. The cryptographic
cryptographic endpoints (where the encryption and decryption take endpoints (where the encryption and decryption take place) are the
place) are the source and destination of the data packet. In IPv4, source and destination of the data packet. In IPv4, a transport mode
a transport mode security protocol header appears immediately after security protocol header appears immediately after the IP header and
the IP header and before any higher-layer protocols (such as TCP or before any higher-layer protocols (such as TCP or UDP).
UDP).
In the case of AH in transport mode, all upper-layer information is In the case of AH in transport mode, all upper-layer information is
protected, and all fields in the IPv4 header excluding the fields protected, and all fields in the IPv4 header excluding the fields
typically are modified in transit. The fields of the IPv4 header typically are modified in transit. The fields of the IPv4 header that
that are not included are, therefore, set to 0 before applying the are not included are, therefore, set to 0 before applying the
authentication algorithm. These fields are as follows: authentication algorithm. These fields are as follows:
o TOS
o TTL * TOS
o Header Checksum * TTL
o Offset * Header Checksum
o Flags * Offset
* Flags
In the case of ESP in transport mode, security services are provide In the case of ESP in transport mode, security services are provide
only for the higher-layer protocols, not for the IP header. A only for the higher-layer protocols, not for the IP header. A tunnel
tunnel is a vehicle for encapsulating packets inside a protocol is a vehicle for encapsulating packets inside a protocol that is
that is understood at the entry and exit points of a given network. understood at the entry and exit points of a given network. These
These entry and exit points are defined as tunnel interfaces. entry and exit points are defined as tunnel interfaces.
Tunnel mode can be supported by data packet endpoints as well as by Tunnel mode can be supported by data packet endpoints as well as by
intermediate security gateways. In tunnel mode, there is an "outer" intermediate security gateways. In tunnel mode, there is an "outer"
IP header that specifies the IPsec processing destination, plus an IP header that specifies the IPsec processing destination, plus an
"inner" IP header that specifies the ultimate destination for the "inner" IP header that specifies the ultimate destination for the
packet. The source address in the outer IP header is the initiating packet. The source address in the outer IP header is the initiating
cryptographic endpoint; the source address in the inner header is cryptographic endpoint; the source address in the inner header is the
the true source address of the packet. The security protocol header true source address of the packet. The security protocol header
appears after the outer IP header and before the inner IP header. appears after the outer IP header and before the inner IP header.
If AH is employed in tunnel mode, portions of the outer IP header If AH is employed in tunnel mode, portions of the outer IP header are
are given protection (those same fields as for transport mode, given protection (those same fields as for transport mode, described
described earlier in this section), as well as all of the tunneled earlier in this section), as well as all of the tunneled IP packet
IP packet (that is, all of the inner IP header is protected as are (that is, all of the inner IP header is protected as are the
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 outer header. afforded only to the tunneled packet, not to the outer header.
1.2. IPsec Operation 2.1 IPsec Operation
1.2.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 how the entities will use security services to communicate securely.
securely. The SA includes: an encryption algorithm, an The SA includes: an encryption algorithm, an authentication algorithm
authentication algorithm and a shared session key. and a shared session key.
Because an SA is unidirectional, two SAs (one in each direction) Because an SA is unidirectional, two SAs (one in each direction) are
are required to secure typical, bidirectional communication between required to secure typical, bidirectional communication between two
two entities. The security services associated with an SA can be entities. The security services associated with an SA can be used for
used for AH or ESP, but not for both. If both AH and ESP protection AH or ESP, but not for both. If both AH and ESP protection is applied
is applied to a traffic stream, two (or more) SAs are created for to a traffic stream, two (or more) SAs are created for each direction
each direction to protect the traffic stream. 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)
[RFC2408]. 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 SPI from the SA into the IPsec header. When the IPsec peer receives
receives the packet, it looks up the SA in its database by the packet, it looks up the SA in its database by destination
destination address, protocol, and SPI and then processes the address, protocol, and SPI and then processes the packet as required.
packet as required.
1.2.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 and automatic distribution of keys encryption services. Both manual and automatic distribution of keys
is supported. IKE is specified as the public-key-based approach for is supported. IKE is specified as the public-key-based approach for
automatic key management. 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 SAs in a secure and
authenticated manner: authenticated manner:
o ISAKMP (Internet Security Association and Key Management
Protocol), which provides a framework for authentication and 1. ISAKMP (Internet Security Association and Key Management
key exchange but does not define them. ISAKMP is designed to Protocol), which provides a framework for authentication and key
be key exchange independent; that is, it is designed to exchange but does not define them. ISAKMP is designed to be key
support many different key exchanges. exchange independent; it is designed to support many different
o Oakley, which describes a series of key exchanges, called key exchanges.
modes, and details the services provided by each (for example,
perfect forward secrecy for keys, identity protection, and 2. Oakley, which describes a series of key exchanges, called modes,
and details the services provided by each (for example, perfect
forward secrecy for keys, identity protection, and
authentication). [RFC 2412] authentication). [RFC 2412]
o SKEME (Secure Key Exchange Mechanism for Internet), which 3. [SKEME] (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that provides describes a versatile key exchange technique that provides
anonymity, reputability, and quick key refreshment. anonymity, reputability, and quick key refreshment.
IKE creates an authenticated, secure tunnel between two entities IKE creates an authenticated, secure tunnel between two entities and
and then negotiates the security association for IPsec. This is then negotiates the security association for IPsec. This is performed
performed in two phases. in two phases.
In Phase 1, the two unidirectional SA's establish a secure, In Phase 1, the two unidirectional SA's establish a secure,
authenticated channel with which to communicate. Phase 1 has two authenticated channel with which to communicate. Phase 1 has two
distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1
1 provides identity protection. When identity protection is not provides identity protection. When identity protection is not needed,
needed, Aggressive Mode can be used. The completion of Phase 1 an Aggressive Mode can be used. The completion of Phase 1 an IKE SA is
IKE SA is established. established.
The following attributes are used by IKE and are negotiated as part The following attributes are used by IKE and are negotiated as part
of the IKE SA: of the IKE SA:
o Encryption algorithm
o Hash algorithm o Encryption algorithm.
o Authentication method (can be digital signature, public-key
encryption, or pre-shared key) o Hash algorithm.
o Information about a group on which to perform Diffie-
Hellman o Authentication method (digital signature, public-key encryption,
or pre-shared key).
o Diffie-Hellman group information.
After the attributes are negotiated, both parties must be After the attributes are negotiated, both parties must be
authenticated to each other. IKE supports multiple authentication authenticated to each other. IKE supports multiple authentication
methods. At this time, the following mechanisms are generally methods. At this time, the following mechanisms are generally
implemented: implemented:
o Preshared keys. The same key is pre-installed on each host.
IKE peers authenticate each other by computing and sending a o Preshared keys. The same key is pre-installed on each host. IKE
keyed hash of data that includes the preshared key. If the peers authenticate each other by computing and sending a keyed
receiving peer can independently create the same hash using hash of data that includes the preshared key. If the receiving
its preshared key, it knows that both parties must share the peer can independently create the same hash using its preshared
same secret, and thus the other party is authenticated. key, it knows that both parties must share the same secret, and
thus the other party is authenticated.
o Public key cryptography. Each party generates a pseudo-random o Public key cryptography. Each party generates a pseudo-random
number (a nonce) and encrypts it and its ID using the other number (a nonce) and encrypts it and its ID using the other
party's public key. The ability for each party to compute a party's public key. The ability for each party to compute a keyed
keyed hash containing the other peer's nonce and ID, decrypted hash containing the other peer's nonce and ID, decrypted with the
with the local private key, authenticates the parties to each local private key, authenticates the parties to each other. This
other. This method does not provide nonrepudiation; either method does not provide nonrepudiation; either side of the
side of the exchange could plausibly deny that it took part in exchange could plausibly deny that it took part in the exchange.
the exchange.
o Digital signature. Each device digitally signs a set of data o Digital signature. Each device digitally signs a set of data and
and sends it to the other party. This method is similar to sends it to the other party. This method is similar to the
the public-key cryptography approach except that it provides public-key cryptography approach except that it provides
nonrepudiation. nonrepudiation.
Note that both digital signature and public-key cryptography Note that both digital signature and public-key cryptography require
require the use of digital certificates to validate the the use of digital certificates to validate the public/private key
public/private key mapping. IKE allows the certificate to be mapping. IKE allows the certificate to be accessed independently or
accessed independently or by having the two devices explicitly by having the two devices explicitly exchange certificates as part of
exchange certificates as part of IKE. Both parties must have a IKE. Both parties must have a shared session key to encrypt the IKE
shared session key to encrypt the IKE tunnel. The Diffie-Hellman tunnel. The Diffie-Hellman protocol is used to agree on a common
protocol is used to agree on a common session key. session key.
In Phase 2 of the process, IPsec SAs are negotiated on behalf of In Phase 2 of the process, IPsec SAs are negotiated on behalf of
services such as IPsec AH or ESP. IPsec uses a different shared services such as IPsec AH or ESP. IPsec uses a different shared key
key than does IKE. The IPsec shared key can be derived by using than does IKE. The IPsec shared key can be derived by using
Diffie-Hellman again or by refreshing the shared secret derived Diffie-Hellman again or by refreshing the shared secret derived from
from the original Diffie-Hellman exchange that generated the IKE SA the original Diffie-Hellman exchange that generated the IKE SA by
by hashing it with nonces. After this step is complete, the IPsec hashing it with nonces. After this step is complete, the IPsec SAs
SAs are established. Now the data traffic can be exchanged with are established. Now the data traffic can be exchanged with the
the negotiated IPsec parameters. The completion of Phase 2 is negotiated IPsec parameters. The completion of Phase 2 is called an
called an IPsec SA. IPsec SA.
1.2.3. Using the term 'Tunnel'
The term "tunnel" is often used in a variety of contexts. To avoid
any discrepancies, in this document we define the following
distinctions between the word "tunnel":
"IKE Tunnel": A bidirectional IKE Phase 1 SA, which is also
referred to as ISAKMP SA. It sets up a secure authenticated
"control channel" for further IKE communications.
"IPsec Tunnel": A bidirectional IKE Phase 2 SA, which is also
referred to as an IPsec SA. It creates the secure data exchange
channel.
"Tunnel": The combination of an IKE and an IPsec Tunnel
2. Document Scope 3. Document Scope
The primary focus of this document is to establish useful The primary focus of this document is to establish useful performance
performance testing terminology for IPsec devices. As such we want testing terminology for IPsec devices that support IKEv1. We want to
to constrain the terminology specified in this document to meet the constrain the terminology specified in this document to meet the
requirements of the testing methodology. The testing will be requirements of the Methodology for Benchmarking IPSec Devices
constrained to devices acting as IPsec gateways and will pertain to documented test methodologies. The testing will be constrained to
both IPsec tunnel and transport mode. devices acting as IPsec gateways and will pertain to both IPsec
tunnel and transport mode.
What is specifically out of scope is any testing that pertains to Any testing involving interoperability and/or conformance issues,
interoperability and/or conformance issues. Additionally, any L2TP, GRE, 2547 (MPLS VPNs), multicast, and anything that does not
testing involving L2TP, GRE and 2547 (MPLS VPNs) is out of scope.
It is also out of scope to deal with anything that does not
specifically relate to the establishment and tearing down of IPsec specifically relate to the establishment and tearing down of IPsec
tunnels. It is assumed that all relevant networking parameters tunnels is specifically out of scope. It is assumed that all relevant
that facilitate in the running of these tests are pre-configured networking parameters that facilitate in the running of these tests
(this includes at a minimum ARP caches and routing tables). are pre-configured (this includes at a minimum ARP caches and routing
Pertinent to IKEv2, NAT Traversal has been included in the tables). This document will encompass updates to AH, ESP and NAT
document, therefore NAT is not included in this document. All Traversal. Since NAT traversal has been included in the document, NAT
references to IKE connotate the inclusion of IKEv2 as well. is not included in this document.
3. Definition Format 4. Definition Format
The definition format utilized by this document is described in RFC
1242, Section 2. The definition format utilized by this document is described in
[RFC1242], Section 2.
Term to be defined. Term to be defined.
Definition: Definition:
The specific definition for the term. The specific definition for the term.
Discussion: Discussion:
A brief discussion of the term, its application, or other A brief discussion of the term, its application, or other
information that would build understanding. information that would build understanding.
Issues:
List of issues or conditions that affect this term. This field can
present items the may impact the term's related methodology or
otherwise restrict its measurement procedures.
[Measurement units:] [Measurement units:]
Units used to record measurements of this term. This field is Units used to record measurements of this term. This field is
mandatory where applicable. This field is optional in this mandatory where applicable. This field is optional in this
document. document.
[Issues:]
List of issues or conditions that affect this term. This field
can present items the may impact the term's related
methodology or otherwise restrict its measurement procedures.
This field is optional in this document.
[See Also:] [See Also:]
List of other terms that are relevant to the discussion of
this term. This field is optional in this document.
4. Key Words to Reflect Requirements List of other terms that are relevant to the discussion of this
term. This field is optional in this document.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 5. Key Words to Reflect Requirements
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119.
RFC 2119 defines the use of these key words to help make the intent
of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards
track document.
5. Existing Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. RFC 2119
defines the use of these key words to help make the intent of
standards track documents as clear as possible. While this document
uses these keywords, this document is not a standards track document.
It is recommended that readers consult RFCs 1242, 2544 and 2285 6. Existing Definitions
before making use of this document. These and other IETF
It is recommended that readers consult [RFC1242], [RFC2544] and
[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 documents contain several existing terms relevant to benchmarking the
the performance of IPsec devices. The conceptual framework performance of IPsec devices. The conceptual framework established in
established in these earlier RFCs will be evident in this document. these earlier RFCs 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 Note: "DUT/SUT" refers to a metric that may be applicable to a DUT
(Device Under Test) or an SUT (System Under Test). (Device Under Test) or an SUT (System Under Test).
6. Term Definitions 7. Term Definitions
6.1. IPsec 7.1 Tunnel
The term "tunnel" is often used in a variety of contexts. To avoid
any discrepancies, in this document we define the following
distinctions between the word "tunnel":
"IKE Tunnel": (ISAKMP/IKE SA, IKE Phase 1 SA, Phase 1 SA) One simplex
Phase 1 IKE SA, which is sometimes is also referred to as ISAKMP or
IKE SA, IKE Phase 1 SA, or Phase 1 SA. An IKE Tunnel between IPSec
devices facilitates a mechanism for secure negotiation of Phase 1
properties and 2 SA's needed for protected data transport.
"IPsec SA": (IPsec SA, IKE Phase 2 SA) One simplex IKE Phase 2 SA,
which is also referred to as an IPsec SA or IKE Phase 2 SA.
"IPsec Tunnel": In the case of simplex communication, a single phase
2 SA. In the more likely case where bidirectional communication is
needed it is a pair of Phase 2 SA's, one for each direction. Unless
stated otherwise, bidirectional communication is always assumed. The
IPSec Tunnel will protect the data traffic flowing between IPSec
devices.
"Tunnel": The combination of one IKE Tunnel and one IPsec Tunnel i.e.
a single Phase 1 SA and a pair of Phase 2 SA's (for bidirectional
communication).
7.1.1 Configured Tunnel
Definition: Definition:
IP Security protocol suite which comprises a set of standards
used to provide privacy and authentication services at the IP A tunnel that is present in the IPSec device's configuration but
layer. does not have any SA's in the SADB.
Discussion: Discussion:
TBD
Several steps are required before a Tunnel can be used to actually
trasport data. The very first step would be to configure the
tunnel in the IPsec device. In that way packet classification can
make a decision if it is required to start negotiating SA's. At
this time there are no SA's associated with the Tunnel.
Issues: Issues:
N/A
See Also: See Also:
6.2. IPsec Device Tunnel, Established Tunnel, Active Tunnel, Terminated Tunnel
7.1.2 Established Tunnel
Definition:
A Tunnel that has completed Phase 1 and Phase 2 SA negotiations
but is otherwise idle.
Discussion:
A second step needed to ensure that a Tunnel can transport data is
the Phase 1 and Phase 2 negotiation phase. After the packet
classification process has asserted that a packet requires
security services, the negotation is started to obtain both Phase
1 and Phase 2 SA's. After this is completed the tunnel is called
'Established'. Note that at this time there is still no traffic
flowing through the Tunnel.
Issues:
In the case of manually keyed tunnels, there is no distinction
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:
Tunnel, Configured Tunnel, Active Tunnel, Terminated Tunnel
7.1.3 Active Tunnel
Definition:
A tunnel that has completed Phase 1 and Phase 2 SA negotiations
and is transmitting data.
Discussion:
When a Tunnel is Established it is ready to transport data
traffic, and we call the tunnel 'Active'.
Issues:
N/A
See Also:
Tunnel, Configured Tunnel, Established Tunnel, Terminated Tunnel
7.1.4 Terminated Tunnel
Definition: Definition:
A tunnel that has relinquished all it's SA's and is not
transmitting data anymore.
Discussion:
At the point where it is no longer required to provide security
services between IPsec devices, first the Phase 2 SA's are
released after which the Phase 1 SA is deleted and the Tunnel is
no longer. After all resources (SA's) are (in most cases
volountary released) the Tunnel returns to a 'Configured' state.
Issues:
Note that manually keyed tunnels never can be in a Terminated
state. The only way to prevent data forwarding over a manually
keyed tunnel is to deconfigure the Tunnel.
See Also:
Tunnel, Configured Tunnel, Established Tunnel, Active Tunnel
7.2 IPsec
Definition:
IPsec or IP Security protocol suite which comprises a set of
standards used to provide security services at the IP layer.
Discussion:
IPsec is a large framework of protocols that offer authentication,
authenticity and encryption services to the IP and/or upper layer
protocols. The major components of the protocol suite are IKE,
used for key exchanges, and IPsec protocols such as AH and ESP,
which use the exchanged keys to protect payload traffic.
Issues:
N/A
See Also:
IPsec Device, IKE, ISAKMP, ESP, AH
7.3 IPsec Device
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 come in many forms and shapes. Not only can
they be grouped by 'external' properties (e.g. software vs.
hardware implementations) but more important is the subtle
differences that implementations may have with relation to the
IPsec Protocol Suite. Not all implementations will cover all
RFCs that encompass the IPsec Protocol Suite, but the majority
will support a large subset of features described in the
suite.
In that context, any implementation, that supports basic IP Implementations can be grouped by 'external' properties (e.g.
layer security services as described in the IPsec protocol software vs. hardware implementations) but more important is the
suite shall be called an IPsec Device'. subtle differences that implementations may have with relation to
the IPsec Protocol Suite. Not all implementations will cover all
RFC's that encompass the IPsec Protocol Suite, but the majority
will support a large subset of features described in the suite,
nor will all implementations utilize all of the cryptographic
functions listed in the RFCs.
In that context, any implementation, that supports basic IP layer
security services as described in the IPsec protocol suite shall
be called an IPsec Device.
Issues: Issues:
Due to the fragmented nature of the IPsec Protocol Suite RFCs,
it is not unlikely that IPsec implementations will not be able Due to the fragmented nature of the IPsec Protocol Suite RFC's, it
to interoperate. Therefore it is important to know which is possible that IPsec implementations will not be able to
features and options are implemented in the IPsec Device. interoperate. Therefore it is important to know which features and
options are implemented in the IPsec Device.
See Also: See Also:
IPsec IPsec
6.3. ISAKMP
7.3.1 Initiator
Definition: Definition:
The Internet Security Association and Key Management Protocol,
which provides a framework for authentication and key exchange IPsec devices which start the negotiation of IKE Phase 1 or IKE
but does not define them. ISAKMP is designed to be key Phase 2 tunnels.
exchange independent; that is, it is designed to support many
different key exchanges. ISAKMP is defined in RFC 2407.
Discussion: Discussion:
TBD
When a traffic flow is offered at an IPSec device and it is
determined that the flow must be protected, but there is no tunnel
yet, it is the responsibility of the IPsec device to start a
negotiation process. This process will establish an IKE Phase 1 SA
and one or more IKE phase 2 SA's, eventually resulting in secured
data transport. The device that takes the action to start this
negotiation process will be called an Initiator. Note that an IKE
Phase 1 initiator, does not necessarily become an IKE Phase 2
initiator.
Issues: Issues:
IPsec devices/implementations can always be both an initiator as
well as a responder. The distinction is useful from a test
perspective.
See Also: See Also:
IKE
6.4. IKE Responder, IKE, IPsec
7.3.2 Responder
Definition: Definition:
A hybrid protocol, defined in RFC 2409, from the following 3
protocols: IPsec devices which reply to the incoming initiators IKE Phase 1
o ISAKMP (Internet Security Association and Key Management or Phase 2 tunnel requests and process these messages in order to
Protocol), which provides a framework for authentication establish a tunnel.
and key exchange but does not define them. ISAKMP is
designed to be key exchange independent; that is, it is
designed to support many different key exchanges.
o Oakley, which describes a series of key exchanges, called
modes, and details the services provided by each (for
example, perfect forward secrecy for keys, identity
protection, and authentication). [RFC 2412]
o SKEME (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that
provides anonymity, reputability, and quick key
refreshment.
Discussion: Discussion:
TBD
When an initiator attempts to establish SAs with another IPsec
device, this peer will need to evaluate the proposals made by the
initiator and either accept or deny them. In the former case, the
traffic flow will be decrypted according to the negotiated
parameters. Such a device will be called a Responder.
Issues: Issues:
During the first IPsec deployment experiences, many
ambiguities were found in the original IKE specification, IPsec devices/implementations can usually be both an initiator as
which lead to many interoperability problems. To resolve these well as a responder. The distinction is useful from a test
issues, there is an ongoing effort to simplify the current IKE perspective.
protocol and remove all unused features and options. This
effort manifests itself in a new IKE version, called IKEv2.
IKEv2 is an updated version of the current IKE stack and is
code preserving a compatible with IKEv1.
See Also: See Also:
ISAKMP, Ipsec
6.5. Initiator Initiator, IKE
7.3.3 IPsec Client
Definition: Definition:
IPsec devices which start the negotiation of IKE Phase 1 and
IKE Phase 2 tunnels. IPsec Devices that will only act as an Initiator.
Discussion: Discussion:
When a traffic flow is offered at an IPSec device and it is
determined that the flow must be protected, but there is no In some situations it is not needed or prefered to have an IPsec
active tunnel yet, it is the responsibility of the IPSec device respond to an inbound tunnel request. In the case of e.g.
device to start a negotiation process. This process will road warriors or home office scenarios the only property needed
establish an IKE Phase 1 SA and one or more IKE phase 2 SA_s, from the IPsec device is the ability to securely connect to a
eventually resulting in secured data transport. The device remote private network. The IPsec Client will set up one or more
that takes the action to start this negotiation process will Tunnels to an IPSec Server on the network that needs to be
be called an Initiator. accessed and to provide the required security services. IPsec
clients are generally used to connect remote users in a secure
fashion over the Internet to a private network.
Issues: Issues:
IPSec devices/implementations can always be both an initiator
as well as a responder. The distinction is useful only from a N/A
test perspective.
See Also: See Also:
Responder
6.6. Responder IPsec device, IPsec Server, Initiator, Responder
7.3.4 IPsec Server
Definition: Definition:
IPsec devices which reply to the incoming initiators IKE Phase IPSec Devices that can both act as an Initiator as well as a
1 and Phase 2 tunnel requests and process these messages in Responder.
order to establish a tunnel.
Discussion: Discussion:
When an initiator attempts to establish SAs with another IPsec IPSec Servers are mostly positioned at private network edges and
device, this peer will need to evaluate the proposals made by provide several functions :
the initiator and either accept or deny them. In the former
case, the traffic flow will be decrypted according to the Responds to tunnel setup request from IPSec Clients.
negotiated parameters. Such a device will be called a
Responder_. Responds to tunnel setup request from other IPSec devices/
Initiators.
Initiate tunnels to other IPSec servers inside or outside the
private network.
Issues: Issues:
IPSec devices/implementations can usually be both an initiator
as well as a responder. The distinction is useful only from a IPsec Servers are also sometimes referred to as 'concentrators'.
test perspective.
See Also: See Also:
Initiator
6.7. Security Association (SA) IPsec Device, IPsec Client, Initiator, Responder
7.4 ISAKMP
Definition: Definition:
The Internet Security Association and Key Management Protocol,
which provides a framework for authentication and key exchange but
does not define them. ISAKMP is designed to be key exchange
independent; it is designed to support many different key
exchanges. ISAKMP is defined in [RFC2407].
Discussion:
Though ISAKMP is only a framework for the IPsec standard key
management protocol, it is often misused and interchanged with the
term 'IKE', which is an implementation of ISAKMP. The term ISAKMP
SA is used by some vendors while others use IKE SA. Both refer to
IKE Phase 1 SA.
Issues:
N/A
See Also:
IKE
7.5 IKE
Definition:
A hybrid protocol, defined in [RFC2409], from the following 3
protocols:
* ISAKMP (Internet Security Association and Key Management
Protocol), which provides a framework for authentication and
key exchange but does not define them. ISAKMP is designed to be
key exchange independent; it is designed to support many
different key exchanges.
* Oakley, which describes a series of key exchanges, called
modes, and details the services provided by each (for example,
perfect forward secrecy for keys, identity protection, and
authentication). [RFC2412]
* [SKEME] (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that provides
anonymity, reputability, and quick key refreshment.
Discussion:
Note that IKE is an optional protocol within the IPsec framework
and that tunnels also can be manually keyed resulting in hardwired
SA's as configured by the administrator.
Issues:
During the first IPsec deployment experiences, ambiguities were
found in the IKEv1 specification, which lead to interoperability
problems. To resolve these issues, IKEv1 is being updated by
IKEv2.
See Also:
ISAKMP, IPsec
7.6 Security Association (SA)
Definition:
A simplex (unidirectional) logical connection, created for A simplex (unidirectional) logical connection, created for
security purposes. All traffic traversing an SA is provided security purposes. All traffic traversing an SA is provided the
the same security processing. In IPsec, an SA is an Internet same security processing. In IPsec, an SA is an Internet layer
layer abstraction implemented through the use of AH or ESP. abstraction implemented through the use of AH or ESP. [RFC2401]
[RFC 2401]
Discussion: Discussion:
A set of policy and key(s) used to protect information. It is
a negotiation agreement between two IPsec devices, A set of policy and key(s) used to protect information. It is a
specifically the Initiator and Responder. negotiation agreement between two IPsec devices, specifically the
Initiator and Responder.
Issues: Issues:
N/A
See Also: See Also:
6.8. IKE Phase 1 Initiator, Responder
7.7 IKE Phase 1
Definition: Definition:
The shared policy and key(s) used by negotiating peers to set
up a secure authenticated "control channel" for further IKE The shared policy and key(s) used by negotiating peers to set up a
secure authenticated "control channel" for further IKE
communications. communications.
Discussion: Discussion:
TBD
Note that IKE is an optional protocol within the IPsec framework
and keys can also be manually configured.
Issues: Issues:
In other documents also referenced as ISAKMP SA or IKE SA.
In other documents can be referenced as ISAKMP SA or IKE SA.
See Also: See Also:
IKE, ISAKMP IKE, ISAKMP
6.8.1. Phase 1 Main Mode 7.7.1 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 RFC 2409. Exchange, defined in [RFC2409]. Upon successful completion it
results in the establishment of an IKE Phase 1 SA.
Discussion: Discussion:
IKE Main Mode uses 3 separate message exchanges, for a total
of 6 messages. The first two messages negotiate policy; the IKE Main Mode use 3 distinct message pairs, for a total of 6
next two exchange Diffie-Hellman public values and ancillary messages. The first two messages negotiate policy; the next two
data (e.g. nonces necessary for the exchange); and the last represent Diffie-Hellman public values and ancillary data (e.g.
two messages authenticate the Diffie-Hellman Exchange. The nonces); and the last two messages authenticate the Diffie-Hellman
authentication method negotiated as part of the initial IKE Exchange. The authentication method negotiated as part of the
Phase 1 exchange influences the composition of the payloads initial IKE Phase 1 influence the composition of the payloads but
but not their purpose. not their purpose.
Issues: Issues:
N/A
See Also: See Also:
IKE, IKE Phase 1, Phase 1 Aggressive Mode
6.8.2. Phase 1 Aggressive Mode ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode
7.7.2 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 RFC 2409. Exchange, defined in [RFC2409]. Upon successful completion it
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
negotiate policy, exchange Diffie-Hellman public values and negotiate policy, exchange Diffie-Hellman public values and
ancillary data necessary for the exchange, and identities. In ancillary data necessary for the exchange, and identities. In
addition the second message authenticates the Responder. The addition the second message authenticates the Responder. The third
third message authenticates the Initiator and provides a proof message authenticates the Initiator and provides proof of
of participation in the exchange. participation in the exchange.
Issues: Issues:
For IKEv1 the standard specifies that all implementations use both
main and agressive mode, however, it is common to use only main
mode.
See Also: See Also:
IKE, IKE Phase 1, Phase 1 Main Mode
6.9. IKE Phase 2 ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode
7.8 IKE Phase 2
Definition: Definition:
Protocol which upon successful completion establishes the shared
keys used by negotiating peers to set up a secure "data channel"
for IPsec.
Discussion: Discussion:
TBD
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
IPsec (called "rekeying"), as well as for exchanging informational
messages.
Issues: Issues:
In other documents also referenced as IPsec SA.
See Also: See Also:
6.9.1. Phase 2 Quick Mode IKE Phase 1, ISAKMP, IKE
7.8.1 Phase 2 Quick Mode
Definition:
Definition
A SA negotiation and an exchange of nonces that provide replay A SA negotiation and an exchange of nonces that provide replay
protection. protection.
Discussion: Discussion:
Quick Mode is not a complete exchange itself (in that it is
bound to a phase 1 exchange), but is used as part of the SA Quick Mode is not a complete exchange itself (it is bound to a
negotiation process (phase 2) to derive keying material and phase 1 exchange), but is used as part of the SA negotiation
negotiate shared policy for non-ISAKMP SA's. The ISAKMP SA process (phase 2) to derive keying material and negotiate shared
protects the information exchanged along with Quick Mode, i.e. policy for non-ISAKMP SA's. The ISAKMP SA protects the information
all payloads except the ISAKMP header are encrypted. Also, an exchanged along with Quick Mode, i.e. all payloads except the
optional Key Exchange payload can be exchanged to allow for an ISAKMP header are encrypted. Also, an optional Key Exchange
additional Diffie-Hellman exchange and exponentiation per payload can be exchanged to allow for an additional Diffie-Hellman
Quick Mode. exchange, PFS and exponentiation per Quick Mode.
Issues: Issues:
N/A
See Also: See Also:
6.9.2. IPsec Tunnel ISAKMP, IKE, IKE Phase 2
7.8.2 IPsec Tunnel
Definition: Definition:
A bidirectional IPsec SA that is set up as part of IKE phase
2. It creates the secure data exchange channel. A bidirectional IPsec SA which is set up as part of IKE phase 2.
It creates the secure data exchange channel.
Discussion: Discussion:
Manually established IPsec tunnels do exist, however, from a
benchmarking perspective, they do not differ from IPsec Manually keyed IPsec tunnels differ from tunnels that are
tunnels that are negotiated by IKE. Note that some metrics negotiated by IKE in that there is no setup time for them, which
will not be applicable due to the limited use of manually would have an effect on tunnel setup rate. For this reason some
established IPsec tunnels. metrics will be eliminated from the test methodology matrix,
specific to manually keyed IPsec tunnels, i.e. Phase 1 Setup Rate.
Issues: Issues:
N/A
See Also: See Also:
6.10. Compound Tunnels IPsec, IKE, IKE Phase 2
6.10.1. Nested Tunnels 7.9 Iterated Tunnels
Iterated Tunnels are a bundle of transport and/or tunnel mode SA's.
The bundles are divided into two major groups :
7.9.1 Nested Tunnels
Definition: Definition:
An SA bundle consisting of two or more 'tunnel mode' SAs.
An SA bundle consisting of two or more 'tunnel mode' SA's.
Discussion: Discussion:
The process of nesting tunnels can theoretically be repeated
multiple times (for example, tunnels can be many levels deep),
but for all practical purposes, most implementations limit the
level of nesting.
Nested tunnels can use a mix of AH and ESP encapsulated The process of nesting tunnels can theoretically be repeated
traffic. multiple times (for example, tunnels can be many levels deep), but
for all practical purposes, most implementations limit the level
of nesting. Nested tunnels can use a mix of AH and ESP
encapsulated traffic.
[GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
| | | | | | | |
| | | | | | | |
| +----{SA1 (ESP tunnel)}----+ | | +----{SA1 (ESP tunnel)}----+ |
| | | |
+--------------{SA2 (AH tunnel)}---------------+ +--------------{SA2 (AH tunnel)}---------------+
In the IP Cloud a packet would have a format like this: In the IP Cloud a packet would have a format like this:
[IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TRAILER][ESP AUTH]
[IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TR][ESP AUTH] Nested tunnels can be deployed to provide additional security on
already secured traffic. A typical example of this would be that
Nested tunnels can be deployed to provide additional security the inner gateways (GW2 and GW3) are securing traffic between two
on already protected traffic. For example, the inner gateways branch offices and the outer gateways (GW1 & GW4) add an
(GW2 & GW3) are securing traffic between two branch offices additional layer of security between departments within those
and the outer gateways (GW1 & GW4) add an additional layer of branch offices.
security between departments within those branch offices.
Issues: Issues:
N/A
See Also: See Also:
Transport adjacency, IPsec Tunnel
6.10.2. Transport Adjacency Transport Adjacency, IPsec Tunnel
7.9.2 Transport Adjacency
Definition: Definition:
An SA bundle consisting of two or more transport mode SAs.
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 or more transport mode IPsec tunnels are set side by side
to enhance applied security properties.
Transport adjacency can be used with a mix of AH and ESP Transport adjacency is a form of tunnel nesting. In this case two
tunnels although some combinations are not preferred. If AH or more transport mode IPsec tunnels are set side by side to
and ESP are mixed, the ESP tunnel should always encapsulate enhance applied security properties.
the AH tunnel. The reverse combination is a valid combination
but doesn't make cryptographical sense. Transport adjacency can be used with a mix of AH and ESP tunnels
although some combinations are not preferred. If AH and ESP are
mixed, the ESP tunnel should always encapsulate the AH tunnel. The
reverse combination is a valid combination but doesn't make
cryptographical sense.
[GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
| | | | | | | |
| | | | | | | |
| +--{SA1 (ESP transport)}---+ | | +------{SA1 (ESP transport)}--------+ |
| | | |
+-------------{SA2 (AH transport)}-------------+ +-------------{SA2 (AH transport)}--------------+
In the IP cloud a packet would have a format like this:
In the IP Cloud a packet would have a format like this :
[IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH]
Issues: Issues:
This is rarely used.
See Also: See Also:
Nested tunnels, IPsec Tunnel
6.11. Transform Protocols Nested Tunnels, IPsec Tunnel
7.10 Transform protocols
Definition: Definition:
Encryption and authentication algorithms that provide Encryption and authentication algorithms that provide
cryptograhical services to the IPsec Protocols. cryptograhical services to the IPsec Protocols.
Discussion: Discussion:
TBD
Some algorithms run significantly slower than others. For example,
TripleDES encryption is one third as fast as DES encryption.
Issues: Issues:
N/A
See Also: See Also:
Authentication protocols, Encryption protocols Authentication protocols, Encryption protocols
6.11.1. Authentication protocols 7.10.1 Authentication Protocols
Definition: Definition:
Algorithms which provide data integrity and data source Algorithms which provide data integrity and data source
authentication. authentication.
Discussion: Discussion:
Authentication protocols provide no confidentiality. Commonly
used authentication algorithms/protocols are: Authentication protocols provide no confidentiality. Commonly used
o MD5-HMAC authentication algorithms/protocols are:
o SHA-HMAC
o AES-HMAC * MD5-HMAC
* SHA-HMAC
* AES-HMAC
Issues: Issues:
SHA-HMAC is thought to be more secure than MD5-HMAC and is often
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
6.11.2. Encryption protocols 7.10.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:
o NULL encryption
o DES-CBC
o 3DES-CBC
o AES-CBC
* NULL encryption
* DES-CBC
* 3DES-CBC
* AES-CBC
Issues: Issues:
Null option is a valid encryption mechanism although it reverts to
use of IPsec back to message authenticity but only for upper layer
protocols, and is commonly used.
DES has been officially deprecated by NIST, though it is still
mandated RFC and is still commonly implemented and used due to
it's speed advantage over 3DES.
See Also: See Also:
Transform protocols, Authentication protocols Transform protocols, Authentication protocols
6.12. IPsec Protocols 7.11 IPSec Protocols
6.12.1. Authentication Header (AH) Definition:
A suite of protocols which provide a framework of open standards
that provides data confidentiality, data integrity, and data
authenticity between participating peers at the IP layer. The
IPsec protocol suite set of standards is documented in RFC's 2401
through 2412 and RFC 2451.
Discussion:
The IPsec Protocol suite is modular and forward compatible. The
protocols that comprise the IPsec protocol suite can be replaced
with new versions of those protocols as the older versions become
obsolete. For example, IKEv2 will soon replace IKEv1.
Issues:
N/A
See Also:
AH, ESP
7.11.1 Authentication Header (AH)
Definition: Definition:
Provides authentication and data integrity (including replay Provides authentication and data integrity (including replay
protection) security services [RFC2402]. protection) security services [RFC2402].
Discussion: Discussion:
The AH protocol supports both modes of operation; tunnel mode and
transport mode. If AH is employed in tunnel mode, portions of the
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: 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.
See Also: See Also:
Transform protocols, IPsec protocols, Encapsulated Security Transform protocols, IPsec protocols, Encapsulated Security
Payload Payload
6.12.2. Encapsulated Security Payload (ESP) 7.11.2 Encapsulated Security Payload (ESP)
Definition: Definition:
Provides three essential components needed for secure data Provides three essential components needed for secure data
exchange: authentication, integrity (including replay exchange: authentication, integrity (including replay protection)
protection) and confidentiality [RFC2406]. and confidentiality [RFC2406].
Discussion: Discussion:
The ESP protocol supports both modes of operation; tunnel mode and
transport mode. If ESP is employed in tunnel mode, the 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: Original IPv4 packet:
[IP ORIG][L4 HDR][PAYLOAD] [IP ORIG][L4 HDR][PAYLOAD]
In transport mode: In transport mode:
[IP ORIG][ESP][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] [IP ORIG][ESP][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH]
In tunnel mode: In tunnel mode:
[IP NEW][ESP][IP ORIG][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] [IP NEW][ESP][IP ORIG][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH]
Issues: Issues:
N/A
See Also: See Also:
Transform protocols, IPsec protocols, Authentication Header Transform protocols, IPsec protocols, Authentication Header
6.13. Selectors 7.12 Selectors
Definition: Definition:
A mechanism required to classify traffic flows when IPsec is
used to protect traffic between networks which are proxied A criteria used by a classification mechanism required to classify
between two or more participating peers. After traffic flows when IPsec is used to protect traffic between
classification, a decision can be made if the traffic needs to networks which are proxied between two or more participating
be encrypted/decrypted and how this should be done. peers. After classification, a decision can be made if the traffic
needs to be encrypted/decrypted and how this should be done.
Selectors classify specific IP packets that require IPsec
processing. Selectors also define those packets that must be
discarded or passed along without modification. These are flexible
objects that can match on source and destination addresses, range
of IP addresses, wildcard addresses, different protocols, and
different port numbers (like FTP) within a protocol.
Discussion: Discussion:
The selectors are a set of fields that will be extracted from
the network and transport layer headers that provide the The selectors are a set of fields that will be extracted from the
ability to classify the traffic flow and later associate it network and transport layer headers that provide the ability to
with an SA. classify the traffic flow and later associate it with an SA.
Issues: Issues:
See Also: Both sides must agree exactly on both the networks being
protected, and they both must agree on how to describe the
networks (range, subnet, addresses). This is a common point of
non-interoperability.
6.14. NAT Traversal (NAT-T) 7.13 NAT Traversal (NAT-T)
Definition: Definition:
The capability to support IPsec functionality in the presence
of NAT devices. The capability to support IPsec functionality in the presence of
NAT devices.
Discussion: Discussion:
NAT-Traversal requires some modifications to IKE.
Specifically, in phase 1, it requires detecting if the other NAT-Traversal requires some modifications to IKE. Specifically, in
end supports NAT-Traversal, and detecting if there are one or phase 1, it requires detecting if the other end supports
more NAT instances along the path from host to host. In IKE NAT-Traversal, and detecting if there are one or more NAT
Quick Mode, there is a need to negotiate the use of UDP instances along the path from host to host. In IKE Quick Mode,
encapsulated IPsec packets. there is a need to negotiate the use of UDP encapsulated IPsec
packets.
NAT-T also describes how to transmit the original source and NAT-T also describes how to transmit the original source and
destination addresses to the other end if needed. The destination addresses to the other end if needed. The original
original source and destination addresses are used in source and destination addresses are used in transport mode to
transport mode to incrementally update the TCP/IP checksums so incrementally update the TCP/IP checksums so that they will match
that they will match after the NAT transform (The NAT cannot after the NAT transform (The NAT cannot do this, because the TCP/
do this, because the TCP/IP checksum is inside the UDP IP checksum is inside the UDP encapsulated IPsec packet).
encapsulated IPsec packet).
Issues: Issues:
N/A
See Also: See Also:
IKE IKE
6.15. IP Compression 7.14 IP Compression
Definition: Definition:
TBD [IPPCP RFC2393]
A mechanism as defined in [RFC2393] that reduces the size of the
payload that needs to be encrypted.
Discussion: Discussion:
TBD
IP payload compression is a protocol to reduce the size of IP
datagrams. This protocol will increase the overall communication
performance between a pair of communicating hosts/gateways
("nodes") by compressing the datagrams, provided the nodes have
sufficient computation power, through either CPU capacity or a
compression coprocessor, and the communication is over slow or
congested links.
IP payload compression is especially useful when encryption is
applied to IP datagrams. Encrypting the IP datagram causes the
data to be random in nature, rendering compression at lower
protocol layers (e.g., PPP Compression Control Protocol [RFC1962])
ineffective. If both compression and encryption are required,
compression must be applied before encryption.
Issues: Issues:
See Also: N/A
6.16. Security Context 7.15 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 describe the characteristics of the path that a tunnel will take,
take, all of the tunnel parameters and the effects it has on all of the tunnel parameters and the effects it has on the
the underlying protected traffic. Security Context underlying protected traffic. Security Context encompasses
encompasses protocol suite and security policy(ies). protocol suite and security policy(ies).
Discussion: Discussion:
In order to fairly compare multiple IPsec devices it is
imperative that an accurate overview is given of all security
parameters that were used to establish tunnels and to secure
the traffic between protected networks. To avoid listing to
much information when reporting metrics we have divided the
security context into an IKE context and an IPsec context.
When merely discussing the behavior of traffic flows through In order to fairly compare multiple IPsec devices it is imperative
IPsec devices, an IPsec context MUST be provided. In other that an accurate overview is given of all security parameters that
cases the scope of a discussion or report may focus on a more were used to establish tunnels and to secure the traffic between
broad set of behavioral characteristics of the IPsec device, protected networks. Security Context is not a metric; it is
the both and IPsec and an IKE context MUST be provided. included to accurately reflect the test environment variables when
reporting the methodology results. To avoid listing too much
information when reporting metrics, we have divided the security
context into an IKE context and an IPsec context.
When merely discussing the behavior of traffic flows through IPsec
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
behavioral characteristics of the IPsec device, the both and 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:
o Number of active IPsec tunnels
o IPsec tunnels per IKE tunnel (IKE/IPsec tunnel ratio)
o IPsec protocol
o IPsec mode (tunnel or transport)
o Authentication protocol used by IPsec
o Encryption protocol used by IPsec (if applicable)
o IPsec SA lifetime (traffic and time based)
The IPsec context MAY also list:
o Selectors
o Fragmentation handling
The IKE context MUST consist of the following elements: * Number of IPsec tunnels
o Number of active IKE tunnels.
o Authentication protocol used by IKE * IPsec tunnels per IKE tunnel (IKE/IPsec tunnel ratio)
o Encryption protocol used by IKE
o Key exchange mechanism (pre-shared key, Certificate, * IPsec protocol
etc)
o Key size (if applicable) * IPsec mode (tunnel or transport)
o Diffie-Hellman group
o IKE SA lifetime (time based) * Authentication protocol used by IPsec
o Keepalive, heartbeat or DPD values * Encryption protocol used by IPsec (if applicable)
o Compression (IPPCP RFC2393)
o PFS Diffie-Hellman group * IPsec SA lifetime (traffic and time based)
The IPsec Context MAY also list:
* Selectors
* Fragmentation handling
The IKE Context MUST consist of the following elements:
* Number of IKE tunnels.
* Authentication protocol used by IKE
* Encryption protocol used by IKE
* Key exchange mechanism (pre-shared key, certificate authority,
etc ...)
* Key size (if applicable)
* Diffie-Hellman group
* IKE SA lifetime (time based)
* Keepalive, heartbeat or DPD values [DPD]
* IP Compression [RFC2393]
* PFS Diffie-Hellman group
The IKE context MAY also list: The IKE context MAY also list:
o Phase 1 mode (main or aggressive)
o Available bandwidth and latency to Certificate * Phase 1 mode (main or aggressive)
Authority server (if applicable)
* Available bandwidth and latency to Certificate Authority server
(if applicable)
Issues: Issues:
A Security Context will be an important element in describing
the environment where protected traffic is traveling through. A Security Context will be an important element in describing the
environment where protected traffic is traveling through.
See Also: See Also:
IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase
2, Selectors, IPsec Tunnel
6.17. Performance Metrics IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2,
Selectors, IPsec Tunnel
6.17.1. Tunnels Per Second (TPS) 8. Performance Metrics
8.1 Tunnels Per Second (TPS)
Definition: Definition:
TBD
Tunnels Per Second; the measurement unit for the Tunnel Setup Rate
tests. The rate that tunnels are established per second.
Discussion: Discussion:
TBD
According to rfc 2401 two tunnels cannot be established between
the same gateways with the same selectors. This is to prevent
overlapping tunnels. If overlapping tunnels are attempted, the
error will take longer than if the tunnel setup was successful.
For this reason, a unique pair of selector sets are required for
TPS testing.
Issues: Issues:
A unique pair of selector sets are required for TPS testing.
See Also: See Also:
6.17.2. Tunnel Flaps Per Second (TFPS) Tunnel Setup Rate Behavior; Tunnel Setup Rate, IKE Setup Rate,
IPsec Setup Rate
8.2 Tunnel Rekeys Per Seconds (TRPS)
Definition: Definition:
TBD
A metric that quantifies the number of tunnel rekey's per seconds
a DUT can correctly process.
Discussion: Discussion:
TBD This metric will be will be primary used with Tunnel Rekey
behavior tests.
TRPS will provide a metric used to see system behavior under
stressful conditions where large volumes of tunnels are being
rekeyed at the same time or in a short timespan.
Issues: Issues:
N/A
See Also: See Also:
6.17.3. Tunnels Attempted Per Second (TAPS) Tunnel Rekey; Phase 1 Rekey Rate, Phase 2 Rekey Rate
8.3 Tunnel Attempts Per Second (TAPS)
Definition: Definition:
TBD
A metric that quantifies the number of valid or invalid tunnel
(both Phase 1 or Phase 2) establishment requests per second.
Discussion: Discussion:
TBD
This metric can be used to measure IKE DOS Resilience behavior
test.
TAPS provides an important metric to validate the stability of a
platform, if stressed with valid (large number of IPsec tunnel
establishments per seconds or TPS) or invalid (IKE DOS attacks of
any style) tunnel establishment requests.
Issues: Issues:
See Also: If the TAPS increases, the TPS usually decreases, due to burdening
of the DUT with the DOS attack traffic.
7. Test Terminology 9. Test Definitions
7.1. Framesizes 9.1 Framesizes
7.1.1. Layer3 Clear Framesize 9.1.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 payload. It SHALL NOT include any encapsulations that MAY
be applied before the PDU is processed for encryption. For
example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload.
Measurement units: In relation to IPsec this is the size of the IP header and its
payload. It SHALL NOT include any encapsulations that MAY be
applied before the PDU is processed for encryption.
For example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload.
Measurement Units:
Bytes Bytes
Issues: Issues:
N/A
See Also: See Also:
Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2
Encrypted Framesize. Encrypted Framesize.
7.1.2. Layer3 Encrypted Framesize 9.1.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 The size of the IP packet and its payload after encapsulations
MAY be applied and the PDU is being processed by the MAY be applied and the PDU is being processed by the transform.
transform. For example, after a tunnel mode ESP 3DES/SHA1
transform has been applied, an unencrypted or clear Layer3 For example, after a tunnel mode ESP 3DES/SHA1 transform has been
framesize of 46 bytes becomes 96 bytes: applied an unencrypted or clear layer3 framesize of 46 bytes
Becomes 96 bytes:
20 bytes outer IP header (tunnel mode) 20 bytes outer IP header (tunnel mode)
4 bytes SPI (ESP header) 4 bytes SPI (ESP header)
4 bytes Sequence (ESP Header) 4 bytes Sequence (ESP Header)
8 bytes IV (IOS ESP-3DES) 8 bytes IV (IOS ESP-3DES)
46 bytes payload 46 bytes payload
0 bytes pad (ESP-3DES 64 bit) 0 bytes pad (ESP-3DES 64 bit)
1 byte Pad length (ESP Trailer) 1 byte Pad length (ESP Trailer)
1 byte Next Header (ESP Trailer) 1 byte Next Header (ESP Trailer)
12 bytes ESP-HMAC SHA1 96 digest 12 bytes ESP-HMAC SHA1 96 digest
Measurement units: Measurement Units:
Bytes Bytes
Issues: Issues:
N/A
See Also: See Also:
Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2
Encrypted Framesize.
7.1.3. Layer2 Clear Framesize Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted
Framesize.
9.1.3 Layer2 clear framesize
Definition: Definition:
The total size of the unencrypted L2 PDU. The total size of the unencrypted L2 PDU.
Discussion: Discussion:
This is the Layer 3 clear framesize plus the entire layer2
overhead. In the case of Ethernet this would be 18 bytes. This is the Layer 3 clear framesize plus all the layer2 overhead.
For example, a 46 byte Layer3 clear framesize packet would In the case of Ethernet this would be 18 bytes.
become 64 bytes after Ethernet Layer2 overhead is added:
6 bytes destination MAC address For example, a 46 byte Layer3 clear framesize packet would become
6 bytes source MAC address 64 Bytes after Ethernet Layer2 overhead is added:
6 bytes destination mac address
6 bytes source mac address
2 bytes length/type field 2 bytes length/type field
46 bytes layer3 (IP) payload 46 bytes layer3 (IP) payload
4 bytes FCS 4 bytes FCS
Measurement units: Measurement Units:
Bytes Bytes
Issues: Issues:
If it is not mentioned explicitly what kind of framesize is
used, the layer2 clear framesize will be the default. If it is not mentioned explicitly what kind of framesize is used,
the layer2 clear framesize will be the default.
See Also: See Also:
Layer3 clear framesize, Layer2 encrypted framesize, Layer2 Layer3 clear framesize, Layer2 encrypted framesize, Layer2
encrypted framesize. encrypted framesize.
7.1.4. Layer2 encrypted framesize 9.1.4 Layer2 encrypted framesize
Definition: Definition:
The total size of the encrypted L2 PDU. The total size of the encrypted L2 PDU.
Discussion: Discussion:
This is the Layer 3 encrypted framesize plus all the Layer2
overhead. In the case of Ethernet this would be 18 bytes. For This is the Layer 3 encrypted framesize plus all the layer2
example, a 96 byte Layer3 encrypted framesize packet would overhead. In the case of Ethernet this would be 18 bytes.
For example, a 96 byte Layer3 encrypted framesize packet would
become 114 bytes after Ethernet Layer2 overhead is added: become 114 bytes after Ethernet Layer2 overhead is added:
6 bytes destination mac address 6 bytes destination mac address
6 bytes source mac address 6 bytes source mac address
2 bytes length/type field 2 bytes length/type field
96 bytes layer3 (IPsec) payload 96 bytes layer3 (IPsec) payload
4 bytes FCS 4 bytes FCS
Measurement units: Measurement Units:
Bytes Bytes
Issues: Issues:
N/A
See Also: See Also:
Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2
Clear Framesize
7.2. Internet Mix Traffic (IMIX) Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2 Clear
Framesize
9.2 Internet Mix Traffic (IMIX)
Definition: Definition:
A traffic pattern consisting of a preset mixture of framesizes A traffic pattern consisting of a preset mixture of framesizes
used to emulate real-world traffic scenarios in a testing used to emulate real-world traffic scenarios in a testing
environment. environment.
Discussion: Discussion:
IMIX traffic patterns can be used to measure different
forwarding behaviors of the IPsec device with pseudo live
traffic.
Several facilities, including the National Laboratory for IMIX traffic patterns can be used to measure different forwarding
Applied Network Research, have collected and reported traffic behaviors of the IPsec device with pseudo live traffic.
Several facilities have collected and reported traffic
distribution by monitoring live Internet links. The study distribution by monitoring live Internet links. The study
concluded that in a simulation environment, a small mix of concluded that in a simulation environment, a small mix of packets
packets in a preset ratio can resemble to a certain degree the in a preset ratio can resemble to a certain degree the live
live traffic that was monitored during the study. One of the traffic that was monitored during the study. One of the mixes is
mixes is called (simple) IMIX and consists of 7 parts 64 byte called (simple) and consists of 7 parts 64 byte packets, 4 parts
packets, 4 parts 570 byte packets and 1 1518 byte 570 byte packets and 1 1518 byte packet.
packet.[IMIX]
Measurement units:
TBD
Issues: Issues:
The ratio of frame sizes sent and traffic distribution to be The ratio of frame sizes sent and traffic distribution to be
determined by the test methodology. determined by the test methodology.
See Also: 9.3 Throughput
7.3. Throughput
7.3.1. IPsec Tunnel Throughput 9.3.1 IPsec Tunnel Throughput
Definition: Definition:
The forwarding rate through an established IKE/IPsec tunnel at
which none of the offered frames are dropped by the device The forwarding rate through an IKE/IPsec tunnel at which none of
under test. the offered frames are dropped by the device under test.
Discussion: Discussion:
The IPsec Tunnel Throughput is almost identically defined as The IPsec Tunnel Throughput is almost identically defined as
Throughput in RFC 1242, section 3.17. The only difference is Throughput in [RFC1242], section 3.17. The only difference is that
that the throughput is measured with a traffic flow that is the throughput is measured with a traffic flow getting encrypted
getting encrypted and decrypted by an IPsec device. The and decrypted by an IPsec device. The Tunnel Throughput is an
Tunnel Throughput is an end-to-end measurement and is intended end-to-end measurement and is intended to characterize end-user
to characterize end-user forwarding behavior. forwarding behavior.
The metric can be represented in two variants depending on The metric can be represented in two variants depending on where
where the in the SUT the measurement is taken. One can look measurement is taken in the SUT. One can look at throughput from a
at throughput from a cleartext point of view i.e. find the cleartext point of view i.e. find the forwarding rate where
forwarding rate where clearpackets no longer get dropped. clearpackets no longer get dropped. This forwarding rate can be
This forwarding rate can be recalculated with an encrypted recalculated with an encrypted framesize to represent the
framesize to represent the encryption forwarding rate. The encryption forwarding rate. The latter is the preferred method of
latter is the preferred method of representation. representation.
Measurement Units:
Measurement units:
Packets per seconds (pps), Mbps Packets per seconds (pps), Mbps
Issues: Issues:
N/A
See Also: See Also:
7.3.2. IPsec Tunnel Encryption Throughput IPsec Encryption Throughput, IPsec Decryption Throughput
9.3.2 IPsec Encryption Throughput
Definition: Definition:
The maximum encryption rate through an established IPsec
tunnel at which none of the offered cleartext frames are The maximum encryption rate through an IPsec tunnel at which none
dropped by the device under test. of the offered cleartext frames are dropped by the device under
test.
Discussion: Discussion:
Since it is not necessarily the case that the encryption
throughput is equal to the decryption throughput, both of the
forwarding rates must be measured independently.
The independent forwarding rates have to be measured with the Since encryption throughput is not necessarily equal to the
help of an IPsec aware test device that can originate and decryption throughput, both of the forwarding rates must be
terminate IPsec and IKE tunnels. As defined in RFC 1242, measured independently. The independent forwarding rates have to
measurements should be taken with an assortment of frame measured with the help of an IPsec aware test device that can
sizes. originate and terminate IPsec and IKE tunnels. As defined in
[RFC1242], measurements should be taken with an assortment of
frame sizes.
Measurement Units:
Measurement units:
Packets per seconds (pps), Mbps Packets per seconds (pps), Mbps
Issues: Issues:
N/A
See Also: See Also:
7.3.3. IPsec Tunnel Decryption Throughput IPsec Tunnel Throughput, IPsec Decryption Throughput
9.3.3 IPsec Decryption Throughput
Definition: Definition:
The maximum decryption rate through an established IPsec
tunnel at which none of the offered encrypted frames are The maximum decryption rate through an IPsec tunnel at which none
dropped by the device under test. of the offered encrypted frames are dropped by the device under
test.
Discussion: Discussion:
Since it is not necessarily the case that the encryption
throughput is equal to the decryption throughput, both of the
forwarding rates must be measured independently.
The independent forwarding rates have to be measured with the Since encryption throughput is not necessarily equal to the
help of an IPsec aware test device that can originate and decryption throughput, both of the forwarding rates must be
terminate IPsec tunnels. As defined in RFC 1242, measurements measured independently.
The independent forwarding rates have to be measured with the help
of an IPsec aware test device that can originate and terminate
IPsec and IKE tunnels. As defined in [RFC1242], measurements
should be taken with an assortment of frame sizes. should be taken with an assortment of frame sizes.
Measurement units: Measurement Units:
Packets per seconds (pps), Mbps Packets per seconds (pps), Mbps
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:
7.4. Latency IPsec Tunnel Throughput, IPsec Encryption Throughput
7.4.1. IPsec Tunnel Encryption Latency 9.4 Latency
9.4.1 IPsec Tunnel Encryption Latency
Definition: Definition:
The IPsec Tunnel Encryption Latency is the time interval
starting when the end of the first bit of the cleartext frame The IPsec Tunnel Encryption Latency is the time interval starting
reaches the input interface, through an established IPsec when the end of the first bit of the cleartext frame reaches the
tunnel, and ending when the start of the first bit of the input interface, through an IPsec tunnel, and ending when the
encrypted output frame is seen on the output interface. start of the first bit of the encrypted output frame is seen on
the output interface.
Discussion: Discussion:
IPsec Tunnel Encryption latency is the latency that is
introduced when encrypting traffic through an established
IPsec tunnel.
Like encryption/decryption throughput, it is not always the IPsec Tunnel Encryption latency is the latency introduced when
case that encryption latency equals the decryption latency. encrypting traffic through an IPsec tunnel.
Therefore a distinction between the two has to be made in
order to get a more accurate view of where the latency is the Like encryption/decryption throughput, it is not always the case
most pronounced. that encryption latency equals the decryption latency. Therefore 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.
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
RFC 1242, 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
See Also: See Also:
7.4.2. IPsec Tunnel Decryption Latency IPsec Tunnel Decryption Latency
9.4.2 IPsec Tunnel Decryption Latency
Definition: Definition:
The IPsec Tunnel decryption Latency is the time interval
starting when the end of the first bit of the encrypted frame The IPsec Tunnel decryption Latency is the time interval starting
reaches the input interface, through an established IPsec when the end of the first bit of the encrypted frame reaches the
tunnel, and ending when the start of the first bit of the input interface, through an IPsec tunnel, and ending when the
decrypted output frame is seen on the output interface. start of the first bit of the decrypted output frame is seen on
the output interface.
Discussion: Discussion:
IPsec Tunnel decryption latency is the latency that is
introduced when decrypting traffic through an established IPsec Tunnel decryption latency is the latency introduced when
IPsec tunnel. Like encryption/decryption throughput, it is decrypting traffic through an IPsec tunnel. Like encryption/
not always the case that encryption latency equals the decryption throughput, it is not always the case that encryption
decryption latency. Therefore a distinction between the two latency equals the decryption latency. Therefore a distinction
has to be made in order to get a more accurate view of where between the two has to be made in order to get a more accurate
the latency is the most pronounced. view of where the latency is the most pronounced.
The independent encryption/decryption latencies have to be The independent encryption/decryption latencies have to be
measured with the help of an IPsec aware test device that can measured with the help of an IPsec aware test device that can
originate and terminate IPsec and IKE tunnels. As defined in originate and terminate IPsec and IKE tunnels. As defined in
RFC 1242, 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
See Also: See Also:
7.4.3. Time To First Packet (TTFP) IPsec Tunnel Encryption Latency
9.4.3 Time To First Packet
Definition: Definition:
The Time To First Packet (TTFP) is the time required to
process a cleartext packet when no tunnel is present. The Time To First Packet (TTFP) is the time required process an
cleartext packet when no tunnel is present.
Discussion: Discussion:
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 established tunnel path. The TTFP MUST include the
time to set up the tunnel that is triggered by the traffic
flow (both phase 1 and phase 2 setup times are included) and
the time it takes to encrypt and decrypt the packet on a
corresponding peer.
It must be noted that it is highly unlikely that the first The TTFP addresses the issue of responsiveness of an IPsec device
packet of the traffic flow will be the packet that will be by looking how long it take to transmit a packet over a not yet
used to measure the TTFP. There MAY be several protocol established tunnel path. The TTFP MUST include the time to set up
layers in the stack before the tunnel is formed. Traffic is the tunnel, triggered by the traffic flow (both phase 1 and phase
forwarded and several packets could be lost during 2 setup times are included) and the time it takes to encrypt and
negotiation, for example, ARP and/or IKE. decrypt the packet on a corresponding peer.
Measurement units: It must be noted that it is highly unlikely that the first packet
Time units with enough precision to reflect a TTFP of the traffic flow will be the packet that will be used to
measurement. measure the TTFP. There MAY be several protocol layers in the
stack before the tunnel is formed and the traffic is forwarded,
hence several packets COULD be lost during negotiation, for
example, ARP and/or IKE.
Measurement Units:
Time units with enough precision to reflect a TTFP measurement.
Issues: Issues:
See Also: N/A
7.5. Frame Loss Rate 9.5 Frame Loss Rate
7.5.1. IPsec Tunnel Encryption Frame Loss Rate 9.5.1 IPsec Tunnel Encryption Frame Loss Rate
Definition: Definition:
Percentage of cleartext frames that should have been encrypted Percentage of cleartext frames that should have been encrypted
through an established IPsec tunnel under steady state through an IPsec tunnel under steady state (constant) load but
(constant)load but were dropped. were dropped.
Discussion: Discussion:
TBD
Measurement units: DUT's will always have an inherent forwarding limitation. This
will be more pronounced when IPsec is employed on the DUT. The
moment that a Tunnel is established and traffic is offered at a
given rate that will flow through that tunnel, there is a
possibility that the offered traffic rate at the tunnel is too
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 is called the IPsec Tunnel Encryption Frame Loss Rate.
Measurement Units:
Percent (%) Percent (%)
Issues: Issues:
N/A
See Also: See Also:
7.5.2. IPsec Tunnel Decryption Frame Loss Rate IPsec Tunnel Decryption Frame Loss Rate
9.5.2 IPsec Tunnel Decryption Frame Loss Rate
Definition: Definition:
Percentage of encrypted frames that should have been decrypted Percentage of encrypted frames that should have been decrypted
through an established IPsec tunnel under steady state through an IPsec tunnel under steady state (constant) load but
(constant)load but were dropped. were dropped.
Discussion: Discussion:
TBD
Measurement units: A DUT will also have an inherent forwarding limitation when
Percent (%) decrypting packets. When established tunnel encrypted traffic is
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
perfom this action on all of the packets due to limitations of the
decryption performance. The percentage of encrypted frames that
would get dropped under these conditions is called the IPsec
Tunnel Decryption Frame Loss Rate.
Measurement Units:
Percent (%)
Issues: Issues:
N/A
See Also: See Also:
7.6. Back-to-Back IPsec Tunnel Encryption Frame Loss Rate
7.6.1. Encryption Back-to-Back Frames 9.6 Back-to-back Frames
9.6.1 Encryption Back-to-back Frames
Definition: Definition:
The number of cleartext frames, offered at a constant load
that can be sent through an established IPsec tunnel without A burst of cleartext frames, offered at a constant load that can
losing a single encrypted frame. be sent through an IPsec tunnel without losing a single encrypted
frame.
Discussion: Discussion:
TBD
Measurement units: Encryption back-to-back frames is the measure of the maximum burst
Frames size that a device can handle for encrypting traffic that it
receives as plaintext. Since it is not necessarily the case that
the maximum burst size a DUT can handle for encryption is equal to
the maximum burst size a DUT can handle for decryption, both of
these capabilities must be measured independently. The encryption
back-to-back frame measurement has to be measured with the help of
an IPsec aware test device that can decrypt the traffic to
determine the validity of the encrypted frames.
Measurement Units:
Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future
methodology document.
See Also: See Also:
Decryption Back-to-back frames Decryption Back-to-back frames
7.6.2. Decryption Back-to-back frames 9.6.2 Decryption Back-to-back Frames
Definition: Definition:
The number of encrypted frames, offered at a constant load,
that can be sent through an established IPsec tunnel without The number of encrypted frames, offered at a constant load, that
losing a single cleartext frame. can be sent through an IPsec tunnel without losing a single
cleartext frame.
Discussion: Discussion:
TBD
Measurement units: Decryption back-to-back frames is the measure of the maximum burst
Frames size that a device can handle for decrypting traffic that it
receives as encrypted traffic. Since it is not necessarily the
case that the maximum burst size a DUT can handle for decryption
is equal to the maximum burst size a DUT can handle for
encryption, both of these capabilities must be measured
independently. The decryption back-to-back frame measurement has
to be measured with the help of an IPsec aware test device that
can determine the validity of the decrypted frames.
Measurement Units:
Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future
methodology document.
See Also: See Also:
Encryption back-to-back frames Encryption back-to-back frames
7.7. Tunnel Setup Rate Behavior 9.7 Tunnel Setup Rate Behavior
7.7.1. Tunnel Setup Rate 9.7.1 Tunnel Setup Rate
Definition: Definition:
The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per
second that an IPsec device can successfully establish. The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per second
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
established tunnels on the DUT. tunnels on the DUT. Several factors may influence Tunnel Setup
Rate, such as: TAPS rate, Background Load on crypto link (clear
traffic), Already established tunnels, Authentication method:
pre-shared keys, RSA-encryption, RSA-signature, DSS Key sizes used
(when using RSA/DSS)
Measurement Units:
Tunnels Per Second (TPS)
Measurement units:
Tunnels per second (TPS)
Issues: Issues:
N/A
See Also: See Also:
7.7.2. IKE Tunnel Setup Rate IKE Setup Rate, IPsec Setup Rate
9.7.2 IKE Setup Rate
Definition: Definition:
The maximum number of IKE tunnels per second that an IPsec
device can be observed to successfully establish. The maximum number of IKE tunnels per second that an IPsec device
can be observed to 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
established tunnels on the DUT. tunnels on the DUT.
Measurement units: Measurement Units:
Tunnels per second (TPS)
Tunnels Per Second (TPS)
Issues: Issues:
N/A
See Also: See Also:
Rekey Time
7.7.3. IPsec Tunnel Setup Rate Tunnel Setup Rate, IPsec Setup Rate
9.7.3 IPsec Setup Rate
Definition: Definition:
The maximum number of IPsec tunnels per second that a IPsec
device can be observed to successfully establish. The maximum number of IPsec tunnels per second that a IPsec device
can be observed to 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
established tunnels on the DUT. tunnels on the DUT.
Measurement units: Measurement Units:
Tunnels per second (TPS)
Tunnels Per Second (TPS)
Issues: Issues:
N/A
See Also: See Also:
Tunnel Rekey Tunnel Rekey
7.8. Tunnel Rekey 9.8 Tunnel Rekey
7.8.1. Phase 1 Rekey Time 9.8.1 Phase 1 Rekey Rate
Definition: Definition:
The interval necessary for a particular Phase 1 to re-
establish after the previous Phase 1 lifetime [hard or soft]
has expired.
Discussion:
TBD
Measurement units:
Time units with enough precision to reflect rekey time
measurement.
Issues: The interval necessary for a particular Phase 1 to re-establish
after the previous Phase 1 lifetime (hard or soft) has expired.
See Also:
Phase 2 Rekey Time, Tunnel Flapping
7.8.2. Phase 2 Rekey Time Discussion:
Definition: Although many implementations will usually derive new keying
The interval necessary for a particular Phase 2 to re- material before the old keys expire, there may still be a period
establish after the previous Phase 2 lifetime [hard or soft] of time where frames get dropped before the phase 1 and subsequent
has expired. phase 2 tunnels are successfully (re)established. To measure the
phase 1 rekey rate, the measurement will require an IPsec aware
test device to act as a responder when negotiating the new phase 1
key.
Discussion: Measurement Units:
TBD
Measurement units: Time units with enough precision to reflect rekey rate
Time units with enough precision to reflect rekey time
measurement. measurement.
Issues: Issues:
N/A
See Also: See Also:
Phase 1 Rekey Time , Tunnel Flapping
7.9. Tunnel Flapping Phase 2 Rekey Rate
9.8.2 Phase 2 Rekey Rate
Definition: Definition:
A behavior observed where a tunnel is dropped and then re-
established with the same parameters.
Discussion: The interval necessary for a particular Phase 2 to re-establish
TBD after the previous Phase 2 lifetime (hard or soft) has expired.
Measurement units: Discussion:
TBD
Issues: The test methodology report must specify if PFS is enabled in
reported security context.
See Also: Measurement Units:
Phase 1 Rekey Time, Phase 2 Rekey Time
7.9.1. Tunnel Flap Rate Time units with enough precision to reflect rekey rate
measurement.
Definition: Issues:
The number of times per second a tunnel is dropped and re-
established.
Discussion: N/A
TBD
Measurement units: See Also:
Tunnel flaps per second (TFPS)
Issues: Phase 1 Rekey Rate
See Also: 9.9 Tunnel Failover Time (TFT)
Phase 1 Rekey Time, Phase 2 Rekey Time
7.10. Tunnel Failover Time (TFT)
Definition: Definition:
Recovery time required to re-establish all tunnels on a
standby node or other failsafe system after a tunnel failing Time required to recover all tunnels on a stanby IPsec device,
event has occurred, such as a catastrophic IPsec device after a catastrophic failure occurs on the active IPsec device.
failure, including all traffic that previously ran through
those tunnels. The recovery time is delta between the point
of failure and when the first packet is seen on the last
restored tunnel on the backup device.
Discussion: Discussion:
TBD
Measurement units: Recovery time required to re-establish all tunnels and reroute all
Tunnel flaps per second (TFPS) 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: Issues:
See Also: N/A
Tunnel Flapping
7.11. IKE DOS Resilience Rate 10. IKE DOS Resilience Rate
Definition: Definition:
The IKE Denial Of Service (DOS) Resilience Rate provides a
rate of invalid or mismatching IKE tunnels setup attempts at The IKE Denial Of Service (DOS) Resilience Rate provides a rate of
which it is no longer possible to set up a valid IKE tunnel. invalid or mismatching IKE tunnels setup attempts at which it is
no longer possible to set up a valid IKE tunnel.
Discussion: Discussion:
The IKE DOS Resilience Rate will provide a metric to how
robust and hardened an IPsec device is against malicious
attempts to set up a tunnel.
IKE DOS attacks can pose themselves in various forms and do The IKE DOS Resilience Rate will provide a metric to how robust
not necessarily have to have a malicious background. It is and hardened an IPsec device is against malicious attempts to set
sufficient to make a typographical error in a shared secret in up a tunnel.
an IPsec 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, IKE DOS attacks can pose themselves in various forms and do not
a system might end up in a state that it is only doing key necessarily have to have a malicious background. It is sufficient
exchanges and burdening the CPU for any other processes that to make a typographical error in a shared secret in an IPsec
might be running in the IPsec device. At this point it will aggregation device to be susceptible to a large number of IKE
be no longer be possible to process a valid IKE tunnel setup attempts that need to be turned down. Due to the intense
request and thus IKE DOS is in effect. 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.
Measurement units: Depending on how many of these messages have to be processed, a
Tunnel attempts per second (TAPS) 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:
Tunnel Attempts Per Seconds (TAPS)
Issues: Issues:
See Also: N/A
8. Security Considerations 11. Security Considerations
As this document is solely for the purpose of providing test As this document is solely for the purpose of providing test
benchmarking terminology and describes neither a protocol nor a benchmarking terminology and describes neither a protocol nor a
protocol's implementation; there are no security considerations protocol's implementation; there are no security considerations
associated with this document. associated with this document.
9. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the following individual for The authors would like to acknowledge the following individual for
their help and participation of the compilation and editing of this their help and participation of the compilation and editing of this
document Debby Stopp, Ixia. document: Debby Stopp, Ixia.
10. Contributors 13. Contributors
The authors would like to acknowledge the following individual for The authors would like to acknowledge the following individual for
their help and contributions to this document Sunil Kalidindi, their significant help, guidance, and contributions to this document:
Ixia. Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI.
11. References
Normative References 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
skipping to change at page 35, line 5 skipping to change at page 48, line 45
[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", RFC
2402, November 1998. 2402, November 1998.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of [RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998. Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet [RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet
Security Association and Key Management Protocol(ISAKMP)", RFC Security Association and Key Management Protocol
2408, November 1998. (ISAKMP)", RFC 2408, November 1998.
[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
Its Use With IPsec", RFC 2410, November 1998.
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998. 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.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange [I-D.ietf-ipsec-ikev2]
Mechanism for Internet", from IEEE Proceedings of the 1996 Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
Symposium on Network and Distributed Systems Security, URL draft-ietf-ipsec-ikev2-08 (work in progress), June 2003.
http://www.research.ibm.com/security/skeme.ps, 1996.
[IMIX] National Library for Applied Network Research (NLANR),
February 2001, ANI-9807479
Informative References
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [I-D.ietf-ipsec-nat-t-ike]
Its Use With IPsec", RFC 2410, November 1998. Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
draft-ietf-ipsec-nat-t-ike-06 (work in progress), May
2003.
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security [I-D.ietf-ipsec-udp-encaps]
Document Roadmap", RFC 2411, November 1998. Huttunen, A., "UDP Encapsulation of IPsec Packets",
draft-ietf-ipsec-udp-encaps-06 (work in progress), January
2003.
[I-D.ietf-ipsec-ikev2] Kaufman, C., "Internet Key Exchange (IKEv2) [I-D.ietf-ipsec-nat-reqts]
Protocol",draft-ietf-ipsec-ikev2-04 (work in progress), Aboba, B. and W. Dixon, "IPsec-NAT Compatibility
January 2003. Requirements", draft-ietf-ipsec-nat-reqts-04 (work in
progress), March 2003.
[I-D.ietf-ipsec-nat-reqts] Aboba, B. and W. Dixon, "IPsec-NAT [I-D.ietf-ipsec-properties]
Compatibility Requirements", draft-ietf-ipsec-nat-reqts-03 Krywaniuk, A., "Security Properties of the IPsec Protocol
(work in progress), January 2003. Suite", draft-ietf-ipsec-properties-02 (work in progress),
July 2002.
[I-D.ietf-ipsec-nat-t-ike] Kivinen, T., "Negotiation of NAT-Traversal [FIPS.186-1.1998]
in the IKE", draft-ietf-ipsec-nat-t-ike-05 (work in National Institute of Standards and Technology, "Digital
progress),January 2003. Signature Standard", FIPS PUB 186-1, December 1998,
<http://csrc.nist.gov/fips/fips1861.pdf>.
[I-D.ietf-ipsec-properties] Krywaniuk, A., "Security Properties of Informative References
the IPsec Protocol Suite", draft-ietf-ipsec-properties-02
(work in progress), July 2002.
[I-D.ietf-ipsec-udp-encaps] Huttunen, A., "UDP Encapsulation of IPsec [Designing Network Security]
Packets", draft-ietf-ipsec-udp-encaps-06 (work in progress) Kaeo, M., "Designing Network Security", ISBN: 1578700434,
Published: May 07, 1999; Copyright: 1999, 1999.
[FIPS.186-1.1998] National Institute of Standards and Technology, [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
"Digital Signature Standard", FIPS PUB 186-1, December 1998, Mechanism for Internet", from IEEE Proceedings of the
<http://csrc.nist.gov/fips/fips1861.pdf>. 1996 Symposium on Network and Distributed Systems
Security, URI http://www.research.ibm.com/security/
skeme.ps, 1996.
[Hu95] Huitema, C., "Routing in the Internet", Prentice Hall, 1995. [DPD] "DPD draft-ietf-ipsec-dpd-02", , URI http://www.ietf.org/
January 2003. internet-drafts/draft-ietf-ipsec-dpd-02.txt.
12. Contact Information Authors' Addresses
Michele Bustos Michele Bustos
IXIA IXIA
26601 W. Agoura Rd. 26601 W. Agoura Rd.
Calabasas, CA 91302 Calabasas, CA 91302
USA US
Phone: 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, Inc.
170 W. Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
USA US
Phone: 408 527 2461
Email: herckt@cisco.com
Phone: +1 (408)527-2461
EMail: herct@cisco.com
Merike Kaeo Merike Kaeo
Merike, Inc.
123 Ross Street 123 Ross Street
Santa Cruz, CA 95060 Santa Cruz, CA 95060
USA US
Phone: 831 818 4864 Phone: +1 (831)818-4864
Email: kaeo@merike.com EMail: kaeo@merike.com
13. Full Copyright Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies 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
obtain a general license or permission for the use of such
proprietary rights by implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved.
"Copyright (C) The Internet Society (2003). 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 others, and derivative works that comment on or otherwise explain it
it or assist in its implementation may be prepared, copied, or assist in its implementation may be prepared, copied, published
published and distributed, in whole or in part, without restriction and distributed, in whole or in part, without restriction of any
of any kind, provided that the above copyright notice and this kind, provided that the above copyright notice and this paragraph are
paragraph are included on all such copies and derivative works. included on all such copies and derivative works. However, this
However, this document itself may not be modified in any way, such document itself may not be modified in any way, such as by removing
as by removing the copyright notice or references to the Internet the copyright notice or references to the Internet Society or other
Society or other Internet organizations, except as needed for the Internet organizations, except as needed for the purpose of
purpose of developing Internet standards in which case the developing Internet standards in which case the procedures for
procedures for copyrights defined in the Internet Standards process copyrights defined in the Internet Standards process must be
must be followed, or as required to translate it into. followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
 End of changes. 391 change blocks. 
925 lines changed or deleted 1491 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/