< 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 12 ¶		skipping to change at page 27, line 12 ¶
	* 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 49 ¶		skipping to change at page 27, line 50 ¶
	- 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.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/