[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]
Versions: 00 01 02 03 04 05 06 07 08 09 10 11
12
Network Working Group Michele Bustos
INTERNET-DRAFT IXIA
Expires in: August 2003 Tim Van Herck
Cisco
Merike Kaeo
Merike, Inc.
Terminology for Benchmarking IPsec Devices
<draft-ietf-bmwg-ipsec-term-00.txt>
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other
documents at any time. It is inappropriate to use Internet-Drafts
as reference material or to cite them other than as "work in
progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved.
Abstract
This purpose of this document is to define terminology specific to
measuring the performance of IPsec devices. It builds upon the
tenets set forth in RFC 1242, RFC 2544, RFC 2285 and other IETF
Benchmarking Methodology Working Group (BMWG) documents used for
benchmarking routers and switches. This document seeks to extend
these efforts specific to the IPsec paradigm. The BMWG produces
two major classes of documents: Benchmarking Terminology documents
and Benchmarking Methodology documents. The Terminology documents
present the benchmarks and other related terms. The Methodology
documents define the procedures required to collect the benchmarks
cited in the corresponding Terminology documents.
Bustos, Van Herck & Kaeo [Page 1]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Table of Contents
1. INTRODUCTION...................................................4
1.1. IPsec Fundamentals...........................................4
1.2. IPsec Operation..............................................6
1.2.1. Security Associations.....................................6
1.2.2. Key Management............................................6
1.2.3. Using the term 'Tunnel'...................................8
2. DOCUMENT SCOPE.................................................8
3. DEFINITION FORMAT..............................................8
4. KEY WORDS TO REFLECT REQUIREMENTS..............................9
5. EXISTING DEFINITIONS...........................................9
6. TERM DEFINITIONS..............................................10
6.1. IPsec.......................................................10
6.2. IPsec Device................................................10
6.3. ISAKMP......................................................11
6.4. IKE.........................................................11
6.5. Initiator...................................................12
6.6. Responder...................................................12
6.7. Security Association (SA)...................................13
6.8. IKE Phase 1.................................................13
6.8.1. Phase 1 Main Mode........................................13
6.8.2. Phase 1 Aggressive Mode..................................14
6.9. IKE Phase 2.................................................14
6.9.1. Phase 2 Quick Mode.......................................14
6.9.2. IPsec Tunnel.............................................15
6.10. Compound Tunnels...........................................15
6.10.1. Nested Tunnels...........................................15
6.10.2. Transport Adjacency......................................16
6.11. Transform Protocols........................................17
6.11.1. Authentication protocols.................................17
6.11.2. Encryption protocols.....................................17
6.12. IPsec Protocols............................................18
6.12.1. Authentication Header (AH)...............................18
6.12.2. Encapsulated Security Payload (ESP)......................18
6.13. Selectors..................................................19
6.14. NAT Traversal (NAT-T)......................................19
6.15. IP Compression.............................................20
6.16. Security Context...........................................20
6.17. Performance Metrics........................................21
6.17.1. Tunnels Per Second (TPS).................................21
6.17.2. Tunnel Flaps Per Second (TFPS)...........................21
6.17.3. Tunnels Attempted Per Second (TAPS)......................22
7. TEST TERMINOLOGY..............................................22
7.1. Framesizes..................................................22
7.1.1. Layer3 Clear Framesize...................................22
Bustos, Van Herck & Kaeo [Page 2]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
7.1.2. Layer3 Encrypted Framesize...............................22
7.1.3. Layer2 Clear Framesize...................................23
7.1.4. Layer2 encrypted framesize...............................24
7.2. Internet Mix Traffic (IMIX).................................24
7.3. Throughput..................................................25
7.3.1. IPsec Tunnel Throughput..................................25
7.3.2. IPsec Tunnel Encryption Throughput.......................25
7.3.3. IPsec Tunnel Decryption Throughput.......................26
7.4. Latency.....................................................26
7.4.1. IPsec Tunnel Encryption Latency..........................26
7.4.2. IPsec Tunnel Decryption Latency..........................27
7.4.3. Time To First Packet (TTFP)..............................28
7.5. Frame Loss Rate.............................................28
7.5.1. IPsec Tunnel Encryption Frame Loss Rate..................28
7.5.2. IPsec Tunnel Decryption Frame Loss Rate..................29
7.6. Back-to-Back................................................29
7.6.1. Encryption Back-to-Back Frames...........................29
7.6.2. Decryption Back-to-back frames...........................29
7.7. Tunnel Setup Rate Behavior..................................30
7.7.1. Tunnel Setup Rate........................................30
7.7.2. IKE Tunnel Setup Rate....................................30
7.7.3. IPsec Tunnel Setup Rate..................................31
7.8. Tunnel Rekey................................................31
7.8.1. Phase 1 Rekey Time.......................................31
7.8.2. Phase 2 Rekey Time.......................................31
7.9. Tunnel Flapping.............................................32
7.9.1. Tunnel Flap Rate.........................................32
7.10. Tunnel Failover Time (TFT).................................33
7.11. IKE DOS Resilience Rate....................................33
8. SECURITY CONSIDERATIONS.......................................34
9. ACKNOWLEDGEMENTS..............................................34
10. CONTRIBUTORS.................................................34
11. REFERENCES...................................................34
12. CONTACT INFORMATION..........................................37
13. FULL COPYRIGHT STATEMENT.....................................37
Bustos, Van Herck & Kaeo [Page 3]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
1. Introduction
Despite the need to secure communications over a public medium
there is no standard method of performance measurement nor a
standard in the terminology used to develop such hardware/software
solutions. This results in varied implementations which challenge
interoperability and direct performance comparisons. Standardized
IPsec terminology and performance test methodologies will enable
users to decide if the IPsec device they select will withstand
relatively heavy loads of secured traffic.
To appropriately define the parameters and scope of this document,
this section will give a brief overview of the IPsec standard.
1.1. IPsec Fundamentals
IPsec is a framework of open standards that provides data
confidentiality, data integrity, and data authentication between
participating peers. IPsec provides these security services at the
IP layer. IPsec uses IKE to handle negotiation of protocols 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 more data flows between a pair of hosts, between a pair of
security gateways, or between a security gateway and a host. The
IPsec protocol suite set of standards is documented in RFC's 2401
through 2412 and RFC 2451. The reader is assumed to be familiar
with these documents. Some Internet Drafts supersede these RFC's
and will be taken into consideration. Mainly it will encompass
current work in progress on NAT Traversal and updates to AH, ESP,
and IKE.
IPsec itself defines the following:
Authentication Header (AH):
A security protocol, defined in RFC 2402, which provides data
authentication and optional anti-replay services. AH ensures
the integrity and data origin authentication of the IP
datagram as well as the invariant fields in the outer IP
header.
Encapsulating Security Payload (ESP):
A security protocol, defined in RFC 2406, which provides
confidentiality, data origin authentication, connectionless
integrity, an anti-replay service and limited traffic flow
confidentiality. The set of services provided depends on
options selected at the time of Security Association (SA)
establishment and on the location of the implementation in a
network topology. ESP authenticates only headers and data
after the IP header.
Bustos, Van Herck & Kaeo [Page 4]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Internet Key Exchange (IKE):
A hybrid protocol which implements Oakley and SKEME key
exchanges inside the ISAKMP framework. While IKE can be used
with other protocols, its initial implementation is with the
IPsec protocol. IKE provides authentication of the IPsec
peers, negotiates IPsec security associations, and establishes
IPsec keys. Note that IKE is an optional protocol within the
IPsec framework and keys can also be manually configured.
The AH and ESP protocols each support two modes of operation:
transport mode and tunnel mode. In transport mode, two hosts
provide protection primarily for upper-layer protocols. The
cryptographic endpoints (where the encryption and decryption take
place) are the source and destination of the data packet. In IPv4,
a transport mode security protocol header appears immediately after
the IP header and before any higher-layer protocols (such as TCP or
UDP).
In the case of AH in transport mode, all upper-layer information is
protected, and all fields in the IPv4 header excluding the fields
typically are modified in transit. The fields of the IPv4 header
that are not included are, therefore, set to 0 before applying the
authentication algorithm. These fields are as follows:
o TOS
o TTL
o Header Checksum
o Offset
o Flags
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 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
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 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 outer header.
Bustos, Van Herck & Kaeo [Page 5]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
1.2. IPsec Operation
1.2.1. Security Associations
The concept of a Security Association (SA) is fundamental to IPsec.
An SA is a relationship between two or more entities that describes
how the entities will use security services to communicate
securely. The SA includes: an encryption algorithm, an
authentication algorithm and a shared session key.
Because an SA is unidirectional, two SAs (one in each direction)
are required to secure typical, bidirectional communication between
two entities. The security services associated with an SA can be
used for AH or ESP, but not for both. If both AH and ESP protection
is applied to a traffic stream, two (or more) SAs are created for
each direction to protect the traffic stream.
The SA is uniquely identified by the security parameter index (SPI)
[RFC2408]. When a system sends a packet that requires IPsec
protection, it looks up the SA in its database and applies the
specified processing and security protocol (AH/ESP), inserting the
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 address, protocol, and SPI and then processes the
packet as required.
1.2.2. Key Management
IPsec uses cryptographic keys for authentication/integrity and
encryption services. Both manual and automatic distribution of keys
is supported. IKE is specified as the public-key-based approach for
automatic key management.
IKE authenticates each peer involved in IPsec, negotiates the
security policy, and handles the exchange of session keys. IKE is a
hybrid protocol, combining parts of the following protocols to
negotiate and derive keying material for SAs in a secure and
authenticated manner:
o ISAKMP (Internet Security Association and Key Management
Protocol), which provides a framework for authentication and
key exchange but does not define them. ISAKMP is designed to
be key exchange independent; that is, it is designed to
support many different key exchanges.
o Oakley, which describes a series of key exchanges, called
modes, and details the services provided by each (for example,
perfect forward secrecy for keys, identity protection, and
authentication). [RFC 2412]
o SKEME (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that provides
anonymity, reputability, and quick key refreshment.
Bustos, Van Herck & Kaeo [Page 6]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
IKE creates an authenticated, secure tunnel between two entities
and then negotiates the security association for IPsec. This is
performed in two phases.
In Phase 1, the two unidirectional SA's establish a secure,
authenticated channel with which to communicate. Phase 1 has two
distinct modes; Main Mode and Aggressive Mode. Main Mode for Phase
1 provides identity protection. When identity protection is not
needed, Aggressive Mode can be used. The completion of Phase 1 an
IKE SA is established.
The following attributes are used by IKE and are negotiated as part
of the IKE SA:
o Encryption algorithm
o Hash algorithm
o Authentication method (can be digital signature, public-key
encryption, or pre-shared key)
o Information about a group on which to perform Diffie-
Hellman
After the attributes are negotiated, both parties must be
authenticated to each other. IKE supports multiple authentication
methods. At this time, the following mechanisms are generally
implemented:
o Preshared keys. The same key is pre-installed on each host.
IKE peers authenticate each other by computing and sending a
keyed hash of data that includes the preshared key. If the
receiving peer can independently create the same hash using
its preshared key, it knows that both parties must share the
same secret, and thus the other party is authenticated.
o Public key cryptography. Each party generates a pseudo-random
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 hash containing the other peer's nonce and ID, decrypted
with the local private key, authenticates the parties to each
other. This method does not provide nonrepudiation; either
side of the exchange could plausibly deny that it took part in
the exchange.
o Digital signature. Each device digitally signs a set of data
and sends it to the other party. This method is similar to
the public-key cryptography approach except that it provides
nonrepudiation.
Note that both digital signature and public-key cryptography
require the use of digital certificates to validate the
public/private key mapping. IKE allows the certificate to be
accessed independently or by having the two devices explicitly
exchange certificates as part of 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 session key.
In Phase 2 of the process, IPsec SAs are negotiated on behalf of
services such as IPsec AH or ESP. IPsec uses a different shared
Bustos, Van Herck & Kaeo [Page 7]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
key than does IKE. The IPsec shared key can be derived by using
Diffie-Hellman again or by refreshing the shared secret derived
from the original Diffie-Hellman exchange that generated the IKE SA
by hashing it with nonces. After this step is complete, the IPsec
SAs are established. Now the data traffic can be exchanged with
the negotiated IPsec parameters. The completion of Phase 2 is
called an IPsec SA.
1.2.3. Using the term 'Tunnel'
The term "tunnel" is often used in a variety of contexts. To avoid
any discrepancies, in this document we define the following
distinctions between the word "tunnel":
"IKE Tunnel": A bidirectional IKE Phase 1 SA, which is also
referred to as ISAKMP SA. It sets up a secure authenticated
"control channel" for further IKE communications.
"IPsec Tunnel": A bidirectional IKE Phase 2 SA, which is also
referred to as an IPsec SA. It creates the secure data exchange
channel.
"Tunnel": The combination of an IKE and an IPsec Tunnel
2. Document Scope
The primary focus of this document is to establish useful
performance testing terminology for IPsec devices. As such we want
to constrain the terminology specified in this document to meet the
requirements of the testing methodology. The testing will be
constrained to devices acting as IPsec gateways and will pertain to
both IPsec tunnel and transport mode.
What is specifically out of scope is any testing that pertains to
interoperability and/or conformance issues. Additionally, any
testing involving L2TP, GRE and 2547 (MPLS VPNs) is out of scope.
It is also out of scope to deal with anything that does not
specifically relate to the establishment and tearing down of IPsec
tunnels. It is assumed that all relevant networking parameters
that facilitate in the running of these tests are pre-configured
(this includes at a minimum ARP caches and routing tables).
Pertinent to IKEv2, NAT Traversal has been included in the
document, therefore NAT is not included in this document. All
references to IKE connotate the inclusion of IKEv2 as well.
3. Definition Format
The definition format utilized by this document is described in RFC
1242, Section 2.
Term to be defined.
Bustos, Van Herck & Kaeo [Page 8]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Definition:
The specific definition for the term.
Discussion:
A brief discussion of the term, its application, or other
information that would build understanding.
[Measurement units:]
Units used to record measurements of this term. This field is
mandatory where applicable. This field is optional in this
document.
[Issues:]
List of issues or conditions that affect this term. This field
can present items the may impact the term's related
methodology or otherwise restrict its measurement procedures.
This field is optional in this document.
[See Also:]
List of other terms that are relevant to the discussion of
this term. This field is optional in this document.
4. Key Words to Reflect Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL"
in this document are to be interpreted as described in RFC 2119.
RFC 2119 defines the use of these key words to help make the intent
of standards track documents as clear as possible. While this
document uses these keywords, this document is not a standards
track document.
5. Existing Definitions
It is recommended that readers consult RFCs 1242, 2544 and 2285
before making use of this document. These and other IETF
Benchmarking Methodology Working Group (BMWG) router and switch
documents contain several existing terms relevant to benchmarking
the performance of IPsec devices. The conceptual framework
established in these earlier RFCs will be evident in this document.
This document also draws on existing terminology defined in other
BMWG documents. Examples include, but are not limited to:
Throughput [RFC 1242, section 3.17]
Latency [RFC 1242, section 3.8]
Frame Loss Rate [RFC 1242, section 3.6]
Forwarding Rates [RFC 2285, section 3.6]
Loads [RFC 2285, section 3.5]
Note: "DUT/SUT" refers to a metric that may be applicable to a DUT
(Device Under Test) or an SUT (System Under Test).
Bustos, Van Herck & Kaeo [Page 9]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
6. Term Definitions
6.1. IPsec
Definition:
IP Security protocol suite which comprises a set of standards
used to provide privacy and authentication services at the IP
layer.
Discussion:
TBD
Issues:
See Also:
6.2. IPsec Device
Definition:
Any implementation that has the ability to process data flows
according to the IPsec protocol suite specifications.
Discussion:
Implementations come in many forms and shapes. Not only can
they be grouped by 'external' properties (e.g. software vs.
hardware implementations) but more important is the subtle
differences that implementations may have with relation to the
IPsec Protocol Suite. Not all implementations will cover all
RFCs that encompass the IPsec Protocol Suite, but the majority
will support a large subset of features described in the
suite.
In that context, any implementation, that supports basic IP
layer security services as described in the IPsec protocol
suite shall be called an æIPsec Device'.
Issues:
Due to the fragmented nature of the IPsec Protocol Suite RFCs,
it is not unlikely that IPsec implementations will not be able
to interoperate. Therefore it is important to know which
features and options are implemented in the IPsec Device.
See Also:
IPsec
Bustos, Van Herck & Kaeo [Page 10]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
6.3. ISAKMP
Definition:
The Internet Security Association and Key Management Protocol,
which provides a framework for authentication and key exchange
but does not define them. ISAKMP is designed to be key
exchange independent; that is, it is designed to support many
different key exchanges. ISAKMP is defined in RFC 2407.
Discussion:
TBD
Issues:
See Also:
IKE
6.4. IKE
Definition:
A hybrid protocol, defined in RFC 2409, from the following 3
protocols:
o ISAKMP (Internet Security Association and Key Management
Protocol), which provides a framework for authentication
and key exchange but does not define them. ISAKMP is
designed to be key exchange independent; that is, it is
designed to support many different key exchanges.
o Oakley, which describes a series of key exchanges, called
modes, and details the services provided by each (for
example, perfect forward secrecy for keys, identity
protection, and authentication). [RFC 2412]
o SKEME (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that
provides anonymity, reputability, and quick key
refreshment.
Discussion:
TBD
Issues:
During the first IPsec deployment experiences, many
ambiguities were found in the original IKE specification,
which lead to many interoperability problems. To resolve these
issues, there is an ongoing effort to simplify the current IKE
protocol and remove all unused features and options. This
effort manifests itself in a new IKE version, called IKEv2.
IKEv2 is an updated version of the current IKE stack and is
code preserving a compatible with IKEv1.
See Also:
ISAKMP, Ipsec
Bustos, Van Herck & Kaeo [Page 11]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
6.5. Initiator
Definition:
IPsec devices which start the negotiation of IKE Phase 1 and
IKE Phase 2 tunnels.
Discussion:
When a traffic flow is offered at an IPSec device and it is
determined that the flow must be protected, but there is no
active tunnel yet, it is the responsibility of the IPSec
device to start a negotiation process. This process will
establish an IKE Phase 1 SA and one or more IKE phase 2 SA_s,
eventually resulting in secured data transport. The device
that takes the action to start this negotiation process will
be called an Initiator.
Issues:
IPSec devices/implementations can always be both an initiator
as well as a responder. The distinction is useful only from a
test perspective.
See Also:
Responder
6.6. Responder
Definition:
IPsec devices which reply to the incoming initiators IKE Phase
1 and Phase 2 tunnel requests and process these messages in
order to establish a tunnel.
Discussion:
When an initiator attempts to establish SAs with another IPsec
device, this peer will need to evaluate the proposals made by
the initiator and either accept or deny them. In the former
case, the traffic flow will be decrypted according to the
negotiated parameters. Such a device will be called a
Responder_.
Issues:
IPSec devices/implementations can usually be both an initiator
as well as a responder. The distinction is useful only from a
test perspective.
Bustos, Van Herck & Kaeo [Page 12]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
See Also:
Initiator
6.7. Security Association (SA)
Definition:
A simplex (unidirectional) logical connection, created for
security purposes. All traffic traversing an SA is provided
the same security processing. In IPsec, an SA is an Internet
layer abstraction implemented through the use of AH or ESP.
[RFC 2401]
Discussion:
A set of policy and key(s) used to protect information. It is
a negotiation agreement between two IPsec devices,
specifically the Initiator and Responder.
Issues:
See Also:
6.8. IKE Phase 1
Definition:
The shared policy and key(s) used by negotiating peers to set
up a secure authenticated "control channel" for further IKE
communications.
Discussion:
TBD
Issues:
In other documents also referenced as ISAKMP SA or IKE SA.
See Also:
IKE, ISAKMP
6.8.1. Phase 1 Main Mode
Definition:
Main Mode is an instantiation of the ISAKMP Identity Protect
Exchange, defined in RFC 2409.
Discussion:
IKE Main Mode uses 3 separate message exchanges, for a total
of 6 messages. The first two messages negotiate policy; the
next two exchange Diffie-Hellman public values and ancillary
Bustos, Van Herck & Kaeo [Page 13]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
data (e.g. nonces necessary for the exchange); and the last
two messages authenticate the Diffie-Hellman Exchange. The
authentication method negotiated as part of the initial IKE
Phase 1 exchange influences the composition of the payloads
but not their purpose.
Issues:
See Also:
IKE, IKE Phase 1, Phase 1 Aggressive Mode
6.8.2. Phase 1 Aggressive Mode
Definition:
Aggressive Mode is an instantiation of the ISAKMP Aggressive
Exchange, defined in RFC 2409.
Discussion:
IKE Aggressive Mode uses 3 messages. The first two messages
negotiate policy, exchange Diffie-Hellman public values and
ancillary data necessary for the exchange, and identities. In
addition the second message authenticates the Responder. The
third message authenticates the Initiator and provides a proof
of participation in the exchange.
Issues:
See Also:
IKE, IKE Phase 1, Phase 1 Main Mode
6.9. IKE Phase 2
Definition:
Discussion:
TBD
Issues:
See Also:
6.9.1. Phase 2 Quick Mode
Definition
A SA negotiation and an exchange of nonces that provide replay
protection.
Discussion:
Quick Mode is not a complete exchange itself (in that it is
bound to a phase 1 exchange), but is used as part of the SA
Bustos, Van Herck & Kaeo [Page 14]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
negotiation process (phase 2) to derive keying material and
negotiate shared policy for non-ISAKMP SA's. The ISAKMP SA
protects the information exchanged along with Quick Mode, i.e.
all payloads except the ISAKMP header are encrypted. Also, an
optional Key Exchange payload can be exchanged to allow for an
additional Diffie-Hellman exchange and exponentiation per
Quick Mode.
Issues:
See Also:
6.9.2. IPsec Tunnel
Definition:
A bidirectional IPsec SA that is set up as part of IKE phase
2. It creates the secure data exchange channel.
Discussion:
Manually established IPsec tunnels do exist, however, from a
benchmarking perspective, they do not differ from IPsec
tunnels that are negotiated by IKE. Note that some metrics
will not be applicable due to the limited use of manually
established IPsec tunnels.
Issues:
See Also:
6.10. Compound Tunnels
6.10.1. Nested Tunnels
Definition:
An SA bundle consisting of two or more 'tunnel mode' SAs.
Discussion:
The process of nesting tunnels can theoretically be repeated
multiple times (for example, tunnels can be many levels deep),
but for all practical purposes, most implementations limit the
level of nesting.
Bustos, Van Herck & Kaeo [Page 15]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Nested tunnels can use a mix of AH and ESP encapsulated
traffic.
[GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
| | | |
| | | |
| +----{SA1 (ESP tunnel)}----+ |
| |
+--------------{SA2 (AH tunnel)}---------------+
In the IP Cloud a packet would have a format like this:
[IP{2,3}][ESP][IP{1,4}][AH][IP][PAYLOAD][ESP TR][ESP AUTH]
Nested tunnels can be deployed to provide additional security
on already protected traffic. For example, the inner gateways
(GW2 & GW3) are securing traffic between two branch offices
and the outer gateways (GW1 & GW4) add an additional layer of
security between departments within those branch offices.
Issues:
See Also:
Transport adjacency, IPsec Tunnel
6.10.2. Transport Adjacency
Definition:
An SA bundle consisting of two or more transport mode SAs.
Discussion:
Transport adjacency is a form of tunnel nesting. In this case
two or more transport mode IPsec tunnels are set side by side
to enhance applied security properties.
Transport adjacency can be used with a mix of AH and ESP
tunnels although some combinations are not preferred. If AH
and ESP are mixed, the ESP tunnel should always encapsulate
the AH tunnel. The reverse combination is a valid combination
but doesn't make cryptographical sense.
[GW1] --- [GW2] ---- [IP CLOUD] ---- [GW3] --- [GW4]
| | | |
| | | |
| +--{SA1 (ESP transport)}---+ |
| |
+-------------{SA2 (AH transport)}-------------+
Bustos, Van Herck & Kaeo [Page 16]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
In the IP cloud a packet would have a format like this:
[IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH]
Issues:
See Also:
Nested tunnels, IPsec Tunnel
6.11. Transform Protocols
Definition:
Encryption and authentication algorithms that provide
cryptograhical services to the IPsec Protocols.
Discussion:
TBD
Issues:
See Also:
Authentication protocols, Encryption protocols
6.11.1. Authentication protocols
Definition:
Algorithms which provide data integrity and data source
authentication.
Discussion:
Authentication protocols provide no confidentiality. Commonly
used authentication algorithms/protocols are:
o MD5-HMAC
o SHA-HMAC
o AES-HMAC
Issues:
See Also:
Transform protocols, Encryption protocols
6.11.2. Encryption protocols
Definition:
Algorithms which provide data confidentiality.
Bustos, Van Herck & Kaeo [Page 17]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Discussion:
Encryption protocols provide no authentication. Commonly used
encryption algorithms/protocols are:
o NULL encryption
o DES-CBC
o 3DES-CBC
o AES-CBC
Issues:
See Also:
Transform protocols, Authentication protocols
6.12. IPsec Protocols
6.12.1. Authentication Header (AH)
Definition:
Provides authentication and data integrity (including replay
protection) security services [RFC2402].
Discussion:
Original IPv4 packet:
[IP ORIG][L4 HDR][PAYLOAD]
In transport mode:
[IP ORIG][AH][L4 HDR][PAYLOAD]
In tunnel mode:
[IP NEW][AH][IP ORIG][L4 HDR][PAYLOAD]
Issues:
See Also:
Transform protocols, IPsec protocols, Encapsulated Security
Payload
6.12.2. Encapsulated Security Payload (ESP)
Definition:
Provides three essential components needed for secure data
exchange: authentication, integrity (including replay
protection) and confidentiality [RFC2406].
Discussion:
Original IPv4 packet:
[IP ORIG][L4 HDR][PAYLOAD]
In transport mode:
[IP ORIG][ESP][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH]
Bustos, Van Herck & Kaeo [Page 18]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
In tunnel mode:
[IP NEW][ESP][IP ORIG][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH]
Issues:
See Also:
Transform protocols, IPsec protocols, Authentication Header
6.13. Selectors
Definition:
A mechanism required to classify traffic flows when IPsec is
used to protect traffic between networks which are proxied
between two or more participating peers. After
classification, a decision can be made if the traffic needs to
be encrypted/decrypted and how this should be done.
Discussion:
The selectors are a set of fields that will be extracted from
the network and transport layer headers that provide the
ability to classify the traffic flow and later associate it
with an SA.
Issues:
See Also:
6.14. NAT Traversal (NAT-T)
Definition:
The capability to support IPsec functionality in the presence
of NAT devices.
Discussion:
NAT-Traversal requires some modifications to IKE.
Specifically, in phase 1, it requires detecting if the other
end supports NAT-Traversal, and detecting if there are one or
more NAT instances along the path from host to host. In IKE
Quick Mode, there is a need to negotiate the use of UDP
encapsulated IPsec packets.
NAT-T also describes how to transmit the original source and
destination addresses to the other end if needed. The
original source and destination addresses are used in
transport mode to incrementally update the TCP/IP checksums so
that they will match after the NAT transform (The NAT cannot
do this, because the TCP/IP checksum is inside the UDP
encapsulated IPsec packet).
Issues:
Bustos, Van Herck & Kaeo [Page 19]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
See Also:
IKE
6.15. IP Compression
Definition:
TBD [IPPCP RFC2393]
Discussion:
TBD
Issues:
See Also:
6.16. Security Context
Definition:
A security context is a collection of security parameters that
describe the characteristics of the path that a tunnel will
take, all of the tunnel parameters and the effects it has on
the underlying protected traffic. Security Context
encompasses protocol suite and security policy(ies).
Discussion:
In order to fairly compare multiple IPsec devices it is
imperative that an accurate overview is given of all security
parameters that were used to establish tunnels and to secure
the traffic between protected networks. To avoid listing to
much information when reporting metrics we have divided the
security context into an IKE context and an IPsec context.
When merely discussing the behavior of traffic flows through
IPsec devices, an IPsec context MUST be provided. In other
cases the scope of a discussion or report may focus on a more
broad set of behavioral characteristics of the IPsec device,
the both and IPsec and an IKE context MUST be provided.
The IPsec context MUST consist of the following elements:
o Number of active IPsec tunnels
o IPsec tunnels per IKE tunnel (IKE/IPsec tunnel ratio)
o IPsec protocol
o IPsec mode (tunnel or transport)
o Authentication protocol used by IPsec
o Encryption protocol used by IPsec (if applicable)
o IPsec SA lifetime (traffic and time based)
Bustos, Van Herck & Kaeo [Page 20]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
The IPsec context MAY also list:
o Selectors
o Fragmentation handling
The IKE context MUST consist of the following elements:
o Number of active IKE tunnels.
o Authentication protocol used by IKE
o Encryption protocol used by IKE
o Key exchange mechanism (pre-shared key, Certificate,
etc)
o Key size (if applicable)
o Diffie-Hellman group
o IKE SA lifetime (time based)
o Keepalive, heartbeat or DPD values
o Compression (IPPCP RFC2393)
o PFS Diffie-Hellman group
The IKE context MAY also list:
o Phase 1 mode (main or aggressive)
o Available bandwidth and latency to Certificate
Authority server (if applicable)
Issues:
A Security Context will be an important element in describing
the environment where protected traffic is traveling through.
See Also:
IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase
2, Selectors, IPsec Tunnel
6.17. Performance Metrics
6.17.1. Tunnels Per Second (TPS)
Definition:
TBD
Discussion:
TBD
Issues:
See Also:
6.17.2. Tunnel Flaps Per Second (TFPS)
Definition:
TBD
Discussion:
Bustos, Van Herck & Kaeo [Page 21]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
TBD
Issues:
See Also:
6.17.3. Tunnels Attempted Per Second (TAPS)
Definition:
TBD
Discussion:
TBD
Issues:
See Also:
7. Test Terminology
7.1. Framesizes
7.1.1. Layer3 Clear Framesize
Definition:
The total size of the unencrypted L3 PDU.
Discussion:
In relation to IPsec this is the size of the IP header and
its payload. It SHALL NOT include any encapsulations that MAY
be applied before the PDU is processed for encryption. For
example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload.
Measurement units:
Bytes
Issues:
See Also:
Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2
Encrypted Framesize.
7.1.2. Layer3 Encrypted Framesize
Definition:
The total size of the encrypted L3 PDU.
Discussion:
Bustos, Van Herck & Kaeo [Page 22]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
The size of the IP packet and its payload after encapsulations
MAY be applied and the PDU is being processed by the
transform. For example, after a tunnel mode ESP 3DES/SHA1
transform has been applied, an unencrypted or clear Layer3
framesize of 46 bytes becomes 96 bytes:
20 bytes outer IP header (tunnel mode)
4 bytes SPI (ESP header)
4 bytes Sequence (ESP Header)
8 bytes IV (IOS ESP-3DES)
46 bytes payload
0 bytes pad (ESP-3DES 64 bit)
1 byte Pad length (ESP Trailer)
1 byte Next Header (ESP Trailer)
12 bytes ESP-HMAC SHA1 96 digest
Measurement units:
Bytes
Issues:
See Also:
Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2
Encrypted Framesize.
7.1.3. Layer2 Clear Framesize
Definition:
The total size of the unencrypted L2 PDU.
Discussion:
This is the Layer 3 clear framesize plus the entire layer2
overhead. In the case of Ethernet this would be 18 bytes.
For example, a 46 byte Layer3 clear framesize packet would
become 64 bytes after Ethernet Layer2 overhead is added:
6 bytes destination MAC address
6 bytes source MAC address
2 bytes length/type field
46 bytes layer3 (IP) payload
4 bytes FCS
Measurement units:
Bytes
Issues:
If it is not mentioned explicitly what kind of framesize is
used, the layer2 clear framesize will be the default.
See Also:
Layer3 clear framesize, Layer2 encrypted framesize, Layer2
encrypted framesize.
Bustos, Van Herck & Kaeo [Page 23]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
7.1.4. Layer2 encrypted framesize
Definition:
The total size of the encrypted L2 PDU.
Discussion:
This is the Layer 3 encrypted framesize plus all the Layer2
overhead. In the case of Ethernet this would be 18 bytes. For
example, a 96 byte Layer3 encrypted framesize packet would
become 114 bytes after Ethernet Layer2 overhead is added:
6 bytes destination mac address
6 bytes source mac address
2 bytes length/type field
96 bytes layer3 (IPsec) payload
4 bytes FCS
Measurement units:
Bytes
Issues:
See Also:
Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2
Clear Framesize
7.2. Internet Mix Traffic (IMIX)
Definition:
A traffic pattern consisting of a preset mixture of framesizes
used to emulate real-world traffic scenarios in a testing
environment.
Discussion:
IMIX traffic patterns can be used to measure different
forwarding behaviors of the IPsec device with pseudo live
traffic.
Several facilities, including the National Laboratory for
Applied Network Research, have collected and reported traffic
distribution by monitoring live Internet links. The study
concluded that in a simulation environment, a small mix of
packets in a preset ratio can resemble to a certain degree the
live traffic that was monitored during the study. One of the
mixes is called (simple) IMIX and consists of 7 parts 64 byte
packets, 4 parts 570 byte packets and 1 1518 byte
packet.[IMIX]
Measurement units:
TBD
Bustos, Van Herck & Kaeo [Page 24]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Issues:
The ratio of frame sizes sent and traffic distribution to be
determined by the test methodology.
See Also:
7.3. Throughput
7.3.1. IPsec Tunnel Throughput
Definition:
The forwarding rate through an established IKE/IPsec tunnel at
which none of the offered frames are dropped by the device
under test.
Discussion:
The IPsec Tunnel Throughput is almost identically defined as
Throughput in RFC 1242, section 3.17. The only difference is
that the throughput is measured with a traffic flow that is
getting encrypted and decrypted by an IPsec device. The
Tunnel Throughput is an end-to-end measurement and is intended
to characterize end-user forwarding behavior.
The metric can be represented in two variants depending on
where the in the SUT the measurement is taken. One can look
at throughput from a cleartext point of view i.e. find the
forwarding rate where clearpackets no longer get dropped.
This forwarding rate can be recalculated with an encrypted
framesize to represent the encryption forwarding rate. The
latter is the preferred method of representation.
Measurement units:
Packets per seconds (pps), Mbps
Issues:
See Also:
7.3.2. IPsec Tunnel Encryption Throughput
Definition:
The maximum encryption rate through an established IPsec
tunnel at which none of the offered cleartext frames are
dropped by the device under test.
Discussion:
Since it is not necessarily the case that the encryption
throughput is equal to the decryption throughput, both of the
forwarding rates must be measured independently.
Bustos, Van Herck & Kaeo [Page 25]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
The independent forwarding rates have to be measured with the
help of an IPsec aware test device that can originate and
terminate IPsec and IKE tunnels. As defined in RFC 1242,
measurements should be taken with an assortment of frame
sizes.
Measurement units:
Packets per seconds (pps), Mbps
Issues:
See Also:
7.3.3. IPsec Tunnel Decryption Throughput
Definition:
The maximum decryption rate through an established IPsec
tunnel at which none of the offered encrypted frames are
dropped by the device under test.
Discussion:
Since it is not necessarily the case that the encryption
throughput is equal to the decryption throughput, both of the
forwarding rates must be measured independently.
The independent forwarding rates have to be measured with the
help of an IPsec aware test device that can originate and
terminate IPsec tunnels. As defined in RFC 1242, measurements
should be taken with an assortment of frame sizes.
Measurement units:
Packets per seconds (pps), Mbps
Issues:
Recommended test frame sizes will be addressed in future
methodology document.
See Also:
7.4. Latency
7.4.1. IPsec Tunnel Encryption Latency
Definition:
The IPsec Tunnel Encryption Latency is the time interval
starting when the end of the first bit of the cleartext frame
reaches the input interface, through an established IPsec
tunnel, and ending when the start of the first bit of the
encrypted output frame is seen on the output interface.
Bustos, Van Herck & Kaeo [Page 26]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Discussion:
IPsec Tunnel Encryption latency is the latency that is
introduced when encrypting traffic through an established
IPsec tunnel.
Like encryption/decryption throughput, it is not always the
case that encryption latency equals the decryption latency.
Therefore a distinction between the two has to be made in
order to get a more accurate view of where the latency is the
most pronounced.
The independent encryption/decryption latencies have to be
measured with the help of an IPsec aware test device that can
originate and terminate IPsec and IKE tunnels. As defined in
RFC 1242, measurements should be taken with an assortment of
frame sizes.
Measurement units:
Time units with enough precision to reflect latency
measurement.
Issues:
See Also:
7.4.2. IPsec Tunnel Decryption Latency
Definition:
The IPsec Tunnel decryption Latency is the time interval
starting when the end of the first bit of the encrypted frame
reaches the input interface, through an established IPsec
tunnel, and ending when the start of the first bit of the
decrypted output frame is seen on the output interface.
Discussion:
IPsec Tunnel decryption latency is the latency that is
introduced when decrypting traffic through an established
IPsec tunnel. Like encryption/decryption throughput, it is
not always the case that encryption latency equals the
decryption latency. Therefore a distinction between the two
has to be made in order to get a more accurate view of where
the latency is the most pronounced.
The independent encryption/decryption latencies have to be
measured with the help of an IPsec aware test device that can
originate and terminate IPsec and IKE tunnels. As defined in
RFC 1242, measurements should be taken with an assortment of
frame sizes.
Bustos, Van Herck & Kaeo [Page 27]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Measurement units:
Time units with enough precision to reflect latency
measurement.
Issues:
See Also:
7.4.3. Time To First Packet (TTFP)
Definition:
The Time To First Packet (TTFP) is the time required to
process a cleartext packet when no tunnel is present.
Discussion:
The TTFP addresses the issue of responsiveness of an IPsec
device by looking how long it take to transmit a packet over a
not yet established tunnel path. The TTFP MUST include the
time to set up the tunnel that is triggered by the traffic
flow (both phase 1 and phase 2 setup times are included) and
the time it takes to encrypt and decrypt the packet on a
corresponding peer.
It must be noted that it is highly unlikely that the first
packet of the traffic flow will be the packet that will be
used to measure the TTFP. There MAY be several protocol
layers in the stack before the tunnel is formed. Traffic is
forwarded and several packets could be lost during
negotiation, for example, ARP and/or IKE.
Measurement units:
Time units with enough precision to reflect a TTFP
measurement.
Issues:
See Also:
7.5. Frame Loss Rate
7.5.1. IPsec Tunnel Encryption Frame Loss Rate
Definition:
Percentage of cleartext frames that should have been encrypted
through an established IPsec tunnel under steady state
(constant)load but were dropped.
Discussion:
TBD
Bustos, Van Herck & Kaeo [Page 28]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Measurement units:
Percent (%)
Issues:
See Also:
7.5.2. IPsec Tunnel Decryption Frame Loss Rate
Definition:
Percentage of encrypted frames that should have been decrypted
through an established IPsec tunnel under steady state
(constant)load but were dropped.
Discussion:
TBD
Measurement units:
Percent (%)
Issues:
See Also:
7.6. Back-to-Back
7.6.1. Encryption Back-to-Back Frames
Definition:
The number of cleartext frames, offered at a constant load
that can be sent through an established IPsec tunnel without
losing a single encrypted frame.
Discussion:
TBD
Measurement units:
Frames
Issues:
See Also:
Decryption Back-to-back frames
7.6.2. Decryption Back-to-back frames
Bustos, Van Herck & Kaeo [Page 29]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Definition:
The number of encrypted frames, offered at a constant load,
that can be sent through an established IPsec tunnel without
losing a single cleartext frame.
Discussion:
TBD
Measurement units:
Frames
Issues:
See Also:
Encryption back-to-back frames
7.7. Tunnel Setup Rate Behavior
7.7.1. Tunnel Setup Rate
Definition:
The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per
second that an IPsec device can successfully establish.
Discussion:
The tunnel setup rate SHOULD be measured at varying number of
established tunnels on the DUT.
Measurement units:
Tunnels per second (TPS)
Issues:
See Also:
7.7.2. IKE Tunnel Setup Rate
Definition:
The maximum number of IKE tunnels per second that an IPsec
device can be observed to successfully establish.
Discussion:
The tunnel setup rate SHOULD be measured at varying number of
established tunnels on the DUT.
Measurement units:
Tunnels per second (TPS)
Issues:
Bustos, Van Herck & Kaeo [Page 30]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
See Also:
Rekey Time
7.7.3. IPsec Tunnel Setup Rate
Definition:
The maximum number of IPsec tunnels per second that a IPsec
device can be observed to successfully establish.
Discussion:
The tunnel setup rate SHOULD be measured at varying number of
established tunnels on the DUT.
Measurement units:
Tunnels per second (TPS)
Issues:
See Also:
Tunnel Rekey
7.8. Tunnel Rekey
7.8.1. Phase 1 Rekey Time
Definition:
The interval necessary for a particular Phase 1 to re-
establish after the previous Phase 1 lifetime [hard or soft]
has expired.
Discussion:
TBD
Measurement units:
Time units with enough precision to reflect rekey time
measurement.
Issues:
See Also:
Phase 2 Rekey Time, Tunnel Flapping
7.8.2. Phase 2 Rekey Time
Definition:
The interval necessary for a particular Phase 2 to re-
establish after the previous Phase 2 lifetime [hard or soft]
has expired.
Bustos, Van Herck & Kaeo [Page 31]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Discussion:
TBD
Measurement units:
Time units with enough precision to reflect rekey time
measurement.
Issues:
See Also:
Phase 1 Rekey Time , Tunnel Flapping
7.9. Tunnel Flapping
Definition:
A behavior observed where a tunnel is dropped and then re-
established with the same parameters.
Discussion:
TBD
Measurement units:
TBD
Issues:
See Also:
Phase 1 Rekey Time, Phase 2 Rekey Time
7.9.1. Tunnel Flap Rate
Definition:
The number of times per second a tunnel is dropped and re-
established.
Discussion:
TBD
Measurement units:
Tunnel flaps per second (TFPS)
Issues:
See Also:
Phase 1 Rekey Time, Phase 2 Rekey Time
Bustos, Van Herck & Kaeo [Page 32]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
7.10. Tunnel Failover Time (TFT)
Definition:
Recovery time required to re-establish all tunnels on a
standby node or other failsafe system after a tunnel failing
event has occurred, such as a catastrophic IPsec device
failure, including all traffic that previously ran through
those tunnels. The recovery time is delta between the point
of failure and when the first packet is seen on the last
restored tunnel on the backup device.
Discussion:
TBD
Measurement units:
Tunnel flaps per second (TFPS)
Issues:
See Also:
Tunnel Flapping
7.11. IKE DOS Resilience Rate
Definition:
The IKE Denial Of Service (DOS) Resilience Rate provides a
rate of invalid or mismatching IKE tunnels setup attempts at
which it is no longer possible to set up a valid IKE tunnel.
Discussion:
The IKE DOS Resilience Rate will provide a metric to how
robust and hardened an IPsec device is against malicious
attempts to set up a tunnel.
IKE DOS attacks can pose themselves in various forms and do
not necessarily have to have a malicious background. It is
sufficient to make a typographical error in a shared secret in
an IPsec aggregation device to be susceptible to a large
number of IKE attempts that need to be turned down. Due to
the intense computational nature of an IKE exchange every
single IKE tunnel attempt that has to be denied will take a
non-negligible time an a CPU in the IPsec device.
Depending on how many of these messages have to be processed,
a system might end up in a state that it is only doing key
exchanges and burdening the CPU for any other processes that
might be running in the IPsec device. At this point it will
be no longer be possible to process a valid IKE tunnel setup
request and thus IKE DOS is in effect.
Bustos, Van Herck & Kaeo [Page 33]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
Measurement units:
Tunnel attempts per second (TAPS)
Issues:
See Also:
8. Security Considerations
As this document is solely for the purpose of providing test
benchmarking terminology and describes neither a protocol nor a
protocol's implementation; there are no security considerations
associated with this document.
9. Acknowledgements
The authors would like to acknowledge the following individual for
their help and participation of the compilation and editing of this
document û Debby Stopp, Ixia.
10. Contributors
The authors would like to acknowledge the following individual for
their help and contributions to this document û Sunil Kalidindi,
Ixia.
11. References
Normative References
[RFC1242] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2285] Mandeville, R., "Benchmarking Terminology for LAN
Switching Devices", RFC 2285, February 1998.
[RFC2393] Shacham, A., Monsour, R., Pereira, R. and M. Thomas, "IP
Payload Compression Protocol (IPComp)", RFC 2393, December
1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC
2402, November 1998.
Bustos, Van Herck & Kaeo [Page 34]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2408] Maughan, D., Schneider, M. and M. Schertler, "Internet
Security Association and Key Management Protocol(ISAKMP)", RFC
2408, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2412] Orman, H., "The OAKLEY Key Determination Protocol", RFC
2412, November 1998.
[RFC2451] Pereira, R. and R. Adams, "The ESP CBC-Mode Cipher
Algorithms", RFC 2451, November 1998.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
1999.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", from IEEE Proceedings of the 1996
Symposium on Network and Distributed Systems Security, URL
http://www.research.ibm.com/security/skeme.ps, 1996.
[IMIX] National Library for Applied Network Research (NLANR),
February 2001, ANI-9807479
Informative References
[RFC2403] Madson, C. and R. Glenn, "The Use of HMAC-MD5-96 within
ESP and AH", RFC 2403, November 1998.
[RFC2404] Madson, C. and R. Glenn, "The Use of HMAC-SHA-1-96 within
ESP and AH", RFC 2404, November 1998.
[RFC2405] Madson, C. and N. Doraswamy, "The ESP DES-CBC Cipher
Algorithm With Explicit IV", RFC 2405, November 1998.
[RFC2410] Glenn, R. and S. Kent, "The NULL Encryption Algorithm and
Its Use With IPsec", RFC 2410, November 1998.
[RFC2411] Thayer, R., Doraswamy, N. and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[I-D.ietf-ipsec-ikev2] Kaufman, C., "Internet Key Exchange (IKEv2)
Protocol",draft-ietf-ipsec-ikev2-04 (work in progress),
January 2003.
Bustos, Van Herck & Kaeo [Page 35]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
[I-D.ietf-ipsec-nat-reqts] Aboba, B. and W. Dixon, "IPsec-NAT
Compatibility Requirements", draft-ietf-ipsec-nat-reqts-03
(work in progress), January 2003.
[I-D.ietf-ipsec-nat-t-ike] Kivinen, T., "Negotiation of NAT-Traversal
in the IKE", draft-ietf-ipsec-nat-t-ike-05 (work in
progress),January 2003.
[I-D.ietf-ipsec-properties] Krywaniuk, A., "Security Properties of
the IPsec Protocol Suite", draft-ietf-ipsec-properties-02
(work in progress), July 2002.
[I-D.ietf-ipsec-udp-encaps] Huttunen, A., "UDP Encapsulation of IPsec
Packets", draft-ietf-ipsec-udp-encaps-06 (work in progress)
[FIPS.186-1.1998] National Institute of Standards and Technology,
"Digital Signature Standard", FIPS PUB 186-1, December 1998,
<http://csrc.nist.gov/fips/fips1861.pdf>.
[Hu95] Huitema, C., "Routing in the Internet", Prentice Hall, 1995.
January 2003.
Bustos, Van Herck & Kaeo [Page 36]
INTERNET-DRAFT Terminology for Benchmarking IPsec Devices Aug. 2003
12. Contact Information
Michele Bustos
IXIA
26601 W. Agoura Rd.
Calabasas, CA 91302
USA
Phone: 818 444 3244
Email: mbustos@ixiacom.com
Tim Van Herck
Cisco Systems
170 W. Tasman Drive
San Jose, CA 95134-1706
USA
Phone: 408 527 2461
Email: herckt@cisco.com
Merike Kaeo
123 Ross Street
Santa Cruz, CA 95060
USA
Phone: 831 818 4864
Email: kaeo@merike.com
13. Full Copyright Statement
"Copyright (C) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain
it or assist in its implementation may be prepared, copied,
published and distributed, in whole or in part, without restriction
of any kind, provided that the above copyright notice and this
paragraph are included on all such copies and derivative works.
However, this document itself may not be modified in any way, such
as by removing 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.ö
Bustos, Van Herck & Kaeo [Page 37]
Html markup produced by rfcmarkup 1.129d, available from
https://tools.ietf.org/tools/rfcmarkup/