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/