draft-ietf-v6ops-ra-guard-implementation-06.txt		draft-ietf-v6ops-ra-guard-implementation-07.txt
	IPv6 Operations Working Group (v6ops) F. Gont		IPv6 Operations Working Group (v6ops) F. Gont
	Internet-Draft UK CPNI		Internet-Draft UK CPNI
	Updates: 6105 (if approved) November 14, 2012		Updates: 6105 (if approved) November 14, 2012
	Intended status: Informational		Intended status: Informational
	Expires: May 18, 2013		Expires: May 18, 2013
	Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)		Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
	draft-ietf-v6ops-ra-guard-implementation-06		draft-ietf-v6ops-ra-guard-implementation-07
	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
	skipping to change at page 8, line 8		skipping to change at page 8, line 8
	The second fragment presents the same challenges as the second		The second fragment presents the same challenges as the second
	fragment of the previous variant. That is, it would be impossible		fragment of the previous variant. That is, it would be impossible
	for a device processing only the second fragment to locate the second		for a device processing only the second fragment to locate the second
	Destination Options header (and hence the ICMPv6 header), since the		Destination Options header (and hence the ICMPv6 header), since the
	"Hdr Ext Len" field of the first Destination Options header is		"Hdr Ext Len" field of the first Destination Options header is
	present in the first fragment (rather than the second).		present in the first fragment (rather than the second).
	3. RA-Guard implementation advice		3. RA-Guard implementation advice
	The following filtering rules must be implemented as part of an "RA-		The following filtering rules must be implemented as part of an "RA-
	Guard" implementation on those ports that are not allowed to send		Guard" implementation on ports that face interfaces that are not
	ICMPv6 Router Advertisement messages, such that the vulnerabilities		allowed to send ICMPv6 Router Advertisement messages, such that the
	discussed in this document are eliminated:		vulnerabilities discussed in this document are eliminated:
	1. If the IPv6 Source Address of the packet is not a link-local		1. If the IPv6 Source Address of the packet is not a link-local
	address (fe80::/10), RA-Guard must pass the packet.		address (fe80::/10), RA-Guard must pass the packet.
	RATIONALE: Section 6.1.2 of [RFC4861] requires nodes to		RATIONALE: This prevents "RA-Guard" from dedicating compute
	discard Router Advertisement messages if their IPv6 Source		cycles to filtering packets that originate off-net and, if
	Address is not a link-local address.		they are RA's, would not be accepted by the host. Section
			6.1.2 of [RFC4861] requires nodes to discard Router
			Advertisement messages if their IPv6 Source Address is not a
			link-local address.
	2. If the Hop Limit is not 255, RA-Guard must pass the packet.		2. If the Hop Limit is not 255, RA-Guard must pass the packet.
	RATIONALE: Section 6.1.2 of [RFC4861] requires nodes to		RATIONALE: This prevents "RA-Guard" from dedicating compute
	discard Router Advertisement messages if their Hop Limit is		cycles to filtering packets that originate off-net and, if
	not 255.		they are RA's, would not be accepted by the host. Section
			6.1.2 of [RFC4861] requires nodes to discard Router
			Advertisement messages if their Hop Limit is not 255.
	3. RA-Guard must parse the IPv6 entire header chain present in the		3. RA-Guard must parse the IPv6 entire header chain present in the
	packet, to identify whether the packet is a Router Advertisement		packet, to identify whether the packet is a Router Advertisement
	message.		message.
	RATIONALE: [RFC6564] specifies a uniform format for IPv6		RATIONALE: [RFC6564] specifies a uniform format for IPv6
	Extension Header, thus meaning that an IPv6 node can parse an		Extension Header, thus meaning that an IPv6 node can parse an
	IPv6 header chain even if it contains Extension Headers that		IPv6 header chain even if it contains Extension Headers that
	are not currently supported by that node. Additionally,		are not currently supported by that node. Additionally,
	[I-D.ietf-6man-oversized-header-chain] requires that if a		[I-D.ietf-6man-oversized-header-chain] requires that if a
End of changes. 4 change blocks.
	10 lines changed or deleted		15 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/