General Best Practices and Route Summarization
The basic best practices for IP addressing should be familiar to you. At a high level in your design, you first must decide whether the IP address of the user on your network will have any significance from a security standpoint. For example, if you are an organization with three sites, are you just going to assig a subnet to each of the three sites, even though there are individuals at each site with different levels o security access?
This approach is fine if your security system depends mostly on application layer security controls (AAA, intrusion detection). I've seen many designs that do this successfully, but it does take away a simple control that many find useful: L3 access control. Here, users are put into group-specific subnets that provide an additional layer of access control between the user and the resources. You can compare the two approaches in Figures 6-11 and 6-12.
Figure 6-11. Application Security Design
Figure 6-11. Application Security Design
Figure 6-12. Application Security Plus L3 ACL Design
As you can see in Figure 6-11, this simplified diagram shows three sites, each with a /23 subnet of the : network. There are two main groups at these three sites, marketing and R&D. In this design, the servei and PCs for each of these groups share the same site-specific subnet. This means any security controls will be unable to take into account the IP address of the system attempting access.
In Figure 6-12, the same /23 subnet exists per site, but it has been further divided into two /24 subnets one for each organization. This allows intersubnet filtering at the routed connection at each site. This filtering could be used in sites B and C to prevent the R&D and marketing departments from accessing each other's PCs and at the data center to ensure that only marketing PCs can access marketing server and likewise for the R&D department.
This sort of filtering is referred to as role-based subnetting throughout the rest of this book.
Although the benefits of the approach shown in Figure 6-12 are pretty clear, this kind of design gets exponentially more difficult as the number of sites of different groups in an organization increase. Wireless features and the wired mobility of the workforce also affect the feasibility of this design. Technologies such as 802.1x (see Chapter 9) can make this easier but by no means solve all the problems.
Like any of the discussions in this book, every design decision should come back to the requirements of your security policy.
I have seen some designs that attempt to trunk VLANs throughout the sites of an organization. For example, consider if the design in Figure 6-12 had only two subnets, one for R&D and another for marketing. These subnets would need to exist at all three sites. The principal problem with this design is the need to trunk the VLANs at L2 throughout the organization. This increases the dependence on STP and could make the design more difficult to troubleshoot.
Route summarization is always something that sounds easy when you first design a network and gets harder and harder as the network goes into operation. The basic idea is to keep your subnet allocations contiguous per site so that your core routers need the smallest amount of routes in their tables to properly forward traffic. In addition to reducing the number of routes on your routers, route summarization also makes a network far easier to troubleshoot. In Figure 6-12, you can see a very simple example of route summarization. Sites B and C each have two /24 subnets, but they are contiguously addressed so they can be represented as one /23 subnet. These summarizations also help when writing ACLs since a large number of subnets can be identified with a single summarized ACL entr
Continue reading here: Rfc 1918
Was this article helpful?