Technical Summary
The IPv6 Router Advertisement Guard (RA-Guard) mechanism is commonly
employed to mitigate attack vectors based on forged ICMPv6 Router
Advertisement messages. Many existing IPv6 deployments rely on RA-
Guard [RFC6105] as the first line of defense against the
aforementioned attack vectors. However, some implementations of
RA-Guard have been found to be prone to circumvention by employing
IPv6 Extension Headers. This document describes the evasion
techniques that affect the aforementioned implementations, and
provides advice on the implementation of RA-Guard, such that the
RA-Guard evasion vectors are eliminated.
Working Group Summary
Initial version of this draft was announced on the v6ops list 1/5/12,a previous related draft draft-gont-v6ops-ra-guard-evasion first discussed 6/1/11 was supplanted by it Some initial discussion on the list and between the authors WG chairs and IESG members asked for guidance on the work being done in V6ops versus the security or internet areas. Probably as a consequence of the original RFC 6105 RA-Guard work was done under the v6ops charter it was concluded that v6ops was an appropriate venue to provide advice to implementers. The document was accepted as working group document on 2/13/12. Working-group last call commenced 04/22/12 and Completed on 5/6/12. 26 messages in favor from 11 participants were recorded with none opposed. The outcome of the WGLC is consistent with the v6ops discussion during IETF 82.
Document Quality
The document has received significant review both within v6ops and elsewhere in the community such as SAAG and 6man.
Personnel
The document shepherd is Joel Jaeggli co-chair of the v6ops working group. The responsible AD is Ron Bonica.
RFC Editor Note
OLD>
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
<OLD
NEW>
<NEW
OLD>
RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies
that the first-fragment (i.e., the fragment with the Fragment
Offset set to 0) MUST contain the entire IPv6 header chain,
and allows intermmediate systems such as routers to drop those
packets that fail to comply with this requirement.
<OLD
NEW>
RATIONALE: [I-D.ietf-6man-oversized-header-chain] specifies
that the first-fragment (i.e., the fragment with the Fragment
Offset set to 0) must contain the entire IPv6 header chain,
and allows intermmediate systems such as routers to drop those
packets that fail to comply with this requirement.
<NEW
OLD>
RATIONALE: By definition, Router Advertisement messages MUST
originate on-link, MUST have a link-local IPv6 Source Address,
and MUST have a Hop Limit value of 255. [RFC4861].
<OLD
NEW>
RATIONALE: By definition, Router Advertisement messages MUST
originate on-link, must have a link-local IPv6 Source Address,
and MUST have a Hop Limit value of 255. [RFC4861].
<NEW
OLD>
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
<OLD
NEW>
<NEW