The Scary World Beyond the Network Edge

There’s an old Gahan Wilson cartoon in which a car is stopped on a road that has suddenly ended at the edge of a cliff stretching out to the horizon. Two guys are out of the car, one on his hands and knees peering over the edge. The other, holding a map, says, “That’s funny, the map ends here too.”

You should look at the edge of your administrative domain as the edge of a cliff, an unsafe and scary place for any of the nice things happily running in your network.

How do you define the edge of your administrative domain? It’s not always as clear-cut as an autonomous system edge. Here’s a simple guideline to follow: If the router you are connecting to is not under your control, it is not in your administrative domain and therefore IS NOT TO BE TRUSTED.

Sorry, I hate it when people shout and I hate it when people type in capital letters.

But I’m provoked to capitalization by the number of times I’ve seen networks in which an IGP is extended precariously past the edge. IGPs (OSPF, EIGRP, IS-IS if you can, RIP if you must) are designed with the assumption that the neighbors they peer with are trusted, and therefore that the information the neighbors send is trusted. The protocols are designed for performance and easy information exchange.

If you are not in control of the neighboring router, you have no guarantee that the router is going to send you good information, you have no guarantee that the administrator of the neighboring domain is competent or even benign, and hence the assumptions of your IGP are no good.

So here’s a principle I highly recommend (and I promise not to capitalize any words this time):

Never, ever allow an IGP session with a router that you do not control.

You might think that your ISP, your enterprise partner, your customer, or that other IT division of your company is perfectly trustworthy, but if you do not control the router do not let your IGP talk to it.

The route information you send to, and most especially the route information you receive from, an untrusted neighbor should be carefully and tightly controlled. The best and most secure way to do that is to exchange no information at all: Use static routes.

If you must have dynamic routing, because (1) there are multiple external connections and (2) the same destinations are reachable over more than one of those external connections, and (3) more control over the route choice than just the closest entry or exit point is required, then use EBGP. That’s what it’s designed for, and it gives you lots of policy control.

By the way, this principle of no IGP on external links goes beyond external peering: Don’t run your IGP in passive mode on your external links, either. Many network operators do this so they have management control (ping and the such) of their external-facing interfaces. This runs the risk of forgetting the “passive” statement on an edge interface, which in turn opens the risk of an IGP attack or unintended peering session—rare, but it can and does happen. If you need the external link’s subnet to be “visible” internally, use a static route and redistribute it into your IGP at the edge, or put it in IBGP if you happen to be running that.

Following this “no IGP beyond the edge” principle does require a little extra operational effort, like any strong security policy, but the risk reduction is well worth it.