Building

Practical IPv6 Troubleshooting while Setting up the Troopers Network

Hello Everyone,

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.

See you all in a week!

Best,

Christopher

Continue reading
Building

An MLD Testing Methodology

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.

Continue reading “An MLD Testing Methodology”

Continue reading
Events

A Chiron Workshop at the IPv6 Security Summit of Troopers 15

This is a guest post from Antonios Atlasis.

Last year, during the IPv6 Security Summit of Troopers 14 I had the pleasure to present publicly, for first time, my IPv6 Penetration Testing / Security Assessment framework called Chiron, while later, it was also presented at Brucon 14 as part of the 5×5 project. This year, I am returning back to the place where it all started, to the beautiful city of Heidelberg to give another workshop about Chiron at the IPv6 Security Summit of Troopers 15. But, is it just another workshop with the known Chiron features or has something changed?
I would say a lot :). The most significant enhancements are described below.

Continue reading “A Chiron Workshop at the IPv6 Security Summit of Troopers 15”

Continue reading
Building

IPv6-related Requirements for Security Devices

This is the sequel to the similar post on “IPv6-related Requirements for the Internet Uplink or MPLS Networks“. As mentioned there these requirements were created in the course of an RfP for network security services. The goal of this document was to provide a check list of IPv6-related requirements that security devices being part of the individual providers’ offerings have to fulfill in order to fully support the future IPv6 network.  Continue reading “IPv6-related Requirements for Security Devices”

Continue reading
Building

Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6

One of the main DHCPv6 enhancements – fyi: we have already discussed DHCPv6 in some other posts – many practitioners have been waiting for quite some time now, is full support of RFC 6939 (Client Link-Layer Address Option in DHCPv6) by network devices (acting as relays) and DHCPv6 servers. RFC 6939 support would allow a number of things which large organizations use in their DHCPv4 based networks, incl.

  • reservations (assigning a kind-of fixed DHCP address based on the MAC address of a system which in turn allows for “centralized administration of somewhat static addresses”).
  • correlation of IPv4 and IPv6 addresses of a given host identified by its MAC address.
  • (some type) of security enforcement based on the MAC address of a host gathered in the course of a DHCP exchange (see for example slide #29 of this presentation of the IPv6 deployment at CERN, btw: slide #9 might be helpful when discussing IPv6 transition plans with your CIO. or not).

So far it seemed very few components support RFC 6939. When Tim Martin mentioned at Cisco Live that Cisco devices running IOS XE support it by default, we decided go to the lab ;-).

Continue reading “Is RFC 6939 Support Finally Here – Checking the Implementation of the “Client Link Layer Address Option” in DHCPv6”

Continue reading
Building

IPv6-related Requirements for the Internet Uplink or MPLS Networks

We’re currently involved in a complex RfP procedure for global network services of a large organization. As part of that we were asked to define a list of IPv6 related requirements as for the  Internet uplink and MPLS circuit connections. The involved service providers/carrier offerings will be checked to comply with those.

Continue reading “IPv6-related Requirements for the Internet Uplink or MPLS Networks”

Continue reading
Building

The Persistent Problem of State in IPv6 (Security)

I’ve discussed the heavy complexity of IPv6 and its negative impact on security architectures relying on state  – you know, “stateful” firewalls and the like 😉 – before (here and here. btw, the widely discussed IPv6-related network outage at MIT last year was a state problem as well: switches keeping track of multicast groups, of which in turn many existed due privacy extensions combined with the unfortunate relationship of MLD and ND).

One of the conclusions I’ve drawn in the past was recommending to minimize the amount of state one might use within security architectures in the IPv6 world. First, this is bad news for quite some well-established security controls that need a certain amount of state to work properly, like IDPS systems – which subsequently have hard times to work properly in IPv6 networks.
Secondly there’s another severe caveat. As I fully realized yesterday, at Cisco Live Europe, in Andrew Yourtchenko‘s excellent breakout session on “Advanced IPv6 Security in the Core”, this carries some consequences for stateless (and hence: seemingly “unaffected”) security controls, too.

Continue reading “The Persistent Problem of State in IPv6 (Security)”

Continue reading