< draft-gont-6man-flowlabel-security-02.txt		draft-gont-6man-flowlabel-security-03.txt >
	IPv6 maintenance Working Group (6man) F. Gont		IPv6 maintenance Working Group (6man) F. Gont
	Internet-Draft UK CPNI		Internet-Draft UK CPNI
	Intended status: BCP January 12, 2012		Intended status: BCP March 12, 2012
	Expires: July 15, 2012		Expires: September 13, 2012
	Security Assessment of the IPv6 Flow Label		Security Assessment of the IPv6 Flow Label
	draft-gont-6man-flowlabel-security-02		draft-gont-6man-flowlabel-security-03
	Abstract		Abstract
	This document discusses the security implications of the IPv6 "Flow		This document discusses the security implications of the IPv6 "Flow
	Label" header field, and analyzes possible schemes for selecting the		Label" header field, and analyzes possible schemes for selecting the
	Flow Label value of IPv6 packets.		Flow Label value of IPv6 packets.
	Status of this Memo		Status of this Memo
	This Internet-Draft is submitted in full conformance with the		This Internet-Draft is submitted in full conformance with the
	skipping to change at page 1, line 34 ¶		skipping to change at page 1, line 34 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	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."
	This Internet-Draft will expire on July 15, 2012.		This Internet-Draft will expire on September 13, 2012.
	Copyright Notice		Copyright Notice
	Copyright (c) 2012 IETF Trust and the persons identified as the		Copyright (c) 2012 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		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Vulnerability analysis . . . . . . . . . . . . . . . . . . . . 4		2. Vulnerability analysis . . . . . . . . . . . . . . . . . . . . 4
	2.1. RFC3697-compliant implementations . . . . . . . . . . . . 4		2.1. RFC3697-compliant implementations . . . . . . . . . . . . 4
	2.1.1. DoS resulting from verification of Flow Label		2.1.1. DoS resulting from verification of Flow Label
	consistency . . . . . . . . . . . . . . . . . . . . . 4		consistency . . . . . . . . . . . . . . . . . . . . . 4
	2.1.2. Covert channels . . . . . . . . . . . . . . . . . . . 5		2.1.2. Covert channels . . . . . . . . . . . . . . . . . . . 5
	2.1.3. QoS theft . . . . . . . . . . . . . . . . . . . . . . 5		2.1.3. QoS theft . . . . . . . . . . . . . . . . . . . . . . 5
	2.1.4. Information Leaking . . . . . . . . . . . . . . . . . 5		2.1.4. Information Leaking . . . . . . . . . . . . . . . . . 5
	2.2. RFC6437-compliant implementations . . . . . . . . . . . . 6		2.2. RFC6437-compliant implementations . . . . . . . . . . . . 6
	3. Selecting Flow Label values . . . . . . . . . . . . . . . . . 7		3. Selecting Flow Label values . . . . . . . . . . . . . . . . . 7
	4. Secret-key considerations . . . . . . . . . . . . . . . . . . 12		3.1. Recommended algorithm . . . . . . . . . . . . . . . . . . 7
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 13		3.2. Alternative Algorithm . . . . . . . . . . . . . . . . . . 7
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14		3.2.1. Secret-key considerations . . . . . . . . . . . . . . 10
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15		4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	8.1. Normative References . . . . . . . . . . . . . . . . . . . 16		6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
	8.2. Informative References . . . . . . . . . . . . . . . . . . 16		7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
			7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
			7.2. Informative References . . . . . . . . . . . . . . . . . . 14
	Appendix A. Survey of Flow Label selection algorithms in use		Appendix A. Survey of Flow Label selection algorithms in use
	by some popular implementations . . . . . . . . . . . 18		by some popular implementations . . . . . . . . . . . 16
	A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 18		A.1. FreeBSD . . . . . . . . . . . . . . . . . . . . . . . . . 16
	A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 18		A.2. Linux . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 18		A.3. NetBSD . . . . . . . . . . . . . . . . . . . . . . . . . . 16
	A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 18		A.4. OpenBSD . . . . . . . . . . . . . . . . . . . . . . . . . 16
	A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 18		A.5. OpenSolaris . . . . . . . . . . . . . . . . . . . . . . . 16
	Appendix B. Changes from previous versions of the draft (to		Appendix B. Changes from previous versions of the draft (to
	be removed by the RFC Editor before publication		be removed by the RFC Editor before publication
	of this document as a RFC . . . . . . . . . . . . . . 19		of this document as a RFC . . . . . . . . . . . . . . 17
	B.1. Changes from draft-gont-6man-flowlabel-security-01 . . . . 19		B.1. Changes from draft-gont-6man-flowlabel-security-02 . . . . 17
	B.2. Changes from draft-gont-6man-flowlabel-security-00 . . . . 19		B.2. Changes from draft-gont-6man-flowlabel-security-01 . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20		B.3. Changes from draft-gont-6man-flowlabel-security-00 . . . . 17
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18
	1. Introduction		1. Introduction
	The flow label is a 20-bit field that allows a source to label		The flow label is a 20-bit field that allows a source to label
	sequences of packets for which it requests special handling by IPv6		sequences of packets for which it requests special handling by IPv6
	routers (e.g., non-default quality of service). It is specified in		routers (e.g., non-default quality of service). It is specified in
	[RFC6437]. RFC 6438 [RFC6438] specifies the use of the Flow Label		[RFC6437]. RFC 6438 [RFC6438] specifies the use of the Flow Label
	for Equal Cost Multipath Routing and Link Aggregation in Tunnels.		for Equal Cost Multipath Routing and Link Aggregation in Tunnels.
	It was originally loosely specified in RFC 2460 [Deering and		The FLow Label was originally loosely specified in RFC 2460
	Hinden, 1998] then later refined in [RFC3697]. Its specification		[RFC2460], and then later refined in [RFC3697]. Its specification
	has been recently revised by RFC 6437 [RFC6437]. [RFC6436]		has been recently revised by RFC 6437 [RFC6437]. [RFC6436]
	discusses the rationale for the update to the Flow Label		discusses the rationale for the update to the Flow Label
	specification in [RFC6437].		specification in [RFC6437].
	Section 2Section 2.1[RFC6437]Section 2.2[RFC6437]		Section 2Section 2.1[RFC6437]Section 2.2[RFC6437]
	2. Vulnerability analysis		2. Vulnerability analysis
	2.1. RFC3697-compliant implementations		2.1. RFC3697-compliant implementations
	2.1.1. DoS resulting from verification of Flow Label consistency		2.1.1. DoS resulting from verification of Flow Label consistency
	[RFC2460] states that hosts and routers that do not support the		[RFC2460] states that hosts and routers that do not support the
	functions of the Flow Label field are required to set this field to		functions of the Flow Label field are required to set this field to
	zero, pass the field unchanged when forwarding a packet, and ignore		zero, pass the field unchanged when forwarding a packet, and ignore
	the field when forwarding a packet.		the field when forwarding a packet.
	If any packet belonging to a flow includes a Hop-by-Hop Options		If any packet belonging to a flow includes a Hop-by-Hop Options
	header, then they all must be sent with the same Hop-by-Hop Options		header, then all packets of that flow must contain a Hop-by-Hop
	header contents (excluding the Next Header field of the Hop-by-Hop		Options header with the same contents (excluding the Next Header
	Options header). If any of those packets contains a Routing Header,		field of the Hop-by-Hop Options header). If any packet belonging to
	then all packets belonging to that flow must be originated with the		a flow contains a Routing Header, then all packets of that flow must
	same contents in all Extension Headers up to and including the		have the same contents in all Extension Headers up to and including
	Routing Header (but excluding the Next Header field of the Routing		the Routing Header (but excluding the Next Header field of the
	header).		Routing header).
	Appendix A of [RFC2460] states that routers and destinations are		Appendix A of [RFC2460] states that routers and destinations are
	permitted, but not required, to verify that these conditions are		permitted, but not required, to verify that these conditions are
	satisfied. In order to perform this verification, the Hop-by-Hop		satisfied. In order to perform this verification, the Hop-by-Hop
	Options header (and possibly the Destination Options header and the		Options header (and possibly the Destination Options header and the
	Routing header) used for the packets of each of the different flows		Routing header) used for the packets of each of the different flows
	should be kept in memory. This requirement, by itself, would open		should be kept in memory. This requirement, by itself, would open
	the door to at least two Denial of Service (DoS) vulnerabilities.		the door to at least two Denial of Service (DoS) vulnerabilities.
	Firstly, an attacker could forge a large number of packets with		Firstly, an attacker could forge a large number of packets with
	skipping to change at page 7, line 23 ¶		skipping to change at page 7, line 23 ¶
	o Flow Labels (together with the Source Address and the Destination		o Flow Labels (together with the Source Address and the Destination
	Address) are meant to uniquely identify a packet "flow". Hence,		Address) are meant to uniquely identify a packet "flow". Hence,
	to the extent that is possible each flow should result in a unique		to the extent that is possible each flow should result in a unique
	{Source Address, Destination Address, Flow Label} set of values at		{Source Address, Destination Address, Flow Label} set of values at
	any given time.		any given time.
	o In order to help with the use of the Flow Label for Equal Cost		o In order to help with the use of the Flow Label for Equal Cost
	Multipath Routing (ECMP) and Link Aggregation (LAG) in Tunnels,		Multipath Routing (ECMP) and Link Aggregation (LAG) in Tunnels,
	Flow Labels should (ideally) have a uniform distribution.		Flow Labels should (ideally) have a uniform distribution.
	These requirements are similar to those of TCP port numbers, TCP		Section 3.1 specifies the RECOMMENDED algorithm for selecting Flow
	Initial Sequence Numbers, and TCP timestamps. [CPNI-TCP] provides		Label values. Section 3.2 specifies an alternative algorithm that
	a detailed discussion of the requirements for such TCP parameters,		MAY be used by those implementations concerned about the Flow Label
	and a number of algorithms that could be used to meet those		reuse frequency of the RECOMMENDED algorithm.
	requirements.
	Considering that the Flow Label is a 20-bit field, and that Flow
	Label values must be unique for each (Source Address, Destination
	Address) pair at any given time, it might make sense to simply
	randomize the Flow Label value for each new flow.
	This has been proposed in [I-D.blake-ipv6-flow-label-nonce].		3.1. Recommended algorithm
	In order to reduce the chances of collisions of Flow Label values,		Considering that the Flow Label is a 20-bit field, that Flow Label
	while still providing obfuscation, we propose that the Flow Label for		values must be unique for each (Source Address, Destination Address)
	new IPv6 flows be selected according the following scheme:		pair at any given time, and that [RFC6437] relaxed the requirement of
			uniqueness that was enforced in [RFC3697], we RECOMMEND that the Flow
			Label of each flo be selected acording to a PRNG. That is, each Flow
			Label would be selected with:
	Flow Label = counter + F(Source Address, Destination Address, Secret Key)		Flow Label = random()
	where:		where:
	counter:		random():
	Is a variable that is initialized to some arbitrary value, and is		Is a a Pseudo-Random Number Generator (PRNG).
	incremented once for each flow label value that is selected.
	F():
	Is a hash function that should take as input both the Source
	Address and the Destination Address, and a secret key. The result
	of F should not be computable without knowledge of all the
	parameters of the hash function.
	This scheme should be used when a new flow is to be created (e.g.,
	when a new TCP connection is to be created). Once a Flow Label value
	for such flow is selected, the Flow Label field of all the IPv6
	packets corresponding to that flow would be set to the selected value
	(until the flow is terminated).
	This scheme was originally proposed in [RFC1948] for the selection of
	TCP Initial Sequence Numbers, and later proposed for the selection of
	TCP ephemeral ports [RFC6056] and for the selection of TCP timestamps
	[CPNI-TCP].
	This scheme separates the Flow Label space for each pair of (Source
	Address, Destination Address), resulting in a sequence of
	monotonically-increasing Flow Label values (with a pseudo-random
	origin) within each of those Flow Label spaces.
	The following figure illustrates this algorithm in pseudo-code:
	/* Initialization at system boot time */
	counter = 0;
	/* Flow Label selection function */
	offset = F(local_IP, remote_IP, secret_key);
	count = 1048576;
	do {
	flowlabel = (offset + counter) % 1048576;
	counter++;
	if(three-tuple is unique)
	return flowlabel;
	count--;
	} while (count > 0);
	/* Set the Flow Label to 0 if there is no
	unused Flow Label */
	return 0;
	Figure 1
	This algorithm should be executed when a new flow is to be created
	(e.g., when a new TCP connection is to be created). Once a Flow
	Label value for such flow is selected, the Flow Label field of all
	the IPv6 packets corresponding to that flow would be set to the
	selected value (until the flow is terminated).
	The following table shows a sample output of this scheme:
	+-----+-------------+-------------+--------+---------+------------+
	| Nr. | Src. Addr. | Dst. Addr. | offset | counter | Flow Label |
	+-----+-------------+-------------+--------+---------+------------+
	| #1 | 2001:db8::1 | 2001:db8::2 | 1000 | 0 | 1000 |
	+-----+-------------+-------------+--------+---------+------------+
	| #2 | 2001:db8::1 | 2001:db8::2 | 1000 | 1 | 1001 |
	+-----+-------------+-------------+--------+---------+------------+
	| #3 | 2001:db8::1 | 2001:db8::4 | 4500 | 2 | 4502 |
	+-----+-------------+-------------+--------+---------+------------+
	| #4 | 2001:db8::1 | 2001:db8::4 | 4500 | 3 | 4503 |
	+-----+-------------+-------------+--------+---------+------------+
	| #5 | 2001:db8::1 | 2001:db8::2 | 1000 | 4 | 1004 |
	+-----+-------------+-------------+--------+---------+------------+
	Table 1: Sample output of the simple-hash algorithm		3.2. Alternative Algorithm
	This scheme can be further improved by separating the increment		Implemenatations concerned with the Flow Label reuse frequency of the
	spaces, such that the selection of a Flow Label within one space does		algorithm specified in Section 3.1 MAY use the following alternative
	not necessarily cause a Flow Label value to be skipped in the other		scheme, which aims at minimizing the Flow Label reuse frequency by
	spaces. To perform a separation of the increment spaces, the global		producing per-destination monotonically-increasing Flow Label values.
	counter would be replaced with an array of counters as follows:
	Flow Label = table[G(Source Address, Destination Address, Secret Key1)] +		Flow Label = F(Source Address, Destination Address, Secret Key2) +
	F(Source Address, Destination Address, Secret Key2)		table[G(Source Address, Destination Address, Secret Key1)]
	where:		where:
	table:		table:
	Is an array of counters that are initialized to some arbitrary		Is an array of counters that are initialized to random values upon
	value. The larger the array, the greater the obfuscation.		system bottstrap. The larger the array, the greater the
			separation of the "increments" space.
	F():		F():
	Is a hash function that should take as input both the Source		Is a hash function that should take as input both the Source
	Address and the Destination Address, and a secret key. The result		Address and the Destination Address of the flow, and a secret key.
	of F should not be computable without knowledge of all the		The result of F() should not be computable without knowledge of
	parameters of the hash function.		all the parameters of the hash function.
			If random numbers are used as the only source of the secret
			key, they should be chosen in accordance with the
			recommendations given in [RFC4086].
	G():		G():
	Is a hash function that should take as input both the Source		Is a hash function that should take as input both the Source
	Address and the Destination Address, and a secret key. The result		Address and the Destination Address of the flow, and a secret key.
	of F should not be computable without knowledge of all the		The result of G() should not be computable without knowledge of
	parameters of the hash function.		all the parameters of the hash function.
	As with the previous algorithm, this scheme should be invoked when a		If random numbers are used as the only source of the secret
	new flow is to be created (e.g., when a new TCP connection is to be		key, they should be chosen in accordance with the
	created). Once a Flow Label value for such flow is selected, the		recommendations given in [RFC4086].
	Flow Label field of all the IPv6 packets corresponding to that flow
	would be set to the selected value (until the flow is terminated).		This scheme should be invoked when a new flow is to be created (e.g.,
			when a new TCP connection is to be created). Once a Flow Label value
			for such flow is selected, the Flow Label field of all the IPv6
			packets corresponding to that flow would be set to the selected value
			(until the flow is terminated).
	The following figure illustrates this algorithm in pseudo-code:		The following figure illustrates this algorithm in pseudo-code:
	/* Initialization at system boot time */		/* Initialization at system boot time */
	for(i = 0; i < TABLE_LENGTH; i++)		for(i = 0; i < TABLE_LENGTH; i++)
	table[i] = random();		table[i] = random();
	/* Flow Label selection function */		/* Flow Label selection function */
	offset = F(local_IP, remote_IP, secret_key1);		offset = F(local_IP, remote_IP, secret_key1);
	index = G(local_IP, remote_IP, secret_key2);		index = G(local_IP, remote_IP, secret_key2);
	skipping to change at page 10, line 38 ¶		skipping to change at page 9, line 30 ¶
	count--;		count--;
	} while (count > 0);		} while (count > 0);
	/* Set the Flow Label to 0 if there is no		/* Set the Flow Label to 0 if there is no
	unused Flow Label */		unused Flow Label */
	return 0;		return 0;
	Figure 2		Figure 1
	This scheme does not strictly comply with the requirement that a Flow
	Label value must not be reassigned assigned to new flows with the
	same address pair within 120 seconds of the termination of the
	previous flow. However, by minimizing the Flow Label reuse
	frequency, it is expected that in virtually all real network
	scenarios such a requirement will be met.
	The following table shows a sample output of this algorithm:		The following table shows a sample output of this algorithm:
	+-----+-------------+-------------+------+----+------+------------+		+-----+-------------+-------------+------+----+------+------------+
	| Nr. | Src. Addr. | Dst. Addr. | off. | i | t[i] | Flow Label |		| Nr. | Src. Addr. | Dst. Addr. | off. | i | t[i] | Flow Label |
	+-----+-------------+-------------+------+----+------+------------+		+-----+-------------+-------------+------+----+------+------------+
	| #1 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 5 | 1005 |		| #1 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 5 | 1005 |
	+-----+-------------+-------------+------+----+------+------------+		+-----+-------------+-------------+------+----+------+------------+
	| #2 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 6 | 1006 |		| #2 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 6 | 1006 |
	+-----+-------------+-------------+------+----+------+------------+		+-----+-------------+-------------+------+----+------+------------+
	| #3 | 2001:db8::1 | 2001:db8::4 | 4500 | 15 | 10 | 4510 |		| #3 | 2001:db8::1 | 2001:db8::4 | 4500 | 15 | 10 | 4510 |
	+-----+-------------+-------------+------+----+------+------------+		+-----+-------------+-------------+------+----+------+------------+
	| #4 | 2001:db8::1 | 2001:db8::4 | 4500 | 15 | 11 | 4511 |		| #4 | 2001:db8::1 | 2001:db8::4 | 4500 | 15 | 11 | 4511 |
	+-----+-------------+-------------+------+----+------+------------+		+-----+-------------+-------------+------+----+------+------------+
	| #5 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 7 | 1007 |		| #5 | 2001:db8::1 | 2001:db8::2 | 1000 | 10 | 7 | 1007 |
	+-----+-------------+-------------+------+----+------+------------+		+-----+-------------+-------------+------+----+------+------------+
	Table 2: Sample output of the double-hash algorithm		Table 1: Sample output of the double-hash algorithm
	We recommend the implementation of this algorithm for the selection
	of the Flow Label.
	4. Secret-key considerations		3.2.1. Secret-key considerations
	Every complex manipulation (like MD5) is no more secure than the		Every complex manipulation (like MD5) is no more secure than the
	input values, and in the case of ephemeral ports, the secret key. If		input values, and in the case of ephemeral ports, the secret key. If
	an attacker is aware of which cryptographic hash function is being		an attacker is aware of which cryptographic hash function is being
	used by the victim (which we should expect), and the attacker can		used by the victim (which we should expect), and the attacker can
	obtain enough material (e.g. Flow Label values selected by the		obtain enough material (e.g. Flow Label values selected by the
	victim), the attacker may simply search the entire secret key space		victim), the attacker may simply search the entire secret key space
	to find matches.		to find matches.
	To protect against this, the secret key should be of a reasonable		To protect against this, the secret key should be of a reasonable
	skipping to change at page 13, line 5 ¶		skipping to change at page 11, line 5 ¶
	o Some predefined/random time has expired.		o Some predefined/random time has expired.
	o The secret has been used N times (i.e. we consider it insecure).		o The secret has been used N times (i.e. we consider it insecure).
	o There is little traffic (the performance overhead of collisions is		o There is little traffic (the performance overhead of collisions is
	tolerated).		tolerated).
	o There is enough random data available to change the secret key		o There is enough random data available to change the secret key
	(pseudo-random changes should not be done).		(pseudo-random changes should not be done).
	5. Security Considerations		4. Security Considerations
	This document provides a security assessment of the IPv6 Flow Label		This document provides a security assessment of the IPv6 Flow Label
	header field, and possible strategies to mitigate them.		header field, and possible strategies to mitigate them.
	Additionally, it proposes an algorithm for selecting the Flow Label
	values at hosts that complies with the current specification of the
	the Flow Label field
	If the local offset function F() results in identical offsets for		5. IANA Considerations
	different inputs at greater frequency than would be expected by
	chance, the port-offset mechanism proposed in this document would
	have a reduced effect.
	If random numbers are used as the only source of the secret key, they
	should be chosen in accordance with the recommendations given in
	[RFC4086].
	6. IANA Considerations
	There are no IANA registries within this document. The RFC-Editor		There are no IANA registries within this document. The RFC-Editor
	can remove this section before publication of this document as an		can remove this section before publication of this document as an
	RFC.		RFC.
	7. Acknowledgements		6. Acknowledgements
	The author would like to thank (in alphabetical order) Shane Amante,		The author would like to thank (in alphabetical order) Shane Amante,
	Ran Atkinson, Steven Blake, and Brian Carpenter for providing		Ran Atkinson, Steven Blake, and Brian Carpenter for providing
	valuable feedback on earlier versions of this document.		valuable feedback on earlier versions of this document.
	The offset function used in this document was inspired by the		The offset function used by the algorithm in Section 3.1 was inspired
	mechanism proposed by Steven Bellovin in [RFC1948] for defending		by the mechanism proposed by Steven Bellovin in [RFC1948] for
	against TCP sequence number attacks.		defending against TCP sequence number attacks.
	This document is heavily based on the document "Security Assessment		This document is heavily based on the document "Security Assessment
	of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] written by		of the Internet Protocol version 6 (IPv6)" [CPNI-IPv6] written by
	Fernando Gont on behalf of the UK Centre for the Protection of		Fernando Gont on behalf of the UK Centre for the Protection of
	National Infrastructure (CPNI).		National Infrastructure (CPNI).
	Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for		Fernando Gont would like to thank CPNI (http://www.cpni.gov.uk) for
	their continued support.		their continued support.
	8. References		7. References
	8.1. Normative References		7.1. Normative References
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	(IPv6) Specification", RFC 2460, December 1998.		(IPv6) Specification", RFC 2460, December 1998.
	[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.
	[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,		[RFC3697] Rajahalme, J., Conta, A., Carpenter, B., and S. Deering,
	"IPv6 Flow Label Specification", RFC 3697, March 2004.		"IPv6 Flow Label Specification", RFC 3697, March 2004.
	skipping to change at page 16, line 31 ¶		skipping to change at page 14, line 31 ¶
	[RFC4301] Kent, S. and K. Seo, "Security Architecture for the		[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
	Internet Protocol", RFC 4301, December 2005.		Internet Protocol", RFC 4301, December 2005.
	[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,		[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
	"IPv6 Flow Label Specification", RFC 6437, November 2011.		"IPv6 Flow Label Specification", RFC 6437, November 2011.
	[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label		[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label
	for Equal Cost Multipath Routing and Link Aggregation in		for Equal Cost Multipath Routing and Link Aggregation in
	Tunnels", RFC 6438, November 2011.		Tunnels", RFC 6438, November 2011.
	8.2. Informative References		7.2. Informative References
	[FreeBSD] The FreeBSD Project, "http://www.freebsd.org".		[FreeBSD] The FreeBSD Project, "http://www.freebsd.org".
	[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",		[RFC1948] Bellovin, S., "Defending Against Sequence Number Attacks",
	RFC 1948, May 1996.		RFC 1948, May 1996.
	[I-D.blake-ipv6-flow-label-nonce]		[I-D.blake-ipv6-flow-label-nonce]
	Blake, S., "Use of the IPv6 Flow Label as a Transport-		Blake, S., "Use of the IPv6 Flow Label as a Transport-
	Layer Nonce to Defend Against Off-Path Spoofing Attacks",		Layer Nonce to Defend Against Off-Path Spoofing Attacks",
	draft-blake-ipv6-flow-label-nonce-02 (work in progress),		draft-blake-ipv6-flow-label-nonce-02 (work in progress),
	skipping to change at page 19, line 9 ¶		skipping to change at page 17, line 9 ¶
	?		?
	A.5. OpenSolaris		A.5. OpenSolaris
	?		?
	Appendix B. Changes from previous versions of the draft (to be removed		Appendix B. Changes from previous versions of the draft (to be removed
	by the RFC Editor before publication of this document as a		by the RFC Editor before publication of this document as a
	RFC		RFC
	B.1. Changes from draft-gont-6man-flowlabel-security-01		B.1. Changes from draft-gont-6man-flowlabel-security-02
			o The document now recommends randomized Flow Labels as the default
			approach, and describes the hash-based approach as an alternative
			method to be used if there are concerns about the Flow Label reuse
			frequency.
			o Minor editorial changes.
			B.2. Changes from draft-gont-6man-flowlabel-security-01
	o The document has been updated to contain an analysis of the		o The document has been updated to contain an analysis of the
	revised Flow Label specification [RFC6437].		revised Flow Label specification [RFC6437].
	o Minor editorial changes.		o Minor editorial changes.
	B.2. Changes from draft-gont-6man-flowlabel-security-00		B.3. Changes from draft-gont-6man-flowlabel-security-00
	o Clarified *when* Flow Labels are selected, in response to Shane		o Clarified *when* Flow Labels are selected, in response to Shane
	Amante's feedback.		Amante's feedback.
	Author's Address		Author's Address
	Fernando Gont		Fernando Gont
	UK Centre for the Protection of National Infrastructure		UK Centre for the Protection of National Infrastructure
	Email: fernando@gont.com.ar		Email: fernando@gont.com.ar
End of changes. 33 change blocks.
	177 lines changed or deleted		99 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/