Welcome to the third edition of “Beyond the Thunderdome: A Review of TROOPERS15”. The focus today is on IPv6 and Data Center Networks, so kick back and enjoy the following talks and videos. And as always, check out our website www.troopers.de for details on TROOPERS16 March 14-18, 2016.
“Enabling and Securing IPv6 in Service Provider Networks” talk created and given by Tarko Titan
Telekom.ee had no IPv6, 8 moths ago. They deployed IPv6 in about 4 weeks and by now about 6% of all transported traffic is IPv6 traffic. Actually the 4 weeks timeframe is a bit too optimistic but more on that later. Tarko first explains the biggest problems in the network migration, which were the access network and the Customer -Provider Edge (CPE). Also Telekom Estonia doesn’t want to make a tradeoff at security in the IPv6 deployment.
Next he explains their network setup, which was built around a big L2 access network, accomplished by a L2 core transported via Multi Protocol Label Switching (MPLS) pseudo wires. All redundancy was purely implemented in the MPLS part of the network, as it can be gained there for free. Also a split horizon was implemented, so that the CPEs can’t communicate with each other but only with the Border Network Gateway (BNGs). Some special protection mechanism needed to be implemented in the layer 2 domain, as special loop protections for the connected customers. Not more that 8 Mac addresses are learned per customer to compensate against resource exhaustion. The uplink BNG addresses must not be learned from the customer facing ports and some rate limiting needed to be deployed for unknown unicast, multicast and broadcast traffic.
Then Tarko explains the boot up process of the Customer-Premises Network (CPNs), which first establishes IPv4 communication and delay IPv6 configuration till that’s finished. The CPNs are authenticated on the BNG via DHCP option 82 and connected port number. In IPv6 more overhead is needed, the process starts with the default router configuration, which is done via Router Advertisements (RAs), as DHCP6 has no option to configure the default router. The RA setup is a bit hacky and not standard conform, as the RAs are send from the BNG to the unicast address of the CPEs, to not flood the network. The actual authentication is in IPv6 also done via DHCP6 and is synced against the already known IPv4 authentication data. Some special features needed to be implemented on the CPEs to improve customer experience, like an IPv6 ingress firewall, which by default blocks incoming Transmission Control Protocols (TCP) connections. Also Neighbor Discovery (ND) data is logged on the CPE to make the debugging process simpler for the helpdesk.
In the future Telekom Estonia wants to support other CPEs for IPv6, today only the own boxes are supported. Also they want to implement hierarchical address delegation on customer sites and move their own VoIP and IPTV application to IPv6.
In the end, Tarko showed statistics showing today already 38000+ subscribers using IPv6, 70% with more than one IPv6 enabled device. Also he explained the overly optimistic migration phase, which had 3+ years of leading work. It started with the BNG replacement, the configuration rollout, but still filtering IPv6 at the BNGs and ended with debugging and CPE customization.
Check out the slides here
“IPv6 First Hop Security in Virtualized Environments” talk created and given by Christopher Werny
In Christopher’s talk he will give an overview which features are available on common virtual switches in VMware ESX and MS Hyper-V environments and how they compare to their “physical counterparts” in terms of configuration and actual security benefit provided.
He starts his talk with an introduction to IPv6 First-hop Security and explains what it is about. Cisco First-Hop-Security is a marketing name for various security features in IPv6. The rollout was planned in three stages. Phase1 is available since summer 2010 and introduced RA Guard and Port based IPv6. Phase 2 is available since the end of 2011 or, depending on the platform, since the beginning of 2012. It introduced DHCPv6 Guard and NDP Snooping.
In his opinion, First-Hop-Security is so important in virtual environments because more and more systems get virtualized on different Hypervisor platforms and because private cloud environments are getting more and more prevalent.
To test the First-Hop-Security capabilities of different virtual switches, he uses a Hypervisor lab setup with three different types of Hypervisors: Windows Server 2012 R2 Hyper-V, VMware ESXi 5.5 and Kernel-based Virtual Machine (KVM). Based on it, three different types of virtual switches are tested: Hyper-V vSwitch, Cisco Nexus 1000V and Open vSwitch.
He tests the three different virtual switches with the same testing procedure. The first step is: use default switch configuration, perform different (IPv6) attacks and observe/document the results. The second step is: activate/configure the First-Hop-Security feature of the switch, test again and observe/document the results. In the last step, he tries to evade the First-Hop-Security feature. He uses the THC-IPv6 toolkit and do a couple of test like fake_router26, flood_router26 and fake_dhcps6.
The result of the tests he has performed shows that IPv6 First-hop security features are NOT wide spread in common virtual switches. Hyper-V is as of right now the only one, which supports at least few First-hop security features.
He concluded his talk by pointing out that there is room for improvement on First-hop security availability.
Check out the slides from this talk here
https://youtu.be/UO_vgSJP3sg?list=PL1eoQr97VfJni4_O1c3kBCCWwxu-6-lqy
“IPv6 Microsegmentation Done Right” talk created and given by Ivan Pepelnjak
In his talk Ivan will show solutions to fight against IPv6 layer-2 security challenges by building a layer-3-only IPv6 network.
He starts his talk with an overview of the IPv6 layer-2 security challenges and explains why they exist at all. In his opinion, the main problem lies on the assumption that one subnet is equal to one security zone. The corollary from this is, that intra-subnet communication is not secure, with the result that you have multiple first-hop vulnerabilities like RA spoofing, DHCPv6 spoofing and so on. He says, the root cause is that all LAN infrastructures we use today emulate 40-year-old thick coax cable. The traditional way to fix these is to add more kludges like RA guard, DHCPv6 guard and so on.
To solve these issues, he suggests removing layer-2 from the network. One way to reach this goal would be to replace the switch with a router. As a result, every host is in a dedicated /64 subnet and all layer-2 attacks are eliminated immediately. He says, the mobile operators do it in this way already and this works in huge networks. But in datacenters with VM Mobility this is a huge problem, because they result in IPv6 routing table explosion (most data center switches have very limited IPv6 forwarding tables). To illustrate how huge the problem is, he presents some numbers from common datacenter switches and especially how many IPv6 prefixes they support. It ranges from 1K IPv6 prefix (Juniper Networks EX4300 Ethernet Switch) to 8K IPv6 prefix (Arista Spline Switches).
In a large Datacenter this is unrealistic, replacing the switch with a router is a good idea but we can’t do it, he says. Then he shows some limited solutions like Private VLANs and came to the point that we still need something better.
As an appropriate solution he shows an Intra-Subnet (host route) layer-3 forwarding scenario where hosts are connected to layer-3 switches (routers) and share a /64 subnet (a /64 subnet spans multiple routers). To make it work host routes needed. Further IPv6 ND entries are used instead of IPv6 routing table entries. In this Scenario /64 routes are replaced with /128 routes, the trick is that most modern switches already supports /128 routes. They are called neighbor discovery entries. To show why this solution scaled better than the other stuff he shows the number of IPv6 ND entries compared to the IPv6 prefix entries. For example the Juniper Networks EX4300 Ethernet Switch supports 32K IPv6 ND entries but only 1K IPv6 prefixes. The reason for that is that datacenter switches uses variable-length prefixes for the IPv6 table entries and hash table lookup for ND entries, which is cheaper to do in hardware.
Finally, he shows an example, which is realized with Hyper-V Network Virtualization. Hyper-V Virtual switches are full-blown IPv6 router. The virtual machines are attached straight to the router, and there is no layer-2. As a result, all layer-2 security problems are gone. Further, he explains in detail how the virtual switches do ARP and ND proxying.
He finished his talk with following hint: vote with your wallet that’s the only thing the vendors care about.
Check out the slides here
Next up in our series more on IPv6 Security!
