Security Implications of Using IPv6 GUAs Only

When planning for IPv6 addressing, many organizations – rightfully & wisely – decide to go with global unicast addresses (GUAs) only (hence not to use unique local addresses/ULAs as of RFC 4193 at all), in order to avoid address selection hell or just for simplicity & consistency reasons. This post discusses security implications and complementary security controls of such an approach.

In their IPv4 networks, most of these organizations currently use RFC 1918 space, combined with NAT for specific connections or use cases. Ideally NAT is only in place “where strictly needed”, in practice it’s often used as a kludge to conceal of all types of bad network design or debatable application architectures. I won’t enter the “is NAT a security control?” debate here, one statement might be allowed though: as of section 3 (“Because private addresses have no global meaning, routing information about private networks shall not be propagated on inter-enterprise links, and packets with private source or destination addresses should not be forwarded across such links.”) RFC 1918 space is usually not reachable from the Internet. So using such address space for internal networks is a nice example of the isolation principle as of the “Seven Sisters” approach we like to use. Now, bringing NAT into these networks enables connections (usually between trusted and untrusted networks) which simply would not be possible without it [NAT], so this actually breaks the isolation property. Question: how can one ever call something that increases the number of possible interactions between assets and potential attack originators a ‘security control’?!

Back to IPv6: going with a “GUAs only within the whole corporate network” approach could constitute a loss of that isolation property as well, and hence this must be reflected upon from a security perspective.

Let’s assume there’s some parts of your organization’s network that you want never to be reachable from untrusted networks/the Internet (these can industrial control systems, facility mgmt/building automation related stuff or just the address space used for management/infrastructure purposes). Let’s further assume you can identify those parts with a sufficient degree of certainty as for the must-not-be-reachable-from-Internet property. I mean, we all know that, at times, business comes up with all types of strange ideas… 😉
In fact to reduce the operational footprint of all the approaches laid out below it’s quite helpful if you can (try to) identify those parts during the address planning phase and incorporate this accordingly.
This could be done “on the VRF level” (provided there is one) or on the “service” hierarchy level found in a number of address plans. For example looking at the first table discussed in the 3rd post of the address planning series), there on the /52 level one could make the first bit (= the 49th bit overall) a distinguisher for the must-not-be-reachable-from-Internet property, e.g. use
2001:db8:55de:0::/52 – 2001:db8:55de:7::/52 for networks/types of services that potentially have connections to the outside world, whereas
2001:db8:55de:8::/52 – 2001:db8:55de:F::/52 are used for facility mgmt, industrial control systems etc.

This will greatly facilitate treating those groups of systems differently, on the filtering and/or routing level.

Now, how can one provide (additional) security for those networks of the latter type? Mainly there’s three approaches:

• Traffic filtering
• Selective route announcements
• Null routing specific segments

Let’s have a closer look at those in the following.

Traffic Filtering

That’s probably the first thing to come to mind in many environments and it might already be in place in a similar way in their IPv4 networks. Still it should be noted that this implements, well, the filtering principle 😉 as of the 7 Sisters (isolation = “building walls”, filtering = “drilling doors into the walls & putting security guards at them”), while we’re striving to compensate for “losses in the area of the isolation principle”. Furthermore we should keep in mind that filtering is prone to human error in the course of rule creation/maintenance (actives failure as of James Reason’s model of accidents) and/or weak business processes (latent failures as of James Reason) and filtering might be operationally expensive.

Selective Route Announcements

You might ask: “why not just refrain from announcing the full IPv6 address space the organization has been allocated/assigned and instead only announce a selected part of it, say some /48s used for DMZ type of networks?” and actually some documents discuss/suggest such an approach (e.g. the German BSI’s “Leitfaden für eine sichere IPv6-Netzwerkarchitektur” mentions it on page 17).
At the first glance this seems an obvious approach (“hide our internal networks from global routing visibility”), however there’s one (not so) small problem with it.
Let’s assume your organization is located in Europe and hence address space from RIPE is used. This can either be so-called PI space which is usually a /48 within the 2001:678::/29 prefix. Splitting this it into smaller pieces for selective route propagation means that those will have longer prefixes than /48 which as of “common consensus” has only small chances of getting routed/propagated on the global level.
Most organizations we work with have chosen another path anyway: they have become LIR and subsequently received an allocation of a /32 (or /29 depending on the point of time they underwent the procedure) which is “PA space” from the 2a00::/12 range. Splitting such an allocation would technically work (e.g. by creating specific /48s for the DMZ segments), but then unfortunately all the implications of strict filtering might kick in, inhibiting the organization to annouce the /48s without a covering aggregate, which in turn – of course – undermines the whole purpose of the approach…
See the second part of the address planning series or our presentation at the recent RIPE meeting for a more detailed discussion on this. Suffice to say we’ve seen this exact thing happen in real life so we recommend being very cautious with this approach.

Null-routing of must-not-be-reachable-from-Internet Segments at Network Borders

This is another option which serves a similar purpose as the previous option just discussed (selective route announcements), but works slightly different. Announce the full aggregate (only if needed, ofc) but implement null routes for the must-not-be-reachable-from-Internet segments on the routers connecting your organization to “the outside world”, like (for the example introduced above)

Router(config)# ipv6 route 2001:db8:55de:8::/53 null0

Some things to be noted in addition:

• Connections to “the outside world” can, and should, include connections to business partners (remember: “the supply chain is the new perimeter”).
• This only works in a “clean and easy” way if there’s a clear separation between “external” and “internal” routing. Once both things happen on the same devices (e.g. in MPLS networks involving customers/business partners) one must be extra careful with this approach.
• From our perspective such null-routing brings a nice additional layer of security (defense in depth…), just in case “the filtering fails”, but this means that any changes of the “starting from today, for whatever reason we actually need external access to $SEGMENT” type now potentially affect two departments/groups (the firewall guys responsible for filtering and the infrastructure guys involved with routing). Which – depending on the maturity of change management processes in $ORGANIZATION – can be good thing or not ;-).

Once you keep this stuff in mind, null-routing might be an elegant way of (somewhat) implementing the isolation approach in IPv6 networks. That said, I’d like to re-emphasize two key takeaways from the above discussion:

• Security on the network infrastructure layer is not just filtering.
• Think hard about potential security models and implications when designing an IPv6 address plan.

As always we’re happy to receive feedback of any type from your experience/way of doing things.
Have a good one

Enno