draft-ietf-v6ops-ra-guard-05.txt		draft-ietf-v6ops-ra-guard-06.txt
	v6ops Working Group E. Levy-Abegnoli		v6ops Working Group E. Levy-Abegnoli
	Internet-Draft G. Van de Velde		Internet-Draft G. Van de Velde
	Intended status: Informational C. Popoviciu		Intended status: Informational C. Popoviciu
	Expires: December 2, 2010 Cisco Systems		Expires: December 19, 2010 Cisco Systems
	J. Mohacsi		J. Mohacsi
	NIIF/Hungarnet		NIIF/Hungarnet
	May 31, 2010		June 17, 2010
	IPv6 RA-Guard		IPv6 RA-Guard
	<draft-ietf-v6ops-ra-guard-05.txt>		<draft-ietf-v6ops-ra-guard-06.txt>
	Abstract		Abstract
	It is particularly easy to experience "rogue" routers on an unsecured		It is particularly easy to experience "rogue" routers on an unsecured
	link [reference4]. Devices acting as a rougue router may send		link [reference4]. Devices acting as a rogue router may send
	illegitimate RAs. Section 6 of SeND [RFC3971] provides a full		illegitimate RAs. Section 6 of SeND [RFC3971] provides a full
	solution to this problem, by enabling routers certification. This		solution to this problem, by enabling routers certification. This
	solution does, however, require all nodes on an L2 network segment to		solution does, however, require all nodes on an L2 network segment to
	support SeND, as well as it carries some deployment challenges. End-		support SeND, as well as it carries some deployment challenges. End-
	nodes must be provisioned with certificate anchors. The solution		nodes must be provisioned with certificate anchors. The solution
	works better when end-nodes have access to a Certificate Revocation		works better when end-nodes have access to a Certificate Revocation
	List server, and to a Network Time Protocol server, both typically		List server, and to a Network Time Protocol server, both typically
	off-link, which brings some bootstrap issues.		off-link, which brings some bootstrap issues.
	When using IPv6 within a single L2 network segment it is possible and		When using IPv6 within a single L2 network segment it is possible and
	sometimes desirable to enable layer 2 devices to drop rogue RAs		sometimes desirable to enable layer 2 devices to drop rogue RAs
	before they reach end-nodes. In order to distinguish valid from		before they reach end-nodes. In order to distinguish valid from
	rogue RAs, the L2 devices can use a spectrum of criterias, from a		rogue RAs, the L2 devices can use a spectrum of criteria, from a
	static scheme that blocks RAs received on un-trusted ports, or from		static scheme that blocks RAs received on un-trusted ports, or from
	un-trusted sources, to a more dynamic scheme that uses SeND to		un-trusted sources, to a more dynamic scheme that uses SeND to
	challenge RA sources.		challenge RA sources.
	This document reviews various techniques applicable on the L2 devices		This document reviews various techniques applicable on the L2 devices
	to reduce the threat of rogue RAs.		to reduce the threat of rogue RAs.
	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 2, line 7		skipping to change at page 2, line 7
	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 December 2, 2010.		This Internet-Draft will expire on December 19, 2010.
	Copyright Notice		Copyright Notice
	Copyright (c) 2010 IETF Trust and the persons identified as the		Copyright (c) 2010 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 5, line 35		skipping to change at page 5, line 35
	supported by all devices involved. It may take time until SeND is		supported by all devices involved. It may take time until SeND is
	ubiquitous in IPv6 networks and some of its large scale deployment		ubiquitous in IPv6 networks and some of its large scale deployment
	aspects are sorted out such as provisioning hosts with trust anchors.		aspects are sorted out such as provisioning hosts with trust anchors.
	It is also reasonable to expect that some devices might not consider		It is also reasonable to expect that some devices might not consider
	implementing SeND at all such as IPv6 enabled sensors. An RA-Guard		implementing SeND at all such as IPv6 enabled sensors. An RA-Guard
	implementation which SeND-validates RAs on behalf of hosts would		implementation which SeND-validates RAs on behalf of hosts would
	potentially simplify some of these challenges.		potentially simplify some of these challenges.
	RA-Guard can be seen as a superset of SEND with regard to router		RA-Guard can be seen as a superset of SEND with regard to router
	authorization. Its purpose is to filter Router Advertisements based		authorization. Its purpose is to filter Router Advertisements based
	on a set of criterias, from a simplistic "RA disallowed on a given		on a set of criteria, from a simplistic "RA disallowed on a given
	interface" to "RA allowed from pre-defined sources" and up to full		interface" to "RA allowed from pre-defined sources" and up to full
	fladge SeND "RA allowed from authorized sources only".		fledge SeND "RA allowed from authorized sources only".
	In addition to this granularity on the criteria for filtering out		In addition to this granularity on the criteria for filtering out
	Router Advertisements, RA-Guard introduces the concept of router		Router Advertisements, RA-Guard introduces the concept of router
	authorization proxy. Instead of each node on the link analyzing RAs		authorization proxy. Instead of each node on the link analyzing RAs
	and making an individual decision, a legitimate node-in-the-middle		and making an individual decision, a legitimate node-in-the-middle
	performs the analysis on behalf of all other nodes on the link. The		performs the analysis on behalf of all other nodes on the link. The
	analysis itself is not different from what each node would do: if		analysis itself is not different from what each node would do: if
	SeND is enabled, the RA is checked against X.509 certificates. If		SeND is enabled, the RA is checked against X.509 certificates. If
	any other criteria is in use, such as known L3 (addresses) or L2		any other criteria is in use, such as known L3 (addresses) or L2
	(link-layer address, port number) legitimate sources of RAs, the		(link-layer address, port number) legitimate sources of RAs, the
	skipping to change at page 8, line 36		skipping to change at page 8, line 36
	RA-Guard mechanisms do not offer protection in environments where		RA-Guard mechanisms do not offer protection in environments where
	IPv6 traffic is tunneled.		IPv6 traffic is tunneled.
	6. IANA Considerations		6. IANA Considerations
	There are no extra IANA consideration for this document.		There are no extra IANA consideration for this document.
	7. Security Considerations		7. Security Considerations
	Once RA-Guard has setup the proper criterias, for example, it		Once RA-Guard has setup the proper criteria, for example, it
	identified that a port is allowed to receive RAs, or it identified		identified that a port is allowed to receive RAs, or it identified
	legitimiate sources of RA, or certificate base, then there is no		legitimate sources of RA, or certificate base, then there is no
	possible instances of accidently filtered legitimate RA's assuming		possible instances of accidentlly filtered legitimate RA's assuming
	the RA-Guard filter enforcement follows strictly the RA-Guard		the RA-Guard filter enforcement follows strictly the RA-Guard
	criteria's.		criteria's.
	8. Acknowledgements		8. Acknowledgements
	The authors dedicate this document to the memory of Jun-ichiro Hagino		The authors dedicate this document to the memory of Jun-ichiro Hagino
	(itojun) for his contributions to the development and deployment of		(itojun) for his contributions to the development and deployment of
	IPv6.		IPv6.
	9. References		9. References
	9.1. Normative References		9.1. Normative References
	[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure		[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
	"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
	September 2007.
	9.2. Informative References		9.2. Informative References
	[reference1]		[reference1]
	LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol		LORIA/INRIA, "NDPMon - IPv6 Neighbor Discovery Protocol
	Monitor (http://ndpmon.sourceforge.net/)", November 2007.		Monitor (http://ndpmon.sourceforge.net/)", November 2007.
	[reference2]		[reference2]
	KAME Project, "rafixd - developed at KAME - An active		KAME Project, "rafixd - developed at KAME - An active
	rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/		rogue RA nullifier (http://www.kame.net/dev/cvsweb2.cgi/
	kame/kame/kame/rafixd/)", November 2007.		kame/kame/kame/rafixd/)", November 2007.
End of changes. 11 change blocks.
	15 lines changed or deleted		11 lines changed or added
This html diff was produced by rfcdiff 1.38. The latest version is available from http://tools.ietf.org/tools/rfcdiff/