draft-ietf-bmwg-ipsec-meth-01.txt   draft-ietf-bmwg-ipsec-meth-02.txt 
Benchmarking Working Group M. Kaeo Benchmarking Working Group M. Kaeo
Internet-Draft Double Shot Security Internet-Draft Double Shot Security
Expires: September 6, 2006 T. Van Herck Expires: January 9, 2008 T. Van Herck
Cisco Systems Cisco Systems
March 5, 2006 July 8, 2007
Methodology for Benchmarking IPsec Devices Methodology for Benchmarking IPsec Devices
draft-ietf-bmwg-ipsec-meth-01 draft-ietf-bmwg-ipsec-meth-02
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 September 6, 2006. This Internet-Draft will expire on January 9, 2008.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The IETF Trust (2007).
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 27 skipping to change at page 2, line 27
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 . . . . . . . . . . . . . . . 9 6.3. Fragmentation and Reassembly . . . . . . . . . . . . . . . 9
6.4. Time To Live . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . 12
6.6.3. IKE Keepalives . . . . . . . . . . . . . . . . . . . . 12 6.6.3. IKE Keepalives . . . . . . . . . . . . . . . . . . . . 13
6.6.4. IKE DH-group . . . . . . . . . . . . . . . . . . . . . 12 6.6.4. IKE DH-group . . . . . . . . . . . . . . . . . . . . . 13
6.6.5. IKE SA / IPsec SA Lifetime . . . . . . . . . . . . . . 12 6.6.5. IKE SA / IPsec SA Lifetime . . . . . . . . . . . . . . 13
6.6.6. IPsec Selectors . . . . . . . . . . . . . . . . . . . 13 6.6.6. IPsec Selectors . . . . . . . . . . . . . . . . . . . 14
7. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6.6.7. NAT-Traversal . . . . . . . . . . . . . . . . . . . . 14
7.1. IKE SA Capacity . . . . . . . . . . . . . . . . . . . . . 13 7. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . . . 14 7.1. IKE SA Capacity . . . . . . . . . . . . . . . . . . . . . 14
8. Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 15 7.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . . . 15
8.1. Throughput baseline . . . . . . . . . . . . . . . . . . . 15 8. Throughput . . . . . . . . . . . . . . . . . . . . . . . . . . 16
8.2. IPsec Throughput . . . . . . . . . . . . . . . . . . . . . 16 8.1. Throughput baseline . . . . . . . . . . . . . . . . . . . 16
8.2. IPsec Throughput . . . . . . . . . . . . . . . . . . . . . 17
8.3. IPsec Encryption Throughput . . . . . . . . . . . . . . . 17 8.3. IPsec Encryption Throughput . . . . . . . . . . . . . . . 17
8.4. IPsec Decryption Throughput . . . . . . . . . . . . . . . 18 8.4. IPsec Decryption Throughput . . . . . . . . . . . . . . . 18
9. Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . 18 9. Latency . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Latency Baseline . . . . . . . . . . . . . . . . . . . . . 19 9.1. Latency Baseline . . . . . . . . . . . . . . . . . . . . . 19
9.2. IPsec Latency . . . . . . . . . . . . . . . . . . . . . . 20 9.2. IPsec Latency . . . . . . . . . . . . . . . . . . . . . . 20
9.3. IPsec Encryption Latency . . . . . . . . . . . . . . . . . 21 9.3. IPsec Encryption Latency . . . . . . . . . . . . . . . . . 21
9.4. IPsec Decryption Latency . . . . . . . . . . . . . . . . . 22 9.4. IPsec Decryption Latency . . . . . . . . . . . . . . . . . 22
10. Time To First Packet . . . . . . . . . . . . . . . . . . . . . 22 10. Time To First Packet . . . . . . . . . . . . . . . . . . . . . 22
11. Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . . . 23 11. Frame Loss Rate . . . . . . . . . . . . . . . . . . . . . . . 23
11.1. Frame Loss Baseline . . . . . . . . . . . . . . . . . . . 23 11.1. Frame Loss Baseline . . . . . . . . . . . . . . . . . . . 23
11.2. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . . . 24 11.2. IPsec Frame Loss . . . . . . . . . . . . . . . . . . . . . 24
11.3. IPsec Encryption Frame Loss . . . . . . . . . . . . . . . 25 11.3. IPsec Encryption Frame Loss . . . . . . . . . . . . . . . 24
11.4. IPsec Decryption Frame Loss . . . . . . . . . . . . . . . 26 11.4. IPsec Decryption Frame Loss . . . . . . . . . . . . . . . 25
11.5. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . . 26 11.5. IKE Phase 2 Rekey Frame Loss . . . . . . . . . . . . . . . 26
12. Back-to-back Frames . . . . . . . . . . . . . . . . . . . . . 27 12. Back-to-back Frames . . . . . . . . . . . . . . . . . . . . . 26
12.1. Back-to-back Frames Baseline . . . . . . . . . . . . . . . 27 12.1. Back-to-back Frames Baseline . . . . . . . . . . . . . . . 26
12.2. IPsec Back-to-back Frames . . . . . . . . . . . . . . . . 28 12.2. IPsec Back-to-back Frames . . . . . . . . . . . . . . . . 27
12.3. IPsec Encryption Back-to-back Frames . . . . . . . . . . . 28 12.3. IPsec Encryption Back-to-back Frames . . . . . . . . . . . 27
12.4. IPsec Decryption Back-to-back Frames . . . . . . . . . . . 29 12.4. IPsec Decryption Back-to-back Frames . . . . . . . . . . . 28
13. IPsec Tunnel Setup Behavior . . . . . . . . . . . . . . . . . 30 13. IPsec Tunnel Setup Behavior . . . . . . . . . . . . . . . . . 28
13.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . . . 30 13.1. IPsec Tunnel Setup Rate . . . . . . . . . . . . . . . . . 28
13.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . . . 31 13.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . . . 29
13.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . . . 32 13.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . . . 30
14. IPsec Rekey Behavior . . . . . . . . . . . . . . . . . . . . . 33 14. IPsec Rekey Behavior . . . . . . . . . . . . . . . . . . . . . 31
14.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . 33 14.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . 31
14.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . 34 14.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . 32
15. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . . . 34 15. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . . . 32
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 36 16. DoS Resiliency . . . . . . . . . . . . . . . . . . . . . . . . 34
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 37 16.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . . . 34
17.1. Normative References . . . . . . . . . . . . . . . . . . . 37 16.2. Phase 2 DoS Resiliency Rate . . . . . . . . . . . . . . . 35
17.2. Informative References . . . . . . . . . . . . . . . . . . 38 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 39 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Intellectual Property and Copyright Statements . . . . . . . . . . 40 18.1. Normative References . . . . . . . . . . . . . . . . . . . 35
18.2. Informative References . . . . . . . . . . . . . . . . . . 37
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 4, line 34 skipping to change at page 4, line 34
IPsec tunnel and transport mode. IPsec tunnel and transport mode.
o Devices acting as IPsec end-hosts whose tests will pertain to both o Devices acting as IPsec end-hosts whose tests will pertain to both
IPsec tunnel and transport mode. IPsec tunnel and transport mode.
Note that special considerations will be presented for IPsec end-host Note that special considerations will be presented for IPsec end-host
testing since the tests cannot be conducted without introducing testing since the tests cannot be conducted without introducing
additional variables that may cause variations in test results. additional variables that may cause variations in test results.
What is specifically out of scope is any testing that pertains to What is specifically out of scope is any testing that pertains to
considerations involving NAT, L2TP [RFC2661], GRE [RFC2784], BGP/MPLS considerations involving, L2TP [RFC2661], GRE [RFC2784], BGP/MPLS
VPNs [RFC2547] and anything that does not specifically relate to the VPNs [RFC2547] and anything that does not specifically relate to the
establishment and tearing down of IPsec tunnels. establishment and tearing down of IPsec tunnels.
3. Key Words to Reflect Requirements 3. 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.
4. Test Considerations 4. Test Considerations
Before any of the IPsec data plane benchmarking tests are carried Before any of the IPsec data plane benchmarking tests are carried
out, a Baseline MUST be established. I.e. the particular test in out, a baseline MUST be established. I.e. the particular test in
question must first be measured for performance characteristics question must first be measured for performance characteristics
without enabling IPsec. Once both the Baseline clear text without enabling IPsec. Once both the Baseline clear text
performance and the performance using an IPsec enabled datapath have performance and the performance using an IPsec enabled datapath have
been measured, the difference between the two can be discerned. been measured, the difference between the two can be discerned.
This document explicitly assumes that you MUST follow logical This document explicitly assumes that you MUST follow logical
performance test methodology that includes the pre-configuration of performance test methodology that includes the pre-configuration of
routing protocols, ARP caches, IPv6 neighbor discovery and all other routing protocols, ARP caches, IPv6 neighbor discovery and all other
extraneous IPv4 and IPv6 parameters required to pass packets before extraneous IPv4 and IPv6 parameters required to pass packets before
the tester is ready to send IPsec protected packets. IPv6 nodes that the tester is ready to send IPsec protected packets. IPv6 nodes that
skipping to change at page 10, line 17 skipping to change at page 10, line 17
optimization may favorably impact performance and vendors SHOULD optimization may favorably impact performance and vendors SHOULD
report whether any such optimization is configured. report whether any such optimization is configured.
6.4. Time To Live 6.4. Time To Live
The source frames should have a TTL value large enough to accommodate The source frames should have a TTL value large enough to accommodate
the DUT/SUT. A Minimum TTL of 64 is RECOMMENDED. the DUT/SUT. A Minimum TTL of 64 is RECOMMENDED.
6.5. Trial Duration 6.5. Trial Duration
The duration of the test portion of each trial SHOULD be at least 30 The duration of the test portion of each trial SHOULD be at least 60
seconds. In the case of IPsec tunnel rekeying tests, the test seconds. In the case of IPsec tunnel rekeying tests, the test
duration must be at least two times the IPsec tunnel rekey time to duration must be at least two times the IPsec tunnel rekey time to
ensure a reasonable worst case scenario test. ensure a reasonable worst case scenario test.
6.6. Security Context Parameters 6.6. Security Context Parameters
All of the security context parameters listed in this section and All of the security context parameters listed in section 7.13 of the
used in any test MUST be reported. IPsec Benchmarking Terminology document MUST be reported. When
merely discussing the behavior of traffic flows through IPsec
devices, an IPsec context MUST be provided. In the cases where IKE
is configured (as opposed to using manually keyed tunnels), both an
IPsec and an IKE context MUST be provided. Additional considerations
for reporting security context parameters are detailed below. These
all MUST be reported.
6.6.1. IPsec Transform Sets 6.6.1. IPsec Transform Sets
All tests should be done on different IPsec transform set All tests should be done on different IPsec transform set
combinations. An IPsec transform specifies a single IPsec security combinations. An IPsec transform specifies a single IPsec security
protocol (either AH or ESP) with its corresponding security protocol (either AH or ESP) with its corresponding security
algorithms and mode. A transform set is a combination of individual algorithms and mode. A transform set is a combination of individual
IPsec transforms designed to enact a specific security policy for IPsec transforms designed to enact a specific security policy for
protecting a particular traffic flow. At minumim, the transform set protecting a particular traffic flow. At minumim, the transform set
must include one AH algorithm and a mode or one ESP algorithm and a must include one AH algorithm and a mode or one ESP algorithm and a
mode, as shown in Table 1: mode.
+---------------+--------------+----------------------+-----------+ +-------------+------------------+----------------------+-----------+
| Transform Set | AH Algorithm | ESP Algorithm | Mode | | ESP | Encryption | Authentication | Mode |
+---------------+--------------+----------------------+-----------+ | Transform | Algorithm | Algorithm | |
| 1 | AH-SHA1 | None | Tunnel | +-------------+------------------+----------------------+-----------+
| 2 | AH-SHA1 | None | Transport | | 1 | NULL | HMAC-SHA1-96 | Transport |
| 3 | AH-SHA1 | ESP-3DES | Tunnel | | 2 | NULL | HMAC-SHA1-96 | Tunnel |
| 4 | AH-SHA1 | ESP-3DES | Transport | | 3 | 3DES-CBC | HMAC-SHA1-96 | Transport |
| 5 | AH-SHA1 | ESP-AES128 | Tunnel | | 4 | 3DES-CBC | HMAC-SHA1-96 | Tunnel |
| 6 | AH-SHA1 | ESP-AES128 | Transport | | 5 | AES-CBC-128 | HMAC-SHA1-96 | Transport |
| 7 | None | ESP-3DES | Tunnel | | 6 | AES-CBC-128 | HMAC-SHA1-96 | Tunnel |
| 8 | None | ESP-3DES-HMAC-SHA1 | Tunnel | | 7 | NULL | AES-XCBC-MAC-96 | Transport |
| 9 | None | ESP-3DES | Transport | | 8 | NULL | AES-XCBC-MAC-96 | Tunnel |
| 10 | None | ESP-3DES-HMAC-SHA1 | Transport | | 9 | 3DES-CBC | AES-XCBC-MAC-96 | Transport |
| 11 | None | ESP-AES128 | Tunnel | | 10 | 3DES-CBC | AES-XCBC-MAC-96 | Tunnel |
| 12 | None | ESP-AES128-HMAC-SHA1 | Tunnel | | 11 | AES-CBC-128 | AES-XCBC-MAC-96 | Transport |
| 13 | None | ESP-AES128 | Transport | | 12 | AES-CBC-128 | AES-XCBC-MAC-96 | Tunnel |
| 14 | None | ESP-AES128-HMAC-SHA1 | Transport | +-------------+------------------+----------------------+-----------+
+---------------+--------------+----------------------+-----------+
Table 1 Table 1
Testing of all the transforms shown in Table 1 MUST be supported. Testing of ESP Transforms 1-4 MUST be supported. Testing of ESP
Note that this table is derived from the updated IKEv1 requirements Transforms 5-12 SHOULD be supported.
as described in [RFC4109]. Optionally, other AH and/or ESP
transforms MAY be supported. +--------------+--------------------------+-----------+
| AH Transform | Authentication Algorithm | Mode |
+--------------+--------------------------+-----------+
| 1 | HMAC-SHA1-96 | Transport |
| 2 | HMAC-SHA1-96 | Tunnel |
| 3 | AES-XBC-MAC-96 | Transport |
| 4 | AES-XBC-MAC-96 | Tunnel |
+--------------+--------------------------+-----------+
Table 2
Testing of AH Transforms 1 and 2 MUST be supported. Testing of AH
Transforms 3 And 4 SHOULD be supported.
Note that this these tables are derived from the Cryptographic
Algorithms for AH and ESP requirements as described in [RFC4305].
Optionally, other AH and/or ESP transforms MAY be supported.
+-----------------------+----+-----+
| Transform Combination | AH | ESP |
+-----------------------+----+-----+
| 1 | 1 | 1 |
| 2 | 2 | 2 |
| 3 | 1 | 3 |
| 4 | 2 | 4 |
+-----------------------+----+-----+
Table 3
It is RECOMMENDED that the transforms shown in Table 3 be supported
for IPv6 traffic selectors since AH may be used with ESP in these
environments. Since AH will provide the overall authentication and
integrity, the ESP Authentication algorithm MUST be Null for these
tests. Optionally, other combined AH/ESP transform sets MAY be
supported.
6.6.2. IPsec Topologies 6.6.2. IPsec Topologies
All tests should be done at various IPsec topology configurations and All tests should be done at various IPsec topology configurations and
the IPsec topology used MUST be reported. Since IPv6 requires the the IPsec topology used MUST be reported. Since IPv6 requires the
implementation of manual keys for IPsec, both manual keying and IKE implementation of manual keys for IPsec, both manual keying and IKE
configurations MUST be tested. configurations MUST be tested.
For manual keying tests, the IPsec SAs used should vary from 1 to For manual keying tests, the IPsec SAs used should vary from 1 to
101, increasing in increments of 50. Although it is not expected 101, increasing in increments of 50. Although it is not expected
skipping to change at page 12, line 19 skipping to change at page 13, line 11
o {max/2} IKE SA's & {(max/2) IKE SA's} IPsec SA's o {max/2} IKE SA's & {(max/2) IKE SA's} IPsec SA's
o {max} IKE SA's & {(max) IKE SA's} IPsec SA's o {max} IKE SA's & {(max) IKE SA's} IPsec SA's
6.6.3. IKE Keepalives 6.6.3. IKE Keepalives
IKE keepalives track reachability of peers by sending hello packets IKE keepalives track reachability of peers by sending hello packets
between peers. During the typical life of an IKE Phase 1 SA, packets between peers. During the typical life of an IKE Phase 1 SA, packets
are only exchanged over this IKE Phase 1 SA when an IPsec IKE Quick are only exchanged over this IKE Phase 1 SA when an IPsec IKE Quick
Mode (QM) negotiation is required at the expiration of the IPSec Mode (QM) negotiation is required at the expiration of the IPSec
Tunnel SAs. There is no standards-based mechanism for either type of Tunnel SA's. There is no standards-based mechanism for either type
SA to detect the loss of a peer, except when the QM negotiation of SA to detect the loss of a peer, except when the QM negotiation
fails. Most IPsec implementations use the Dead Peer Detection (i.e. fails. Most IPsec implementations use the Dead Peer Detection (i.e.
Keepalive) mechanism to determine whether connectivity has been lost Keepalive) mechanism to determine whether connectivity has been lost
with a peer before the expiration of the IPsec Tunnel SA's. with a peer before the expiration of the IPsec Tunnel SA's.
All tests using IKEv1 MUST use the same IKE keepalive parameters. All tests using IKEv1 MUST use the same IKE keepalive parameters.
6.6.4. IKE DH-group 6.6.4. IKE DH-group
There are 3 Diffie-Hellman groups which can be supported by IPsec There are 3 Diffie-Hellman groups which can be supported by IPsec
standards compliant devices: standards compliant devices:
skipping to change at page 13, line 24 skipping to change at page 14, line 14
timeframe or the total number of bytes to be transmitted during the timeframe or the total number of bytes to be transmitted during the
test. test.
Note that the IPsec SA lifetime MUST be equal to or less than the IKE Note that the IPsec SA lifetime MUST be equal to or less than the IKE
SA lifetime. Both the IKE SA lifetime and the IPsec SA lifetime used SA lifetime. Both the IKE SA lifetime and the IPsec SA lifetime used
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 as
described in [RFC2401] section 4.4.2.
7. Capacity 6.6.7. NAT-Traversal
7.1. IKE SA Capacity For any tests that include network address translation
considerations, the use of NAT-T in the test environment MUST be
recorded.
Objective: 7. Capacity
Measure the maximum number of IKE SA's that can be sustained on an 7.1. IKE SA Capacity
IPsec Device.
Procedure: Objective: Measure the maximum number of IKE SA's that can be
sustained on an IPsec Device.
The IPsec Device under test initially MUST NOT have any Active Procedure: The IPsec Device under test initially MUST NOT have any
IPsec Tunnels. The Initiator (either a tester or an IPsec peer) Active IPsec Tunnels. The Initiator (either a tester or an IPsec
will start the negotiation of an IPsec Tunnel (a single Phase 1 SA peer) will start the negotiation of an IPsec Tunnel (a single
and a pair Phase 2 SA's). Phase 1 SA and a pair Phase 2 SA's).
After it is detected that the tunnel is established, a limited After it is detected that the tunnel is established, a limited
number (50 packets RECOMMENDED) SHALL be sent through the tunnel. number (50 packets RECOMMENDED) SHALL be sent through the tunnel.
If all packet are received by the Responder (i.e. the DUT), a new If all packet are received by the Responder (i.e. the DUT), a new
IPsec Tunnel may be attempted. IPsec Tunnel may be attempted.
This proces will be repeated until no more IPsec Tunnels can be This proces will be repeated until no more IPsec Tunnels can be
established. established.
At the end of the test, a traffic pattern is sent to the initiator 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 that will be distributed over all Active IPsec Tunnels, where each
tunnel will need to propagate a fixed number of packets at a 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 minimum rate of 5 pps. When all packets sent by the Iniator are
being received by the Responder, the test has succesfully being received by the Responder, the test has succesfully
determined the IKE SA Capacity. If however this final check determined the IKE SA Capacity. If however this final check
fails, the test needs to be re-executed with a lower number of 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 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 number of Active IPsec Tunnels i.e. an upper limit of Active IPsec
Tunnel SHOULD be defined in the test. Tunnel SHOULD be defined in the test.
Reporting Format: Reporting Format: The reporting format SHOULD be the same as listed
in 7.1 with the additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 7.1 with the parameters defined in 5.6 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
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: Measure the maximum number of IPsec SA's that can be
sustained on an IPsec Device.
Measure the maximum number of IPsec SA's that can be sustained on
an IPsec Device.
Procedure:
The IPsec Device under test initially MUST NOT have any Active Procedure: The IPsec Device under test initially MUST NOT have any
IPsec Tunnels. The Initiator (either a tester or an IPsec peer) Active IPsec Tunnels. The Initiator (either a tester or an IPsec
will start the negotiation of an IPsec Tunnel (a single Phase 1 SA peer) will start the negotiation of an IPsec Tunnel (a single
and a pair Phase 2 SA's). Phase 1 SA and a pair Phase 2 SA's).
After it is detected that the tunnel is established, a limited After it is detected that the tunnel is established, a limited
number (50 packets RECOMMENDED) SHALL be sent through the tunnel. number (50 packets RECOMMENDED) SHALL be sent through the tunnel.
If all packet are received by the Responder (i.e. the DUT), a new 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 pair of IPsec SA's may be attempted. This will be achieved by
offering a specific traffic pattern to the Initiator that matches offering a specific traffic pattern to the Initiator that matches
a given selector and therfore triggering the negotiation of a new a given selector and therfore triggering the negotiation of a new
pair of IPsec SA's. pair of IPsec SA's.
This proces will be repeated until no more IPsec SA' can be This proces will be repeated until no more IPsec SA' can be
skipping to change at page 15, line 9 skipping to change at page 15, line 43
At the end of the test, a traffic pattern is sent to the initiator 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 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 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 pps. When all packets sent by the Iniator are being received by
the Responder, the test has succesfully determined the IPsec SA the Responder, the test has succesfully determined the IPsec SA
Capacity. If however this final check fails, the test needs to be 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 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 need to enforce a lower number IPsec SA's i.e. an upper limit of
IPsec SA's SHOULD be defined in the test. IPsec SA's SHOULD be defined in the test.
Reporting Format: Reporting Format: The reporting format SHOULD be the same as listed
in 7.1 with the additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 7.1 with the parameters defined in 5.6 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
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/
UDP, IPv6/UDP, IPv4/TCP and IPv6/TCP traffic. UDP, IPv6/UDP, IPv4/TCP and IPv6/TCP traffic.
8.1. Throughput baseline 8.1. Throughput baseline
Objective: Objective: Measure the intrinsic cleartext throughput of a device
without the use of IPsec. The throughput baseline methodology and
Measure the intrinsic cleartext throughput of a device without the reporting format is derived from [RFC2544].
use of IPsec. The throughput baseline methodology and reporting
format is derived from [RFC2544].
Procedure:
Send a specific number of frames that matches the IPsec SA Procedure: Send a specific number of frames that matches the IPsec
selector(s) to be tested at a specific rate through the DUT and SA selector(s) to be tested at a specific rate through the DUT and
then count the frames that are transmitted by the DUT. If the then count the frames that are transmitted by the DUT. If the
count of offered frames is equal to the count of received frames, count of offered frames is equal to the count of received frames,
the rate of the offered stream is increased and the test is rerun. the rate of the offered stream is increased and the test is rerun.
If fewer frames are received than were transmitted, the rate of If fewer frames are received than were transmitted, the rate of
the offered stream is reduced and the test is rerun. the offered stream is reduced and the test is rerun.
The throughput is the fastest rate at which the count of test The throughput is the fastest rate at which the count of test
frames transmitted by the DUT is equal to the number of test frames transmitted by the DUT is equal to the number of test
frames sent to it by the test equipment. frames sent to it by the test equipment.
Reporting Format: Reporting Format: The results of the throughput test SHOULD be
reported in the form of a graph. If it is, the x coordinate
The results of the throughput test SHOULD be reported in the form SHOULD be the frame size, the y coordinate SHOULD be the frame
of a graph. If it is, the x coordinate SHOULD be the frame size, rate. There SHOULD be at least two lines on the graph. There
the y coordinate SHOULD be the frame rate. There SHOULD be at SHOULD be one line showing the theoretical frame rate for the
least two lines on the graph. There SHOULD be one line showing media at the various frame sizes. The second line SHOULD be the
the theoretical frame rate for the media at the various frame plot of the test results. Additional lines MAY be used on the
sizes. The second line SHOULD be the plot of the test results. graph to report the results for each type of data stream tested.
Additional lines MAY be used on the graph to report the results Text accompanying the graph SHOULD indicate the protocol, data
for each type of data stream tested. Text accompanying the graph stream format, and type of media used in the tests.
SHOULD indicate the protocol, data stream format, and type of
media used in the tests.
We assume that if a single value is desired for advertising We assume that if a single value is desired for advertising
purposes the vendor will select the rate for the minimum frame purposes the vendor will select the rate for the minimum frame
size for the media. If this is done then the figure MUST be size for the media. If this is done then the figure MUST be
expressed in packets per second. The rate MAY also be expressed expressed in packets per second. The rate MAY also be expressed
in bits (or bytes) per second if the vendor so desires. The in bits (or bytes) per second if the vendor so desires. The
statement of performance MUST include: statement of performance MUST include:
* Measured maximum frame rate * Measured maximum frame rate
skipping to change at page 16, line 39 skipping to change at page 17, line 19
* Theoretical limit of the media for that frame size * Theoretical limit of the media for that frame size
* Type of protocol used in the test * Type of protocol used in the test
Even if a single value is used as part of the advertising copy, Even if a single value is used as part of the advertising copy,
the full table of results SHOULD be included in the product data the full table of results SHOULD be included in the product data
sheet. sheet.
8.2. IPsec Throughput 8.2. IPsec Throughput
Objective: Objective: Measure the intrinsic throughput of a device utilizing
IPsec.
Measure the intrinsic throughput of a device utilizing IPsec.
Procedure:
Send a specific number of cleartext frames that match the IPsec SA Procedure: Send a specific number of cleartext frames that match the
selector(s) at a specific rate through the DUT/SUT. DUTa will IPsec SA selector(s) at a specific rate through the DUT/SUT. DUTa
encrypt the traffic and forward to DUTb which will in turn decrypt will encrypt the traffic and forward to DUTb which will in turn
the traffic and forward to the testing device. The testing device decrypt the traffic and forward to the testing device. The
counts the frames that are transmitted by the DUTb. If the count testing device counts the frames that are transmitted by the DUTb.
of offered frames is equal to the count of received frames, the If the count of offered frames is equal to the count of received
rate of the offered stream is increased and the test is rerun. If frames, the rate of the offered stream is increased and the test
fewer frames are received than were transmitted, the rate of the is rerun. If fewer frames are received than were transmitted, the
offered stream is reduced and the test is rerun. rate of the offered stream is reduced and the test is rerun.
The IPsec Throughput is the fastest rate at which the count of The IPsec Throughput is the fastest rate at which the count of
test frames transmitted by the DUT/SUT is equal to the number of test frames transmitted by the DUT/SUT is equal to the number of
test frames sent to it by the test equipment. test frames sent to it by the test equipment.
For tests using multiple IPsec SA's, the test traffic associated For tests using multiple IPsec SA's, the test traffic associated
with the individual traffic selectors defined for each IPsec SA with the individual traffic selectors defined for each IPsec SA
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 additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 7.1 with the parameters defined in 5.6 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 5.6 and utilized for this test MUST be included in any
statement of performance.
8.3. IPsec Encryption Throughput 8.3. IPsec Encryption Throughput
Objective: Objective: Measure the intrinsic DUT vendor specific IPsec
Encryption Throughput.
Measure the intrinsic DUT vendor specific IPsec Encryption
Throughput.
Procedure:
Send a specific number of cleartext frames that match the IPsec SA Procedure: Send a specific number of cleartext frames that match the
selector(s) at a specific rate to the DUT. The DUT will receive IPsec SA selector(s) at a specific rate to the DUT. The DUT will
the cleartext frames, perform IPsec operations and then send the receive the cleartext frames, perform IPsec operations and then
IPsec protected frame to the tester. Upon receipt of the send the IPsec protected frame to the tester. Upon receipt of the
encrypted packet, the testing device will timestamp the packet(s) encrypted packet, the testing device will timestamp the packet(s)
and record the result. If the count of offered frames is equal to and record the result. If the count of offered frames is equal to
the count of received frames, the rate of the offered stream is the count of received frames, the rate of the offered stream is
increased and the test is rerun. If fewer frames are received increased and the test is rerun. If fewer frames are received
than were transmitted, the rate of the offered stream is reduced than were transmitted, the rate of the offered stream is reduced
and the test is rerun. and the test is rerun.
The IPsec Encryption Throughput is the fastest rate at which the The IPsec Encryption Throughput is the fastest rate at which the
count of test frames transmitted by the DUT is equal to the number count of test frames transmitted by the DUT is equal to the number
of test frames sent to it by the test equipment. of test frames sent to it by the test equipment.
For tests using multiple IPsec SA's, the test traffic associated For tests using multiple IPsec SA's, the test traffic associated
with the individual traffic selectors defined for each IPsec SA with the individual traffic selectors defined for each IPsec SA
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 additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 7.1 with the parameters defined in 5.6 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 5.6 and utilized for this test MUST be included in any
statement of performance.
8.4. IPsec Decryption Throughput 8.4. IPsec Decryption Throughput
Objective: Objective: Measure the intrinsic DUT vendor specific IPsec
Decryption Throughput.
Measure the intrinsic DUT vendor specific IPsec Decryption
Throughput.
Procedure:
Send a specific number of IPsec protected frames that match the Procedure: Send a specific number of IPsec protected frames that
IPsec SA selector(s) at a specific rate to the DUT. The DUT will match the IPsec SA selector(s) at a specific rate to the DUT. The
receive the IPsec protected frames, perform IPsec operations and DUT will receive the IPsec protected frames, perform IPsec
then send the cleartext frame to the tester. Upon receipt of the operations and then send the cleartext frame to the tester. Upon
cleartext packet, the testing device will timestamp the packet(s) receipt of the cleartext packet, the testing device will timestamp
and record the result. If the count of offered frames is equal to the packet(s) and record the result. If the count of offered
the count of received frames, the rate of the offered stream is frames is equal to the count of received frames, the rate of the
increased and the test is rerun. If fewer frames are received offered stream is increased and the test is rerun. If fewer
than were transmitted, the rate of the offered stream is reduced frames are received than were transmitted, the rate of the offered
and the test is rerun. stream is reduced and the test is rerun.
The IPsec Decryption Throughput is the fastest rate at which the The IPsec Decryption Throughput is the fastest rate at which the
count of test frames transmitted by the DUT is equal to the number count of test frames transmitted by the DUT is equal to the number
of test frames sent to it by the test equipment. of test frames sent to it by the test equipment.
For tests using multiple IPsec SAs, the test traffic associated For tests using multiple IPsec SAs, the test traffic associated
with the individual traffic selectors defined for each IPsec SA with the individual traffic selectors defined for each IPsec SA
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 additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 7.1 with the parameters defined in 5.6 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 5.6 and utilized for this test MUST be included in any
statement of performance.
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.
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
latency tests MUST be run at the measured IPsec throughput level of latency tests MUST be run at the measured IPsec throughput level of
the DUT/SUT; IPsec latency at other offered loads is optional. the DUT/SUT; IPsec latency at other offered loads is optional.
Lastly, [RFC1242] and [RFC2544] draw distinction between two classes Lastly, [RFC1242] and [RFC2544] draw distinction between two classes
of devices: "store and forward" and "bit-forwarding". Each class of devices: "store and forward" and "bit-forwarding". Each class
impacts how latency is collected and subsequently presented. See the impacts how latency is collected and subsequently presented. See the
related RFCs for more information. In practice, much of the test related RFC's for more information. In practice, much of the test
equipment will collect the latency measurement for one class or the equipment will collect the latency measurement for one class or the
other, and, if needed, mathematically derive the reported value by other, and, if needed, mathematically derive the reported value by
the addition or subtraction of values accounting for medium the addition or subtraction of values accounting for medium
propagation delay of the packet, bit times to the timestamp trigger propagation delay of the packet, bit times to the timestamp trigger
within the packet, etc. Test equipment vendors SHOULD provide within the packet, etc. Test equipment vendors SHOULD provide
documentation regarding the composition and calculation latency documentation regarding the composition and calculation latency
values being reported. The user of this data SHOULD understand the values being reported. The user of this data SHOULD understand the
nature of the latency values being reported, especially when nature of the latency values being reported, especially when
comparing results collected from multiple test vendors. (E.g., If comparing results collected from multiple test vendors. (E.g., If
test vendor A presents a "store and forward" latency result and test test vendor A presents a "store and forward" latency result and test
vendor B presents a "bit-forwarding" latency result, the user may vendor B presents a "bit-forwarding" latency result, the user may
erroneously conclude the DUT has two differing sets of latency erroneously conclude the DUT has two differing sets of latency
values.). values.).
9.1. Latency Baseline 9.1. Latency Baseline
Objective: Measure the intrinsic latency (min/avg/max) introduced by
a device without the use of IPsec.
Objective: Procedure: First determine the throughput for the DUT/SUT at each of
the listed frame sizes. Send a stream of frames at a particular
Measure the intrinsic latency (min/avg/max) introduced by a device frame size through the DUT at the determined throughput rate using
without the use of IPsec.
Procedure:
First determine the throughput for the DUT/SUT at each of the
listed frame sizes. Send a stream of frames at a particular frame
size through the DUT at the determined throughput rate using
frames that match the IPsec SA selector(s) to be tested. The frames that match the IPsec SA selector(s) to be tested. The
stream SHOULD be at least 120 seconds in duration. An identifying stream SHOULD be at least 120 seconds in duration. An identifying
tag SHOULD be included in one frame after 60 seconds with the type tag SHOULD be included in one frame after 60 seconds with the type
of tag being implementation dependent. The time at which this of tag being implementation dependent. The time at which this
frame is fully transmitted is recorded (timestamp A). The frame is fully transmitted is recorded (timestamp A). The
receiver logic in the test equipment MUST recognize the tag receiver logic in the test equipment MUST recognize the tag
information in the frame stream and record the time at which the information in the frame stream and record the time at which the
tagged frame was received (timestamp B). tagged frame was received (timestamp B).
The latency is timestamp B minus timestamp A as per the relevant The latency is timestamp B minus timestamp A as per the relevant
definition from RFC 1242, namely latency as defined for store and definition from RFC 1242, namely latency as defined for store and
forward devices or latency as defined for bit forwarding devices. forward devices or latency as defined for bit forwarding devices.
The test MUST be repeated at least 20 times with the reported The test MUST be repeated at least 20 times with the reported
value being the average of the recorded values. value being the average of the recorded values.
Reporting Format Reporting Format The report MUST state which definition of latency
(from [RFC1242]) was used for this test. The latency results
The report MUST state which definition of latency (from [RFC1242]) SHOULD be reported in the format of a table with a row for each of
was used for this test. The latency results SHOULD be reported in the tested frame sizes. There SHOULD be columns for the frame
the format of a table with a row for each of the tested frame size, the rate at which the latency test was run for that frame
sizes. There SHOULD be columns for the frame size, the rate at size, for the media types tested, and for the resultant latency
which the latency test was run for that frame size, for the media values for each type of data stream tested.
types tested, and for the resultant latency values for each type
of data stream tested.
9.2. IPsec Latency 9.2. IPsec Latency
Objective: Objective: Measure the intrinsic IPsec Latency (min/avg/max)
introduced by a device when using IPsec.
Measure the intrinsic IPsec Latency (min/avg/max) introduced by a
device when using IPsec.
Procedure:
First determine the throughput for the DUT/SUT at each of the Procedure: First determine the throughput for the DUT/SUT at each of
listed frame sizes. Send a stream of cleartext frames at a the listed frame sizes. Send a stream of cleartext frames at a
particular frame size through the DUT/SUT at the determined particular frame size through the DUT/SUT at the determined
throughput rate using frames that match the IPsec SA selector(s) throughput rate using frames that match the IPsec SA selector(s)
to be tested. DUTa will encrypt the traffic and forward to DUTb to be tested. DUTa will encrypt the traffic and forward to DUTb
which will in turn decrypt the traffic and forward to the testing which will in turn decrypt the traffic and forward to the testing
device. device.
The stream SHOULD be at least 120 seconds in duration. An The stream SHOULD be at least 120 seconds in duration. An
identifying tag SHOULD be included in one frame after 60 seconds identifying tag SHOULD be included in one frame after 60 seconds
with the type of tag being implementation dependent. The time at with the type of tag being implementation dependent. The time at
which this frame is fully transmitted is recorded (timestamp A). which this frame is fully transmitted is recorded (timestamp A).
skipping to change at page 21, line 8 skipping to change at page 21, line 15
tagged frame was received (timestamp B). tagged frame was received (timestamp B).
The IPsec Latency is timestamp B minus timestamp A as per the The IPsec Latency is timestamp B minus timestamp A as per the
relevant definition from [RFC1242], namely latency as defined for relevant definition from [RFC1242], namely latency as defined for
store and forward devices or latency as defined for bit forwarding store and forward devices or latency as defined for bit forwarding
devices. devices.
The test MUST be repeated at least 20 times with the reported The test MUST be repeated at least 20 times with the reported
value being the average of the recorded values. value being the average of the recorded values.
Reporting format: Reporting format: The reporting format SHOULD be the same as listed
in 8.1 with the additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 8.1 with the parameters defined in 5.6 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 5.6 and utilized for this test MUST be included in any
statement of performance.
9.3. IPsec Encryption Latency 9.3. IPsec Encryption Latency
Objective: Objective: Measure the DUT vendor specific IPsec Encryption Latency
for IPsec protected traffic.
Measure the DUT vendor specific IPsec Encryption Latency for IPsec
protected traffic.
Procedure:
Send a stream of cleartext frames at a particular frame size Procedure: Send a stream of cleartext frames at a particular frame
through the DUT/SUT at the determined throughput rate using frames size through the DUT/SUT at the determined throughput rate using
that match the IPsec SA selector(s) to be tested. frames that match the IPsec SA selector(s) to be tested.
The stream SHOULD be at least 120 seconds in duration. An The stream SHOULD be at least 120 seconds in duration. An
identifying tag SHOULD be included in one frame after 60 seconds identifying tag SHOULD be included in one frame after 60 seconds
with the type of tag being implementation dependent. The time at with the type of tag being implementation dependent. The time at
which this frame is fully transmitted is recorded (timestamp A). which this frame is fully transmitted is recorded (timestamp A).
The DUT will receive the cleartext frames, perform IPsec The DUT will receive the cleartext frames, perform IPsec
operations and then send the IPsec protected frames to the tester. operations and then send the IPsec protected frames to the tester.
Upon receipt of the encrypted frames, the receiver logic in the Upon receipt of the encrypted frames, the receiver logic in the
test equipment MUST recognize the tag information in the frame test equipment MUST recognize the tag information in the frame
stream and record the time at which the tagged frame was received stream and record the time at which the tagged frame was received
(timestamp B). (timestamp B).
The IPsec Encryption Latency is timestamp B minus timestamp A as The IPsec Encryption Latency is timestamp B minus timestamp A as
per the relevant definition from [RFC1242], namely latency as per the relevant definition from [RFC1242], namely latency as
defined for store and forward devices or latency as defined for defined for store and forward devices or latency as defined for
bit forwarding devices. bit forwarding devices.
The test MUST be repeated at least 20 times with the reported The test MUST be repeated at least 20 times with the reported
value being the average of the recorded values. value being the average of the recorded values.
Reporting format: Reporting format: The reporting format SHOULD be the same as listed
in 8.1 with the additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 8.1 with the parameters defined in 5.6 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 5.6 and utilized for this test MUST be included in any
statement of performance.
9.4. IPsec Decryption Latency 9.4. IPsec Decryption Latency
Objective: Objective: Measure the DUT Vendor Specific IPsec Decryption Latency
for IPsec protected traffic.
Measure the DUT Vendor Specific IPsec Decryption Latency for IPsec
protected traffic.
Procedure:
Send a stream of IPsec protected frames at a particular frame size Procedure: Send a stream of IPsec protected frames at a particular
through the DUT/SUT at the determined throughput rate using frames frame size through the DUT/SUT at the determined throughput rate
that match the IPsec SA selector(s) to be tested. using frames that match the IPsec SA selector(s) to be tested.
The stream SHOULD be at least 120 seconds in duration. An The stream SHOULD be at least 120 seconds in duration. An
identifying tag SHOULD be included in one frame after 60 seconds identifying tag SHOULD be included in one frame after 60 seconds
with the type of tag being implementation dependent. The time at with the type of tag being implementation dependent. The time at
which this frame is fully transmitted is recorded (timestamp A). which this frame is fully transmitted is recorded (timestamp A).
The DUT will receive the IPsec protected frames, perform IPsec The DUT will receive the IPsec protected frames, perform IPsec
operations and then send the cleartext frames to the tester. Upon operations and then send the cleartext frames to the tester. Upon
receipt of the decrypted frames, the receiver logic in the test receipt of the decrypted frames, the receiver logic in the test
equipment MUST recognize the tag information in the frame stream equipment MUST recognize the tag information in the frame stream
and record the time at which the tagged frame was received and record the time at which the tagged frame was received
(timestamp B). (timestamp B).
The IPsec Decryption Latency is timestamp B minus timestamp A as The IPsec Decryption Latency is timestamp B minus timestamp A as
per the relevant definition from [RFC1242], namely latency as per the relevant definition from [RFC1242], namely latency as
defined for store and forward devices or latency as defined for defined for store and forward devices or latency as defined for
bit forwarding devices. bit forwarding devices.
The test MUST be repeated at least 20 times with the reported The test MUST be repeated at least 20 times with the reported
value being the average of the recorded values. value being the average of the recorded values.
Reporting format: Reporting format: The reporting format SHOULD be the same as listed
in 8.1 with the additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 8.1 with the parameters defined in 5.6 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 5.6 and utilized for this test MUST be included in any
statement of performance.
10. Time To First Packet 10. Time To First Packet
Objective: Objective: Measure the time it takes to transmit a packet when no
SA's have been established.
Measure the time it takes to transmit a packet when no SAs have
been established.
Procedure:
Determine the IPsec throughput for the DUT/SUT at each of the Procedure: Determine the IPsec throughput for the DUT/SUT at each of
listed frame sizes. Start with a DUT/SUT with Configured Tunnels. the listed frame sizes. Start with a DUT/SUT with Configured
Send a stream of cleartext frames at a particular frame size Tunnels. Send a stream of cleartext frames at a particular frame
through the DUT/SUT at the determined throughput rate using frames size through the DUT/SUT at the determined throughput rate using
that match the IPsec SA selector(s) to be tested. frames 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 Note that it is possible that packets can be lost during IPsec
Tunnel establishment and that timestamp A & B are not required to Tunnel establishment and that timestamp A & B are not required to
be associated with a unique packet. be associated with a unique packet.
Reporting format: Reporting format: The Time To First Packet results SHOULD be
reported in the format of a table with a row for each of the
The Time To First Packet results SHOULD be reported in the format tested frame sizes. There SHOULD be columns for the frame size,
of a table with a row for each of the tested frame sizes. There the rate at which the TTFP test was run for that frame size, for
SHOULD be columns for the frame size, the rate at which the TTFP the media types tested, and for the resultant TTFP values for each
test was run for that frame size, for the media types tested, and type of data stream tested. The Security Context parameters
for the resultant TTFP values for each type of data stream tested. defined in 5.6 and utilized for this test MUST be included in any
The Security Context parameters defined in 5.6 and utilized for statement of performance.
this test MUST be included in any statement of performance.
11. Frame Loss Rate 11. Frame Loss Rate
This section presents methodologies relating to the characterization This section presents methodologies relating to the characterization
of frame loss rate, as defined in [RFC1242], in an IPsec environment. of frame loss rate, as defined in [RFC1242], in an IPsec environment.
11.1. Frame Loss Baseline 11.1. Frame Loss Baseline
Objective: Objective: To determine the frame loss rate, as defined in
[RFC1242], of a DUT/SUT throughout the entire range of input data
To determine the frame loss rate, as defined in [RFC1242], of a rates and frame sizes without the use of IPsec.
DUT/SUT throughout the entire range of input data rates and frame
sizes without the use of IPsec.
Procedure:
Send a specific number of frames at a specific rate through the Procedure: Send a specific number of frames at a specific rate
DUT/SUT to be tested using frames that match the IPsec SA through the DUT/SUT to be tested using frames that match the IPsec
selector(s) to be tested and count the frames that are transmitted SA selector(s) to be tested and count the frames that are
by the DUT/SUT. The frame loss rate at each point is calculated transmitted by the DUT/SUT. The frame loss rate at each point is
using the following equation: calculated using the following equation:
( ( input_count - output_count ) * 100 ) / input_count ( ( input_count - output_count ) * 100 ) / input_count
The first trial SHOULD be run for the frame rate that corresponds The first trial SHOULD be run for the frame rate that corresponds
to 100% of the maximum rate for the frame size on the input media. to 100% of the maximum rate for the frame size on the input media.
Repeat the procedure for the rate that corresponds to 90% of the Repeat the procedure for the rate that corresponds to 90% of the
maximum rate used and then for 80% of this rate. This sequence maximum rate used and then for 80% of this rate. This sequence
SHOULD be continued (at reducing 10% intervals) until there are SHOULD be continued (at reducing 10% intervals) until there are
two successive trials in which no frames are lost. The maximum two successive trials in which no frames are lost. The maximum
granularity of the trials MUST be 10% of the maximum rate, a finer granularity of the trials MUST be 10% of the maximum rate, a finer
granularity is encouraged. granularity is encouraged.
Reporting Format: Reporting Format: The results of the frame loss rate test SHOULD be
plotted as a graph. If this is done then the X axis MUST be the
The results of the frame loss rate test SHOULD be plotted as a input frame rate as a percent of the theoretical rate for the
graph. If this is done then the X axis MUST be the input frame media at the specific frame size. The Y axis MUST be the percent
rate as a percent of the theoretical rate for the media at the loss at the particular input rate. The left end of the X axis and
specific frame size. The Y axis MUST be the percent loss at the the bottom of the Y axis MUST be 0 percent; the right end of the X
particular input rate. The left end of the X axis and the bottom axis and the top of the Y axis MUST be 100 percent. Multiple
of the Y axis MUST be 0 percent; the right end of the X axis and lines on the graph MAY used to report the frame loss rate for
the top of the Y axis MUST be 100 percent. Multiple lines on the different frame sizes, protocols, and types of data streams.
graph MAY used to report the frame loss rate for different frame
sizes, protocols, and types of data streams.
11.2. IPsec Frame Loss 11.2. IPsec Frame Loss
Objective: Objective: To measure the frame loss rate of a device when using
IPsec to protect the data flow.
To measure the frame loss rate of a device when using IPsec to
protect the data flow.
Procedure:
Ensure that the DUT/SUT is in active tunnel mode. Send a specific Procedure: Ensure that the DUT/SUT is in active tunnel mode. Send a
number of cleartext frames that match the IPsec SA selector(s) to specific number of cleartext frames that match the IPsec SA
be tested at a specific rate through the DUT/SUT. DUTa will selector(s) to be tested at a specific rate through the DUT/SUT.
encrypt the traffic and forward to DUTb which will in turn decrypt DUTa will encrypt the traffic and forward to DUTb which will in
the traffic and forward to the testing device. The testing device turn decrypt the traffic and forward to the testing device. The
counts the frames that are transmitted by the DUTb. The frame testing device counts the frames that are transmitted by the DUTb.
loss rate at each point is calculated using the following The frame loss rate at each point is calculated using the
equation: following equation:
( ( input_count - output_count ) * 100 ) / input_count ( ( input_count - output_count ) * 100 ) / input_count
The first trial SHOULD be run for the frame rate that corresponds The first trial SHOULD be run for the frame rate that corresponds
to 100% of the maximum rate for the frame size on the input media. to 100% of the maximum rate for the frame size on the input media.
Repeat the procedure for the rate that corresponds to 90% of the Repeat the procedure for the rate that corresponds to 90% of the
maximum rate used and then for 80% of this rate. This sequence maximum rate used and then for 80% of this rate. This sequence
SHOULD be continued (at reducing 10% intervals) until there are SHOULD be continued (at reducing 10% intervals) until there are
two successive trials in which no frames are lost. The maximum two successive trials in which no frames are lost. The maximum
granularity of the trials MUST be 10% of the maximum rate, a finer granularity of the trials MUST be 10% of the maximum rate, a finer
granularity is encouraged. granularity is encouraged.
Reporting Format: Reporting Format: The reporting format SHOULD be the same as listed
in 10.1 with the additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 10.1 with the parameters defined in 6.7 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 6.7 and utilized for this test MUST be included in any
statement of performance.
11.3. IPsec Encryption Frame Loss 11.3. IPsec Encryption Frame Loss
Objective: Objective: To measure the effect of IPsec encryption on the frame
loss rate of a device.
To measure the effect of IPsec encryption on the frame loss rate
of a device.
Procedure:
Send a specific number of cleartext frames that match the IPsec SA Procedure: Send a specific number of cleartext frames that match the
selector(s) at a specific rate to the DUT. The DUT will receive IPsec SA selector(s) at a specific rate to the DUT. The DUT will
the cleartext frames, perform IPsec operations and then send the receive the cleartext frames, perform IPsec operations and then
IPsec protected frame to the tester. The testing device counts send the IPsec protected frame to the tester. The testing device
the encrypted frames that are transmitted by the DUT. The frame counts the encrypted frames that are transmitted by the DUT. The
loss rate at each point is calculated using the following frame loss rate at each point is calculated using the following
equation: equation:
( ( input_count - output_count ) * 100 ) / input_count ( ( input_count - output_count ) * 100 ) / input_count
The first trial SHOULD be run for the frame rate that corresponds The first trial SHOULD be run for the frame rate that corresponds
to 100% of the maximum rate for the frame size on the input media. to 100% of the maximum rate for the frame size on the input media.
Repeat the procedure for the rate that corresponds to 90% of the Repeat the procedure for the rate that corresponds to 90% of the
maximum rate used and then for 80% of this rate. This sequence maximum rate used and then for 80% of this rate. This sequence
SHOULD be continued (at reducing 10% intervals) until there are SHOULD be continued (at reducing 10% intervals) until there are
two successive trials in which no frames are lost. The maximum two successive trials in which no frames are lost. The maximum
granularity of the trials MUST be 10% of the maximum rate, a finer granularity of the trials MUST be 10% of the maximum rate, a finer
granularity is encouraged. granularity is encouraged.
Reporting Format: Reporting Format: The reporting format SHOULD be the same as listed
in 10.1 with the additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 10.1 with the parameters defined in 6.7 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 6.7 and utilized for this test MUST be included in any
statement of performance.
11.4. IPsec Decryption Frame Loss 11.4. IPsec Decryption Frame Loss
Objective: Objective: To measure the effects of IPsec encryption on the frame
loss rate of a device.
To measure the effects of IPsec encryption on the frame loss rate
of a device.
Procedure:
Send a specific number of IPsec protected frames that match the Procedure: Send a specific number of IPsec protected frames that
IPsec SA selector(s) at a specific rate to the DUT. The DUT will match the IPsec SA selector(s) at a specific rate to the DUT. The
receive the IPsec protected frames, perform IPsec operations and DUT will receive the IPsec protected frames, perform IPsec
then send the cleartext frames to the tester. The testing device operations and then send the cleartext frames to the tester. The
counts the cleartext frames that are transmitted by the DUT. The testing device counts the cleartext frames that are transmitted by
frame loss rate at each point is calculated using the following the DUT. The frame loss rate at each point is calculated using
equation: the following equation:
( ( input_count - output_count ) * 100 ) / input_count ( ( input_count - output_count ) * 100 ) / input_count
The first trial SHOULD be run for the frame rate that corresponds The first trial SHOULD be run for the frame rate that corresponds
to 100% of the maximum rate for the frame size on the input media. to 100% of the maximum rate for the frame size on the input media.
Repeat the procedure for the rate that corresponds to 90% of the Repeat the procedure for the rate that corresponds to 90% of the
maximum rate used and then for 80% of this rate. This sequence maximum rate used and then for 80% of this rate. This sequence
SHOULD be continued (at reducing 10% intervals) until there are SHOULD be continued (at reducing 10% intervals) until there are
two successive trials in which no frames are lost. The maximum two successive trials in which no frames are lost. The maximum
granularity of the trials MUST be 10% of the maximum rate, a finer granularity of the trials MUST be 10% of the maximum rate, a finer
granularity is encouraged. granularity is encouraged.
Reporting format: Reporting format: The reporting format SHOULD be the same as listed
in 10.1 with theadditional requirement that the Security Context
The reporting format SHOULD be the same as listed in 10.1 with the parameters defined in 6.7 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 6.7 and utilized for this test MUST be included in any
statement of performance.
11.5. IKE Phase 2 Rekey Frame Loss 11.5. IKE Phase 2 Rekey Frame Loss
Objective: Objective: To measure the frame loss due to an IKE Phase 2 (i.e.
IPsec SA) Rekey event.
To measure the frame loss due to an IKE Phase 2 (i.e. IPsec SA)
Rekey event.
Procedure:
The procedure is the same as in 10.2 with the exception that the
IPsec SA lifetime MUST be configured to be one-third of the trial
test duration or one-third of the total number of bytes to be
transmitted during the trial duration.
Reporting format: Procedure: The procedure is the same as in 10.2 with the exception
that the IPsec SA lifetime MUST be configured to be one-third of
the trial test duration or one-third of the total number of bytes
to be transmitted during the trial duration.
The reporting format SHOULD be the same as listed in 10.1 with the Reporting format: The reporting format SHOULD be the same as listed
additional requirement that the Security Context parameters in 10.1 with the additional requirement that the Security Context
defined in 6.7 and utilized for this test MUST be included in any parameters defined in 6.7 and utilized for this test MUST be
statement of performance. included in any statement of performance.
12. Back-to-back Frames 12. Back-to-back Frames
This section presents methodologies relating to the characterization This section presents methodologies relating to the characterization
of back-to-back frame processing, as defined in [RFC1242], in an of back-to-back frame processing, as defined in [RFC1242], in an
IPsec environment. IPsec environment.
12.1. Back-to-back Frames Baseline 12.1. Back-to-back Frames Baseline
Objective: Objective: To characterize the ability of a DUT to process back-to-
back frames as defined in [RFC1242], without the use of IPsec.
To characterize the ability of a DUT to process back-to-back
frames as defined in [RFC1242], without the use of IPsec.
Procedure:
Send a burst of frames that matches the IPsec SA selector(s) to be Procedure: Send a burst of frames that matches the IPsec SA
tested with minimum inter-frame gaps to the DUT and count the selector(s) to be tested with minimum inter-frame gaps to the DUT
number of frames forwarded by the DUT. If the count of and count the number of frames forwarded by the DUT. If the count
transmitted frames is equal to the number of frames forwarded the of transmitted frames is equal to the number of frames forwarded
length of the burst is increased and the test is rerun. If the the length of the burst is increased and the test is rerun. If
number of forwarded frames is less than the number transmitted, the number of forwarded frames is less than the number
the length of the burst is reduced and the test is rerun. transmitted, the length of the burst is reduced and the test is
rerun.
The back-to-back value is the number of frames in the longest The back-to-back value is the number of frames in the longest
burst that the DUT will handle without the loss of any frames. burst that the DUT will handle without the loss of any frames.
The trial length MUST be at least 2 seconds and SHOULD be repeated The trial length MUST be at least 2 seconds and SHOULD be repeated
at least 50 times with the average of the recorded values being at least 50 times with the average of the recorded values being
reported. reported.
Reporting format: Reporting format: The back-to-back results SHOULD be reported in the
format of a table with a row for each of the tested frame sizes.
The back-to-back results SHOULD be reported in the format of a There SHOULD be columns for the frame size and for the resultant
table with a row for each of the tested frame sizes. There SHOULD average frame count for each type of data stream tested. The
be columns for the frame size and for the resultant average frame standard deviation for each measurement MAY also be reported.
count for each type of data stream tested. The standard deviation
for each measurement MAY also be reported.
12.2. IPsec Back-to-back Frames 12.2. IPsec Back-to-back Frames
Objective: Objective: To measure the back-to-back frame processing rate of a
device when using IPsec to protect the data flow.
To measure the back-to-back frame processing rate of a device when
using IPsec to protect the data flow.
Procedure:
Send a burst of cleartext frames that matches the IPsec SA Procedure: Send a burst of cleartext frames that matches the IPsec
selector(s) to be tested with minimum inter-frame gaps to the DUT/ SA selector(s) to be tested with minimum inter-frame gaps to the
SUT. DUTa will encrypt the traffic and forward to DUTb which will DUT/SUT. DUTa will encrypt the traffic and forward to DUTb which
in turn decrypt the traffic and forward to the testing device. will in turn decrypt the traffic and forward to the testing
The testing device counts the frames that are transmitted by the device. The testing device counts the frames that are transmitted
DUTb. If the count of transmitted frames is equal to the number by the DUTb. If the count of transmitted frames is equal to the
of frames forwarded the length of the burst is increased and the number of frames forwarded the length of the burst is increased
test is rerun. If the number of forwarded frames is less than the and the test is rerun. If the number of forwarded frames is less
number transmitted, the length of the burst is reduced and the than the number transmitted, the length of the burst is reduced
test is rerun. and the test is rerun.
The back-to-back value is the number of frames in the longest The back-to-back value is the number of frames in the longest
burst that the DUT/SUT will handle without the loss of any frames. burst that the DUT/SUT will handle without the loss of any frames.
The trial length MUST be at least 2 seconds and SHOULD be repeated The trial length MUST be at least 2 seconds and SHOULD be repeated
at least 50 times with the average of the recorded values being at least 50 times with the average of the recorded values being
reported. reported.
Reporting Format: Reporting Format: The reporting format SHOULD be the same as listed
in 11.1 with the additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 11.1 with the parameters defined in 6.7 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 6.7 and utilized for this test MUST be included in any
statement of performance.
12.3. IPsec Encryption Back-to-back Frames 12.3. IPsec Encryption Back-to-back Frames
Objective: Objective: To measure the effect of IPsec encryption on the back-to-
back frame processing rate of a device.
To measure the effect of IPsec encryption on the back-to-back
frame processing rate of a device.
Procedure:
Send a burst of cleartext frames that matches the IPsec SA Procedure: Send a burst of cleartext frames that matches the IPsec
selector(s) to be tested with minimum inter-frame gaps to the DUT. SA selector(s) to be tested with minimum inter-frame gaps to the
The DUT will receive the cleartext frames, perform IPsec DUT. The DUT will receive the cleartext frames, perform IPsec
operations and then send the IPsec protected frame to the tester. operations and then send the IPsec protected frame to the tester.
The testing device counts the encrypted frames that are The testing device counts the encrypted frames that are
transmitted by the DUT. If the count of transmitted encrypted transmitted by the DUT. If the count of transmitted encrypted
frames is equal to the number of frames forwarded the length of frames is equal to the number of frames forwarded the length of
the burst is increased and the test is rerun. If the number of the burst is increased and the test is rerun. If the number of
forwarded frames is less than the number transmitted, the length forwarded frames is less than the number transmitted, the length
of the burst is reduced and the test is rerun. of the burst is reduced and the test is rerun.
The back-to-back value is the number of frames in the longest The back-to-back value is the number of frames in the longest
burst that the DUT will handle without the loss of any frames. burst that the DUT will handle without the loss of any frames.
The trial length MUST be at least 2 seconds and SHOULD be repeated The trial length MUST be at least 2 seconds and SHOULD be repeated
at least 50 times with the average of the recorded values being at least 50 times with the average of the recorded values being
reported. reported.
Reporting format: Reporting format: The reporting format SHOULD be the same as listed
in 11.1 with the additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 11.1 with the parameters defined in 6.7 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 6.7 and utilized for this test MUST be included in any
statement of performance.
12.4. IPsec Decryption Back-to-back Frames 12.4. IPsec Decryption Back-to-back Frames
Objective: Objective: To measure the effect of IPsec decryption on the back-to-
back frame processing rate of a device.
To measure the effect of IPsec decryption on the back-to-back
frame processing rate of a device.
Procedure:
Send a burst of cleartext frames that matches the IPsec SA Procedure: Send a burst of cleartext frames that matches the IPsec
selector(s) to be tested with minimum inter-frame gaps to the DUT. SA selector(s) to be tested with minimum inter-frame gaps to the
The DUT will receive the IPsec protected frames, perform IPsec DUT. The DUT will receive the IPsec protected frames, perform
operations and then send the cleartext frame to the tester. The IPsec operations and then send the cleartext frame to the tester.
testing device counts the frames that are transmitted by the DUT. The testing device counts the frames that are transmitted by the
If the count of transmitted frames is equal to the number of DUT. If the count of transmitted frames is equal to the number of
frames forwarded the length of the burst is increased and the test frames forwarded the length of the burst is increased and the test
is rerun. If the number of forwarded frames is less than the is rerun. If the number of forwarded frames is less than the
number transmitted, the length of the burst is reduced and the number transmitted, the length of the burst is reduced and the
test is rerun. test is rerun.
The back-to-back value is the number of frames in the longest The back-to-back value is the number of frames in the longest
burst that the DUT will handle without the loss of any frames. burst that the DUT will handle without the loss of any frames.
The trial length MUST be at least 2 seconds and SHOULD be repeated The trial length MUST be at least 2 seconds and SHOULD be repeated
at least 50 times with the average of the recorded values being at least 50 times with the average of the recorded values being
reported. reported.
Reporting format: Reporting format: The reporting format SHOULD be the same as listed
in 11.1 with the additional requirement that the Security Context
The reporting format SHOULD be the same as listed in 11.1 with the parameters defined in 6.7 and utilized for this test MUST be
additional requirement that the Security Context parameters included in any statement of performance.
defined in 6.7 and utilized for this test MUST be included in any
statement of performance.
13. IPsec Tunnel Setup Behavior 13. IPsec Tunnel Setup Behavior
13.1. IPsec Tunnel Setup Rate 13.1. IPsec Tunnel Setup Rate
Objective: Objective: Determine the rate at which IPsec Tunnels can be
established.
Determine the rate at which IPsec Tunnels can be established.
Procedure:
Configure the DUT/SUT with n IKE Phase 1 and corresponding IKE Procedure: Configure the DUT/SUT with n IKE Phase 1 and
Phase 2 policies. Ensure that no SA's are established and that corresponding IKE Phase 2 policies. Ensure that no SA's are
the DUT/SUT is in configured tunnel mode for all n policies. Send established and that the DUT/SUT is in configured tunnel mode for
a stream of cleartext frames at a particular frame size through all n policies. Send a stream of cleartext frames at a particular
the DUT/SUT at the determined throughput rate using frames with frame size through the DUT/SUT at the determined throughput rate
selectors matching the first IKE Phase 1 policy. As soon as the using frames with selectors matching the first IKE Phase 1 policy.
testing device receives its first frame from the DUT/SUT, it knows As soon as the testing device receives its first frame from the
that the IPsec Tunnel is established and starts sending the next DUT/SUT, it knows that the IPsec Tunnel is established and starts
stream of cleartext frames using the same frame size and sending the next stream of cleartext frames using the same frame
throughput rate but this time using selectors matching the second size and throughput rate but this time using selectors matching
IKE Phase 1 policy. This process is repeated until all configured the second IKE Phase 1 policy. This process is repeated until all
IPsec Tunnels have been established. configured IPsec Tunnels have been established.
The IPsec Tunnel Setup Rate is determined by the following The IPsec Tunnel Setup Rate is determined by the following
formula: formula:
Tunnel Setup Rate = n / [Duration of Test - (n * Tunnel Setup Rate = n / [Duration of Test - (n *
frame_transmit_time)] frame_transmit_time)]
The IKE SA lifetime and the IPsec SA lifetime MUST be configured The IKE SA lifetime and the IPsec SA lifetime MUST be configured
to exceed the duration of the test time. It is RECOMMENDED that to exceed the duration of the test time. It is RECOMMENDED that
n=100 IPsec Tunnels are tested at a minimum to get a large enough n=100 IPsec Tunnels are tested at a minimum to get a large enough
sample size to depict some real-world behavior. sample size to depict some real-world behavior.
Reporting Format: Reporting Format: The Tunnel Setup Rate results SHOULD be reported
in the format of a table with a row for each of the tested frame
The Tunnel Setup Rate results SHOULD be reported in the format of sizes. There SHOULD be columns for the frame size, the rate at
a table with a row for each of the tested frame sizes. There which the test was run for that frame size, for the media types
SHOULD be columns for the frame size, the rate at which the test tested, and for the resultant Tunnel Setup Rate values for each
was run for that frame size, for the media types tested, and for type of data stream tested. The Security Context parameters
the resultant Tunnel Setup Rate values for each type of data defined in 6.7 and utilized for this test MUST be included in any
stream tested. The Security Context parameters defined in 6.7 and statement of performance.
utilized for this test MUST be included in any statement of
performance.
13.2. IKE Phase 1 Setup Rate 13.2. IKE Phase 1 Setup Rate
Objective: Objective: Determine the rate of IKE SA's that can be established.
Determine the rate of IKE SA's that can be established.
Procedure:
Configure the DUT with n IKE Phase 1 and corresponding IKE Phase 2 Procedure: Configure the DUT with n IKE Phase 1 and corresponding
policies. Ensure that no SAs are established and that the DUT is IKE Phase 2 policies. Ensure that no SAs are established and that
in configured tunnel mode for all n policies. Send a stream of the DUT is in configured tunnel mode for all n policies. Send a
cleartext frames at a particular frame size through the DUT at the stream of cleartext frames at a particular frame size through the
determined throughput rate using frames with selectors matching DUT at the determined throughput rate using frames with selectors
the first IKE Phase 1 policy. As soon as the Phase 1 SA is matching the first IKE Phase 1 policy. As soon as the Phase 1 SA
established, the testing device starts sending the next stream of is established, the testing device starts sending the next stream
cleartext frames using the same frame size and throughput rate but of cleartext frames using the same frame size and throughput rate
this time using selectors matching the second IKE Phase 1 policy. but this time using selectors matching the second IKE Phase 1
This process is repeated until all configured IKE SAs have been policy. This process is repeated until all configured IKE SA's
established. have been established.
The IKE SA Setup Rate is determined by the following formula: The IKE SA Setup Rate is determined by the following formula:
IKE SA Setup Rate = n / [Duration of Test - (n * IKE SA Setup Rate = n / [Duration of Test - (n *
frame_transmit_time)] frame_transmit_time)]
The IKE SA lifetime and the IPsec SA lifetime MUST be configured The IKE SA lifetime and the IPsec SA lifetime MUST be configured
to exceed the duration of the test time. It is RECOMMENDED that to exceed the duration of the test time. It is RECOMMENDED that
n=100 IKE SAs are tested at a minumum to get a large enough sample n=100 IKE SA's are tested at a minumum to get a large enough
size to depict some real-world behavior. sample size to depict some real-world behavior.
Reporting Format:
The IKE Phase 1 Setup Rate results SHOULD be reported in the Reporting Format: The IKE Phase 1 Setup Rate results SHOULD be
format of a table with a row for each of the tested frame sizes. reported in the format of a table with a row for each of the
There SHOULD be columns for the frame size, the rate at which the tested frame sizes. There SHOULD be columns for the frame size,
test was run for that frame size, for the media types tested, and the rate at which the test was run for that frame size, for the
for the resultant IKE Phase 1 Setup Rate values for each type of media types tested, and for the resultant IKE Phase 1 Setup Rate
data stream tested. The Security Context parameters defined in values for each type of data stream tested. The Security Context
6.7 and utilized for this test MUST be included in any statement parameters defined in 6.7 and utilized for this test MUST be
of performance. included in any statement of performance.
13.3. IKE Phase 2 Setup Rate 13.3. IKE Phase 2 Setup Rate
Objective: Objective: Determine the rate of IPsec SA's that can be established.
Determine the rate of IPsec SA's that can be established.
Procedure:
Configure the DUT with a single IKE Phase 1 policy and n Procedure: Configure the DUT with a single IKE Phase 1 policy and n
corresponding IKE Phase 2 policies. Ensure that no SAs are corresponding IKE Phase 2 policies. Ensure that no SAs are
established and that the DUT is in configured tunnel mode for all established and that the DUT is in configured tunnel mode for all
policies. Send a stream of cleartext frames at a particular frame policies. Send a stream of cleartext frames at a particular frame
size through the DUT at the determined throughput rate using size through the DUT at the determined throughput rate using
frames with selectors matching the first IPsec SA policy. frames with selectors matching the first IPsec SA policy.
The time at which the IKE SA is established is recorded as The time at which the IKE SA is established is recorded as
timestamp A. As soon as the Phase 1 SA is established, the IPsec timestamp A. As soon as the Phase 1 SA is established, the IPsec
SA negotiation will be initiated. Once the first IPsec SA has SA negotiation will be initiated. Once the first IPsec SA has
been established, start sending the next stream of cleartext been established, start sending the next stream of cleartext
skipping to change at page 32, line 39 skipping to change at page 30, line 51
process is repeated until all configured IPsec SA's have been process is repeated until all configured IPsec SA's have been
established. established.
The IPsec SA Setup Rate is determined by the following formula: The IPsec SA Setup Rate is determined by the following formula:
IPsec SA Setup Rate = n / [Duration of Test - {A +((n-1) * IPsec SA Setup Rate = n / [Duration of Test - {A +((n-1) *
frame_transmit_time)}] frame_transmit_time)}]
The IKE SA lifetime and the IPsec SA lifetime MUST be configured The IKE SA lifetime and the IPsec SA lifetime MUST be configured
to exceed the duration of the test time. It is RECOMMENDED that to exceed the duration of the test time. It is RECOMMENDED that
n=100 IPsec SAs are tested at a minumum to get a large enough n=100 IPsec SA's are tested at a minumum to get a large enough
sample size to depict some real-world behavior. sample size to depict some real-world behavior.
Reporting Format: Reporting Format: The IKE Phase 2 Setup Rate results SHOULD be
reported in the format of a table with a row for each of the
The IKE Phase 2 Setup Rate results SHOULD be reported in the tested frame sizes. There SHOULD be columns for the frame size,
format of a table with a row for each of the tested frame sizes. the rate at which the test was run for that frame size, for the
There SHOULD be columns for the frame size, the rate at which the media types tested, and for the resultant IKE Phase 2 Setup Rate
test was run for that frame size, for the media types tested, and values for each type of data stream tested. The Security Context
for the resultant IKE Phase 2 Setup Rate values for each type of parameters defined in 6.7 and utilized for this test MUST be
data stream tested. The Security Context parameters defined in included in any statement of performance.
6.7 and utilized for this test MUST be included in any statement
of performance.
14. IPsec Rekey Behavior 14. IPsec Rekey Behavior
The IPsec Rekey Behavior test all need to be executed by an IPsec 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 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 IKE FSM and cannot be done by offering specific traffic pattern at
either the Initiator or the Responder. 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 SA's.
Determine the maximum rate at which an IPsec Device can rekey IKE
SA's.
Procedure:
The IPsec Device under test should initially be set up with the Procedure: The IPsec Device under test should initially be set up
determined IKE SA Capacity number of Active IPsec Tunnels. with the determined IKE SA Capacity number of Active IPsec
Tunnels.
The IPsec aware tester should then perform a binary search where The IPsec aware tester should then perform a binary search where
it initiates an IKE Phase 1 SA rekey for all Active IPsec Tunnels. it initiates an IKE Phase 1 SA rekey for all Active IPsec Tunnels.
The tester MUST timestamp for each IKE SA when it initiated the The tester MUST timestamp for each IKE SA when it initiated the
rekey and MUST timestamp once more once the FSM declares the rekey rekey and MUST timestamp once more once the FSM declares the rekey
is completed. Once the itteration is complete the tester now has is completed. Once the itteration is complete the tester now has
a table of rekey times for each IKE SA. The reciproce of the a table of rekey times for each IKE SA. The reciproce of the
average of this table is the IKE Phase 1 Rekey Rate. average of this table is the IKE Phase 1 Rekey Rate.
This is obviously granted that all IKE SA were able to rekey This is obviously granted that all IKE SA were able to rekey
succesfully. If this is not the case, the IPsec Tunnels are all 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 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 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 is determined at which a all SA's in that timeframe rekey
correctly. correctly.
Reporting Format: Reporting Format: The IKE Phase 1 Rekey Rate results SHOULD be
reported in the format of a table with a row for each of the
The IKE Phase 1 Rekey Rate results SHOULD be reported in the tested frame sizes. There SHOULD be columns for the frame size,
format of a table with a row for each of the tested frame sizes. the rate at which the test was run for that frame size, for the
There SHOULD be columns for the frame size, the rate at which the media types tested, and for the resultant IKE Phase 1 Rekey Rate
test was run for that frame size, for the media types tested, and values for each type of data stream tested. The Security Context
for the resultant IKE Phase 1 Rekey Rate values for each type of parameters defined in 6.7 and utilized for this test MUST be
data stream tested. The Security Context parameters defined in included in any statement of performance.
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 IPsec SA's.
Determine the maximum rate at which an IPsec Device can rekey
IPsec SA's.
Procedure:
The IPsec Device under test should initially be set up with the Procedure: The IPsec Device under test should initially be set up
determined IKE SA Capacity number of Active IPsec Tunnels. with the determined IKE SA Capacity number of Active IPsec
Tunnels.
The IPsec aware tester should then perform a binary search where 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 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 tester MUST timestamp for each IPsec SA when it initiated the
rekey and MUST timestamp once more once the FSM declares the rekey rekey and MUST timestamp once more once the FSM declares the rekey
is completed. Once the itteration is complete the tester now has is completed. Once the itteration is complete the tester now has
a table of rekey times for each IPsec SA. The reciproce of the a table of rekey times for each IPsec SA. The reciproce of the
average of this table is the IKE Phase 2 Rekey Rate. average of this table is the IKE Phase 2 Rekey Rate.
This is obviously granted that all IPsec SA were able to rekey This is obviously granted that all IPsec SA were able to rekey
succesfully. If this is not the case, the IPsec Tunnels are all succesfully. If this is not the case, the IPsec Tunnels are all
re-established and the binary search goes to the next value of 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 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 rate is determined at which a all SA's in that timeframe rekey
correctly. correctly.
Reporting Format: Reporting Format: The IKE Phase 2 Rekey Rate results SHOULD be
reported in the format of a table with a row for each of the
The IKE Phase 2 Rekey Rate results SHOULD be reported in the tested frame sizes. There SHOULD be columns for the frame size,
format of a table with a row for each of the tested frame sizes. the rate at which the test was run for that frame size, for the
There SHOULD be columns for the frame size, the rate at which the media types tested, and for the resultant IKE Phase 2 Rekey Rate
test was run for that frame size, for the media types tested, and values for each type of data stream tested. The Security Context
for the resultant IKE Phase 2 Rekey Rate values for each type of parameters defined in 6.7 and utilized for this test MUST be
data stream tested. The Security Context parameters defined in included in any statement of performance.
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 35, line 26 skipping to change at page 33, line 24
device and a standby device. In some cases the standby device is not device and a standby device. In some cases the standby device is not
present and two or more IPsec devices are backing eachother up in present and two or more IPsec devices are backing eachother up in
case of a catastrophic device or stack failure. The standby (or case of a catastrophic device or stack failure. The standby (or
potential other active) IPsec Devices can back up the active IPsec potential other active) IPsec Devices can back up the active IPsec
Device in either a stateless or statefull method. In the former Device in either a stateless or statefull method. In the former
case, Phase 1 SA's as well as Phase 2 SA's will need to be re- case, Phase 1 SA's as well as Phase 2 SA's will need to be re-
established in order to guarantuee packet forwarding. In the latter established in order to guarantuee packet forwarding. In the latter
case, the SPD and SADB of the active IPsec Device is synchronized to case, the SPD and SADB of the active IPsec Device is synchronized to
the standby IPsec Device to ensure immediate packet path recovery. the standby IPsec Device to ensure immediate packet path recovery.
Objective: Objective: Determine the time required to fail over all Active
Tunnels from an active IPsec Device to its standby device.
Determine the time required to fail over all Active Tunnels from
an active IPsec Device to its standby device.
Procedure:
Before a failover can be triggered, the IPsec Device has to be in Procedure: Before a failover can be triggered, the IPsec Device has
a state where the active stack/engine/node has a the maximum to be in a state where the active stack/engine/node has a the
supported number of Active Tunnnels. The Tunnels will be maximum supported number of Active Tunnnels. The Tunnels will be
transporting bidirectional traffic at the Tunnel Throughput rate transporting bidirectional traffic at the Tunnel Throughput rate
for the smallest framesize that the stack/engine/node is capable for the smallest framesize that the stack/engine/node is capable
of forwarding (In most cases, this will be 64 Bytes). The traffic of forwarding (In most cases, this will be 64 Bytes). The traffic
should traverse in a round robin fashion through all Active should traverse in a round robin fashion through all Active
Tunnels. Tunnels.
It is RECOMMENDED that the test is repeated for various number of It is RECOMMENDED that the test is repeated for various number of
Active Tunnels as well as for different framesizes and framerates. Active Tunnels as well as for different framesizes and framerates.
When traffic is flowing through all Active Tunnels in steady When traffic is flowing through all Active Tunnels in steady
skipping to change at page 36, line 37 skipping to change at page 34, line 32
Then it will find the SA with the largest gap in sequence number. Then it will find the SA with the largest gap in sequence number.
Given the fact that the framesize is fixed and the time of that Given the fact that the framesize is fixed and the time of that
framesize can easily be calculated for the initiator links, a framesize can easily be calculated for the initiator links, a
simple multiplication of the framesize time * largest packetloss simple multiplication of the framesize time * largest packetloss
gap will yield the Tunnel Failover Time. gap will yield the Tunnel Failover Time.
If the tester never reaches a state where all Tunnels are marked If the tester never reaches a state where all Tunnels are marked
as 'recovered', the the Failover Time MUST be listed as as 'recovered', the the Failover Time MUST be listed as
'infinite'. 'infinite'.
Reporting Format: The results shall be represented in a tabular
format, where the first column will list the number of Active
Tunnels, the second column the Framesize, the third column the
Framerate and the fourth column the Tunnel Failover Time in
milliseconds.
16. DoS Resiliency
16.1. Phase 1 DoS Resiliency Rate
Objective:
Procedure:
Reporting Format: Reporting Format:
The results shall be represented in a tabular format, where the 16.2. Phase 2 DoS Resiliency Rate
first column will list the number of Active Tunnels, the second
column the Framesize, the third column the Framerate and the
fourth column the Tunnel Failover Time in milliseconds.
16. Acknowledgements Objective:
Procedure:
Reporting Format:
17. Acknowledgements
The authors would like to acknowledge the following individual for The authors would like to acknowledge the following individual for
their help and participation of the compilation and editing of this their help and participation of the compilation and editing of this
document: Michele Bustos, Ixia. ; Paul Hoffman, VPNC document: Michele Bustos, Ixia. ; Paul Hoffman, VPNC
17. References 18. References
17.1. Normative References 18.1. Normative References
[RFC1242] Bradner, S., "Benchmarking terminology for network [RFC1242] Bradner, S., "Benchmarking terminology for network
interconnection devices", RFC 1242, July 1991. interconnection devices", RFC 1242, July 1991.
[RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery
for IP version 6", RFC 1981, August 1996. for IP version 6", RFC 1981, August 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
skipping to change at page 38, line 34 skipping to change at page 37, line 5
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999. RFC 2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000. March 2000.
[RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version [RFC4109] Hoffman, P., "Algorithms for Internet Key Exchange version
1 (IKEv1)", RFC 4109, May 2005. 1 (IKEv1)", RFC 4109, May 2005.
[RFC4305] Eastlake, D., "Cryptographic Algorithm Implementation
Requirements for Encapsulating Security Payload (ESP) and
Authentication Header (AH)", RFC 4305, December 2005.
[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-17 (work in progress), draft-ietf-ipsec-ikev2-17 (work in progress),
October 2004. October 2004.
[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.
17.2. Informative References 18.2. Informative References
[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>.
Authors' Addresses Authors' Addresses
Merike Kaeo Merike Kaeo
Double Shot Security Double Shot Security
520 Washington Blvd #363 3518 Fremont Ave N #363
Marina Del Rey, CA 90292 Seattle, WA 98103
US USA
Phone: +1 (310)866-0165 Phone: +1 (310)866-0165
Email: kaeo@merike.com Email: kaeo@merike.com
Tim Van Herck Tim Van Herck
Cisco Systems Cisco Systems
170 West Tasman Drive 170 West Tasman Drive
San Jose, CA 95134-1706 San Jose, CA 95134-1706
US USA
Phone: +1(408)853-2284
Email: herckt@cisco.com Email: herckt@cisco.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The IETF Trust (2007).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 40, line 29 skipping to change at page 38, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
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 that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Copyright Statement
Copyright (C) The Internet Society (2006). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 116 change blocks. 
581 lines changed or deleted 505 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/