Subject: [v6ops] Presentation about ra-guard evasion (draft-gont-v6ops-ra-guard-evasion)

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Jul 2011 17:40:37 -0300

Folks,

A few minutes ago it was asked in the v6ops meeting whether adopting
draft-gont-v6ops-ra-guard-evasion would step over 6man's work.

I'd note that ra-gurd itself was produced by v6ops, and *not* 6man, and
that is why I think this document should be pursued in this working
group -- i.e., I see no reason for which an update to a document
produced here (RFC6105) should be produced elsewhere.

That aside, the filtering checks that are proposed in the aforementioned
document are an operational mitigation to the described issues.

Thanks,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Thu, 28 Jul 2011 23:06:26 +0200

Hi Fernando,

[Speaking as one of the co-authors of RA-Guard]

The 'informational' RA-Guard paper was created on v6OPS because it
describes a 
method to mainly avoid misconfiguration. It is something that protects
the access 
layer better as nothing. For the most part it is a poor man solution and
not at all a full flavor security solution.
That is acknowledged in the RFC6105 in the abstract:

"

   Routed protocols are often susceptible to spoof attacks.  The
   canonical solution for IPv6 is Secure Neighbor Discovery (SEND), a
   solution that is non-trivial to deploy.  This document proposes a
   light-weight alternative and complement to SEND based on filtering in
   the layer-2 network fabric, using a variety of filtering criteria,
   including, for example, SEND status.
"

And more references to this are made later in the paper.

IMHO the full solution for rogue RA's is SEND ... and not an even more
complex form of RA-Guard and make it less Lite.
Some of the elements documented are also valid for existing IPv4 and
IPv6 Access-lists and other xxx-Guard 
mechanisms. 

In 6man meeting there were some serious flaws discussed in the proposed
solutions as they break IPv6 technology 
elements. (i.e. dropping RA packets with fragments, could break SEND
where the certificate is larger as the 
link MTU... there were more and I guess those can be found in the
minutes soon).

So looking at the fact RA-Guard is a lightweight protocol, and the
evasion techniques discussed are quite 
known as traditional mechanisms to also bypass most traditional
access-lists, I think that changing any 
protocol aspects does not make much sense...

G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Fernando Gont
Sent: 28 July 2011 16:41
To: IPv6 Operations
Cc: V6ops Chairs
Subject: [v6ops] Presentation about ra-guard
evasion(draft-gont-v6ops-ra-guard-evasion)

Folks,

Thanks,

_______________________________________________
v6ops mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/v6ops

---

From: Fernando Gont <[email-masked]>
Date: Thu, 28 Jul 2011 18:54:11 -0300

Hi, Gunter,

On 07/28/2011 06:06 PM, Gunter Van de Velde (gvandeve) wrote:
> describes a method to mainly avoid misconfiguration. 

While RFC6104 (problem statement for rogue RAs) focuses on RAs resulting
from misconfiguration, RFC6105 seems to focus on malicious RAs.

> complex form of RA-Guard and make it less Lite.

... if only SEND was easily deployable.

That aside, RA-Guard parallels existing functionality in IPv4 (DHCP
snooping) -- hence that's, IMHO, enough of a motivation for it to be
made "good enough" so that people that currently dhcp snooping in v4
have an equivalent mechanism in IPv6.

> link MTU... there were more and I guess those can be found in the

If you deploy and enable send, you can enable fragmentation with the
same knob.

That aside, draft-gont-v6ops-ra-guard-evasion does not disable
fragmentation. It just drops fragmented traffic where the first fragment
does not contain the upper layer protocol header -- which would only
happen if you had large number of *IPv6* options in extension headers
(dst options, hbh, etc.)

> protocol aspects does not make much sense...

They are quite known for bypassing layer-3/4 filtering (e.g., a typical
firewall). But I don't think they are so "quite known" for bypassing
layer-2 filtering.

For instance, these evasion techniques have no counterpart in the v4
world, since you cannot have an arbitrarily large amount of nonsense
before the upper layer header (ICMPv6 in this case), because of the
upper bound on the IPv4 header.

Posts on some operations lists seem to indicate that evasion of ra-guard
wasn't that obvious to everyone....

Thanks,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 29 Jul 2011 07:29:43 +0200 (CEST)

On Thu, 28 Jul 2011, Gunter Van de Velde (gvandeve) wrote:

> complex form of RA-Guard and make it less Lite. Some of the elements 
> documented are also valid for existing IPv4 and IPv6 Access-lists and 
> other xxx-Guard mechanisms.

Personally I think SEND is too advanced for the general use, or it'll take 
way too long to get widely implemented in a user-friendly way. The 
certificate distribution and handling problem is the killer for me.

> evasion techniques discussed are quite known as traditional mechanisms 
> to also bypass most traditional access-lists, I think that changing any 

I don't agree.

Then again IPv6 was generally designed without L2 security in mind, so 
ISPs might have to go for full L2 separation of hosts anyway. I don't see 
any other short- or medium term solution. SEND in itself doesn't solve it 
from a practical point of view, even though it does from a theoretical 
PoV.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Joel Jaeggli <[email-masked]>
Date: Fri, 29 Jul 2011 09:26:59 -0400

On Jul 29, 2011, at 1:29 AM, Mikael Abrahamsson wrote:

>> IMHO the full solution for rogue RA's is SEND ... and not an even more complex form of RA-Guard and make it less Lite. Some of the elements documented are also valid for existing IPv4 and IPv6 Access-lists and other xxx-Guard mechanisms.
> 
> Personally I think SEND is too advanced for the general use, or it'll take way too long to get widely implemented in a user-friendly way. The certificate distribution and handling problem is the killer for me.
> 
>> So looking at the fact RA-Guard is a lightweight protocol, and the evasion techniques discussed are quite known as traditional mechanisms to also bypass most traditional access-lists, I think that changing any protocol aspects does not make much sense...
> 
> I don't agree.
> 
> Then again IPv6 was generally designed without L2 security in mind, so ISPs might have to go for full L2 separation of hosts anyway. I don't see any other short- or medium term solution. SEND in itself doesn't solve it from a practical point of view, even though it does from a theoretical PoV.

Unsurprisingly the goal of having two to N hosts on a subnet with no security association talk to each other does limit  our options. Full L2 isolation is great if that's what you want, but I want to be able to talk to my printer and my apple tv.

---

From: "Gunter Van de Velde (gvandeve)" <[email-masked]>
Date: Fri, 29 Jul 2011 15:29:10 +0200

Hi Fernando,

After further thinking on this there may be another approach available.
RFC6105 mentions that RA-Guard drops the RA's. The tests you seem to
have done indicate 
that in some corner cases the existing implementations don't drop the
RA. However that 
is an implementation detail on how the vendor decided to put the
mechanism in place to drop the RA's.
(most vendors just use access-lists, and hence to bypass these any ACL
evasion technology could be used)

The RFC6105 does not inform/advice 'HOW' a L2 switch should drop the RA,
it just specifies it should 
be dropped on certain ports/interfaces

What could be done is to create a draft on best practices to drop RA's,
and have that complement RA-Guard.
I think that could work pretty well actually.

G/

-----Original Message-----
From: Fernando Gont [mailto:[email-masked]] On
Behalf Of Fernando Gont
Sent: 28 July 2011 17:54
To: Gunter Van de Velde (gvandeve)
Cc: IPv6 Operations; V6ops Chairs
Subject: Re: [v6ops] Presentation about ra-guard
evasion(draft-gont-v6ops-ra-guard-evasion)

Hi, Gunter,

Thanks,

---

From: Fernando Gont <[email-masked]>
Date: Fri, 29 Jul 2011 11:01:45 -0300

Hi, Gunter,

> RFC6105 mentions that RA-Guard drops the RA's. The tests you seem to
[....]
> I think that could work pretty well actually.

Sorry, what's the difference between what you propose, and
draft-gont-v6ops-ra-guard-evasion?

The only "difference" I see is that I might add two lines to my I-D
noting that this is a common implementation flaw of RA-Guard....

Thoughts?

Thanks,

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 29 Jul 2011 20:05:19 +0200 (CEST)

On Fri, 29 Jul 2011, Joel Jaeggli wrote:

> Unsurprisingly the goal of having two to N hosts on a subnet with no 
> security association talk to each other does limit our options. Full L2 
> isolation is great if that's what you want, but I want to be able to 
> talk to my printer and my apple tv.

Well, I was referring to separation of customers (in this case I guess 
households). Also, I wasn't implying filtering of these devices, they can 
still talk L3 with each other, but it does limit automatic discovery of 
each other.