Networks, like the enterprises they support, evolve over time. It is extremely rare that one has the opportunity to re-evaluate the underlying assumptions behind a logical network design and the IP address schema, and with the advantage of hindsight, make course corrections that can provide flexibility and accommodate the security controls needed now and into the future. Such an opportunity may only come along once a decade or more. Most corporate enterprises did not connect to the Internet until the late 1990’s or early 2000’s, and their experience with TCP/IP was limited, but many are still living with the choices made long ago. If you could re-design your enterprise network IP address space today, what would you change? The example that follows provides one such way for a large private network. Of course you have to have a driver for undertaking such a project and the creation of security zones is a good one!
CIDR, NAT, and RFC1918
In 1993, classless inter-domain routing (CIDR) was proposed as a short-term solution to address two problems — very large router tables in the Internet core and scalability issues threatening IP address exhaustion. However, the largest impact on logical network design arguably came with network address translation (NAT). NAT is not a perfect solution, undermining end-to-end transparency that was a tenant of the original Internet architecture. It can create difficulties which we will not address here. Also, NAT is not a security mechanism, nor was it ever intended to be one. However, there’s no arguing that NAT is here to stay — at least until the day that IPv6 becomes ubiquitous — and IPv4 address space certainly would have been exhausted long ago without it. NAT was already popular when most corporate enterprises connected to the Internet, and so, like it or not, RFC1918 private address space was widely deployed. For the purposes of the following examples, we’ll use private addresses; you may adapt as needed.
Partitioning by Function
Partitioning IP address space should serve a purpose, or optimize around some necessary function. There are two important functions to consider:
Routing optimization occurs through summarization. If all the subnets in a network can be summarized by some common feature, then extraneous routing table entries are avoided. Given the advance in hardware (e.g., ASICs), this may not be as much of a concern as previously, and even less so in an enterprise environment, still, a logical coalescing of IP addresses can reduce human errors.
The ability to cover infrastructure components having similar features with one logical subnet can also make applying security controls easier and more efficient. When firewalls or other layer 3 access controls are applied within a network, minimizing the rule sets for controlling traffic patterns reduces complexity, thereby improving performance, lessening the likelihood of human error in maintenance efforts, and making efficient use of human resources. When most corporate networks were built, security concerns were not as grave as they are now. Most large enterprise networks are unfortunately fairly flat — not in terms of broadcast domains, but in terms of the ability to segment traffic. They often exhibit the ‘hard shell, but soft gooey inside’ characteristic that makes internal network security extremely difficult.
Optimization: Only Along One ‘Axis’
IP address space is linear, and although one can make use of more than one axis (i.e., an organizing feature), optimization is only possible along one of them. This is perhaps the most important decision one must make when thinking about the layout of IP address space. While there may be others, the following seem the most logical:
- Risk rating
- Function (e.g., architecture tier)
Applications or network services may be classified according to their importance to the proper functioning of the enterprise. Large enterprises all employ risk management functions to ensure the proper coordination and use of resources to address risks and realize opportunities. Often risks are classified as simply as high, medium and low. If the classification is applied well, and meaningful controls can be applied, this may be a meaningful feature for partitioning IP address space. And… for creating security zones!
Function, in terms of application architecture, can be something as simple as presentation (e.g., web servers), business logic (e.g., application servers), and data (e.g., database servers).
Location may be important for defining areas of a network.
The Binomial Coefficient of Networks
(or ‘n choose 1’)
For our example, we’ll use location as the outermost function, but not necessarily how you might think, and not as the primary axis for organization. More on location later. First, let’s examine a visual example of how choosing the primary axis can affect routing and security. Look at the following diagram, which organizes IP address space by risk rating (represented by color), but further subdividing by function (represented by the numbers 1 through 4):
All infrastructure components of the same risk rating can be covered by a single subnet. We can still address all components by function, but these network blocks are non-adjacent and must be made into a collection (e.g., a defined network object). Both routing and security are optimized around risk rating; addressing network components by function is still possible, but even with the indirection of defining ‘network objects,’ all of these smaller subnets will be broken out within a layer 3 device when referenced in ACLs or firewall rules, for example.
Now look at the next diagram, which organizes IP address space by function (represented by the numbers 1 through 4), but further subdividing by risk rating (represented by the color):
All infrastructure components of the same function (or application architecture tier) can be covered by a single subnet. As before, we can still address all components by risk rating, but these network blocks are non-adjacent and must be made into a collection (e.g., a defined network object). Both routing and security are optimized around function.
Well, is a hybrid approach possible? Sure, but it will either come with small subnets or by using twice as much IP address space. They is not likely a concern, given the amount of private IP address space available, however, this approach is probably only valuable during a long transition, rather than in a steady state.
You will have noticed that both risk and function allowed for four distinct categories, when we’ve only ever mentioned three. This leaves room for the all important ‘other’ category. Now let’s turn our attention back to location as an organizing feature!
Location, Location, Location!
In a very large network, it is important to efficiently route traffic and also to be able to easily identify nodes as belonging to one place or another. I always like to build visual cues into IP addresses to assist with this. On a very large scale, I’m even willing to do this at the expense of some routing efficiency. If all nodes can fit into two /16 networks, then no efficiency is lost (if the first uses an even-numbered second octet and the next is one greater, e.g., 10.10/15 covers both 10.10/16 and 10.11/16), but otherwise there may be additional routing table entries. You can use a single /16 network for each location, or an entire range. Choose what works best for you!
This approach can accommodate 24 different locations (or 25 if you use the implicit leading zero), or could be modified for many more if each location can use a single /16. Of course, if your network is much smaller, you can collapse everything into a smaller address space.
NOTE: If route optimization is of prime importance to you then you would not use this approach, but instead opt for a summarized block of addresses on a clean binary boundary for the second octet rather than using decimal digits in the IP address octets.
In the examples that follow, you’ll notice that many times /23 netblocks are used rather than the typical /24. Why, you might ask? If you have fewer than 254 layer 3 devices in a location, you can assign each of them a unique fourth octet in the IP address, and then simply re-use that octet in one half of a /23. For example, reserve the lower half for your network devices, and use the upper half for hosts. Network engineers then always know to which switch or router they are connected. This is especially useful in a “layer 3 everywhere” approach, but if you use layer 2 switches at the edges of your network, then you will probably shrink these to the more common /24 network block. Again, use what works best for you!
Here are two sample subdivisions: one organized by risk first (as in the diagram above) , and a second diagram organized by functional types. Either way, larger blocks can be subdivided into smaller ones to minimize the small of broadcast domains and/or to assign to different distribution layer routers (i.e., optimizing for security rather than internal routing, at the distribution layer at least).
Why all the fuss?
Why bother with all of this? Having an efficient, well-organized IP address schema will make it possible to develop security zones that can be efficiently referenced in router ACLs, firewall rules, SIEM rulesets, and network models of all kinds. Without this level of organization, developing and maintaining good models for security will be very difficult. However, a good foundation (in the form of cleanly organized IP address space) will serve you well in many areas. Security zones will be discussed at length in an upcoming post — stay tuned!
Physical design choices can strongly influence your enterprise IP address schema. Also, your needs may allow to slide network masks one way or another, but the basic ideas are the same. Use some, all, or none of them! YMMV.