Security Overview and MPLS

When talking about security concepts, the first question you must answer is, "What is meant by the term secure?" In a normal family house, for example, a good door lock is considered adequate security. In a jeweler's shop, though, a door has to be considerably more robust to be secure, and a bank might have guards in addition to several strong doors. In every scenario, the first step is to define secure; only after this is done can the next step of actually securing a network be performed.

Early discussions on MPLS VPN security had exactly this problem: To some users, secure was equivalent to encryption of data. Of course, with this definition, MPLS VPNs as such would be insecure. Many enterprises, however, do not necessarily require encryptionfor them, secure means a separation of their network traffic from other networks. These two viewpoints clash because they are based on different definitions of the term secure.

Both enterprises and service providers define corporate security in a security policy. The starting point is a threat model, which defines security exposure on different levelsfor 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 the definition of security requirements. Note that a threat model is not just limited to MPLS, but rather is generic to security overall.

In the MPLS VPN environment, security can be viewed from two angles: from the VPN customer's perspective and from the service provider's perspective. Both possess different threat models. For a customer, it is important to safeguard against network intrusions from outside his VPN. Therefore, one of the main threats to a VPN customer is intrusions into his domain. For a service provider, one of the key issues is the availability of the core network. Thus, one of the main threats to a service provider is denial-of-service 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 allows the clear distinction of the 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 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 develop a threat model for each zone and for the overall environment. Secure can then be defined through the requirements coming from the threat model. There is no absolute, 100 percent system security despite the fact that single components of a given system can be 100 percent secure. Entire systems can never be 100 percent securemainly because of the human factor involved.

For example, the One-Time-Pad 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, this key string has to be carried from the encrypting to the decrypting side, so it can be intercepted. Or the device used for writing the message might have a backdoor that allows sniffing the plain text. Thus, the overall system will never be 100 percent secure.

The first problem that occurs when engineers are asked to work on new projects is that they are often given rather sloppy guidelines, such as "it must be secure," without any further explanation. One of the issues here is, as explained previously, that the term secure needs to be defined in painfully precise terms before it can be implemented. As with many things, the devil is in the details! Furthermore, security requirements can be a moving target as organizations evolve.

The second problem is that, even if you have 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 also one of the reasons a security policy must contain a threat model. Security must always be measured against perceived threats. Many discussions about MPLS VPN security have commenced by analyzing the architecture. One example is asserting that nobody can intrude from the outside of a customer network into a customer VPN because the service provider core would not accept labeled packets from outside the service provider network. Then the customer discovers that if an operator misconfigures a provider edge (PE), VPN separation will not be guaranteed any longer. The conclusion is, therefore, that MPLS is insecure. This is an incorrect conclusion, though, because the problem of the misconfiguration is an operational problem, which can occur in any technology. These discussions confuse architecture and the operations of that architecture.

Even more confusing, when looking at traditional VPN technologies, such as ATM, people had to admit that they had essentially the same problems, yet the technologies were assumed to be secure. So what went wrong in these discussions? The previous example with the One-Time-Pad gives an idea that 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, you have to analyze the three fundamental parts that comprise the system:

• Architecture or algorithm used This is the formal specification. In cryptography, it's the algorithm itself; in the case of MPLS VPNs, it's the formal specification as defined in RFC2547bis.

• Implementation of that architecture or algorithm Implementation refers to how the architecture or algorithm is actually implemented in reality. Programming issues play a role here.

• Operation thereof For cryptography, key handling is involved; in the case of networks, an example is weak router passwords.

Of course, security is a broad field, and it is impossible to capture all the details in a short introduction. However, some additional security concepts are worth mentioning briefly:

• Confidentiality, integrity, availability The three basic properties of security (some text books add authenticity as a fourth). When defining security, you can be more precise by defining which of the security properties is required to which extent. For example, in a military environment the most important security property is probably confidentiality. In a bank, confidentiality is important, too, but even more important is the integrity of the data. For an online shopping site, however, availability of the web page is an important factor. Overall security can usually be defined with these three properties.

  In the MPLS context, every VPN customer has slightly different requirements in these parameters. Customers expect that their data will be private (confidential) for their VPN.

• Defense in depth Because one weak link is sufficient to endanger the security of an overall system, it is common practice to construct several layers of security around a solution, such that if one single component breaks, others still defend the assets. The best example in enterprise networks is the demilitarized zone: Servers of a company are usually highly protected. However, even if this protection fails and a hacker gains access to a server, a firewall is still there that the hacker must overcome to get into the network.

  It is good practice to add several layers of defense around everything that needs to be protected. This design principle is also important in MPLS networks.

• Secure failure The primary mode of operation of any technology is usually well considered and well secured. However, when the primary method fails, the backup method also needs to be appropriately secured. It is common practice today to use secure shell (SSH) for router configuration; however, you need a backup method of getting to a router in case the SSH server fails. This is usually done through out-of-band access, mostly over the telephone network. It is important that this backup mode be as secured as the principal access mode.

MPLS-based VPN services have increased significantly over the last years. One of the reasons is that they can be provided more easily than traditional layer 2 VPNs, such as ATM and Frame Relay. This ease of provisioning often leads to attractive pricing models for the customer.