draft-ietf-v6ops-ra-guard-implementation-03.txt		draft-ietf-v6ops-ra-guard-implementation-04.txt
	IPv6 Operations Working Group (v6ops) F. Gont		IPv6 Operations Working Group (v6ops) F. Gont
	Internet-Draft UK CPNI		Internet-Draft UK CPNI
	Intended status: BCP May 11, 2012		Updates: 6105 (if approved) May 22, 2012
	Expires: November 12, 2012		Intended status: BCP
			Expires: November 23, 2012
	Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)		Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
	draft-ietf-v6ops-ra-guard-implementation-03		draft-ietf-v6ops-ra-guard-implementation-04
	Abstract		Abstract
	The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly		The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly
	employed to mitigate attack vectors based on forged ICMPv6 Router		employed to mitigate attack vectors based on forged ICMPv6 Router
	Advertisement messages. Many existing IPv6 deployments rely on RA-		Advertisement messages. Many existing IPv6 deployments rely on RA-
	Guard as the first line of defense against the aforementioned attack		Guard as the first line of defense against the aforementioned attack
	vectors. However, some implementations of RA-Guard have been found		vectors. However, some implementations of RA-Guard have been found
	to be prone to circumvention by employing IPv6 Extension Headers.		to be prone to circumvention by employing IPv6 Extension Headers.
	This document describes the evasion techniques that affect the		This document describes the evasion techniques that affect the
	aforementioned implementations, and provides advice on the		aforementioned implementations, and formally updates RFC 6105, such
	implementation of RA-Guard, such that the RA-Guard evasion vectors		that the aforementioned RA-Guard evasion vectors are eliminated.
	are eliminated.
	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
	provisions of BCP 78 and BCP 79.		provisions of BCP 78 and BCP 79.
	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 November 12, 2012.		This Internet-Draft will expire on November 23, 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 19		skipping to change at page 2, line 19
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Evasion techniques for some Router Advertisement Guard (RA		2. Evasion techniques for some Router Advertisement Guard (RA
	Guard) implementations . . . . . . . . . . . . . . . . . . . . 4		Guard) implementations . . . . . . . . . . . . . . . . . . . . 4
	2.1. Attack Vector based on IPv6 Extension Headers . . . . . . 4		2.1. Attack Vector based on IPv6 Extension Headers . . . . . . 4
	2.2. Attack vector based on IPv6 fragmentation . . . . . . . . 4		2.2. Attack vector based on IPv6 fragmentation . . . . . . . . 4
	3. RA-Guard implementation advice . . . . . . . . . . . . . . . . 8		3. RA-Guard implementation advice . . . . . . . . . . . . . . . . 8
	4. Other Implications . . . . . . . . . . . . . . . . . . . . . . 11		4. Other Implications . . . . . . . . . . . . . . . . . . . . . . 11
	5. Security Considerations . . . . . . . . . . . . . . . . . . . 12		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
	6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13		6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
	7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
	7.1. Normative References . . . . . . . . . . . . . . . . . . . 14		8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
	7.2. Informative References . . . . . . . . . . . . . . . . . . 14		8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
	Appendix A. Assessment tools . . . . . . . . . . . . . . . . . . 16		8.2. Informative References . . . . . . . . . . . . . . . . . . 15
	Appendix B. Advice and guidance to vendors . . . . . . . . . . . 17		Appendix A. Assessment tools . . . . . . . . . . . . . . . . . . 17
	Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 18		Appendix B. Advice and guidance to vendors . . . . . . . . . . . 18
			Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 19
	1. Introduction		1. Introduction
	IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique		IPv6 Router Advertisement Guard (RA-Guard) is a mitigation technique
	for attack vectors based on ICMPv6 Router Advertisement messages.		for attack vectors based on ICMPv6 Router Advertisement messages.
	[RFC6104] describes the problem statement of "Rogue IPv6 Router		[RFC6104] describes the problem statement of "Rogue IPv6 Router
	Advertisements", and [RFC6105] specifies the "IPv6 Router		Advertisements", and [RFC6105] specifies the "IPv6 Router
	Advertisement Guard" functionality.		Advertisement Guard" functionality.
	The concept behind RA-Guard is that a layer-2 device filters ICMPv6		The concept behind RA-Guard is that a layer-2 device filters ICMPv6
	skipping to change at page 12, line 5		skipping to change at page 11, line 13
	with [RFC5722].		with [RFC5722].
	4. Other Implications		4. Other Implications
	A similar concept to that of "RA-Guard" has been implemented for		A similar concept to that of "RA-Guard" has been implemented for
	protecting against forged DHCPv6 messages. Such protection can be		protecting against forged DHCPv6 messages. Such protection can be
	circumvented with the same techniques discussed in this document, and		circumvented with the same techniques discussed in this document, and
	the counter-measures for such evasion attack are analogous to those		the counter-measures for such evasion attack are analogous to those
	described in Section 3 of this document.		described in Section 3 of this document.
	5. Security Considerations		[DHCPv6-Shield] specifies a mechanism to protect against rogue
			DHCPv6 servers, while taking into consideration the evasion
			techniques discussed in this document.
			5. IANA Considerations
			This document has no actions for IANA.
			6. Security Considerations
	This document describes a number of techniques that have been found		This document describes a number of techniques that have been found
	to be effective to circumvent popular RA-Guard implementations, and		to be effective to circumvent popular RA-Guard implementations, and
	provides advice to RA-Guard implementations such that those evasion		provides advice to RA-Guard implementations such that those evasion
	vulnerabilities are eliminated.		vulnerabilities are eliminated.
	As noted in Section 3, IPv6 implementations that allow overlapping		As noted in Section 3, IPv6 implementations that allow overlapping
	fragments (i.e. that do not comply with [RFC5722]) might still be		fragments (i.e. that do not comply with [RFC5722]) might still be
	subject of RA-based attacks. However, most current		subject of RA-based attacks. However, most current
	implementations seem to comply with [RFC5722].		implementations seem to comply with [RFC5722].
	skipping to change at page 12, line 32		skipping to change at page 13, line 32
	complete datagram. If a large number of such packets were sent by an		complete datagram. If a large number of such packets were sent by an
	attacker, and the victim node failed to implement proper resource		attacker, and the victim node failed to implement proper resource
	management for the fragment reassembly buffer, this could lead to a		management for the fragment reassembly buffer, this could lead to a
	Denial of Service (DoS). However, this does not really introduce a		Denial of Service (DoS). However, this does not really introduce a
	new attack vector, since an attacker could always perform the same		new attack vector, since an attacker could always perform the same
	attack by sending forged fragmented datagram in which at least one of		attack by sending forged fragmented datagram in which at least one of
	the fragments is missing. [CPNI-IPv6] discusses some resource		the fragments is missing. [CPNI-IPv6] discusses some resource
	management strategies that could be implemented for the fragment		management strategies that could be implemented for the fragment
	reassembly buffer.		reassembly buffer.
	Finally, we note that most effective and efficient mitigation for		We note that most effective and efficient mitigation for these
	these attacks would be to prohibit the use of IPv6 fragmentation with		attacks would be to prohibit the use of IPv6 fragmentation with
	Router Advertisement messages (as proposed by		Router Advertisement messages (as proposed by
	[I-D.gont-6man-nd-extension-headers]), such that the RA-Guard		[I-D.gont-6man-nd-extension-headers]), such that the RA-Guard
	functionality is easier to implement. However, since such mitigation		functionality is easier to implement. However, since such mitigation
	would require an update to existing implementations, it cannot be		would require an update to existing implementations, it cannot be
	relied upon in the short or near term.		relied upon in the short or near term.
	6. Acknowledgements		Finally, we note that RA-Guard only mitigates attack vectors based on
			ICMPv6 Router advertisement messages. Protection against similar
			attacks based on other messages (such as DCHPv6) is considered out of
			the scope of this document, and left for other documents(e.g.
			[DHCPv6-Shield]).
			7. Acknowledgements
	The author would like to thank Ran Atkinson, Karl Auer, Robert		The author would like to thank Ran Atkinson, Karl Auer, Robert
	Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray		Downie, Washam Fan, David Farmer, Marc Heuse, Nick Hilliard, Ray
	Hunter, Simon Perreault, Arturo Servin, Gunter van de Velde, James		Hunter, Joel Jaeggli, Simon Perreault, Arturo Servin, Gunter van de
	Woodyatt, and Bjoern A. Zeeb, for providing valuable comments on		Velde, James Woodyatt, and Bjoern A. Zeeb, for providing valuable
	earlier versions of this document.		comments on earlier versions of this document.
	The author would like to thank Arturo Servin, who presented this		The author would like to thank Arturo Servin, who presented this
	document at IETF 81.		document at IETF 81.
	This document resulted from the project "Security Assessment of the		This document resulted from the project "Security Assessment of the
	Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out by		Internet Protocol version 6 (IPv6)" [CPNI-IPv6], carried out 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). The author would like to thank the		National Infrastructure (CPNI). The author would like to thank the
	UK CPNI, for their continued support.		UK CPNI, for their continued support.
	7. References		8. References
	7.1. Normative References		8.1. Normative References
	[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.
	[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",		[RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)",
	RFC 4303, December 2005.		RFC 4303, December 2005.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,		[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,		"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.		September 2007.
	[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",		[RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments",
	RFC 5722, December 2009.		RFC 5722, December 2009.
	[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and		[RFC6564] Krishnan, S., Woodyatt, J., Kline, E., Hoagland, J., and
	M. Bhatia, "A Uniform Format for IPv6 Extension Headers",		M. Bhatia, "A Uniform Format for IPv6 Extension Headers",
	RFC 6564, April 2012.		RFC 6564, April 2012.
	7.2. Informative References		8.2. Informative References
	[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement		[RFC6104] Chown, T. and S. Venaas, "Rogue IPv6 Router Advertisement
	Problem Statement", RFC 6104, February 2011.		Problem Statement", RFC 6104, February 2011.
	[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.		[RFC6105] Levy-Abegnoli, E., Van de Velde, G., Popoviciu, C., and J.
	Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,		Mohacsi, "IPv6 Router Advertisement Guard", RFC 6105,
	February 2011.		February 2011.
	[I-D.gont-6man-oversized-header-chain]		[I-D.gont-6man-oversized-header-chain]
	Gont, F. and V. Manral, "Security and Interoperability		Gont, F. and V. Manral, "Security and Interoperability
	Implications of Oversized IPv6 Header Chains",		Implications of Oversized IPv6 Header Chains",
	draft-gont-6man-oversized-header-chain-01 (work in		draft-gont-6man-oversized-header-chain-01 (work in
	progress), April 2012.		progress), April 2012.
	[I-D.gont-6man-nd-extension-headers]		[I-D.gont-6man-nd-extension-headers]
	Gont, F., "Security Implications of the Use of IPv6		Gont, F., "Security Implications of the Use of IPv6
	Extension Headers with IPv6 Neighbor Discovery",		Extension Headers with IPv6 Neighbor Discovery",
	draft-gont-6man-nd-extension-headers-02 (work in		draft-gont-6man-nd-extension-headers-02 (work in
	progress), January 2012.		progress), January 2012.
			[DHCPv6-Shield]
			Gont, F., "DHCPv6-Shield: Protecting Against Rogue DHCPv6
			Servers", IETF Internet Draft,
			draft-gont-opsec-dhcpv6-shield, work in progress,
			May 2012.
	[CPNI-IPv6]		[CPNI-IPv6]
	Gont, F., "Security Assessment of the Internet Protocol		Gont, F., "Security Assessment of the Internet Protocol
	version 6 (IPv6)", UK Centre for the Protection of		version 6 (IPv6)", UK Centre for the Protection of
	National Infrastructure, (available on request).		National Infrastructure, (available on request).
	[NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor",		[NDPMon] "NDPMon - IPv6 Neighbor Discovery Protocol Monitor",
	<http://ndpmon.sourceforge.net/>.		<http://ndpmon.sourceforge.net/>.
	[rafixd] "rafixd", <http://www.kame.net/dev/cvsweb2.cgi/kame/kame/		[rafixd] "rafixd", <http://www.kame.net/dev/cvsweb2.cgi/kame/kame/
	kame/rafixd/>.		kame/rafixd/>.
End of changes. 13 change blocks.
	25 lines changed or deleted		46 lines changed or added
This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/