In the first part of this series we tried to identify which risks related to network-related threats actually change when IPv6 gets deployed and hence which ones to take care of in a prioritized manner (as opposed to those which one might be tempted to [initially] disregard with a “has been there in IPv4 already and we did not address it then, why now?” stance). Let’s assume we went through this step and, for those most relevant risks we identified, we want to come up with infrastructure level controls first, before tackling controls to be deployed on the host level (as in many organizations the sysowners of “hosts” like servers in datacenters tend to expect “the network/infrastructure guys to provide the 1st layer of defense against threats”, in particular once those originate from an apparent network layer protocol, that is IPv6).
Usually there’s three main areas of infrastructure level security controls to think of for an IPv6 network:
- Network isolation on the routing layer
- IPv6 specific filtering of network traffic
- First Hop Security features implemented on the switching infrastructure.
In this post I’ll focus on the first one of these which encompasses potential measures in the space of “routing reachability & visibility”. When thinking about the security implications of a network with GUAs only (which actually constitutes the addressing strategy most of our customers opt for, for various reasons outside the scope of this post), quite a few people come up with a filtering-oriented mindset like “let’s solve all this by appropriate rulesets on our firewalls” which in turn has its own set of operational issues (some old dogs from large environments even consider the term “appropriate rulesets” as an oxymoron…). Turns out that our toolbox of controls contains some approaches to consider before even touching the firewalls.
Selective Route Propagation
As stated, the planned use of only global unicast addresses can implicate that individual segments within a corporate network become reachable from untrusted networks. This could be avoided once it’s possible to identify network segments that are to be made reachable from external entities and subsequently only propagate those routing-wise. Here we have to differentiate between mainly two possible implementations:
- Only those identified segments are announced via BGP to the respective uplink providers. In general it’s preferable to propagate short prefixes (/40 or shorter) due to strict prefix filtering some providers/carriers (still) perform. If should be clarified in advance, if the uplink providers will accept such routes from the organization in question (and, of course, proper route6 objects have to be created in the RIPE database). At the moment (December 2015) more than 45% of all IPv6 routes in the default-free zone (DFZ) have a prefix length of /48 (the majority of them without a covering aggregate), so that the propagation of /40s (or shorter prefixes) can be considered doable.
- Alternatively, the organizations’s full aggregate prefix can be propagated to the uplink providers. This aggregate (route) will then be directed in full to a null-route at the border gateways of the network. At the same time more specific routes for the identified (to-be-reachable) segments will be configured in direction of the corporate network. Evidently those will be more specific than the “global null-route” which subsequently results in reachability of only those selected prefixes from external networks. With this approach the problem of strict filtering is avoided and the propagation of new segments might become easier (than in the 1st approach laid out above) as there is no operational overhead/e.g. tickets with uplink providers involved here (e.g. no route filters on their side to remove/take care of). Because of the higher flexibility we usually recommend this variant once a “selective route propagation” strategy is chosen.
Null-Routing of Selected Prefixes
Instead of, or (in complex networks with several intersection points) even in addition to, the above approach (selective route propagation) network segments of the corporate network can be identified that are supposed to never be reachable from the public Internet or even all external networks (incl. business partners). Packets destined to these network segments can then be discarded at the network perimeter (connections to the Internet or business partners) by means of null-routing. Due to the potential operational effort for this technique (e.g. more difficult troubleshooting as people might not be aware there’s an extra layer dropping packets in addition to firewall rules) such an approach should be applied quite sparsely (small overall number of such [null-] routes). On the other hand this can constitute a very effective way of protecting networks segments with very high protection needs (loopback addresses of devices, R&D networks etc.).
In general both approaches laid out above must be comprehensively thought through in a specific environment (and, ofc, this has to be aligned with the IPv6 address plan). Choosing the wrong strategy today might lead to significant effort tomorrow. In one customer environment we just recently had to heavily modify the address plan created (in several iterations) 12 months ago as it incorporated some of those principles, but now that organization plans to use Office 365 which in turn means that large (“internal”) parts of the corporate network have to communicate with external entities in a mostly direct way (read: without proxies)…
Reduced Hop Limit within Specific Segments
Configuring (ideally by means of router advertisements) a reduced hop limit of systems would actually mean that traffic originating from those systems has a limited “outbound reach”. So while systems/segments might be reachable from untrusted networks in an inbound direction, their return traffic will not (be able to) leave the corporate network. Such an approach can be applied to networks/segments within the organization which are not supposed to communicate with systems outside the organization such as management addresses/networks or research & development areas. As of December 2015 we consider a hop limit of at maximum seven (7) as sufficient to traverse corporate networks (at least those we know) if needed but at the same time providing some protection, given the average Internet path length of IPv6 packets can be assumed to be around ten (10) hops in late 2015 (this source provides some numbers from 2013, but measurements are on [average] AS path length) and is considered to rise (slowly) over time due to increasing network complexity.
This reduced hop limit can be provided by ICMPv6 router advertisements which further facilitates the deployment of the approach. It should be kept in mind though that this will not be suited to prevent data exfiltration once an attacker has actually compromised a system (given he might be able to increase the current hop limit of a system to allow further outbound reach).
At this point I’d like to thank Andrew Yourtchenko for providing the initial idea. We know some organizations actually reviewing the approach for very specific high-security networks, but it might be advisable to gain operational experience first before deploying/considering this on a large scale.
Again, thanks! for reading so far ;-); in the next part I will discuss IPv6 specific traffic filtering.
Stay tuned and have a great day,
Enno