[ipv6hackers] IPv6 security presentation at Hack.lu 2011
tpoder at cis.vutbr.cz
Wed Sep 28 15:31:07 CEST 2011
thanks for comments. I made some to clarification/extension into text.
On 9/27/11 4:30 AM, Jim Small wrote:
> 05/2011 IPv6 - Security Issues - IPSec does "solve" everything
> 09/2011 Deploying IPv6 in University Campus Network
> (starting slide 26 there are touched some issues that we feel them as
> are very problematic - specially in a security area).
> [JRS>] For problem 1, very nice write up and demonstration of the complexities/issues with address auto-configuration.
> For problem 2, impact on existing IPv4 infrastructure - for the most part this exists today. You can do ARP poisoning/spoofing and you can just as easily enable a rogue DHCPv4 server. The only real difference here is that because you can fragment NDP a malicious attacker is much harder to block. For someone accidentally enabling RAs/DHCPv6 this can be blocked with RA Guard/Port ACLs.
Yes, we already discussed that before. There are some possibilities but
implementing them into either existing or new infrastructure is really
not a piece of cake.
> For problem 3 - as has been discussed and shown there are solutions but the question remains will they be adopted/implemented?
> I do not agree with your conclusion for problem number 4. There are many benefits to IPv6. IPv4+NAT smothers innovation, especially for communications. It is ironic that the Internet was created for communication and yet IPv4+NAT makes this very difficult and requires 3rd party gateways. IPv6 restores this, at least partially by removing the need for NAT.
IT professionals have no doubt about need of IPv6. Unfortunately
ordinary users that are used to using common applications (web, FB,
skype, twitter, ip telephony) do not understand what is wrong with
current IPv4 network and why some changes are necessary. People who
decides about money are ordinary users as well and it is very difficult
do convince them that money spend on a IPv6 infrastructure will not be
> For number 5 it really depends on who. Actually Cisco and Microsoft has excellent IPv6 VPN solutions. Cisco is closing in on feature parity between IPv4 and IPv6. Microsoft has also done fairly well in this regard. But you are correct in that some solutions/vendors have poor IPv6 support.
Right. VPN was just an example. There are problems not only with VPN.
Many vendors claims support for IPv6, but often only basic IPv6 features
are implemented. For example some routers supports BGP, but BGP+ is not
implemented. Just same story with multicast routing, VRRP, etc.
> For problem 6, privacy extensions can be disabled although this can be an issue for non-managed devices. I'm not sure what you mean by Netflow - v9/IPFIX support IPv6. DHCPv6 does have issues to work through but I think you captured this in problem 1. NAT is its own topic but where you talk about the benefits (and there are some), you should also talk about the drawbacks which are just as numerous. IPv6 tends to result in more tunnels too, but this really isn't a new issue - these exist today in IPv4. I will say that on a decent sized network with IPv6 IPAM becomes a necessity.
The basic problem with privacy extensions and netflow becomes when the
flow data are used for accounting purposes. The pure netflow data can
provide enough information due to address changes. The more detailed
description of the problem can be found in the following document
(based on collecting neighbor cache and extending flow data).
I agree with you comment about NAT. There no doubts that NAT has lot of
The problem with tunnels is something new in IPv6 from my point of view.
Sure - tunnels/VPNs are common in IPv4 as well, but there is a big
difference. Tunnels like 6to4 and teredo are created automatically
without attention of users or administrators. But that problem can be
partially solved by deploying native IPv6 connectivity.
> Problem 7 is an issue. I think it is likely IPv4 will disappear off the Internet in less than 10 years. However, within our intranets it will likely persist for a long time most likely out lasting all of us. :-) This is added complexity but I think it's unlikely a solution will emerge to eliminate it. Just like with AppleTalk, IPX, SNA, DECnet and other legacy protocols as long as it is needed it will persist.
Right, that is matter of time. I thing less than 10 years is too
optimistic (considering that many enterprise vendors have not even think
about ipv6 :-) ). We will see in 10 years.
> I do not agree with problem 8. Newer development languages abstract addressing. If you use the right development tools you will most likely be oblivious to the addressing system. This is really only an issue for network administrators and people who write device drivers and the like. I like the presentation overall and agree that we need to have frank discussions and push vendors to solve existing problems.
Exactly - it is the only way how we can move forward with IPv6.
Thanks again for your comments.
More information about the Ipv6hackers