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).

21 comments:

  1. Hi Ivan,
    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,

    Enno
    Replies
    1. The fix proposed is to only have one host per link, and have the hardware currently called the "switch" become an IPv6 router.
    2. Exactly. Get rid of L2 completely. It adds no value.
    3. Hi Ivan,

      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.
      Best

      Enno
    4. On the specific case of access network (i.e. to hosts), it is offering even more benefits: for example, say bye bye to spanning tree ;-)
    5. @Enno: It's different. Microsegmentation in your example used /64 per host, I propose using /128 per host while still advertising the same /64 to all hosts (that's why you have to turn off the on-link flag).

      @Eric: Yes. Finally ;)
    6. Ivan,
      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?
      best
      Enno
    7. No. The "link" is between the host and the adjacent router which terminates all RA|ND|DHCPv6 messages.
  2. There will still be the need for a transport network for IPv6. Normally this would be the data link layer a.k.a. L2. The value of L2 is to provide the link connectivity. Getting rid of L2 means getting rid of connectivity.
    Replies
    1. You're absolutely correct, but there's no real need to stretch L2 across more than two adjacent devices.
    2. I would say that it depends on the environment. Overlay networks make this even more complex. And then there is Metro and Carrier Ethernet ;-)
  3. Very good idea, but there are some problems. There is a lot of network equipment, unable to route packets in hardware using routes with prefix longer than /64. And in general this is possible only in IPv6-only networks, since those with enough IPv4 addresses to spare at least /30 for every physical link are extremely scarce.
    Replies
    1. Not true. Every IPv6-capable switch can route packets to /128s - they use that functionality to implement ND cache, as I explained in the blog post and in more details in the linked document.
    2. OK, true for /128s, but there are still troubles with prefixes /65-/127. And we need at least /127 for a link. Then there are also hosts with multiple IPs.
  4. Ivan,
    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.
    Replies
    1. What is so special about IP telephony devices (wired ones)? Are you talking about connecting computers to the network through IP phones?
    2. Yes, single wire desktop deployment with IP tel
  5. I could be wrong, but Amazon has already implement something similar to this for their v6 AWS
  6. I love the out-of-the-box approach, and I see a lot of benefits. In the extreme HPC world, they do this with IPv4 already. coupled with TCP/IP stack offload/acceleration, it's extremely fast.

    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.

    CWB
    Replies
    1. Virtualized environments: Hyper-V does exactly what I described, as does Contrail for OpenStack/Linux environments (IPv4 only at the moment), which means we have two out of three covered.

      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.
  7. He also had some similar ideas for traffic isolation:

    - http://h30499.www3.hp.com/t5/Comware-Based/Port-Security-on-A5500/m-p/6502816#M5517

    - plus add SAVI:
    http://www.ietf.org/proceedings/76/slides/savi-7.pdf
    http://www.ietf.org/proceedings/78/slides/savi-4.pdf
    http://www.ietf.org/proceedings/80/slides/savi-2.pdf
Add comment
Sidebar