Introduction: Issues with Link Layer-Only Security

In previous chapters, we discussed some of the problems associated with security provi- sioning for links providing access to networks. Often, the link security mechanisms are developed specifically for the physical media on that link. We also provided some examples on how protocols such as EAP can be used to provide authentication and secure channels between a client and the network over a generic link technology. Still, methods such as EAP must be fitted tightly to the link technology. A bigger problem with such link security mech- anisms is that they only provide security mechanisms for the link between the client and a device at the edge of the network (network point of presence) and do not extend beyond that single hop. The following example intends to demonstrate the problem that arises when link layer security mechanisms are deployed for generic communications scenarios.

Consider the case, when the two communicating hosts A and B are four hops away, i.e. separated by three routers. When only link layer security mechanisms are available, security protection can be provided over a single link (between two neighboring routers) at a time. In our example, this would mean that each of the hops 1, 2, 3, and 4 in Figure 4.1 must be secured individually based on the trust relationships between the routers on each end of that hop. When a packet traverses from host A to host B, each receiving router on the path must first decrypt the packet from the previous hop, and re-encrypt the packet before forwarding it over the next hop toward the following router. This decryption/encryption of each packet would not only significantly increase the processing burden on each of the inter- mediary routers, but also leaves the host A and host B at the mercy of those routers: they simply have no choice but to trust all of these routers with their traffic. For that to be accept- able, the two hosts must in advance know how their traffic is being routed through the Internet and trust all the security relationships across the path. We can see how this approach can quickly bring the Internet speed and scalability down!

All the impracticalities described in the previous example point to the fact that the two hosts are better off with establishing an end-to-end secure channel between themselves in

a manner that is transparent to the intermediate networks. That way the intermediary routers do not have to carry the burden of security processing and can focus their processing power on routing and forwarding. The two hosts can be sure that no intermediaries had access to the content of their packets.

Another case, where link security provisioning becomes impractical, is a popular scenario that is shown in Figure 4.2. An enterprise wishes to connect two parts of its network at two remote locations (site 1 and site 2) in a way that the nodes and users residing at each location can communicate with each other securely and transparently, as if they belonged to a single network. The enterprise leases a high bandwidth link from a commercial provider to connect the two sites, and is assured about the link performance by the provider, but cannot trust the provider with the content that is being transferred between the two sites. Furthermore, the enterprise may wish to handle both sites as if they were part of one site by for instance using addresses from the same IP address pool or applying the same network policies at both sites. One prominent method for solving the problem described above is to deploy a so-called virtual private network (VPN). The VPN establishes a secure channel between the two network parts (hence the term “private”) and routes the traffic in a way that the users at each end feel they are part of the same network (hence the term “virtual”). Each of the two network portions is considered as a part of the secure and trusted domain. Specific routers that also act as security gateways and are often called VPN gateways are deployed at the edge of each site and define the boundaries of each site. All traffic going in or out of each site must go through these gateways and most often in encrypted format, while the traffic within the boundaries does not have to be secured. When host A needs to communicate with host B, the traffic is encrypted by security gateway 1 (SG1) before going over the untrusted link to security gateway 2 (SG2), which in turn decrypts the packets and forward them over the trusted topology in site 2.

Host A R1 R3 Host B Packet flow R2 1 2 3 4

Figure 4.1 Securing communications between two entities that are multiple hops away

Host A _{Host B} Untrusted link SG1 SG2 Site 1 Site 2

Deploying security between the security gateways at IP layer allows the application traffic travel between any host A and host B without any regard to how the traffic is being routed.

As we see, it is often practical to provide key exchange and security at a layer higher than link layer. There are several choices on which layer to apply the security protection to the ongoing traffic. Looking at the TCP/IP stack, applying security at any of the network layer (IP layer), transport layer and application layer comes to mind. In this chapter, we will discuss the most prominent security protocols at network and transport layer, namely, internet protocol security (IPsec) and transport layer security (TLS). Out of those two, TLS provides its own key exchange mechanism, while IPsec relies on internet key exchange (IKE) for key exchange. For that reason, we also devote a section to IKE as well. The reader may even experience an imbalance on the amount of text dedicated to IKE compared to that for IPsec. The reason for that conscious effort is that we believe there is a large amount of literature (including books) devoted to IPsec, while there are very few comprehensive sources on IKE. Also, we do not provide any text on application layer security for several reasons. First, application layer security can be directly applied by using algorithms that are described in previous chapters and other cryptographic text. Second, providing security at application layer requires the application designer to possess the know-how on cryptographic procedures. Using IP and transport layer security mechanisms allows the application designers to focus on the application functionality and simply use standardized lower layer mechanisms to provision security.