draft-ietf-bmwg-ipsec-term-05.txt   draft-ietf-bmwg-ipsec-term-06.txt 
Benchmarking Working Group M. Bustos Benchmarking Working Group M. Bustos
Internet-Draft IXIA Internet-Draft IXIA
Expires: August 22, 2005 T. Van Herck Expires: February 2, 2006 T. Van Herck
Cisco Systems Cisco Systems
M. Kaeo M. Kaeo
Double Shot Security Double Shot Security
February 18, 2005 August 2005
Terminology for Benchmarking IPsec Devices Terminology for Benchmarking IPsec Devices
draft-ietf-bmwg-ipsec-term-05 draft-ietf-bmwg-ipsec-term-06
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with By submitting this Internet-Draft, each author represents that any
all provisions of Section 10 of RFC 2026. applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as other groups may also distribute working documents as Internet-
Internet-Drafts. 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 The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 22, 2005. This Internet-Draft will expire on February 2, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). All Rights Reserved. Copyright (C) The Internet Society (2005). All Rights Reserved.
By submitting this Internet-Draft, I certify that any applicable
patent or other IPR claims of which I am aware have been disclosed,
and any of which I become aware will be disclosed, in accordance with
RFC 3668.
Abstract Abstract
This purpose of this document is to define terminology specific to This purpose of this document is to define terminology specific to
measuring the performance of IPsec devices. It builds upon the measuring the performance of IPsec devices. It builds upon the
tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF
Benchmarking Methodology Working Group (BMWG) documents used for Benchmarking Methodology Working Group (BMWG) documents used for
benchmarking routers and switches. This document seeks to extend benchmarking routers and switches. This document seeks to extend
these efforts specific to the IPsec paradigm. The BMWG produces two these efforts specific to the IPsec paradigm. The BMWG produces two
major classes of documents: Benchmarking Terminology documents and major classes of documents: Benchmarking Terminology documents and
Benchmarking Methodology documents. The Terminology documents Benchmarking Methodology documents. The Terminology documents
present the benchmarks and other related terms. The Methodology present the benchmarks and other related terms. The Methodology
documents define the procedures required to collect the benchmarks documents define the procedures required to collect the benchmarks
cited in the corresponding Terminology documents. cited in the corresponding Terminology documents.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . 5 2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . 4
2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 7 2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Security Associations . . . . . . . . . . . . . . . . 7 2.1.1 Security Associations . . . . . . . . . . . . . . . . 6
2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . 7 2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . 6
3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 9 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . . 8
4. Definition Format . . . . . . . . . . . . . . . . . . . . . 9 4. Definition Format . . . . . . . . . . . . . . . . . . . . . 9
5. Key Words to Reflect Requirements . . . . . . . . . . . . . 10 5. Key Words to Reflect Requirements . . . . . . . . . . . . . 9
6. Existing Benchmark Definitions . . . . . . . . . . . . . . . 10 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . 9
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.2 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.2 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3.1 IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 13 7.3.1 IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 12
7.3.2 IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 13 7.3.2 IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 13
7.3.3 IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 14 7.3.3 IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 13
7.3.4 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 15 7.3.4 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 14
7.3.5 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 15 7.3.5 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 14
7.4 Security Association (SA) . . . . . . . . . . . . . . . . 16 7.4 Security Association (SA) . . . . . . . . . . . . . . . . 15
7.5 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 16 7.5 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 15
7.6 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 17 7.6 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 16
7.6.1 Initiator . . . . . . . . . . . . . . . . . . . . . . 18 7.6.1 Initiator . . . . . . . . . . . . . . . . . . . . . . 17
7.6.2 Responder . . . . . . . . . . . . . . . . . . . . . . 18 7.6.2 Responder . . . . . . . . . . . . . . . . . . . . . . 17
7.6.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . 19 7.6.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . 18
7.6.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . 19 7.6.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . 19
7.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 20 7.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.7.1 IKE Tunnel . . . . . . . . . . . . . . . . . . . . . . 20 7.7.1 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 19
7.7.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 21 7.7.2 Configured Tunnel . . . . . . . . . . . . . . . . . . 21
7.7.3 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 21 7.7.3 Established Tunnel . . . . . . . . . . . . . . . . . . 22
7.7.4 Configured Tunnel . . . . . . . . . . . . . . . . . . 22 7.7.4 Active Tunnel . . . . . . . . . . . . . . . . . . . . 22
7.7.5 Established Tunnel . . . . . . . . . . . . . . . . . . 23 7.8 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 23
7.7.6 Active Tunnel . . . . . . . . . . . . . . . . . . . . 23 7.8.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . 23
7.8 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 24 7.8.2 Transport Adjacency . . . . . . . . . . . . . . . . . 24
7.8.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . 24 7.9 Transform protocols . . . . . . . . . . . . . . . . . . . 25
7.8.2 Transport Adjacency . . . . . . . . . . . . . . . . . 25
7.9 Transform protocols . . . . . . . . . . . . . . . . . . . 26
7.9.1 Authentication Protocols . . . . . . . . . . . . . . . 26 7.9.1 Authentication Protocols . . . . . . . . . . . . . . . 26
7.9.2 Encryption Protocols . . . . . . . . . . . . . . . . . 27 7.9.2 Encryption Protocols . . . . . . . . . . . . . . . . . 26
7.10 IPsec Protocols . . . . . . . . . . . . . . . . . . . . 27 7.10 IPsec Protocols . . . . . . . . . . . . . . . . . . . . 27
7.10.1 Authentication Header (AH) . . . . . . . . . . . . . 28 7.10.1 Authentication Header (AH) . . . . . . . . . . . . . 27
7.10.2 Encapsulated Security Payload (ESP) . . . . . . . . 29 7.10.2 Encapsulated Security Payload (ESP) . . . . . . . . 28
7.11 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . 29 7.11 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . 29
7.12 IP Compression . . . . . . . . . . . . . . . . . . . . . 30 7.12 IP Compression . . . . . . . . . . . . . . . . . . . . . 29
7.13 Security Context . . . . . . . . . . . . . . . . . . . . 31 7.13 Security Context . . . . . . . . . . . . . . . . . . . . 30
8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . 33 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . 32
8.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 33 8.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32
8.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33 8.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33
8.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34 8.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34
8.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 35 8.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 34
9. Performance Metrics . . . . . . . . . . . . . . . . . . . . 36 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . 35
9.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 36 9.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 35
9.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 36 9.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 36
9.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 37 9.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 36
10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . 37 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . 37
10.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . 37 10.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . 37
10.1.1 Tunnel Throughput . . . . . . . . . . . . . . . . . 37 10.1.1 IPsec Tunnel Throughput . . . . . . . . . . . . . . 37
10.1.2 IPsec Encryption Throughput . . . . . . . . . . . . 38 10.1.2 IPsec Tunnel Encryption Throughput . . . . . . . . . 38
10.1.3 IPsec Decryption Throughput . . . . . . . . . . . . 39 10.1.3 IPsec Tunnel Decryption Throughput . . . . . . . . . 38
10.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . 40 10.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . 39
10.2.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . 40 10.2.1 IPsec Tunnel Latency . . . . . . . . . . . . . . . . 39
10.2.2 IPsec Tunnel Encryption Latency . . . . . . . . . . 40 10.2.2 IPsec Tunnel Encryption Latency . . . . . . . . . . 40
10.2.3 IPsec Tunnel Decryption Latency . . . . . . . . . . 41 10.2.3 IPsec Tunnel Decryption Latency . . . . . . . . . . 41
10.2.4 Time To First Packet . . . . . . . . . . . . . . . . 42 10.2.4 Time To First Packet . . . . . . . . . . . . . . . . 41
10.3 Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 43 10.3 Frame Loss . . . . . . . . . . . . . . . . . . . . . . . 42
10.3.1 IPsec Tunnel Frame Loss . . . . . . . . . . . . . . 43 10.3.1 IPsec Tunnel Frame Loss . . . . . . . . . . . . . . 42
10.3.2 IPsec Tunnel Encryption Frame Loss . . . . . . . . . 43 10.3.2 IPsec Tunnel Encryption Frame Loss . . . . . . . . . 43
10.3.3 IPsec Tunnel Decryption Frame Loss . . . . . . . . . 44 10.3.3 IPsec Tunnel Decryption Frame Loss . . . . . . . . . 44
10.3.4 Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . 45 10.3.4 Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . 44
10.4 Back-to-back Frames . . . . . . . . . . . . . . . . . . 45 10.4 Back-to-back Frames . . . . . . . . . . . . . . . . . . 45
10.4.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . 45 10.4.1 IPsec Tunnel Back-to-back Frames . . . . . . . . . . 45
10.4.2 Encryption Back-to-back Frames . . . . . . . . . . . 46 10.4.2 IPsec Tunnel Encryption Back-to-back Frames . . . . 46
10.4.3 Decryption Back-to-back Frames . . . . . . . . . . . 47 10.4.3 IPsec Tunnel Decryption Back-to-back Frames . . . . 46
10.5 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . 47 10.5 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . 47
10.5.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . 47 10.5.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . 47
10.5.2 Phase 1 Setup Rate . . . . . . . . . . . . . . . . . 48 10.5.2 Phase 1 Setup Rate . . . . . . . . . . . . . . . . . 48
10.5.3 Phase 2 Setup Rate . . . . . . . . . . . . . . . . . 49 10.5.3 Phase 2 Setup Rate . . . . . . . . . . . . . . . . . 48
10.6 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . 49 10.6 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . 49
10.6.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . 49 10.6.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . 49
10.6.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . 50 10.6.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . 50
10.7 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . 51 10.7 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . 51
10.8 IKE DOS Resilience Rate . . . . . . . . . . . . . . . . 51 10.8 IKE DOS Resilience Rate . . . . . . . . . . . . . . . . 51
11. Security Considerations . . . . . . . . . . . . . . . . . . 52 11. Security Considerations . . . . . . . . . . . . . . . . . . 52
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 52
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 52
14. References . . . . . . . . . . . . . . . . . . . . . . . . . 53 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 52
14.1 Normative References . . . . . . . . . . . . . . . . . . 53 14.1 Normative References . . . . . . . . . . . . . . . . . . 52
14.2 Informative References . . . . . . . . . . . . . . . . . 55 14.2 Informative References . . . . . . . . . . . . . . . . . 55
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 55
Intellectual Property and Copyright Statements . . . . . . . 57 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 and software solutions. the terminology used to develop such hardware and software solutions.
This results in varied implementations which challenge This results in varied implementations which challenge
interoperability and direct performance comparisons. Standardized interoperability and direct performance comparisons. Standardized
IPsec terminology and performance test methodologies will enable IPsec terminology and performance test methodologies will enable
users to determine if the IPsec device they select will withstand users to determine if the IPsec device they select will withstand
loads of secured traffic that meet their requirements. loads of secured traffic that meet their requirements.
To appropriately define the parameters and scope of this document, To appropriately define the parameters and scope of this document,
this section will give a brief overview of the IPsec standard: this section will give a brief overview of the IPsec standard:
2. IPsec Fundamentals 2. 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 origin authenticity between
participating peers. IPsec provides these security services at the participating peers. IPsec provides these security services at the
IP layer. IPsec uses IKE to handle negotiation of protocols and IP layer. IPsec uses IKE to handle negotiation of protocols and
algorithms based on local policy, and to generate the encryption and algorithms based on local policy, and to generate the encryption and
authentication keys to be used. IPsec can be used to protect one or authentication keys to be used. IPsec can be used to protect one or
more data flows between a pair of hosts, between a pair of security more data flows between a pair of hosts, between a pair of security
gateways, or between a security gateway and a host. The IPsec gateways, or between a security gateway and a host. The IPsec
protocol suite set of standards is documented in RFC's [RFC2401] protocol suite set of standards is documented in RFC's [RFC2401]
through [RFC2412] and [RFC2451]. The reader is assumed to be through [RFC2412] and [RFC2451]. The reader is assumed to be
familiar with these documents. Some Internet Drafts supersede these familiar with these documents. Some Internet Drafts supersede these
RFC's and will be 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-
anti-replay services. AH ensures the integrity and data origin replay services. AH ensures the integrity and data origin
authentication of the IP datagram as well as the invariant fields in authentication of the IP datagram as well as the invariant fields in
the outer IP header. the outer IP header.
Encapsulating Security Payload (ESP): A security protocol, defined in Encapsulating Security Payload (ESP): A security protocol, defined in
[RFC2406], which provides confidentiality, data origin [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
skipping to change at page 6, line 15 skipping to change at page 5, line 15
implementation is with the IPsec protocol. IKE provides implementation is with the IPsec protocol. IKE provides
authentication of the IPsec peers, negotiates IPsec security authentication of the IPsec peers, negotiates IPsec security
associations, and establishes IPsec keys. 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 IPv6, the
security protocol header appears after the base IP header and
In the case of AH in transport mode, all upper-layer information is selected extension headers. It may appear before or after
protected, and all fields in the IPv4 header excluding the fields destination options but must appear before next layer protocols
typically are modified in transit. The fields of the IPv4 header (e.g., TCP, UDP, SCTP)
that are not included are, therefore, set to 0 before applying the
authentication algorithm. These fields are as follows:
* TOS In the case of AH in transport mode, security services are provided
* TTL to selected portions of the IP header preceding the AH header,
* Header Checksum selected portions of extension headers, and selected options
* Offset (contained in the IPv4 header, IPv6 Hop-by-Hop extension header, or
* Flags IPv6 Destination extension headers). Any fields in these headers/
extension headers which are modified in transit are set to 0 before
applying the authentication algorithm. If a field is mutable, but
its value at the receiving IPsec peer is predictable, then that value
is inserted into the field before applying the cryptographic
algorithm.
In the case of ESP in transport mode, security services are provide In the case of ESP in transport mode, security services are provide
only for the higher-layer protocols, not for the IP header. only for the higher-layer protocols, not for the IP header or any
extension headers preceding the ESP header.
A tunnel is a vehicle for encapsulating packets inside a protocol A tunnel is a vehicle for encapsulating packets inside a protocol
that is understood at the entry and exit points of a given network. that is understood at the entry and exit points of a given network.
These entry and exit points are defined as tunnel interfaces. These entry and exit points are defined as tunnel interfaces.
Both the AH and ESP protocols can be used in tunnel mode for data Both the AH and ESP protocols can be used in tunnel mode for data
packet endpoints as well as by intermediate security gateways. In packet endpoints as well as by intermediate security gateways. In
tunnel mode, there is an "outer" IP header that specifies the IPsec tunnel mode, there is an "outer" IP header that specifies the IPsec
processing destination, plus an "inner" IP header that specifies the processing destination, plus an "inner" IP header that specifies the
ultimate destination for the packet. The source address in the outer ultimate destination for the packet. The source address in the outer
IP header is the initiating cryptographic endpoint; the source IP header is the initiating cryptographic endpoint; the source
address in the inner header is the true source address of the packet. address in the inner header is the true source address of the packet.
The security protocol header appears after the outer IP header and The security protocol header appears after the outer IP header and
before the inner IP header. before the inner IP header.
If AH is employed in tunnel mode, portions of the outer IP header are If AH is employed in tunnel mode, portions of the new outer IP header
given protection (those same fields as for transport mode, described are given protection (those same fields as for transport mode,
earlier in this section), as well as all of the tunneled IP packet described earlier in this section), as well as all of the tunneled IP
(that is, all of the inner IP header is protected as are the packet (that is, all of the inner IP header is protected as are the
higher-layer protocols). If ESP is employed, the protection is higher-layer protocols). If ESP is employed, the protection is
afforded only to the tunneled packet, not to the outer header. afforded only to the tunneled packet, not to the new outer IP header.
2.1 IPsec Operation 2.1 IPsec Operation
2.1.1 Security Associations 2.1.1 Security Associations
The concept of a Security Association (SA) is fundamental to IPsec. The concept of a Security Association (SA) is fundamental to IPsec.
An SA is a relationship between two or more entities that describes An SA is a relationship between two or more entities that describes
how the entities will use security services to communicate. The SA how the entities will use security services to communicate. The SA
includes: an encryption algorithm, an authentication algorithm and a includes: an encryption algorithm, an authentication algorithm and a
shared session key. shared session key.
skipping to change at page 7, line 34 skipping to change at page 6, line 38
protection, it looks up the SA in its database and applies the protection, it looks up the SA in its database and applies the
specified processing and security protocol (AH/ESP), inserting the specified processing and security protocol (AH/ESP), inserting the
SPI from the SA into the IPsec header. When the IPsec peer receives SPI from the SA into the IPsec header. When the IPsec peer receives
the packet, it looks up the SA in its database by destination the packet, it looks up the SA in its database by destination
address, protocol, and SPI and then processes the packet as required. address, protocol, and SPI and then processes the packet as required.
2.1.2 Key Management 2.1.2 Key Management
IPsec uses cryptographic keys for authentication, integrity and IPsec uses cryptographic keys for authentication, integrity and
encryption services. Both manual provisioning and automatic encryption services. Both manual provisioning and automatic
distribution of keys is supported. IKE is specified as the distribution of keys is supported. IKE is specified as the public-
public-key-based approach for automatic key management. key-based approach for automatic key management.
IKE authenticates each peer involved in IPsec, negotiates the IKE authenticates each peer involved in IPsec, negotiates the
security policy, and handles the exchange of session keys. IKE is a security policy, and handles the exchange of session keys. IKE is a
hybrid protocol, combining parts of the following protocols to hybrid protocol, combining parts of the following protocols to
negotiate and derive keying material for SA's in a secure and negotiate and derive keying material for SA's in a secure and
authenticated manner: authenticated manner:
1. ISAKMP [RFC2408] (Internet Security Association and Key 1. ISAKMP [RFC2408] (Internet Security Association and Key
Management Protocol), which provides a framework for Management Protocol), which provides a framework for
authentication and key exchange but does not define them. ISAKMP authentication and key exchange but does not define them. ISAKMP
skipping to change at page 9, line 28 skipping to change at page 8, line 33
derived by using Diffie-Hellman again or by refreshing the shared key derived by using Diffie-Hellman again or by refreshing the shared key
derived from the original Diffie-Hellman exchange that generated the derived from the original Diffie-Hellman exchange that generated the
IKE_SA by hashing it with nonces. Once the shared key is derived and IKE_SA by hashing it with nonces. Once the shared key is derived and
additional communication parameters are negotiated, the IPsec SA's additional communication parameters are negotiated, the IPsec SA's
are established and traffic can be exchanged using the negotiated are established and traffic can be exchanged using the negotiated
parameters. parameters.
3. Document Scope 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 manual keying and
constrain the terminology specified in this document to meet the IKEv1. We want to constrain the terminology specified in this
requirements of the Methodology for Benchmarking IPsec Devices document to meet the requirements of the Methodology for Benchmarking
documented test methodologies. The testing will be constrained to IPsec Devices documented test methodologies.
devices acting as IPsec gateways and will pertain to both IPsec
tunnel and transport mode. The testing will be constrained to:
o Devices acting as IPsec gateways whose tests will pertain to both
IPsec tunnel and transport mode.
o Devices acting as IPsec end-hosts whose tests will pertain to
IPsec transport mode.
Any testing involving interoperability and/or conformance issues, Any testing involving interoperability and/or conformance issues,
L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and L2TP [RFC2661], GRE [RFC2784], MPLS VPN's [RFC2547], multicast, and
anything that does not specifically relate to the establishment and anything that does not specifically relate to the establishment and
tearing down of IPsec tunnels is specifically out of scope. It is tearing down of IPsec tunnels is specifically out of scope. It is
assumed that all relevant networking parameters that facilitate in assumed that all relevant networking parameters that facilitate in
the running of these tests are pre-configured (this includes at a the running of these tests are pre-configured (this includes at a
minimum ARP caches and routing tables). minimum ARP caches and routing tables).
4. Definition Format 4. Definition Format
skipping to change at page 11, line 23 skipping to change at page 10, line 31
7.1 IPsec 7.1 IPsec
Definition: Definition:
IPsec or IP Security protocol suite which comprises a set of IPsec or IP Security protocol suite which comprises a set of
standards used to provide security services at the IP layer. standards used to provide security services at the IP layer.
Discussion: Discussion:
IPsec is a framework of protocols that offer authentication, IPsec is a framework of protocols that offer authentication,
authenticity and encryption services to the IP and/or upper layer integrity and encryption services to the IP and/or upper layer
protocols. The major components of the protocol suite are IKE, protocols. The major components of the protocol suite are IKE,
used for key exchanges, and IPsec protocols such as AH and ESP, used for key exchanges, and IPsec protocols such as AH and ESP,
which use the exchanged keys to protect payload traffic. which use the exchanged keys to protect payload traffic.
Issues: Issues:
N/A N/A
See Also: See Also:
skipping to change at page 12, line 18 skipping to change at page 11, line 30
an IKE Phase 1 SA. an IKE Phase 1 SA.
See Also: See Also:
IKE, Security Association IKE, Security Association
7.3 IKE 7.3 IKE
Definition: Definition:
A hybrid key management protocol that allows secure negotiation of A hybrid key management protocol that provides authentication of
IPsec SA paramters. the IPsec peers, negotiates IPsec SAs and establishes IPsec keys.
Discussion: Discussion:
A hybrid protocol, defined in [RFC2409], from the following 3 A hybrid protocol, defined in [RFC2409], from the following 3
protocols: protocols:
* ISAKMP (Internet Security Association and Key Management * ISAKMP (Internet Security Association and Key Management
Protocol), which provides a framework for authentication and Protocol), which provides a framework for authentication and
key exchange but does not define them. ISAKMP is designed to key exchange but does not define them. ISAKMP is designed to
be key exchange independent; it is designed to support many be key exchange independent; it is designed to support many
skipping to change at page 12, line 42 skipping to change at page 12, line 6
* 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 network IPsec SAs may also be manually configured. Manual keying is the
administrator will provide keys that will be associated with the most basic mechanism to establish IPsec SAs between two IPsec
Phase 2 SA's as long as the IPsec Tunnel is configured. This devices. However, it is not a scalable solution and often
method is the most basic mechanism to establish an IPsec tunnel manually configured keys are not changed on a periodic basis which
between two IPsec devices but it also reduces the level of reduces the level of protection since the keys are effectively
protection since the keys are static and as a result are more static and as a result are more prone to various attacks. When
prone to various attacks. When IKE is employed as a key IKE is employed as a key management protocol, the keys are
management protocol, the keys will change on a regular basis (time automatically renegotiated on a user-defined basis (time and/or
and/or traffic volume based) as part of the IKE rekeying traffic volume based) as part of the IKE rekeying mechanism.
mechanism.
Issues: Issues:
During the first IPsec deployment experiences, ambiguities were During the first IPsec deployment experiences, ambiguities were
found in the IKEv1 specification, which lead to interoperability found in the IKEv1 specification, which lead to interoperability
problems. To resolve these issues, IKEv1 is being updated by problems. To resolve these issues, IKEv1 is being updated by
IKEv2. IKEv2.
See Also: See Also:
skipping to change at page 15, line 39 skipping to change at page 15, line 6
Definition: Definition:
Quick Mode is an instanciation of IKE Phase 2. After successful Quick Mode is an instanciation of IKE Phase 2. After successful
completion it will result in one or typically two or more IPsec completion it will result in one or typically two or more IPsec
SA's SA's
Discussion: Discussion:
Quick Mode is used to negotiate the SA's and keys that will be Quick Mode is used to negotiate the SA's and keys that will be
used to protect the user data, i.e. the IPsec SA. Three used to protect the user data. Three different messages are
different messages are exchanged, which are protected by the exchanged, which are protected by the security parameters
security parameters negotiated by the IKE phase 1 exchange. An negotiated by the IKE phase 1 exchange. An additional Diffie-
additional Diffie-Hellman exchange may be performed if PFS Hellman exchange may be performed if PFS (Perfect Forward Secrecy)
(Perfect Forward Secrecy) is enabled. is enabled.
Issues: Issues:
N/A N/A
See Also: See Also:
ISAKMP, IKE, IKE Phase 2 ISAKMP, IKE, IKE Phase 2
7.4 Security Association (SA) 7.4 Security Association (SA)
skipping to change at page 18, line 10 skipping to change at page 17, line 25
See Also: See Also:
IPsec IPsec
7.6.1 Initiator 7.6.1 Initiator
Definition: Definition:
An IPsec device which starts the negotiation of IKE Phase 1 and An IPsec device which starts the negotiation of IKE Phase 1 and
Phase 2 tunnels. IKE Phase 2 SAs.
Discussion: Discussion:
When a traffic flow is offered at an IPsec device and it is When a traffic flow is offered at an IPsec device and it is
determined that the flow must be protected, but there is no IPsec determined that the flow must be protected, but there is no IPsec
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
skipping to change at page 18, line 34 skipping to change at page 18, line 4
Issues: Issues:
IPsec devices/implementations can be both an initiator as well as IPsec devices/implementations can be both an initiator as well as
a responder. The distinction is useful from a test perspective. a responder. The distinction is useful from a test perspective.
See Also: See Also:
Responder, IKE, IPsec Responder, IKE, IPsec
7.6.2 Responder 7.6.2 Responder
Definition: Definition:
An IPsec devices which replies to incoming IKE Phase 1 and Phase 2 An IPsec device which replies to incoming IKE Phase 1 and IKE
tunnel requests and process these messages in order to establish a Phase 2 requests and processes these messages in order to
tunnel. establish an IPsec tunnel.
Discussion: Discussion:
When an initiator attempts to establish SA's with another IPsec When an initiator attempts to establish SA's with another IPsec
device, this peer will need to evaluate the proposals made by the device, this peer will need to evaluate the proposals made by the
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:
skipping to change at page 19, line 22 skipping to change at page 18, line 37
7.6.3 IPsec Client 7.6.3 IPsec Client
Definition: Definition:
IPsec Devices that will only act as an Initiator. IPsec Devices that will only act as an Initiator.
Discussion: Discussion:
In some situations it is not needed or prefered to have an IPsec In some situations it is not needed or prefered to have an IPsec
device respond to an inbound tunnel request. In the case of e.g. device respond to an inbound IKE SA or IPsec SA request. In the
road warriors or home office scenarios the only property needed case of e.g. road warriors or home office scenarios the only
from the IPsec device is the ability to securely connect to a property needed from the IPsec device is the ability to securely
remote private network. The IPsec Client will set up one or more connect to a remote private network. The IPsec Client will
Tunnels to an IPsec Server on the network that needs to be initiate one or more IPsec tunnels to an IPsec Server on the
accessed and to provide the required security services. An IPsec network that needs to be accessed and to provide the required
client will silently drop and ignore any inbound tunnel requests. security services. An IPsec client will silently drop and ignore
IPsec clients are generally used to connect remote users in a any inbound IPsec tunnel requests. IPsec clients are generally
secure fashion over the Internet to a private network. used to connect remote users in a secure fashion over the Internet
to a private network.
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec device, IPsec Server, Initiator, Responder IPsec device, IPsec Server, Initiator, Responder
7.6.4 IPsec Server 7.6.4 IPsec Server
skipping to change at page 20, line 8 skipping to change at page 19, line 25
Definition: Definition:
IPsec Devices that can both act as an Initiator as well as a IPsec Devices that can both act as an Initiator as well as a
Responder. Responder.
Discussion: Discussion:
IPsec Servers are mostly positioned at private network edges and IPsec Servers are mostly positioned at private network edges and
provide several functions : provide several functions :
Responds to tunnel setup request from IPsec Clients. * Responds to IPsec tunnel setup request from IPsec Clients.
Responds to tunnel setup request from other IPsec devices * Responds to IPsec tunnel setup request from other IPsec devices
(Initiators). (Initiators).
Initiate tunnels to other IPsec servers inside or outside the * Initiate IPsec tunnels to other IPsec servers inside or outside
private network. the private network.
Issues: Issues:
IPsec Servers are also sometimes referred to as 'VPN IPsec Servers are also sometimes referred to as 'VPN
Concentrators'. Concentrators'.
See Also: See Also:
IPsec Device, IPsec Client, Initiator, Responder IPsec Device, IPsec Client, Initiator, Responder
7.7 Tunnels 7.7 Tunnels
The term "tunnel" is often used in a variety of contexts. To avoid The term "tunnel" is often used in a variety of contexts. To avoid
any discrepancies, in this document, the following distinctions have any discrepancies, in this document, the following distinctions have
been defined : been defined :
7.7.1 IKE Tunnel 7.7.1 IPsec Tunnel
Definition:
A single Phase 1 IKE SA.
Discussion:
An IKE Tunnel between IPsec devices facilitates a mechanism for
secure negotiation of Phase 1 properties and Phase 2 SA's needed
for protected data transport. The initiator may choose which mode
to start the negotiation of the IKE Tunnel in. This can be either
main mode or aggressive mode.
Issues:
Also referred to as an ISAKMP SA or IKE SA or Phase 1 Tunnel.
See Also:
Tunnel, IPsec Tunnel, Security Association, IKE, IKE Phase 1
7.7.2 IPsec Tunnel
Definition: Definition:
One or more Phase 2 SA's that are negotiated in conjunction with The combination of an IKE Phase 1 SA and a pair of IKE Phase 2
an IKE Tunnel. SA's.
Discussion: Discussion:
In the case of simplex communication, a single phase 2 SA. A 'Tunnel' will be defined as a single (1) Phase 1 SA and a pair
(2) Phase 2 SA's. This construct will allow bidirectional traffic
In the more likely case where bidirectional communication is to be passed between two IPsec Devices The AH and ESP protocols
needed it is a pair (2) Phase 2 SA's. The two SA's are used to each support two modes of operation: transport mode and tunnel
secure inbound and outbound traffic. mode. In transport mode, two hosts provide protection primarily
for upper-layer protocols. The cryptographic endpoints (where the
Not in all situations is it required to have an existing IKE encryption and decryption take place) are the source and
Tunnel in order to negotiate IPsec Tunnel properties and destination of the data packet. In IPv4, a transport mode
parameters. Manually keyed tunnels allow the set up of IPsec security protocol header appears immediately after the IP header
Tunnels without the need of the IKE protocol. and before any higher-layer protocols (such as TCP or UDP). In
IPv6, the security protocol header appears after the base IP
header and selected extension headers. It may appear before or
after destination options but must appear before next layer
protocols (e.g., TCP, UDP, SCTP) In the case of AH in transport
mode, security services are provided to selected portions of the
IP header preceding the AH header, selected portions of extension
headers, and selected options (contained in the IPv4 header, IPv6
Hop-by-Hop extension header, or IPv6 Destination extension
headers). Any fields in these headers/extension headers which are
modified in transit are set to 0 before applying the
authentication algorithm. If a field is mutable, but its value at
the receiving IPsec peer is predictable, then that value is
inserted into the field before applying the cryptographic
algorithm. In the case of ESP in transport mode, security
services are provide only for the higher-layer protocols, not for
the IP header or any extension headers preceding the ESP header.
A tunnel is a vehicle for encapsulating packets inside a protocol
that is understood at the entry and exit points of a given
network. These entry and exit points are defined as tunnel
interfaces. Both the AH and ESP protocols can be used in tunnel
mode for data packet endpoints as well as by intermediate security
gateways. In tunnel mode, there is an "outer" IP header that
specifies the IPsec processing destination, plus an "inner" IP
header that specifies the ultimate destination for the packet.
The source address in the outer IP header is the initiating
cryptographic endpoint; the source address in the inner header is
the true source address of the packet. The security protocol
header appears after the outer IP header and before the inner IP
header. If AH is employed in tunnel mode, portions of the new
outer IP header are given protection (those same fields as for
transport mode, described earlier in this section), as well as all
of the tunneled IP packet (that is, all of the inner IP header is
protected as are the higher-layer protocols). If ESP is employed,
the protection is afforded only to the tunneled packet, not to the
new outer IP header. where the traffic can benefit form the
services offered in the IPsec framework.
Issues: Issues:
If not explicitly specified it SHALL be assumed that an IPsec Since it is implied that a Phase 1 SA is used, a Tunnel will be by
Tunnel is a pair (2) Phase 2 SA's. definition a dynamically negotiated secured link. If manual
keying is used to enable secure data transport, then this link
Also referred to as a Phase 2 Tunnel or a Phase 2 SA (may be will merely refered to as a pair of IKE Phase 2 SA's.
multiple).
See Also:
Tunnel, IKE Tunnel, Security Association, IKE, IKE Phase 2
7.7.3 Tunnel
Definition:
The combination of an IKE Tunnel and an IPsec Tunnel
Discussion:
In the majority of the cases IPsec is used to protect
bidirectional traffic flows. Unless stated otherwise a 'Tunnel'
will be defined as a single Phase 1 SA and two Phase 2 SA's that
are associated with the Phase 1 SA.
Issues:
If other than a single Phase 2 SA, for each direction, have been It is very likely that more then one pair of Phase 2 SA's are
negotiated through a single IKE Tunnel, then this specific ratio associated with a single Phase 1 SA. Also in this case, the
MUST be mentioned and the term 'Tunnel' MUST NOT be used in this Tunnel definition WILL NOT apply. Instead the ratio between Phase
context." 1 SA's and Phase 2 SA's MUST be explictly stated. The umbrella
term of "IPsec Tunnel" MUST NOT be used in this context.
See Also: See Also:
IKE Tunnel, IPsec Tunnel IKE Phase 1, IKE Phase 2
7.7.4 Configured Tunnel 7.7.2 Configured Tunnel
Definition: Definition:
A tunnel that is present in the IPsec device's configuration but An IPsec tunnel that is provisioned in the IPsec device's
does not have any entries in the SADB (Security Association configuration and SADB.
DataBase) i.e. SA's.
Discussion: Discussion:
Several steps are required before a Tunnel can be used to actually Several steps are required before an IPsec Tunnel can be used to
transport traffic. The very first step is to configure the tunnel actually transport traffic. The very first step is to configure
in the IPsec device. In that way packet classification can make a the IPsec Tunnel in the IPsec device. In that way packet
decision if it is required to start negotiating SA's. At this classification can make a decision if it is required to start
time there are no SA's associated with the Tunnel and no traffic negotiating SA's. At this time there are no SA's associated with
is going through the IPsec device that matches the Selectors, the Tunnel and no traffic is going through the IPsec device that
which would instantiate the Tunnel. matches the Selectors, which would instantiate the IPsec Tunnel.
A Configured Tunnel is also a tunnel that has relinquished all A Configured Tunnel is also an IPsec Tunnel that has relinquished
it's SA's and is not transmitting data anymore. To be more all 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 due to either an administrative action or an IKE event that
deactivated the tunnel, the tunnel will be back in a configured deactivated the IPsec Tunnel, the IPsec Tunnel will be back in a
state. configured state.
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel, Established Tunnel, Active Tunnel Tunnel, Established Tunnel, Active Tunnel
7.7.5 Established Tunnel 7.7.3 Established Tunnel
Definition: Definition:
A Tunnel that has completed Phase 1 and Phase 2 SA negotiations An IPsec Tunnel that has completed Phase 1 and Phase 2 SA
but is otherwise idle. negotiations 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 an IPsec Tunnel can transport
to complete the Phase 1 and Phase 2 negotiations. After the data is to complete the Phase 1 and Phase 2 negotiations. After
packet classification process has asserted that a packet requires the packet classification process has asserted that a packet
security services, the negotation is started to obtain both Phase requires security services, the negotation is started to obtain
1 and Phase 2 SA's. After this is completed the tunnel is called both Phase 1 and Phase 2 SA's. After this is completed the IPsec
'Established'. Note that at this time there is still no traffic Tunnel is called 'Established'. Note that at this time there is
flowing through the Tunnel. Just enough packet(s) have been sent still no traffic flowing through the IPsec Tunnel. Just enough
to the IPsec device that matched the selectors and triggered the packet(s) have been sent to the IPsec device that matched the
Tunnel setup. This may also be acomplished by an administrative selectors and triggered the IPsec Tunnel setup. This may also be
command to connect the Tunnel, in which case the Tunnel is not acomplished by an administrative command to connect the Tunnel, in
triggered by any positive packet classification. which case the Tunnel is not triggered by any positive packet
classification.
Issues: Issues:
In the case of manually keyed tunnels, there is no distinction In the case of manually keyed Tunnels, there is no distinction
between a Configured Tunnel or an Established Tunnel since there between a Configured Tunnel or an Established Tunnel since there
is no negotiation required with these type of Tunnels and the is no negotiation required with these type of Tunnels and the
Tunnel is Established at time of Configuration since all keying Tunnel is Established at time of Configuration since all keying
information is known at that point. information is known at that point.
See Also: See Also:
Tunnel, Configured Tunnel, Active Tunnel Tunnel, Configured Tunnel, Active Tunnel
7.7.6 Active Tunnel 7.7.4 Active Tunnel
Definition: Definition:
A tunnel that has completed Phase 1 and Phase 2 SA negotiations An IPsec Tunnel that has completed Phase 1 and Phase 2 SA
and is forwarding data. negotiations and is forwarding data.
Discussion: Discussion:
When a Tunnel is Established and it is transporting traffic, the When an IPsec Tunnel is Established and it is transporting
tunnel is called 'Active'. traffic, the tunnel is called 'Active'.
Issues: Issues:
The distinction between an Active Tunnel and The distinction between an Active Tunnel and Configured/
Configured/Established Tunnel is made in the context of manual Established Tunnel is made in the context of manual keyed Tunnels.
keyed Tunnels. In this case it would be possible to have an In this case it would be possible to have an Established tunnel on
Established tunnel on an IPsec device which has no counterpart on an IPsec device which has no counterpart on it's corresponding
it's corresponding peer. This will lead to encrypted traffic peer. This will lead to encrypted traffic flows which will be
flows which will be discarded on the receiving peer. Only if both discarded on the receiving peer. Only if both peers have an
peers have an Established Tunnel that shows evidence of traffic Established Tunnel that shows evidence of traffic transport, it
transport, it may be called an Active Tunnel. may be called an Active Tunnel.
See Also: See Also:
Tunnel, Configured Tunnel, Established Tunnel Tunnel, Configured Tunnel, Established Tunnel
7.8 Iterated Tunnels 7.8 Iterated Tunnels
Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. Iterated Tunnels are a bundle of transport and/or tunnel mode SA's.
The bundles are divided into two major groups : The bundles are divided into two major groups :
skipping to change at page 29, line 23 skipping to change at page 28, line 40
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 The ESP protocol supports both modes of operation i.e. tunnel mode
mode and transport mode. If ESP is employed in tunnel mode, the 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 25 skipping to change at page 30, line 39
See Also: See Also:
IKE, ISAKMP, IPsec Device IKE, ISAKMP, IPsec Device
7.13 Security Context 7.13 Security Context
Definition: Definition:
A security context is a collection of security parameters that A security context is a collection of security parameters that
describe the characteristics of the path that a tunnel will take, describe the characteristics of the path that an IPsec Tunnel will
all of the tunnel parameters and the effects it has on the take, all of the IPsec Tunnel parameters and the effects it has on
underlying protected traffic. Security Context encompasses the underlying protected traffic. Security Context encompasses
protocol suite and security policy. protocol suite and security policy.
Discussion: Discussion:
In order to fairly compare multiple IPsec devices it is imperative In order to fairly compare multiple IPsec devices it is imperative
that an accurate overview is given of all security parameters that that an accurate overview is given of all security parameters that
were used to establish tunnels and to secure the traffic between were used to establish the IPsec Tunnels and to secure the traffic
protected networks. Security Context is not a metric; it is between protected networks. Security Context is not a metric; it
included to accurately reflect the test environment variables when is included to accurately reflect the test environment variables
reporting the methodology results. To avoid listing too much when reporting the methodology results. To avoid listing too much
information when reporting metrics, we have divided the security information when reporting metrics, we have divided the security
context into an IKE context and an IPsec context. context into an IKE context and an IPsec context.
When merely discussing the behavior of traffic flows through IPsec When merely discussing the behavior of traffic flows through IPsec
devices, an IPsec context MUST be provided. In other cases the devices, an IPsec context MUST be provided. In other cases the
scope of a discussion or report may focus on a more broad set of scope of a discussion or report may focus on a more broad set of
behavioral characteristics of the IPsec device, the both and IPsec behavioral characteristics of the IPsec device, the both and IPsec
and an IKE context MUST be provided. and an IKE context MUST be provided.
The IPsec context MUST consist of the following elements: The IPsec context MUST consist of the following elements:
* Number of IPsec tunnels * Number of IPsec Tunnels or IKE Phase 1 / Phase 2 ratio
* IPsec tunnels per IKE tunnel (IKE/IPsec tunnel ratio)
* IPsec protocol * IPsec protocol
* IPsec mode (tunnel or transport) * IPsec mode (tunnel or transport)
* Authentication protocol used by IPsec * Authentication protocol used by IPsec
* Encryption protocol used by IPsec (if applicable) * Encryption protocol used by IPsec (if applicable)
* IPsec SA lifetime (traffic and time based) * IPsec SA lifetime (traffic and time based)
skipping to change at page 34, line 7 skipping to change at page 33, line 20
Encrypted Framesize. Encrypted Framesize.
8.2 Layer3 encrypted framesize 8.2 Layer3 encrypted framesize
Definition: Definition:
The total size of the encrypted L3 PDU. The total size of the encrypted L3 PDU.
Discussion: Discussion:
The size of the IP packet and itĘs payload after encapsulations The size of the IP packet and its payload after encapsulations MAY
MAY be applied and the PDU is being processed by the transform. be applied and the PDU is being processed by the transform.
For example, after a tunnel mode ESP 3DES/SHA1 transform has been For example, after a tunnel mode ESP 3DES/SHA1 transform has been
applied an unencrypted or clear layer3 framesize of 46 bytes applied an unencrypted or clear layer3 framesize of 46 bytes
Becomes 96 bytes: Becomes 96 bytes:
20 bytes outer IP header (tunnel mode) 20 bytes outer IP header (tunnel mode)
4 bytes SPI (ESP header) 4 bytes SPI (ESP header)
4 bytes Sequence (ESP Header) 4 bytes Sequence (ESP Header)
8 bytes IV (IOS ESP-3DES) 8 bytes IV (IOS ESP-3DES)
46 bytes payload 46 bytes payload
skipping to change at page 36, line 18 skipping to change at page 35, line 33
Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2 Clear Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2 Clear
Framesize Framesize
9. Performance Metrics 9. Performance Metrics
9.1 Tunnels Per Second (TPS) 9.1 Tunnels Per Second (TPS)
Definition: Definition:
The measurement unit for the Tunnel Setup Rate tests. The rate The measurement unit for the IPsec Tunnel Setup Rate tests. The
that Tunnels are established per second. rate that IPsec Tunnels are established per second.
Discussion: Discussion:
According to [RFC2401] two tunnels cannot be established between According to [RFC2401] two IPsec Tunnels cannot be established
the same gateways with the same selectors. This is to prevent between the same gateways with the same selectors. This is to
overlapping tunnels. If overlapping tunnels are attempted, the prevent overlapping IPsec Tunnels. If overlapping IPsec Tunnels
error will take longer than if the tunnel setup was successful. are attempted, the error will cause the IPsec Tunnel setup time to
For this reason, a unique pair of selector sets are required for take longer than if the IPsec Tunnel setup was successful. For
TPS testing. this reason, a unique pair of selector sets are required for IPsec
Tunnel Setup Rate testing.
Issues: Issues:
A unique pair of selector sets are required for TPS testing. A unique pair of selector sets are required for TPS testing.
See Also: See Also:
Tunnel Setup Rate Behavior, Tunnel Setup Rate, IKE Setup Rate, Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate, IKE Setup
IPsec Setup Rate Rate, IPsec Setup Rate
9.2 Tunnel Rekeys Per Seconds (TRPS) 9.2 Tunnel Rekeys Per Seconds (TRPS)
Definition: Definition:
A metric that quantifies the number of IKE or IPsec Tunnel rekey's A metric that quantifies the number of IKE Phase 1 or Phase 2
per seconds a DUT can correctly process. rekey's per seconds a DUT can correctly process.
Discussion: Discussion:
This metric will be will be primary used with Tunnel Rekey This metric will be will be primary used with Tunnel Rekey
behavior tests. behavior tests.
TRPS will provide a metric used to see system behavior under TRPS will provide a metric used to see system behavior under
stressful conditions where large volumes of tunnels are being stressful conditions where large volumes of tunnels are being
rekeyed at the same time or in a short timespan. rekeyed at the same time or in a short timespan.
skipping to change at page 37, line 22 skipping to change at page 36, line 39
See Also: See Also:
Tunnel Rekey; Phase 1 Rekey Rate, Phase 2 Rekey Rate Tunnel Rekey; Phase 1 Rekey Rate, Phase 2 Rekey Rate
9.3 Tunnel Attempts Per Second (TAPS) 9.3 Tunnel Attempts Per Second (TAPS)
Definition: Definition:
A metric that quantifies the number of successful and unsuccessful A metric that quantifies the number of successful and unsuccessful
tunnel (both Phase 1 or Phase 2) establishment requests per IPsec Tunnel establishment requests per second.
second.
Discussion: Discussion:
This metric can be used to measure IKE DOS Resilience behavior This metric can be used to measure IKE DOS Resilience behavior
test. test.
TAPS provides an important metric to validate the stability of a TAPS provides an important metric to validate the stability of an
platform, if stressed with valid (large number of IPsec tunnel IPsec device, if stressed with valid (large number of IPsec tunnel
establishments per seconds or TPS) or invalid (IKE DOS attacks of establishments per seconds or TPS) or invalid (IKE DOS attacks of
any style) tunnel establishment requests. any style) tunnel establishment requests. IPsec Tunnel setups
offered to an IPsec devices can either fail due to lack of
resources in the IPsec device to proces all the requests or due to
an IKE DOS attack (usually the former is a result of the latter).
Issues: Issues:
If the TAPS increases, the TPS usually decreases, due to burdening If the TAPS increases, the TPS usually decreases, due to burdening
of the DUT with the DOS attack traffic. of the DUT with the DOS attack traffic.
10. Test Definitions 10. Test Definitions
10.1 Throughput 10.1 Throughput
10.1.1 Tunnel Throughput 10.1.1 IPsec 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 Throughput in [RFC1242], section 3.17. The only difference is
skipping to change at page 38, line 33 skipping to change at page 38, line 7
Packets per seconds (pps), Mbps Packets per seconds (pps), Mbps
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Encryption Throughput, IPsec Decryption Throughput IPsec Encryption Throughput, IPsec Decryption Throughput
10.1.2 IPsec Encryption Throughput 10.1.2 IPsec Tunnel Encryption Throughput
Definition: Definition:
The maximum encryption rate through an IPsec tunnel at which none The maximum encryption rate through an IPsec tunnel at which none
of the offered cleartext frames are dropped by the device under of the offered cleartext frames are dropped by the device under
test. test.
Discussion: Discussion:
Since encryption throughput is not necessarily equal to the Since encryption throughput is not necessarily equal to the
skipping to change at page 39, line 15 skipping to change at page 38, line 35
Measurement Units: Measurement Units:
Packets per seconds (pps), Mbps Packets per seconds (pps), Mbps
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Throughput, IPsec Decryption Throughput IPsec Tunnel Throughput, IPsec Tunnel Decryption Throughput
10.1.3 IPsec Decryption Throughput 10.1.3 IPsec Tunnel Decryption Throughput
Definition: Definition:
The maximum decryption rate through an IPsec tunnel at which none The maximum decryption rate through an IPsec tunnel at which none
of the offered encrypted frames are dropped by the device under of the offered encrypted frames are dropped by the device under
test. test.
Discussion: Discussion:
Since encryption throughput is not necessarily equal to the Since encryption throughput is not necessarily equal to the
skipping to change at page 39, line 47 skipping to change at page 39, line 21
Packets per seconds (pps), Mbps Packets per seconds (pps), Mbps
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also:
IPsec Tunnel Throughput, IPsec Encryption Throughput IPsec Tunnel Throughput, IPsec Tunnel Encryption Throughput
10.2 Latency 10.2 Latency
10.2.1 Tunnel Latency 10.2.1 IPsec Tunnel Latency
Definition: Definition:
Time required to propagate a cleartext frame from the input Time required to propagate a cleartext frame from the input
interface of an initiator, through an IPsec Tunnel, to the output interface of an initiator, through an 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
skipping to change at page 41, line 41 skipping to change at page 41, line 18
The IPsec Tunnel decryption Latency is the time interval starting The IPsec Tunnel decryption Latency is the time interval starting
when the end of the first bit of the encrypted frame reaches the when the end of the first bit of the encrypted frame reaches the
input interface, through an IPsec tunnel, and ending when the input interface, through an IPsec tunnel, and ending when the
start of the first bit of the decrypted output frame is seen on start of the first bit of the decrypted output frame is seen on
the output interface. the output interface.
Discussion: Discussion:
IPsec Tunnel decryption latency is the latency introduced when IPsec Tunnel decryption latency is the latency introduced when
decrypting traffic through an IPsec tunnel. Like decrypting traffic through an IPsec tunnel. Like encryption/
encryption/decryption throughput, it is not always the case that decryption throughput, it is not always the case that encryption
encryption latency equals the decryption latency. Therefore a latency equals the decryption latency. Therefore a distinction
distinction between the two has to be made in order to get a more between the two has to be made in order to get a more accurate
accurate view of where the latency is the most pronounced. view of where the latency is the most pronounced.
The independent encryption/decryption latencies have to be The independent encryption/decryption latencies have to be
measured with the help of an IPsec aware test device that can measured with the help of an IPsec aware test device that can
originate and terminate IPsec and IKE 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 43, line 12 skipping to change at page 42, line 38
N/A N/A
10.3 Frame Loss 10.3 Frame Loss
10.3.1 IPsec Tunnel Frame Loss 10.3.1 IPsec Tunnel Frame Loss
Definition: Definition:
Percentage of cleartext frames that should have been forwarded Percentage of cleartext frames that should have been forwarded
through a Tunnel under steady state (constant) load but were through an IPsec Tunnel under steady state (constant) load but
dropped before encryption or after decryption. were dropped before encryption or after decryption.
Discussion: Discussion:
The IPsec Tunnel Frame Loss is almost identically defined as Frame The IPsec Tunnel Frame Loss is almost identically defined as Frame
Loss Rate in [RFC1242], section 3.6. The only difference is that Loss Rate in [RFC1242], section 3.6. The only difference is that
the IPsec Tunnel Frame Loss Rate is measured with a traffic flow the IPsec Tunnel Frame Loss Rate is measured with a traffic flow
getting encrypted and decrypted by an IPsec device. IPsec Tunnel getting encrypted and decrypted by an IPsec device. IPsec Tunnel
Frame Loss Rate is an end-to-end measurement. Frame Loss Rate is an end-to-end measurement.
Measurement Units: Measurement Units:
skipping to change at page 43, line 41 skipping to change at page 43, line 23
See Also: See Also:
IPsec Tunnel Encryption Frame Loss, IPsec Tunnel Decryption Frame IPsec Tunnel Encryption Frame Loss, IPsec Tunnel Decryption Frame
Loss Loss
10.3.2 IPsec Tunnel Encryption Frame Loss 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
skipping to change at page 44, line 25 skipping to change at page 44, line 10
See Also: See Also:
IPsec Tunnel Frame Loss, IPsec Tunnel Decryption Frame Loss IPsec Tunnel Frame Loss, IPsec Tunnel Decryption Frame Loss
10.3.3 IPsec Tunnel Decryption Frame Loss 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
skipping to change at page 45, line 38 skipping to change at page 45, line 22
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 2 Rekey Rate 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 IPsec 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.
Discussion: Discussion:
The Tunnel Back-to-back Frames is almost identically defined as The Tunnel Back-to-back Frames is almost identically defined as
Back-to-back in [RFC1242], section 3.1. The only difference is Back-to-back in [RFC1242], section 3.1. The only difference is
that the Tunnel Back-to-back Frames is measured with a traffic that the Tunnel Back-to-back Frames is measured with a traffic
flow getting encrypted and decrypted by an IPsec device. Tunnel flow getting encrypted and decrypted by an IPsec device. IPsec
Back-to-back Frames is an end-to-end measurement. Tunnel Back-to-back Frames is an end-to-end measurement.
Measurement Units: Measurement Units:
Number of N-octet frames in burst. Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also:
Encryption Back-to-back frames, Decryption Back-to-back frames IPsec Tunnel Encryption Back-to-back frames, IPsec Tunnel
Decryption Back-to-back frames
10.4.2 Encryption Back-to-back Frames 10.4.2 IPsec Tunnel Encryption Back-to-back Frames
Definition: Definition:
A burst of cleartext frames, offered at a constant load that can A burst of cleartext frames, offered at a constant load that can
be sent through an IPsec tunnel without losing a single encrypted be sent through an IPsec Tunnel without losing a single encrypted
frame. frame.
Discussion: Discussion:
Encryption back-to-back frames is the measure of the maximum burst Encryption back-to-back frames is the measure of the maximum burst
size that a device can handle for encrypting traffic that it size that a device can handle for encrypting traffic that it
receives as plaintext. Since it is not necessarily the case that receives as plaintext. Since it is not necessarily the case that
the maximum burst size a DUT can handle for encryption is equal to the maximum burst size a DUT can handle for encryption is equal to
the maximum burst size a DUT can handle for decryption, both of the maximum burst size a DUT can handle for decryption, both of
these capabilities must be measured independently. The encryption these capabilities must be measured independently. The encryption
skipping to change at page 47, line 7 skipping to change at page 46, line 39
Number of N-octet frames in burst. Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also:
Tunnel Back-to-back frames, Decryption Back-to-back frames IPsec Tunnel Back-to-back frames, IPsec Tunnel Decryption Back-to-
back frames
10.4.3 Decryption Back-to-back Frames 10.4.3 IPsec Tunnel Decryption Back-to-back Frames
Definition: Definition:
The number of encrypted frames, offered at a constant load, that The number of encrypted frames, offered at a constant load, that
can be sent through an IPsec tunnel without losing a single can be sent through an IPsec Tunnel without losing a single
cleartext frame. cleartext frame.
Discussion: Discussion:
Decryption back-to-back frames is the measure of the maximum burst Decryption back-to-back frames is the measure of the maximum burst
size that a device can handle for decrypting traffic that it size that a device can handle for decrypting traffic that it
receives as encrypted traffic. Since it is not necessarily the receives as encrypted traffic. Since it is not necessarily the
case that the maximum burst size a DUT can handle for decryption case that the maximum burst size a DUT can handle for decryption
is equal to the maximum burst size a DUT can handle for is equal to the maximum burst size a DUT can handle for
encryption, both of these capabilities must be measured encryption, both of these capabilities must be measured
skipping to change at page 47, line 40 skipping to change at page 47, line 28
Number of N-octet frames in burst. Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also:
Tunnel Back-to-back frames, Encryption back-to-back frames IPsec Tunnel Back-to-back frames, IPsec Tunnel Encryption back-to-
back frames
10.5 Tunnel Setup Rate Behavior 10.5 Tunnel Setup Rate Behavior
10.5.1 Tunnel Setup Rate 10.5.1 Tunnel Setup Rate
Definition: Definition:
The maximum number of tunnels (1 IKE SA + 2 IPsec SA's) per second The maximum number of tunnels (1 IKE SA + 2 IPsec SA's) per second
that an IPsec device can successfully establish. that an IPsec device can successfully establish.
skipping to change at page 53, line 18 skipping to change at page 53, line 5
[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.
[RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP [RFC2393] Shacham, A., Monsour, R., Pereira, R., and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, December Payload Compression Protocol (IPComp)", RFC 2393,
1998. December 1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998. Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998. RFC 2402, November 1998.
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within [RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998. ESP and AH", RFC 2403, November 1998.
skipping to change at page 53, line 43 skipping to change at page 53, line 30
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher [RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998. Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998. Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of [RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998. Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet [RFC2408] Maughan, D., Schneider, M., and M. Schertler, "Internet
Security Association and Key Management Protocol Security Association and Key Management Protocol
(ISAKMP)", RFC 2408, November 1998. (ISAKMP)", RFC 2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998. (IKE)", RFC 2409, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and [RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998. Its Use With IPsec", RFC 2410, November 1998.
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security [RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998. Document Roadmap", RFC 2411, November 1998.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", [RFC2412] Orman, H., "The OAKLEY Key Determination Protocol",
RFC 2412, November 1998. RFC 2412, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher [RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547,
1999. March 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999. RFC 2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D. and P. Traina, [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
"Generic Routing Encapsulation (GRE)", RFC 2784, March Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
2000. 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",
Internet-Draft draft-ietf-ipsec-ikev2-17, October 2004. draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004.
[I-D.ietf-ipsec-dpd] [I-D.ietf-ipsec-dpd]
Huang, G., Beaulieu, S. and D. Rochefort, "A Traffic-Based Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic-
Method of Detecting Dead IKE Peers", Based Method of Detecting Dead IKE Peers",
Internet-Draft draft-ietf-ipsec-dpd-04, October 2003. 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",
Internet-Draft draft-ietf-ipsec-nat-t-ike-08, February draft-ietf-ipsec-nat-t-ike-08 (work in progress),
2004. February 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",
Internet-Draft draft-ietf-ipsec-udp-encaps-09, May 2004. draft-ietf-ipsec-udp-encaps-09 (work in progress),
May 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", Requirements", draft-ietf-ipsec-nat-reqts-06 (work in
Internet-Draft draft-ietf-ipsec-nat-reqts-06, October progress), October 2003.
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", Internet-Draft draft-ietf-ipsec-properties-02, Suite", draft-ietf-ipsec-properties-02 (work in progress),
July 2002. July 2002.
[FIPS.186-1.1998] [FIPS.186-1.1998]
National Institute of Standards and Technology, "Digital National Institute of Standards and Technology, "Digital
Signature Standard", FIPS PUB 186-1, December 1998, Signature Standard", FIPS PUB 186-1, December 1998,
<http://csrc.nist.gov/fips/fips1861.pdf>. <http://csrc.nist.gov/fips/fips1861.pdf>.
14.2 Informative References 14.2 Informative References
[Designing Network Security] [Designing Network Security]
skipping to change at page 56, line 4 skipping to change at page 55, line 36
Email: mbustos@ixiacom.com Email: mbustos@ixiacom.com
Tim Van Herck Tim Van Herck
Cisco Systems Cisco Systems
170 West Tasman Dr. 170 West Tasman Dr.
San Jose, CA 95134-1706 San Jose, CA 95134-1706
US US
Phone: +1 (408)527-2461 Phone: +1 (408)527-2461
Email: herckt@cisco.com Email: herckt@cisco.com
Merike Kaeo Merike Kaeo
Double Shot Security Double Shot Security
520 Washington Blvd #363 520 Washington Blvd #363
Marina Del Rey, CA 90292 Marina Del Rey, CA 90292
US US
Phone: +1 (310)866-0165 Phone: +1 (310)866-0165
Email: merike@doubleshotsecurity.com Email: kaeo@merike.com
Copyright (C) The Internet Society (2005). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights."
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Intellectual Property Statement Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; neither does it represent that it might or might not be available; nor does it represent that it has
has made any effort to identify any such rights. Information on the made any independent effort to identify any such rights. Information
IETF's procedures with respect to rights in standards-track and on the procedures with respect to rights in RFC documents can be
standards-related documentation can be found in BCP 11. Copies of found in BCP 78 and BCP 79.
claims of rights made available for publication and any assurances of
licenses to be made available, or the result of an attempt made to Copies of IPR disclosures made to the IETF Secretariat and any
obtain a general license or permission for the use of such assurances of licenses to be made available, or the result of an
proprietary rights by implementors or users of this specification can attempt made to obtain a general license or permission for the use of
be obtained from the IETF Secretariat. such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF at
Director. ietf-ipr@ietf.org.
Full Copyright Statement
Copyright (C) The Internet Society (2005). All Rights Reserved. Disclaimer of Validity
This document and translations of it may be copied and furnished to This document and the information contained herein are provided on an
others, and derivative works that comment on or otherwise explain it "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
or assist in its implementation may be prepared, copied, published OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
and distributed, in whole or in part, without restriction of any ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
kind, provided that the above copyright notice and this paragraph are INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
included on all such copies and derivative works. However, this INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
document itself may not be modified in any way, such as by removing WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be Copyright Statement
revoked by the Internet Society or its successors or assignees.
This document and the information contained herein is provided on an Copyright (C) The Internet Society (2005). This document is subject
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING to the rights, licenses and restrictions contained in BCP 78, and
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING except as set forth therein, the authors retain all their rights.
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 116 change blocks. 
376 lines changed or deleted 358 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/