draft-ietf-bmwg-ipsec-term-01.txt   draft-ietf-bmwg-ipsec-term-02.txt 
Benchmarking Working Group M. Bustos Benchmarking Working Group M. Bustos
Internet-Draft IXIA Internet-Draft IXIA
Expires: December 30, 2003 T. Van Herck Expires: May 1, 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-01 draft-ietf-bmwg-ipsec-term-02
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 33 skipping to change at page 1, line 34
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 December 30, 2003. This Internet-Draft will expire on May 1, 2004.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2003). All Rights Reserved. Copyright (C) The Internet Society (2003). 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
skipping to change at page 2, line 49 skipping to change at page 2, line 49
7.9 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 21 7.9 Iterated Tunnels . . . . . . . . . . . . . . . . . . . . . 21
7.9.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . . . 21 7.9.1 Nested Tunnels . . . . . . . . . . . . . . . . . . . . . . 21
7.9.2 Transport Adjacency . . . . . . . . . . . . . . . . . . . 22 7.9.2 Transport Adjacency . . . . . . . . . . . . . . . . . . . 22
7.10 Transform protocols . . . . . . . . . . . . . . . . . . . 23 7.10 Transform protocols . . . . . . . . . . . . . . . . . . . 23
7.10.1 Authentication Protocols . . . . . . . . . . . . . . . . . 24 7.10.1 Authentication Protocols . . . . . . . . . . . . . . . . . 24
7.10.2 Encryption Protocols . . . . . . . . . . . . . . . . . . . 24 7.10.2 Encryption Protocols . . . . . . . . . . . . . . . . . . . 24
7.11 IPSec Protocols . . . . . . . . . . . . . . . . . . . . . 25 7.11 IPSec Protocols . . . . . . . . . . . . . . . . . . . . . 25
7.11.1 Authentication Header (AH) . . . . . . . . . . . . . . . . 25 7.11.1 Authentication Header (AH) . . . . . . . . . . . . . . . . 25
7.11.2 Encapsulated Security Payload (ESP) . . . . . . . . . . . 26 7.11.2 Encapsulated Security Payload (ESP) . . . . . . . . . . . 26
7.12 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 27 7.12 Selectors . . . . . . . . . . . . . . . . . . . . . . . . 27
7.13 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 27 7.13 NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 28
7.14 IP Compression . . . . . . . . . . . . . . . . . . . . . . 28 7.14 IP Compression . . . . . . . . . . . . . . . . . . . . . . 28
7.15 Security Context . . . . . . . . . . . . . . . . . . . . . 29 7.15 Security Context . . . . . . . . . . . . . . . . . . . . . 29
8. Performance Metrics . . . . . . . . . . . . . . . . . . . 31 8. Performance Metrics . . . . . . . . . . . . . . . . . . . 31
8.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 31 8.1 Tunnels Per Second (TPS) . . . . . . . . . . . . . . . . . 31
8.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 31 8.2 Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 31
8.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 32 8.3 Tunnel Attempts Per Second (TAPS) . . . . . . . . . . . . 32
9. Test Definitions . . . . . . . . . . . . . . . . . . . . . 32 9. Test Definitions . . . . . . . . . . . . . . . . . . . . . 32
9.1 Framesizes . . . . . . . . . . . . . . . . . . . . . . . . 32 9.1 Framesizes . . . . . . . . . . . . . . . . . . . . . . . . 32
9.1.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32 9.1.1 Layer3 clear framesize . . . . . . . . . . . . . . . . . . 32
9.1.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33 9.1.2 Layer3 encrypted framesize . . . . . . . . . . . . . . . . 33
9.1.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34 9.1.3 Layer2 clear framesize . . . . . . . . . . . . . . . . . . 34
9.1.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 34 9.1.4 Layer2 encrypted framesize . . . . . . . . . . . . . . . . 35
9.2 Internet Mix Traffic (IMIX) . . . . . . . . . . . . . . . 35 9.2 Internet Mix Traffic (IMIX) . . . . . . . . . . . . . . . 35
9.3 Throughput . . . . . . . . . . . . . . . . . . . . . . . . 36 9.3 Throughput . . . . . . . . . . . . . . . . . . . . . . . . 36
9.3.1 IPsec Tunnel Throughput . . . . . . . . . . . . . . . . . 36 9.3.1 IPsec Tunnel Throughput . . . . . . . . . . . . . . . . . 36
9.3.2 IPsec Encryption Throughput . . . . . . . . . . . . . . . 37 9.3.2 IPsec Encryption Throughput . . . . . . . . . . . . . . . 37
9.3.3 IPsec Decryption Throughput . . . . . . . . . . . . . . . 37 9.3.3 IPsec Decryption Throughput . . . . . . . . . . . . . . . 37
9.4 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 38 9.4 Latency . . . . . . . . . . . . . . . . . . . . . . . . . 38
9.4.1 IPsec Tunnel Encryption Latency . . . . . . . . . . . . . 38 9.4.1 Tunnel Latency . . . . . . . . . . . . . . . . . . . . . . 38
9.4.2 IPsec Tunnel Decryption Latency . . . . . . . . . . . . . 39 9.4.2 IPsec Tunnel Encryption Latency . . . . . . . . . . . . . 39
9.4.3 Time To First Packet . . . . . . . . . . . . . . . . . . . 40 9.4.3 IPsec Tunnel Decryption Latency . . . . . . . . . . . . . 40
9.5 Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . 40 9.4.4 Time To First Packet . . . . . . . . . . . . . . . . . . . 40
9.5.1 IPsec Tunnel Encryption Frame Loss Rate . . . . . . . . . 40 9.5 Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . 41
9.5.2 IPsec Tunnel Decryption Frame Loss Rate . . . . . . . . . 41 9.5.1 Tunnel Frame Loss Rate . . . . . . . . . . . . . . . . . . 41
9.6 Back-to-back Frames . . . . . . . . . . . . . . . . . . . 42 9.5.2 IPsec Tunnel Encryption Frame Loss Rate . . . . . . . . . 42
9.6.1 Encryption Back-to-back Frames . . . . . . . . . . . . . . 42 9.5.3 IPsec Tunnel Decryption Frame Loss Rate . . . . . . . . . 43
9.6.2 Decryption Back-to-back Frames . . . . . . . . . . . . . . 42 9.6 Back-to-back Frames . . . . . . . . . . . . . . . . . . . 43
9.7 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . . 43 9.6.1 Tunnel Back-to-back Frames . . . . . . . . . . . . . . . . 43
9.7.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . . . . 43 9.6.2 Encryption Back-to-back Frames . . . . . . . . . . . . . . 44
9.7.2 IKE Setup Rate . . . . . . . . . . . . . . . . . . . . . . 44 9.6.3 Decryption Back-to-back Frames . . . . . . . . . . . . . . 45
9.7.3 IPsec Setup Rate . . . . . . . . . . . . . . . . . . . . . 44 9.7 Maximum Number of Tunnels . . . . . . . . . . . . . . . . 45
9.8 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . . 45 9.7.1 Maximum Configured Tunnels (MCT) . . . . . . . . . . . . . 45
9.8.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . . . 45 9.7.2 Maximum Active Tunnels (MAT) . . . . . . . . . . . . . . . 46
9.8.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . . . 46 9.8 Tunnel Setup Rate Behavior . . . . . . . . . . . . . . . . 46
9.9 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . . 46 9.8.1 Tunnel Setup Rate . . . . . . . . . . . . . . . . . . . . 46
10. IKE DOS Resilience Rate . . . . . . . . . . . . . . . . . 47 9.8.2 IKE Setup Rate . . . . . . . . . . . . . . . . . . . . . . 47
11. Security Considerations . . . . . . . . . . . . . . . . . 48 9.8.3 IPsec Setup Rate . . . . . . . . . . . . . . . . . . . . . 47
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 48 9.9 Tunnel Rekey . . . . . . . . . . . . . . . . . . . . . . . 48
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . 48 9.9.1 Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . . . 48
Normative References . . . . . . . . . . . . . . . . . . . 48 9.9.2 Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . . . 49
Informative References . . . . . . . . . . . . . . . . . . 50 9.10 Tunnel Failover Time (TFT) . . . . . . . . . . . . . . . . 49
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 50 10. IKE DOS Resilience Rate . . . . . . . . . . . . . . . . . 50
Intellectual Property and Copyright Statements . . . . . . 52 11. Security Considerations . . . . . . . . . . . . . . . . . 51
12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 51
13. Contributors . . . . . . . . . . . . . . . . . . . . . . . 51
Normative References . . . . . . . . . . . . . . . . . . . 51
Informative References . . . . . . . . . . . . . . . . . . 53
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 53
Intellectual Property and Copyright Statements . . . . . . 55
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 43 skipping to change at page 8, line 43
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, 2547 (MPLS VPNs), multicast, and anything that does not
specifically relate to the establishment and tearing down of IPsec specifically relate to the establishment and tearing down of IPsec
tunnels is specifically out of scope. It is assumed that all relevant tunnels is specifically out of scope. It is assumed that all relevant
networking parameters that facilitate in the running of these tests networking parameters that facilitate in the running of these tests
are pre-configured (this includes at a minimum ARP caches and routing are pre-configured (this includes at a minimum ARP caches and routing
tables). This document will encompass updates to AH, ESP and NAT tables). This document will encompass updates to AH, ESP and NAT
Traversal. Since NAT traversal has been included in the document, NAT Traversal.
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 38, line 21 skipping to change at page 38, line 31
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 9.4 Latency
9.4.1 IPsec Tunnel Encryption Latency 9.4.1 Tunnel Latency
Definition:
Tunnel Latency is the delay introduced when sending traffic
through an established IPsec tunnel between two interconnected
IPsec devices.
Discussion:
The Tunnel Latency is the time interval starting when the end of
the first bit of the cleartext frame reaches the input interface
of the encrypting router, and ending when the start of the first
bit of the cleartext frame is seen on the output interface of the
decrypting router.
Measurement Units:
Time units with enough precision to reflect latency measurement.
Issues:
N/A
See Also:
IPsec Tunnel Encryption Latency, IPsec Tunnel Decryption Latency
9.4.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 15 skipping to change at page 40, line 5
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 Decryption Latency
9.4.2 IPsec Tunnel Decryption Latency 9.4.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 7 skipping to change at page 40, line 42
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 Encryption Latency
9.4.3 Time To First Packet 9.4.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 40, line 40 skipping to change at page 41, line 29
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 9.5 Frame Loss Rate
9.5.1 IPsec Tunnel Encryption Frame Loss Rate 9.5.1 Tunnel Frame Loss Rate
Definition:
Percentage of cleartext frames that should have been forwarded
through an IPsec tunnel under steady state (constant) load but
were dropped.
Discussion:
DUT's will always have an inherent forwarding limitation. This
will be more pronounced when IPsec is employed on the DUT. The
instant that a Tunnel is established and offered traffic that will
flow through that tunnel at a constant rate, the possibility
exists that either the offerred traffic rate at the tunnel is too
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:
Percent (%)
Issues:
N/A
See Also:
IPsec Tunnel Encryption Frame Loss Rate, IPsec Tunnel Decryption
Frame Loss Rate
9.5.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 41, line 27 skipping to change at page 43, line 5
Percent (%) Percent (%)
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Decryption Frame Loss Rate IPsec Tunnel Decryption Frame Loss Rate
9.5.2 IPsec Tunnel Decryption Frame Loss Rate 9.5.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 42, line 14 skipping to change at page 43, line 38
Issues: Issues:
N/A N/A
See Also: See Also:
IPsec Tunnel Encryption Frame Loss Rate IPsec Tunnel Encryption Frame Loss Rate
9.6 Back-to-back Frames 9.6 Back-to-back Frames
9.6.1 Encryption Back-to-back Frames 9.6.1 Tunnel Back-to-back Frames
Definition:
A burst of cleartext frames, offered at a constant load that can
be sent through an IPsec tunnel without losing a single frame.
Discussion:
Tunnel back-to-back frames is the measure of the maximum burst
size of cleartext frames that can be sent through an established
tunnel between two interconnected IPsec devices.
Measurement Units:
Number of N-octet frames in burst.
Issues:
Recommended test frame sizes will be addressed in future
methodology document.
See Also:
Encryption Back-to-back frames, Decryption Back-to-back frames
9.6.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 42, line 47 skipping to change at page 45, line 5
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 Decryption Back-to-back frames
9.6.2 Decryption Back-to-back Frames 9.6.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
size that a device can handle for decrypting traffic that it size that a device can handle for decrypting traffic that it
skipping to change at page 43, line 35 skipping to change at page 45, line 38
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 Encryption back-to-back frames
9.7 Tunnel Setup Rate Behavior 9.7 Maximum Number of Tunnels
9.7.1 Tunnel Setup Rate 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
9.8.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 44, line 18 skipping to change at page 47, line 20
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.7.2 IKE Setup Rate 9.8.2 IKE 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 44, line 42 skipping to change at page 47, line 44
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.7.3 IPsec Setup Rate 9.8.3 IPsec 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 45, line 22 skipping to change at page 48, line 25
Tunnels Per Second (TPS) Tunnels Per Second (TPS)
Issues: Issues:
N/A N/A
See Also: See Also:
Tunnel Rekey Tunnel Rekey
9.8 Tunnel Rekey 9.9 Tunnel Rekey
9.8.1 Phase 1 Rekey Rate 9.9.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 46, line 4 skipping to change at page 49, line 6
key. key.
Measurement Units: Measurement Units:
Time units with enough precision to reflect rekey rate Time units with enough precision to reflect rekey rate
measurement. measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 2 Rekey Rate Phase 2 Rekey Rate
9.8.2 Phase 2 Rekey Rate 9.9.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 46, line 33 skipping to change at page 49, line 36
measurement. measurement.
Issues: Issues:
N/A N/A
See Also: See Also:
Phase 1 Rekey Rate Phase 1 Rekey Rate
9.9 Tunnel Failover Time (TFT) 9.10 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 49, line 38 skipping to change at page 52, line 41
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-08 (work in progress), June 2003. draft-ietf-ipsec-ikev2-11 (work in progress), October
2003.
[I-D.ietf-ipsec-nat-t-ike] [I-D.ietf-ipsec-nat-t-ike]
Kivinen, T., "Negotiation of NAT-Traversal in the IKE", Kivinen, T., "Negotiation of NAT-Traversal in the IKE",
draft-ietf-ipsec-nat-t-ike-06 (work in progress), May draft-ietf-ipsec-nat-t-ike-07 (work in progress),
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-06 (work in progress), January
2003. 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-04 (work in Requirements", draft-ietf-ipsec-nat-reqts-06 (work in
progress), March 2003. progress), October 2003.
[I-D.ietf-ipsec-properties] [I-D.ietf-ipsec-properties]
Krywaniuk, A., "Security Properties of the IPsec Protocol Krywaniuk, A., "Security Properties of the IPsec Protocol
Suite", draft-ietf-ipsec-properties-02 (work in progress), Suite", draft-ietf-ipsec-properties-02 (work in progress),
July 2002. July 2002.
[FIPS.186-1.1998] [FIPS.186-1.1998]
National Institute of Standards and Technology, "Digital National Institute of Standards and Technology, "Digital
Signature Standard", FIPS PUB 186-1, December 1998, Signature Standard", FIPS PUB 186-1, December 1998,
<http://csrc.nist.gov/fips/fips1861.pdf>. <http://csrc.nist.gov/fips/fips1861.pdf>.
skipping to change at page 50, line 41 skipping to change at page 54, line 4
Authors' Addresses Authors' Addresses
Michele Bustos Michele Bustos
IXIA IXIA
26601 W. Agoura Rd. 26601 W. Agoura Rd.
Calabasas, CA 91302 Calabasas, CA 91302
US US
Phone: +1 (818)444-3244 Phone: +1 (818)444-3244
EMail: mbustos@ixiacom.com EMail: mbustos@ixiacom.com
Tim Van Herck Tim Van Herck
Cisco Systems, Inc. Cisco Systems, Inc.
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
US US
Phone: +1 (408)527-2461 Phone: +1 (408)527-2461
EMail: herct@cisco.com EMail: herckt@cisco.com
Merike Kaeo Merike Kaeo
Merike, Inc. Merike, Inc.
123 Ross Street 123 Ross Street
Santa Cruz, CA 95060 Santa Cruz, CA 95060
US US
Phone: +1 (831)818-4864 Phone: +1 (831)818-4864
EMail: kaeo@merike.com EMail: kaeo@merike.com
Intellectual Property Statement Intellectual Property Statement
 End of changes. 29 change blocks. 
54 lines changed or deleted 197 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/