A Security-Oriented Approach to IP Addressing


Contents

Introduction
A New Addressing Methodology
Benefits of a Role-Based Address Assignment Methodology
Development of an Addressing Methodology
Deployment Considerations




Introduction

Using IP addresses as a form of identification is a common practice, and for good reason. IP address use in ACLs and routing is commonplace. This paper will show that with a little more consideration, addresses can also be used as a management tool, even in scenarios where an IP address is load balanced to many hosts.

A New Addressing Methodology

The application of IP addressing purely on a topographic basis does not create an environment in which concise security policies are easily created. This fact, in conjunction with the IP address dependencies of many security features, can lead to overly complex device configurations. The assignment of IP addressing using a role-based methodology is the most effective way to reduce this complexity. This methodology will allow for the simplification of many network device configurations as well as the creation of succinct ACLs that will be easier to add and maintain. With a role-based addressing methodology, interface IP addresses are assigned from pools dedicated to specific device roles. For example, loopback addresses may be allocated from 10.255.255.0/24, while addresses that support remote access networks are allocated from 10.200.0.0/16.

After administrators employ a role-based address assignment, there will be new avenues through which they can implement additional security controls. For example, if administrators are sure that all addresses in the subnet 10.255.255.0/24 represent loopback interfaces of core network devices, they can safely leverage that information throughout the network. Additionally, they can fortify that assumption using supporting technologies. For example, the infrastructure ACL implementation could drop packets that contain a source address of 10.255.255.99 when these packets are entering the network because there is no valid reason for that source to exist outside the network. More information about infrastructure ACLs is available at Protecting Your Core: Infrastructure Protection Access Control Lists.

Benefits of a Role-Based Address Assignment Methodology

Administrators can leverage efficiencies in security controls throughout the network after IP addresses have been assigned using a role-based methodology. These efficiencies will not only allow for more succinct configurations, but will also remove the error-prone nature of "one-off" manual configurations.

  • Access Control Lists: The configuration of ACLs throughout the network will be simplified through the use of a role-based addressing methodology because roles can be represented using a single contiguous address space. This efficiency is applicable to the configuration of infrastructure and transit ACLs as well as ACLs that are configured for other functionality, such as access classes and IPsec.
  • Control Plane Policing and Protection: The configuration of Control Plane Policing (CoPP) and Control Plane Protection (CPPr) are inherently ACL dependent. For this reason, grouping like devices into a contiguous address space will reduce the effort required to implement, maintain, and subsequently troubleshoot complete deployments of CoPP and CPPr.
  • Static Management Workstation Definition: Many management protocols suggest that administrative workstations be statically defined in the configuration of a network device. This stipulation includes SNMP and SSH connections to network devices as well as HTTPS connections to many applications. Allocating network management and Network Operations Center (NOC) subnets contiguously will streamline these configurations.

Note: Although a contiguous subnet mask—a mask in which there is exactly one group of ones and one group of zeros—is typically required by network devices, access control entries (ACEs) do not carry this restriction. When administrators define security controls with ACLs, it may be possible to leverage this fact. For example, hypothetical NOC subnets of 10.100.100.0/24 and 10.101.100.0/24 can be represented by the ACE permit ip 10.100.100.0 0.1.0.255 any. This technique should not be used extensively in an addressing methodology; however, it is an available tool to address special cases.

Beyond the traditional placement of security controls, grouping devices in this manner will create new applications for IP address–based security features. For example, if the subnets that house IP phones and their supporting servers have been allocated from a single, contiguous block of IP address space, it may be possible to implement more stringent controls on traffic to and from those segments. Taking this a step further, implementation of an ACL similar to the one in the following example may become feasible.

!
ip access-list extended ACL-UC-IN/OUT
 remark *** 172.16/16 dedicated to Unified Communications ***
 permit ip 172.16.0.0 0.0.255.255 172.16.0.0 0.0.255.255
 !
interface Vlan <VOICE-VLAN>
 ip access-group ACL-UC-IN/OUT in
 ip access-group ACL-UC-IN/OUT out
!

Although the preceding ACL is meant to be illustrative and is not comprehensive, this type of VLAN is an area in which improved security is often welcomed because voice VLANs typically bypass the security controls that are applied to data segments (such as 802.1x or Network Admission Control).

Development of an Addressing Methodology

Administrators must devise an interface and device grouping methodology as a first step. A security-oriented methodology should aim to minimize the configuration complexity of network devices and applications. If standard device or interface naming has been deployed in an organization, administrators can examine those structures to identify parallels that should be carried into the addressing methodology.

The following list provides a starting point for an organization-specific grouping scheme. It is important to note that a single device will likely be in more than one group; a particular IP address, and not the entire device, is included in the group.

  • Core devices: Loopback interfaces
  • Core interfaces: Transit interfaces
  • Edge interfaces: Internal
  • Edge interfaces: External (such as extranet connections)
  • Access interfaces: Dial and VPN termination
  • Service-based groupings (such as Unified Communications servers)
  • Network Operations Center subnets and interfaces
  • Data center–specific networks (such as storage or backup networks)

After the groups have been defined and vetted, addressing must be assigned to each group of devices and interfaces. This step may be made easier through the use of addresses set aside for private use according to RFC 1918. One common approach that can make it easier to associate an IP address to its role is to use similar but obviously different addresses for roles that are different but somehow related. For example, administrators could assign the subnet 172.16.1.0/24 to the data network at a remote location and 10.16.1.0/24 to the phones at the same location.

Administrators can use any proven re-addressing strategy after completing the address assignment methodology; however, a pure network re-addressing exercise is very difficult. A more appropriate approach would be to implement this strategy for deployments of new networks or IPv6, or to incorporate the re-addressing into the phased reprovisioning of the network.

Deployment Considerations

When any change is made to a network, it is important to understand its ramifications. The following questions should be answered prior to pursuing a security-oriented addressing methodology.

  • Does sufficient IP address space exist?
  • Will the new addressing impact the routing protocol used in the network?
  • Will existing route summarization be adversely affected?
  • What will happen to packets sent to nonexistent destinations, specifically at transitions into portions of the network without a default route?
  • If sinkholes have been deployed, how will they be affected?
  • How will the new addressing methodology be deployed?

 


This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

This document is provided on an “as is” basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.


Back to Top