draft-ietf-bmwg-ipsec-meth-04.txt   draft-ietf-bmwg-ipsec-meth-05.txt 
Benchmarking Working Group M. Kaeo Benchmarking Working Group M. Kaeo
Internet-Draft Double Shot Security Internet-Draft Double Shot Security
Expires: October 5, 2009 T. Van Herck Intended status: Informational T. Van Herck
Cisco Systems Expires: January 29, 2010 Cisco Systems
April 3, 2009 July 28, 2009
Methodology for Benchmarking IPsec Devices Methodology for Benchmarking IPsec Devices
draft-ietf-bmwg-ipsec-meth-04 draft-ietf-bmwg-ipsec-meth-05
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from IETF Standards Process. Without obtaining an adequate license from
skipping to change at page 1, line 43 skipping to change at page 1, line 43
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 October 5, 2009. This Internet-Draft will expire on January 29, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 4, line 14 skipping to change at page 4, line 14
12.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . . . 30 12.2. IKE Phase 1 Setup Rate . . . . . . . . . . . . . . . . . . 30
12.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . . . 31 12.3. IKE Phase 2 Setup Rate . . . . . . . . . . . . . . . . . . 31
13. IPsec Rekey Behavior . . . . . . . . . . . . . . . . . . . . . 32 13. IPsec Rekey Behavior . . . . . . . . . . . . . . . . . . . . . 32
13.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . 32 13.1. IKE Phase 1 Rekey Rate . . . . . . . . . . . . . . . . . . 32
13.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . 33 13.2. IKE Phase 2 Rekey Rate . . . . . . . . . . . . . . . . . . 33
14. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . . . 34 14. IPsec Tunnel Failover Time . . . . . . . . . . . . . . . . . . 34
15. DoS Attack Resiliency . . . . . . . . . . . . . . . . . . . . 36 15. DoS Attack Resiliency . . . . . . . . . . . . . . . . . . . . 36
15.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . . . 36 15.1. Phase 1 DoS Resiliency Rate . . . . . . . . . . . . . . . 36
15.2. Phase 2 Hash Mismatch DoS Resiliency Rate . . . . . . . . 37 15.2. Phase 2 Hash Mismatch DoS Resiliency Rate . . . . . . . . 37
15.3. Phase 2 Anti Replay Attack DoS Resiliency Rate . . . . . . 37 15.3. Phase 2 Anti Replay Attack DoS Resiliency Rate . . . . . . 37
16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39 16. Security Considerations . . . . . . . . . . . . . . . . . . . 39
17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 39
17.1. Normative References . . . . . . . . . . . . . . . . . . . 39 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 39
17.2. Informative References . . . . . . . . . . . . . . . . . . 41 18.1. Normative References . . . . . . . . . . . . . . . . . . . 39
18.2. Informative References . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 41
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 6, line 17 skipping to change at page 6, line 17
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.
5. Test Considerations 5. 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 executed to measure its performance without question must first be executed to measure its performance without
enabling IPsec. Once both the Baseline clear text performance and enabling IPsec). Once both the Baseline clear text performance and
the performance using an IPsec enabled datapath have been measured, the performance using an IPsec enabled datapath have been measured,
the difference between the two can be discerned. 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 or performance test methodology that includes the pre-configuration or
pre-population of routing protocols, ARP caches, IPv6 neighbor pre-population of routing protocols, ARP caches, IPv6 neighbor
discovery and all other extraneous IPv4 and IPv6 parameters required discovery and all other extraneous IPv4 and IPv6 parameters required
to pass packets before the tester is ready to send IPsec protected to pass packets before the tester is ready to send IPsec protected
packets. IPv6 nodes that implement Path MTU Discovery [RFC1981] MUST packets. IPv6 nodes that implement Path MTU Discovery [RFC1981] MUST
ensure that the PMTUD process has been completed before any of the ensure that the PMTUD process has been completed before any of the
skipping to change at page 21, line 26 skipping to change at page 21, line 26
impacts how latency is collected and subsequently presented. See the impacts how latency is collected and subsequently presented. See the
related RFC's 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
test vendor A presents a "store and forward" latency result and 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.).
10.1. Latency Baseline 10.1. Latency Baseline
Objective: Measure the intrinsic latency (min/avg/max) introduced by Objective: Measure the intrinsic latency (min/avg/max) introduced by
a device without the use of IPsec. a device without the use of IPsec.
Topology If no IPsec aware tester is available the test MUST be Topology If no IPsec aware tester is available the test MUST be
skipping to change at page 33, line 12 skipping to change at page 33, line 12
with the determined IPsec Tunnel Capacity number of Active IPsec with the determined IPsec Tunnel Capacity number of Active IPsec
Tunnels. 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 (timestamp_A) and MUST timestamp once more once the FSM rekey (timestamp_A) and MUST timestamp once more once the FSM
declares the rekey is completed (timestamp_B).The rekey time for a declares the rekey is completed (timestamp_B).The rekey time for a
specific SA equals timestamp_B - timestamp_A. Once the iteration specific SA equals timestamp_B - timestamp_A. Once the iteration
is complete the tester now has a table of rekey times for each IKE is complete the tester now has a table of rekey times for each IKE
SA. The reciproce of the average of this table is the IKE Phase 1 SA. The reciprocal of the average of this table is the IKE Phase
Rekey Rate. 1 Rekey Rate.
It is expected that all IKE SA were able to rekey succesfully. If It is expected that all IKE SA were able to rekey succesfully. If
this is not the case, the IPsec Tunnels are all re-established and this is not the case, the IPsec Tunnels are all re-established and
the binary search goes to the next value of IKE SA's it will the binary search goes to the next value of IKE SA's it will
rekey. The process will repeat itself until a rate is determined rekey. The process will repeat itself until a rate is determined
at which all SA's in that timeframe rekey correctly. at which all SA's in that timeframe rekey correctly.
Reporting Format: The IKE Phase 1 Rekey Rate results SHOULD be 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 reported in the format of a table with a row for each of the
tested frame sizes. There SHOULD be columns for the frame size, tested frame sizes. There SHOULD be columns for the frame size,
skipping to change at page 33, line 49 skipping to change at page 33, line 49
with the determined IPsec Tunnel Capacity number of Active IPsec with the determined IPsec Tunnel Capacity number of Active IPsec
Tunnels. 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 (timestamp_A) and MUST timestamp once more once the FSM rekey (timestamp_A) and MUST timestamp once more once the FSM
declares the rekey is completed (timestamp_B). The rekey time for declares the rekey is completed (timestamp_B). The rekey time for
a specific IPsec SA is timestamp_B - timestamp_A. Once the a specific IPsec SA is timestamp_B - timestamp_A. Once the
itteration is complete the tester now has a table of rekey times itteration is complete the tester now has a table of rekey times
for each IPsec SA. The reciproce of the average of this table is for each IPsec SA. The reciprocal of the average of this table is
the IKE Phase 2 Rekey Rate. the IKE Phase 2 Rekey Rate.
It is expected that all IPsec SA's were able to rekey succesfully. It is expected that all IPsec SA's were able to rekey succesfully.
If this is not the case, the IPsec Tunnels are all re-established If this is not the case, the IPsec Tunnels are all re-established
and the binary search goes to the next value of IPsec SA's it will and the binary search goes to the next value of IPsec SA's it will
rekey. The process will repeat itself until a rate is determined rekey. The process will repeat itself until a rate is determined
at which a all SA's in that timeframe rekey correctly. at which a all SA's in that timeframe rekey correctly.
Reporting Format: The IKE Phase 2 Rekey Rate results SHOULD be 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 reported in the format of a table with a row for each of the
skipping to change at page 35, line 43 skipping to change at page 35, line 43
If the tester observes no sequence number drops on any of the If the tester observes no sequence number drops on any of the
Tunnels in both directions then the Failover Time MUST be listed Tunnels in both directions then the Failover Time MUST be listed
as 'null', indicating that the failover was immediate and without as 'null', indicating that the failover was immediate and without
any packetloss. any packetloss.
In all other cases where the tester observes a gap in the sequence In all other cases where the tester observes a gap in the sequence
numbers of the instrumented payload of the packets, the tester numbers of the instrumented payload of the packets, the tester
will monitor all SA's and look for any Tunnels that are still not will monitor all SA's and look for any Tunnels that are still not
receiving packets after the Failover. These will be marked as receiving packets after the Failover. These will be marked as
'pending' Tunnels. Active Tunnels that are forwarding packets 'pending' Tunnels. Active Tunnels that are forwarding packets
again without any packetloss shall be marked as 'recovered' again without any additional packet loss shall be marked as
Tunnels. In background the tester will keep monitoring all SA's 'recovered' Tunnels. In background the tester will keep
to make sure that no packets are dropped. If this is the case monitoring all SA's to make sure that no packets are dropped. If
then the Tunnel in question will be placed back in 'pending' this is the case then the Tunnel in question will be placed back
state. in 'pending' state.
Note that reordered packets can naturally occur after en/ Note that reordered packets can naturally occur after en/
decryption. This is not a valid reason to place a Tunnel back in decryption. This is not a valid reason to place a Tunnel back in
'pending' state. 'pending' state.
The tester will wait until all Tunnel are marked as 'recovered'. The tester will wait until all Tunnel are marked as 'recovered'.
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
skipping to change at page 37, line 25 skipping to change at page 37, line 25
Reporting Format: The result shall be represented as the highest Reporting Format: The result shall be represented as the highest
percentage of invalid IKE Phase1 messages that still allowed all percentage of invalid IKE Phase1 messages that still allowed all
the valid attempts to be completed. The Security Context the valid attempts to be completed. The Security Context
Parameters defined in Section 7.6 and utilized for this test MUST Parameters defined in Section 7.6 and utilized for this test MUST
be included in any statement of performance. be included in any statement of performance.
15.2. Phase 2 Hash Mismatch DoS Resiliency Rate 15.2. Phase 2 Hash Mismatch DoS Resiliency Rate
Objective: Determine the rate of Hash Mismatched packets at which a Objective: Determine the rate of Hash Mismatched packets at which a
valid IPsec stream start dropping frames. valid IPsec stream starts dropping frames.
Topology: The test MUST be conducted using a Device Under Test Topology: The test MUST be conducted using a Device Under Test
Topology as depicted in Figure 1. Topology as depicted in Figure 1.
Procedure: A stream of IPsec traffic is offered to a DUT for Procedure: A stream of IPsec traffic is offered to a DUT for
decryption. This stream consists of two microflows. One valid decryption. This stream consists of two microflows. One valid
microflow and one that contains altered IPsec packets with a Hash microflow and one that contains altered IPsec packets with a Hash
Mismatch. The aggregate rate of both microflows MUST be equal to Mismatch. The aggregate rate of both microflows MUST be equal to
the IPsec Throughput and should therefore be able to pass the DUT. the IPsec Throughput and should therefore be able to pass the DUT.
A binary search will be applied to determine the ratio between the A binary search will be applied to determine the ratio between the
skipping to change at page 38, line 14 skipping to change at page 38, line 14
Objective: Determine the rate of replayed packets at which a valid Objective: Determine the rate of replayed packets at which a valid
IPsec stream start dropping frames. IPsec stream start dropping frames.
Topology: The test MUST be conducted using a Device Under Test Topology: The test MUST be conducted using a Device Under Test
Topology as depicted in Figure 1. Topology as depicted in Figure 1.
Procedure: A stream of IPsec traffic is offered to a DUT for Procedure: A stream of IPsec traffic is offered to a DUT for
decryption. This stream consists of two microflows. One valid decryption. This stream consists of two microflows. One valid
microflow and one that contains replayed packets of the valid microflow and one that contains replayed packets of the valid
microflow. The aggregate rate of both microflows MUST be equal to microflow. The aggregate rate of both microflows MUST be equal to
the IPsec Throughput ad should therefore be able to pass the DUT. the IPsec Throughput and should therefore be able to pass the DUT.
A binary seach will be applied to determine the ration between the A binary search will be applied to determine the ratio between the
two microflows that causes packetloss on the valid microflow of two microflows that causes packetloss on the valid microflow of
traffic. traffic.
The replayed packets should always be offered within the window of The replayed packets should always be offered within the window of
which the original packet arrived i.e. it MUST be replayed which the original packet arrived i.e. it MUST be replayed
directly after the original packet has been sent to the DUT. The directly after the original packet has been sent to the DUT. The
binary search SHOULD start with a low anti replay count where binary search SHOULD start with a low anti-replay count where
every few anti replay windows, a single packet in the window is every few anti-replay windows, a single packet in the window is
replayed. To increase this, one should obey the following replayed. To increase this, one should obey the following
sequence: sequence:
* Increase the replayed packets so every window contains a single * Increase the replayed packets so every window contains a single
replayed packet replayed packet
* Increase the replayed packets so every packet within a window * Increase the replayed packets so every packet within a window
is replayed once is replayed once
* Increase the replayed packets so packets within a single window * Increase the replayed packets so packets within a single window
are replayed multiple times following the same fill sequence are replayed multiple times following the same fill sequence
If the flow of replayed traffic equals the IPsec Throughput, the If the flow of replayed traffic equals the IPsec Throughput, the
flow SHOULD be increased till the point where packetloss is flow SHOULD be increased till the point where packetloss is
observed on the replayed traffic flow. observed on the replayed traffic flow.
The test MUST be conducted with a single Active Tunnel. It MAY be The test MUST be conducted with a single Active Tunnel. It MAY be
repeated at various Tunnel scalability data points. The test repeated at various Tunnel scalability data points. The test
SHOULD also be repeated on all configurable Anti Replay Window SHOULD also be repeated on all configurable anti-replay window
Sizes. sizes.
Reporting Format: PPS (of replayed traffic). The Security Context Reporting Format: PPS (of replayed traffic). The Security Context
Parameters defined in Section 7.6 and utilized for this test MUST Parameters defined in Section 7.6 and utilized for this test MUST
be included in any statement of performance. be included in any statement of performance.
16. Acknowledgements 16. Security Considerations
The authors would like to acknowledge the following individual for As this document is solely for the purpose of providing test
benchmarking methodology and describes neither a protocol nor a
protocol's implementation; there are no security considerations
associated with this document.
17. Acknowledgements
The authors would like to acknowledge the following individuals 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, Paul Hoffman, Benno Overeinder, Scott document: Michele Bustos, Paul Hoffman, Benno Overeinder, Scott
Poretsky and Yaron Sheffer Poretsky, Yaron Sheffer and Al Morton.
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 41, line 11 skipping to change at page 41, line 21
[RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D. [RFC5180] Popoviciu, C., Hamza, A., Van de Velde, G., and D.
Dugatkin, "IPv6 Benchmarking Methodology for Network Dugatkin, "IPv6 Benchmarking Methodology for Network
Interconnect Devices", RFC 5180, May 2008. Interconnect Devices", RFC 5180, May 2008.
[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
 End of changes. 20 change blocks. 
34 lines changed or deleted 42 lines changed or added

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