Week 2 of my attempt to pick a random topic and just start writing. This week to default route to the internet or not to default route? That is the question.
This can be a hotly debated topic in some circles. In other circles it is fairly straightforward answer. Within a large enterprise environment there are several potential use cases for advertising a default route throughout the network. The question really find myself debating is the merits of allowing a default route to the internet vs the alternative of using proxies to intermediate the traffic. Is the risk worth the convenience?
What risk you might ask? I am not going to cover in detail so if you want some more background see the links below under “Routing best practice and design”. Entire forests have been decimated and truck loads of ink have been used in network text books to discuss, detail, advise and warn of the pros and cons of route summarization. Many people have made careers for themselves specialize in building large scale routing environments. Why is this so? There have been decades of work done to strike a balance between resource utilization and information summarization that are necessary in large scale environments.
Why is this so? It is simple, the lowest common detonator of hardware in service on the network is many years behind the needs of the network today, this is especially so in provider backbone networks. Routing tables continue to grow, security threat vectors continue to expand and the hardware required to manage these sorts of requirement is more and more stressed as they age. In years past it was absolutely critical to protect resource utilization through optimization of routing information. This is how annoying configuration like EIGRP auto summary get introduced into platforms and protocols.
On the other hand summarization has it’s trade-offs of course. In short, any time you summarize you lose information somewhere. You will notice that there are many references in the documents below to best practice in order to prevent issues from the resulting loss of information from summarization, most predominately routing loops.
This brings me to my first point: a default route is simply the ultimate route summarization and as such much downstream information is hidden. As with all summarization there are potential issues with using a default route in an Enterprise environment and exponential more issues when this default route leads to the wild west of the interweb. For that reason this is why I call relying on default route and heavy summarization an implicit routing design. Let us name a few of the potential issues with this approach:
- Higher probability of routing loops and black holes.
- Decreased control and visibility of internet traffic:
- Ability for malware infected machines to ‘call home’ with little to no safeguard. “Firewalls”, you say? Ha, good one.
- Ability to use backdoor internet proxies.
- Potential for new and unknown protocols to carry malicious or illegal traffic (torrent morphing for example).
There is an alternative that many enterprises have moved towards. This approach is currently more prevalent in European countries as far as I can ascertain but is gaining traction in the Americas. I call it the explicit routing design. This is a routing design in which every prefix is explicitly defined and route information is passed end-to-end with as little modification or loss of information as possible. In the larger context of enterprise networks and namely the enterprise edge (any handoff between enterprise managed assets and externally managed devices) this routing model relies on proxies to act as a go between for any communication between the outside world and the internal enterprise environment.
The reason I call this an explicit routing design is because every destination is explicitly known and every invalid prefix is dropped upon entry into the network. The drawbacks to this approach are:
- Higher administrative overhead to maintain edge proxy environment.
- Higher operation discipline to maintain more specific and larger routing tables.
But wait! Didn’t we just say that aging network hardware has trouble keeping up with the routing table and feature sprawl required? In 99% of enterprise environments, the hardware that has been sold in the past 5 years is far and away more capable from a memory and resource perspective than an non-summarized enterprise routing table will require. The lowest common denominator here is hardware that is capable of supporting the rich feature sets required in multi-faceted enterprise environments. In short, this generally is not an issue in an enterprise with a fraction of the route table size that providers manage.
Personally, I feel that there is little to no reason for enterprises to continue to permit internal hosts (users and servers alike) to communicate uninhibited to hosts on the internet. The explicit proxy model provides significantly more opportunity to inspect and police traffic. The key difference is that users following a default route can initiate direct layer 4 sessions to external hosts, which gives them the opportunity to encrypt data and hide nefarious communication. On the other hand it is much more difficult (albeit far from impossible) for an internal host to hide information from a proxy server since the proxy doesn’t allow a direct session between both parties. As a mediator and translator as it were, it has the ability (in theory) to inspect both sides of the communication and have much deeper visibility into communication. This is especially true when you enable SSL/TLS inspection functionality. Yes, it is still possible to build an encrypted web-session tunneled inside of another web session but that requires some effort. You have a much higher probability of detected and preventing zero day malware infected hosts from ‘calling home’ for example.
Yes, this explicit routing model requires more effort and discipline than an implicit routing model. On the other hand, building resilient and secure technology infrastructure is on ongoing exercise in effort and discipline is it not?
Routing best practice and design: