Welcome to this Cisco Support Community Ask the Expert conversation. This is an opportunity to learn and ask questions about IPv6 Security with experts Eric Vyncke and Andrew Yourtchenko.
Distinguished System Engineer Eric Vyncke and Engineering Technical Leader Andrew Yourtchenko explain the security myths and security issues in the IPv6 protocol. Though IPv6 is only available to 3 percent of Internet users, this number is doubling every 6 to 9 months, and, more important, all host OSes have IPv6 enabled by default. The session will focus mainly on the protocol security itself, though some product features will also be explained. It is expected that the attendees have some knowledge of IPv6 and also of IPv4 network security.
This is a continuation of the live webcast.
Eric Vyncke is a distinguished engineer based in the Brussels office of Cisco. His main current technical focus is security and IPv6. He has designed several secured large IPsec networks and other security-related designs. In his work for the IETF, he coauthored RFC 3585 and 5514 and is active in V6OPS, 6MAN, and OPSEC working groups. His recent works are related to IPv6, including coauthoring a book on IPv6 security; he also authored a book on Layer 2 security. Eric is the current cochair of the Belgian IPv6 Council; www.vyncke.org/ipv6status is well known for several years to collect statistics about IPv6 deployment. He is also a visiting professor for security topics at the University of Mons. He is an adjunct professor at HEC, the business school of University of Liège, Belgium. He holds a CISSP certification, is a member of ISSA, and speaks frequently at international conferences.
Andrew Yourtchenko, CCIE No.5423 is a Technical Leader at Cisco Systems Network Operating Systems Technology Group, and has been involved in networking since 1995, specializing in the areas of applications and network security. He spent a significant portion of his career at Cisco TAC, driving the resolution of complex technical problems. He contributes to IETF, and is a frequent speaker at IPv6 conferences. He actively engages with Cisco customers and partners in the areas of IPv6 transition, focusing on the transport and application levels.
Remember to use the rating system to let Eric and Andrew know if you have received an adequate response.
Because of the volume expected during this event, our experts might not be able to answer every question. Remember that you can continue the conversation in the Security community under subcommunity Other Security Subjects shortly after the event. This event lasts through May 9, 2014. Visit this forum often to view responses to your questions and the questions of other Cisco Support Community members.
Webcast Related Links
Hello Eric and Andrew,
Thank you for covering this important topic. My question is, if I do not have IPv6 on my network, should I be concerned?
Yes, you should be concerned because as soon as you have a single host (desktop, laptop, tablet, ...) whose Operating System has IPv6 enabled by default (which means all of them except Black Berry & XP), then, a LOCAL attack can be mounted using IPv6 link-local addresses (which are always present).
The rogue RA attack will work in an IPv4-only network by enabling IPv6 on all devices and attracting all IPv6 destinations (Gmail, WIkipedia, ...) through the rogue router. A Man-in-the-middle attack can then be mounted with the help of tunnels.
The only kind of attack against which your IPv4-only network is protected are the remote IPv6 attacks.
Please note that this is not a sign that IPv6 is bad or insecure, it is simply a sign that security policies must be augmented even in IPv4-only network. For example, you need to augment your vulnerability scanning by adding IPv6 scanning NOW.
I hope it helps
I was hoping for your thoughts on selecting an IPv6 prefix for a large organisation with Internet connectivity so as not to compromise security. I have seen various posts and articles on the topic. Is the current recommendation to deploy global on every network device, including deep within your core network behind your Internet facing firewall?
May I suggest to post your question in a generic IPv6 thread? This one is dedicated to security :-)
But, in short, "it depends"... Most deployments start with the Internet facing edge (web / email /VPN servers which is the most critical issue) then moving to the inside network/intranet starting indeed with the core, then distribution then access (it is safer to do this in this order usually and you gain experience without disrupting anything)
I don't think I framed my question properly. This was in relation to a greenfield IPv6 site. Many of my IPv4 colleagues think that deploying global IPv6 to every device is a security risk. Their argument is that in theory hackers could route to these addresses from the internet.
They are used to deploying RFC 1918 IPv4 addresses on enterprise networks. They therefore think that the equivalent IPv6 solution is to use ULA addresses and then NAT these to a global address in order to reach the Internet.
I'll do some further research.
Edited by S. Evershed
Yet another classical question :-)
First, please note that NAT (while being often colocated with a firewall) offers nearly no security (after all most of the botnet members are being a home router doing NAT -- CodeRed, Nimda have been replaced by more sophisticated attacks). NAT makes security even harder: writing ACL is more complex and audit-trail is either impossible or way too long.
Second, as you know, RFC 1918 address and ULA does not prevent 'by magic' any communication with the outside. There are a lot of packets on the Internet whose source address is RFC 1918 or ULA... My point is that even with those addresses, a security policy MUST be enforced at the perimeter of your network.
So, NAT makes thing more complex hence less secure. But, of course, esp for enterprise network, please use a network firewall (plus IPS, ...) to block some traffic based on layer-3 or layer-4 information such as addresses.
A promise of IPv6 is to make network cleaner and easier (hence safer) to operate thanks to the absence of NAT. So, think twice before using NAT for IPv6.
If you really want to make your life miserable, then you can use NAT for IPv6 on ASA (even overloading, i.e. all your zillions of internal IPv6 addresses mapped to a single 'public' IPv6 address). Again, not recommended.
To be honest, this is a frequent question. It will take some time for your security dept to swallow it and to digest the above answer
Many of my IPv4 colleagues think that NAT provides security through network obfuscation. However it was never designed for that purpose and as you say it's doesn't really work that way.
Thanks for the feedback Eric.
Bear in mind that there isn't really any NAT66, so while you can hide ULA's behind an application proxy just as in v4, you can't expect to reliably translate from a ULA to a global v6 address, not in a multivendor environment, unlike v4. Plus a lot of even fairly recent operating systems make silly address choices if they see both ULA and global addresses. So your ULA-only hosts with only internal communications are OK, but the rest of your v6 network breaks, unless you spend a lot of time tuning your address prefix policy tables.
Really, tell folks to just use global unicast addresses and learn to like it.
-- Jim Leinweber, WI State Lab of Hygiene
Please note that blocking IPv6 traffic is not really the right thing to do. You will spend a lot of energy to implement it (see below) and some applications may fail (by default Windows and others try to use IPv6 link-local communication). Moreover, in a couple of years, you will force to reverse the setting by embracing IPv6.
In short, blocking IPv6 is not a short-term fix, it is more a waste of time ;-) Rather deploy IPv6 or at least configure your network to block IPv6 attacks (RA guard for instance in your switches).
There are basically two ways to prevent any IPv6 traffic in your network:
You may also want to use IDS/IPS to detect any non-compliant host/switch configuration because this will be a long 'mouse and cat' game.
Good luck :-)
Hi Éric and Andrew,
Thanks for this opportunity and looking forward to seeing your latest presentations at Live. With the publication of RFC 7112, do you see IOS (Routers/Switches)/IOS-XE/ASA/NX-OS adding an option to allow enforcement? Perhaps an option at the Interface or VLAN level (like RA Guard) which drops any IPv6 packet where the entire header chain isn't present? This seems like a great and simple way to make sure there are no loop holes with RA Guard/DHCPv6 Snooping/etc. I know no commitments/timelines can be offered. Hoping you can comment on interest and your perceived urgency.
Another question I wanted to ask is what do you think of taking the tools from Mr. Gont and Mr. Heuse and incorporating them into standard product tests? For example - with IOS/ASA my thought is that any of the various RA Flood type attacks shouldn't spike the CPU. Looking at Linux, I believe this is possible. Has this been considered?
Finally - there are many fantastic security options available in Cisco products for IPv6 already. However, any thoughts as to some tuning guidance? NDP for example offers many knobs for its various facets but would be great to see a discussion of the pros/cons of various approaches. The FHS wiki (http://docwiki.cisco.com/wiki/FHS) and your Live talks for example are fantastic. More resources - especially detailed write ups/whitepapers would be welcome.
Best regards and thanks again,
[Retyping the whole reply after this $*%! system failed to accept my reply ]
Nice to read from you again and thanks for participating in the webcast!
Cisco has implemented 'undetermined-transport' years before RFC 7112 in order to block those too-long-extension-header packets. Of course, as it is a data-plane feature, it is heavily depending on the existing HW hence not available on every switches... The missing platforms keep me awake at night sometimes... A real threat.
Regarding the regression tests, I am unsure and cannot reply to you. I know for sure that Cisco Product Security Incident Response Team is aware and usually they are pretty efficient to fix bug and to prevent them to occur in other places/time.
Point taken for white papers as well
Thanks again for your interest and looking forward to meeting you at Cisco Live in a couple of weeks
Hi Éric and Andrew,
I have noticed that there are incompatibilities between IPsec VPNs using different platforms. For example, I don't believe an IPv6 IPsec tunnel can be established between an ASA and an IOS Router. Ideally I'd like to see the following all supported:
ASAv4v4 <--> IOSv4v4 - Works (IPv4 outer and inner tunnels)
ASAv6v6 <--> IOSv6v6 - Don't believe works (IPv6 outer and inner tunnels)
ASAv4v6 <--> IOSv4v6 - Don't believe works (IPv4 outer and IPv6 inner tunnels) - See CSCtu09251
ASAv4DS <--> IOSv4DS - Don't believe works (IPv4 outer and IPv4+IPv6 [Dual Stack] inner tunnels) - is this supported by the current RFCs? Or can you only have a single address family for the inner tunnel?
ASAv6v4 <--> IOSv6v4 - Don't believe works (IPv6 outer and IPv4 inner tunnels) - See CSCtu09251
ASAv6DS <--> IOSv6DS - Don't believe works (IPv6 outer and IPv4+IPv6 [Dual Stack] inner tunnels) - is this supported by the current RFCs? Or can you only have a single address family for the inner tunnel?
Perhaps the best place to start is to define the problem. Do the current IPsec/IKE RFCs support interoperability:
v4v4 <--> v4v4 - supported
v6v6 <--> v6v6 - believe supported, agree?
v4v6 <--> v4v6 - supported?
v6v4 <--> v6v4 - supported?
v4DS <--> v4DS - supported?
v6DS <--> v6DS - supported?
The next step is what makes sense for Cisco to support. Perhaps starting with the above combinations and FLEX VPN on IOS with the ASA?
Very interested in your thoughts on this,
I have not done the tests you mention in my lab (there are not so many users using IPsec VPN between IOS & ASA :-) ), so, I can only partially reply to your question.
Indeed, IOS VTI (native IPsec without GRE) does not support one protocol family inside the other one. Using Flex VPN or DMVPN allow you to do this mix but not supported by the ASA.
Regarding IETF RFC, my reading is that a single IKE/ISAKMP session can negotiate two pairs of IPsec SA: one for IPv4 and one for IPv6. Very similar to a single tunnel.
Of course, for site to site, DMVPN & FlexVPN allow for a single GRE tunnel which can be used to transport both IPv4 and IPv6. This is what Cisco employees have at home ;-) and it works fine.
Sorry for this partial reply