Key Security Concepts

To be able to analyze and evaluate the security of MPLS networks, it is important to understand some fundamental security concepts. This section specifically targets network engineers who normally do not work much with security. For security engineers, this section serves as a review of the fundamentals.

This section discusses these fundamental security concepts:

• Security differs from other technologies

• What is "secure"?

• There is no such thing as 100 percent security

• Three components of system security

• Principle of the weakest link

• Principle of the least privilege

• Other important security concepts

Security Differs from Other Technologies

This book targets both networking and security professionals not as separate groups, but as a joint engineering team. Together, both groups need to design, implement, and operate a network for it to be functional and secure. Security has to be planned into the network from the beginning because various functional networking solutions may have completely different security properties. This is also the reason why security cannot be easily retrofitted into an existing network: Some network design decisions might later complicate network security. For example, if the address plan of a network is disjoined with contiguous subnets distributed over different parts of the company, it is harder to define a consistent security policy. Therefore, a good network design and operation should always involve both the network engineers and the security engineers.

However, companies often have relatively strict separation between the networking group and the security group. Sometimes this separation is formalized in an organizational structure, but even when both types of engineers are part of the same group, the security engineers and the rest of the group frequently have communication issues. When both groups must jointly manage some parts of a network, frictions can regularly be observed between the groups.

The security group is often seen by the networking people as too restrictive, and networking people often have the reputation of being too permissive. The typical discussion centers on a new security measure, which requires network management changes. The network engineers do not acknowledge the added value of the new measure ("we have never had an issue with this"), while the security group deems it necessary. Often there is no objective way to prove the effectiveness of a security measure.

One of the main reasons that it is important for both network and security engineers to be involved in the network design is that security as a technology area is substantially different from other technology areas: To succeed in other areas, such as wide-area networking, one needs to find a single way among several options to implement a solution. For example, there are many ways to interconnect two sites, with a number of technologies such as MPLS, ATM, and so on, and with various routing protocols. Many of these options will lead to success, maybe with subtle differences. So an engineer can select one of several options and implement it. Proving that this solution works is relatively simple and can be done by simulating user behavior and tools. Even if some aspects of a technology do not work as expected, the solution can often be used anyway. Maybe one routing protocol converges faster than another in the case of an outage of connections; but in most cases, both protocols will be sufficient for the solution. So in most technologies, there are many possible solutions, and only one is required for an implementation.

In security, this logic is reversed: a security engineer is successful if no security breaches occur. This cannot be fully tested, so there is never a full guarantee that all security mechanisms are configured correctly. An intrusion into a VPN, for example, can occur in many different ways: through a vulnerability in a company web server, a configuration mistake on the firewall, or an unsecured modem in somebody's office. So while a network engineer can quite easily prove that his network is still working correctly, a security engineer can only do this by testing all potentially vulnerable points of the network. However, one single security breach can uncover an engineering mistake.

In other words, the difference between security and other technologies lies in how one defines success: A network engineer is successful when he finds one single way to implement a network. A security engineer is unsuccessful if there is one single way to break into the system. It is very hard to prove that a security engineer is successful: only failures are clearly visible.

What Is "Secure"?

When talking about security concepts, the first question one needs to answer is, "What is meant by the term 'secure'"? In fact, there is no global definition for this concept. In a normal family household, for example, a good door lock is considered adequate security. In a jeweler's shop, a door has to be considerably more robust to be secure; and in a bank, there might be guards in addition to several strong doors. So in every scenario, the first step is to define "secure."

Early discussions on MPLS VPN security had exactly this problem: To some users, "secure" was equivalent to "encryption." Of course, with this definition, MPLS VPNs as such would be insecure. Many enterprises, however, do not necessarily require encryption, and for them "secure" meant essentially separation from other networks. These two viewpoints clashed because they were based on different definitions for "secure." Based on their respective definitions, both groups were actually right.

Both enterprises and service providers define corporate security in a security policy. A security policy defines the necessary technical measures and operational procedures to secure a network. The starting point is a threat model, which defines security exposure on different levels; for example, physical security (somebody carrying out a computer) or network security (hackers gaining illegitimate access to network resources). The threat model serves as a basis for defining security requirements.

In the MPLS VPN environment, security can be viewed from two different angles: from the VPN customer and from the service provider. Both possess different threat models: For a customer, it is important to safeguard against network intrusions from outside of the customer's VPN. Therefore, one of the main threats for a VPN customer is intrusions into his or her domain. For a service provider, one of the key issues is availability of the core network. Thus one of the main threats is prevention of denial of service (DoS) attacks. Both aspects are important in MPLS VPN scenarios, but each part of the network has a different emphasis in its threat model.

The security reference model described later in this chapter in the section "A Security Reference Model for MPLS VPNs" allows the clear distinction of the different network zones in an MPLS VPN environment and defines the so-called "zones of trust." Each of these zones of trust has its own security policy and its own threat model.

So the formally correct way to define "secure" in a certain context is to start by defining the zones of trust in a given environment and then to develop a threat model for each zone and for the overall environment. "Secure" can then be defined using the requirements coming from the threat model.

This book follows this procedure as well: In this chapter, we define the zones of trust for an MPLS VPN environment, we define a threat model, and in Chapter 3 we define the security requirements. Thus, the first three chapters define the term "secure" for the context of MPLS VPNs and serve as a basis for the rest of the book.

No System Is 100 Percent Secure

There is no absolute, 100 percent system security despite the fact that single components of a given system may be 100 percent secure. Entire systems can never be 100 percent secure?often because of the human factor involved.

For example, the one-time pad (OTP) in cryptography is a 100 percent secure encryption algorithm. Every bit in the clear text is encrypted using a bit from a key string. If the key string is as long as the plain text and is never reused, and if the bits in the key string are entirely random, the encryption as such is 100 percent secure. However, of course, this key string has to be carried from the encrypting to the decrypting side. It may be intercepted, or the device used for writing the message may have a backdoor that allows sniffing the plain text. So the overall system will never be 100 percent secure.

When engineers are asked to work on new projects, they are often given sloppy guidelines such as "it must be secure," without any further explanation. One of the problems here is, as explained above, that the term "secure" needs to be defined. Second, even if there is a clear understanding of what is meant by the term "secure" in a certain context, security is not an absolute value and can never be achieved 100 percent. A more reasonable approach is to define a system as sufficiently secure against a list of perceived threats. This is one of the reasons why a security policy must contain a threat model. Security must always be measured against perceived threats.

Three Components of System Security

Many discussions about MPLS VPN security commenced with analysis of the architectural aspects of the solution. For example, the assertion was made that nobody can intrude from the outside of a customer network into a customer VPN. The technical reason for this was that the service provider core would not accept labeled packets from outside the service provider network.

Then the customer discovered that if an operator misconfigured a provider edge (PE) router, VPN separation would no longer be guaranteed. The customer concluded that MPLS is insecure, but this is an incorrect conclusion because the problem of the misconfiguration is an operational problem that can happen in any technology. Network operations must be strictly controlled to avoid such problems. These discussions confused the origin of the security problems by assuming they were architectural rather than operational.

This confusion became apparent when traditional VPN technologies, such as ATM, were looked at. People had to admit that those technologies had essentially the same problems, yet they were assumed to be secure. So what went wrong in these discussions?

The previous OTP example provides an explanation: even if an algorithm is proven to be 100 percent secure, the overall system might still have weaknesses in other areas.

Therefore, when classifying the overall security of a system such as an MPLS VPN network, one has to analyze separately the three fundamental parts that compose the system (see Figure 1-1):

• The architecture (or algorithm) used? This is the formal specification. In cryptography, the algorithm itself, in the case of MPLS VPNs, is the formal specification (as defined in RFC 2547bis, "BGP/MPLS IP VPNs." See www.ietf.org/internet-drafts/draft-ietf-13-vpn-rfc2547bis-03.text, which is a work in progress.)

• Implementation of that architecture or algorithm? This refers to how the architecture or algorithm is actually implemented in reality. Programming mistakes, such as buffer overflows, play a role here.

• Operation of the architecture of algorithm? This includes operator issues, such as choosing weak passwords on routers or workstations, or accidental disclosure of a shared key, such as if configurations are sent to untrusted third parties.

Whenever system security is discussed, it is paramount to separate these three components and to analyze the security of each single one of them. It also helps to understand this separation when defining security policies because the best algorithm is useless when operated in a weak way. In practice, one can find systems where a lot of effort was put into securing the architecture, but its operation was completely neglected. Password management in enterprises is an example of this: often, very good security systems are rendered useless because users choose weak passwords. The designers of such systems should keep in mind that the overall security depends on all three security components.

This book keeps these three parts of a system separate: Chapters 3 and 4 focus solely on the architecture as defined in the standard RFC 2547bis. In these chapters, there are no references to implementation or operation at all; the essential question answered in Chapters 3 and 4 is whether the standard is secure, or in other words, whether an MPLS VPN network as defined by the standard can be operated securely. Chapters 5 through 8 then describe the implementation and operational issues.

Principle of the Weakest Link

Earlier in this chapter, we made the observation that a security engineer is unsuccessful if there is one single way to break into the system. There is an important detail in this sentence: only one weakness is required to break the security of an entire system. The common analogy used to explain this is a chain: if one link breaks, the whole chain is broken.

In practical security systems, much effort is usually put into technical measurement, but quite often, the weakest link is the human factor. There are many well-known cases of this, such as users giving out their passwords freely to someone calling them on the phone, or configuration errors in otherwise very secure systems.

Because there must be a person who ultimately has the power to configure a router, there is always the possibility of that person misconfiguring a router. This problem cannot be completely averted. In practice, the way to minimize the exposure to human mistakes is to use automated tools as much as possible and to use a strict authorization system in conjunction with logging. Of course, automated tools have their own problems, but they provide consistency and prevent mistyping and transient mistakes, such as wrong parameters. The specific topic of operations in an MPLS network will be discussed in detail in Chapter 8, "Secure Operation and Maintenance of an MPLS Core."

Even though the human factor is, in practice, often the weakest link, other parts of the security system might also be flawed and need to be monitored carefully. The security policy should cover all parts of the system with their potential weaknesses, and it should be checked regularly. The only way to find and eliminate the weakest link in a network is with consistent monitoring and tight operational control.

Principle of the Least Privilege

Because human mistakes are an important security risk, the most secure way to design systems is to provide every operator only the authorization strictly required to perform the job. This is called the principle of the least privilege. The idea is that every privilege an operator or user has might lead to potential security breaches, and that therefore every privilege must be monitored and controlled. The less an operator is authorized to do, the less control and monitoring needs must be done and the smaller the overall risk of security problems.

In this area, MPLS networks do not behave any differently than other networks, and the normal controls for network operations apply equally. More information on how to secure a core network can be found in the book Cisco ISP Essentials (1-58705-041-2; published by Cisco Press).

The principle of the least privilege was originally devised in the context of human operators. However, the principle of the least privilege can equally be applied to general network security in that, on a network, everything should be restricted as much as possible. For example, it is not necessary for a user outside the core network (on the Internet or in a VPN) to send packets to core routers. Only very few protocols must reach the core routers from outside the core network?routing protocols are the obvious case (for example, BGP to and from the external peers). Therefore, the "privilege" to send traffic into the network should be limited from the outside to what is really required, such as routing. This type of traffic filtering is also referred to as infrastructure access control lists (iACLs). Further discussion on this topic can be found in the book Cisco ISP Essentials, mentioned previously.