IPSec is a robust and extensible mechanism for securing IP datagrams. IPSec provides stateless security—data confidentiality, data integrity, data source authentication, protection against traffic analysis, and antireplay protection—and therefore does not make any requirements on the IP protocol to achieve security. As such it is ideal for protecting any type of traffic that can travel on top of IP—basically any traffic.
By providing security at the IP layer, IPSec allows any application to take full advantage of its functionality. Security is done in one place, in the stack, instead of in each application that requires security. Authentication and access control are therefore done at the communications aggregation point in the stack. It is important to contrast this with socket-based security—such as SSL—in which every application that desires security must be modified. With IPSec, you just modify your stack and, voila, all applications can be secured.
Different modes of IPSec—tunnel mode and transport mode—allow it to be deployed anywhere an IP stack exists and to protect any type of traffic carried over IP. Transport mode is ideally suited for providing end-to-end security, while tunnel mode is ideally suited for providing protection to transient traffic.
By placing IPSec-enabled hardware at different points in the network—routers, firewalls, hosts, and bump-in-the-wire (BITW) “crypto boxes”—different security deployments can be realized. End-to-end security can be achieved by deploying IPSec-enabled stacks on hosts or by providing a bump-in-the-stack (BITS) solution as a “shim” inserted into the networking stack. A virtual private network (VPN) can be constructed by IPSec-enabled routers protecting traffic between protected subnets. Scenarios such as the roaming road warrior can be achieved by combining host-based and router-based IPSec solutions together.
Since IPSec-protected datagrams are themselves IP datagrams, IPSec can be applied serially or recursively, allowing for hub-and-spoke deployments, or end-to-end IPSec-secured packets being tunneled through an IPSec-protected VPN.
When IPSec exists on a host or end system—either natively in the stack or as a bump-in-the-stack implementation—IP packets can be secured from the data source to the data sink (Figure 10.1). The value of this cannot be overstated. When end-to-end security is achieved, every packet that leaves or enters a host can be secured. In addition, it is possible to configure IPSec on a host such that packets that are not IPSec-protected will be dropped. The result is a box that is “invisible” on the network—any of the popular port-scanning applications will not report such a device on the network—but, provided SAs are shared with it, will allow the full gamut of services a host or server can provide.
Depending on policy selectors, a single SA pair can secure all traffic between two endpoints—Telnet, SMTP, Web, etc.—or unique SA pairs can protect each stream independently. In either case, the traffic does not exist on the wire in an unsecured state.
Generally, end-to-end security is accomplished by using IPSec in transport mode since the communication endpoints are also the IPSec endpoints. But tunnel mode can be used to provide end-to-end security with the added overhead of an extra IP header. Either mode is perfectly legal.
A possible drawback to end-to-end security is that various applications that require the ability to “inspect” or modify a transient packet will fail when end-to-end confidentiality is employed. Various Quality of Service (QoS) solutions, traffic shaping, firewalling, and traffic monitoring tools will all be unable to determine what sort of packet is being transmitted—it's just an IPSec packet—and will therefore be unable to make the decisions that they're supposed to make. In addition, Network Address Translation (NAT) will fail because it is attempting to modify a packet that has been secured. In fact, NAT can be thought of as just the sort of attack that IPSec is designed to prevent. Since NAT is very popular, there is work on-going in the IETF to allow the two to be used simultaneously. Re-addressing entire networks or enabling security is not a choice most network administrators want to make!
When IPSec is deployed in intermediate networking devices—another way of saying routers—virtual private networks (VPNs) can be established (Figure 10.2). A VPN is virtual because it is not a physically distinct network. Tunnels are used to establish connectivity between disparate physical networks. A VPN is private because the tunnels are encrypted to provide confidentiality. A VPN is a network because, well, this is networking! We're connecting two different networks and establishing what is, in effect, a single, albeit virtual, entity: a new network.
VPNs are becoming important when people realize the cost savings that can be achieved by switching from traditional leased line types of networks to those that utilize public networks. Since these networks are literally public, a company is reluctant to just connect their corporate network to it. Proprietary information could inadvertently leak out and hackers would almost certainly come in. A VPN can give a company the security it needs at a great savings in cost over a leased line.
VPNs are constructed by deploying IPSec on routers that provide the physical network connection to a protected network. On one side of the routers, the red side (red because of the image it invokes of danger, caution, and attention) is a protected network to which access must be strictly controlled. On the other side, the black side (black because we can't see what's in the packets being emitted), is the unsafe and unsecured network—usually the big I, Internet. When two such routers establish IPSec tunnels through which they send traffic from locally protected subnets to remotely protected subnets, it is called a VPN.
In a VPN, each IPSec-enabled router is a network aggregation point and attempts at traffic analysis of the VPN will fail. All traffic destined for the VPN goes through tunnels on the router and to a snooper in the network all the traffic looks the same—it's just encrypted packets sourced by one router and destined to another router. Depending on the selectors dictating which traffic is part of the VPN, there may be many pairs of SAs defining the VPN or a single pair of SAs defining the VPN. In either case, the only information a snooper could derive is the SPI being used, but since he has no way to equate SPIs with traffic—this part of the IKE exchange is encrypted, after all—this information is not very useful.
Since VPNs are protecting transient traffic—traffic sourced or destined for hosts on a protected network—they must use IPSec in tunnel mode. The only way for transport mode IPSec to be used is if the transient traffic is being tunneled via some other protocol. L2TP is an example of this and will be discussed in Chapter 12.
In end-to-end security, packets are encrypted and decrypted by the host that produces and/or consumes the traffic. In a VPN, a router on the network encrypts and decrypts packets on behalf of a host (or hosts) on a protected network. A combination of the two is generally referred to as the road warrior configuration (Figure 10.3).
A road warrior is typically an individual who does not reside at a fixed location but still requires access to a protected network. The most common situation is a traveling employee who must securely access corporate resources from a hotel, or airport dial-up, or from any Internet point of presense (POP) available.
In a road warrior scenario, the road warrior's computer supports IPSec either natively or by a bump-in-the-stack shim. He is able to secure outbound packets before they reach the wire and able to verify the security on inbound packets before they reach IP processing. The road warrior's IPSec peer is a router that protects the network the road warrior wishes to access. This router can simultaneously be supporting a VPN—terminating IPSec tunnels with other routers—and allowing secure remote access to other roaming road warriors.
One side of this connection will be both the communications and IPSec endpoint but the other side will be providing IPSec as a service to another network entity. Therefore, the road warrior scenario is similar to the VPN in that it either must be IPSec in tunnel mode or the transient traffic—from the road warrior's portable computer to the protected network—must be tunneled by some other protocol.
Sometimes there are multiple levels of network security that need to be supported. The canonical example of this is a corporation that has a security gateway to protect its network from competitors and hackers, and inside the network has another security gateway protecting a sensitive subnet from its own employees. Imagine the human resources, or mergers and acquisitions departments of a major corporation. The information managed by those departments cannot be made available to all employees, just as other proprietary corporate information on its main network cannot be made available to the general public.
In this situation, when one wishes to access a protected subnet inside a protected network, nested tunnels are necessary (figure 10.4). Alice is in the mergers and acquisitions department of the NetWidgit Corporation and spent the day evaluating a takeover target. She wishes to share the information she gathered with her co-workers, but is in another town and there are no local offices. With IPSec, Alice can establish an encrypted and authenticated tunnel to the security gateway for the NetWidget Corporation, and, once inside the network (via an IPSec-protected tunnel to the security gateway), establish another encrypted and authenticated tunnel with the security gateway of the mergers and acquisitions department. Her packets, from her portable computer to a server inside her department's subnet, are encapsulated with IPSec packets addressed to the security gateway of Mergers and Acquisitions. Those IPSec packets are further encapsulated with IPSec addressed to the security gateway of the NetWidget Corporation itself. These layers are peeled off like layers of an onion as the packet makes its way toward its ultimate destination (Figure 10.5).
A packet from Alice's department server back to her portable computer is straightforward to construct since each of the encapsulations is atomic. The packet Alice sends to her department server is much more difficult to construct. Her original packet destined for her department server will hit an SPD match in her local policy database. That will trigger an IPSec encapsulation and the resulting IPSec packet will be reinserted back into the packet output path for another policy check. This IPSec packet, destined for her department's security gateway, will hit another SPD match and result in yet another IPSec encapsulation and reinsertion back into the packet output path. This final header, an IPSec packet from Alice's computer to her corporate gateway, will be sent out the wire.
Just as complicated is the way this whole thing is established! Alice must have policy in her SPD that specifies traffic to her department's server must be protected by ESP (AH) with the IPSec peer of her department's security gateway. Furthermore, she must have policy that says that all traffic, including ESP (AH) and IKE traffic, to her department's security gateway must be protected with ESP (AH) with the IPSec peer for that traffic being the corporate gateway. The first packet she attempts to send to the server on a network behind two security gateways will trigger an IKE exchange to her department's security gateway. This IKE packet will trigger another IKE exchange, this one to her corporate gateway! Once the second IKE exchange, to the corporate gateway of NetWidget, is complete and SAs exist between Alice's computer and her corporate gateway, the first IKE exchange can be securely tunneled through the gateway to her department's gateway. Only when that IKE exchange is complete and two pairs of SAs exist—both inbound to Alice but outbound to the different security gateways—can the original packet be sent.
Policy for nested tunnels is difficult to set up, but once it is established it can be left in place. Alice has no need to modify the security policy on her mobile PC once it has been defined. Following the packet flow for nested tunnels (two IKE exchanges being kicked off for a single packet, IPSec securing an IKE exchange, etc.) is likewise confusing, but once you've stepped through it, it becomes obvious what is happening and the strength and beauty of IPSec becomes apparent.
A common deployment of network security is a hub-and-spoke, as seen in Figure 10.6. The network architect is usually thinking about link encryption when this is designed but there can be other reasons, such as many-to-many encryption.
In such a design, there is usually a router that terminates multiple tunnels. Packets destined from one network to another that traverse a hub-and-spoke network are encrypted by a security gateway, decrypted by the hub, reencrypted (most likely with a different key), and decrypted by the security gateway protecting the remote network. Sometimes there are several hubs and the decryption and reencryption is done several times. Each of the tunnels in the path are chained together.
Obviously, the performance of this design is not as good as a traditional VPN, because the same packet will be encrypted many times. The setup latency for the first packet will also be quite poor because the packet will be delayed at each stop while the next tunnel in the chain is established. In spite of these drawbacks, this is a fairly common deployment. The primary reason is one of management. In a network with hundreds, even up to one thousand, stub networks trying to configure a peerwise relationship with every other security gateway, protecting a stub network would be a colossal feat! Adding one new stub network would entail visiting, and configuring, every single stub gateway. It's much easier to have several hubs in the network, each terminating a handful of tunnels, some to other hubs, some to stub gateways.
Unfortunately, there is really no easy solution to this problem. IPSec is a point-to-point protocol and each point has to know the other. Each stub gateway has to know the identity of every possible peer and the network it protects. That way, when the gateway gets a packet it knows to whom it must be encapsulated.