draft-ietf-bmwg-ipsec-term-11.txt   draft-ietf-bmwg-ipsec-term-12.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
M. Bustos M. Bustos
IXIA IXIA
April 3, 2009 July 28, 2009
Terminology for Benchmarking IPsec Devices Terminology for Benchmarking IPsec Devices
draft-ietf-bmwg-ipsec-term-11 draft-ietf-bmwg-ipsec-term-12
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 45 skipping to change at page 1, line 45
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 5 skipping to change at page 4, line 5
7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 23 7.10.1. Authentication Header (AH) . . . . . . . . . . . . . . 23
7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 24 7.10.2. Encapsulated Security Payload (ESP) . . . . . . . . . 24
7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 25 7.11. NAT Traversal (NAT-T) . . . . . . . . . . . . . . . . . . 25
7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 25 7.12. IP Compression . . . . . . . . . . . . . . . . . . . . . . 25
7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 26 7.13. Security Context . . . . . . . . . . . . . . . . . . . . . 26
8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 28 8. Framesizes . . . . . . . . . . . . . . . . . . . . . . . . . . 28
8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 28 8.1. Layer3 clear framesize . . . . . . . . . . . . . . . . . . 28
8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 29 8.2. Layer3 encrypted framesize . . . . . . . . . . . . . . . . 29
9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 30 9. Performance Metrics . . . . . . . . . . . . . . . . . . . . . 30
9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 30 9.1. IPsec Tunnels Per Second (TPS) . . . . . . . . . . . . . . 30
9.2. Tunnel Rekeys Per Seconds (TRPS) . . . . . . . . . . . . . 30 9.2. Tunnel Rekeys Per Second (TRPS) . . . . . . . . . . . . . 30
9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 30 9.3. IPsec Tunnel Attempts Per Second (TAPS) . . . . . . . . . 30
10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 31 10. Test Definitions . . . . . . . . . . . . . . . . . . . . . . . 31
10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 31 10.1. Capacity . . . . . . . . . . . . . . . . . . . . . . . . . 31
10.1.1. IPsec Tunnel Capacity . . . . . . . . . . . . . . . . 31 10.1.1. IPsec Tunnel Capacity . . . . . . . . . . . . . . . . 31
10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 31 10.1.2. IPsec SA Capacity . . . . . . . . . . . . . . . . . . 31
10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 32 10.2. Throughput . . . . . . . . . . . . . . . . . . . . . . . . 32
10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 32 10.2.1. IPsec Throughput . . . . . . . . . . . . . . . . . . . 32
10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 32 10.2.2. IPsec Encryption Throughput . . . . . . . . . . . . . 32
10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 33 10.2.3. IPsec Decryption Throughput . . . . . . . . . . . . . 33
10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 34 10.3. Latency . . . . . . . . . . . . . . . . . . . . . . . . . 34
skipping to change at page 14, line 34 skipping to change at page 14, line 34
Discussion: The main purpose of Phase 2 is to produce the key for Discussion: The main purpose of Phase 2 is to produce the key for
the IPsec tunnel. Phase 2 is also used for exchanging the IPsec tunnel. Phase 2 is also used for exchanging
informational messages. informational messages.
Issues: In other documents also referenced as IPsec SA. Issues: In other documents also referenced as IPsec SA.
See Also: IKE Phase 1, ISAKMP, IKE See Also: IKE Phase 1, ISAKMP, IKE
7.3.5. Phase 2 Quick Mode 7.3.5. Phase 2 Quick Mode
Definition: Quick Mode is an instanciation of IKE Phase 2. After Definition: Quick Mode is an instantiation of IKE Phase 2. After
successful completion it will result in one or typically two or successful completion it will result in one or typically two or
more IPsec SA's more IPsec SA's
Discussion: Quick Mode is used to negotiate the SA's and keys that Discussion: Quick Mode is used to negotiate the SA's and keys that
will be used to protect the user data. Three different messages will be used to protect the user data. Three different messages
are exchanged, which are protected by the security parameters are exchanged, which are protected by the security parameters
negotiated by the IKE phase 1 exchange. An additional Diffie- negotiated by the IKE phase 1 exchange. An additional Diffie-
Hellman exchange may be performed if PFS (Perfect Forward Secrecy) Hellman exchange may be performed if PFS (Perfect Forward Secrecy)
is enabled. is enabled.
skipping to change at page 19, line 15 skipping to change at page 19, line 15
manual keying that is provisioned in the IPsec device's manual keying that is provisioned in the IPsec device's
configuration. configuration.
Discussion: Several steps are required before IPsec can be used to Discussion: Several steps are required before IPsec can be used to
actually transport traffic. The very first step is to configure actually transport traffic. The very first step is to configure
the IPsec Tunnel (or IPsec SA's in the case of manual keying) in the IPsec Tunnel (or IPsec SA's in the case of manual keying) in
the IPsec device. When using IKE there are no SA's associated the IPsec device. When using IKE there are no SA's associated
with the IPsec Tunnel and no traffic is going through the IPsec with the IPsec Tunnel and no traffic is going through the IPsec
device that matches the Selectors, which would instantiate the device that matches the Selectors, which would instantiate the
IPsec Tunnel. When using either manual keying or IKE, a IPsec Tunnel. When using either manual keying or IKE, a
configured tunnel will not have a populated SADB. configured tunnel will not have a populated Security Association
Database (SADB).
Issues: When using IKE, a configured tunnel will not have any SA's Issues: When using IKE, a configured tunnel will not have any SA's
while with manual keying, the SA's will have simply been while with manual keying, the SA's will have simply been
configured but not populated in the SADB. configured but not populated in the SADB.
See Also: IPsec Tunnel, Established Tunnel, Active Tunnel See Also: IPsec Tunnel, Established Tunnel, Active Tunnel
7.7.3. Established Tunnel 7.7.3. Established Tunnel
Definition: An IPsec device that has a populated SADB and is ready Definition: An IPsec device that has a populated SADB and is ready
skipping to change at page 27, line 11 skipping to change at page 27, line 11
* Anti Replay Window Size (Assumed to be 64 packets if not * Anti Replay Window Size (Assumed to be 64 packets if not
specified) specified)
The IPsec Context MAY also list: The IPsec Context MAY also list:
* Selectors * Selectors
* Fragmentation handling (assumed to be post-encryption when not * Fragmentation handling (assumed to be post-encryption when not
mentioned) mentioned)
* PMTUD (assumed disabled when not mentioned) * Path MTU Discovery (PMTUD) (assumed disabled when not
mentioned)
The IKE Context MUST consist of the following elements: The IKE Context MUST consist of the following elements:
* Number of IPsec Tunnels. * Number of IPsec Tunnels.
+ IKE Phase 1 SA to IKE Phase 2 SA ratio (if applicable) + IKE Phase 1 SA to IKE Phase 2 SA ratio (if applicable)
+ IKE Phase 1 parameters + IKE Phase 1 parameters
- Authentication algorithm - Authentication algorithm
skipping to change at page 27, line 48 skipping to change at page 27, line 49
- Authentication algorithm (part of IPsec context) - Authentication algorithm (part of IPsec context)
- Encryption algorithm (part of IPsec context) - Encryption algorithm (part of IPsec context)
- DH-Group - DH-Group
- PFS Group used - PFS Group used
- SA Lifetime (part of IPsec context) - SA Lifetime (part of IPsec context)
* Use of IKE Keepalive or DPD, as defined in [RFC3706], and its * Use of IKE Keepalive or Dead Peer Detection (DPD), as defined
interval and retry values (assumed disabled when not in [RFC3706], and its interval and retry values (assumed
mentioned). disabled when not mentioned).
* IP Compression [RFC2393] * IP Compression [RFC2393]
The IKE context MUST also list: The IKE context MUST also list:
* Phase 1 mode (main or aggressive) * Phase 1 mode (main or aggressive)
* Available bandwidth and latency to Certificate Authority server * Available bandwidth and latency to Certificate Authority server
(if applicable) (if applicable)
skipping to change at page 30, line 18 skipping to change at page 30, line 18
Definition: The measurement unit for the IPsec Tunnel Setup Rate Definition: The measurement unit for the IPsec Tunnel Setup Rate
tests. The rate at which IPsec Tunnels are established per tests. The rate at which IPsec Tunnels are established per
second. second.
Discussion: According to [RFC2401] two IPsec Tunnels cannot be Discussion: According to [RFC2401] two IPsec Tunnels cannot be
established between the same gateways with the same selectors. established between the same gateways with the same selectors.
This is to prevent overlapping IPsec Tunnels. If overlapping This is to prevent overlapping IPsec Tunnels. If overlapping
IPsec Tunnels are attempted, the error will cause the IPsec Tunnel IPsec Tunnels are attempted, the error will cause the IPsec Tunnel
setup time to take longer than if the IPsec Tunnel setup was setup time to take longer than if the IPsec Tunnel setup was
successful. For this reason, a unique pair of selector sets are successful (and non-overlapping). For this reason, a unique pair
required for IPsec Tunnel Setup Rate testing. of selector sets are required for IPsec Tunnel Setup Rate testing.
Issues: A unique pair of selector sets are required for TPS testing. Issues: A unique pair of selector sets are required for TPS testing.
See Also: IPsec Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate, See Also: IPsec Tunnel Setup Rate Behavior, IPsec Tunnel Setup Rate,
IKE Setup Rate, IPsec Setup Rate IKE Setup Rate, IPsec Setup Rate
9.2. Tunnel Rekeys Per Seconds (TRPS) 9.2. Tunnel Rekeys Per Second (TRPS)
Definition: A metric that quantifies the number of IKE Phase 1 or Definition: A metric that quantifies the number of IKE Phase 1 or
Phase 2 rekeys per seconds a DUT can correctly process. Phase 2 rekeys per second a DUT can correctly process.
Discussion: This metric will be will be primary used with Tunnel Discussion: This metric will be will be primary used with Tunnel
Rekey behavior tests. Rekey behavior tests.
TRPS will provide a metric used to see system behavior under TRPS will provide a metric used to see system behavior under
stressful conditions where large volumes of SA's are being rekeyed stressful conditions where large volumes of SA's are being rekeyed
at the same time or in a short timespan. at the same time or in a short timespan.
Issues: N/A Issues: N/A
See Also: Tunnel Rekey Behavior, Phase 1 Rekey Rate, Phase 2 Rekey See Also: Tunnel Rekey Behavior, Phase 1 Rekey Rate, Phase 2 Rekey
Rate Rate
9.3. IPsec Tunnel Attempts Per Second (TAPS) 9.3. IPsec Tunnel Attempts Per Second (TAPS)
Definition: A metric that quantifies the number of successful and Definition: A metric that quantifies the number of successful and
unsuccessful IPsec Tunnel establishment requests per second. unsuccessful IPsec Tunnel establishment requests per second.
Discussion: This metric can be used to measure IKE DOS Resilience Discussion: This metric can be used to measure IKE DOS Resilience
behavior test. behavior.
TAPS provides an important metric to validate the stability of an TAPS provides an important metric to validate the stability of an
IPsec device, if stressed with valid (large number of IPsec tunnel IPsec device, if stressed with valid (large number of IPsec tunnel
establishments per seconds or TPS) or invalid (IKE DOS attacks of establishments per seconds or TPS) or invalid (IKE DOS attacks of
any style) tunnel establishment requests. IPsec Tunnel setups any style) tunnel establishment requests. IPsec Tunnel setups
offered to an IPsec devices can either fail due to lack of offered to an IPsec devices can either fail due to lack of
resources in the IPsec device to process all the requests or due resources in the IPsec device to process all the requests or due
to an IKE DOS attack (usually the former is a result of the to an IKE DOS attack (usually the former is a result of the
latter). latter).
skipping to change at page 31, line 29 skipping to change at page 31, line 29
10. Test Definitions 10. Test Definitions
10.1. Capacity 10.1. Capacity
10.1.1. IPsec Tunnel Capacity 10.1.1. IPsec Tunnel Capacity
Definition: The maximum number of Active IPsec Tunnels that can be Definition: The maximum number of Active IPsec Tunnels that can be
sustained on an IPsec Device. sustained on an IPsec Device.
Discussion: This metric will represent the quantity of IPsec Tunnels Discussion: This metric will represent the quantity of IPsec Tunnels
that can be establish on an IPsec Device that can forward traffic that can be established on an IPsec Device that can forward
i.e. Active Tunnels. It will be a measure that indicates how traffic i.e. Active Tunnels. It will be a measure that indicates
many remote peers an IPsec Device can establish a secure how many remote peers an IPsec Device can establish a secure
connection with. For IPsec Tunnel Capacity, each IPsec SA is connection with. For IPsec Tunnel Capacity, each IPsec SA is
associated with exactly 1 IKE SA. associated with exactly 1 IKE SA.
Measurement Units: IPsec Tunnels Measurement Units: IPsec Tunnels
Issues: N/A Issues: N/A
See Also: IPsec SA Capacity See Also: IPsec SA Capacity
10.1.2. IPsec SA Capacity 10.1.2. IPsec SA Capacity
skipping to change at page 33, line 13 skipping to change at page 33, line 13
this case fragmentation will be required before IPsec services are this case fragmentation will be required before IPsec services are
applied. applied.
In other cases, the packet is of a size very close to the MTU of In other cases, the packet is of a size very close to the MTU of
the egress interface of the IPsec Tunnel. Here, the mere addition the egress interface of the IPsec Tunnel. Here, the mere addition
of the IPsec header will create enough overhead to make the IPsec of the IPsec header will create enough overhead to make the IPsec
packet larger then the MTU of the egress interface. In such packet larger then the MTU of the egress interface. In such
instance, the original payload packet must be fragmented either instance, the original payload packet must be fragmented either
before or after the IPsec overhead is applied. before or after the IPsec overhead is applied.
Note that the two aforementioned scenario's can happen Note that the two aforementioned scenarios can happen
simultaniously on a single packet, creating multiple small simultaniously on a single packet, creating multiple small
fragments. fragments.
When measuring the IPsec Encryption Throughput, one has to When measuring the IPsec Encryption Throughput, one has to
consider that when probing with packets of a size near MTU's consider that when probing with packets of a size near MTU's
associated with the IPsec Tunnel, fragmentation may accor and the associated with the IPsec Tunnel, fragmentation may accor and the
decrypting IPsec Device (either a tester or a corresponding IPsec decrypting IPsec Device (either a tester or a corresponding IPsec
peer) has to reassemble the IPsec and/or payload fragments to peer) has to reassemble the IPsec and/or payload fragments to
validate its content. validate its content.
skipping to change at page 38, line 30 skipping to change at page 38, line 30
Discussion: The Tunnel Setup Rate SHOULD be measured at varying Discussion: The Tunnel Setup Rate SHOULD be measured at varying
number of IPsec Tunnels (1 Phase 1 SA and 2 Phase 2 SA's) on the number of IPsec Tunnels (1 Phase 1 SA and 2 Phase 2 SA's) on the
DUT. Several factors may influence Tunnel Setup Rate, such as: DUT. Several factors may influence Tunnel Setup Rate, such as:
TAPS rate, Background cleartext traffic load on the secure TAPS rate, Background cleartext traffic load on the secure
interface, Already established IPsec Tunnels, Authentication interface, Already established IPsec Tunnels, Authentication
method such as pre-shared keys, RSA-encryption, RSA-signature, DSS method such as pre-shared keys, RSA-encryption, RSA-signature, DSS
Key sizes used (when using RSA/DSS). Key sizes used (when using RSA/DSS).
The Tunnel Setup Rate is an important factor to understand when The Tunnel Setup Rate is an important factor to understand when
designing networks using statless failover of IPsec tunnels to a designing networks using stateless failover of IPsec tunnels to a
standby chassis. At the same time it can be important to set standby chassis. At the same time it can be important to set
Connection and Admission control paramters in an IPsec device to Connection and Admission control paramters in an IPsec device to
prevent overloading the IPsec Device. prevent overloading the IPsec Device.
Measurement Units: Tunnels Per Second (TPS) Measurement Units: Tunnels Per Second (TPS)
Issues: N/A Issues: N/A
See Also: IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec See Also: IKE Phase 1 Setup Rate, IKE Phase 2 Setup Rate, IPsec
Tunnel Rekey Behavior Tunnel Rekey Behavior
skipping to change at page 39, line 14 skipping to change at page 39, line 14
Measurement Units: Tunnels Per Second (TPS) Measurement Units: Tunnels Per Second (TPS)
Issues: N/A Issues: N/A
See Also: IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec See Also: IPsec Tunnel Setup Rate, IKE Phase 2 Setup Rate, IPsec
Tunnel Rekey Behavior Tunnel Rekey Behavior
10.5.3. IKE Phase 2 Setup Rate 10.5.3. IKE Phase 2 Setup Rate
Definition: The maximum number of successfully IKE Phase 2 SA's per Definition: The maximum number of successful IKE Phase 2 SA's per
second that an IPsec Device can Only relevant when using IKE second that an IPsec Device can Only relevant when using IKE
establish. establish.
Discussion: The IKE Phase 2 Setup Rate is a portion of the IPsec Discussion: The IKE Phase 2 Setup Rate is a portion of the IPsec
Tunnel Setup Rate. For identical reasons why it is required to Tunnel Setup Rate. For identical reasons why it is required to
quantify the IKE Phase 1 Setup Rate, it is a good practice to know quantify the IKE Phase 1 Setup Rate, it is a good practice to know
the processing delays involved in setting up an IKE Phase 2 SA for the processing delays involved in setting up an IKE Phase 2 SA for
each direction of the protected traffic flow. each direction of the protected traffic flow.
IKE Phase 2 Setup Rates will ALWAYS be measured for multiples of IKE Phase 2 Setup Rates will ALWAYS be measured for multiples of
skipping to change at page 42, line 50 skipping to change at page 42, line 50
11. Security Considerations 11. Security Considerations
As this document is solely for the purpose of providing test As this document is solely for the purpose of providing test
benchmarking terminology and describes neither a protocol nor a benchmarking terminology and describes neither a protocol nor a
protocol's implementation; there are no security considerations protocol's implementation; there are no security considerations
associated with this document. associated with this document.
12. Acknowledgements 12. Acknowledgements
The authors would like to acknowledge the following individual for The authors would like to acknowledge the following individuals for
their participation of the compilation and editing of this document their participation of the compilation and editing of this document
and guidance: Debby Stopp, Paul Hoffman, Sunil Kalidindi, Brian and guidance: Debby Stopp, Paul Hoffman, Sunil Kalidindi, Brian
Talbert and Yaron Sheffer. Talbert, Yaron Sheffer and Al Morton.
13. References 13. References
13.1. Normative References 13.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.
[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.
 End of changes. 19 change blocks. 
25 lines changed or deleted 27 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/