[ipv6hackers] "Stick to limited IPv6 deployments, businesses warned"

[Tim Chown]

On 4 Sep 2012, at 22:02, Tomas Podermanski <tpoder at cis.vutbr.cz> wrote:
> 
> Not at all. 802.1X is the layer 2 authentication. That says nothing
> about IP address used for communication. You have to deploy some
> mechanism that allows somehow tie L2 information obtained from 802.1X
> authentication process (user, MAC address) with a L3 IP address. What is
> pretty difficult since DHCPv6 don't have MAC in the requests and it is
> impossible to tie 802.1x authentication requests with DUIDs from DHCPv6.
> As such some extra system that gathers neighbor cache on the router have
> to be deployed. The absence of MAC address in DHCPv6 is really tragic
> issue.

There is this, which is about adding the link layer address in relays.  So this gives you what you want if you're in an environment where all DCHPv6 requests are relayed.

http://www.ietf.org/id/draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-01.txt

> Some more about that is on
> http://ipv6.vutbr.cz/article/flow-based-monitoring-of-ipv6/ (slide 6)
> and more detailed description in the article
> http://ipv6.vutbr.cz/article/design-of-data-retention-system-in-ipv6-network/.

We harvest the necessary information from switch/router devices. There's a few open source packages that do this.

> You are right. The support for IPv6 in Win XP is in a minimal form.
> However I expect that Win XP will disappear in a few next years. It is
> one of the reason why we are just considering redesigning our SLAAC
> environment to pure DHCPv6. Devices that doesn't support DHCPv6 won't
> have access to IPv6 network. Users will have to either upgrade their
> system or install additional software with a DHCPv6 client.

Personally I think it's equally valid to take the view that IPv6 devices will pick their own addresses, and take account of that.  In a campus style environment anyway.

>> 5)  First Hop Security Threats - there are some vendors who have solutions to all of these (though limited availability for some of them to a few high end products for now)
> 
> Many vendors have some solution for this kind of threads (at least some
> of them), however the price of those devices is much bigger comparing to
> the devices that have similar security features for IPv4. For example
> Cisco have this features only in the "big boxes" (6xxx, 49xx, 45xx) that
> are no suitable as the access switches. Wen we building a new
> installations we are in very difficult position. It is tough decision
> whether to buy much more expensive switches that supports IPv6 security
> features. Another option is to buy cheaper switches that have this
> features only for IPv4 and in case of massive attack just block whole
> IPv6 traffic on the access ports.

We've found the Cisco first hop security implementation in their WLCs problematic.  Hopefully the new 7.3 builds just released will fix this.

>> 8)  Slide 27 - first hop security countermeasures:
>> SeND - will probably never happen.  Microsoft and Apple have no interest in doing this and that pretty much kills it.
>> RA-Guard/PACLs - these work.  It's true you can use a tool to defeat these with fragmentation but that requires actively attacking the infrastructure with an attack tool (would never be by accident which is mostly what you run into).  If I look at the IPv4 world, it is rare that people deploy DHCP snooping/DAI/IPSG because it can break protocols that can't deal with security (e.g. Apple's).  Therefore while I would like to see a solution to this I wonder how many people will actually use it.
> 
> I can't agree that features like DHCP snooping are used very rare.

When I poll audiences of university network people, about half the hands go up when I ask who uses DHCP snooping.

> I didn't want to implicate that message. That slide just says the there
> is always something more important than IPv6 in many organizations  That
> is the reason why IPv6 deployment is going so slow.

Which is the main reason that while 100+ UK universities have an IPv6 allocation, only 10 or so have any significant deployment.

The other arguments of managing IPv6 for security benefit, deploying to support teaching/research, etc haven't yet worked through. Other priorities are higher, and most universities in the UK have old Class B IPv4 allocations.

> The fact is that less than 0.7% of clients are able to use IPv6 today
> and less that 4% of content providers have content available over IPv6.
> Such numbers also means that there are approximately 99.6% of clients
> that are not able to reach IPv6 content and 94% of content (lets say web
> sites) is not available for IPv6 only clients. It doesn't look good on
> both sides and I really don't know what to do about it.

It depends which countries you look at.  France and Romania are much higher.  And while 4% of content providers have IPv6 by number, by traffic volume from a typical residential network, the figure is much higher, even approaching 50%.  See http://6lab.cisco.com/stats.  Google, FB, Youtube, etc represent a lot of traffic for home networks.

> Maybe it is something to think about. However it seem that process is a
> "log distance run". Having practical experience the problems that we
> tried to solve 4-5 years ago aren't solved yet or a very little progress
> has been done. But there is still hope that progress will speed up
> before all ISPs deploy CGNs.

I fear that once the expensive CGNs go in, ISPs may not thrown them away in a hurry.

> Thanks a lot for your comments. I really appreciated it.

Your slides are very good :)

Tim