Security and the Management Plane, Part 1
- Overview of the Management Plane
- Secure MP Login
- Management Plane Security
- References
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Overview of the Management Plane
A few years ago I overheard an IT staffer saying, "I know the salaries of all the people on this site. They're stored on a remote disk and I have the password." This security incident illustrates the crucial point that up to 80% [1] of attacks originate from within organizational boundaries. We should always bear this principle in mind when thinking about securing any system or network:
Security is only as strong as its weakest link (often human or process).
So what's so special about the management plane?
The management plane (MP) provides an important element in the orderly running of networks. It's a valuable resource for deploying and managing increasingly advanced network services including (among others):
IP-based differentiated services—voice/video-over IP
Layer 3 (or IP) VPN—incorporating MPLS
Layer 2 VPN—extending the reach of a LAN across a service provider
The demand for these services is growing and many service providers are deploying them. This change is in response to both user demand and the threat to service providers of price-sensitive, commoditized business models. The service-level agreement (SLA) is a key commercial differentiator of the above services, but SLAs are difficult to achieve without leveraging the MP.
A further, more subtle role for the MP is enabling the alignment of IT and enterprise core business processes. While not the subject of this article, this important topic is all the rage nowadays. One way to effect this alignment is for IT to explicitly define and document the services it manages within an organization, such as the following:
Client and server machine configuration
Segmenting the network into virtual LANs (VLANs)
Software distribution and license management
Network protection (antivirus) and security
In a separate step, these services are typically rolled out onto the network via the MP of the associated devices. Following this point, the MP is used to keep the services up and running.
If the process of service definition, rollout, and subsequent management is automated, this setup becomes a powerful way for IT to run the network. In turn, this power can be leveraged by the organization to help achieve its business goals; for example, extending LAN-level services to remote workers, creating secure extranets, and so on. Unfortunately, most organizations use scripts and other proprietary facilities to run their networks. This technique tends to restrict the potential for aligning IT and business goals because so much IT staff time is spent firefighting.
Automating MP interactions (for instance, using network management software) facilitates powerful business-enabling processes. In many ways, the industry focuses on the control plane, often at the expense of the MP. In this article and the next, I hope to illustrate the point that the MP is often an underutilized resource. Hence, the need to secure it!
Security Threats
Traditional threats to security include denial-of-service, hacking, snooping, data modification, and more. The increased deployment of differentiated IP-based services provides the opportunity for a theft-of-service type of attack. In this attack, a user fraudulently marks IP packets in order to receive a higher level of service.
The MP provides facilities for helping in the war against these and many other types of attacks. Let's take a closer look at the MP.
The Management Plane: Network Gold
The MP performs management functions for an overall system and provides coordination among all the planes (control, data, forwarding, and so forth). The MP, control plane, and data plane are illustrated in Figure 1 in conjunction with a remote management system.
)
Figure
1 Management system and conceptual device planes.
The management system in Figure 1 may be one or more of the following:
Element Management System (EMS). Handles one or more devices and provides a device-centered perspective.
Network Management System (NMS). Handles many devices and provides a network-wide perspective (often communicates with the EMS).
Operational Support System (OSS). Handles network-wide operations with interfaces to upper business layers (often drives the NMS).
Regardless of the management system type, all device access passes through the MP. In Figure 1, the MP is shown interacting with the control plane (such as changing a routing table entry on one of the devices in the managed network).
Under the direction of the network manager, the management system interacts with the MP, typically performing reads and writes of managed objects. The MP can also relay notification messages that are sent autonomously from the network to the management system. Typically, the latter message type signifies some important event or fault that has occurred in the network, such as these:
Node or link failure (may require rapid reaction to avoid service loss)
Onset of congestion in some important part of the network (may require reaction within a few hours)
Completion of a software upgrade on a node (may be purely informational)
The bidirectional message exchange allows the management system to keep track of and modify the state of the underlying managed network devices. The MP facilitates this process and allows the management system (and hence the network manager) to keep track of the picture it has of the network.
NOTE
A fundamental rule of network management is that the management system is constantly working to maintain an accurate picture of the state of the managed devices. [2] The more closely matched the management system picture is with the real network, the better.
An important point about Figure 1 is that each managed device—router, switch, hub, etc.—contains its own set of planes (not shown in Figure 1). It is, however, a major goal of the management system (particularly the NMS and OSS) to provide a single system image of the underlying network. In this context, the three planes in Figure 1 can be considered to represent an entire network of devices. This useful abstraction facilitates management scalability as the network grows.
As we'll see later, security demands that every element of Figure 1 be individually secured.
NOTE
It's axiomatic to say that a network is generally only as fast as its slowest element. Similarly, a network is generally only as secure as its least secure element.
Why Provide Planes?
Wouldn't it be easier if networks were just monolithic entities, without having to think about all these planes? Unfortunately not, particularly given the growing complexity of network devices. The provision of planes greatly assists pretty much everyone in the networking value chain: developers, testers, installers, end users. To understand why, let's look at a few common characteristics of network devices:
Expensive to develop and purchase
Long lived, they may reside in managed networks for years
Upgraded over time to add new technologies, such as MPLS, layer 2/3 VPN
Try to think of network devices (routers, switches, hubs, etc.) as special-purpose computers. Typically, they contain many different interfaces on which traffic is sent and received. Modern devices are equipped with interfaces that support many technologies, such as these:
Ethernet—legacy or VLAN-aware or QoS-aware (i.e., IEEE 802.1p/Q)
HDLC/PPP
Frame relay
ATM
MPLS
IP
Configuring and managing services on any of the above is decidedly non-trivial! Many different elements have to be configured, such as layer 2/3 addresses, subnet masks, routing/signaling protocols, virtual circuits, and more.
Separating the various areas of device management, control, and data (among others) into individual planes [3] provides a useful abstraction. End users can then become accustomed to a stable MP user interface; for example, the Cisco CLI is a de facto standard. SNMP provides a slightly less visible point of MP access but is a (de jure) standard nonetheless. By placing CLI and other access technologies into the MP, device vendors can provide a useful division of labor. Unfortunately, sometimes the division into planes results in MP development taking place late in the project lifecycle. This delay presents its own special problems!
If a vendor wants to add new technology support to a device, the vendor (initially) only has to upgrade the control plane. Associated changes to the other planes can then be applied later, rather than having to update all planes at once. This stratagem makes development somewhat easier to control and is similar in concept to the layered architecture of network protocols.
Accessing the Management Plane
Traditionally, access to the MP is made using either the command-line interface (CLI) or a network management protocol (such as SNMP or OSI). Management access to the MP of a given device typically occurs through a dedicated interface such as an Ethernet port, serial port, and so on. Figure 2 illustrates a hard-pressed network manager laboring to keep a big network up and running while her coffee goes cold. Also in Figure 2, we see the two access methods (CLI/SNMPv3) in use by the NMS. We assume that SNMPv3 is in use on all devices in the network. This may not be the case in practice; e.g., legacy devices may not support SNMPv3.
)
Figure
2 Command-line and SNMP access to the management plane.
NOTE
Many network devices also support web access—both secured and unsecured. Many vendors support CLI, SNMP, and web-based access, essentially providing the same facilities from all three methods. In this article and the next, I'll focus on CLI and SNMP only.
CLI is little more than a text menu-based interface, much like that of MS-DOS. Some vendors provide very fine-grained control as part of CLI; for example, with numerous levels of access.
SNMP is somewhat more sophisticated than CLI because it's a standard, message-based protocol with a well-defined, extensible data model.
NOTE
The difference between CLI and SNMP is that CLI provides a human-to-machine interface, while SNMP uses a machine-to-machine interface.
It's likely that as technology advances, the use of SNMP (in conjunction with NMS products) will overtake CLI.