Using IPsec to Implement CE-Based VPNs

IPsec VPNs, as specified in RFC 2401, constitute the most widely deployed example of a CE-based layer 3 VPN. An IPsec VPN relies on two protocols to provide secure transport over the IP core backbone. Authentication Header (AH) enables message integrity and authenticity. Encapsulating Security Payload (ESP) headers are inserted in the IP packet to enable encryption and confidentiality. ESP can also provide message integrity and authenticity, and thus ESP provides a superset of AH's functionality.

Examples of CE-based VPNs range from the remote user connecting into the corporate network to large enterprises sites being connected together.

Remote Access

The common deployment model is that the remote user runs an IPsec VPN client on his laptop computer, which sets up an IPsec tunnel into a VPN concentrator located at the enterprise. The client's security policy can be controlled on the VPN concentrator. One example of such a policy is to prohibit split tunneling, thereby forcing all traffic to go through the tunnel (split tunneling allows the user to tunnel traffic for certain routes while forwarding traffic outside the tunnel for others). An alternative is to run the VPN client on the customer premises equipment (CPE) router in the telecommuter's home, thereby giving secure access to the corporation from its whole home network. This model still stands with IPv6, providing that VPN client software supports IPv6 and an IPv6-enabled VPN concentrator is deployed. At the time of this writing, Cisco VPN concentrators do not support IPv6.

IPsec Tunnel Alternatives

There are alternatives to point-to-point IPsec tunnels. If connecting over an IPv4 network, you can use, for example, 6to4 combined with BGP tunneling. The control plane is then similar to BGP's use in MPLS-BGP, whereas the transport uses 6to4. In this solution, you do not need a full mesh of tunnels, only a mesh of BGP peers. By using the same techniques as described in the "Scaling IPv6 VPN" section, you can limit the number of BGP peers. The CE routers use 6to4 addresses to peer with each other, but the prefixes exchanged can be normal IPv6 prefixes. The downside of this solution is that security is not nearly as good as in the IPsec case, and it is not easy to deploy multicast over a virtual link layer, which is not itself multicast capable. Chapter 3 describes BGP tunneling and 6to4 in more detail.

Routing

Although IP tunnels (GRE, IPv6 in IPv4/IPv6) support most IPv6 routing protocols (except IS-IS), IPsec does not. The IPv6 routing protocols using IPv6 transport use IPv6 multicast. IPsec supports only unicast. Therefore, a separate tunnel is needed for the routing protocol. This tunnel is then itself tunneled inside IPsec to get the required security. If you ever had a Russian Matryoshka doll, you get the idea.

With the "separate tunnel" solution previously mentioned, you can use any IPv6 routing protocol. You can extend the interior gateway protocol (IGP) running within a site to include the VPN, or you can use a separate routing protocol between the CEs across the VPN. One example is to run OSPFv3 within the site and iBGP over the CE peerings. Routes would be redistributed between the two.

IPv6 CE-Based VPN deployment

You can deploy IPv6 CE-based VPNs in the same manner as IPv4 CE-based VPNs. If there is an existing tunnel infrastructure, you can deploy IPv6 over it. Both IPv4 and IPv6 can run over an IPsec tunnel infrastructure that uses IPv4 transport. In the future, when the SP becomes IPv6 capable, you can use IPv6 transport for the IPsec tunnels, while still tunneling both versions of the protocol. An example of this scenario is provided in the "Topology Examples" section of this chapter.