14.2 IETF STANDARDIZATION

Team-Fly

When the IETF started to develop the next version of IP (i.e., IPv6), it was commonly agreed that this version had to incorporate strong security features (at least for users who desire security). The security features had to be algorithm-independent so that the cryptographic algorithms could be altered without affecting the other parts of an implementation. Furthermore, the security features should be useful in enforcing a wide variety of security policies, and yet they should be designed in a way that avoids adverse impacts on Internet users who do not need security services for the protection of their IP traffic at all.

Against this background, the IETF chartered an IPSEC WG in 1992. The aim was to define a security architecture (mainly for IPv6), and to standardize both an IP Security Protocol (IPSP) and a related Internet Key Management Protocol (IKMP). Soon it was realized that the same security architecture that was being developed for IPv6 could also be used for IPv4. Consequently, the charter of the IETF IPSEC WG was revised to target both IPv6 and IPv4, and the resulting security architecture had to be the same. The main difference is that the security mechanisms specified in the IP security architecture have to be retrofitted into IPv4 implementations, whereas they must be present in all IPv6 implementations at the beginning.

In August 1995, the IETF IPSEC WG published a series of RFC documents that collectively specified a first version of the IP security architecture and the IPSP [7–11]. This version was incomplete and rushed to publication mainly to satisfy a perceived industry need. Nevertheless, the IESG approved the IPSP specification to enter the Internet standards track as a Proposed Standard, and the participants of the IETF IPSEC WG continued their work to refine the IP security architecture and the IPSP specification, as well as to standardize the IKMP [12, 13]. As explained later in this chapter, the discussion on the standardization of the IKMP was very controversial. In the end, two protocol proposals, namely, the Internet Security Association and Key Management Protocol (ISAKMP) and the OAKLEY Key Determination Protocol, were merged to become the IKMP. Furthermore, the acronym IPSP was replaced with the term IPsec protocols (as it consists of two subprotocols), and the acronym IKMP was replaced with the term Internet Key Exchange (IKE). Consequently, the IP security architecture as we understand it today comprises both a series of IPsec protocols and an IKE protocol.

In November 1998, the IETF IPSEC WG published a series of RFC documents that collectively specify a revised version of the IP security architecture [14], including revised versions of the IPsec [15–20] and IKE [21–23] protocols.^[6] In addition, an informational RFC was published that provides a road map for the various documents that are released under the auspices of the IETF IPSEC WG [24]. Further information about the current status of the various protocol specifications can be found on the home page of the IETF IPSEC WG.^[7]

Soon after the release of the revised series of RFC documents, it was realized that two topics deserved further study:

The use of policies in IPsec environments;
The use of IPsec technologies to secure remote access services.

In early 2000, the IETF chartered an IP Security Policy (IPSP)^[8] WG to address the first topic and an IP Security Remote Access (IPSRA)^[9] WG to address the second topic. As of this writing, the two WGs are still in the process of defining their aims and scope, as well as their goals and milestones. Consequently, their work is not further addressed in this book. You may refer to the home pages of the two WGs to get an overview about the current status of their work.

^[6]As of this writing, the protocol specifications refer to Proposed Standards.

^[7]http://www.ietf.org/html.charters/ipsec-charter.html

^[8]http://www.ietf.org/html.charters/ipsp-charter.html

^[9]http://www.ietf.org/html.charters/ipsra-charter.html

Team-Fly