7.8 Network Layer Security: IPsec
Having examined case studies of the use of various security mechanisms
at the application, socket, and transport layers, our final case study
naturally takes us down to the network layer. Here, we'll examine the the
IP Security protocol, more commonly known as IPsec - a suite
of protocols that provides security at the network layer. IPsec is a rather
complex animal, and different parts of it are described in more than a
dozen RFCs. In this section, we'll discuss IPsec in a specific context,
namely, in the context that all hosts in the Internet support
IPsec. Although this context is many years away, the context will simplify
the discussion and help us understand the key features of IPsec. Two key
RFCs are [RFC 2401], which describes the overall
IP security architecture and [RFC 2411], which
provides an overview of the IPsec protocol suite and the documents describing
it. A nice introduction to IPsec is given in [Kessler].
Before getting into the specifics of IPsec, let's step back and consider
what it means to provide security at the network layer. Consider first
what it means to provide network layer secrecy. The network layer
would provide secrecy if all data carried by all IP datagrams were
encrypted. This means that whenever a host wants to send a datagram,
it encrypts the data field of the datagram before shipping it out into
the network. In principle, the encryption could be done with symmetric
key encryption, public key encryption or with session keys that have are
negotiated using public key encryption. The data field could be a TCP segment,
a UDP segment, an ICMP message, etc. If such a network layer service
were in place, all data sent by hosts -- including e-mail, Web pages,
control and management messages (such as ICMP and SNMP) -- would be hidden
from any third party that is "wire tapping" the network. (However, the
unencrypted data could be snooped at points in the source or destination
hosts.) Thus, such a service would provide a certain "blanket coverage"
for all Internet traffic, thereby giving all of us a certain sense of security.
In addition to secrecy, one might want the network layer to also provide
source
authentication. When a destination host receives an IP datagram with
a particular IP source address, it might authenticate the source by making
sure that the IP datagram was indeed generated by the host with that IP
source address. Such a service prevents attackers from spoofing IP addresses.
In the IPsec protocol suite there are two principal protocols: the Authentication
Header (AH) protocol and the Encapsulation Security Payload (ESP)
protocol. When a source host sends secure datagrams to a destination
host, it does so with either the AH protocol or with the ESP protocol.The
AH protocol provides source authentication and data integrity but does
not provide secrecy. The ESP protocol provides data integrity and secrecy.
Providing more services, the ESP protocol is naturally more complicated
and requires more processing than the AH protocol. We'll discuss both of
these protocols below.
For both the AH and the ESP protocols, before sending secured datagrams
from a source host to a destination host, the source and network hosts
handshake and create a network layer logical connection. This logical channel
is called a security agreement (SA). Thus, IPsec transforms the
traditional connectionless network layer of the Internet to a layer with
logical connections! The logical connection defined by a SA is a simplex
connection, that is, it is unidirectional. If both hosts want to send secure
datagrams to each other, then two SAs (i.e., logical connections) need
to be established, one in each direction. A SA is uniquely identified by
a 3-tuple consisting of:
-
a security protocol (AH or ESP) identifier;
-
the source IP address for the simplex connection;
-
a 32-bit connection identifier called the Security Paramter Index (SPI).
For a given SA (that is, a given logical connection from source host to
destination host), each IPsec datagram will have a special field for the
SPI. All of the datagrams in the SA will use the same SPI value in this
field.
Authentication Header (AH) Protocol
As mentioned above, the AH protocol provides source host identification
and data integrity but not secrecy. When a particular source host wants
to send one or more datagrams to a particular destination, it first establishes
an SA with the destination. After having established the SA, the
source can send secured datagrams to the destination host. The secured
datagrams include the AH header, which is inserted between the original
IP datagram data (e.g., a TCP or UDP segment) and the IP header, as shown
in Figure 7.8-1. Thus the AH header augments the original data field, and
this augmented data field is encapsulated as a standard IP datagram. For
the protocol field in the IP header, the value 51 is used to indicate that
the datagram includes an AH header. When the destination host recieves
the IP datagram, it takes note of the 51 in the protocol field, and processes
the datagram using the AH protocol. (Recall that the protocol field in
the IP datagram is traditionally used to distinguish between UDP, TCP,
ICMP, etc.) Intermediate routers process the datagrams just as they always
have -- they examine the destination IP address and route the datagrams
accordingly.
Figure 7.8-1: Position of the AH header in the IP datagram.
The AH header includes several fields, including:
-
Next Header field, which has the role that the protocol field has
for an ordinary datagram. It indicates if the data following the AH header
is a TCP segment, UDP segment, ICMP segment, etc. (Recall that protocol
field in the datagram is now being used to indicate the AH protocol, so
it can no longer be used to indicate the transport-layer protocol.)
-
Security Parameter Index (SPI) field, an arbitrary 32-bit value
that, in combination with the destination IP address and the security protocol,
uniquely identifies the SA for the datagram.
-
Sequence Number field, a 32-bit field containing a sequence number
for each datagram. It is initally set to 0 at the establishment of an SA.
The AH protocol uses the sequence numbers to prevent playback and man-in-the-middle
attacks (see Section 7.3).
-
Authentication Data field, a variable-length field containing signed
message digest (i.e., a digital signature) for this packet. The message
digist is calculated over the original IP datagram, thereby providing source
host authentication and IP datagram integrity. The digital signature is
computed using the authentication algorithm specified by the SA, such as
DES, MD5 or SHA.
When the destination host receives an IP datagram with an AH header, it
determines the SA for the packet and then authenticates the integrity of
the datagram by processing the authentication data field. The IPsec authentication
scheme (for both the AH and ESP protocols) uses a scheme called HMAC, which
is an encrypted message digest described in [RFC
2104]. HMAC uses a shared secret key between two parties rather than
public key methods for message authentication. Further details about the
AH protocol can be found in [RFC 2402].
The ESP Protocol
The ESP protocol provides network layer secrecy as well as source host
authentication. Once again, it all begins with a source host establishing
a SA with a destination host. Then the source host can send secured datagrams
to the destination host. As shown in Figure 7.8-2, a secured datagram is
created by surrounding the original IP datagram data with header and trailer
fields, and then inserting this encapsulated data into the data field of
an IP datagram. For the protocol field in the header of the IP datagram,
the value 50 is used to indicate that the datagram includes an ESP header
and trailer. When the destination host recieves the IP datagram, it takes
note of the 50 in the protocol field, and processes the datagram using
the ESP protocol. As shown in Figure 7.8-2, the original IP datagram data
along with the ESP Trailer field are encrypted. Secrecy is provided with
DES-CBC encryption [RFC 2405]. The ESP header
consists of a 32-bit field for the SPI and 32-bit field for the sequence
number, which have exactly the same role as in the AH protocol. The trailer
includes the Next Header field, which also has exactly the same role. Note
that because the Next Header field is encrypted along with the original
data, an intruder will not be able to determine the transport protocol
that is being used. Following the trailer there is the Authentication Data
field, which again serves the same role as in the AH protocol. Further
details about the AH protocol can be found in [RFC
2406].
Figure 7.8-2: The ESP fields in the IP datagram.
SA and Key Management
For sucessful deployment of IPsec, a scalable and automated SA and key
management scheme is necessary. Several protocols have been defined for
these tasks, including:
-
The Internet Key Exchange (IKE) algorithm [RFC 2409]
is the default key management protocol for IPsec.
-
The Internet Security Assoication and Key Management Protocol (ISKMP) defines
procedures for establishing and tearing down SAs [RFC
2407] [RFC 2408]. ISKMP's security association
is completely separate from IKE key exchange.
This wraps up our summary of IPsec. We have discussed IPsec in the context
of IPv4 and the "transport mode". IPsec also defines a "tunnel mode," in
which routers introduce the security functionality rather than the hosts.
Finally, IPsec describes encryption procedures for IPv6 as well as IPv4.
References
[Kessler] G.C. Kessler, An Overview of Cryptography,
May 1998, Hill Associates, http://www.hill.com/TechLibrary/index.htm
[RFC 2104] H. Krawczyk, M.Bellare, R. Canetti,
HMAC: Keyed-Hashing for Message Authentication, [RFC
2104], February 1997.
[RFC 2401] S. Kent and R. Atkinson, Security
Architecture for the Internet Protocol, [RFC
2401], November 1998.
[RFC 2402] S. Kent and R. Atkinson, IP Authentication
Header, [RFC 2402],
November 1998.
[RFC 2405] C. Madson and N.Doraswamy, The
ESP DES-CBC Cipher Algorithm with Explicit IV, [RFC
2405], November 1998.
[RFC 2406] S. Kent and R. Atkinson, IP Authentication
Header, [RFC 2406],
November 1998.
[RFC 2407] D. Piper, The Internet IP Security
Domain of Interpretation for ISAKMP, [RFC
2407], November 1998
[RFC 2408] D. Maughan, M. Schertler, M. Schneider
and J. Turner, Internet Security Association and Key Management Protocol
(ISAKMP), [RFC 2408],
November 1998.
[RFC 2409] D. Harkins and D. Carrel, The Internet
Key Exchange (IKE), [RFC
2409], November 1998
[RFC 2411] R. Thayer, N. Doraswamy and R.
Glenn, "IP Security Document Road Map," [RFC
2411], November 1998
Copyright 1999-2000 . Keith W. Ross and Jim Kurose. All rights
reserved.