KE version 2 (IKEv2), defined in RFC 4306, expands upon IKEv1. (Public keys, digital certificates, and CAs are discussed later in this chapter.) Initially, IPsec became the predominant mechanism for providing the underly- ing VPN architectures. This technology works at OSI Layer 3 to create a connec- tion into the network SO that as a device logs on, it can act as if it is physically attached to the LAN. By encrypting the traffic, the customer can build VPN net- works over the Internet. A customer's traffic is encrypted but not necessarily seg- mented. IPsec provides encryption and authentication, but there is a tradeoff in performance, although most modern hardware can handle the cryptographic requirements well enough. In general, IPsec is inefficient because it requires signif- icant overhead to encrypt the traffic. This may be acceptable on low-speed links, but throughput is significantly affected on high-speed links. Most router vendors provide IPsec capabilities embedded in the operating systems, but there is a signifi- cant performance degradation in the routers. Line-speed IPsec processing is still not where most customers would like it to be. You need to take this into consideration when choosing a routing platform that will be initiating IPsec security associations. In addition to the performance impact, there is the additional management overhead of configuring, maintaining, and managing IPsec across the IP cloud. IPsec, key distribution, key management, and peering configuration can become complex in a large IPsec deployment. Chapter 9 IP Services GRE VPNs RFC 2784 and RFC 1702 specify the GRE protocol for using IP as both the delivery and payload protocol. In the most general case, a system has a packet that needs to be encapsulated and delivered to some destination, referred to as the payload packet. The payload is first encapsulated in a GRE packet. The resulting GRE packet can then be encapsulated in some other protocol and forwarded. This outer protocol is referred to as the delivery protocol. GRE