A Security Reference Model for MPLS VPNs

Whenever discussing security for a given system, it is important to define the security zones within this system. In a bank, for example, there are a number of security zones with defined "interfaces" between them: there is the outside of the bank, the open customer area inside the bank, the tills which are again separated from the customer area, and further security areas such as the safe room. In a security policy, the various security zones have to be described, security levels have to be assigned to them, and the "interfaces" have to be defined?that is, how to get from one zone to another.

The same procedure must be applied in the context of networks to define a security policy. The network must be divided into security zones, which must be clearly defined, and "interfaces" between the zones need to be described and defined. The Internet draft "Security Framework for Provider Provisioned VPNs" defines such a security reference model for MPLS VPNs. This RFC coins the generic term of PPVPN network. Since this book covers specifically BGP/MPLS VPN networks, the term MPLS network is used here.

Figure 1-8 illustrates the generic model used in the just mentioned security framework document, here applied to the MPLS VPN environment. An MPLS network consists of an MPLS core network and MPLS VPNs distributed over various VPN sites. An MPLS VPN is a service provided over an MPLS core network to a number of VPN users in various sites.

Figure 1-8. Basic Security Reference Model for MPLS VPNs


In this basic model, there are several restrictions: the VPNs cannot interconnect, and there is no extranet or Internet connectivity yet. Important for security considerations is that the zones are separated for any practical consideration: This separation means that it is not possible to send traffic from a VPN to another VPN, nor to the core. How this separation is achieved will be discussed in detail in Chapter 3. In principle, it is also not possible to send or receive packets from the core network to a VPN. However, Chapter 8 will show that operators of the service provider can change configurations and add new sites, implying that in practice a service provider operator or a hacker, who has obtained similar permissions, can intrude into VPNs provided on the network. Chapter 8 will also outline how this type of threat can be controlled.

In practice, MPLS networks are more complex than the basic concept previously shown: Many VPNs have interconnections to other VPNs, to extranets, or to the Internet. When two or more VPNs are merged on the MPLS core, they form logically one single VPN from the MPLS point of view. Further divisions of those VPNs by firewalls or packet filters are outside the scope of this work, although they are probably standard configurations in many cases. The MPLS backbone sees these two merged VPNs as a single VPN. Extranet connections can similarly be seen as a connection of one of more VPNs with an extranet site, which is another VPN viewed from the MPLS core (see Figure 1-9). The extranet might prevent direct connectivity between the different VPNs, but this is, again, outside the scope of the MPLS security model and this book.

Figure 1-9. Security Reference Model with Extranet


Similarly, if a VPN receives Internet access through the MPLS core network, this can be seen as a connection of this VPN to the Internet (see Figure 1-10). Typically, some type of firewall would be provided between the VPN and the Internet. This firewall can be provided by the service provider or by the VPN user. In either case, the MPLS core does not lose its status as a separate security zone.

Figure 1-10. Security Reference Model with Internet Access


The MPLS core could also be provided by more than one provider, via advanced MPLS VPN architectures such as Inter-AS or Carrier's Carrier (see Figure 1-11). The fact that there is more than one provider involved in the provisioning is invisible to the VPN users from a technical point of view, except that they do not connect all the various VPN sites to the same providers, but to a set of different providers. The new aspect here is that the service providers involved in the provisioning of shared VPNs also have to secure their own MPLS core against intrusions from other MPLS cores. In all cases, the VPN users have to trust all the providers involved. This issue is discussed in more detail in Chapter 4, "Secure MPLS VPN Designs."

Figure 1-11. Security Reference Model with Several MPLS Service Providers


All these scenarios define security zones, or zones of trust, with their respective connections to other security zones. Where these zones are not connecting, intrusions are impossible: for example, it is impossible to intrude from a VPN into the MPLS core. Within a single zone of trust there are, by default, no further security measures. For example, a single VPN spans all sites normally, unless within the VPN further security divisions are added such as by using firewalls. For intrusion prevention, this means that once an intruder has penetrated a single zone of trust, typically the intruder has gained access to the entire zone.

The model of zones of trust is important for creating security policies and risk assessments. In the context of MPLS, this model also has to be applied to be able to analyze security and threats. The following chapters build on this zone model when analyzing security and proposing security measures.