draft-ietf-bmwg-ipsec-term-03.txt   draft-ietf-bmwg-ipsec-term-04.txt 
Benchmarking Working Group M. Bustos Benchmarking Working Group M. Bustos
Internet-Draft IXIA Internet-Draft IXIA
Expires: August 30, 2004 T. Van Herck Expires: January 30, 2005 T. Van Herck
Cisco Systems, Inc. Cisco Systems
M. Kaeo M. Kaeo
Merike, Inc. Double Shot Security
August 2004
Terminology for Benchmarking IPSec Devices Terminology for Benchmarking IPSec Devices
draft-ietf-bmwg-ipsec-term-03 draft-ietf-bmwg-ipsec-term-04
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 other Task Force (IETF), its areas, and its working groups. Note that
groups may also distribute working documents as Internet-Drafts. other groups may also distribute working documents as
Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at 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 August 30, 2004. This Internet-Draft will expire on January 30, 2005.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved. Copyright (C) The Internet Society (2004). 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 [RFC1242], [RFC2544], [RFC2285] and other IETF
Benchmarking Methodology Working Group (BMWG) documents used for Benchmarking Methodology Working Group (BMWG) documents used for
benchmarking routers and switches. This document seeks to extend benchmarking routers and switches. This document seeks to extend
these efforts specific to the IPsec paradigm. The BMWG produces two these efforts specific to the IPsec paradigm. The BMWG produces two
major classes of documents: Benchmarking Terminology documents and major classes of documents: Benchmarking Terminology documents and
Benchmarking Methodology documents. The Terminology documents present Benchmarking Methodology documents. The Terminology documents
the benchmarks and other related terms. The Methodology documents present the benchmarks and other related terms. The Methodology
define the procedures required to collect the benchmarks cited in the documents define the procedures required to collect the benchmarks
corresponding Terminology documents. cited in the corresponding Terminology documents.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . 4 2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . 4
2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6 2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Security Associations . . . . . . . . . . . . . . . . . . 6 2.1.1 Security Associations . . . . . . . . . . . . . . . . 6
2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . 6
3. Document Scope . . . . . . . . . . . . . . . . . . . . . . 8 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 8
4. Definition Format . . . . . . . . . . . . . . . . . . . . 8 4. Definition Format . . . . . . . . . . . . . . . . . . . . . 8
5. Key Words to Reflect Requirements . . . . . . . . . . . . 9 5. Key Words to Reflect Requirements . . . . . . . . . . . . . 9
6. Existing Benchmark Definitions . . . . . . . . . . . . . . 9 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . 9
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3.1 IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . . . 12 7.3.1 IKEv1 Phase 1 . . . . . . . . . . . . . . . . . . . . 12
7.3.2 Phase 1 Main Mode . . . . . . . . . . . . . . . . . . . . 12 7.3.2 IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 12
7.3.3 Phase 1 Aggressive Mode . . . . . . . . . . . . . . . . . 13 7.3.3 IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 13
7.3.4 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 13 7.3.4 IKEv2 Phase 1 . . . . . . . . . . . . . . . . . . . . 13
7.3.5 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . . . 14 7.3.5 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 14
7.3.6 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 15
7.4 Security Association (SA) . . . . . . . . . . . . . . . . 15 7.4 Security Association (SA) . . . . . . . . . . . . . . . . 15
7.5 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 15 7.5 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 16
7.6 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 16 7.6 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 17
7.6.1 Initiator . . . . . . . . . . . . . . . . . . . . . . . . 17 7.6.1 Initiator . . . . . . . . . . . . . . . . . . . . . . 17
7.6.2 Responder . . . . . . . . . . . . . . . . . . . . . . . . 17 7.6.2 Responder . . . . . . . . . . . . . . . . . . . . . . 18
7.6.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . . . 18 7.6.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . 18
7.6.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . . . 18 7.6.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . 19
7.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 19 7.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.7.1 IKE Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 19 7.7.1 IKE Tunnel . . . . . . . . . . . . . . . . . . . . . . 20
7.7.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . . . 20 7.7.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 20
7.7.3 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.7.3 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 21
7.7.4 Configured Tunnel . . . . . . . . . . . . . . . . . . . . 21 7.7.4 Configured Tunnel . . . . . . . . . . . . . . . . . . 22
7.7.5 Established Tunnel . . . . . . . . . . . . . . . . . . . . 21 7.7.5 Established Tunnel . . . . . . . . . . . . . . . . . . 22
7.7.6 Active Tunnel . . . . . . . . . . . . . . . . . . . . . . 22 7.7.6 Active Tunnel . . . . . . . . . . . . . . . . . . . . 23
7.8 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 23 7.8 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 24
7.8.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . . . 23 7.8.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . 24
7.8.2 Transport Adjacency . . . . . . . . . . . . . . . . . . . 24 7.8.2 Transport Adjacency . . . . . . . . . . . . . . . . . 25
7.9 Transform protocols . . . . . . . . . . . . . . . . . . . 25 7.9 Transform protocols . . . . . . . . . . . . . . . . . . . 25
7.9.1 Authentication Protocols . . . . . . . . . . . . . . . . . 25 7.9.1 Authentication Protocols . . . . . . . . . . . . . . . 26
7.9.2 Encryption Protocols . . . . . . . . . . . . . . . . . . . 26 7.9.2 Encryption Protocols . . . . . . . . . . . . . . . . . 26
7.10 IPSec Protocols . . . . . . . . . . . . . . . . . . . . . 26 7.10 IPSec Protocols . . . . . . . . . . . . . . . . . . . . 27
7.10.1 Authentication Header (AH) . . . . . . . . . . . . . . . . 27 7.10.1 Authentication Header (AH) . . . . . . . . . . . . . 28
7.10.2 Encapsulated Security Payload (ESP) . . . . . . . . . . . 28 7.10.2 Encapsulated Security Payload (ESP) . . . . . . . . 28
7.11 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 28 7.11 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . 29
7.12 IP Compression . . . . . . . . . . . . . . . . . . . . . . 29 7.12 IP Compression . . . . . . . . . . . . . . . . . . . . . 30
7.13 Security Context . . . . . . . . . . . . . . . . . . . . . 30 7.13 Security Context . . . . . . . . . . . . . . . . . . . . 30
8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . 32 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32 8.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32
8.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 32 8.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33
8.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 33 8.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34
8.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 34 8.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 34
9. Performance Metrics . . . . . . . . . . . . . . . . . . . 35 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . 35
9.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 35 9.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 35
9.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 35 9.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 36
9.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 36 9.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 36
10. Test Definitions . . . . . . . . . . . . . . . . . . . . . 36 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . 37
10.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . 37
10.1.1 Tunnel Throughput . . . . . . . . . . . . . . . . . . . . 36 10.1.1 Tunnel Throughput . . . . . . . . . . . . . . . . . 37
10.1.2 IPsec Encryption Throughput . . . . . . . . . . . . . . . 37 10.1.2 IPsec Encryption Throughput . . . . . . . . . . . . 38
10.1.3 IPsec Decryption Throughput . . . . . . . . . . . . . . . 38 10.1.3 IPsec Decryption Throughput . . . . . . . . . . . . 38
10.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . 39
10.2.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . . . . 38 10.2.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . 39
10.2.2 IPsec Tunnel Encryption Latency . . . . . . . . . . . . . 39 10.2.2 IPsec Tunnel Encryption Latency . . . . . . . . . . 40
10.2.3 IPsec Tunnel Decryption Latency . . . . . . . . . . . . . 40 10.2.3 IPsec Tunnel Decryption Latency . . . . . . . . . . 41
10.2.4 Time To First Packet . . . . . . . . . . . . . . . . . . . 41 10.2.4 Time To First Packet . . . . . . . . . . . . . . . . 41
10.3 Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . 41 10.3 Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 42
10.3.1 IPSec Tunnel Frame Loss Rate . . . . . . . . . . . . . . . 41 10.3.1 IPSec Tunnel Frame Loss . . . . . . . . . . . . . . 42
10.3.2 IPsec Tunnel Encryption Frame Loss Rate . . . . . . . . . 42 10.3.2 IPsec Tunnel Encryption Frame Loss . . . . . . . . . 43
10.3.3 IPsec Tunnel Decryption Frame Loss Rate . . . . . . . . . 43 10.3.3 IPsec Tunnel Decryption Frame Loss . . . . . . . . . 43
10.4 Back-to-back Frames . . . . . . . . . . . . . . . . . . . 44 10.3.4 Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . 44
10.4.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . . . . 44 10.4 Back-to-back Frames . . . . . . . . . . . . . . . . . . 45
10.4.2 Encryption Back-to-back Frames . . . . . . . . . . . . . . 44 10.4.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . 45
10.4.3 Decryption Back-to-back Frames . . . . . . . . . . . . . . 45 10.4.2 Encryption Back-to-back Frames . . . . . . . . . . . 45
10.5 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . . 46 10.4.3 Decryption Back-to-back Frames . . . . . . . . . . . 46
10.5.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . . . . 46 10.5 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . 47
10.5.2 Phase 1 Setup Rate . . . . . . . . . . . . . . . . . . . . 46 10.5.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . 47
10.5.3 Phase 2 Setup Rate . . . . . . . . . . . . . . . . . . . . 47 10.5.2 Phase 1 Setup Rate . . . . . . . . . . . . . . . . . 47
10.6 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . . 47 10.5.3 Phase 2 Setup Rate . . . . . . . . . . . . . . . . . 48
10.6.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . . . 47 10.6 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . 49
10.6.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . . . 48 10.6.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . 49
10.7 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . . 49 10.6.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . 49
10.8 IKE DOS Resilience Rate . . . . . . . . . . . . . . . . . 49 10.7 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . 50 10.8 IKE DOS Resilience Rate . . . . . . . . . . . . . . . . 51
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 50 11. Security Considerations . . . . . . . . . . . . . . . . . . 52
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . 50 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
Normative References . . . . . . . . . . . . . . . . . . . 50 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
Informative References . . . . . . . . . . . . . . . . . . 52 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53 14.1 Normative References . . . . . . . . . . . . . . . . . . . 52
Intellectual Property and Copyright Statements . . . . . . 54 14.2 Informative References . . . . . . . . . . . . . . . . . . 54
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 56
1. Introduction 1. Introduction
Despite the need to secure communications over a public medium there Despite the need to secure communications over a public medium there
is no standard method of performance measurement nor a standard in is no standard method of performance measurement nor a standard in
the terminology used to develop such hardware/software solutions. the terminology used to develop such hardware and software solutions.
This results in varied implementations which challenge This results in varied implementations which challenge
interoperability and direct performance comparisons. Standarized interoperability and direct performance comparisons. Standardized
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 determine if the IPsec device they select will withstand
relatively heavy loads of secured traffic. loads of secured traffic that meet their requirements.
To appropriately define the parameters and scope of this To appropriately define the parameters and scope of this document,
document,this section will give a brief overview of the IPsec this section will give a brief overview of the IPsec standard:
standard:
2. 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 authenticity between confidentiality, data integrity, and data authenticity between
participating peers. IPsec provides these security services at the IP participating peers. IPsec provides these security services at the
layer. IPsec uses IKE to handle negotiation of protocols and IP layer. IPsec uses IKE to handle negotiation of protocols and
algorithms based on local policy, and to generate the encryption and algorithms based on local policy, and to generate the encryption and
authentication keys to be used. IPsec can be used to protect one or authentication keys to be used. IPsec can be used to protect one or
more data flows between a pair of hosts, between a pair of security more data flows between a pair of hosts, between a pair of security
gateways, or between a security gateway and a host. The IPsec gateways, or between a security gateway and a host. The IPsec
protocol suite set of standards is documented in RFC's 2401 through protocol suite set of standards is documented in RFC's [RFC2401]
2412 and RFC 2451. The reader is assumed to be familiar with these through [RFC2412] and [RFC2451]. The reader is assumed to be
documents. Some Internet Drafts supersede these RFC's and will be familiar with these documents. Some Internet Drafts supersede these
taken into consideration. RFC's and will be taken into consideration.
IPsec itself defines the following: IPsec itself defines the following:
Authentication Header (AH): A security protocol, defined in Authentication Header (AH): A security protocol, defined in
[RFC2402], which provides data authentication and optional [RFC2402], which provides data authentication and optional
anti-replay services. AH ensures the integrity and data origin anti-replay services. AH ensures the integrity and data origin
authentication of the IP datagram as well as the invariant fields in authentication of the IP datagram as well as the invariant fields in
the outer IP header. the outer IP header.
Encapsulating Security Payload (ESP): A security protocol, defined in Encapsulating Security Payload (ESP): A security protocol, defined in
[RFC2406], which provides confidentiality, data origin [RFC2406], which provides confidentiality, data origin
authentication, connectionless integrity, an anti-replay service and authentication, connectionless integrity, an anti-replay service and
limited traffic flow confidentiality. The set of services provided limited traffic flow confidentiality. The set of services provided
depends on options selected at the time of Security Association (SA) depends on options selected at the time of Security Association (SA)
establishment and on the location of the implementation in a network establishment and on the location of the implementation in a network
topology. ESP authenticates only headers and data after the IP topology. ESP authenticates only headers and data after the IP
header. header.
Internet Key Exchange (IKE): A hybrid protocol which implements Internet Key Exchange (IKE): A hybrid protocol which implements
Oakley and SKEME key exchanges inside the ISAKMP framework. While IKE Oakley [RFC2412] and SKEME [SKEME] key exchanges inside the ISAKMP
can be used with other protocols, its initial implementation is with framework. While IKE can be used with other protocols, its initial
the IPsec protocol. IKE provides authentication of the IPsec peers, implementation is with the IPsec protocol. IKE provides
negotiates IPsec security associations, and establishes IPsec keys. authentication of the IPsec peers, negotiates IPsec security
associations, and establishes IPsec keys.
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 provide transport mode and tunnel mode. In transport mode, two hosts provide
protection primarily for upper-layer protocols. The cryptographic protection primarily for upper-layer protocols. The cryptographic
endpoints (where the encryption and decryption take place) are the endpoints (where the encryption and decryption take place) are the
source and destination of the data packet. In IPv4, a transport mode source and destination of the data packet. In IPv4, a transport mode
security protocol header appears immediately after the IP header and security protocol header appears immediately after the IP header and
before any higher-layer protocols (such as TCP or UDP). before any higher-layer protocols (such as TCP or 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 that typically are modified in transit. The fields of the IPv4 header
are not included are, therefore, set to 0 before applying the that 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:
* TOS * TOS
* TTL * TTL
* Header Checksum * Header Checksum
* Offset * Offset
* Flags * 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 tunnel only for the higher-layer protocols, not for the IP header.
is a vehicle for encapsulating packets inside a protocol that is
understood at the entry and exit points of a given network. These
entry and exit points are defined as tunnel interfaces.
Tunnel mode can be supported by data packet endpoints as well as by A tunnel is a vehicle for encapsulating packets inside a protocol
intermediate security gateways. In tunnel mode, there is an "outer" that is understood at the entry and exit points of a given network.
IP header that specifies the IPsec processing destination, plus an These entry and exit points are defined as tunnel interfaces.
"inner" IP header that specifies the ultimate destination for the
packet. The source address in the outer IP header is the initiating Both the AH and ESP protocols can be used in tunnel mode for data
cryptographic endpoint; the source address in the inner header is the packet endpoints as well as by intermediate security gateways. In
true source address of the packet. The security protocol header tunnel mode, there is an "outer" IP header that specifies the IPsec
appears after the outer IP header and before the inner IP header. processing destination, plus an "inner" IP header that specifies the
ultimate destination for the packet. The source address in the outer
IP header is the initiating cryptographic endpoint; the source
address in the inner header is the true source address of the packet.
The security protocol header appears after the outer IP header and
before the inner IP header.
If AH is employed in tunnel mode, portions of the outer IP header are If AH is employed in tunnel mode, portions of the outer IP header are
given protection (those same fields as for transport mode, described given protection (those same fields as for transport mode, described
earlier in this section), as well as all of the tunneled IP packet earlier in this section), as well as all of the tunneled IP packet
(that is, all of the inner IP header is protected as are the (that is, all of the inner IP header is protected as are the
higher-layer protocols). If ESP is employed, the protection is higher-layer protocols). If ESP is employed, the protection is
afforded only to the tunneled packet, not to the outer header. afforded only to the tunneled packet, not to the outer header.
2.1 IPsec Operation 2.1 IPsec Operation
2.1.1 Security Associations 2.1.1 Security Associations
The concept of a Security Association (SA) is fundamental to IPsec. The concept of a Security Association (SA) is fundamental to IPsec.
An SA is a relationship between two or more entities that describes An SA is a relationship between two or more entities that describes
how the entities will use security services to communicate securely. how the entities will use security services to communicate. The SA
The SA includes: an encryption algorithm, an authentication algorithm includes: an encryption algorithm, an authentication algorithm and a
and a shared session key. shared session key.
Because an SA is unidirectional, two SAs (one in each direction) are Because an SA is unidirectional, two SAs (one in each direction) are
required to secure typical, bidirectional communication between two required to secure typical, bidirectional communication between two
entities. The security services associated with an SA can be used for entities. The security services associated with an SA can be used
AH or ESP, but not for both. If both AH and ESP protection is applied for AH or ESP, but not for both. If both AH and ESP protection is
to a traffic stream, two (or more) SAs are created for each direction applied to a traffic stream, two (or more) SAs are created for each
to protect the traffic stream. direction to protect the traffic stream.
The SA is uniquely identified by the security parameter index (SPI) The SA is uniquely identified by the security parameter index (SPI)
[RFC2406]. When a system sends a packet that requires IPsec [RFC2406]. When a system sends a packet that requires IPsec
protection, it looks up the SA in its database and applies the protection, it looks up the SA in its database and applies the
specified processing and security protocol (AH/ESP), inserting the specified processing and security protocol (AH/ESP), inserting the
SPI from the SA into the IPsec header. When the IPsec peer receives SPI from the SA into the IPsec header. When the IPsec peer receives
the packet, it looks up the SA in its database by destination the packet, it looks up the SA in its database by destination
address, protocol, and SPI and then processes the packet as required. address, protocol, and SPI and then processes the packet as required.
2.1.2 Key Management 2.1.2 Key Management
IPsec uses cryptographic keys for authentication/integrity and IPsec uses cryptographic keys for authentication, integrity and
encryption services. Both manual and automatic distribution of keys encryption services. Both manual provisioning and automatic
is supported. IKE is specified as the public-key-based approach for distribution of keys is supported. IKE is specified as the
automatic key management. public-key-based approach for automatic key management.
IKE authenticates each peer involved in IPsec, negotiates the IKE authenticates each peer involved in IPsec, negotiates the
security policy, and handles the exchange of session keys. IKE is a security policy, and handles the exchange of session keys. IKE is a
hybrid protocol, combining parts of the following protocols to hybrid protocol, combining parts of the following protocols to
negotiate and derive keying material for SAs in a secure and negotiate and derive keying material for SAs in a secure and
authenticated manner: authenticated manner:
1. ISAKMP (Internet Security Association and Key Management 1. ISAKMP [RFC2408] (Internet Security Association and Key
Protocol), which provides a framework for authentication and key Management Protocol), which provides a framework for
exchange but does not define them. ISAKMP is designed to be key authentication and key exchange but does not define them. ISAKMP
exchange independent; it is designed to support many different is designed to be key exchange independent; it is designed to
key exchanges. support many different key exchanges.
2. Oakley [RFC2412], 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).
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). [RFC2412]
3. [SKEME] (Secure Key Exchange Mechanism for Internet), which 3. [SKEME] (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that provides describes a versatile key exchange technique that provides
anonymity, reputability, and quick key refreshment. anonymity, reputability, and quick key refreshment.
IKE creates an authenticated, secure tunnel between two entities and IKE creates an authenticated, secure tunnel between two entities and
then negotiates the security association for IPsec. This is performed then negotiates the security association for IPsec. This is
in two phases. performed in two phases.
In Phase 1, the two unidirectional SA's establish a secure, In Phase 1, the two unidirectional SA's establish a secure,
authenticated channel with which to communicate. Phase 1 has two authenticated channel with which to communicate. Phase 1 has two
distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1 distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase 1
provides identity protection. When identity protection is not needed, provides identity protection. When identity protection is not
Aggressive Mode can be used. The completion of Phase 1 an IKE SA is needed, Aggressive Mode can be used. The completion of Phase 1 is
established. called an IKE SA.
The following attributes are used by IKE and are negotiated as part The following attributes are used by IKE and are negotiated as part
of the IKE SA: of the IKE SA:
o Encryption algorithm. o Encryption algorithm.
o Hash algorithm. o Hash algorithm.
o Authentication method (digital signature, public-key encryption, o Authentication method (digital signature, public-key encryption or
or pre-shared key). pre-shared key).
o Diffie-Hellman group information. 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. The following mechanisms are generally implemented:
implemented:
o Preshared keys. The same key is pre-installed on each host. IKE o Pre-shared keys: The same key is pre-installed on each host. IKE
peers authenticate each other by computing and sending a keyed peers authenticate each other by computing and sending a keyed
hash of data that includes the preshared key. If the receiving hash of data that includes the pre-shared key. If the receiving
peer can independently create the same hash using its preshared peer can independently create the same hash using its preshared
key, it knows that both parties must share the same secret, and key, it knows that both parties must share the same secret, and
thus the other party is authenticated. 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 keyed party's public key. The ability for each party to compute a keyed
hash containing the other peer's nonce and ID, decrypted with the hash containing the other peer's nonce and ID, decrypted with the
local private key, authenticates the parties to each other. This local private key, authenticates the parties to each other. This
method does not provide nonrepudiation; either side of the method does not provide nonrepudiation; either side of the
exchange could plausibly deny that it took part in the exchange. exchange could plausibly deny that it took part in the exchange.
o Digital signature. Each device digitally signs a set of data and o Digital signature: Each device digitally signs a set of data and
sends it to the other party. This method is similar to the sends it to the other party. This method is similar to 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 require Note that both digital signature and public-key cryptography require
the use of digital certificates to validate the public/private key the use of digital certificates to validate the public/private key
mapping. IKE allows the certificate to be accessed independently or mapping. IKE allows the certificate to be accessed independently or
by having the two devices explicitly exchange certificates as part of by having the two devices explicitly exchange certificates as part of
IKE. Both parties must have a shared session key to encrypt the IKE IKE. Both parties must have a shared session key to encrypt the IKE
tunnel. The Diffie-Hellman protocol is used to agree on a common tunnel. The Diffie-Hellman protocol is used to agree on a common
session key. session key.
In Phase 2 of the process, IPsec SAs are negotiated on behalf of In Phase 2 of IKE, SA's are negotiated for ESP and/or AH. These SA's
services such as IPsec AH or ESP. IPsec uses a different shared key will be called IPsec SAs. These IPsec SA's use a different shared
than does IKE. The IPsec shared key can be derived by using key than that used for the IKE_SA. The IPsec SA shared key can be
Diffie-Hellman again or by refreshing the shared secret derived from derived by using Diffie-Hellman again or by refreshing the shared key
the original Diffie-Hellman exchange that generated the IKE SA by derived from the original Diffie-Hellman exchange that generated the
hashing it with nonces. After this step is complete, the IPsec SAs IKE_SA by hashing it with nonces. Once the shared key is derived and
are established. Now the data traffic can be exchanged with the additional communication parameters are negotiated, the IPsec SA's
negotiated IPsec parameters. The completion of Phase 2 is called an are established and traffic can be exchanged using the negotiated
IPsec SA. parameters. Note that for IKEv2, the term CHILD-SA is used for what
we call an IPsec SA.
3. Document Scope 3. Document Scope
The primary focus of this document is to establish useful performance The primary focus of this document is to establish useful performance
testing terminology for IPsec devices that support IKEv1. We want to testing terminology for IPsec devices that support IKEv1. We want to
constrain the terminology specified in this document to meet the constrain the terminology specified in this document to meet the
requirements of the Methodology for Benchmarking IPSec Devices requirements of the Methodology for Benchmarking IPSec Devices
documented test methodologies. The testing will be constrained to documented test methodologies. The testing will be constrained to
devices acting as IPsec gateways and will pertain to both IPsec devices acting as IPsec gateways and will pertain to both IPsec
tunnel and transport mode. tunnel and transport mode.
Any testing involving interoperability and/or conformance issues, Any testing involving interoperability and/or conformance issues,
L2TP, GRE, RFC 2547 (MPLS VPNs), multicast, and anything that does L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and
not specifically relate to the establishment and tearing down of anything that does not specifically relate to the establishment and
IPsec tunnels is specifically out of scope. It is assumed that all tearing down of IPsec tunnels is specifically out of scope. It is
relevant networking parameters that facilitate in the running of assumed that all relevant networking parameters that facilitate in
these tests are pre-configured (this includes at a minimum ARP caches the running of these tests are pre-configured (this includes at a
and routing tables). This document will encompass updates to AH, ESP minimum ARP caches and routing tables). This document will encompass
and NAT Traversal. Since NAT traversal has been included in the updates to AH, ESP and NAT Traversal. Since NAT traversal has been
document, NAT is not included in this document. included in the document, NAT is not included in this document.
4. Definition Format 4. Definition Format
The definition format utilized by this document is described in The definition format utilized by this document is described in
[RFC1242], Section 2. [RFC1242], Section 2.
Term to be defined. Term to be defined.
Definition: Definition:
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: Issues:
List of issues or conditions that affect this term. This field can List of issues or conditions that affect this term. This field
present items the may impact the term's related methodology or can present items the may impact the term's related methodology or
otherwise restrict its measurement procedures. 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.
[See Also:] [See Also:]
skipping to change at page 9, line 46 skipping to change at page 9, line 46
defines the use of these key words to help make the intent of defines the use of these key words to help make the intent of
standards track documents as clear as possible. While this document standards track documents as clear as possible. While this document
uses these keywords, this document is not a standards track document. uses these keywords, this document is not a standards track document.
6. Existing Benchmark Definitions 6. Existing Benchmark Definitions
It is recommended that readers consult [RFC1242], [RFC2544] and It is recommended that readers consult [RFC1242], [RFC2544] and
[RFC2285] before making use of this document. These and other IETF [RFC2285] before making use of this document. These and other IETF
Benchmarking Methodology Working Group (BMWG) router and switch Benchmarking Methodology Working Group (BMWG) router and switch
documents contain several existing terms relevant to benchmarking the documents contain several existing terms relevant to benchmarking the
performance of IPsec devices. The conceptual framework established in performance of IPsec devices. The conceptual framework established
these earlier RFCs will be evident in this document. in 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]
skipping to change at page 11, line 11 skipping to change at page 11, line 11
exchanges. ISAKMP is defined in [RFC2407]. exchanges. ISAKMP is defined in [RFC2407].
Discussion: Discussion:
Though ISAKMP is only a framework for the IPsec standard key Though ISAKMP is only a framework for the IPsec standard key
management protocol, it is often misused and interchanged with the management protocol, it is often misused and interchanged with the
term 'IKE', which is an implementation of ISAKMP. term 'IKE', which is an implementation of ISAKMP.
Issues: Issues:
When implementations refer to the term 'ISAKMP SA' it refers to an When implementations refer to the term 'ISAKMP SA', it refers to
IKE Phase 1 SA. an IKE Phase 1 SA.
See Also: See Also:
IKE, Security Association IKE, Security Association
7.3 IKE 7.3 IKE
Definition: Definition:
A hybrid key management protocol that allows secure negotiation of A hybrid key management protocol that allows secure negotiation of
IPsec SA paramters. IPsec SA paramters.
Discussion: Discussion:
A hybrid protocol, defined in [RFC2409], from the following 3 A hybrid protocol, defined in [RFC2409], from the following 3
protocols: protocols:
* ISAKMP (Internet Security Association and Key Management * ISAKMP (Internet Security Association and Key Management
Protocol), which provides a framework for authentication and Protocol), which provides a framework for authentication and
key exchange but does not define them. ISAKMP is designed to be key exchange but does not define them. ISAKMP is designed to
key exchange independent; it is designed to support many be key exchange independent; it is designed to support many
different key exchanges. different key exchanges.
* Oakley, which describes a series of key exchanges, called * Oakley, which describes a series of key exchanges, called
modes, and details the services provided by each (for example, modes, and details the services provided by each (for example,
perfect forward secrecy for keys, identity protection, and perfect forward secrecy for keys, identity protection, and
authentication). [RFC2412] authentication). [RFC2412]
* [SKEME] (Secure Key Exchange Mechanism for Internet), which * [SKEME] (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that provides describes a versatile key exchange technique that provides
anonymity, reputability, and quick key refreshment. anonymity, reputability, and quick key refreshment.
Note that IKE is an optional protocol within the IPsec framework. Note that IKE is an optional protocol within the IPsec framework.
Tunnels may also be manually configured i.e. the administrator Tunnels may also be manually configured i.e. the administrator
will provide keys that will be associated with the Phase 2 SA's as will provide keys that will be associated with the Phase 2 SA's as
long as the IPsec Tunnel is configured. This method is the most long as the IPsec Tunnel is configured. This method is the most
basic mechanism to establish an IPsec tunnel between two IPsec basic mechanism to establish an IPsec tunnel between two IPsec
devices but it also decreases the level of protection since the devices but it also decreases the level of protection since the
keys are not changing as they normally would during an IKE phase 2 keys are not changing as they normally would during an IKE phase 2
rekey which is controlled by the IKE protocol. rekey.
Issues: Issues:
During the first IPsec deployment experiences, ambiguities were During the first IPsec deployment experiences, ambiguities were
found in the IKEv1 specification, which lead to interoperability found in the IKEv1 specification, which lead to interoperability
problems. To resolve these issues, IKEv1 is being updated by problems. To resolve these issues, IKEv1 is being updated by
IKEv2. IKEv2.
See Also: See Also:
ISAKMP, IPsec, Security Association ISAKMP, IPsec, Security Association
7.3.1 IKE Phase 1 7.3.1 IKEv1 Phase 1
Definition: Definition:
The shared policy and key(s) used by negotiating peers to set up a The shared policy and key(s) used by negotiating peers to set up a
secure authenticated "control channel" for further IKE secure authenticated "control channel" for further IKE
communications. communications.
Discussion: Discussion:
Note that IKE is an optional protocol within the IPsec framework Note that IKE is an optional protocol within the IPsec framework
and keys can also be manually configured. and keys can also be manually configured.
Issues: Issues:
In other documents often referenced as ISAKMP SA or IKE SA. In other documents often referenced as ISAKMP SA or IKE SA.
See Also: See Also:
IKE, ISAKMP IKE, ISAKMP
7.3.2 Phase 1 Main Mode 7.3.2 IKE Phase 1 Main Mode
Definition: Definition:
Main Mode is an instantiation of the ISAKMP Identity Protect Main Mode is an instantiation of the ISAKMP Identity Protect
Exchange, defined in [RFC2409]. Upon successful completion it Exchange, defined in [RFC2409]. Upon successful completion it
results in the establishment of an IKE Phase 1 SA. results in the establishment of an IKE Phase 1 SA.
Discussion: Discussion:
IKE Main Mode use 3 distinct message pairs, for a total of 6 IKE Main Mode use 3 distinct message pairs, for a total of 6
skipping to change at page 13, line 21 skipping to change at page 13, line 21
not their purpose. not their purpose.
Issues: Issues:
N/A N/A
See Also: See Also:
ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode
7.3.3 Phase 1 Aggressive Mode 7.3.3 IKE Phase 1 Aggressive Mode
Definition: Definition:
Aggressive Mode is an instantiation of the ISAKMP Aggressive Aggressive Mode is an instantiation of the ISAKMP Aggressive
Exchange, defined in [RFC2409]. Upon successful completion it Exchange, defined in [RFC2409]. Upon successful completion it
results in the establishment of an IKE Phase 1 SA. results in the establishment of an IKE Phase 1 SA.
Discussion: Discussion:
IKE Aggressive Mode uses 3 messages. The first two messages IKE Aggressive Mode uses 3 messages. The first two messages
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 third addition the second message authenticates the Responder. The
message authenticates the Initiator and provides proof of third message authenticates the Initiator and provides proof of
participation in the exchange. participation in the exchange.
Issues: Issues:
For IKEv1 the standard specifies that all implementations use both For IKEv1 the standard specifies that all implementations use both
main and agressive mode, however, it is common to use only main main and agressive mode, however, it is common to use only main
mode. mode.
See Also: See Also:
ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode
7.3.4 IKE Phase 2 7.3.4 IKEv2 Phase 1
Definition:
IKEv2 calls the IKEv1 Phase 1 the IKEv2 Initial Exchange.
Discussion:
IKEv2 uses 2 exchanges (i.e. four messages) to complete its
initial exchange. The first pair of messages (IKE_SA_INIT)
negotiate cryptographic algorithms, exchange nonces and do a
Diffie-Hellman exchange. The second pair of messages (IKE_AUTH)
authenticate the previous messages, exchange identities and
certificates, and establish the first CHILD_SA. Parts of the
IKE_AUTH messages are encrypted and integrity protected with keys
established through the IKE_SA_INIT exchange.
Issues:
In some scenarios, only a single CHILD_SA is needed between IPsec
endpoints and therefore there would be no additional exchanges.
However, subsequent exchanges (i.e. the CREATE_CHILD_SA exchange)
are often used for re-keying purposes.
See Also:
ISAKMP, IKE, IKEv1 Phase 1, Phase 1 Main Mode
7.3.5 IKE Phase 2
Definition: Definition:
ISAKMP phase which upon successful completion establishes the ISAKMP phase which upon successful completion establishes the
shared keys used by the negotiating peers to set up a secure "data shared keys used by the negotiating peers to set up a secure "data
channel" for IPsec. channel" for IPsec.
Discussion: Discussion:
The main purpose of Phase 2 is to produce the key for the IPsec The main purpose of Phase 2 is to produce the key for the IPsec
tunnel. Phase 2 is also used to regenerate the key being used for tunnel. Phase 2 is also used to regenerate the key being used for
IPsec (called "rekeying"), as well as for exchanging informational IPsec (called "rekeying"), as well as for exchanging informational
messages. messages.
IKEv2 calls the IKEv1 phase 2 the IKEv2 CREATE_CHILD_SA Exchange.
These messages are used to create additional CHILD_SAs between
IPsec endpoints or to re-key existing CHILD-SAs.
Issues: Issues:
In other documents also referenced as IPsec SA. In other documents also referenced as IPsec SA.
See Also: See Also:
IKE Phase 1, ISAKMP, IKE IKE Phase 1, ISAKMP, IKE
7.3.5 Phase 2 Quick Mode 7.3.6 Phase 2 Quick Mode
Definition: Definition:
Quick Mode is an instanciation of IKE Phase 2. After successful Quick Mode is an instanciation of IKE Phase 2. After successful
completion it will result in one or typically two or more IPsec completion it will result in one or typically two or more IPsec
SA's SA's
Discussion: Discussion:
Quick Mode is not a complete exchange itself (it is bound to a Quick Mode is used to negotiate the SA's and keys that will be
phase 1 exchange), but is used as part of the SA negotiation used to protect the user data, i.e. the IPsec SA. Three
process (phase 2) to derive keying material and negotiate shared different messages are exchanged, which are protected by the
policy for non-ISAKMP SA's. The ISAKMP SA protects the information security parameters negotiated by the IKE phase 1 exchange. An
exchanged along with Quick Mode, i.e. all payloads except the additional Diffie-Hellman exchange may be performed if PFS
ISAKMP header are encrypted. Also, an optional Key Exchange (Perfect Forward Secrecy) is enabled.
payload can be exchanged to allow for an additional Diffie-Hellman
exchange, PFS and exponentiation per Quick Mode. The IKEv2 CREATE_CHILD_SA exchange consists of a single request/
response pair. These messages are cryptographically protected
using the cryptographic algorithms and keys negotiated in the
IKE_SA_INIT messages.
Issues: Issues:
N/A N/A
See Also: See Also:
ISAKMP, IKE, IKE Phase 2 ISAKMP, IKE, IKE Phase 2
7.4 Security Association (SA) 7.4 Security Association (SA)
Definition: Definition:
A simplex (unidirectional) logical connection that links a traffic A simplex (unidirectional) logical connection that links a traffic
flow to a set of security parameters. All traffic traversing an SA flow to a set of security parameters. All traffic traversing an
is provided the same security processing and will be subjected to SA is provided the same security processing and will be subjected
a common set of encryption and/or authentication algorithms. In to a common set of encryption and/or authentication algorithms.
IPsec, an SA is an Internet layer abstraction implemented through
the use of AH or ESP as defined in [RFC2401]. In IPsec, an SA is an Internet layer abstraction implemented
through the use of AH or ESP as defined in [RFC2401].
Discussion: Discussion:
A set of policy and key(s) used to protect information. It is a A set of policy and key(s) used to protect information. It is a
negotiation agreement between two IPsec devices, specifically the negotiation agreement between two IPsec devices, specifically the
Initiator and Responder. Initiator and Responder.
Issues: Issues:
N/A N/A
skipping to change at page 16, line 32 skipping to change at page 17, line 21
Discussion: Discussion:
Implementations can be grouped by 'external' properties (e.g. Implementations can be grouped by 'external' properties (e.g.
software vs. hardware implementations) but more important is the software vs. hardware implementations) but more important is the
subtle differences that implementations may have with relation to subtle differences that implementations may have with relation to
the IPsec Protocol Suite. Not all implementations will cover all the IPsec Protocol Suite. Not all implementations will cover all
RFC's that encompass the IPsec Protocol Suite, but the majority RFC's that encompass the IPsec Protocol Suite, but the majority
will support a large subset of features described in the suite, will support a large subset of features described in the suite,
nor will all implementations utilize all of the cryptographic nor will all implementations utilize all of the cryptographic
functions listed in the RFCs. functions listed in the RFC's.
In that context, any implementation, that supports basic IP layer In that context, any implementation, that supports basic IP layer
security services as described in the IPsec protocol suite shall security services as described in the IPsec protocol suite shall
be called an IPsec Device. be called an IPsec Device.
Issues: Issues:
Due to the fragmented nature of the IPsec Protocol Suite RFC's, it Due to the fragmented nature of the IPsec Protocol Suite RFC's, it
is possible that IPsec implementations will not be able to is possible that IPsec implementations will not be able to
interoperate. Therefore it is important to know which features and interoperate. Therefore it is important to know which features
options are implemented in the IPsec Device. and options are implemented in the IPsec Device.
See Also: See Also:
IPsec IPsec
7.6.1 Initiator 7.6.1 Initiator
Definition: Definition:
An IPsec devices which starts the negotiation of IKE Phase 1 and An IPsec devices which starts the negotiation of IKE Phase 1 and
Phase 2 tunnels. Phase 2 tunnels.
Discussion: Discussion:
When a traffic flow is offered at an IPSec device and it is When a traffic flow is offered at an IPsec device and it is
determined that the flow must be protected, but there is no IPsec determined that the flow must be protected, but there is no IPsec
tunnel to send the traffic through, it is the responsibility of tunnel to send the traffic through, it is the responsibility of
the IPsec device to start a negotiation process that will the IPsec device to start a negotiation process that will
instantiate the IPsec tunnel. This process will establish an IKE instantiate the IPsec tunnel. This process will establish an IKE
Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's, Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's,
eventually resulting in secured data transport. The device that eventually resulting in secured data transport. The device that
takes the action to start this negotiation process will be called takes the action to start this negotiation process will be called
an Initiator. an Initiator.
Issues: Issues:
IPsec devices/implementations can always be both an initiator as IPsec devices/implementations can be both an initiator as well as
well as a responder. The distinction is useful from a test a responder. The distinction is useful from a test perspective.
perspective.
See Also: See Also:
Responder, IKE, IPsec Responder, IKE, IPsec
7.6.2 Responder 7.6.2 Responder
Definition: Definition:
An IPsec devices which replies to incoming IKE Phase 1 and Phase 2 An IPsec devices which replies to incoming IKE Phase 1 and Phase 2
tunnel requests and process these messages in order to establish a tunnel requests and process these messages in order to establish a
tunnel. tunnel.
Discussion: Discussion:
When an initiator attempts to establish SAs with another IPsec When an initiator attempts to establish SA's with another IPsec
device, this peer will need to evaluate the proposals made by the device, this peer will need to evaluate the proposals made by the
initiator and either accept or deny them. In the former case, the initiator and either accept or deny them. In the former case, the
traffic flow will be decrypted according to the negotiated traffic flow will be decrypted according to the negotiated
parameters. Such a device will be called a Responder. parameters. Such a device will be called a Responder.
Issues: Issues:
IPsec devices/implementations can usually be both an initiator as IPsec devices/implementations can usually be both an initiator as
well as a responder. The distinction is useful from a test well as a responder. The distinction is useful from a test
perspective. perspective.
skipping to change at page 18, line 28 skipping to change at page 19, line 14
IPsec Devices that will only act as an Initiator. IPsec Devices that will only act as an Initiator.
Discussion: Discussion:
In some situations it is not needed or prefered to have an IPsec In some situations it is not needed or prefered to have an IPsec
device respond to an inbound tunnel request. In the case of e.g. device respond to an inbound tunnel request. In the case of e.g.
road warriors or home office scenarios the only property needed road warriors or home office scenarios the only property needed
from the IPsec device is the ability to securely connect to a from the IPsec device is the ability to securely connect to a
remote private network. The IPsec Client will set up one or more remote private network. The IPsec Client will set up one or more
Tunnels to an IPSec Server on the network that needs to be Tunnels to an IPsec Server on the network that needs to be
accessed and to provide the required security services. An IPsec accessed and to provide the required security services. An IPsec
client will silently drop and ignore any inbound tunnel requests. client will silently drop and ignore any inbound tunnel requests.
IPsec clients are generally used to connect remote users in a IPsec clients are generally used to connect remote users in a
secure fashion over the Internet to a private network. secure fashion over the Internet to a private network.
Issues: Issues:
N/A N/A
See Also: See Also:
skipping to change at page 19, line 12 skipping to change at page 19, line 42
IPSec Devices that can both act as an Initiator as well as a IPSec Devices that can both act as an Initiator as well as a
Responder. Responder.
Discussion: Discussion:
IPSec Servers are mostly positioned at private network edges and IPSec Servers are mostly positioned at private network edges and
provide several functions : provide several functions :
Responds to tunnel setup request from IPSec Clients. Responds to tunnel setup request from IPSec Clients.
Responds to tunnel setup request from other IPSec devices/ Responds to tunnel setup request from other IPsec devices
Initiators. (Initiators).
Initiate tunnels to other IPSec servers inside or outside the Initiate tunnels to other IPsec servers inside or outside the
private network. private network.
Issues: Issues:
IPsec Servers are also sometimes referred to as 'VPN IPsec Servers are also sometimes referred to as 'VPN
Concentrators'. Concentrators'.
See Also: See Also:
IPsec Device, IPsec Client, Initiator, Responder IPsec Device, IPsec Client, Initiator, Responder
skipping to change at page 19, line 37 skipping to change at page 20, line 22
7.7 Tunnels 7.7 Tunnels
The term "tunnel" is often used in a variety of contexts. To avoid The term "tunnel" is often used in a variety of contexts. To avoid
any discrepancies, in this document, the following distinctions have any discrepancies, in this document, the following distinctions have
been defined : been defined :
7.7.1 IKE Tunnel 7.7.1 IKE Tunnel
Definition: Definition:
One simplex Phase 1 IKE SA A single Phase 1 IKE SA.
Discussion: Discussion:
An IKE Tunnel between IPSec devices facilitates a mechanism for An IKE Tunnel between IPsec devices facilitates a mechanism for
secure negotiation of Phase 1 properties and Phase 2 SA's needed secure negotiation of Phase 1 properties and Phase 2 SA's needed
for protected data transport. The initiator may choose which mode for protected data transport. The initiator may choose which mode
to start the negotiation of the IKE Tunnel in. This can be either to start the negotiation of the IKE Tunnel in. This can be either
main mode or aggressive mode. main mode or aggressive mode.
Issues: Issues:
Also referred to as an ISAKMP SA or IKE SA or Phase 1 Tunnel. Also referred to as an ISAKMP SA or IKE SA or Phase 1 Tunnel.
See Also: See Also:
skipping to change at page 20, line 21 skipping to change at page 21, line 8
Definition: Definition:
One or more Phase 2 SA's that are negotiated in conjuntion with an One or more Phase 2 SA's that are negotiated in conjuntion with an
IKE Tunnel. IKE Tunnel.
Discussion: Discussion:
In the case of simplex communication, a single phase 2 SA. In the case of simplex communication, a single phase 2 SA.
In the more likely case where bidirectional communication is In the more likely case where bidirectional communication is
needed it is a pair (2) of Phase 2 SA's. The two SA's are used to needed it is a pair (2) Phase 2 SA's. The two SA's are used to
secure inbound and outbound traffic. secure inbound and outbound traffic.
Not in all situations is it required to have an existing IKE Not in all situations is it required to have an existing IKE
Tunnel in order to negotiate IPsec Tunnel properties and Tunnel in order to negotiate IPsec Tunnel properties and
parameters. Manually keyed tunnels allow the set up of IPsec parameters. Manually keyed tunnels allow the set up of IPsec
Tunnels without the need of the IKE protocol. Tunnels without the need of the IKE protocol.
Issues: Issues:
Also referred to as a Phase 2 Tunnel or a Phase 2 SA (may be Also referred to as a Phase 2 Tunnel or a Phase 2 SA (may be
skipping to change at page 21, line 7 skipping to change at page 21, line 40
Discussion: Discussion:
In the majority of the cases IPsec is used to protect In the majority of the cases IPsec is used to protect
bidirectional traffic flows. Unless stated otherwise a 'Tunnel' bidirectional traffic flows. Unless stated otherwise a 'Tunnel'
will be defined as a single Phase 1 SA and two Phase 2 SA's that will be defined as a single Phase 1 SA and two Phase 2 SA's that
are associated with the Phase 1 SA. are associated with the Phase 1 SA.
Issues: Issues:
If only a single Phase 2 SA or more then two Phase 2 SA's have If other than a single Phase 2 SA, for each direction, have been
been negotiated through a single IKE Tunnel, then this specific negotiated through a single IKE Tunnel, then this specific ratio
ratio must be mentioned and the term 'Tunnel' MUST NOT be used in MUST be mentioned and the term 'Tunnel' MUST NOT be used in this
this context. context."
See Also: See Also:
IKE Tunnel, IPsec Tunnel IKE Tunnel, IPsec Tunnel
7.7.4 Configured Tunnel 7.7.4 Configured Tunnel
Definition: Definition:
A tunnel that is present in the IPSec device's configuration but A tunnel that is present in the IPSec device's configuration but
does not have any entries in the SAD i.e. SA's. does not have any entries in the SADBi.e. SA's.
Discussion: Discussion:
Several steps are required before a Tunnel can be used to actually Several steps are required before a Tunnel can be used to actually
transport traffic. The very first step is to configure the tunnel transport traffic. The very first step is to configure the tunnel
in the IPsec device. In that way packet classification can make a in the IPsec device. In that way packet classification can make a
decision if it is required to start negotiating SA's. At this time decision if it is required to start negotiating SA's. At this
there are no SA's associated with the Tunnel and no traffic is time there are no SA's associated with the Tunnel and no traffic
going through the IPsec device that matches the Selectors, which is going through the IPsec device that matches the Selectors,
would instantiate the Tunnel. which would instantiate the Tunnel.
A Configured Tunnel is also a tunnel that has relinquished all A Configured Tunnel is also a tunnel that has relinquished all
it's SA's and is not transmitting data anymore. To be more it's SA's and is not transmitting data anymore. To be more
specific, when an Established or an Active Tunnel is terminated specific, when an Established or an Active Tunnel is terminated
due to either an administrative action or an IKE event that teared due to either an administrative action or an IKE event that teared
down the tunnel, the tunnel will be back in a solely configured down the tunnel, the tunnel will be back in a configured state.
state.
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel, Established Tunnel, Active Tunnel Tunnel, Established Tunnel, Active Tunnel
7.7.5 Established Tunnel 7.7.5 Established Tunnel
skipping to change at page 22, line 4 skipping to change at page 22, line 37
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel, Established Tunnel, Active Tunnel Tunnel, Established Tunnel, Active Tunnel
7.7.5 Established Tunnel 7.7.5 Established Tunnel
Definition: Definition:
A Tunnel that has completed Phase 1 and Phase 2 SA negotiations A Tunnel that has completed Phase 1 and Phase 2 SA negotiations
but is otherwise idle. but is otherwise idle.
Discussion: Discussion:
A second step needed to ensure that a Tunnel can transport data is A second step needed to ensure that a Tunnel can transport data is
to complete the Phase 1 and Phase 2 negotiations. After the packet to complete the Phase 1 and Phase 2 negotiations. After the
classification process has asserted that a packet requires packet classification process has asserted that a packet requires
security services, the negotation is started to obtain both Phase security services, the negotation is started to obtain both Phase
1 and Phase 2 SA's. After this is completed the tunnel is called 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 'Established'. Note that at this time there is still no traffic
flowing through the Tunnel. Just enough packet(s) have been sent flowing through the Tunnel. Just enough packet(s) have been sent
to the IPsec device that matched the selectors and triggered the to the IPsec device that matched the selectors and triggered the
Tunnel setup. This may also be acomplished by an administrative Tunnel setup. This may also be acomplished by an administrative
command to connect the Tunnel, in which case the Tunnel is not command to connect the Tunnel, in which case the Tunnel is not
triggered by any positive packet classification. triggered by any positive packet classification.
Issues: Issues:
skipping to change at page 22, line 40 skipping to change at page 23, line 26
See Also: See Also:
Tunnel, Configured Tunnel, Active Tunnel Tunnel, Configured Tunnel, Active Tunnel
7.7.6 Active Tunnel 7.7.6 Active Tunnel
Definition: Definition:
A tunnel that has completed Phase 1 and Phase 2 SA negotiations A tunnel that has completed Phase 1 and Phase 2 SA negotiations
and is transmitting data. and is forwarding data.
Discussion: Discussion:
When a Tunnel is Established and it is transporting traffic, the When a Tunnel is Established and it is transporting traffic, the
tunnel is called 'Active'. tunnel is called 'Active'.
Issues: Issues:
The distinction between an Active Tunnel and Configured/ The distinction between an Active Tunnel and Configured/
Established Tunnel is made in the context of manual keyed Tunnels. Established Tunnel is made in the context of manual keyed Tunnels.
skipping to change at page 24, line 30 skipping to change at page 25, line 19
An SA bundle consisting of two or more transport mode SA's. An SA bundle consisting of two or more transport mode SA's.
Discussion: Discussion:
Transport adjacency is a form of tunnel nesting. In this case two Transport adjacency is a form of tunnel nesting. In this case two
or more transport mode IPsec tunnels are set side by side to or more transport mode IPsec tunnels are set side by side to
enhance applied security properties. enhance applied security properties.
Transport adjacency can be used with a mix of AH and ESP tunnels Transport adjacency can be used with a mix of AH and ESP tunnels
although some combinations are not preferred. If AH and ESP are although some combinations are not preferred. If AH and ESP are
mixed, the ESP tunnel should always encapsulate the AH tunnel. The mixed, the ESP tunnel should always encapsulate the AH tunnel.
reverse combination is a valid combination but doesn't make The reverse combination is a valid combination but doesn't make
cryptographical sense. cryptographical sense.
[GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4] [GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
| | | | | | | |
| | | | | | | |
| +------{SA1 (ESP transport)}--------+ | | +------{SA1 (ESP transport)}--------+ |
| | | |
+-------------{SA2 (AH transport)}--------------+ +-------------{SA2 (AH transport)}--------------+
In the IP Cloud a packet would have a format like this : In the IP Cloud a packet would have a format like this :
skipping to change at page 25, line 18 skipping to change at page 26, line 7
7.9 Transform protocols 7.9 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:
Some algorithms run significantly slower than others. For example, Some algorithms run significantly slower than others. For
TripleDES encryption is one third as fast as DES encryption. example, TripleDES encryption is one third as fast as DES
encryption.
Issues: Issues:
N/A N/A
See Also: See Also:
Authentication protocols, Encryption protocols Authentication protocols, Encryption protocols
7.9.1 Authentication Protocols 7.9.1 Authentication Protocols
Definition: Definition:
Algorithms which provide data integrity and data source Algorithms which provide data integrity and data source
authentication. authentication.
Discussion: Discussion:
Authentication protocols provide no confidentiality. Commonly used Authentication protocols provide no confidentiality. Commonly
authentication algorithms/protocols are: used authentication algorithms/protocols are:
* MD5-HMAC * MD5-HMAC
* SHA-HMAC * SHA-HMAC
* AES-HMAC * AES-HMAC
Issues: Issues:
SHA-HMAC is thought to be more secure than MD5-HMAC and is often 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. used. AES-HMAC is still fairly new and not in common use yet.
skipping to change at page 26, line 46 skipping to change at page 27, line 36
Transform protocols, Authentication protocols Transform protocols, Authentication protocols
7.10 IPSec Protocols 7.10 IPSec Protocols
Definition: Definition:
A suite of protocols which provide a framework of open standards A suite of protocols which provide a framework of open standards
that provides data confidentiality, data integrity, and data that provides data confidentiality, data integrity, and data
authenticity between participating peers at the IP layer. The authenticity between participating peers at the IP layer. The
IPsec protocol suite set of standards is documented in RFC's 2401 IPsec protocol suite set of standards is documented in [RFC2401]
through 2412 and RFC 2451. through [RFC2412] and [RFC2451].
Discussion: Discussion:
The IPsec Protocol suite is modular and forward compatible. The The IPsec Protocol suite is modular and forward compatible. The
protocols that comprise the IPsec protocol suite can be replaced protocols that comprise the IPsec protocol suite can be replaced
with new versions of those protocols as the older versions become with new versions of those protocols as the older versions become
obsolete. For example, IKEv2 will soon replace IKEv1. obsolete. For example, IKEv2 will soon replace IKEv1.
Issues: Issues:
skipping to change at page 27, line 33 skipping to change at page 28, line 21
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 The AH protocol supports both modes of operation; tunnel mode and
transport mode. If AH is employed in tunnel mode, portions of the transport mode. If AH is employed in tunnel mode, portions of the
outer IP header are given protection, as well as all 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 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 protected as are the higher-layer protocols). In the case of AH
transport mode, all upper-layer information is protected, and all in transport mode, all upper-layer information is protected, and
fields in the IPv4 header excluding the fields typically are all fields in the IPv4 header excluding the fields typically are
modified in transit. modified in transit.
Original IPv4 packet : Original IPv4 packet :
[IP ORIG][L4 HDR][PAYLOAD] [IP ORIG][L4 HDR][PAYLOAD]
In transport mode : In transport mode :
[IP ORIG][AH][L4 HDR][PAYLOAD] [IP ORIG][AH][L4 HDR][PAYLOAD]
In tunnel mode : In tunnel mode :
[IP NEW][AH][IP ORIG][L4 HDR][PAYLOAD] [IP NEW][AH][IP ORIG][L4 HDR][PAYLOAD]
Issues: Issues:
skipping to change at page 28, line 18 skipping to change at page 29, line 7
7.10.2 Encapsulated Security Payload (ESP) 7.10.2 Encapsulated Security Payload (ESP)
Definition: Definition:
Provides three essential components needed for secure data Provides three essential components needed for secure data
exchange: authentication, integrity (including replay protection) exchange: authentication, integrity (including replay protection)
and confidentiality as defined in [RFC2406]. and confidentiality as defined in [RFC2406].
Discussion: Discussion:
The ESP protocol supports both modes of operation i.e. tunnel mode The ESP protocol supports both modes of operation i.e. tunnel
and transport mode. If ESP is employed in tunnel mode, the mode and transport mode. If ESP is employed in tunnel mode, the
protection is afforded only to the tunneled packet, not to the protection is afforded only to the tunneled packet, not to the
outer header. In the case of ESP in transport mode, security outer header. In the case of ESP in transport mode, security
services are provided only for the higher-layer protocols, not for services are provided only for the higher-layer protocols, not for
the IP header. 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 :
skipping to change at page 31, line 27 skipping to change at page 32, line 12
* Key exchange mechanism (pre-shared key, certificate authority, * Key exchange mechanism (pre-shared key, certificate authority,
etc ...) etc ...)
* Key size (if applicable) * Key size (if applicable)
* Diffie-Hellman group * Diffie-Hellman group
* IKE SA lifetime (time based) * IKE SA lifetime (time based)
* Keepalive, heartbeat or DPD values [DPD] * Keepalive or DPD values as defined in [I-D.ietf-ipsec-dpd]
* IP Compression [RFC2393] * IP Compression [RFC2393]
* PFS Diffie-Hellman group * PFS Diffie-Hellman group
The IKE context MAY also list: The IKE context MAY also list:
* Phase 1 mode (main or aggressive) * Phase 1 mode (main or aggressive)
* Available bandwidth and latency to Certificate Authority server * Available bandwidth and latency to Certificate Authority server
skipping to change at page 32, line 15 skipping to change at page 32, line 45
8. Framesizes 8. Framesizes
8.1 Layer3 clear framesize 8.1 Layer3 clear framesize
Definition: Definition:
The total size of the unencrypted L3 PDU. The total size of the unencrypted L3 PDU.
Discussion: Discussion:
In relation to IPsec this is the size of the IP header and its In relation to IPsec this is the size of the IP header and its
payload. It SHALL NOT include any encapsulations that MAY be payload. It SHALL NOT include any encapsulations that MAY be
applied before the PDU is processed for encryption. applied before the PDU is processed for encryption.
For example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload. For example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload.
Measurement Units: Measurement Units:
Bytes Bytes
Issues: Issues:
skipping to change at page 36, line 48 skipping to change at page 37, line 29
10.1.1 Tunnel Throughput 10.1.1 Tunnel Throughput
Definition: Definition:
The maximum rate through an IPsec tunnel at which none of the The maximum rate through an IPsec tunnel at which none of the
offered frames are dropped by the device under test. offered frames are dropped by the device under test.
Discussion: Discussion:
The IPsec Tunnel Throughput is almost identically defined as The IPsec Tunnel Throughput is almost identically defined as
Throughput in [RFC1242], section 3.17. The only difference is that Throughput in [RFC1242], section 3.17. The only difference is
the throughput is measured with a traffic flow getting encrypted that the throughput is measured with a traffic flow getting
and decrypted by an IPsec device. IPsec Tunnel Throughput is an encrypted and decrypted by an IPsec device. IPsec Tunnel
end-to-end measurement. Throughput is an end-to-end measurement.
The metric can be represented in two variantions depending on The metric can be represented in two variantions depending on
where measurement is taken in the SUT. One can look at throughput where measurement is taken in the SUT. One can look at throughput
from a cleartext point of view i.e. find the maximum rate where from a cleartext point of view i.e. find the maximum rate where
clearpackets no longer get dropped. This resulting rate can be clearpackets no longer get dropped. This resulting rate can be
recalculated with an encrypted framesize to represent the recalculated with an encrypted framesize to represent the
encryption throughput rate. The latter is the preferred method of encryption throughput rate. The latter is the preferred method of
representation. representation.
Measurement Units: Measurement Units:
skipping to change at page 39, line 15 skipping to change at page 39, line 43
Time required to propagate a cleartext frame from the input Time required to propagate a cleartext frame from the input
interface of an initiator, through an IPsec Tunnel, to the output interface of an initiator, through an IPsec Tunnel, to the output
interface of the responder. interface of the responder.
Discussion: Discussion:
The Tunnel Latency is the time interval starting when the end of The Tunnel Latency is the time interval starting when the end of
the first bit of the cleartext frame reaches the input interface the first bit of the cleartext frame reaches the input interface
of the initiator and ending when the start of the first bit of the of the initiator and ending when the start of the first bit of the
same cleartext frame is detected on the output interface of the same cleartext frame is detected on the output interface of the
responder. The frame has passed through an IPsec Tunnel between an responder. The frame has passed through an IPsec Tunnel between
initiator and a responder and has been through an encryption and an initiator and a responder and has been through an encryption
decryption cycle. and decryption cycle.
Measurement Units: Measurement Units:
Time units with enough precision to reflect latency measurement. Time units with enough precision to reflect latency measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
skipping to change at page 39, line 47 skipping to change at page 40, line 29
input interface, through an IPsec tunnel, and ending when the input interface, through an IPsec tunnel, and ending when the
start of the first bit of the encrypted output frame is seen on start of the first bit of the encrypted output frame is seen on
the output interface. the output interface.
Discussion: Discussion:
IPsec Tunnel Encryption latency is the latency introduced when IPsec Tunnel Encryption latency is the latency introduced when
encrypting traffic through an IPsec tunnel. encrypting traffic through an IPsec tunnel.
Like encryption/decryption throughput, it is not always the case Like encryption/decryption throughput, it is not always the case
that encryption latency equals the decryption latency. Therefore a that encryption latency equals the decryption latency. Therefore
distinction between the two has to be made in order to get a more a distinction between the two has to be made in order to get a
accurate view of where the latency is the most pronounced. more accurate view of where the latency is the most pronounced.
The independent encryption/decryption latencies have to be The independent encryption/decryption latencies have to be
measured with the help of an IPsec aware test device that can measured with the help of an IPsec aware test device that can
originate and terminate IPsec and IKE tunnels. As defined in originate and terminate IPsec and IKE tunnels. As defined in
[RFC1242], measurements should be taken with an assortment of [RFC1242], measurements should be taken with an assortment of
frame sizes. frame sizes.
Measurement Units: Measurement Units:
Time units with enough precision to reflect latency measurement. Time units with enough precision to reflect latency measurement.
skipping to change at page 41, line 46 skipping to change at page 42, line 27
example, ARP and/or IKE. example, ARP and/or IKE.
Measurement Units: Measurement Units:
Time units with enough precision to reflect a TTFP measurement. Time units with enough precision to reflect a TTFP measurement.
Issues: Issues:
N/A N/A
10.3 Frame Loss Rate 10.3 Frame Loss
10.3.1 IPSec Tunnel Frame Loss
10.3.1 IPSec Tunnel Frame Loss Rate
Definition: Definition:
Percentage of cleartext frames that should have been forwarded Percentage of cleartext frames that should have been forwarded
through a Tunnel under steady state (constant) load but were through a Tunnel under steady state (constant) load but were
dropped before encryption or after decryption. dropped before encryption or after decryption.
Discussion: Discussion:
The IPsec Tunnel Frame Loss Rate is almost identically defined as The IPsec Tunnel Frame Loss is almost identically defined as Frame
Frame Loss Rate in [RFC1242], section 3.6. The only difference is Loss Rate in [RFC1242], section 3.6. The only difference is that
that the IPsec Tunnel Frame Loss Rate is measured with a traffic the IPsec Tunnel Frame Loss Rate is measured with a traffic flow
flow getting encrypted and decrypted by an IPsec device. IPsec getting encrypted and decrypted by an IPsec device. IPsec Tunnel
Tunnel Frame Loss Rate is an end-to-end measurement. Frame Loss Rate is an end-to-end measurement.
Measurement Units: Measurement Units:
Percent (%) Percent (%)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Encryption Frame Loss Rate, IPsec Tunnel Decryption IPsec Tunnel Encryption Frame Loss, IPsec Tunnel Decryption Frame
Frame Loss Rate Loss
10.3.2 IPsec Tunnel Encryption Frame Loss Rate 10.3.2 IPsec Tunnel Encryption Frame Loss
Definition: Definition:
Percentage of cleartext frames that should have been encrypted Percentage of cleartext frames that should have been encrypted
through an IPsec tunnel under steady state (constant) load but through an IPsec tunnel under steady state (constant) load but
were dropped. were dropped.
Discussion: Discussion:
DUT's will always have an inherent forwarding limitation. This DUT's will always have an inherent forwarding limitation. This
will be more pronounced when IPsec is employed on the DUT. The will be more pronounced when IPsec is employed on the DUT. The
moment that a Tunnel is established and traffic is offered at a moment that a Tunnel is established and traffic is offered at a
given rate that will flow through that tunnel, there is a given rate that will flow through that tunnel, there is a
possibility that the offered traffic rate at the tunnel is too possibility that the offered traffic rate at the tunnel is too
high to be transported through the IPsec tunnel and not all high to be transported through the IPsec tunnel and not all
cleartext packets will get encrypted. In that case, some cleartext packets will get encrypted. In that case, some
percentage of the cleartext traffic will be dropped. This drop percentage of the cleartext traffic will be dropped. This drop
percentage is called the IPsec Tunnel Encryption Frame Loss Rate. percentage is called the IPsec Tunnel Encryption Frame Loss.
Measurement Units: Measurement Units:
Percent (%) Percent (%)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Frame Loss Rate, IPsec Tunnel Decryption Frame Loss IPsec Tunnel Frame Loss, IPsec Tunnel Decryption Frame Loss
Rate
10.3.3 IPsec Tunnel Decryption Frame Loss Rate 10.3.3 IPsec Tunnel Decryption Frame Loss
Definition: Definition:
Percentage of encrypted frames that should have been decrypted Percentage of encrypted frames that should have been decrypted
through an IPsec tunnel under steady state (constant) load but through an IPsec tunnel under steady state (constant) load but
were dropped. were dropped.
Discussion: Discussion:
A DUT will also have an inherent forwarding limitation when A DUT will also have an inherent forwarding limitation when
decrypting packets. When established tunnel encrypted traffic is decrypting packets. When established tunnel encrypted traffic is
offered at a costant load, there might be a possibility that the offered at a costant load, there might be a possibility that the
IPsec Device that needs to decrypt the traffic will not be able to IPsec Device that needs to decrypt the traffic will not be able to
perfom this action on all of the packets due to limitations of the perfom this action on all of the packets due to limitations of the
decryption performance. The percentage of encrypted frames that decryption performance. The percentage of encrypted frames that
would get dropped under these conditions is called the IPsec would get dropped under these conditions is called the IPsec
Tunnel Decryption Frame Loss Rate. Tunnel Decryption Frame Loss.
Measurement Units: Measurement Units:
Percent (%) Percent (%)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Frame Loss Rate, IPsec Tunnel Encryption Frame Loss IPsec Tunnel Frame Loss, IPsec Tunnel Encryption Frame Loss
Rate
10.3.4 Phase 2 Rekey Frame Loss
Definition:
Number of frames dropped as a result of an inefficient Phase 2
rekey.
Discussion:
Normal operation of an IPSec device would require that a rekey
does not create temporary Frame Loss of a traffic stream that is
protected by the Phase 2 SA's. Nevertheless there can be
situations where Frame Loss occurs during the rekey process.
This metric should be ideally zero but this may not be the case on
IPsec devices where IPsec funtionality is not a core feature.
Measurement Units:
Number of N-octet frames
Issues:
N/A
See Also:
Phase 2 Rekey Rate
10.4 Back-to-back Frames 10.4 Back-to-back Frames
10.4.1 Tunnel Back-to-back Frames 10.4.1 Tunnel Back-to-back Frames
Definition: Definition:
A burst of cleartext frames, offered at a constant load that can A burst of cleartext frames, offered at a constant load that can
be sent through an IPsec tunnel without losing a single cleartext be sent through an IPsec tunnel without losing a single cleartext
frame after decryption. frame after decryption.
skipping to change at page 46, line 22 skipping to change at page 47, line 31
Definition: Definition:
The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per second The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per second
that an IPsec device can successfully establish. that an IPsec device can successfully establish.
Discussion: Discussion:
The tunnel setup rate SHOULD be measured at varying number of The tunnel setup rate SHOULD be measured at varying number of
tunnels on the DUT. Several factors may influence Tunnel Setup tunnels on the DUT. Several factors may influence Tunnel Setup
Rate, such as: TAPS rate, Background Load on crypto link (clear Rate, such as: TAPS rate, Background cleartext traffic load on the
traffic), Already established tunnels, Authentication method: secure interface, Already established tunnels, Authentication
pre-shared keys, RSA-encryption, RSA-signature, DSS Key sizes used method such as pre-shared keys, RSA-encryption, RSA-signature, DSS
(when using RSA/DSS) Key sizes used (when using RSA/DSS).
Measurement Units: Measurement Units:
Tunnels Per Second (TPS) Tunnels Per Second (TPS)
Issues: Issues:
N/A N/A
See Also: See Also:
IKE Setup Rate, IPsec Setup Rate Phase 1 Setup Rate, Phase 2 Setup Rate, Tunnel Rekey
10.5.2 Phase 1 Setup Rate 10.5.2 Phase 1 Setup Rate
Definition: Definition:
The maximum number of IKE tunnels per second that an IPsec device The maximum number of IKE tunnels (1 IKE Phase 1 SA) per second
can be observed to successfully establish. that an IPsec device can be observed to successfully establish.
Discussion: Discussion:
The tunnel setup rate SHOULD be measured at varying number of The Phase 1 Setup Rate is a portion of the Tunnel Setup Rate. In
tunnels on the DUT. the process of establishing a Tunnel, it is interesting to know
what the limiting factor of the IKE Finite State Machine is i.e.
is it limited by the Phase 1 processing delays or rather by the
Phase 2 processing delays.
Measurement Units: Measurement Units:
Tunnels Per Second (TPS) Tunnels Per Second (TPS)
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel Setup Rate, IPsec Setup Rate Tunnel Setup Rate, Phase 2 Setup Rate, Tunnel Rekey
10.5.3 Phase 2 Setup Rate 10.5.3 Phase 2 Setup Rate
Definition: Definition:
The maximum number of IPsec tunnels per second that a IPsec device The maximum number of IPsec tunnels (2 IKE Phase 2 SA's) per
can be observed to successfully establish. 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 Phase 2 Setup Rate is a portion of the Tunnel Setup Rate. For
tunnels on the DUT. identical reasons why it is required to quantify the Phase 1 Setup
Rate, it is a good practice to know the processing delays involved
in setting up a Phase 2 SA for each direction of the protected
traffic flow.
Note that once you have the Tunnel Setup Rate and either the Phase
1 or the Phase 2 Setup Rate data, you can extrapolate the
unmeasured metric, although it is RECOMMENDED to measure all three
metrics.
Measurement Units: Measurement Units:
Tunnels Per Second (TPS) Tunnels Per Second (TPS)
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel Rekey Tunnel Setup Rate, Phase 1 Setup Rate, Tunnel Rekey
10.6 Tunnel Rekey 10.6 Tunnel Rekey
10.6.1 Phase 1 Rekey Rate 10.6.1 Phase 1 Rekey Rate
Definition: Definition:
The interval necessary for a particular Phase 1 to re-establish The number of Phase 1 SA's that can be succesfully re-establish
after the previous Phase 1 lifetime (hard or soft) has expired. per second.
Discussion: Discussion:
Although many implementations will usually derive new keying Although the Phase 1 Rekey Rate has less impact on the forwarding
material before the old keys expire, there may still be a period behavior of traffic that requires security services then the Phase
of time where frames get dropped before the phase 1 and subsequent 2 Rekey Rate, it can pose a large burden on the CPU or network
phase 2 tunnels are successfully (re)established. To measure the processor of the IPsec Device. Due to the highly computational
phase 1 rekey rate, the measurement will require an IPsec aware nature of a Phase 1 exchange, it may impact the stability of
test device to act as a responder when negotiating the new phase 1 Active Tunnels in the network when the IPsec Device fails to
key. properly rekey an IKE Tunnel.
Measurement Units: Measurement Units:
Time units with enough precision to reflect rekey rate Rekey's per second
measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 2 Rekey Rate Phase 2 Rekey Rate
10.6.2 Phase 2 Rekey Rate 10.6.2 Phase 2 Rekey Rate
skipping to change at page 48, line 29 skipping to change at page 50, line 4
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 2 Rekey Rate Phase 2 Rekey Rate
10.6.2 Phase 2 Rekey Rate 10.6.2 Phase 2 Rekey Rate
Definition: Definition:
The interval necessary for a particular Phase 2 to re-establish The number of Phase 2 SA's that can be succesfully re-negotiated
after the previous Phase 2 lifetime (hard or soft) has expired. per-second.
Discussion: Discussion:
Although many implementations will usually derive new keying
material before the old keys expire, there may still be a period
of time where frames get dropped before the phase 2 tunnels are
successfully re-established. There may also be some packetloss
introduced when the handover of traffic is done from the expired
SA to the newly negotiated SA. To measure the phase 2 rekey rate,
the measurement will require an IPsec aware test device to act as
a responder when negotiating the new phase 2 keying material.
The test methodology report must specify if PFS is enabled in The test methodology report must specify if PFS is enabled in
reported security context. reported security context.
Measurement Units: Measurement Units:
Time units with enough precision to reflect rekey rate Rekey's per second
measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 1 Rekey Rate Phase 1 Rekey Rate
10.7 Tunnel Failover Time (TFT) 10.7 Tunnel Failover Time (TFT)
skipping to change at page 50, line 42 skipping to change at page 52, line 24
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.
13. Contributors 13. Contributors
The authors would like to acknowledge the following individual for The authors would like to acknowledge the following individual for
their significant help, guidance, and contributions to this document: their significant help, guidance, and contributions to this document:
Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI. Paul Hoffman, VPNC, Sunil Kalidindi, Ixia, Brian Talbert, MCI.
Normative References 14. References
14.1 Normative References
[RFC1242] Bradner, S., "Benchmarking terminology for network [RFC1242] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991. interconnection devices", RFC 1242, July 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN [RFC2285] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998. Switching Devices", RFC 2285, February 1998.
skipping to change at page 52, line 8 skipping to change at page 53, line 39
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
1999. 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G.
and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC
2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina,
"Generic Routing Encapsulation (GRE)", RFC 2784, March
2000.
[I-D.ietf-ipsec-ikev2] [I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-12 (work in progress), January draft-ietf-ipsec-ikev2-14 (work in progress), June 2004.
2004.
[I-D.ietf-ipsec-dpd]
Huang, G., Beaulieu, S. and D. Rochefort, "A Traffic-Based
Method of Detecting Dead IKE Peers",
draft-ietf-ipsec-dpd-04 (work in progress), October 2003.
[I-D.ietf-ipsec-nat-t-ike] [I-D.ietf-ipsec-nat-t-ike]
Kivinen, T., "Negotiation of NAT-Traversal in the IKE", Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
draft-ietf-ipsec-nat-t-ike-07 (work in progress), draft-ietf-ipsec-nat-t-ike-08 (work in progress), February
September 2003. 2004.
[I-D.ietf-ipsec-udp-encaps] [I-D.ietf-ipsec-udp-encaps]
Huttunen, A., "UDP Encapsulation of IPsec Packets", Huttunen, A., "UDP Encapsulation of IPsec Packets",
draft-ietf-ipsec-udp-encaps-07 (work in progress), draft-ietf-ipsec-udp-encaps-09 (work in progress), May
November 2003. 2004.
[I-D.ietf-ipsec-nat-reqts] [I-D.ietf-ipsec-nat-reqts]
Aboba, B. and W. Dixon, "IPsec-NAT Compatibility Aboba, B. and W. Dixon, "IPsec-NAT Compatibility
Requirements", draft-ietf-ipsec-nat-reqts-06 (work in Requirements", draft-ietf-ipsec-nat-reqts-06 (work in
progress), October 2003. progress), October 2003.
[I-D.ietf-ipsec-properties] [I-D.ietf-ipsec-properties]
Krywaniuk, A., "Security Properties of the IPsec Protocol Krywaniuk, A., "Security Properties of the IPsec Protocol
Suite", draft-ietf-ipsec-properties-02 (work in progress), Suite", draft-ietf-ipsec-properties-02 (work in progress),
July 2002. July 2002.
[FIPS.186-1.1998] [FIPS.186-1.1998]
National Institute of Standards and Technology, "Digital National Institute of Standards and Technology, "Digital
Signature Standard", FIPS PUB 186-1, December 1998, Signature Standard", FIPS PUB 186-1, December 1998,
<http://csrc.nist.gov/fips/fips1861.pdf>. <http://csrc.nist.gov/fips/fips1861.pdf>.
Informative References 14.2 Informative References
[Designing Network Security] [Designing Network Security]
Kaeo, M., "Designing Network Security", ISBN: 1578700434, Kaeo, M., "Designing Network Security", ISBN: 1578700434,
Published: May 07, 1999; Copyright: 1999, 1999. Published: May 07, 1999; Copyright: 1999, 1999.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", from IEEE Proceedings of the Mechanism for Internet", from IEEE Proceedings of the
1996 Symposium on Network and Distributed Systems 1996 Symposium on Network and Distributed Systems
Security, URI http://www.research.ibm.com/security/ Security, URI http://www.research.ibm.com/security/
skeme.ps, 1996. skeme.ps, 1996.
[DPD] "DPD draft-ietf-ipsec-dpd-02", , URI http://www.ietf.org/
internet-drafts/draft-ietf-ipsec-dpd-02.txt.
Authors' Addresses Authors' Addresses
Michele Bustos Michele Bustos
IXIA IXIA
26601 W. Agoura Rd. 26601 W. Agoura Rd.
Calabasas, CA 91302 Calabasas, CA 91302
US US
Phone: +1 (818)444-3244 Phone: +1 (818)444-3244
EMail: mbustos@ixiacom.com EMail: mbustos@ixiacom.com
Tim Van Herck Tim Van Herck
Cisco Systems, Inc. Cisco Systems
170 West Tasman Drive 170 West Tasman Dr.
San Jose, CA 95134-1706 San Jose, CA 95134-1706
US US
Phone: +1 (408)527-2461 Phone: +1 (408)527-2461
EMail: herckt@cisco.com EMail: herckt@cisco.com
Merike Kaeo Merike Kaeo
Merike, Inc. Double Shot Security
123 Ross Street 520 Washington Blvd #363
Santa Cruz, CA 95060 Marina Del Rey, CA 90292
US US
Phone: +1 (831)818-4864 Phone: +1 (310)866-0165
EMail: kaeo@merike.com EMail: kaeo@merike.com
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to intellectual property or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; neither does it represent that it
has made any effort to identify any such rights. Information on the has made any effort to identify any such rights. Information on the
 End of changes. 121 change blocks. 
320 lines changed or deleted 419 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/