IPv6 is often called a “complex protocol”, not least by myself (for example in my keynote to the IPv6 Security Summit 2014). In this post I want to have a quick look at three questions:
– Can IPv6 be considered a “complex protocol”?
– Is it “more complex” than IPv4?
– Can we expect IPv6 networks to be “complex networks”?
In our talks in the past we showed what might be possible if an attacker gets access to backhaul and/or core network of a telecommunication provider. In a security analysts perspective this is really disgusting, but provider always will argument that those attack scenarios are not realistic.
The purpose of this blog post is to elucidate how and why MLD, an IPv6 protocol we’ve been lately talking quite a bit about, is an unnecessarily complex beast . This article should also serve to summarize a couple of points we’ve mentioned during our talks about MLD but which because of time constraints never make it into the main discussion. We’ve talked about other aspects of MLD in previous posts. So, have a look at those if this is a topic which you find interesting. Without further ado, let’s start for today.
Troopers is right around the corner and as I am responsible for the whole conference network I wanted to make sure that everything is working as expected. I went to the venue on Friday because of two things I wanted/needed to setup. Compared to last year’s setup we had a couple of changes in regards to the provider connection (resulting in some changes for our network setup). First, we now have a rather big pipe for the uplink and more importantly (well that depends on the point of view ;)) there is a native IPv6 connection. Before that I had to tunnel all IPv6 traffic from the venue to one of our gateways and to forward it out (as native IPv6) from there. As this step isn’t necessary anymore, and the staff on the venue isn’t that experienced with IPv6, I had in mind to setup and verify that IPv6 is working as desired. The router used over there is a Mikrotek Routerboard. As I haven’t worked with these devices before, I was curious whether everything works as it should ;).
After configuring the IPv6 address on the WAN interface I tried to install a default route pointing to the uplink’s Global Unicast Address. But to my surprise, the Mikrotek router kept stating that the next hop was unreachable. This was odd, as the provider’s device was happily answering to pings from the Mikrotek’s command line. Additionally, the Mikrotek router does not install a route when it can’t reach the next hop configured (which is actually not that bad as it at least prevents fat fingering the address). It still didn’t make any sense. After googling around (I found the Mikrotek documentation a little bit lackluster) and trying some other things it still didn’t work. As a last resort, I told myself “screw it and let’s try with the link local address of the provider router”, but how do I get this address as I only was provided with the GUA? Right, looking at the Neighbor Cache of the Mikrotek router I was able to quickly find the link local address of the next hop.
After using this address (together with the interface) as the next hop it started working, by magic. At least I can now sleep better as it is one less thing I have to worry about ;).
Moral of the story: Still in 2015 don’t expect a device to behave like it should when it comes to IPv6. Unfortunately, I wasn’t able to follow this strange behavior up due to time constraints, but it is working and you can enjoy for the first time native IPv6 in the conference network.
If you want to know more about the general conference setup please stop by for my talk at the IPv6 Security Summit.
Based on recent research in the ERNW IPv6 lab and with our MLD talk looming we’ve put together a (as we think) comprehensive document discussing how to thoroughly test MLD implementations in various components (network devices or servers/clients). We hope it can contribute to a better understanding of the protocol and that it can serve as either a checklist for your own environment or as a source of inspiration for researchers looking at MLD themselves.
Server operating systems with an OS, for which vendor support has ended, come with many risks that have to be considered and addressed. The primary goal should be always to decommission or migrate the majority of end-of-life (EoL) servers to OS versions, supported by the vendor. Here it should be noted that a migration to an up-to-date OS should be preferably done before your organization enters the end of life of that software 😉