draft-ietf-bmwg-ipsec-term-10.txt   draft-ietf-bmwg-ipsec-term-11.txt 
Benchmarking Working Group M. Kaeo Benchmarking Working Group M. Kaeo
Internet-Draft Double Shot Security Internet-Draft Double Shot Security
Expires: September 2, 2008 T. Van Herck Expires: October 5, 2009 T. Van Herck
Cisco Systems Cisco Systems
M. Bustos M. Bustos
IXIA IXIA
April 3, 2009
Terminology for Benchmarking IPsec Devices Terminology for Benchmarking IPsec Devices
draft-ietf-bmwg-ipsec-term-10 draft-ietf-bmwg-ipsec-term-11
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any This Internet-Draft is submitted to IETF in full conformance with the
applicable patent or other IPR claims of which he or she is aware provisions of BCP 78 and BCP 79. This document may contain material
have been or will be disclosed, and any of which he or she becomes from IETF Documents or IETF Contributions published or made publicly
aware will be disclosed, in accordance with Section 6 of BCP 79. available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
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 Internet- other groups may also distribute working documents as 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 September 2, 2008. This Internet-Draft will expire on October 5, 2009.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Abstract Abstract
This purpose of this document is to define terminology specific to This purpose of this document is to define terminology specific to
measuring the performance of IPsec devices. It builds upon the measuring the performance of IPsec devices. It builds upon the
tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF tenets set forth in [RFC1242], [RFC2544], [RFC2285] and other IETF
Benchmarking Methodology Working Group (BMWG) documents used for Benchmarking Methodology Working Group (BMWG) documents used for
benchmarking routers and switches. This document seeks to extend benchmarking routers and switches. This document seeks to extend
these efforts specific to the IPsec paradigm. The BMWG produces two these efforts specific to the IPsec paradigm. The BMWG produces two
major classes of documents: Benchmarking Terminology documents and major classes of documents: Benchmarking Terminology documents and
Benchmarking Methodology documents. The Terminology documents Benchmarking Methodology documents. The Terminology documents
present the benchmarks and other related terms. The Methodology present the benchmarks and other related terms. The Methodology
documents define the procedures required to collect the benchmarks documents define the procedures required to collect the benchmarks
cited in the corresponding Terminology documents. cited in the corresponding Terminology documents.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 5
3. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 4 3. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . . . 5
3.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6 3.1. IPsec Operation . . . . . . . . . . . . . . . . . . . . . 7
3.1.1. Security Associations . . . . . . . . . . . . . . . . 6 3.1.1. Security Associations . . . . . . . . . . . . . . . . 7
3.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 7 3.1.2. Key Management . . . . . . . . . . . . . . . . . . . . 8
4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 9 4. Definition Format . . . . . . . . . . . . . . . . . . . . . . 10
5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 9 5. Key Words to Reflect Requirements . . . . . . . . . . . . . . 10
6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 9 6. Existing Benchmark Definitions . . . . . . . . . . . . . . . . 10
7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.2. ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7.3. IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 12 7.3.1. IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . 13
7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 12 7.3.2. IKE Phase 1 Main Mode . . . . . . . . . . . . . . . . 13
7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 12 7.3.3. IKE Phase 1 Aggressive Mode . . . . . . . . . . . . . 13
7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 13 7.3.4. IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . 14
7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 13 7.3.5. Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . 14
7.4. Security Association (SA) . . . . . . . . . . . . . . . . 14 7.4. Security Association (SA) . . . . . . . . . . . . . . . . 15
7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 14 7.5. Selectors . . . . . . . . . . . . . . . . . . . . . . . . 15
7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 14 7.6. IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 15
7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 15 7.6.1. Initiator . . . . . . . . . . . . . . . . . . . . . . 16
7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 16 7.6.2. Responder . . . . . . . . . . . . . . . . . . . . . . 17
7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 16 7.6.3. IPsec Client . . . . . . . . . . . . . . . . . . . . . 17
7.6.4. IPsec Server . . . . . . . . . . . . . . . . . . . . . 16 7.6.4. IPsec Gateway . . . . . . . . . . . . . . . . . . . . 17
7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.7. Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 17 7.7.1. IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . 18
7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 17 7.7.2. Configured Tunnel . . . . . . . . . . . . . . . . . . 18
7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 18 7.7.3. Established Tunnel . . . . . . . . . . . . . . . . . . 19
7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 18 7.7.4. Active Tunnel . . . . . . . . . . . . . . . . . . . . 19
7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 19 7.8. Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 20
7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 19 7.8.1. Nested Tunnels . . . . . . . . . . . . . . . . . . . . 20
7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 20 7.8.2. Transport Adjacency . . . . . . . . . . . . . . . . . 21
7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 20 7.9. Transform protocols . . . . . . . . . . . . . . . . . . . 21
7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 21 7.9.1. Authentication Protocols . . . . . . . . . . . . . . . 22
7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 21 7.9.2. Encryption Protocols . . . . . . . . . . . . . . . . . 22
7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 22 7.10. IPsec Protocols . . . . . . . . . . . . . . . . . . . . . 23
7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 22 7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 23
7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 23 7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 24
7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 24 7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 25
7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 24 7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 25
7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 25 7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 26
8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 27 8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 28
8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 28 8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 29
9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 29 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 30
9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 29 9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 30
9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 29 9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 30
9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 29 9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 30
10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 30 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 30 10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1.1. IPsec Tunnel Capacity . . . . . . . . . . . . . . . . 30 10.1.1. IPsec Tunnel Capacity . . . . . . . . . . . . . . . . 31
10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 30 10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 31
10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 31 10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 32
10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 31 10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 32
10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 31 10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 32
10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 32 10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 33
10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 33 10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 34
10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 33 10.3.1. IPsec Latency . . . . . . . . . . . . . . . . . . . . 34
10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 33 10.3.2. IPsec Encryption Latency . . . . . . . . . . . . . . . 34
10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 34 10.3.3. IPsec Decryption Latency . . . . . . . . . . . . . . . 35
10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 35 10.3.4. Time To First Packet . . . . . . . . . . . . . . . . . 35
10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 35 10.4. Frame Loss . . . . . . . . . . . . . . . . . . . . . . . . 36
10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 35 10.4.1. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . 36
10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 36 10.4.2. IPsec Encryption Frame Loss . . . . . . . . . . . . . 36
10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 36 10.4.3. IPsec Decryption Frame Loss . . . . . . . . . . . . . 37
10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 37 10.4.4. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . 37
10.5. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 37 10.5. Tunnel Setup Behavior . . . . . . . . . . . . . . . . . . 38
10.5.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 37 10.5.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . 38
10.5.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 38 10.5.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . 38
10.5.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 38 10.5.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . 39
10.6. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 39 10.6. IPsec Tunnel Rekey Behavior . . . . . . . . . . . . . . . 39
10.6.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 39 10.6.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . 39
10.6.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 39 10.6.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . 40
10.7. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 40 10.7. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . 40
10.8. DoS Attack Resiliency . . . . . . . . . . . . . . . . . . 40 10.8. DoS Attack Resiliency . . . . . . . . . . . . . . . . . . 41
10.8.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . 40 10.8.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . 41
10.8.2. Phase 2 Hash Mismatch DoS Resiliency Rate . . . . . . 41 10.8.2. Phase 2 Hash Mismatch DoS Resiliency Rate . . . . . . 41
10.8.3. Phase 2 Anti Replay Attack DoS Resiliency Rate . . . . 41 10.8.3. Phase 2 Anti Replay Attack DoS Resiliency Rate . . . . 42
11. Security Considerations . . . . . . . . . . . . . . . . . . . 42 11. Security Considerations . . . . . . . . . . . . . . . . . . . 42
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 42
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 42 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 43
13.1. Normative References . . . . . . . . . . . . . . . . . . . 42 13.1. Normative References . . . . . . . . . . . . . . . . . . . 43
13.2. Informative References . . . . . . . . . . . . . . . . . . 44 13.2. Informative References . . . . . . . . . . . . . . . . . . 45
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 44 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 45
Intellectual Property and Copyright Statements . . . . . . . . . . 46
1. Introduction 1. Introduction
Despite the need to secure communications over a public medium there Despite the need to secure communications over a public medium there
is no standard method of performance measurement nor a standard in is no standard method of performance measurement nor a standard in
the terminology used to develop such hardware and software solutions. the terminology used to develop such hardware and software solutions.
This results in varied implementations which challenge This results in varied implementations which challenge
interoperability and direct performance comparisons. Standardized interoperability and direct performance comparisons. Standardized
IPsec terminology and performance test methodologies will enable IPsec terminology and performance test methodologies will enable
users to determine if the IPsec device they select will withstand users to determine if the IPsec device they select will withstand
skipping to change at page 16, line 44 skipping to change at page 17, line 44
network that needs to be accessed and to provide the required network that needs to be accessed and to provide the required
security services. An IPsec client will silently drop and ignore security services. An IPsec client will silently drop and ignore
any inbound IPsec tunnel requests. IPsec clients are generally any inbound IPsec tunnel requests. IPsec clients are generally
used to connect remote users in a secure fashion over the Internet used to connect remote users in a secure fashion over the Internet
to a private network. to a private network.
Issues: N/A Issues: N/A
See Also: IPsec device, IPsec Server, Initiator, Responder See Also: IPsec device, IPsec Server, Initiator, Responder
7.6.4. IPsec Server 7.6.4. IPsec Gateway
Definition: IPsec Devices that can both act as an Initiator as well Definition: IPsec Devices that can both act as an Initiator as well
as a Responder. as a Responder.
Discussion: IPsec Servers are mostly positioned at private network Discussion: IPsec Servers are mostly positioned at private network
edges and provide several functions: edges and provide several functions:
* Responds to IPsec tunnel setup request from IPsec Clients. * Responds to IPsec tunnel setup request from IPsec Clients.
* Responds to IPsec tunnel setup request from other IPsec devices * Responds to IPsec tunnel setup request from other IPsec devices
(Initiators). (Initiators).
* Initiate IPsec tunnels to other IPsec servers inside or outside * Initiate IPsec tunnels to other IPsec servers inside or outside
the private network. the private network.
Issues: IPsec Servers are also sometimes referred to as 'VPN Issues: IPsec Gateways are also sometimes referred to as 'IPsec
Concentrators'. Servers' or 'VPN Concentrators'.
See Also: IPsec Device, IPsec Client, Initiator, Responder See Also: 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. IPsec Tunnel 7.7.1. IPsec Tunnel
skipping to change at page 26, line 48 skipping to change at page 27, line 48
- Authentication algorithm (part of IPsec context) - Authentication algorithm (part of IPsec context)
- Encryption algorithm (part of IPsec context) - Encryption algorithm (part of IPsec context)
- DH-Group - DH-Group
- PFS Group used - PFS Group used
- SA Lifetime (part of IPsec context) - SA Lifetime (part of IPsec context)
* Use of IKE Keepalive or DPD, as defined in * Use of IKE Keepalive or DPD, as defined in [RFC3706], and its
[I-D.ietf-ipsec-dpd], and its interval and retry values interval and retry values (assumed disabled when not
(assumed disabled when not mentioned). mentioned).
* IP Compression [RFC2393] * IP Compression [RFC2393]
The IKE context MUST also list: The IKE context MUST also list:
* Phase 1 mode (main or aggressive) * Phase 1 mode (main or aggressive)
* Available bandwidth and latency to Certificate Authority server * Available bandwidth and latency to Certificate Authority server
(if applicable) (if applicable)
* Indication of NAT traversal
Issues: A Security Context will be an important element in Issues: A Security Context will be an important element in
describing the environment where protected traffic is traveling describing the environment where protected traffic is traveling
through. through.
See Also: IPsec Protocols, Transform Protocols, IKE Phase 1, IKE See Also: IPsec Protocols, Transform Protocols, IKE Phase 1, IKE
phase 2, Selectors, IPsec Tunnel phase 2, Selectors, IPsec Tunnel
8. Framesizes 8. Framesizes
8.1. Layer3 clear framesize 8.1. Layer3 clear framesize
skipping to change at page 30, line 32 skipping to change at page 31, line 32
10.1.1. IPsec Tunnel Capacity 10.1.1. IPsec Tunnel Capacity
Definition: The maximum number of Active IPsec Tunnels that can be Definition: The maximum number of Active IPsec Tunnels that can be
sustained on an IPsec Device. sustained on an IPsec Device.
Discussion: This metric will represent the quantity of IPsec Tunnels Discussion: This metric will represent the quantity of IPsec Tunnels
that can be establish on an IPsec Device that can forward traffic that can be establish on an IPsec Device that can forward traffic
i.e. Active Tunnels. It will be a measure that indicates how i.e. Active Tunnels. It will be a measure that indicates how
many remote peers an IPsec Device can establish a secure many remote peers an IPsec Device can establish a secure
connection with. connection with. For IPsec Tunnel Capacity, each IPsec SA is
associated with exactly 1 IKE SA.
Measurement Units: IPsec Tunnels Measurement Units: IPsec Tunnels
Issues: N/A Issues: N/A
See Also: IPsec SA Capacity See Also: IPsec SA Capacity
10.1.2. IPsec SA Capacity 10.1.2. IPsec SA Capacity
Definition: The maximum number of IPsec SA's that can be sustained Definition: The maximum number of IPsec SA's that can be sustained
skipping to change at page 31, line 25 skipping to change at page 32, line 26
Definition: The maximum rate through an Active Tunnel at which none Definition: The maximum rate through an Active Tunnel at which none
of the offered frames are dropped by the device under test. of the offered frames are dropped by the device under test.
Discussion: The IPsec Throughput is almost identically defined as Discussion: The IPsec 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
that the throughput is measured with a traffic flow getting that the throughput is measured with a traffic flow getting
encrypted and decrypted by an IPsec device. IPsec Throughput is encrypted and decrypted by an IPsec device. IPsec Throughput is
an end-to-end measurement. an end-to-end measurement.
The metric can be represented in two variantions depending on
where measurement is taken in the SUT. One can look at throughput
from a cleartext point of view i.e. find the maximum rate where
clearpackets no longer get dropped. This resulting rate can be
recalculated with an encrypted framesize to represent the
encryption throughput rate. The latter is the preferred method of
representation and shall be called the IPsec Throughput.
Measurement Units: Packets per seconds (pps) Measurement Units: Packets per seconds (pps)
Issues: N/A Issues: N/A
See Also: IPsec Encryption Throughput, IPsec Decryption Throughput See Also: IPsec Encryption Throughput, IPsec Decryption Throughput
10.2.2. IPsec Encryption Throughput 10.2.2. IPsec Encryption Throughput
Definition: The maximum encryption rate through an Active Tunnel at Definition: The maximum encryption rate through an Active Tunnel at
which none of the offered cleartext frames are dropped by the which none of the offered cleartext frames are dropped by the
skipping to change at page 40, line 37 skipping to change at page 41, line 16
Tunnel Failover Time. Tunnel Failover Time.
Issues: N/A Issues: N/A
10.8. DoS Attack Resiliency 10.8. DoS Attack Resiliency
10.8.1. Phase 1 DoS Resiliency Rate 10.8.1. Phase 1 DoS Resiliency Rate
Definition: The Phase 1 Denial of Service (DoS) Resilience Rate Definition: The Phase 1 Denial of Service (DoS) Resilience Rate
quantifies the rate of invalid or malicious IKE tunnels that can quantifies the rate of invalid or malicious IKE tunnels that can
be directed at a DUT before the Responder stops accepting valid be directed at a DUT before the Responder ignores or rejects valid
tunnel attempts. tunnel attempts.
Discussion: Phase 1 DoS attacks can present themselves in various Discussion: Phase 1 DoS attacks can present themselves in various
forms and do not necessarily have to have a malicious background. forms and do not necessarily have to have a malicious background.
It is sufficient to make a typographical error in a shared secret It is sufficient to make a typographical error in a shared secret
in an IPsec Device to be susceptible to a large number of IKE in an IPsec Device to be susceptible to a large number of IKE
attempts that need to be turned down. Due to the intense attempts that need to be turned down. Due to the intense
computational nature of an IKE exchange every single IKE tunnel computational nature of an IKE exchange every single IKE tunnel
attempt that has to be denied will take non-negligible CPU cycles attempt that has to be denied will take non-negligible CPU cycles
in the IPsec Device. in the IPsec Device.
skipping to change at page 41, line 11 skipping to change at page 41, line 39
processed, a system might end up in a state that the burden on processed, a system might end up in a state that the burden on
system resource performing key exchanges is high enough that all system resource performing key exchanges is high enough that all
resources are consumed by this process. At this point it will be resources are consumed by this process. At this point it will be
no longer possible to process a valid IKE tunnel setup request and no longer possible to process a valid IKE tunnel setup request and
thus a Phase 1 DoS Attack is in effect. thus a Phase 1 DoS Attack is in effect.
The scope of the attack profile for this test will include The scope of the attack profile for this test will include
mismatched pre-shared keys as well as invalid digital mismatched pre-shared keys as well as invalid digital
certificates. certificates.
Measurement Units: Tunnel Attempts Per Seconds (TAPS) Measurement Units: Percentage of FailedTunnel Attempts Per Seconds
(TAPS)
Issues: N/A Issues: N/A
10.8.2. Phase 2 Hash Mismatch DoS Resiliency Rate 10.8.2. Phase 2 Hash Mismatch DoS Resiliency Rate
Definition: The Phase 2 Hash Mismatch Denial of Service (DoS) Definition: The Phase 2 Hash Mismatch Denial of Service (DoS)
Resilience Rate quantifies the rate of invalid ESP/AH packets that Resilience Rate quantifies the rate of invalid ESP/AH packets that
a DUT can drop without affecting the traffic flow of valid ESP/AH a DUT can drop without affecting the traffic flow of valid ESP/AH
packets. packets.
skipping to change at page 42, line 22 skipping to change at page 43, line 6
As this document is solely for the purpose of providing test As this document is solely for the purpose of providing test
benchmarking terminology and describes neither a protocol nor a benchmarking terminology and describes neither a protocol nor a
protocol's implementation; there are no security considerations protocol's implementation; there are no security considerations
associated with this document. associated with this document.
12. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the following individual for The authors would like to acknowledge the following individual for
their participation of the compilation and editing of this document their participation of the compilation and editing of this document
and guidance: Debby Stopp, Paul Hoffman, Sunil Kalidindi, Brian and guidance: Debby Stopp, Paul Hoffman, Sunil Kalidindi, Brian
Talbert. Talbert and Yaron Sheffer.
13. References 13. References
13.1. Normative References 13.1. Normative References
[RFC1242] Bradner, S., "Benchmarking terminology for network [RFC1242] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991. interconnection devices", RFC 1242, July 1991.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 44, line 17 skipping to change at page 44, line 48
[RFC4302] Kent, S., "IP Authentication Header", RFC 4302, [RFC4302] Kent, S., "IP Authentication Header", RFC 4302,
December 2005. December 2005.
[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
RFC 4303, December 2005. RFC 4303, December 2005.
[RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", [RFC4306] Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
RFC 4306, December 2005. RFC 4306, December 2005.
[I-D.ietf-ipsec-ikev2] [RFC3706] Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic-
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Based Method of Detecting Dead Internet Key Exchange (IKE)
draft-ietf-ipsec-ikev2-17 (work in progress), Peers", RFC 3706, February 2004.
October 2004.
[I-D.ietf-ipsec-dpd]
Huang, G., Beaulieu, S., and D. Rochefort, "A Traffic-
Based Method of Detecting Dead IKE Peers",
draft-ietf-ipsec-dpd-04 (work in progress), October 2003.
[I-D.ietf-ipsec-properties] [I-D.ietf-ipsec-properties]
Krywaniuk, A., "Security Properties of the IPsec Protocol Krywaniuk, A., "Security Properties of the IPsec Protocol
Suite", draft-ietf-ipsec-properties-02 (work in progress), Suite", draft-ietf-ipsec-properties-02 (work in progress),
July 2002. July 2002.
[FIPS.186-1.1998] [FIPS.186-1.1998]
National Institute of Standards and Technology, "Digital National Institute of Standards and Technology, "Digital
Signature Standard", FIPS PUB 186-1, December 1998, Signature Standard", FIPS PUB 186-1, December 1998,
<http://csrc.nist.gov/fips/fips1861.pdf>. <http://csrc.nist.gov/fips/fips1861.pdf>.
13.2. Informative References 13.2. Informative References
[Designing Network Security] [Designing Network Security]
Kaeo, M., "Designing Network Security", ISBN: 1578700434, Kaeo, M., "Designing Network Security", ISBN: 1587051176,
Published: May 07, 1999; Copyright: 1999, 1999. Published: November, 2004.
[SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange [SKEME] Krawczyk, H., "SKEME: A Versatile Secure Key Exchange
Mechanism for Internet", from IEEE Proceedings of the Mechanism for Internet", from IEEE Proceedings of the
1996 Symposium on Network and Distributed Systems 1996 Symposium on Network and Distributed Systems
Security, Security,
URI http://www.research.ibm.com/security/skeme.ps, 1996. URI http://www.research.ibm.com/security/skeme.ps, 1996.
Authors' Addresses Authors' Addresses
Merike Kaeo Merike Kaeo
skipping to change at page 45, line 24 skipping to change at page 46, line 4
Email: kaeo@merike.com Email: kaeo@merike.com
Tim Van Herck Tim Van Herck
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
USA USA
Phone: +1(408)853-2284 Phone: +1(408)853-2284
Email: herckt@cisco.com Email: herckt@cisco.com
Michele Bustos Michele Bustos
IXIA IXIA
26601 W. Agoura Rd. 26601 W. Agoura Rd.
Calabasas, CA 91302 Calabasas, CA 91302
USA USA
Phone: +1(818)444-3244 Phone: +1(818)444-3244
Email: mbustos@ixiacom.com Email: mbustos@ixiacom.com
Full Copyright Statement
Copyright (C) The IETF Trust (2008).
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, THE IETF TRUST 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
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by 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
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
 End of changes. 28 change blocks. 
114 lines changed or deleted 119 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/