draft-ietf-bmwg-ipsec-meth-00.txt   draft-ietf-bmwg-ipsec-meth-01.txt 
Benchmarking Working Group M. Kaeo Benchmarking Working Group M. Kaeo
Internet-Draft Double Shot Security Internet-Draft Double Shot Security
Expires: May 5, 2006 T. Van Herck Expires: September 6, 2006 T. Van Herck
Cisco Systems Cisco Systems
November 2005 March 5, 2006
Methodology for Benchmarking IPsec Devices Methodology for Benchmarking IPsec Devices
draft-ietf-bmwg-ipsec-meth-00 draft-ietf-bmwg-ipsec-meth-01
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 35 skipping to change at page 1, line 35
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on May 5, 2006. This Internet-Draft will expire on September 6, 2006.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2005). Copyright (C) The Internet Society (2006).
Abstract Abstract
The purpose of this draft is to describe methodology specific to the The purpose of this draft is to describe methodology specific to the
benchmarking of IPsec IP forwarding devices. It builds upon the benchmarking of IPsec IP forwarding devices. It builds upon the
tenets set forth in [RFC2544], [RFC2432] and other IETF Benchmarking tenets set forth in [RFC2544], [RFC2432] and other IETF Benchmarking
Methodology Working Group (BMWG) efforts. This document seeks to Methodology Working Group (BMWG) efforts. This document seeks to
extend these efforts to the IPsec paradigm. extend these efforts to the IPsec paradigm.
The BMWG produces two major classes of documents: Benchmarking The BMWG produces two major classes of documents: Benchmarking
skipping to change at page 2, line 22 skipping to change at page 2, line 22
2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Document Scope . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Key Words to Reflect Requirements . . . . . . . . . . . . . . 4 3. Key Words to Reflect Requirements . . . . . . . . . . . . . . 4
4. Test Considerations . . . . . . . . . . . . . . . . . . . . . 4 4. Test Considerations . . . . . . . . . . . . . . . . . . . . . 4
5. Test Topologies . . . . . . . . . . . . . . . . . . . . . . . 5 5. Test Topologies . . . . . . . . . . . . . . . . . . . . . . . 5
6. Test Parameters . . . . . . . . . . . . . . . . . . . . . . . 8 6. Test Parameters . . . . . . . . . . . . . . . . . . . . . . . 8
6.1. Frame Type . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1. Frame Type . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1.1. IP . . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1.2. UDP . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.1.3. TCP . . . . . . . . . . . . . . . . . . . . . . . . . 8 6.1.3. TCP . . . . . . . . . . . . . . . . . . . . . . . . . 8
6.2. Frame Sizes . . . . . . . . . . . . . . . . . . . . . . . 8 6.2. Frame Sizes . . . . . . . . . . . . . . . . . . . . . . . 8
6.3. Fragmentation and Reassembly . . . . . . . . . . . . . . . 8 6.3. Fragmentation and Reassembly . . . . . . . . . . . . . . . 9
6.4. Time To Live . . . . . . . . . . . . . . . . . . . . . . . 9 6.4. Time To Live . . . . . . . . . . . . . . . . . . . . . . . 10
6.5. Trial Duration . . . . . . . . . . . . . . . . . . . . . . 10 6.5. Trial Duration . . . . . . . . . . . . . . . . . . . . . . 10
6.6. Security Context Parameters . . . . . . . . . . . . . . . 10 6.6. Security Context Parameters . . . . . . . . . . . . . . . 10
6.6.1. IPsec Transform Sets . . . . . . . . . . . . . . . . . 10 6.6.1. IPsec Transform Sets . . . . . . . . . . . . . . . . . 10
6.6.2. IPsec Topologies . . . . . . . . . . . . . . . . . . . 11 6.6.2. IPsec Topologies . . . . . . . . . . . . . . . . . . . 11
6.6.3. IKE Keepalives . . . . . . . . . . . . . . . . . . . . 11 6.6.3. IKE Keepalives . . . . . . . . . . . . . . . . . . . . 12
6.6.4. IKE DH-group . . . . . . . . . . . . . . . . . . . . . 11 6.6.4. IKE DH-group . . . . . . . . . . . . . . . . . . . . . 12
6.6.5. IKE SA / IPsec SA Lifetime . . . . . . . . . . . . . . 12 6.6.5. IKE SA / IPsec SA Lifetime . . . . . . . . . . . . . . 12
6.6.6. IPsec Selectors . . . . . . . . . . . . . . . . . . . 12 6.6.6. IPsec Selectors . . . . . . . . . . . . . . . . . . . 13
7. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 7. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. IKE SA Capacity . . . . . . . . . . . . . . . . . . . . . 12 7.1. IKE SA Capacity . . . . . . . . . . . . . . . . . . . . . 13
7.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . . . 13 7.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . . . 14
8. Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 13 8. Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Throughput baseline . . . . . . . . . . . . . . . . . . . 13 8.1. Throughput baseline . . . . . . . . . . . . . . . . . . . 15
8.2. IPsec Throughput . . . . . . . . . . . . . . . . . . . . . 15 8.2. IPsec Throughput . . . . . . . . . . . . . . . . . . . . . 16
8.3. IPsec Encryption Throughput . . . . . . . . . . . . . . . 15 8.3. IPsec Encryption Throughput . . . . . . . . . . . . . . . 17
8.4. IPsec Decryption Throughput . . . . . . . . . . . . . . . 16 8.4. IPsec Decryption Throughput . . . . . . . . . . . . . . . 18
8.5. IPsec Fragmentation Throughput . . . . . . . . . . . . . . 17 9. Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
8.6. IPsec Reassembly Throughput . . . . . . . . . . . . . . . 17 9.1. Latency Baseline . . . . . . . . . . . . . . . . . . . . . 19
9. Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9.2. IPsec Latency . . . . . . . . . . . . . . . . . . . . . . 20
9.1. Latency Baseline . . . . . . . . . . . . . . . . . . . . . 18 9.3. IPsec Encryption Latency . . . . . . . . . . . . . . . . . 21
9.2. IPsec Latency . . . . . . . . . . . . . . . . . . . . . . 19 9.4. IPsec Decryption Latency . . . . . . . . . . . . . . . . . 22
9.3. IPsec Encryption Latency . . . . . . . . . . . . . . . . . 20 10. Time To First Packet . . . . . . . . . . . . . . . . . . . . . 22
9.4. IPsec Decryption Latency . . . . . . . . . . . . . . . . . 21 11. Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . . . 23
10. Time To First Packet . . . . . . . . . . . . . . . . . . . . . 21 11.1. Frame Loss Baseline . . . . . . . . . . . . . . . . . . . 23
11. Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . . . 22 11.2. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . . . 24
11.1. Frame Loss Baseline . . . . . . . . . . . . . . . . . . . 22 11.3. IPsec Encryption Frame Loss . . . . . . . . . . . . . . . 25
11.2. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . . . 23 11.4. IPsec Decryption Frame Loss . . . . . . . . . . . . . . . 26
11.3. IPsec Encryption Frame Loss . . . . . . . . . . . . . . . 24 11.5. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . . 26
11.4. IPsec Decryption Frame Loss . . . . . . . . . . . . . . . 25 12. Back-to-back Frames . . . . . . . . . . . . . . . . . . . . . 27
11.5. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . . 25 12.1. Back-to-back Frames Baseline . . . . . . . . . . . . . . . 27
12. Back-to-back Frames . . . . . . . . . . . . . . . . . . . . . 26 12.2. IPsec Back-to-back Frames . . . . . . . . . . . . . . . . 28
12.1. Back-to-back Frames Baseline . . . . . . . . . . . . . . . 26 12.3. IPsec Encryption Back-to-back Frames . . . . . . . . . . . 28
12.2. IPsec Back-to-back Frames . . . . . . . . . . . . . . . . 27 12.4. IPsec Decryption Back-to-back Frames . . . . . . . . . . . 29
12.3. IPsec Encryption Back-to-back Frames . . . . . . . . . . . 27 13. IPsec Tunnel Setup Behavior . . . . . . . . . . . . . . . . . 30
12.4. IPsec Decryption Back-to-back Frames . . . . . . . . . . . 28 13.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . . . 30
13. IPsec Tunnel Setup Behavior . . . . . . . . . . . . . . . . . 29 13.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . . . 31
13.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . . . 29 13.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . . . 32
13.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . . . 30 14. IPsec Rekey Behavior . . . . . . . . . . . . . . . . . . . . . 33
13.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . . . 30 14.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . 33
14. IPsec Rekey Behavior . . . . . . . . . . . . . . . . . . . . . 31 14.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . 34
14.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . 32 15. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . . . 34
14.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . 32 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36
15. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . . . 32 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 34 17.1. Normative References . . . . . . . . . . . . . . . . . . . 37
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 17.2. Informative References . . . . . . . . . . . . . . . . . . 38
17.1. Normative References . . . . . . . . . . . . . . . . . . . 35 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39
17.2. Informative References . . . . . . . . . . . . . . . . . . 36 Intellectual Property and Copyright Statements . . . . . . . . . . 40
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 37
Intellectual Property and Copyright Statements . . . . . . . . . . 38
1. Introduction 1. Introduction
This document defines a specific set of tests that can be used to This document defines a specific set of tests that can be used to
measure and report the performance characteristics of IPsec devices. measure and report the performance characteristics of IPsec devices.
It extends the methodology already defined for benchmarking network It extends the methodology already defined for benchmarking network
interconnecting devices in [RFC2544] to IPsec gateways and interconnecting devices in [RFC2544] to IPsec gateways and
additionally introduces tests which can be used to measure end-host additionally introduces tests which can be used to measure end-host
IPsec performance. IPsec performance.
skipping to change at page 8, line 26 skipping to change at page 8, line 26
The basic IPv6 header is a fixed 40 bytes and uses an extension field The basic IPv6 header is a fixed 40 bytes and uses an extension field
for additional headers. Only the basic headers plus the IPsec AH for additional headers. Only the basic headers plus the IPsec AH
and/or ESP headers MUST be present. and/or ESP headers MUST be present.
It is recommended that IPv4 and IPv6 frames be tested separately to It is recommended that IPv4 and IPv6 frames be tested separately to
ascertain performance parameters for either IPv4 or IPv6 traffic. If ascertain performance parameters for either IPv4 or IPv6 traffic. If
both IPv4 and IPv6 traffic are to be tested, the device SHOULD be both IPv4 and IPv6 traffic are to be tested, the device SHOULD be
pre-configured for a dual-stack environment to handle both traffic pre-configured for a dual-stack environment to handle both traffic
types. types.
IP traffic with L4 protocol set to 'reserved' (255) SHOULD be used. IP traffic with L4 protocol set to 'reserved' (255) MUST be used.
This ensures maximum space for instrumentation data in the payload This ensures maximum space for instrumentation data in the payload
section, even with framesizes of minimum allowed length on the section, even with framesizes of minimum allowed length on the
transport media. transport media.
6.1.2. UDP 6.1.2. UDP
TBD It is also RECOMMENDED that the test is executed using UDP as the L4
protocol. When using UDP, instrumentation data SHOULD be present in
the payload of the packet. It is OPTIONAL to have application
payload.
6.1.3. TCP 6.1.3. TCP
TBD It is OPTIONAL to perform the tests with TCP as the L4 protocol but
in case this is considered, the TCP traffic is RECOMMENDED to be
stateful. With a TCP as a L4 header it is possible that there will
not be enough room to add all instrumentation data to identify the
packets within the DUT/SUT.
6.2. Frame Sizes 6.2. Frame Sizes
Each test SHOULD be run with different frame sizes. The recommended Each test SHOULD be run with different frame sizes. The recommended
plaintext layer 3 frame sizes for IPv4 tests are 64, 128, 256, 512, cleartext layer 2 frame sizes for IPv4 tests over Ethernet media are
1024, 1280, and 1518 bytes, per RFC2544 section 9 [RFC2544]. The 64, 128, 256, 512, 1024, 1280, and 1518 bytes, per RFC2544 section 9
four CRC bytes are included in the frame size specified. [RFC2544]. The four CRC bytes are included in the frame size
specified.
For GigabitEthernet, supporting jumboframes, the cleartext layer 2
framesizes used are 64, 128, 256, 512, 1024, 1280, 1518, 2048, 3072,
4096, 5120, 6144, 7168, 8192 and 9234 bytes
Since IPv6 requires that every link has an MTU of 1280 octets or Since IPv6 requires that every link has an MTU of 1280 octets or
greater, the plaintext frame sizes to test for IPv6 are 1280 and 1518 greater, it is MANDATORY to execute tests with cleartext layer 2
bytes. frame sizes that include 1280 and 1518 bytes. It is RECOMMENDED that
additional frame sizes are included in the IPv6 test execution,
including the maximum supported datagram size for the linktype used.
6.3. Fragmentation and Reassembly 6.3. Fragmentation and Reassembly
IPsec devices can and must fragment packets in specific scenarios. IPsec devices can and must fragment packets in specific scenarios.
Depending on whether the fragmentation is performed in software or Depending on whether the fragmentation is performed in software or
using specialized custom hardware, there may be a significant impact using specialized custom hardware, there may be a significant impact
on performance. on performance.
In IPv4, unless the DF (don't fragment) bit is set by the packet In IPv4, unless the DF (don't fragment) bit is set by the packet
source, the sender cannot guarantee that some intermediary device on source, the sender cannot guarantee that some intermediary device on
the way will not fragment an IPsec packet. For transport mode IPsec, the way will not fragment an IPsec packet. For transport mode IPsec,
the peers must be able to fragment and reassemble IPsec packets. the peers must be able to fragment and reassemble IPsec packets.
Reassembly of fragmented packets is especially important if an IPv4 Reassembly of fragmented packets is especially important if an IPv4
port selector (or IPv6 transport protocol selector) is configured. port selector (or IPv6 transport protocol selector) is configured.
skipping to change at page 13, line 4 skipping to change at page 13, line 29
MUST be reported. This parameter SHOULD be variable when testing IKE MUST be reported. This parameter SHOULD be variable when testing IKE
rekeying performance. rekeying performance.
6.6.6. IPsec Selectors 6.6.6. IPsec Selectors
All tests MUST be performed using standard IPsec selectors. All tests MUST be performed using standard IPsec selectors.
7. Capacity 7. Capacity
7.1. IKE SA Capacity 7.1. IKE SA Capacity
Objective: Objective:
TBD Measure the maximum number of IKE SA's that can be sustained on an
IPsec Device.
Procedure: Procedure:
TBD The IPsec Device under test initially MUST NOT have any Active
IPsec Tunnels. The Initiator (either a tester or an IPsec peer)
will start the negotiation of an IPsec Tunnel (a single Phase 1 SA
and a pair Phase 2 SA's).
After it is detected that the tunnel is established, a limited
number (50 packets RECOMMENDED) SHALL be sent through the tunnel.
If all packet are received by the Responder (i.e. the DUT), a new
IPsec Tunnel may be attempted.
This proces will be repeated until no more IPsec Tunnels can be
established.
At the end of the test, a traffic pattern is sent to the initiator
that will be distributed over all Active IPsec Tunnels, where each
tunnel will need to propagate a fixed number of packets at a
minimum rate of 5 pps. When all packets sent by the Iniator are
being received by the Responder, the test has succesfully
determined the IKE SA Capacity. If however this final check
fails, the test needs to be re-executed with a lower number of
Active IPsec Tunnels. There MAY be a need to enforce a lower
number of Active IPsec Tunnels i.e. an upper limit of Active IPsec
Tunnel SHOULD be defined in the test.
Reporting Format: Reporting Format:
TBD The reporting format SHOULD be the same as listed in 7.1 with the
additional requirement that the Security Context parameters
defined in 5.6 and utilized for this test MUST be included in any
statement of performance.
7.2. IPsec SA Capacity 7.2. IPsec SA Capacity
Objective: Objective:
TBD Measure the maximum number of IPsec SA's that can be sustained on
an IPsec Device.
Procedure: Procedure:
TBD The IPsec Device under test initially MUST NOT have any Active
IPsec Tunnels. The Initiator (either a tester or an IPsec peer)
will start the negotiation of an IPsec Tunnel (a single Phase 1 SA
and a pair Phase 2 SA's).
After it is detected that the tunnel is established, a limited
number (50 packets RECOMMENDED) SHALL be sent through the tunnel.
If all packet are received by the Responder (i.e. the DUT), a new
pair of IPsec SA's may be attempted. This will be achieved by
offering a specific traffic pattern to the Initiator that matches
a given selector and therfore triggering the negotiation of a new
pair of IPsec SA's.
This proces will be repeated until no more IPsec SA' can be
established.
At the end of the test, a traffic pattern is sent to the initiator
that will be distributed over all IPsec SA's, where each SA will
need to propagate a fixed number of packets at a minimum rate of 5
pps. When all packets sent by the Iniator are being received by
the Responder, the test has succesfully determined the IPsec SA
Capacity. If however this final check fails, the test needs to be
re-executed with a lower number of IPsec SA's. There MAY be a
need to enforce a lower number IPsec SA's i.e. an upper limit of
IPsec SA's SHOULD be defined in the test.
Reporting Format: Reporting Format:
TBD The reporting format SHOULD be the same as listed in 7.1 with the
additional requirement that the Security Context parameters
defined in 5.6 and utilized for this test MUST be included in any
statement of performance.
8. Throughput 8. Throughput
This section contains the description of the tests that are related This section contains the description of the tests that are related
to the characterization of the packet forwarding of a DUT/SUT in an to the characterization of the packet forwarding of a DUT/SUT in an
IPsec environment. Some metrics extend the concept of throughput IPsec environment. Some metrics extend the concept of throughput
presented in RFC 1242. The notion of Forwarding Rate is cited in presented in RFC 1242. The notion of Forwarding Rate is cited in
RFC2285. RFC2285.
A separate test SHOULD be performed for Throughput tests using IPv4/ A separate test SHOULD be performed for Throughput tests using IPv4/
skipping to change at page 17, line 17 skipping to change at page 18, line 48
MUST be sent in a round robin type fashion to keep the test MUST be sent in a round robin type fashion to keep the test
balanced so as not to overload any single IPsec SA. balanced so as not to overload any single IPsec SA.
Reporting format: Reporting format:
The reporting format SHOULD be the same as listed in 7.1 with the The reporting format SHOULD be the same as listed in 7.1 with the
additional requirement that the Security Context parameters additional requirement that the Security Context parameters
defined in 5.6 and utilized for this test MUST be included in any defined in 5.6 and utilized for this test MUST be included in any
statement of performance. statement of performance.
8.5. IPsec Fragmentation Throughput
Objective:
TBD
Procedure:
TBD
Reporting format:
TBD
8.6. IPsec Reassembly Throughput
Objective:
TBD
Procedure:
TBD
Reporting format:
TBD
9. Latency 9. Latency
This section presents methodologies relating to the characterization This section presents methodologies relating to the characterization
of the forwarding latency of a DUT/SUT. It extends the concept of of the forwarding latency of a DUT/SUT. It extends the concept of
latency characterization presented in [RFC2544] to an IPsec latency characterization presented in [RFC2544] to an IPsec
environment. environment.
A separate tests SHOULD be performed for latency tests using IPv4/ A separate tests SHOULD be performed for latency tests using IPv4/
UDP, IPv6/UDP, IPv4/TCP and IPv6/TCP traffic. UDP, IPv6/UDP, IPv4/TCP and IPv6/TCP traffic.
skipping to change at page 22, line 19 skipping to change at page 23, line 19
Send a stream of cleartext frames at a particular frame size Send a stream of cleartext frames at a particular frame size
through the DUT/SUT at the determined throughput rate using frames through the DUT/SUT at the determined throughput rate using frames
that match the IPsec SA selector(s) to be tested. that match the IPsec SA selector(s) to be tested.
The time at which the first frame is fully transmitted from the The time at which the first frame is fully transmitted from the
testing device is recorded as timestamp A. The time at which the testing device is recorded as timestamp A. The time at which the
testing device receives its first frame from the DUT/SUT is testing device receives its first frame from the DUT/SUT is
recorded as timestamp B. The Time To First Packet is the recorded as timestamp B. The Time To First Packet is the
difference between Timestamp B and Timestamp A. difference between Timestamp B and Timestamp A.
Note that it is possible that packets can be lost during IPsec
Tunnel establishment and that timestamp A & B are not required to
be associated with a unique packet.
Reporting format: Reporting format:
The Time To First Packet results SHOULD be reported in the format The Time To First Packet results SHOULD be reported in the format
of a table with a row for each of the tested frame sizes. There of a table with a row for each of the tested frame sizes. There
SHOULD be columns for the frame size, the rate at which the TTFP SHOULD be columns for the frame size, the rate at which the TTFP
test was run for that frame size, for the media types tested, and test was run for that frame size, for the media types tested, and
for the resultant TTFP values for each type of data stream tested. for the resultant TTFP values for each type of data stream tested.
The Security Context parameters defined in 5.6 and utilized for The Security Context parameters defined in 5.6 and utilized for
this test MUST be included in any statement of performance. this test MUST be included in any statement of performance.
skipping to change at page 32, line 5 skipping to change at page 33, line 7
format of a table with a row for each of the tested frame sizes. format of a table with a row for each of the tested frame sizes.
There SHOULD be columns for the frame size, the rate at which the There SHOULD be columns for the frame size, the rate at which the
test was run for that frame size, for the media types tested, and test was run for that frame size, for the media types tested, and
for the resultant IKE Phase 2 Setup Rate values for each type of for the resultant IKE Phase 2 Setup Rate values for each type of
data stream tested. The Security Context parameters defined in data stream tested. The Security Context parameters defined in
6.7 and utilized for this test MUST be included in any statement 6.7 and utilized for this test MUST be included in any statement
of performance. of performance.
14. IPsec Rekey Behavior 14. IPsec Rekey Behavior
The IPsec Rekey Behavior test all need to be executed by an IPsec
aware test device since the test needs to be closely linked with the
IKE FSM and cannot be done by offering specific traffic pattern at
either the Initiator or the Responder.
14.1. IKE Phase 1 Rekey Rate 14.1. IKE Phase 1 Rekey Rate
Objective: Objective:
Determine the maximum rate at which an IPsec Device can rekey IKE Determine the maximum rate at which an IPsec Device can rekey IKE
SA's. SA's.
Procedure: Procedure:
Set up a number of Active IPsec Tunnels each with an IKE SA The IPsec Device under test should initially be set up with the
lifetime set to one-half of the test duration time. Send a stream determined IKE SA Capacity number of Active IPsec Tunnels.
of cleartext frames at a particular frame size through the DUT at
the determined throughput rate using frames with selectors The IPsec aware tester should then perform a binary search where
matching each of the IPsec Tunnels. Record the time at which the it initiates an IKE Phase 1 SA rekey for all Active IPsec Tunnels.
first IKE SA rekey is initiated. The tester MUST timestamp for each IKE SA when it initiated the
rekey and MUST timestamp once more once the FSM declares the rekey
is completed. Once the itteration is complete the tester now has
a table of rekey times for each IKE SA. The reciproce of the
average of this table is the IKE Phase 1 Rekey Rate.
This is obviously granted that all IKE SA were able to rekey
succesfully. If this is not the case, the IPsec Tunnels are all
re-established and the binary search goes to the next value of IKE
SA's it will rekey. The process will repeat itself until a rate
is determined at which a all SA's in that timeframe rekey
correctly.
Reporting Format: Reporting Format:
TBD The IKE Phase 1 Rekey Rate results SHOULD be reported in the
format of a table with a row for each of the tested frame sizes.
There SHOULD be columns for the frame size, the rate at which the
test was run for that frame size, for the media types tested, and
for the resultant IKE Phase 1 Rekey Rate values for each type of
data stream tested. The Security Context parameters defined in
6.7 and utilized for this test MUST be included in any statement
of performance.
14.2. IKE Phase 2 Rekey Rate 14.2. IKE Phase 2 Rekey Rate
Objective: Objective:
Determine the maximum rate at which an IPsec Device can rekey Determine the maximum rate at which an IPsec Device can rekey
IPsec SA's. IPsec SA's.
Procedure: Procedure:
TBD The IPsec Device under test should initially be set up with the
determined IKE SA Capacity number of Active IPsec Tunnels.
The IPsec aware tester should then perform a binary search where
it initiates an IKE Phase 2 SA rekey for all IPsec SA's. The
tester MUST timestamp for each IPsec SA when it initiated the
rekey and MUST timestamp once more once the FSM declares the rekey
is completed. Once the itteration is complete the tester now has
a table of rekey times for each IPsec SA. The reciproce of the
average of this table is the IKE Phase 2 Rekey Rate.
This is obviously granted that all IPsec SA were able to rekey
succesfully. If this is not the case, the IPsec Tunnels are all
re-established and the binary search goes to the next value of
IPsec SA's it will rekey. The process will repeat itself until a
rate is determined at which a all SA's in that timeframe rekey
correctly.
Reporting Format: Reporting Format:
TBD The IKE Phase 2 Rekey Rate results SHOULD be reported in the
format of a table with a row for each of the tested frame sizes.
There SHOULD be columns for the frame size, the rate at which the
test was run for that frame size, for the media types tested, and
for the resultant IKE Phase 2 Rekey Rate values for each type of
data stream tested. The Security Context parameters defined in
6.7 and utilized for this test MUST be included in any statement
of performance.
15. IPsec Tunnel Failover Time 15. IPsec Tunnel Failover Time
This section presents methodologies relating to the characterization This section presents methodologies relating to the characterization
of the failover behavior of a DUT/SUT in a IPsec environment. of the failover behavior of a DUT/SUT in a IPsec environment.
In order to lessen the effect of packet buffering in the DUT/SUT, the In order to lessen the effect of packet buffering in the DUT/SUT, the
Tunnel Failover Time tests MUST be run at the measured IPsec Tunnel Failover Time tests MUST be run at the measured IPsec
throughput level of the DUT. Tunnel Failover Time tests at other throughput level of the DUT. Tunnel Failover Time tests at other
offered constant loads are OPTIONAL. offered constant loads are OPTIONAL.
skipping to change at page 38, line 41 skipping to change at page 40, line 41
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement Copyright Statement
Copyright (C) The Internet Society (2005). This document is subject Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights. except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is currently provided by the
Internet Society. Internet Society.
 End of changes. 29 change blocks. 
104 lines changed or deleted 192 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/