draft-ietf-v6ops-ra-guard-03.txt		draft-ietf-v6ops-ra-guard-04.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: November 29, 2009 Cisco Systems		Expires: June 1, 2010 Cisco Systems
	J. Mohacsi		J. Mohacsi
	NIIF/Hungarnet		NIIF/Hungarnet
	May 28, 2009		November 28, 2009
	IPv6 RA-Guard		IPv6 RA-Guard
	<draft-ietf-v6ops-ra-guard-03.txt>		<draft-ietf-v6ops-ra-guard-04.txt>
			Abstract
			It is particularly easy to experience "rogue" routers on an unsecured
			link [reference4]. Devices acting as a rougue router may send
			illegitimate RAs. Section 6 of SeND [RFC3971] provides a full
			solution to this problem, by enabling routers certification. This
			solution does, however, require all nodes on an L2 network segment to
			support SeND, as well as it carries some deployment challenges. End-
			nodes must be provisioned with certificate anchors. The solution
			works better when end-nodes have access to a Certificate Revocation
			List server, and to a Network Time Protocol server, both typically
			off-link, which brings some bootstrap issues.
			When using IPv6 within a single L2 network segment it is possible and
			sometimes desirable to enable layer 2 devices to drop rogue RAs
			before they reach end-nodes. In order to distinguish valid from
			rogue RAs, the L2 devices can use a spectrum of criterias, from a
			static scheme that blocks RAs received on un-trusted ports, or from
			un-trusted sources, to a more dynamic scheme that uses SeND to
			challenge RA sources.
			This document reviews various techniques applicable on the L2 devices
			to reduce the threat of rogue RAs.
	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.
	from IETF Documents or IETF Contributions published or made publicly
	available before November 10, 2008. The person(s) controlling the
	copyright in some of this material may not have granted the IETF
	Trust the right to allow modifications of such material outside the
	IETF Standards Process. Without obtaining an adequate license from
	the person(s) controlling the copyright in such materials, this
	document may not be modified outside the IETF Standards Process, and
	derivative works of it may not be created outside the IETF Standards
	Process, except to format it for publication as an RFC or to
	translate it into languages other than English.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	other groups may also distribute working documents as Internet-		other groups may also distribute working documents as Internet-
	Drafts.		Drafts.
	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."
	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 November 29, 2009.		This Internet-Draft will expire on June 1, 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
	publication of this document (http://trustee.ietf.org/license-info).		(http://trustee.ietf.org/license-info) in effect on the date of
	Please review these documents carefully, as they describe your rights		publication of this document. Please review these documents
	and restrictions with respect to this document.		carefully, as they describe your rights and restrictions with respect
			to this document. Code Components extracted from this document must
	Abstract		include Simplified BSD License text as described in Section 4.e of
			the Trust Legal Provisions and are provided without warranty as
	It is particularly easy to experience "rogue" routers on an unsecured		described in the BSD License.
	link [reference4]. Devices acting as a rougue router may send
	illegitimate RAs. Section 6 of SeND [RFC3971] provides a full
	solution to this problem, by enabling routers certification. This
	solution does, however, require all nodes on an L2 network segment to
	support SeND, as well as it carries some deployment challenges. End-
	nodes must be provisioned with certificate anchors. The solution
	works better when end-nodes have access to a Certificate Revocation
	List server, and to a Network Time Protocol server, both typically
	off-link, which brings some bootstrap issues.
	When using IPv6 within a single L2 network segment it is possible and
	sometimes desirable to enable layer 2 devices to drop rogue RAs
	before they reach end-nodes. In order to distinguish valid from
	rogue RAs, the L2 devices can use a spectrum of criterias, from a
	static scheme that blocks RAs received on un-trusted ports, or from
	un-trusted sources, to a more dynamic scheme that uses SeND to
	challenge RA sources.
	This document reviews various techniques applicable on the L2 devices		This document may contain material from IETF Documents or IETF
	to reduce the threat of rogue RAs.		Contributions published or made publicly available before November
			10, 2008. The person(s) controlling the copyright in some of this
			material may not have granted the IETF Trust the right to allow
			modifications of such material outside the IETF Standards Process.
			Without obtaining an adequate license from the person(s) controlling
			the copyright in such materials, this document may not be modified
			outside the IETF Standards Process, and derivative works of it may
			not be created outside the IETF Standards Process, except to format
			it for publication as an RFC or to translate it into languages other
			than English.
	Table of Contents		Table of Contents
	1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4		1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
	2. Model and Applicability . . . . . . . . . . . . . . . . . . . . 4		2. Model and Applicability . . . . . . . . . . . . . . . . . . . . 4
	3. Stateless RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6		3. Stateless RA-Guard . . . . . . . . . . . . . . . . . . . . . . 6
	4. Stateful RA-Guard . . . . . . . . . . . . . . . . . . . . . . . 6		4. Stateful RA-Guard . . . . . . . . . . . . . . . . . . . . . . . 6
	4.1. State Machine . . . . . . . . . . . . . . . . . . . . . . . 6		4.1. State Machine . . . . . . . . . . . . . . . . . . . . . . . 6
	4.2. SeND-based RA-Guard . . . . . . . . . . . . . . . . . . . . 7		4.2. SeND-based RA-Guard . . . . . . . . . . . . . . . . . . . . 7
	5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . . 8		5. RA-Guard Use Considerations . . . . . . . . . . . . . . . . . . 8
End of changes. 7 change blocks.
	42 lines changed or deleted		48 lines changed or added
This html diff was produced by rfcdiff 1.37a. The latest version is available from http://tools.ietf.org/tools/rfcdiff/