Subject: Re: [v6ops] Question regarding RA-Guard evasion (ND and extension headers)

From: Ray Hunter <[email-masked]>
Date: Thu, 23 Jun 2011 08:56:39 +0200

>
> Subject:
> Re: [v6ops] Question regarding RA-Guard evasion (ND and extension 
> headers)
> From:
> Ted Lemon <[email-masked]>
> Date:
> Wed, 22 Jun 2011 20:56:52 -0400
>
> To:
> Mark Smith <[email-masked]>
> CC:
> [email-masked], [email-masked]
>
> Content-Transfer-Encoding:
> quoted-printable
> Precedence:
> list
> MIME-Version:
> 1.0 (Apple Message framework v1242)
> References:
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]> 
> <[email-masked]>
> In-Reply-To:
> <[email-masked]>
> Message-ID:
> <[email-masked]>
> Content-Type:
> text/plain; charset="us-ascii"
> Message:
> 7
>
>
> On Jun 22, 2011, at 8:25 PM, Mark Smith wrote:
>    
>> >  You're right, with Ethernet being the wrong protocol.
>>      
>
> Well, let's be clear here: Ethernet is apparently the wrong protocol*for you*.   You should be running 802.1x, not plain ethernet, because you have specific needs that make plain ethernet an inappropriate choice for you.
>
> But that wasn't what I was talking about.   IPv6 has to work on ethernet.   IPv6 multicast is useful, and we (at least, some of us) want it to work.   The solution to the rogue RA problem is not to get rid of ethernet (or at least, so I claim).   Moreover, even supposing we could get rid of ethernet in the sense that you mean, that would simply paper over the problem, not solve it.   If we want a secure network, we have to use secure protocols.   Firewalls are a great second-level defense (and your hub-and-spoke model is basically a firewall).   But they do not make your network secure: they simply make it harder to attack.
>
> So if in fact it is impossible for RA to be adequately secured on an ethernet, then we need to fix RA, or come up with a different solution, not slap a bandage on it and call it done.
>
>    

Sounds sensible.

Following are IMVVHO "requirements" from an operational perspective.

People have similar "issues" with ARP and DHCP (v4) and IPv4 today. But 
today it is also trivial to filter BOOTP on networks with fixed 
links/ports to make sure the default route and DNS server are set via 
DHCP, and only the designated DHCP server/ DHCP relay can/will reply, 
and that's generally been "good enough". For wireless, people are 
generally employing something else, like 802.1X, anyway.

Sometimes I think we're in danger of making things so complex that the 
simple filters will no longer work (and having to buy a complete new 
generation of Ethernet LAN switches to make RA work does not sound 
operationally attractive)

IMVHO If it was equally trivial as today to be able to completely filter 
the messages that set the default route and the DNS server to certain 
LAN ports or MAC addresses or IP source addresses or well-known port 
numbers, and so be able to fairly reliably set the DNS server and the 
default router on end hosts from a (weakly) trusted source, then the 
"issue" would be "solved" for most users, because that would be no 
different to today.

If people want to buy a new switch to implement RA Guard, then that's 
fine too. But RA Guard should not be a prerequisite for reliably setting 
of a default route on Ethernet, simply because corporate LAN switches 
generally have to last 5-10 years or so before being replaced.

If the trust relationship between an end node and the source that 
provides the configuration information on the default route and DNS 
server could be made even stronger, all the better, but in a World of 
roaming devices and guest users, that is not a trivial nut to crack 
operationally.

regards,
RayH

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 23 Jun 2011 09:03:37 +0200 (CEST)

On Thu, 23 Jun 2011, Ray Hunter wrote:

> too. But RA Guard should not be a prerequisite for reliably setting of a 
> default route on Ethernet, simply because corporate LAN switches generally 
> have to last 5-10 years or so before being replaced.

I don't see 5-10 year old LAN switches having any kind of capability of 
filtering just certain IPv6 packets. They might have the possibility of 
filtering all 0x86dd packet which is the sensible thing to do unless one 
can secure it by other means.

Securing L2 networks is something not generally done today in enterprise 
and surprisingly often in SP environments as well. This can be seen by all 
the problems reported by Windows ICS v6 RA:s being sent out and causing 
problems to other users (which in a properly build network it shouldn't 
have the capability of doing, because those packets should be filtered by 
the access network).

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Tim Chown <[email-masked]>
Date: Thu, 23 Jun 2011 10:37:34 +0100

On 23 Jun 2011, at 08:03, Mikael Abrahamsson wrote:

> Securing L2 networks is something not generally done today in enterprise and surprisingly often in SP environments as well. This can be seen by all the problems reported by Windows ICS v6 RA:s being sent out and causing problems to other users (which in a properly build network it shouldn't have the capability of doing, because those packets should be filtered by the access network).

I think there is some effort to secure layer 2 in academic enterprises, e.g. I did a straw poll at a recent UK event and about 2/3rds of the admins there were using DHCPv4 snooping/filtering on layer 2 devices.  But pretty much none had any filters applied for RAs, even if they could.   This probably explains in part why so many admins are 'comfortable' with the idea of DHCPv6-only operation, in that it's a known risk model.

Some mechanisms also don't help in the way they're deployed.  While academic sites are now heavily into 802.1X for eduroam deployment, pretty much every rogue ICS-a-like RA that's seen is issued by a device that has authenticated using 802.1X, but in almost every case the devices are put into a shared VLAN, not one per user/device.

But ICS-a-like rogue RAs are invariably 6to4 prefix, and RFC3484-bis generally handles that.  And such 'accidental' rogue RAs are very unlikely to be fragmented in an attempt to defeat RA-Guard.   RFC6104 was written with accidental RAs in mind, for reasons stated in the text.

Interestingly I've noticed a few scenarios where unicast RAs are being suggested more, e.g. related to wireless roaming on campuses.

Tim

---

From: Ray Hunter <[email-masked]>
Date: Thu, 23 Jun 2011 19:14:10 +0200

Mikael Abrahamsson wrote:
>> too. But RA Guard should not be a prerequisite for reliably setting 
> I don't see 5-10 year old LAN switches having any kind of capability 
> of filtering just certain IPv6 packets. They might have the 
> possibility of filtering all 0x86dd packet which is the sensible thing 
> to do unless one can secure it by other means.
>
> Securing L2 networks is something not generally done today in 
> enterprise and surprisingly often in SP environments as well. This can 
> be seen by all the problems reported by Windows ICS v6 RA:s being sent 
> out and causing problems to other users (which in a properly build 
> network it shouldn't have the capability of doing, because those 
> packets should be filtered by the access network). 
Many current devices implement DHCP snooping, IP source guard, and 
similar ARP inspection filters for DHCP (v4) (as an alternative to 
802.1x) because the user admin associated with L2 security technology is 
generally a heavy operational burden. I don't have figures for the 
percentage of people who would be affected by losing such equivalent 
functionality if they moved to IPv6 today, but presumably there was an 
operational "need", or else these IPv4 features would not have been 
implemented. Obviously the likes of 802.1X are technologically far 
superior, but that isn't always the deciding factor for implementation.

I can guess the answer the CFO will give those same people if they 
request to renew their current L2 switches 5 years early just because 
they need to implement RA Guard.

So what would those people do today to retain similar functionality for 
IPv6 without investing heavily, or switching off IPv6?

 > Short of encrypting all traffic and pre-distributing keys

If the WG has reached a stage of looking for a potential alternative 
mitigation (and perhaps completely crazy out of the box thinking) that 
doesn't involve replacing switches, may I humbly suggest consideration 
of using the current DHCPv4/bootp mechanism to distribute an IPv6 
address and MAC address (or some other stronger public-key) associated 
with one or more trusted default routers in the initial network booting 
process as a mitigation mechanism/ stop gap? The IPv6 hosts can then 
defend themselves by filtering incoming RA messages to be from the 
trusted source. I know it sounds truly awful, but it might work. IPv4 
RFC1918 addresses are not going to run out. And it seems to me that's 
the gap between DHCPv6 and DHCPv4 if you have a "problem" with rogue RA, 
but you already have a decent solution in place for "secure enough" 
DHCPv4 and DHCPv6. After all, IPv4 transport was also deemed acceptable 
for use in resolving IPv6 AAAA records. If this is too far left field, 
please simply ignore me :) Or better still, propose something smarter ;)

regards,
RayH