< 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 packet loss 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.
	35 lines changed or deleted		43 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/