Why is IPv6 layer-2 security so complex (and how to fix it)
After the excellent IPv6 security presentation Eric Vyncke had @ 9th Slovenian IPv6 summit someone asked me: “Why is IPv6 first-hop security so complex? It looks like the developers of IPv6 protocol stack tried to make users anonymous and made everyone’s life complex while doing that.”
Well, he was totally surprised by my answer: “The real reason IPv6 first-hop security is so complex is the total mess we made of L2/L3 boundary.”
In the ideal world…
Imagine a perfect world in which we use layer-2 connectivity only between the adjacent nodes (the way it was designed to be used) – the first switch your host is connected to is thus already a layer-3 switch. The security implications are staggering:
- A layer-3 switch (a device formerly known as a router) does not listen to Router Advertisements no RA spoofing;
- Neighbor discovery works across a layer-2 segment, not across layer-3 switches no ND spoofing;
- With every host being on a dedicate layer-2 segment, it’s impossible to reply to DHCPv6 requests (because a host doesn’t ever see requests from other hosts) no DHCPv6 spoofing;
- The layer-3 switch has authoritative forwarding information and can perform unicast Reverse Path Forwarding (uRPF) checks to verify source IPv6 addresses no IPv6 address spoofing.
Won’t that explode the routing tables?
Am I advocating using a /64 for every host? Do I look that stupid? It’s time to get creative and start using host routes:
- A single /64 prefix is advertised to all hosts in a “subnet”;
- The prefix is advertised as available for autoconfiguration (if you want to have autoconfiguration);
- If the layer-3 switch advertises the prefix as off-net, the hosts don’t even try to use Neighbor Discovery mechanism to find the MAC addresses of other hosts, but go straight to the layer-3 switch when they have to send a packet to someone else;
- The layer-3 switch creates a host route for every directly attached host. It can even reuse the exact same silicon used for ND entries these days (see also: that’s not the host route route you’re looking for).
- You could configure those host routes manually (in high-security environment), allow DHCPv6 proxy to do its job (interesting, this code is already available in Cisco IOS), or create a host route out of an DAD message if you decide to trust the hosts and the IPv6 autoconfiguration process.
- The switch may redistribute those host routes into whatever routing protocol it’s using (might be needed in multihomed environments) or advertise the /64 prefix into the rest of the network and let the more-specific-prefix forwarding take care of the rest.
Most of the above functionality is already available in layer-3 switches with reasonably good IPv6 support (read: not many of them), the only missing bit is the host route creation based on DAD messages (effectively reinventing Mobile ARP or Enterasys’ Host Routing).
Will we see a daring switch vendor who’ll break the ancient bad habits and start using the hardware they already have (most high-speed switches already have L3 hardware) in a slightly more creative way, or will Microsoft remain the only one with the guts to say “stop the layer-2 stupidities”? Being the pessimist that I am, I’d bet Microsoft will be very lonely in the IPv6 L3-only world for quite a while, but do prove me wrong in the comments!
Speaking of IPv6 security
I did an IPv6 security webinar with Eric Vyncke 18 months ago, and it’s as relevant as ever (particularly considering the dismal level of first-hop IPv6 security support in hardware- or virtual switches).
thanks for the, as always, enlightening post & creative ideas ;-)
Not sure though how the approach you laid out would solve any of the security problems First-Hop Sec (FHS) is supposed to solve. Advertising a prefix with the on-link flag cleared will indeed (initially, until receiving an ICMP redirect) force a host to communicate through its L3 gateway and hence create a "PVLAN illusion" from the host's perspective, as you rightfully described here http://blog.ipspace.net/2012/11/ipv6-on-link-determination-what-is-it.html.
Still, that host will happily process all rogue RA, ND, DHCPv6 messages received from other (potentially malicious) hosts on the same link. Preventing that is the main purpose of FHS, isn't it?
Or did I miss something in your above approach?
That said, may I further add that any mention of the terms "host routes" and "redistribution" in one sentence makes me shudder instantaneously?
have a great day,
so this would be the (as we called it at the time) "micro-segmentation" approach the two of us discussed somewhere back in 2013 (see also slide #11 of https://www.troopers.de/wp-content/uploads/2013/01/TROOPERS13-Design+Configuration_of_IPv6_Segments_with_High_Security_Requirements-Enno_Rey.pdf).
Don't mean to be pedantic here, but: in that case you don't even need clearing the on-link flag, given there's no neighbors anyway ;-)
Furthermore the above parts then seem a bit misleading to me, given you talk about "hosts" [plural] in a subnet/on the link.
@Eric: Yes. Finally ;)
ok, understood (the difference). Still in such a setup a host is still susceptible to all the on-link attacks (RA|ND|DHCPv6 spoofing) FHS is supposed to protect against, isn't it? Eric? Thoughts?
Great blog and love the "outside the box thinking". A few others (Ed, Andrew, Eric, Steve) and I have been kicking this around for a while now. We have looked at "most" larger organizations using a /48 for infrastructure and indeed assigning a /64 "per port, host, etc.) looking at summarizing an access switch with a /56 (256 /64's, ports, hosts, etc.). The thought being that these larger entities will get a /44 or /40. Wether the subnet has 2, 20, 200 or 2,000 nodes they are all in the same drop of water hitting the pool of 18.5 Quintillion. Some challenges that I have encountered with "proposing" this solution are: 1, Dual stack and how to handle the "legacy" protocol. 2, This is wired only (WiFi would take some considerable thought). 3, IP telephony devices.
In a campus environment, it would take some initial configs to get every port set up as an L3-link rather than a vlan-access port, but it's doable as long as the guys setting up the switches are the guys setting up the PCs.
With wireless, this will be difficult without a massive amount of vendor support.
In server environments, specifically for standalones/rackmounts, this is similar to the campus challenge: the server and switch ports will need to be a coordinated effort.
In virtualized environments, this could all be API-driven, but I don't think there is any automated software at the moment capable of checking to see what /127s have been deployed (or what the next available is).
Thoughts? The automation and self-provisioning is critical... the effort and related costs to doing this manually are not appealing. But if someone has a way to automate it, I'd love to see this as the standard.
Wireless might be a nightmare, but it's a PVLAN by design (if I understood it correctly), so you're good if you set up AP as IPv6 router.
- plus add SAVI: