Extranet Access

MPLS provides the flexibility to link VPN sites in a number of ways. When several VPNs get access to a shared part of network infrastructure, this is called an extranet. Figure 4-9 shows one type of extranet: a shared services extranet.

Technically, extranets are constructed by using route-targets to determine which routes get included into which VRF. In this example, the VPN routes from VPN A and VPN B are imported into the VRF of the extranet. This is achieved through the route-target import statement within the VRF configuration. This way, the extranet receives the routes of the two VPNs. In the other direction, the extranet VPN routes are imported into VPNs A and B with the same command.

The VPNs export their own routes, or a subset thereof, such that the extranet VRF can import them. The command route-target export in the VRF controls this behavior. The extranet VRF exclusively exports its own routes to both VPNs. This way, both VPNs know the route to the extranet.

Normally, VPNs are free to use the entire theoretical IP address space within the VPN. In the extranet scenario, however, routes are exchanged with entities outside the VPN, in this case the extranet VPN. Therefore, the exchanged routes between the VPNs involved (A, B, extranet) must be unique. If the routes are not unique, a network address translation (NAT) function must be used to make all routes within this group unique.

What are the security consequences of linking two VPNs to an extranet? The primary goal of such a configuration is to permit various VPNs to access a shared network while maintaining the separation between the VPNs. Figure 4-10 shows which data flows are "legal" in a scenario like this and which ones would result in a security breach.

The traffic exchange between VPN A and the extranet and VPN B and the extranet is controlled by the route-target configurations on the respective PE routers, as previously explained. To prevent traffic from VPN A flowing to VPN B through the extranet, the first necessary step is not to export the routes from one VPN to the other, but only export the extranet routes. This way, both VPNs do not learn about the routes of the other VPN and therefore cannot send traffic to the other VPN through the extranet.

Assume, however, that a user in VPN A knows that VPN B, a competitor, is connected to the extranet and wants to send traffic into the other VPN. Would that user be able to connect to servers in VPN B by some means? Figure 4-11 shows in more detail the PE routers in this case, with the corresponding VRFs and route-target statements.

Figure 4-11. VRFs and Route-Target Statements

[View full size image]

The VRF of the extranet imports the routes to both VPNs, such that the final VRF table would be as follows:

200.0.1/24; RT: 1:100  (the extranet route)

192.0.1/24; RT: 1:1  (the route for VPN A)

193.0.1/24; RT: 1:2  (the route for VPN B)

If VPN A knows the addressing of VPN B, it could send a local default route to the extranet, thus sending traffic to locally unknown destinations (as addresses of B would be) to the extranet VRF. There the route to VPN B is known, and traffic would flow to VPN B. However, since VPN B does not know a valid route to VPN A, return traffic would not get back to VPN A.

Therefore, it is possible to send traffic unidirectionally into another VPN that is connected in this way to a shared extranet, assuming the "attacker" knows the addressing of the target in the other VPN. Is this a realistic threat?

Yes, this threat does need to be taken seriously: Firstly because there are a number of attack forms that only require a single packet to be sent. The "ping of death" from the early 1990s is a historic example. Note that the way back might be different: for example, a one-packet exploit could open a connection to a host in the Internet. This way, a single command might be transmitted unidirectionally, opening a connection to the Internet for further exploits.

Secondly, many worms have spread this way. The "code red" worm is a more recent example of how a single packet might exploit a local vulnerability. Worms usually spread their infecting packets to random destinations, so if there is some form of default routing to the extranet, some of the packets with random destinations would be sent to the extranet.

This issue can be solved with firewalling, which is explained in more detail in the next section, "MPLS VPNs and Firewalling."

In the previous example, we have discussed an extranet scenario with two VPNs. However, look at Figure 4-11 again and imagine a hub-and-spoke setup within a single VPN: then VPNs A and B would be the spokes and the extranet the hub. Leaving the route-target import/export statements as they are, this would result in an architecture where spoke sites are allowed to exchange traffic with the hub but not with each other.

What are we trying to show with this? The route-target import/export functions control the flow of routing on an MPLS VPN backbone. If routing allows packets to flow either unidirectionally or bidirectionally, we have connected two networks (in the example, the two VPNs with the extranet).

Therefore, when connecting sites through route-target configurations, you have to always assume full connectivity, even if route-targets only allow traffic to flow in one direction by default.

As a corollary from this exercise, note the importance of this single feature, the route-target statements, for security: A single line in the configuration of a PE router decides whether two VPN sites get connected or not. In large VPN environments, VRFs may have a long list of route-target statements. A single error in one of them may endanger the security of one or several sites.

It is, therefore, of utmost importance to control the route-target statements in an MPLS VPN backbone against misconfiguration?deliberate or accidental.

More about operational control of misconfigurations can be found in Chapter 8.

From these considerations, we deduce the following recommendation: when connecting sites of different security zones through route-target statements, always separate these zones through firewalling. How to do this is discussed in the next section.