draft-ietf-bmwg-ipsec-term-02.txt   draft-ietf-bmwg-ipsec-term-03.txt 
Benchmarking Working Group M. Bustos Benchmarking Working Group M. Bustos
Internet-Draft IXIA Internet-Draft IXIA
Expires: May 1, 2004 T. Van Herck Expires: August 30, 2004 T. Van Herck
Cisco Systems, Inc. Cisco Systems, Inc.
M. Kaeo M. Kaeo
Merike, Inc. Merike, Inc.
November 2003
Terminology for Benchmarking IPSec Devices Terminology for Benchmarking IPSec Devices
draft-ietf-bmwg-ipsec-term-02 draft-ietf-bmwg-ipsec-term-03
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts. groups may also distribute working documents as Internet-Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 33
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at http:// The list of current Internet-Drafts can be accessed at http://
www.ietf.org/ietf/1id-abstracts.txt. www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 1, 2004. This Internet-Draft will expire on August 30, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract Abstract
This purpose of this document is to define terminology specific to This purpose of this document is to define terminology specific to
measuring the performance of IPsec devices. It builds upon the measuring the performance of IPsec devices. It builds upon the
tenets set forth in RFC 1242, RFC 2544, RFC 2285 and other IETF tenets set forth in RFC 1242, RFC 2544, RFC 2285 and other IETF
Benchmarking Methodology Working Group (BMWG) documents used for Benchmarking Methodology Working Group (BMWG) documents used for
benchmarking routers and switches. This document seeks to extend benchmarking routers and switches. This document seeks to extend
these efforts specific to the IPsec paradigm. The BMWG produces 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 4
2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . 4 2. IPsec Fundamentals . . . . . . . . . . . . . . . . . . . . 4
2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6 2.1 IPsec Operation . . . . . . . . . . . . . . . . . . . . . 6
2.1.1 Security Associations . . . . . . . . . . . . . . . . . . 6 2.1.1 Security Associations . . . . . . . . . . . . . . . . . . 6
2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . . . 6 2.1.2 Key Management . . . . . . . . . . . . . . . . . . . . . . 6
3. Document Scope . . . . . . . . . . . . . . . . . . . . . . 8 3. Document Scope . . . . . . . . . . . . . . . . . . . . . . 8
4. Definition Format . . . . . . . . . . . . . . . . . . . . 8 4. Definition Format . . . . . . . . . . . . . . . . . . . . 8
5. Key Words to Reflect Requirements . . . . . . . . . . . . 9 5. Key Words to Reflect Requirements . . . . . . . . . . . . 9
6. Existing Definitions . . . . . . . . . . . . . . . . . . . 9 6. Existing Benchmark Definitions . . . . . . . . . . . . . . 9
7. Term Definitions . . . . . . . . . . . . . . . . . . . . . 10 7. Definitions . . . . . . . . . . . . . . . . . . . . . . . 10
7.1 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.1 Configured Tunnel . . . . . . . . . . . . . . . . . . . . 10 7.2 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7.1.2 Established Tunnel . . . . . . . . . . . . . . . . . . . . 11 7.3 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
7.1.3 Active Tunnel . . . . . . . . . . . . . . . . . . . . . . 11 7.3.1 IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . . . 12
7.1.4 Terminated Tunnel . . . . . . . . . . . . . . . . . . . . 12 7.3.2 Phase 1 Main Mode . . . . . . . . . . . . . . . . . . . . 12
7.2 IPsec . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7.3.3 Phase 1 Aggressive Mode . . . . . . . . . . . . . . . . . 13
7.3 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 13 7.3.4 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 13
7.3.1 Initiator . . . . . . . . . . . . . . . . . . . . . . . . 14 7.3.5 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . . . 14
7.3.2 Responder . . . . . . . . . . . . . . . . . . . . . . . . 14 7.4 Security Association (SA) . . . . . . . . . . . . . . . . 15
7.3.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . . . 15 7.5 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 15
7.3.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . . . 16 7.6 IPsec Device . . . . . . . . . . . . . . . . . . . . . . . 16
7.4 ISAKMP . . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.6.1 Initiator . . . . . . . . . . . . . . . . . . . . . . . . 17
7.5 IKE . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7.6.2 Responder . . . . . . . . . . . . . . . . . . . . . . . . 17
7.6 Security Association (SA) . . . . . . . . . . . . . . . . 18 7.6.3 IPsec Client . . . . . . . . . . . . . . . . . . . . . . . 18
7.7 IKE Phase 1 . . . . . . . . . . . . . . . . . . . . . . . 18 7.6.4 IPsec Server . . . . . . . . . . . . . . . . . . . . . . . 18
7.7.1 Phase 1 Main Mode . . . . . . . . . . . . . . . . . . . . 19 7.7 Tunnels . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.7.2 Phase 1 Aggressive Mode . . . . . . . . . . . . . . . . . 19 7.7.1 IKE Tunnel . . . . . . . . . . . . . . . . . . . . . . . . 19
7.8 IKE Phase 2 . . . . . . . . . . . . . . . . . . . . . . . 20 7.7.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . . . 20
7.8.1 Phase 2 Quick Mode . . . . . . . . . . . . . . . . . . . . 20 7.7.3 Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.8.2 IPsec Tunnel . . . . . . . . . . . . . . . . . . . . . . . 21 7.7.4 Configured Tunnel . . . . . . . . . . . . . . . . . . . . 21
7.9 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 21 7.7.5 Established Tunnel . . . . . . . . . . . . . . . . . . . . 21
7.9.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . . . 21 7.7.6 Active Tunnel . . . . . . . . . . . . . . . . . . . . . . 22
7.9.2 Transport Adjacency . . . . . . . . . . . . . . . . . . . 22 7.8 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 23
7.10 Transform protocols . . . . . . . . . . . . . . . . . . . 23 7.8.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . . . 23
7.10.1 Authentication Protocols . . . . . . . . . . . . . . . . . 24 7.8.2 Transport Adjacency . . . . . . . . . . . . . . . . . . . 24
7.10.2 Encryption Protocols . . . . . . . . . . . . . . . . . . . 24 7.9 Transform protocols . . . . . . . . . . . . . . . . . . . 25
7.11 IPSec Protocols . . . . . . . . . . . . . . . . . . . . . 25 7.9.1 Authentication Protocols . . . . . . . . . . . . . . . . . 25
7.11.1 Authentication Header (AH) . . . . . . . . . . . . . . . . 25 7.9.2 Encryption Protocols . . . . . . . . . . . . . . . . . . . 26
7.11.2 Encapsulated Security Payload (ESP) . . . . . . . . . . . 26 7.10 IPSec Protocols . . . . . . . . . . . . . . . . . . . . . 26
7.12 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 27 7.10.1 Authentication Header (AH) . . . . . . . . . . . . . . . . 27
7.13 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 28 7.10.2 Encapsulated Security Payload (ESP) . . . . . . . . . . . 28
7.14 IP Compression . . . . . . . . . . . . . . . . . . . . . . 28 7.11 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 28
7.15 Security Context . . . . . . . . . . . . . . . . . . . . . 29 7.12 IP Compression . . . . . . . . . . . . . . . . . . . . . . 29
8. Performance Metrics . . . . . . . . . . . . . . . . . . . 31 7.13 Security Context . . . . . . . . . . . . . . . . . . . . . 30
8.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 31 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . 32
8.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 31 8.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32
8.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 32 8.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 32
9. Test Definitions . . . . . . . . . . . . . . . . . . . . . 32 8.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 33
9.1 Framesizes . . . . . . . . . . . . . . . . . . . . . . . . 32 8.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 34
9.1.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32 9. Performance Metrics . . . . . . . . . . . . . . . . . . . 35
9.1.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33 9.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 35
9.1.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34 9.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 35
9.1.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 35 9.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 36
9.2 Internet Mix Traffic (IMIX) . . . . . . . . . . . . . . . 35 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . 36
9.3 Throughput . . . . . . . . . . . . . . . . . . . . . . . . 36 10.1 Throughput . . . . . . . . . . . . . . . . . . . . . . . . 36
9.3.1 IPsec Tunnel Throughput . . . . . . . . . . . . . . . . . 36 10.1.1 Tunnel Throughput . . . . . . . . . . . . . . . . . . . . 36
9.3.2 IPsec Encryption Throughput . . . . . . . . . . . . . . . 37 10.1.2 IPsec Encryption Throughput . . . . . . . . . . . . . . . 37
9.3.3 IPsec Decryption Throughput . . . . . . . . . . . . . . . 37 10.1.3 IPsec Decryption Throughput . . . . . . . . . . . . . . . 38
9.4 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 38 10.2 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.4.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . . . . 38 10.2.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . . . . 38
9.4.2 IPsec Tunnel Encryption Latency . . . . . . . . . . . . . 39 10.2.2 IPsec Tunnel Encryption Latency . . . . . . . . . . . . . 39
9.4.3 IPsec Tunnel Decryption Latency . . . . . . . . . . . . . 40 10.2.3 IPsec Tunnel Decryption Latency . . . . . . . . . . . . . 40
9.4.4 Time To First Packet . . . . . . . . . . . . . . . . . . . 40 10.2.4 Time To First Packet . . . . . . . . . . . . . . . . . . . 41
9.5 Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . 41 10.3 Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . 41
9.5.1 Tunnel Frame Loss Rate . . . . . . . . . . . . . . . . . . 41 10.3.1 IPSec Tunnel Frame Loss Rate . . . . . . . . . . . . . . . 41
9.5.2 IPsec Tunnel Encryption Frame Loss Rate . . . . . . . . . 42 10.3.2 IPsec Tunnel Encryption Frame Loss Rate . . . . . . . . . 42
9.5.3 IPsec Tunnel Decryption Frame Loss Rate . . . . . . . . . 43 10.3.3 IPsec Tunnel Decryption Frame Loss Rate . . . . . . . . . 43
9.6 Back-to-back Frames . . . . . . . . . . . . . . . . . . . 43 10.4 Back-to-back Frames . . . . . . . . . . . . . . . . . . . 44
9.6.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . . . . 43 10.4.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . . . . 44
9.6.2 Encryption Back-to-back Frames . . . . . . . . . . . . . . 44 10.4.2 Encryption Back-to-back Frames . . . . . . . . . . . . . . 44
9.6.3 Decryption Back-to-back Frames . . . . . . . . . . . . . . 45 10.4.3 Decryption Back-to-back Frames . . . . . . . . . . . . . . 45
9.7 Maximum Number of Tunnels . . . . . . . . . . . . . . . . 45 10.5 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . . 46
9.7.1 Maximum Configured Tunnels (MCT) . . . . . . . . . . . . . 45 10.5.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . . . . 46
9.7.2 Maximum Active Tunnels (MAT) . . . . . . . . . . . . . . . 46 10.5.2 Phase 1 Setup Rate . . . . . . . . . . . . . . . . . . . . 46
9.8 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . . 46 10.5.3 Phase 2 Setup Rate . . . . . . . . . . . . . . . . . . . . 47
9.8.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . . . . 46 10.6 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . . 47
9.8.2 IKE Setup Rate . . . . . . . . . . . . . . . . . . . . . . 47 10.6.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . . . 47
9.8.3 IPsec Setup Rate . . . . . . . . . . . . . . . . . . . . . 47 10.6.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . . . 48
9.9 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . . 48 10.7 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . . 49
9.9.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . . . 48 10.8 IKE DOS Resilience Rate . . . . . . . . . . . . . . . . . 49
9.9.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . . . 49 11. Security Considerations . . . . . . . . . . . . . . . . . 50
9.10 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . . 49 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 50
10. IKE DOS Resilience Rate . . . . . . . . . . . . . . . . . 50 13. Contributors . . . . . . . . . . . . . . . . . . . . . . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . 51 Normative References . . . . . . . . . . . . . . . . . . . 50
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 51 Informative References . . . . . . . . . . . . . . . . . . 52
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . 51
Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53 Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . 55 Intellectual Property and Copyright Statements . . . . . . 54
1. Introduction 1. Introduction
Despite the need to secure communications over a public medium there Despite the need to secure communications over a public medium there
is no standard method of performance measurement nor a standard in is no standard method of performance measurement nor a standard in
the terminology used to develop such hardware/software solutions. the terminology used to develop such hardware/software solutions.
This results in varied implementations which challenge This results in varied implementations which challenge
interoperability and direct performance comparisons. Standarized interoperability and direct performance comparisons. Standarized
IPsec terminology and performance test methodologies will enable IPsec terminology and performance test methodologies will enable
users to decide if the IPsec device they select will withstand users to decide if the IPsec device they select will withstand
skipping to change at page 8, line 37 skipping to change at page 8, line 37
The primary focus of this document is to establish useful performance The primary focus of this document is to establish useful performance
testing terminology for IPsec devices that support IKEv1. We want to testing terminology for IPsec devices that support IKEv1. We want to
constrain the terminology specified in this document to meet the constrain the terminology specified in this document to meet the
requirements of the Methodology for Benchmarking IPSec Devices requirements of the Methodology for Benchmarking IPSec Devices
documented test methodologies. The testing will be constrained to documented test methodologies. The testing will be constrained to
devices acting as IPsec gateways and will pertain to both IPsec devices acting as IPsec gateways and will pertain to both IPsec
tunnel and transport mode. tunnel and transport mode.
Any testing involving interoperability and/or conformance issues, Any testing involving interoperability and/or conformance issues,
L2TP, GRE, 2547 (MPLS VPNs), multicast, and anything that does not L2TP, GRE, RFC 2547 (MPLS VPNs), multicast, and anything that does
specifically relate to the establishment and tearing down of IPsec not specifically relate to the establishment and tearing down of
tunnels is specifically out of scope. It is assumed that all relevant IPsec tunnels is specifically out of scope. It is assumed that all
networking parameters that facilitate in the running of these tests relevant networking parameters that facilitate in the running of
are pre-configured (this includes at a minimum ARP caches and routing these tests are pre-configured (this includes at a minimum ARP caches
tables). This document will encompass updates to AH, ESP and NAT and routing tables). This document will encompass updates to AH, ESP
Traversal. and NAT Traversal. Since NAT traversal has been included in the
document, NAT is not included in this document.
4. Definition Format 4. Definition Format
The definition format utilized by this document is described in The definition format utilized by this document is described in
[RFC1242], Section 2. [RFC1242], Section 2.
Term to be defined. Term to be defined.
Definition: Definition:
skipping to change at page 9, line 40 skipping to change at page 9, line 40
5. Key Words to Reflect Requirements 5. Key Words to Reflect Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119. RFC 2119 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 defines the use of these key words to help make the intent of
standards track documents as clear as possible. While this document standards track documents as clear as possible. While this document
uses these keywords, this document is not a standards track document. uses these keywords, this document is not a standards track document.
6. Existing Definitions 6. Existing Benchmark Definitions
It is recommended that readers consult [RFC1242], [RFC2544] and It is recommended that readers consult [RFC1242], [RFC2544] and
[RFC2285] before making use of this document. These and other IETF [RFC2285] before making use of this document. These and other IETF
Benchmarking Methodology Working Group (BMWG) router and switch Benchmarking Methodology Working Group (BMWG) router and switch
documents contain several existing terms relevant to benchmarking the documents contain several existing terms relevant to benchmarking the
performance of IPsec devices. The conceptual framework established in performance of IPsec devices. The conceptual framework established in
these earlier RFCs will be evident in this document. these earlier RFCs will be evident in this document.
This document also draws on existing terminology defined in other This document also draws on existing terminology defined in other
BMWG documents. Examples include, but are not limited to: BMWG documents. Examples include, but are not limited to:
Throughput [RFC 1242, section 3.17] Throughput [RFC 1242, section 3.17]
Latency [RFC 1242, section 3.8] Latency [RFC 1242, section 3.8]
Frame Loss Rate [RFC 1242, section 3.6] Frame Loss Rate [RFC 1242, section 3.6]
Forwarding Rates [RFC 2285, section 3.6] Forwarding Rates [RFC 2285, section 3.6]
Loads [RFC 2285, section 3.5] Loads [RFC 2285, section 3.5]
Note: "DUT/SUT" refers to a metric that may be applicable to a DUT Note: "DUT/SUT" refers to a metric that may be applicable to a DUT
(Device Under Test) or an SUT (System Under Test). (Device Under Test) or an SUT (System Under Test).
7. Term Definitions 7. Definitions
7.1 Tunnel 7.1 IPsec
The term "tunnel" is often used in a variety of contexts. To avoid Definition:
any discrepancies, in this document we define the following
distinctions between the word "tunnel":
"IKE Tunnel": (ISAKMP/IKE SA, IKE Phase 1 SA, Phase 1 SA) One simplex IPsec or IP Security protocol suite which comprises a set of
Phase 1 IKE SA, which is sometimes is also referred to as ISAKMP or standards used to provide security services at the IP layer.
IKE SA, IKE Phase 1 SA, or Phase 1 SA. An IKE Tunnel between IPSec
devices facilitates a mechanism for secure negotiation of Phase 1
properties and 2 SA's needed for protected data transport.
"IPsec SA": (IPsec SA, IKE Phase 2 SA) One simplex IKE Phase 2 SA, Discussion:
which is also referred to as an IPsec SA or IKE Phase 2 SA.
"IPsec Tunnel": In the case of simplex communication, a single phase IPsec is a framework of protocols that offer authentication,
2 SA. In the more likely case where bidirectional communication is authenticity and encryption services to the IP and/or upper layer
needed it is a pair of Phase 2 SA's, one for each direction. Unless protocols. The major components of the protocol suite are IKE,
stated otherwise, bidirectional communication is always assumed. The used for key exchanges, and IPsec protocols such as AH and ESP,
IPSec Tunnel will protect the data traffic flowing between IPSec which use the exchanged keys to protect payload traffic.
devices.
"Tunnel": The combination of one IKE Tunnel and one IPsec Tunnel i.e. Issues:
a single Phase 1 SA and a pair of Phase 2 SA's (for bidirectional
communication).
7.1.1 Configured Tunnel N/A
See Also:
IPsec Device, IKE, ISAKMP, ESP, AH
7.2 ISAKMP
Definition: Definition:
A tunnel that is present in the IPSec device's configuration but The Internet Security Association and Key Management Protocol,
does not have any SA's in the SADB. which provides a framework for authentication and key exchange but
does not define them. ISAKMP is designed to be key exchange
independent; it is designed to support many different key
exchanges. ISAKMP is defined in [RFC2407].
Discussion: Discussion:
Several steps are required before a Tunnel can be used to actually Though ISAKMP is only a framework for the IPsec standard key
trasport data. The very first step would be to configure the management protocol, it is often misused and interchanged with the
tunnel in the IPsec device. In that way packet classification can term 'IKE', which is an implementation of ISAKMP.
make a decision if it is required to start negotiating SA's. At
this time there are no SA's associated with the Tunnel.
Issues: Issues:
N/A When implementations refer to the term 'ISAKMP SA' it refers to an
IKE Phase 1 SA.
See Also: See Also:
Tunnel, Established Tunnel, Active Tunnel, Terminated Tunnel IKE, Security Association
7.1.2 Established Tunnel 7.3 IKE
Definition: Definition:
A Tunnel that has completed Phase 1 and Phase 2 SA negotiations A hybrid key management protocol that allows secure negotiation of
but is otherwise idle. IPsec SA paramters.
Discussion: Discussion:
A second step needed to ensure that a Tunnel can transport data is A hybrid protocol, defined in [RFC2409], from the following 3
the Phase 1 and Phase 2 negotiation phase. After the packet protocols:
classification process has asserted that a packet requires
security services, the negotation is started to obtain both Phase * ISAKMP (Internet Security Association and Key Management
1 and Phase 2 SA's. After this is completed the tunnel is called Protocol), which provides a framework for authentication and
'Established'. Note that at this time there is still no traffic key exchange but does not define them. ISAKMP is designed to be
flowing through the Tunnel. key exchange independent; it is designed to support many
different key exchanges.
* Oakley, which describes a series of key exchanges, called
modes, and details the services provided by each (for example,
perfect forward secrecy for keys, identity protection, and
authentication). [RFC2412]
* [SKEME] (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that provides
anonymity, reputability, and quick key refreshment.
Note that IKE is an optional protocol within the IPsec framework.
Tunnels may also be manually configured i.e. the administrator
will provide keys that will be associated with the Phase 2 SA's as
long as the IPsec Tunnel is configured. This method is the most
basic mechanism to establish an IPsec tunnel between two IPsec
devices but it also decreases the level of protection since the
keys are not changing as they normally would during an IKE phase 2
rekey which is controlled by the IKE protocol.
Issues: Issues:
In the case of manually keyed tunnels, there is no distinction During the first IPsec deployment experiences, ambiguities were
between a Configured Tunnel or an Established Tunnel since there found in the IKEv1 specification, which lead to interoperability
is no negotiation required with these type of Tunnels and the problems. To resolve these issues, IKEv1 is being updated by
Tunnel is Established at time of Configuration since all keying IKEv2.
information is known at that point.
See Also: See Also:
Tunnel, Configured Tunnel, Active Tunnel, Terminated Tunnel ISAKMP, IPsec, Security Association
7.3.1 IKE Phase 1
7.1.3 Active Tunnel
Definition: Definition:
A tunnel that has completed Phase 1 and Phase 2 SA negotiations The shared policy and key(s) used by negotiating peers to set up a
and is transmitting data. secure authenticated "control channel" for further IKE
communications.
Discussion: Discussion:
When a Tunnel is Established it is ready to transport data Note that IKE is an optional protocol within the IPsec framework
traffic, and we call the tunnel 'Active'. and keys can also be manually configured.
Issues:
In other documents often referenced as ISAKMP SA or IKE SA.
See Also:
IKE, ISAKMP
7.3.2 Phase 1 Main Mode
Definition:
Main Mode is an instantiation of the ISAKMP Identity Protect
Exchange, defined in [RFC2409]. Upon successful completion it
results in the establishment of an IKE Phase 1 SA.
Discussion:
IKE Main Mode use 3 distinct message pairs, for a total of 6
messages. The first two messages negotiate policy; the next two
represent Diffie-Hellman public values and ancillary data (e.g.
nonces); and the last two messages authenticate the Diffie-Hellman
Exchange. The authentication method negotiated as part of the
initial IKE Phase 1 influence the composition of the payloads but
not their purpose.
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel, Configured Tunnel, Established Tunnel, Terminated Tunnel ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode
7.1.4 Terminated Tunnel 7.3.3 Phase 1 Aggressive Mode
Definition: Definition:
A tunnel that has relinquished all it's SA's and is not Aggressive Mode is an instantiation of the ISAKMP Aggressive
transmitting data anymore. Exchange, defined in [RFC2409]. Upon successful completion it
results in the establishment of an IKE Phase 1 SA.
Discussion: Discussion:
At the point where it is no longer required to provide security IKE Aggressive Mode uses 3 messages. The first two messages
services between IPsec devices, first the Phase 2 SA's are negotiate policy, exchange Diffie-Hellman public values and
released after which the Phase 1 SA is deleted and the Tunnel is ancillary data necessary for the exchange, and identities. In
no longer. After all resources (SA's) are (in most cases addition the second message authenticates the Responder. The third
volountary released) the Tunnel returns to a 'Configured' state. message authenticates the Initiator and provides proof of
participation in the exchange.
Issues: Issues:
Note that manually keyed tunnels never can be in a Terminated For IKEv1 the standard specifies that all implementations use both
state. The only way to prevent data forwarding over a manually main and agressive mode, however, it is common to use only main
keyed tunnel is to deconfigure the Tunnel. mode.
See Also: See Also:
Tunnel, Configured Tunnel, Established Tunnel, Active Tunnel ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode
7.2 IPsec 7.3.4 IKE Phase 2
Definition: Definition:
IPsec or IP Security protocol suite which comprises a set of ISAKMP phase which upon successful completion establishes the
standards used to provide security services at the IP layer. shared keys used by the negotiating peers to set up a secure "data
channel" for IPsec.
Discussion: Discussion:
IPsec is a large framework of protocols that offer authentication, The main purpose of Phase 2 is to produce the key for the IPsec
authenticity and encryption services to the IP and/or upper layer tunnel. Phase 2 is also used to regenerate the key being used for
protocols. The major components of the protocol suite are IKE, IPsec (called "rekeying"), as well as for exchanging informational
used for key exchanges, and IPsec protocols such as AH and ESP, messages.
which use the exchanged keys to protect payload traffic.
Issues:
In other documents also referenced as IPsec SA.
See Also:
IKE Phase 1, ISAKMP, IKE
7.3.5 Phase 2 Quick Mode
Definition:
Quick Mode is an instanciation of IKE Phase 2. After successful
completion it will result in one or typically two or more IPsec
SA's
Discussion:
Quick Mode is not a complete exchange itself (it is bound to a
phase 1 exchange), but is used as part of the SA 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, PFS and exponentiation per Quick Mode.
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Device, IKE, ISAKMP, ESP, AH ISAKMP, IKE, IKE Phase 2
7.3 IPsec Device 7.4 Security Association (SA)
Definition:
A simplex (unidirectional) logical connection that links a traffic
flow to a set of security parameters. All traffic traversing an SA
is provided the same security processing and will be subjected to
a common set of encryption and/or authentication algorithms. In
IPsec, an SA is an Internet layer abstraction implemented through
the use of AH or ESP as defined in [RFC2401].
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:
N/A
See Also:
Initiator, Responder
7.5 Selectors
Definition:
A mechanism used for the classification of traffic flows that
require encryption and/or authentication services.
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 associate it with an SA.
After classification, a decision can be made if the traffic needs
to be encrypted/decrypted and how this should be done depending on
the SA linked to the traffic flow. Simply put, selectors classify
IP packets that require IPsec processing and those packets that
must be passed along without any intervention of the IPsec
framework.
Selectors are flexible objects that can match on ranges of source
and destination addresses and ranges of source and destination
ports.
Issues:
Both sides must agree exactly on both the networks being
protected, and they both must agree on how to describe the
networks (range, subnet, addresses). This is a common point of
non-interoperability.
7.6 IPsec Device
Definition: Definition:
Any implementation that has the ability to process data flows Any implementation that has the ability to process data flows
according to the IPsec protocol suite specifications. according to the IPsec protocol suite specifications.
Discussion: Discussion:
Implementations can be grouped by 'external' properties (e.g. Implementations can be grouped by 'external' properties (e.g.
software vs. hardware implementations) but more important is the software vs. hardware implementations) but more important is the
skipping to change at page 14, line 14 skipping to change at page 17, line 5
Due to the fragmented nature of the IPsec Protocol Suite RFC's, it Due to the fragmented nature of the IPsec Protocol Suite RFC's, it
is possible that IPsec implementations will not be able to is possible that IPsec implementations will not be able to
interoperate. Therefore it is important to know which features and interoperate. Therefore it is important to know which features and
options are implemented in the IPsec Device. options are implemented in the IPsec Device.
See Also: See Also:
IPsec IPsec
7.3.1 Initiator 7.6.1 Initiator
Definition: Definition:
IPsec devices which start the negotiation of IKE Phase 1 or IKE An IPsec devices which starts the negotiation of IKE Phase 1 and
Phase 2 tunnels. Phase 2 tunnels.
Discussion: Discussion:
When a traffic flow is offered at an IPSec device and it is When a traffic flow is offered at an IPSec device and it is
determined that the flow must be protected, but there is no tunnel determined that the flow must be protected, but there is no IPsec
yet, it is the responsibility of the IPsec device to start a tunnel to send the traffic through, it is the responsibility of
negotiation process. This process will establish an IKE Phase 1 SA the IPsec device to start a negotiation process that will
and one or more IKE phase 2 SA's, eventually resulting in secured instantiate the IPsec tunnel. This process will establish an IKE
data transport. The device that takes the action to start this Phase 1 SA and one, or more likely, a pair IKE phase 2 SA's,
negotiation process will be called an Initiator. Note that an IKE eventually resulting in secured data transport. The device that
Phase 1 initiator, does not necessarily become an IKE Phase 2 takes the action to start this negotiation process will be called
initiator. an Initiator.
Issues: Issues:
IPsec devices/implementations can always be both an initiator as IPsec devices/implementations can always be both an initiator as
well as a responder. The distinction is useful from a test well as a responder. The distinction is useful from a test
perspective. perspective.
See Also: See Also:
Responder, IKE, IPsec Responder, IKE, IPsec
7.3.2 Responder 7.6.2 Responder
Definition: Definition:
IPsec devices which reply to the incoming initiators IKE Phase 1 An IPsec devices which replies to incoming IKE Phase 1 and Phase 2
or Phase 2 tunnel requests and process these messages in order to tunnel requests and process these messages in order to establish a
establish a tunnel. tunnel.
Discussion: Discussion:
When an initiator attempts to establish SAs with another IPsec When an initiator attempts to establish SAs with another IPsec
device, this peer will need to evaluate the proposals made by the device, this peer will need to evaluate the proposals made by the
initiator and either accept or deny them. In the former case, the initiator and either accept or deny them. In the former case, the
traffic flow will be decrypted according to the negotiated traffic flow will be decrypted according to the negotiated
parameters. Such a device will be called a Responder. parameters. Such a device will be called a Responder.
Issues: Issues:
IPsec devices/implementations can usually be both an initiator as IPsec devices/implementations can usually be both an initiator as
well as a responder. The distinction is useful from a test well as a responder. The distinction is useful from a test
perspective. perspective.
See Also: See Also:
Initiator, IKE Initiator, IKE
7.3.3 IPsec Client 7.6.3 IPsec Client
Definition: Definition:
IPsec Devices that will only act as an Initiator. IPsec Devices that will only act as an Initiator.
Discussion: Discussion:
In some situations it is not needed or prefered to have an IPsec In some situations it is not needed or prefered to have an IPsec
device respond to an inbound tunnel request. In the case of e.g. device respond to an inbound tunnel request. In the case of e.g.
road warriors or home office scenarios the only property needed road warriors or home office scenarios the only property needed
from the IPsec device is the ability to securely connect to a from the IPsec device is the ability to securely connect to a
remote private network. The IPsec Client will set up one or more remote private network. The IPsec Client will set up one or more
Tunnels to an IPSec Server on the network that needs to be Tunnels to an IPSec Server on the network that needs to be
accessed and to provide the required security services. IPsec accessed and to provide the required security services. An IPsec
clients are generally used to connect remote users in a secure client will silently drop and ignore any inbound tunnel requests.
fashion over the Internet to a private network. IPsec clients are generally used to connect remote users in a
secure fashion over the Internet to a private network.
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec device, IPsec Server, Initiator, Responder IPsec device, IPsec Server, Initiator, Responder
7.3.4 IPsec Server 7.6.4 IPsec Server
Definition: Definition:
IPSec Devices that can both act as an Initiator as well as a IPSec Devices that can both act as an Initiator as well as a
Responder. Responder.
Discussion: Discussion:
IPSec Servers are mostly positioned at private network edges and IPSec Servers are mostly positioned at private network edges and
provide several functions : provide several functions :
skipping to change at page 16, line 27 skipping to change at page 19, line 20
Responds to tunnel setup request from IPSec Clients. Responds to tunnel setup request from IPSec Clients.
Responds to tunnel setup request from other IPSec devices/ Responds to tunnel setup request from other IPSec devices/
Initiators. Initiators.
Initiate tunnels to other IPSec servers inside or outside the Initiate tunnels to other IPSec servers inside or outside the
private network. private network.
Issues: Issues:
IPsec Servers are also sometimes referred to as 'concentrators'. IPsec Servers are also sometimes referred to as 'VPN
Concentrators'.
See Also: See Also:
IPsec Device, IPsec Client, Initiator, Responder IPsec Device, IPsec Client, Initiator, Responder
7.4 ISAKMP 7.7 Tunnels
Definition:
The Internet Security Association and Key Management Protocol,
which provides a framework for authentication and key exchange but
does not define them. ISAKMP is designed to be key exchange
independent; it is designed to support many different key
exchanges. ISAKMP is defined in [RFC2407].
Discussion:
Though ISAKMP is only a framework for the IPsec standard key
management protocol, it is often misused and interchanged with the
term 'IKE', which is an implementation of ISAKMP. The term ISAKMP
SA is used by some vendors while others use IKE SA. Both refer to
IKE Phase 1 SA.
Issues:
N/A
See Also:
IKE The term "tunnel" is often used in a variety of contexts. To avoid
any discrepancies, in this document, the following distinctions have
been defined :
7.5 IKE 7.7.1 IKE Tunnel
Definition: Definition:
A hybrid protocol, defined in [RFC2409], from the following 3 One simplex Phase 1 IKE SA
protocols:
* ISAKMP (Internet Security Association and Key Management
Protocol), which provides a framework for authentication and
key exchange but does not define them. ISAKMP is designed to be
key exchange independent; it is designed to support many
different key exchanges.
* Oakley, which describes a series of key exchanges, called
modes, and details the services provided by each (for example,
perfect forward secrecy for keys, identity protection, and
authentication). [RFC2412]
* [SKEME] (Secure Key Exchange Mechanism for Internet), which
describes a versatile key exchange technique that provides
anonymity, reputability, and quick key refreshment.
Discussion: Discussion:
Note that IKE is an optional protocol within the IPsec framework An IKE Tunnel between IPSec devices facilitates a mechanism for
and that tunnels also can be manually keyed resulting in hardwired secure negotiation of Phase 1 properties and Phase 2 SA's needed
SA's as configured by the administrator. for protected data transport. The initiator may choose which mode
to start the negotiation of the IKE Tunnel in. This can be either
main mode or aggressive mode.
Issues: Issues:
During the first IPsec deployment experiences, ambiguities were Also referred to as an ISAKMP SA or IKE SA or Phase 1 Tunnel.
found in the IKEv1 specification, which lead to interoperability
problems. To resolve these issues, IKEv1 is being updated by
IKEv2.
See Also: See Also:
ISAKMP, IPsec Tunnel, IPsec Tunnel, Security Association, IKE, IKE Phase 1
7.6 Security Association (SA) 7.7.2 IPsec Tunnel
Definition: Definition:
A simplex (unidirectional) logical connection, created for One or more Phase 2 SA's that are negotiated in conjuntion with an
security purposes. All traffic traversing an SA is provided the IKE Tunnel.
same security processing. In IPsec, an SA is an Internet layer
abstraction implemented through the use of AH or ESP. [RFC2401]
Discussion: Discussion:
A set of policy and key(s) used to protect information. It is a In the case of simplex communication, a single phase 2 SA.
negotiation agreement between two IPsec devices, specifically the
Initiator and Responder.
Issues:
N/A
See Also:
Initiator, Responder
7.7 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: In the more likely case where bidirectional communication is
needed it is a pair (2) of Phase 2 SA's. The two SA's are used to
secure inbound and outbound traffic.
Note that IKE is an optional protocol within the IPsec framework Not in all situations is it required to have an existing IKE
and keys can also be manually configured. Tunnel in order to negotiate IPsec Tunnel properties and
parameters. Manually keyed tunnels allow the set up of IPsec
Tunnels without the need of the IKE protocol.
Issues: Issues:
In other documents can be referenced as ISAKMP SA or IKE SA. Also referred to as a Phase 2 Tunnel or a Phase 2 SA (may be
multiple).
See Also: See Also:
IKE, ISAKMP Tunnel, IKE Tunnel, Security Association, IKE, IKE Phase 2
7.7.1 Phase 1 Main Mode 7.7.3 Tunnel
Definition: Definition:
Main Mode is an instantiation of the ISAKMP Identity Protect The combination of an IKE Tunnel and an IPsec Tunnel
Exchange, defined in [RFC2409]. Upon successful completion it
results in the establishment of an IKE Phase 1 SA.
Discussion: Discussion:
IKE Main Mode use 3 distinct message pairs, for a total of 6 In the majority of the cases IPsec is used to protect
messages. The first two messages negotiate policy; the next two bidirectional traffic flows. Unless stated otherwise a 'Tunnel'
represent Diffie-Hellman public values and ancillary data (e.g. will be defined as a single Phase 1 SA and two Phase 2 SA's that
nonces); and the last two messages authenticate the Diffie-Hellman are associated with the Phase 1 SA.
Exchange. The authentication method negotiated as part of the
initial IKE Phase 1 influence the composition of the payloads but
not their purpose.
Issues: Issues:
N/A If only a single Phase 2 SA or more then two Phase 2 SA's have
been negotiated through a single IKE Tunnel, then this specific
ratio must be mentioned and the term 'Tunnel' MUST NOT be used in
this context.
See Also: See Also:
ISAKMP, IKE, IKE Phase 1, Phase 1 Aggressive Mode IKE Tunnel, IPsec Tunnel
7.7.2 Phase 1 Aggressive Mode 7.7.4 Configured Tunnel
Definition: Definition:
Aggressive Mode is an instantiation of the ISAKMP Aggressive A tunnel that is present in the IPSec device's configuration but
Exchange, defined in [RFC2409]. Upon successful completion it does not have any entries in the SAD i.e. SA's.
results in the establishment of an IKE Phase 1 SA.
Discussion: Discussion:
IKE Aggressive Mode uses 3 messages. The first two messages Several steps are required before a Tunnel can be used to actually
negotiate policy, exchange Diffie-Hellman public values and transport traffic. The very first step is to configure the tunnel
ancillary data necessary for the exchange, and identities. In in the IPsec device. In that way packet classification can make a
addition the second message authenticates the Responder. The third decision if it is required to start negotiating SA's. At this time
message authenticates the Initiator and provides proof of there are no SA's associated with the Tunnel and no traffic is
participation in the exchange. going through the IPsec device that matches the Selectors, which
would instantiate the Tunnel.
Issues:
For IKEv1 the standard specifies that all implementations use both
main and agressive mode, however, it is common to use only main
mode.
See Also:
ISAKMP, IKE, IKE Phase 1, Phase 1 Main Mode
7.8 IKE Phase 2
Definition:
Protocol which upon successful completion establishes the shared
keys used by negotiating peers to set up a secure "data channel"
for IPsec.
Discussion:
The main purpose of Phase 2 is to produce the key for the IPsec A Configured Tunnel is also a tunnel that has relinquished all
tunnel. Phase 2 is also used to regenerate the key being used for it's SA's and is not transmitting data anymore. To be more
IPsec (called "rekeying"), as well as for exchanging informational specific, when an Established or an Active Tunnel is terminated
messages. due to either an administrative action or an IKE event that teared
down the tunnel, the tunnel will be back in a solely configured
state.
Issues: Issues:
In other documents also referenced as IPsec SA. N/A
See Also: See Also:
IKE Phase 1, ISAKMP, IKE Tunnel, Established Tunnel, Active Tunnel
7.8.1 Phase 2 Quick Mode
7.7.5 Established Tunnel
Definition: Definition:
A SA negotiation and an exchange of nonces that provide replay A Tunnel that has completed Phase 1 and Phase 2 SA negotiations
protection. but is otherwise idle.
Discussion: Discussion:
Quick Mode is not a complete exchange itself (it is bound to a A second step needed to ensure that a Tunnel can transport data is
phase 1 exchange), but is used as part of the SA negotiation to complete the Phase 1 and Phase 2 negotiations. After the packet
process (phase 2) to derive keying material and negotiate shared classification process has asserted that a packet requires
policy for non-ISAKMP SA's. The ISAKMP SA protects the information security services, the negotation is started to obtain both Phase
exchanged along with Quick Mode, i.e. all payloads except the 1 and Phase 2 SA's. After this is completed the tunnel is called
ISAKMP header are encrypted. Also, an optional Key Exchange 'Established'. Note that at this time there is still no traffic
payload can be exchanged to allow for an additional Diffie-Hellman flowing through the Tunnel. Just enough packet(s) have been sent
exchange, PFS and exponentiation per Quick Mode. to the IPsec device that matched the selectors and triggered the
Tunnel setup. This may also be acomplished by an administrative
command to connect the Tunnel, in which case the Tunnel is not
triggered by any positive packet classification.
Issues: Issues:
N/A In the case of manually keyed tunnels, there is no distinction
between a Configured Tunnel or an Established Tunnel since there
is no negotiation required with these type of Tunnels and the
Tunnel is Established at time of Configuration since all keying
information is known at that point.
See Also: See Also:
ISAKMP, IKE, IKE Phase 2 Tunnel, Configured Tunnel, Active Tunnel
7.8.2 IPsec Tunnel 7.7.6 Active Tunnel
Definition: Definition:
A bidirectional IPsec SA which is set up as part of IKE phase 2. A tunnel that has completed Phase 1 and Phase 2 SA negotiations
It creates the secure data exchange channel. and is transmitting data.
Discussion: Discussion:
Manually keyed IPsec tunnels differ from tunnels that are When a Tunnel is Established and it is transporting traffic, the
negotiated by IKE in that there is no setup time for them, which tunnel is called 'Active'.
would have an effect on tunnel setup rate. For this reason some
metrics will be eliminated from the test methodology matrix,
specific to manually keyed IPsec tunnels, i.e. Phase 1 Setup Rate.
Issues: Issues:
N/A The distinction between an Active Tunnel and Configured/
Established Tunnel is made in the context of manual keyed Tunnels.
In this case it would be possible to have an Established tunnel on
an IPsec device which has no counterpart on it's corresponding
peer. This will lead to encrypted traffic flows which will be
discarded on the receiving peer. Only if both peers have an
Established Tunnel that shows evidence of traffic transport, it
may be called an Active Tunnel.
See Also: See Also:
IPsec, IKE, IKE Phase 2 Tunnel, Configured Tunnel, Established Tunnel
7.9 Iterated Tunnels 7.8 Iterated Tunnels
Iterated Tunnels are a bundle of transport and/or tunnel mode SA's. Iterated Tunnels are a bundle of transport and/or tunnel mode SA's.
The bundles are divided into two major groups : The bundles are divided into two major groups :
7.9.1 Nested Tunnels 7.8.1 Nested Tunnels
Definition: Definition:
An SA bundle consisting of two or more 'tunnel mode' SA's. An SA bundle consisting of two or more 'tunnel mode' SA's.
Discussion: Discussion:
The process of nesting tunnels can theoretically be repeated The process of nesting tunnels can theoretically be repeated
multiple times (for example, tunnels can be many levels deep), but multiple times (for example, tunnels can be many levels deep), but
for all practical purposes, most implementations limit the level for all practical purposes, most implementations limit the level
skipping to change at page 22, line 40 skipping to change at page 24, line 16
branch offices. branch offices.
Issues: Issues:
N/A N/A
See Also: See Also:
Transport Adjacency, IPsec Tunnel Transport Adjacency, IPsec Tunnel
7.9.2 Transport Adjacency 7.8.2 Transport Adjacency
Definition: Definition:
An SA bundle consisting of two or more transport mode SA's. An SA bundle consisting of two or more transport mode SA's.
Discussion: Discussion:
Transport adjacency is a form of tunnel nesting. In this case two Transport adjacency is a form of tunnel nesting. In this case two
or more transport mode IPsec tunnels are set side by side to or more transport mode IPsec tunnels are set side by side to
enhance applied security properties. enhance applied security properties.
skipping to change at page 23, line 33 skipping to change at page 25, line 9
[IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH] [IP][ESP][AH][PAYLOAD][ESP TRAILER][ESP AUTH]
Issues: Issues:
This is rarely used. This is rarely used.
See Also: See Also:
Nested Tunnels, IPsec Tunnel Nested Tunnels, IPsec Tunnel
7.10 Transform protocols 7.9 Transform protocols
Definition: Definition:
Encryption and authentication algorithms that provide Encryption and authentication algorithms that provide
cryptograhical services to the IPsec Protocols. cryptograhical services to the IPsec Protocols.
Discussion: Discussion:
Some algorithms run significantly slower than others. For example, Some algorithms run significantly slower than others. For example,
TripleDES encryption is one third as fast as DES encryption. TripleDES encryption is one third as fast as DES encryption.
skipping to change at page 24, line 4 skipping to change at page 25, line 24
cryptograhical services to the IPsec Protocols. cryptograhical services to the IPsec Protocols.
Discussion: Discussion:
Some algorithms run significantly slower than others. For example, Some algorithms run significantly slower than others. For example,
TripleDES encryption is one third as fast as DES encryption. TripleDES encryption is one third as fast as DES encryption.
Issues: Issues:
N/A N/A
See Also: See Also:
Authentication protocols, Encryption protocols Authentication protocols, Encryption protocols
7.10.1 Authentication Protocols 7.9.1 Authentication Protocols
Definition: Definition:
Algorithms which provide data integrity and data source Algorithms which provide data integrity and data source
authentication. authentication.
Discussion: Discussion:
Authentication protocols provide no confidentiality. Commonly used Authentication protocols provide no confidentiality. Commonly used
authentication algorithms/protocols are: authentication algorithms/protocols are:
skipping to change at page 24, line 33 skipping to change at page 26, line 9
Issues: Issues:
SHA-HMAC is thought to be more secure than MD5-HMAC and is often SHA-HMAC is thought to be more secure than MD5-HMAC and is often
used. AES-HMAC is still fairly new and not in common use yet. used. AES-HMAC is still fairly new and not in common use yet.
See Also: See Also:
Transform protocols, Encryption protocols Transform protocols, Encryption protocols
7.10.2 Encryption Protocols 7.9.2 Encryption Protocols
Definition: Definition:
Algorithms which provide data confidentiality. Algorithms which provide data confidentiality.
Discussion: Discussion:
Encryption protocols provide no authentication. Commonly used Encryption protocols provide no authentication. Commonly used
encryption algorithms/protocols are: encryption algorithms/protocols are:
skipping to change at page 25, line 18 skipping to change at page 26, line 39
protocols, and is commonly used. protocols, and is commonly used.
DES has been officially deprecated by NIST, though it is still DES has been officially deprecated by NIST, though it is still
mandated RFC and is still commonly implemented and used due to mandated RFC and is still commonly implemented and used due to
it's speed advantage over 3DES. it's speed advantage over 3DES.
See Also: See Also:
Transform protocols, Authentication protocols Transform protocols, Authentication protocols
7.11 IPSec Protocols 7.10 IPSec Protocols
Definition: Definition:
A suite of protocols which provide a framework of open standards A suite of protocols which provide a framework of open standards
that provides data confidentiality, data integrity, and data that provides data confidentiality, data integrity, and data
authenticity between participating peers at the IP layer. The authenticity between participating peers at the IP layer. The
IPsec protocol suite set of standards is documented in RFC's 2401 IPsec protocol suite set of standards is documented in RFC's 2401
through 2412 and RFC 2451. through 2412 and RFC 2451.
Discussion: Discussion:
skipping to change at page 25, line 43 skipping to change at page 27, line 20
obsolete. For example, IKEv2 will soon replace IKEv1. obsolete. For example, IKEv2 will soon replace IKEv1.
Issues: Issues:
N/A N/A
See Also: See Also:
AH, ESP AH, ESP
7.11.1 Authentication Header (AH) 7.10.1 Authentication Header (AH)
Definition: Definition:
Provides authentication and data integrity (including replay Provides authentication and data integrity (including replay
protection) security services [RFC2402]. protection) security services [RFC2402].
Discussion: Discussion:
The AH protocol supports both modes of operation; tunnel mode and The AH protocol supports both modes of operation; tunnel mode and
transport mode. If AH is employed in tunnel mode, portions of the transport mode. If AH is employed in tunnel mode, portions of the
skipping to change at page 26, line 32 skipping to change at page 28, line 8
Issues: Issues:
AH is rarely used/implemented. AH is rarely used/implemented.
See Also: See Also:
Transform protocols, IPsec protocols, Encapsulated Security Transform protocols, IPsec protocols, Encapsulated Security
Payload Payload
7.11.2 Encapsulated Security Payload (ESP) 7.10.2 Encapsulated Security Payload (ESP)
Definition: Definition:
Provides three essential components needed for secure data Provides three essential components needed for secure data
exchange: authentication, integrity (including replay protection) exchange: authentication, integrity (including replay protection)
and confidentiality [RFC2406]. and confidentiality as defined in [RFC2406].
Discussion: Discussion:
The ESP protocol supports both modes of operation; tunnel mode and The ESP protocol supports both modes of operation i.e. tunnel mode
transport mode. If ESP is employed in tunnel mode, the protection and transport mode. If ESP is employed in tunnel mode, the
is afforded only to the tunneled packet, not to the outer header protection is afforded only to the tunneled packet, not to the
In the case of ESP in transport mode, security services are outer header. In the case of ESP in transport mode, security
provided only for the higher-layer protocols, not for the IP services are provided only for the higher-layer protocols, not for
header. the IP header.
Original IPv4 packet : Original IPv4 packet :
[IP ORIG][L4 HDR][PAYLOAD] [IP ORIG][L4 HDR][PAYLOAD]
In transport mode : In transport mode :
[IP ORIG][ESP][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] [IP ORIG][ESP][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH]
In tunnel mode : In tunnel mode :
[IP NEW][ESP][IP ORIG][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH] [IP NEW][ESP][IP ORIG][L4 HDR][PAYLOAD][ESP TRAILER][ESP AUTH]
Issues: Issues:
N/A N/A
See Also: See Also:
Transform protocols, IPsec protocols, Authentication Header Transform protocols, IPsec protocols, Authentication Header
7.12 Selectors 7.11 NAT Traversal (NAT-T)
Definition:
A criteria used by a classification 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.
Selectors classify specific IP packets that require IPsec
processing. Selectors also define those packets that must be
discarded or passed along without modification. These are flexible
objects that can match on source and destination addresses, range
of IP addresses, wildcard addresses, different protocols, and
different port numbers (like FTP) within a protocol.
Discussion:
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:
Both sides must agree exactly on both the networks being
protected, and they both must agree on how to describe the
networks (range, subnet, addresses). This is a common point of
non-interoperability.
7.13 NAT Traversal (NAT-T)
Definition: Definition:
The capability to support IPsec functionality in the presence of The capability to support IPsec functionality in the presence of
NAT devices. NAT devices.
Discussion: Discussion:
NAT-Traversal requires some modifications to IKE. Specifically, in NAT-Traversal requires some modifications to IKE as defined in
phase 1, it requires detecting if the other end supports [I-D.ietf-ipsec-nat-t-ike]. Specifically, in phase 1, it requires
NAT-Traversal, and detecting if there are one or more NAT detecting if the other end supports NAT-Traversal, and detecting
instances along the path from host to host. In IKE Quick Mode, if there are one or more NAT instances along the path from host to
there is a need to negotiate the use of UDP encapsulated IPsec host. In IKE Quick Mode, there is a need to negotiate the use of
packets. UDP encapsulated IPsec packets.
NAT-T also describes how to transmit the original source and NAT-T also describes how to transmit the original source and
destination addresses to the other end if needed. The original destination addresses to the corresponding IPsec Device. The
source and destination addresses are used in transport mode to original source and destination addresses are used in transport
incrementally update the TCP/IP checksums so that they will match mode to incrementally update the TCP/IP checksums so that they
after the NAT transform (The NAT cannot do this, because the TCP/ will match after the NAT transform (The NAT cannot do this,
IP checksum is inside the UDP encapsulated IPsec packet). because the TCP/IP checksum is inside the UDP encapsulated IPsec
packet).
Issues: Issues:
N/A N/A
See Also: See Also:
IKE IKE
7.14 IP Compression 7.12 IP Compression
Definition: Definition:
A mechanism as defined in [RFC2393] that reduces the size of the A mechanism as defined in [RFC2393] that reduces the size of the
payload that needs to be encrypted. payload that needs to be encrypted.
Discussion: Discussion:
IP payload compression is a protocol to reduce the size of IP IP payload compression is a protocol to reduce the size of IP
datagrams. This protocol will increase the overall communication datagrams. This protocol will increase the overall communication
skipping to change at page 29, line 16 skipping to change at page 30, line 9
applied to IP datagrams. Encrypting the IP datagram causes the applied to IP datagrams. Encrypting the IP datagram causes the
data to be random in nature, rendering compression at lower data to be random in nature, rendering compression at lower
protocol layers (e.g., PPP Compression Control Protocol [RFC1962]) protocol layers (e.g., PPP Compression Control Protocol [RFC1962])
ineffective. If both compression and encryption are required, ineffective. If both compression and encryption are required,
compression must be applied before encryption. compression must be applied before encryption.
Issues: Issues:
N/A N/A
7.15 Security Context 7.13 Security Context
Definition: Definition:
A security context is a collection of security parameters that A security context is a collection of security parameters that
describe the characteristics of the path that a tunnel will take, describe the characteristics of the path that a tunnel will take,
all of the tunnel parameters and the effects it has on the all of the tunnel parameters and the effects it has on the
underlying protected traffic. Security Context encompasses underlying protected traffic. Security Context encompasses
protocol suite and security policy(ies). protocol suite and security policy(ies).
Discussion: Discussion:
skipping to change at page 31, line 10 skipping to change at page 32, line 5
Issues: Issues:
A Security Context will be an important element in describing the A Security Context will be an important element in describing the
environment where protected traffic is traveling through. environment where protected traffic is traveling through.
See Also: See Also:
IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2, IPsec Protocols, Transform Protocols, IKE Phase 1, IKE phase 2,
Selectors, IPsec Tunnel Selectors, IPsec Tunnel
8. Performance Metrics 8. Framesizes
8.1 Tunnels Per Second (TPS)
Definition:
Tunnels Per Second; the measurement unit for the Tunnel Setup Rate
tests. The rate that tunnels are established per second.
Discussion:
According to rfc 2401 two tunnels cannot be established between
the same gateways with the same selectors. This is to prevent
overlapping tunnels. If overlapping tunnels are attempted, the
error will take longer than if the tunnel setup was successful.
For this reason, a unique pair of selector sets are required for
TPS testing.
Issues:
A unique pair of selector sets are required for TPS testing.
See Also:
Tunnel Setup Rate Behavior; Tunnel Setup Rate, IKE Setup Rate,
IPsec Setup Rate
8.2 Tunnel Rekeys Per Seconds (TRPS)
Definition:
A metric that quantifies the number of tunnel rekey's per seconds
a DUT can correctly process.
Discussion:
This metric will be will be primary used with Tunnel Rekey
behavior tests.
TRPS will provide a metric used to see system behavior under
stressful conditions where large volumes of tunnels are being
rekeyed at the same time or in a short timespan.
Issues:
N/A
See Also:
Tunnel Rekey; Phase 1 Rekey Rate, Phase 2 Rekey Rate
8.3 Tunnel Attempts Per Second (TAPS)
Definition:
A metric that quantifies the number of valid or invalid tunnel
(both Phase 1 or Phase 2) establishment requests per second.
Discussion:
This metric can be used to measure IKE DOS Resilience behavior
test.
TAPS provides an important metric to validate the stability of a
platform, if stressed with valid (large number of IPsec tunnel
establishments per seconds or TPS) or invalid (IKE DOS attacks of
any style) tunnel establishment requests.
Issues:
If the TAPS increases, the TPS usually decreases, due to burdening
of the DUT with the DOS attack traffic.
9. Test Definitions
9.1 Framesizes
9.1.1 Layer3 clear framesize 8.1 Layer3 clear framesize
Definition: Definition:
The total size of the unencrypted L3 PDU. The total size of the unencrypted L3 PDU.
Discussion: Discussion:
In relation to IPsec this is the size of the IP header and its In relation to IPsec this is the size of the IP header and its
payload. It SHALL NOT include any encapsulations that MAY be payload. It SHALL NOT include any encapsulations that MAY be
applied before the PDU is processed for encryption. applied before the PDU is processed for encryption.
For example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload. For example: 46 bytes PDU = 20 bytes IP header + 26 bytes payload.
Measurement Units: Measurement Units:
Bytes Bytes
Issues: Issues:
N/A N/A
See Also: See Also:
Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2 Layer3 Encrypted Framesize, Layer2 Clear Framesize, Layer2
Encrypted Framesize. Encrypted Framesize.
9.1.2 Layer3 encrypted framesize 8.2 Layer3 encrypted framesize
Definition: Definition:
The total size of the encrypted L3 PDU. The total size of the encrypted L3 PDU.
Discussion: Discussion:
The size of the IP packet and its payload after encapsulations The size of the IP packet and its payload after encapsulations
MAY be applied and the PDU is being processed by the transform. MAY be applied and the PDU is being processed by the transform.
For example, after a tunnel mode ESP 3DES/SHA1 transform has been For example, after a tunnel mode ESP 3DES/SHA1 transform has been
applied an unencrypted or clear layer3 framesize of 46 bytes applied an unencrypted or clear layer3 framesize of 46 bytes
Becomes 96 bytes: Becomes 96 bytes:
20 bytes outer IP header (tunnel mode) 20 bytes outer IP header (tunnel mode)
4 bytes SPI (ESP header) 4 bytes SPI (ESP header)
4 bytes Sequence (ESP Header) 4 bytes Sequence (ESP Header)
8 bytes IV (IOS ESP-3DES) 8 bytes IV (IOS ESP-3DES)
skipping to change at page 34, line 17 skipping to change at page 33, line 28
Issues: Issues:
N/A N/A
See Also: See Also:
Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted Layer3 Clear Framesize, Layer2 Clear Framesize, Layer2 Encrypted
Framesize. Framesize.
9.1.3 Layer2 clear framesize 8.3 Layer2 clear framesize
Definition: Definition:
The total size of the unencrypted L2 PDU. The total size of the unencrypted L2 PDU.
Discussion: Discussion:
This is the Layer 3 clear framesize plus all the layer2 overhead. This is the Layer 3 clear framesize plus all the layer2 overhead.
In the case of Ethernet this would be 18 bytes. In the case of Ethernet this would be 18 bytes.
skipping to change at page 35, line 5 skipping to change at page 34, line 17
Issues: Issues:
If it is not mentioned explicitly what kind of framesize is used, If it is not mentioned explicitly what kind of framesize is used,
the layer2 clear framesize will be the default. the layer2 clear framesize will be the default.
See Also: See Also:
Layer3 clear framesize, Layer2 encrypted framesize, Layer2 Layer3 clear framesize, Layer2 encrypted framesize, Layer2
encrypted framesize. encrypted framesize.
9.1.4 Layer2 encrypted framesize 8.4 Layer2 encrypted framesize
Definition: Definition:
The total size of the encrypted L2 PDU. The total size of the encrypted L2 PDU.
Discussion: Discussion:
This is the Layer 3 encrypted framesize plus all the layer2 This is the Layer 3 encrypted framesize plus all the layer2
overhead. In the case of Ethernet this would be 18 bytes. overhead. In the case of Ethernet this would be 18 bytes.
skipping to change at page 35, line 38 skipping to change at page 35, line 5
Issues: Issues:
N/A N/A
See Also: See Also:
Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2 Clear Layer3 Clear Framesize, Layer3 Encrypted Framesize, Layer2 Clear
Framesize Framesize
9.2 Internet Mix Traffic (IMIX) 9. Performance Metrics
9.1 Tunnels Per Second (TPS)
Definition: Definition:
A traffic pattern consisting of a preset mixture of framesizes The measurement unit for the Tunnel Setup Rate tests. The rate
used to emulate real-world traffic scenarios in a testing that Tunnels are established per second.
environment.
Discussion: Discussion:
IMIX traffic patterns can be used to measure different forwarding According to [RFC2401] two tunnels cannot be established between
behaviors of the IPsec device with pseudo live traffic. the same gateways with the same selectors. This is to prevent
overlapping tunnels. If overlapping tunnels are attempted, the
error will take longer than if the tunnel setup was successful.
For this reason, a unique pair of selector sets are required for
TPS testing.
Several facilities have collected and reported traffic Issues:
distribution by monitoring live Internet links. The study
concluded that in a simulation environment, a small mix of packets A unique pair of selector sets are required for TPS testing.
in a preset ratio can resemble to a certain degree the live
traffic that was monitored during the study. One of the mixes is See Also:
called (simple) and consists of 7 parts 64 byte packets, 4 parts
570 byte packets and 1 1518 byte packet. Tunnel Setup Rate Behavior, Tunnel Setup Rate, IKE Setup Rate,
IPsec Setup Rate
9.2 Tunnel Rekeys Per Seconds (TRPS)
Definition:
A metric that quantifies the number of IKE or IPsec Tunnel rekey's
per seconds a DUT can correctly process.
Discussion:
This metric will be will be primary used with Tunnel Rekey
behavior tests.
TRPS will provide a metric used to see system behavior under
stressful conditions where large volumes of tunnels are being
rekeyed at the same time or in a short timespan.
Issues: Issues:
The ratio of frame sizes sent and traffic distribution to be N/A
determined by the test methodology.
9.3 Throughput See Also:
9.3.1 IPsec Tunnel Throughput Tunnel Rekey; Phase 1 Rekey Rate, Phase 2 Rekey Rate
9.3 Tunnel Attempts Per Second (TAPS)
Definition: Definition:
The forwarding rate through an IKE/IPsec tunnel at which none of A metric that quantifies the number of successful and unsuccessful
the offered frames are dropped by the device under test. tunnel (both Phase 1 or Phase 2) establishment requests per
second.
Discussion:
This metric can be used to measure IKE DOS Resilience behavior
test.
TAPS provides an important metric to validate the stability of a
platform, if stressed with valid (large number of IPsec tunnel
establishments per seconds or TPS) or invalid (IKE DOS attacks of
any style) tunnel establishment requests.
Issues:
If the TAPS increases, the TPS usually decreases, due to burdening
of the DUT with the DOS attack traffic.
10. Test Definitions
10.1 Throughput
10.1.1 Tunnel Throughput
Definition:
The maximum rate through an IPsec tunnel at which none of the
offered frames are dropped by the device under test.
Discussion: Discussion:
The IPsec Tunnel Throughput is almost identically defined as The IPsec Tunnel Throughput is almost identically defined as
Throughput in [RFC1242], section 3.17. The only difference is that Throughput in [RFC1242], section 3.17. The only difference is that
the throughput is measured with a traffic flow getting encrypted the throughput is measured with a traffic flow getting encrypted
and decrypted by an IPsec device. The Tunnel Throughput is an and decrypted by an IPsec device. IPsec Tunnel Throughput is an
end-to-end measurement and is intended to characterize end-user end-to-end measurement.
forwarding behavior.
The metric can be represented in two variants depending on where The metric can be represented in two variantions depending on
measurement is taken in the SUT. One can look at throughput from a where measurement is taken in the SUT. One can look at throughput
cleartext point of view i.e. find the forwarding rate where from a cleartext point of view i.e. find the maximum rate where
clearpackets no longer get dropped. This forwarding rate can be clearpackets no longer get dropped. This resulting rate can be
recalculated with an encrypted framesize to represent the recalculated with an encrypted framesize to represent the
encryption forwarding rate. The latter is the preferred method of encryption throughput rate. The latter is the preferred method of
representation. representation.
Measurement Units: Measurement Units:
Packets per seconds (pps), Mbps Packets per seconds (pps), Mbps
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Encryption Throughput, IPsec Decryption Throughput IPsec Encryption Throughput, IPsec Decryption Throughput
9.3.2 IPsec Encryption Throughput 10.1.2 IPsec Encryption Throughput
Definition: Definition:
The maximum encryption rate through an IPsec tunnel at which none The maximum encryption rate through an IPsec tunnel at which none
of the offered cleartext frames are dropped by the device under of the offered cleartext frames are dropped by the device under
test. test.
Discussion: Discussion:
Since encryption throughput is not necessarily equal to the Since encryption throughput is not necessarily equal to the
skipping to change at page 37, line 41 skipping to change at page 38, line 11
Packets per seconds (pps), Mbps Packets per seconds (pps), Mbps
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Throughput, IPsec Decryption Throughput IPsec Tunnel Throughput, IPsec Decryption Throughput
9.3.3 IPsec Decryption Throughput 10.1.3 IPsec Decryption Throughput
Definition: Definition:
The maximum decryption rate through an IPsec tunnel at which none The maximum decryption rate through an IPsec tunnel at which none
of the offered encrypted frames are dropped by the device under of the offered encrypted frames are dropped by the device under
test. test.
Discussion: Discussion:
Since encryption throughput is not necessarily equal to the Since encryption throughput is not necessarily equal to the
skipping to change at page 38, line 29 skipping to change at page 38, line 43
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also:
IPsec Tunnel Throughput, IPsec Encryption Throughput IPsec Tunnel Throughput, IPsec Encryption Throughput
9.4 Latency 10.2 Latency
9.4.1 Tunnel Latency 10.2.1 Tunnel Latency
Definition: Definition:
Tunnel Latency is the delay introduced when sending traffic Time required to propagate a cleartext frame from the input
through an established IPsec tunnel between two interconnected interface of an initiator, through an IPsec Tunnel, to the output
IPsec devices. interface of the responder.
Discussion: Discussion:
The Tunnel Latency is the time interval starting when the end of The Tunnel Latency is the time interval starting when the end of
the first bit of the cleartext frame reaches the input interface the first bit of the cleartext frame reaches the input interface
of the encrypting router, and ending when the start of the first of the initiator and ending when the start of the first bit of the
bit of the cleartext frame is seen on the output interface of the same cleartext frame is detected on the output interface of the
decrypting router. responder. The frame has passed through an IPsec Tunnel between an
initiator and a responder and has been through an encryption and
decryption cycle.
Measurement Units: Measurement Units:
Time units with enough precision to reflect latency measurement. Time units with enough precision to reflect latency measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Encryption Latency, IPsec Tunnel Decryption Latency IPsec Tunnel Encryption Latency, IPsec Tunnel Decryption Latency
9.4.2 IPsec Tunnel Encryption Latency 10.2.2 IPsec Tunnel Encryption Latency
Definition: Definition:
The IPsec Tunnel Encryption Latency is the time interval starting The IPsec Tunnel Encryption Latency is the time interval starting
when the end of the first bit of the cleartext frame reaches the when the end of the first bit of the cleartext frame reaches the
input interface, through an IPsec tunnel, and ending when the input interface, through an IPsec tunnel, and ending when the
start of the first bit of the encrypted output frame is seen on start of the first bit of the encrypted output frame is seen on
the output interface. the output interface.
Discussion: Discussion:
skipping to change at page 39, line 49 skipping to change at page 40, line 21
Measurement Units: Measurement Units:
Time units with enough precision to reflect latency measurement. Time units with enough precision to reflect latency measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Decryption Latency IPsec Tunnel Latency, IPsec Tunnel Decryption Latency
9.4.3 IPsec Tunnel Decryption Latency 10.2.3 IPsec Tunnel Decryption Latency
Definition: Definition:
The IPsec Tunnel decryption Latency is the time interval starting The IPsec Tunnel decryption Latency is the time interval starting
when the end of the first bit of the encrypted frame reaches the when the end of the first bit of the encrypted frame reaches the
input interface, through an IPsec tunnel, and ending when the input interface, through an IPsec tunnel, and ending when the
start of the first bit of the decrypted output frame is seen on start of the first bit of the decrypted output frame is seen on
the output interface. the output interface.
Discussion: Discussion:
skipping to change at page 40, line 40 skipping to change at page 41, line 13
Measurement Units: Measurement Units:
Time units with enough precision to reflect latency measurement. Time units with enough precision to reflect latency measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Encryption Latency IPsec Tunnel Latency, IPsec Tunnel Encryption Latency
9.4.4 Time To First Packet 10.2.4 Time To First Packet
Definition: Definition:
The Time To First Packet (TTFP) is the time required process an The Time To First Packet (TTFP) is the time required process an
cleartext packet when no tunnel is present. cleartext packet when no tunnel is present.
Discussion: Discussion:
The TTFP addresses the issue of responsiveness of an IPsec device 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 by looking how long it take to transmit a packet over a not yet
skipping to change at page 41, line 27 skipping to change at page 41, line 46
example, ARP and/or IKE. example, ARP and/or IKE.
Measurement Units: Measurement Units:
Time units with enough precision to reflect a TTFP measurement. Time units with enough precision to reflect a TTFP measurement.
Issues: Issues:
N/A N/A
9.5 Frame Loss Rate 10.3 Frame Loss Rate
9.5.1 Tunnel Frame Loss Rate
10.3.1 IPSec Tunnel Frame Loss Rate
Definition: Definition:
Percentage of cleartext frames that should have been forwarded Percentage of cleartext frames that should have been forwarded
through an IPsec tunnel under steady state (constant) load but through a Tunnel under steady state (constant) load but were
were dropped. dropped before encryption or after decryption.
Discussion: Discussion:
DUT's will always have an inherent forwarding limitation. This The IPsec Tunnel Frame Loss Rate is almost identically defined as
will be more pronounced when IPsec is employed on the DUT. The Frame Loss Rate in [RFC1242], section 3.6. The only difference is
instant that a Tunnel is established and offered traffic that will that the IPsec Tunnel Frame Loss Rate is measured with a traffic
flow through that tunnel at a constant rate, the possibility flow getting encrypted and decrypted by an IPsec device. IPsec
exists that either the offerred traffic rate at the tunnel is too Tunnel Frame Loss Rate is an end-to-end measurement.
high to be transported. This traffic may not be successful through
the IPsec tunnel and not all cleartext packets will traverse an
established tunnel between two interconnected IPsec devices. In
that case, some percentage of the traffic will be dropped. This
drop percentage is called the Tunnel Frame Loss Rate.
Measurement Units: Measurement Units:
Percent (%) Percent (%)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Encryption Frame Loss Rate, IPsec Tunnel Decryption IPsec Tunnel Encryption Frame Loss Rate, IPsec Tunnel Decryption
Frame Loss Rate Frame Loss Rate
9.5.2 IPsec Tunnel Encryption Frame Loss Rate 10.3.2 IPsec Tunnel Encryption Frame Loss Rate
Definition: Definition:
Percentage of cleartext frames that should have been encrypted Percentage of cleartext frames that should have been encrypted
through an IPsec tunnel under steady state (constant) load but through an IPsec tunnel under steady state (constant) load but
were dropped. were dropped.
Discussion: Discussion:
DUT's will always have an inherent forwarding limitation. This DUT's will always have an inherent forwarding limitation. This
skipping to change at page 42, line 48 skipping to change at page 43, line 15
Measurement Units: Measurement Units:
Percent (%) Percent (%)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Decryption Frame Loss Rate IPsec Tunnel Frame Loss Rate, IPsec Tunnel Decryption Frame Loss
Rate
9.5.3 IPsec Tunnel Decryption Frame Loss Rate 10.3.3 IPsec Tunnel Decryption Frame Loss Rate
Definition: Definition:
Percentage of encrypted frames that should have been decrypted Percentage of encrypted frames that should have been decrypted
through an IPsec tunnel under steady state (constant) load but through an IPsec tunnel under steady state (constant) load but
were dropped. were dropped.
Discussion: Discussion:
A DUT will also have an inherent forwarding limitation when A DUT will also have an inherent forwarding limitation when
skipping to change at page 43, line 34 skipping to change at page 43, line 47
Measurement Units: Measurement Units:
Percent (%) Percent (%)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Encryption Frame Loss Rate IPsec Tunnel Frame Loss Rate, IPsec Tunnel Encryption Frame Loss
Rate
9.6 Back-to-back Frames 10.4 Back-to-back Frames
9.6.1 Tunnel Back-to-back Frames 10.4.1 Tunnel Back-to-back Frames
Definition: Definition:
A burst of cleartext frames, offered at a constant load that can A burst of cleartext frames, offered at a constant load that can
be sent through an IPsec tunnel without losing a single frame. be sent through an IPsec tunnel without losing a single cleartext
frame after decryption.
Discussion: Discussion:
Tunnel back-to-back frames is the measure of the maximum burst The Tunnel Back-to-back Frames is almost identically defined as
size of cleartext frames that can be sent through an established Back-to-back in [RFC1242], section 3.1. The only difference is
tunnel between two interconnected IPsec devices. that the Tunnel Back-to-back Frames is measured with a traffic
flow getting encrypted and decrypted by an IPsec device. Tunnel
Back-to-back Frames is an end-to-end measurement.
Measurement Units: Measurement Units:
Number of N-octet frames in burst. Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also:
Encryption Back-to-back frames, Decryption Back-to-back frames Encryption Back-to-back frames, Decryption Back-to-back frames
9.6.2 Encryption Back-to-back Frames 10.4.2 Encryption Back-to-back Frames
Definition: Definition:
A burst of cleartext frames, offered at a constant load that can A burst of cleartext frames, offered at a constant load that can
be sent through an IPsec tunnel without losing a single encrypted be sent through an IPsec tunnel without losing a single encrypted
frame. frame.
Discussion: Discussion:
Encryption back-to-back frames is the measure of the maximum burst Encryption back-to-back frames is the measure of the maximum burst
skipping to change at page 44, line 49 skipping to change at page 45, line 19
Number of N-octet frames in burst. Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also:
Decryption Back-to-back frames Tunnel Back-to-back frames, Decryption Back-to-back frames
9.6.3 Decryption Back-to-back Frames 10.4.3 Decryption Back-to-back Frames
Definition: Definition:
The number of encrypted frames, offered at a constant load, that The number of encrypted frames, offered at a constant load, that
can be sent through an IPsec tunnel without losing a single can be sent through an IPsec tunnel without losing a single
cleartext frame. cleartext frame.
Discussion: Discussion:
Decryption back-to-back frames is the measure of the maximum burst Decryption back-to-back frames is the measure of the maximum burst
skipping to change at page 45, line 36 skipping to change at page 46, line 7
Number of N-octet frames in burst. Number of N-octet frames in burst.
Issues: Issues:
Recommended test frame sizes will be addressed in future Recommended test frame sizes will be addressed in future
methodology document. methodology document.
See Also: See Also:
Encryption back-to-back frames Tunnel Back-to-back frames, Encryption back-to-back frames
9.7 Maximum Number of Tunnels
9.7.1 Maximum Configured Tunnels (MCT)
Definition:
Maximum number of tunnels that can be configured on an IPsec
device.
Discussion:
Every implementation will have a limitation on the number of
tunnels that can be configured. Most implementation will allow an
operator to configure more tunnels then actually can be
established.
Measurement Units:
Tunnels
See Also:
Configured Tunnel
9.7.2 Maximum Active Tunnels (MAT)
Definition:
Maximum number of active tunnels that can be maintained on an
IPsec device.
Discussion:
Although a number of tunnels may be configured on the IPsec
device, this will not automatically mean that all of these tunnels
can be established and can pass traffic. Each of the tunnels that
need to pass traffic have to be active tunnels.
Measurement Units:
Tunnels
See Also:
Active Tunnel
9.8 Tunnel Setup Rate Behavior 10.5 Tunnel Setup Rate Behavior
9.8.1 Tunnel Setup Rate 10.5.1 Tunnel Setup Rate
Definition: Definition:
The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per second The maximum number of tunnels (1 IKE SA + 2 IPsec SAs) per second
that an IPsec device can successfully establish. that an IPsec device can successfully establish.
Discussion: Discussion:
The tunnel setup rate SHOULD be measured at varying number of The tunnel setup rate SHOULD be measured at varying number of
tunnels on the DUT. Several factors may influence Tunnel Setup tunnels on the DUT. Several factors may influence Tunnel Setup
skipping to change at page 47, line 20 skipping to change at page 46, line 39
Tunnels Per Second (TPS) Tunnels Per Second (TPS)
Issues: Issues:
N/A N/A
See Also: See Also:
IKE Setup Rate, IPsec Setup Rate IKE Setup Rate, IPsec Setup Rate
9.8.2 IKE Setup Rate 10.5.2 Phase 1 Setup Rate
Definition: Definition:
The maximum number of IKE tunnels per second that an IPsec device The maximum number of IKE tunnels per second that an IPsec device
can be observed to successfully establish. can be observed to successfully establish.
Discussion: Discussion:
The tunnel setup rate SHOULD be measured at varying number of The tunnel setup rate SHOULD be measured at varying number of
tunnels on the DUT. tunnels on the DUT.
skipping to change at page 47, line 44 skipping to change at page 47, line 17
Tunnels Per Second (TPS) Tunnels Per Second (TPS)
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel Setup Rate, IPsec Setup Rate Tunnel Setup Rate, IPsec Setup Rate
9.8.3 IPsec Setup Rate 10.5.3 Phase 2 Setup Rate
Definition: Definition:
The maximum number of IPsec tunnels per second that a IPsec device The maximum number of IPsec tunnels per second that a IPsec device
can be observed to successfully establish. can be observed to successfully establish.
Discussion: Discussion:
The tunnel setup rate SHOULD be measured at varying number of The tunnel setup rate SHOULD be measured at varying number of
tunnels on the DUT. tunnels on the DUT.
skipping to change at page 48, line 25 skipping to change at page 47, line 41
Tunnels Per Second (TPS) Tunnels Per Second (TPS)
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel Rekey Tunnel Rekey
9.9 Tunnel Rekey 10.6 Tunnel Rekey
9.9.1 Phase 1 Rekey Rate 10.6.1 Phase 1 Rekey Rate
Definition: Definition:
The interval necessary for a particular Phase 1 to re-establish The interval necessary for a particular Phase 1 to re-establish
after the previous Phase 1 lifetime (hard or soft) has expired. after the previous Phase 1 lifetime (hard or soft) has expired.
Discussion: Discussion:
Although many implementations will usually derive new keying Although many implementations will usually derive new keying
material before the old keys expire, there may still be a period material before the old keys expire, there may still be a period
skipping to change at page 49, line 11 skipping to change at page 48, line 28
measurement. measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 2 Rekey Rate Phase 2 Rekey Rate
9.9.2 Phase 2 Rekey Rate 10.6.2 Phase 2 Rekey Rate
Definition: Definition:
The interval necessary for a particular Phase 2 to re-establish The interval necessary for a particular Phase 2 to re-establish
after the previous Phase 2 lifetime (hard or soft) has expired. after the previous Phase 2 lifetime (hard or soft) has expired.
Discussion: Discussion:
The test methodology report must specify if PFS is enabled in The test methodology report must specify if PFS is enabled in
reported security context. reported security context.
skipping to change at page 49, line 36 skipping to change at page 49, line 7
measurement. measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 1 Rekey Rate Phase 1 Rekey Rate
9.10 Tunnel Failover Time (TFT) 10.7 Tunnel Failover Time (TFT)
Definition: Definition:
Time required to recover all tunnels on a stanby IPsec device, Time required to recover all tunnels on a stanby IPsec device,
after a catastrophic failure occurs on the active IPsec device. after a catastrophic failure occurs on the active IPsec device.
Discussion: Discussion:
Recovery time required to re-establish all tunnels and reroute all Recovery time required to re-establish all tunnels and reroute all
traffic on a standby node or other failsafe system after a failure traffic on a standby node or other failsafe system after a failure
skipping to change at page 50, line 14 skipping to change at page 49, line 32
tunnel on the backup device. tunnel on the backup device.
Measurement Units: Measurement Units:
Time units with enough precision to reflect Tunnel Failover Time. Time units with enough precision to reflect Tunnel Failover Time.
Issues: Issues:
N/A N/A
10. IKE DOS Resilience Rate 10.8 IKE DOS Resilience Rate
Definition: Definition:
The IKE Denial Of Service (DOS) Resilience Rate provides a rate of The IKE Denial Of Service (DOS) Resilience Rate provides a rate of
invalid or mismatching IKE tunnels setup attempts at which it is invalid or mismatching IKE tunnels setup attempts at which it is
no longer possible to set up a valid IKE tunnel. no longer possible to set up a valid IKE tunnel.
Discussion: Discussion:
The IKE DOS Resilience Rate will provide a metric to how robust The IKE DOS Resilience Rate will provide a metric to how robust
skipping to change at page 52, line 41 skipping to change at page 52, line 10
Algorithms", RFC 2451, November 1998. Algorithms", RFC 2451, November 1998.
[RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for [RFC2544] Bradner, S. and J. McQuaid, "Benchmarking Methodology for
Network Interconnect Devices", RFC 2544, March 1999. Network Interconnect Devices", RFC 2544, March 1999.
[RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March [RFC2547] Rosen, E. and Y. Rekhter, "BGP/MPLS VPNs", RFC 2547, March
1999. 1999.
[I-D.ietf-ipsec-ikev2] [I-D.ietf-ipsec-ikev2]
Kaufman, C., "Internet Key Exchange (IKEv2) Protocol", Kaufman, C., "Internet Key Exchange (IKEv2) Protocol",
draft-ietf-ipsec-ikev2-11 (work in progress), October draft-ietf-ipsec-ikev2-12 (work in progress), January
2003. 2004.
[I-D.ietf-ipsec-nat-t-ike] [I-D.ietf-ipsec-nat-t-ike]
Kivinen, T., "Negotiation of NAT-Traversal in the IKE", Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
draft-ietf-ipsec-nat-t-ike-07 (work in progress), draft-ietf-ipsec-nat-t-ike-07 (work in progress),
September 2003. September 2003.
[I-D.ietf-ipsec-udp-encaps] [I-D.ietf-ipsec-udp-encaps]
Huttunen, A., "UDP Encapsulation of IPsec Packets", Huttunen, A., "UDP Encapsulation of IPsec Packets",
draft-ietf-ipsec-udp-encaps-06 (work in progress), January draft-ietf-ipsec-udp-encaps-07 (work in progress),
2003. November 2003.
[I-D.ietf-ipsec-nat-reqts] [I-D.ietf-ipsec-nat-reqts]
Aboba, B. and W. Dixon, "IPsec-NAT Compatibility Aboba, B. and W. Dixon, "IPsec-NAT Compatibility
Requirements", draft-ietf-ipsec-nat-reqts-06 (work in Requirements", draft-ietf-ipsec-nat-reqts-06 (work in
progress), October 2003. progress), October 2003.
[I-D.ietf-ipsec-properties] [I-D.ietf-ipsec-properties]
Krywaniuk, A., "Security Properties of the IPsec Protocol Krywaniuk, A., "Security Properties of the IPsec Protocol
Suite", draft-ietf-ipsec-properties-02 (work in progress), Suite", draft-ietf-ipsec-properties-02 (work in progress),
July 2002. July 2002.
skipping to change at page 55, line 29 skipping to change at page 54, line 29
be obtained from the IETF Secretariat. be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive this standard. Please address the information to the IETF Executive
Director. Director.
Full Copyright Statement Full Copyright Statement
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2004). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of Internet organizations, except as needed for the purpose of
 End of changes. 158 change blocks. 
613 lines changed or deleted 582 lines changed or added

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