Subject: [v6ops] IPv6 transition technologies vs MITM (DEFCON)

From: Tom Perrine <[email-masked]>
Date: Thu, 22 Aug 2013 11:51:44 -0700

There's been a fair amount of debate on the list about the merits of using the transition technologies vs an aggressive
move to native IPv6 (usually dual-stack). We keep coming back to (as we have for 10+ years) to finding business reasons
to transition.

In parallel, there's been a goodly amount of poking around IPv6, "the real world" and those transition technologies.

The MITM attack demonstrated at DEFCON this year was nothing new. While it was widely covered as an "IPv6 security
flaw", it was really taking advantage of the well-known "RA problem" and the behavior of an IPv6-capable node on a
nominally IPv4-only network.

Frankly, while it was a nice "one click" automation of an already-recognized exploit, there wasn't really anything new.

But, what I'm seeing is that no one is talking about how the transition strategies will not address this attack at all,
at least as far as I can tell. They all seem to seek to leave (allegedly) IPv4-only nodes in place and work at one or
more hops away from those nodes. This ignores that so many nodes really aren't IPv4-only. They are really dual-stack
nodes that are waiting for the IPv6 configuration to be completed. And you can complete that configuration, or your
attacker will!

I see two ways to mitigate this attack:  turn off IPv6 on all modern OSes, or fully deploy IPv6.  Guess which one I
don't want to see advocated :-)

Am I missing something, or is this one more point to add to the "deploy IPv6 now, deploy native, skip the transition
technologies" ?  (I'm including dual-stack in the native strategy.)

---

From: Tim Chown <[email-masked]>
Date: Thu, 22 Aug 2013 21:51:18 +0100

> technologies" ?  (I'm including dual-stack in the native strategy.)

There's lots of work within the IETF on this, e.g. take a look at http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05.

The sunset4 WG is also quite interesting.

I'm surprised an event like DEFCON presented something that old.

Tim

---

From: David Farmer <[email-masked]>
Date: Thu, 22 Aug 2013 17:59:18 -0500

On 8/22/13 15:51 , Tim Chown wrote:
>
> On 22 Aug 2013, at 19:51, Tom Perrine <[email-masked]
> <mailto:[email-masked]>> wrote:
>
...
>> But, what I'm seeing is that no one is talking about how the
>> transition strategies will not address this attack at all,
>> at least as far as I can tell. They all seem to seek to leave
>> (allegedly) IPv4-only nodes in place and work at one or
>> more hops away from those nodes. This ignores that so many nodes
>> really aren't IPv4-only. They are really dual-stack
>> nodes that are waiting for the IPv6 configuration to be completed. And
>> you can complete that configuration, or your
>> attacker will!
>>
>> I see two ways to mitigate this attack:  turn off IPv6 on all modern
>> OSes, or fully deploy IPv6.  Guess which one I

Yes, deploying IPv6 is the best answer in many, if not most cases.  BUT;

>> Am I missing something, or is this one more point to add to the
>> "deploy IPv6 now, deploy native, skip the transition

I will expand on the references Tim provides below; On all IPv4 only 
networks you should operationally deploy RA-Guard or filter IPv6 ICMP 
RAs, and DHCPv6 server responses while you are at it too, on all access 
ports where you can, and more drastically filter Ether-Type 86dd all 
together where you don't have RA-Guard or IPv6 filters available.  In my 
view RA-Guard is not only a IPv6 network issue it an issue for all 
networks because of these MITM attacks.

Before World IPv6 day more than two years ago, we had a project to make 
our entire network quad-A safe.  That is we deployed IPv6 every where we 
could, and deployed IPv6 ICMP RA filters on virtually every wired access 
port.  We deployed IPv6 on our 802.1x authenticated wireless.  But we 
had to deploy 86dd filters on our web portal authenticated wireless, as 
the web portal didn't support IPv6, still doesn't, and there was no way 
to properly protect from Rogue RAs, other than to filter all IPv6 
traffic.  These generally weren't malicious MITM attacks, but were 
misconfigured hosts with Internet connection sharing turned on, but they 
still create issues on IPv4 only networks and would break any sites that 
would dare to use quad-As.

So, back to the big BUT above, it is naive to think you can deploy 
native IPv6 absolutely every where.  You may be able to deploy it most 
places, but you must protect from Rouge RAs every where, even IPv4 only 
networks.

For policy reasons, still today, we still haven't turned on IPv6 in 
several parts of our network.  These are mostly areas that deal with 
private data, HIPPI, FERPA, PCI and other compliance regimes, but it was 
extra important that theses areas also got RA-Guard for the very same 
reasons we haven't turned on IPv6 yet.

> There's lots of work within the IETF on this, e.g. take a look at
> http://tools.ietf.org/html/draft-ietf-opsec-ipv6-implications-on-ipv4-nets-05.
>

It's an oldie but goodie. :)

-- 
================================================
David Farmer               Email: [email-masked]
Office of Information Technology
University of Minnesota
2218 University Ave SE     Phone: 1-612-626-0815
Minneapolis, MN 55414-3029  Cell: 1-612-812-9952
================================================

---

From: Fernando Gont <[email-masked]>
Date: Wed, 28 Aug 2013 03:37:36 -0300

> reasons we haven't turned on IPv6 yet.

Regarding RA-Guard, you're probably aware of
<http://tools.ietf.org/id/draft-ietf-v6ops-ra-guard-implementation-07.txt>.

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