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

From: [email-masked]
Date: Thu, 08 Mar 2012 11:57:59 -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-02.txt
	Pages           : 18
	Date            : 2012-03-08

   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 provides advice on the
   implementation of RA-Guard, such that the RA-Guard evasion vectors
   are eliminated.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation-02.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-v6ops-ra-guard-implementation-02.txt

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 29 Mar 2012 14:45:57 +0000 (UTC)

> 	Filename        : draft-ietf-v6ops-ra-guard-implementation-02.txt

What I was trying to say at the mic is that there is no reason to drop the
packet even if I fail on 3.1 of this draft if I can still make sure that it
cannot be an RA. For example the paket could be failing 4861 6.1.2.
rule number 1 if the source of the packet is non link-local.

However the dratf does not have that restriction.  I don't want a
switch vendor to drop my valid packets if the feature is on, simply
because they applied the draft w/o further thinking and not seeing the
entire big picture and other constraints that must apply.

/bz

PS: this is not the only further restriction that must apply.  It
could be worded genrally upfront in which cases these rules will
apply.

-- 
Bjoern A. Zeeb                                 You have to have visions!
          Stop bit received. Insert coin for new address family.

---

From: Fernando Gont <[email-masked]>
Date: Thu, 29 Mar 2012 19:35:19 +0200

Hi, Bjoern,

> rule number 1 if the source of the packet is non link-local.

Rule 3.1 is to prevent an attacker from performing a DoS against the
RA-Guard device.

That is, if an attacker includes, say, 200 extension headers, we don't
want the RA-Guard device to jump through all of them.

Note that an implementation could enforce a limit of e.g. 10, allowing a
single packet to contain more than one copy of each of all the possible
extension headers.

If your traffic has the minimum level of sanity, it will pass rule 3.1.
Then rule 3.3 will check the Source Address and Hop Limit to avoid false
positives.

> could be worded genrally upfront in which cases these rules will

Please let me know if my comment above answers your concerns.

That aside, I'm wondering if we should include another rule to have the
RA-Guard box policy the Neighbor Advertisements that could otherwise
perform a Neighbor Cache poisoning attack for the router's IPv6 address.
After all, if we don't policy such packets an attacker might still be
able to redirect to itself traffic meant for the first-hop router.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: "Bjoern A. Zeeb" <[email-masked]>
Date: Thu, 29 Mar 2012 22:18:42 +0000 (UTC)

> single packet to contain more than one copy of each of all the possible

You are still going be the assumption of what sensible thing you might
find there today but not tomorrow.  IfJohn Doe comes up with a great
idea that will require him to do a 10k extension header on a 9k MTU,
he'll have to wait 5++++ years to get the entire switch world fixed
and given some comments from data center folks - replacing all your
switches is something they didn't even decide to do for the v6 rollout
but rather disable a feature.   Stop thinking to only address
yesterday's problems - think 20 years ahead.  Avoid posisble problems
where you can upfront.

And I am also startignt o wonder how big a 3971 packet could possibly
be and if that would ever work... Not sure I'd want to drop those at
all for RAs?

> Then rule 3.3 will check the Source Address and Hop Limit to avoid false

If I am performning the checkes from 1 to 3 I'll never make 3 if I'll
have more than 1 * mtu IPv6 header + extension headers before the ULP
as 3.1 clearly states that I shall drop the packet.

So maybe you'll also have to be more precise how the evaluation of
these rules should happen.

> perform a Neighbor Cache poisoning attack for the router's IPv6 address.

Please don't mix things up.

---

From: Fernando Gont <[email-masked]>
Date: Fri, 30 Mar 2012 13:10:20 +0200

> idea that will require him to do a 10k extension header on a 9k MTU,

If John Doe comes with such idea, he won't be able to deploy it on the
public Internet, since deployed stateless IPv6 firewalls will block such
packets.

One would also wonder whether John might re-think his idea, since it's
usually the payload that is meant to be much larger than the headers,
and not the other way around.

> be and if that would ever work... Not sure I'd want to drop those at

No need to wonder: See Appendix C of RFC 3971.

And I don't think you want to rely on fragmentation for SEND: if you do,
an attacker could employ any fragmentation-based attack to disable SEND.

> as 3.1 clearly states that I shall drop the packet.

Exactly. There's not way to do stateless packet filtering without
policing such rather insane packets.

> these rules should happen.

Note sure what you mean.

Thanks,