Chapter 14: Internet Layer Security Protocols | Internet & Intranet Security

Team-Fly

In this chapter, we focus on the security protocols that have been developed, proposed, and specified by the IETF IP Security (IPSEC) WG for the Internet layer of the TCP/IP protocol stack. More specifically, we briefly address some previous work in Section 14.1, overview the standardization efforts of the relevant IETF working groups in Section 14.2, elaborate on the IP security architecture in Section 14.3, further describe the IPsec^[1] protocols in Section 14.4, and focus on some relevant key management protocols in Section 14.5. Furthermore, we address implementation issues in Section 14.6 and conclude with some final remarks in Section 14.7. Note that the topic addressed in this chapter (i.e., the IPsec protocols) is very complex, and that the explanations are rather short and not at all comprehensive. Further information can be found in any book on IPsec and virtual private networking [1–3]. Among these books, I particularly recommend [3].^[2]

14.1 PREVIOUS WORK

In most network architectures and corresponding communications protocol stacks, network layer protocol data units are transmitted in the clear, meaning that they are not cryptographically protected during their transmission. Consequently, it is relatively simple to do malicious things, such as inspecting the contents of the data units, forging the source or destination addresses, modifying the contents, or even replaying old data units. There is no guarantee that data units received are in fact from the claimed originators (i.e., the claimed source addresses), that they are delivered to the proper recipients, that they contain the original contents, and that the contents have not been inspected by an eavesdropper while the data units were transmitted from the originators to the recipients. The lack of built-in security is particularly true for IP packets.^[3]

Against this background, the idea of having a standardized network or Internet layer security protocol (to protect network or Internet layer protocol data units) is not new, and several protocols had been proposed before the IETF IPSEC WG started to meet:

The Security Protocol 3 (SP3) was a network layer security protocol jointly developed and proposed by the U.S. National Security Agency (NSA) and the National Institute of Science and Technology (NIST) as part of the secure data network system (SDNS) suite of security protocols [4]. Outside the U.S. military, the SDNS and its security protocols have not seen widespread use. This is particularly true for SP3.
The Network Layer Security Protocol (NLSP) was developed by the ISO to secure the Connectionless Network Protocol (CLNP) [5]. Similar to IP in the Internet model, CLNP provides a connectionless and unreliable network layer service to the higher layers in the OSI-RM. As such, the aim of the NLSP is to secure the network layer service and to provide some basic security services to the higher layers. The NLSP is an incompatible descendent of SP3.
The Integrated NLSP (I-NLSP) was originally developed and proposed by Robert K. Glenn at the NIST to provide security services for both IP (i.e., IPv4) and CLNP.^[4] Again, the security function of I-NLSP is roughly similar to that of SP3, although some details differ. For example, I-NLSP provides some additional functionality, such as security label processing.
A protocol named swIPe was yet another experimental Internet layer security protocol that was developed and prototyped by John Ioannidis and Matt Blaze [6]. The prototype implementation is publicly and freely available on the Internet.^[5] It was often used in UNIX environments and it is still in use today.

The network and Internet layer security protocols listed are more alike than they are different. In fact, they all use encapsulation as their basic enabling technique. What this basically means is that authenticated or encrypted network layer protocol data units are contained within other data units. In the case of IP encapsulation, for example, outgoing plaintext IP packets are authenticated or encrypted and encapsulated in new IP packets by adding new IP headers that are used to route the packets through the internetwork. At the peer systems, the incoming IP packets are decapsulated, meaning that the outer IP headers are stripped off and the inner IP packets are authenticated or decrypted and then forwarded to the intended recipients.

An encapsulated IP packet is illustrated in Figure 14.1. Note that the original IP header and IP payload are collectively treated as the payload for the new IP packet, and that a new IP header must be prepended to this new payload. Consequently, the new IP header must not be encrypted, since it must be used to route (or "tunnel") the new IP packet through the (inter)network. Such an encapsulation or tunneling scheme is convenient, since it means that no changes are required to the existing Internet routing infrastructure: authenticated or encrypted IP packets have an unencrypted, normal-looking outer IP header, and this IP header can be used to route and process the packet as usual. This transparency is convenient for the large-scale deployment of encapsulation and tunneling schemes in general, and IP encapsulation or tunneling in particular. In fact, similar IP encapsulation or tunneling schemes can be used to transfer multicast or IPv6 traffic through unicast or IPv4 network segments.

click to expand
Figure 14.1: Encapsulated IP packet.

^[1]The acronym "IPsec" is used inconsistently. Sometimes "IPSec" is used instead of "IPsec" or "IPSEC." In this book, we use "IPSEC" to refer to the IETF WG of the same name, and "IPsec" to refer to the corresponding security architecture and suite of security protocols.

^[2]This book is also published in Artech House's Computer Security Series.

^[3]Note that IP packets are the protocol data units for the network layer protocol of the Internet architecture, namely, the Internet Protocol (IP).

^[4]I-NLSP was specified in an Internet-Draft that expired long ago.

^[5]ftp://ftp.csua.berkeley.edu/pub/cypherpunks/swIPe/swipe.tar.Z

Team-Fly