Subject: [v6ops] I-D Action: draft-ietf-v6ops-ra-guard-implementation-06.txt

From: [email-masked]
Date: Wed, 14 Nov 2012 08:26:30 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title           : Implementation Advice for IPv6 Router Advertisement Guard (RA-Guard)
	Author(s)       : Fernando Gont
	Filename        : draft-ietf-v6ops-ra-guard-implementation-06.txt
	Pages           : 18
	Date            : 2012-11-14

Abstract:
   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 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 formally updates RFC 6105, such
   that the aforementioned RA-Guard evasion vectors are eliminated.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-ra-guard-implementation

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-ra-guard-implementation-06

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-ra-guard-implementation-06

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Philip Matthews <[email-masked]>
Date: Wed, 14 Nov 2012 17:38:39 -0500

Two comments on version -07 of this draft.

The draft says (section 3):
  3.  RA-Guard must parse the IPv6 entire header chain present in the
       packet, to identify whether the packet is a Router Advertisement
       message.

          RATIONALE: [RFC6564] specifies a uniform format for IPv6
          Extension Header, thus meaning that an IPv6 node can parse an
          IPv6 header chain even if it contains Extension Headers that
          are not currently supported by that node.  Additionally,
          [I-D.ietf-6man-oversized-header-chain] requires that if a
          packet is fragmented, the first fragment contains the entire
          IPv6 header chain.

          RA-Guard implementations must not enforce a limit on the
          number of bytes they can inspect (starting from the beginning
          of the IPv6 packet), since this could introduce false-
          positives: legitimate packets could be dropped simply because
          the RA-Guard device does not parse the entire IPv6 header
          chain present in the packet.  An implementation that has such
          an implementation-specific limit must not claim compliance
          with this specification, and must pass the packet when such
          implementation-specific limit is reached.

First (and I apologize if this is a silly question): If an RA-Guard implementation encounters a protocol number that it does not recognize, then how does it know that this number corresponds to an unrecognized extension header (which follows the format of RFC 6564) and not some new layer 4 protocol (which will likely not follow RFC 6564)?  That is, when an RA-Guard implementation encounters a protocol number N which it does not recognize, then how does it select between the following two options:
      a) Protocol number N is a new extension header (which the implementation does not recognize) and it should skip over the header and keep on parsing up the stack,   OR
      b) Protocol number N is a new layer 4 protocol (which the implementation does not recognize) and it should discard the packet.

Second (and we already discussed this in OPSEC, so I am repeating this so the WG can hear it):  I am concerned with the last sentence that says "An implementation that has such an implementation-specific limit ... must pass the packet when such implementation-specific limit is reached."     It seems to me that an operator would strongly prefer the RA-Guard to drop the packet when the limit is reached, rather than forwarding it. 

- Philip