Erich Chen
Alex Stewart
COEN 150 – Dr. Holliday
May 17, 2004
Internet Protocol Security
Security has become a very important aspect of computer engineering. It has
always been somewhat important, but in recent years the number of attacks and hacks
into systems seems to have increased greatly. Many programs try to compensate for this
by adding additional security at the application layer of the network stack. While this is a
possible solution, it often generates a large amount of overhead that could be avoided if
implemented at a lower level. IP security, or IPsec, tries to solve this problem by
implementing more advanced security measures at the network layer.
Before going into the details of internet protocol security, a little background as to
what the mechanisms are protecting is in order. The Internet Protocol (IP) is the standard
that defines the manner in which the network layers of two hosts interact. It was
designed from the beginning with inter-networking in mind. Each computer on the
Internet has at least one IP address that uniquely identifies it from all other computer on
the Internet. When a person sends or receives data (for example, going to a website), the
message gets divided into little chunks called packets, or datagrams. Each of these
packets contains both the sender’s Internet address and the receiver’s address. Any
packet is sent first to a gateway computer that understands a small part of the Internet.
The gateway computer reads the destination address and forward the packet to an
adjacent gateway that in turn reads the destination address and the pattern continues until
one gateway recognizes the packet as belonging to a computer within its immediate
domain. That gateway then forwards the packet directly to the desired computer.
Because a message is divided into a number of packets, each packet can, if
necessary, be sent by a different route across the Internet. Packets can get lost or arrive
in a different order than the order they were sent in. The Internet Protocol just delivers
them. It is up to the Transmission Control Protocol (TCP) to ensure reliability, and put
them back in the correct order. That is why the Internet is referred to as using the TCP/IP
protocol because it uses both protocols to send and receive complete and accurate
messages. IP is a connectionless protocol, which means that there is no continuing
connection between the end points that are communicating. Each packet that travels
through the Internet is treated as an independent unit of data without any relation to any
other packet. In the Open Systems Interconnection (OSI) communication model, IP is in
Layer 3, the Networking Layer.
The most widely used version of IP today is Internet Protocol 4 (IPv4). However,
IP Version 6 (IPv6) is also beginning to be supported. IPv6 provides for much longer
addresses and therefore for the possibility of many more Internet users. IPv6 includes the
capabilities of IPv4 and any server that can support IPv6 packets can also support IPv4
packets. (searchNetworking.com)
Before getting too far ahead, Internet protocol has been around for a while. IPs
were first developed in the mid-1970s, when the Defense Advanced Research Projects
Agency (DARPA) became interested in establishing a packet-switched network that
would facilitate communication between dissimilar computer systems at research
institutions. The result of this development effort was the Internet protocol suite,
completed in the late 1970s. TCP/IP later was included with Berkeley Software
Distribution (BSD) UNIX and has since become the foundation on which the Internet and
the World Wide Web (WWW) are based. (cisco.com)
As said before, Internet Protocol is a best-effort packet delivery service. It means
that packets might be discarded during transmission, but not without a good reason.
Erratic packet delivery is normally caused by the exhaustion of resources or a failure at
the data link or physical layer. In a highly reliable physical system such as an Ethernet
LAN, the best-effort approach of IP is sufficient for transmission of large volumes of
information. In the geographically distributed and highly diverse Internet, which is
subject to many vagaries of operation, IP delivery is insufficient and needs to be
augmented by a higher level protocol, such as TCP, to provide satisfactory performance.
If less reliability is acceptable and a higher speed is required, then the User Datagram
Protocol (UDP) is used instead at the transport layer. (acm.org)
Currently, for Internet Protocol version 4, all IP packets or datagrams contain
fourteen fields of information.
Version indicates the version of IP currently used. IP Header Length (IHL) indicates the
datagram header length in 32-bit words. Type-of-Service specifies how an upper-layer
protocol would like a current datagram to be handled, and assign datagrams various
levels of importance. Total Length specifies the length, in bytes, of the entire IP packet,
including the data and header. Identification contains an integer that identifies the current
datagram. This field is used to help piece together datagram fragments. Flags consists of
a 3-bit field of which the two low-order bits control fragmentation. The low-order bit
specifies whether the packet can be fragmented. The middle bit specifies whether the
packet is the last fragment in a series of fragmented packets. Fragment Offset indicates
the position of the fragment’s data relative to the beginning of the data in the original
datagram, which allows the destination IP process to properly reconstruct the original
datagram. Time-to-Live maintains a counter that gradually decrements down to zero, at
which point the datagram is discarded. This keeps packets from looping endlessly.
Protocol indicates which upper-layer protocol receives incoming packets after IP
processing is complete. Header Checksum helps ensure IP header integrity. Source
Address specifies the sending node. Destination Address specifies the receiving node.
Options allows IP to support various options, such as security. And finally, Data
contains upper-layer information. (cisco.com)
Knowing what the characteristics of the old version are, IP version 6 is a new
version of the Internet Protocol, designed as the successor to IP version 4. The changes
from IPv4 to IPv6 fall primarily into five categories: expanded addressing capabilities,
header format simplification, improved support for extensions and options, flow labeling
capability, and authentication and privacy capabilities. The first category, expanded
addressing capabilities, is the direct solution to the problem of the old IP version. IPv6
increases the IP address size from 32 bits to 128 bits, to support more levels of addressing
hierarchy, a much greater number of addressable nodes, and simpler auto-configuration
of addresses. The scalability of multicast routing is improved by adding a “scope” field
to multicast addresses. And a new type of address called an “anycast address” is defined,
used to send a packet to any one of a group of nodes.
In addition to solving the numbers problem, IPv6 added other features to improve
on the old version. Some IPv4 header fields have been dropped or made optional, to
reduce the common-case processing cost of packet handling and to limit the bandwidth
cost of the IPv6 header. Changes in the way IP header options are encoded allows for
more efficient forwarding, less stringent limits on the length of options, and greater
flexibility for introducing new options in the future. A new capability is added to enable
the labeling of packets belonging to particular traffic “flows” for which the sender
requests special handling, such as non-default quality of service or “real-time” service.
And finally, extensions to support authentication, data integrity, and (optional) data
confidentiality are specified for IPv6. (isi.edu)
Now that the background has been laid, we can now go into detail as to how IP
security works, and protects this technology. There are two forms of IP security that can
be used to provide defense. Both forms of IPsec require a security association, which is a
“cryptographically protected connection” (Kaufman, p 423). Information about the
security association is stored at each end of the connection. This information includes
vital connection information such as the cryptographic key, the identity of the other end
of the connection, and the type of security being used.
Both forms of IP security require an IPsec header. One of the fields in both of the
headers is know as the Security Parameter Index (SPI). The SPI allows the user to look
up information about a security association in a user’s local security association database.
Any computer using IPsec must keep a running data base of security associations. This
database stores information on how to transfer data to a user, such as what cryptographic
key or sequence number to use. Without the database, there would be know way to tell
which security association belonged to which user. While it may seem like the SPI alone
would be enough to tell a user the information that they need, it is not always to case
because sometimes the SPI is not locally generated, such as in the case of receiving
multicast data, so it could overlap with existing SPI data.
There are two forms of IP security, each having a unique IPsec header. The most
common and useful of the headers is Encapsulating Security Payload (ESP). ESP allows
for either data encryption combined with integrity checking, integrity checking without
encryption, or encryption without checking integrity. The second header is
Authentication Header (AH). AH is good only for protecting the integrity of a message, it
provides no encryption. The two different headers, ESP and AH, can be used in tandem
to provide increased security.
ESP is able to provide integrity protection, so there is some debate as to whether
or not AH is even necessary or simply redundant. This is because of ESP’s ability to
provide integrity checking without encryption, which is what AH does as well. AH does
have one other major difference though, and that is that AH provides integrity checking
for some of the IP header fields, while ESP integrity checking does not use data from the
IP header at all. However, there seems to be little reason to protect the integrity of the IP
header, because changing an IP header is not particularly useful for hackers.
The ESP header is designed like the image above. As mentioned earlier, the SPI is
used to identify the security association. The sequence number is used to keep the order
in which replies are sent during in a secure communication. An initialization vector is
sometimes used by cryptographic algorithms, and the IV field’s size changes based on
which algorithm is used. The data field contains protected data. Padding is used to
compensate for the variable lengths of the previous two fields. Padding length is used to
determine the length of the padding field. The next header field points to the next ESP
header. Authentication data is used for ESP’s integrity check.
The AH header is designed like the image above. Similar to ESP, the next header
field points to the next AH header. Payload length is the size of the AH header. Again, as
mentioned earlier, the SPI is used to identify the security association. The sequence
number is used to keep the order in which replies are sent during in a secure
communication. Authentication data is used for AH’s integrity check.
There are two possibilities for attaching IPsec headers, referred to as “modes.”
The simplest mode, called Transport mode, inserts the IPsec header after the standard IP
header and before the rest of the packet data. The IP header version, either IPv4 or IPv6,
does not matter. Transport mode is most useful when connecting two computers to each
other, as opposed to other networking devices. Transport mode is not actually a necessary
part of IPsec, because Tunnel mode, which will be explained below, can perform the
same functions.
A more complicated mode, known as Tunnel mode, keeps the entire original IP
packet intact, places the IPsec header in front of the original packet, and then places a
new IP header in front of the IPsec header. This mode is most common between two
firewalls, or a firewall and a computer. An example might be an encrypted tunnel formed
between a firewall at Santa Clara University, and a firewall at UCLA. When a student at
Santa Clara wants to send data to someone at UCLA, the firewall would detect the data,
and forward it through the encrypted tunnel. “Tunnel mode is essential between firewalls
in order to preserve the original source and destination addresses” (Kaufman, p 426).
Some parts of IP security do have problems with existing network technology.
IPv4 uses 32-bit IP addresses, which means that with the explosion of the Internet the
number of unique IP addresses began to quickly dry up. IPv6 is designed to use 128-bit
addresses, but while it was being developed a temporary solution had to be implemented
to prevent a deadlock of addresses. That temporary solution was Network Address
Translation (NAT). NAT allows IP address on the inside of a local area network to be
routed to a single IP address on the Internet.
NAT causes a problem for IPsec in several places, although it primarily affects
AH. In fact, AH cannot work with NAT in either Tunnel or Transport mode. This is due
to the fact that AH includes part of the IP header in its integrity check, so when a NAT
router changes that information the integrity check will always fail. It is believed by some
that this was done purposely in an attempt to speed up the removal of NAT from
networks, but it is more likely that NAT will kill AH because NAT is far more useful and
less redundant.
ESP is affected by NAT as well, but NAT does not break ESP like it does AH. In
Tunnel mode, ESP is able to verify the integrity of both the original IP header and the
original packet data. The verification of the original header is possible because no IP
header data is used in the check and the original header remains unmodified in most
respects. However, the new IP header cannot be verified, although this is relatively
unimportant because the original header is intact.
ESP can also work in transport mode when NAT is involved, but not in all cases.
The problem is that “Because NAT modifies the TCP/UDP packet, NAT must also
recalculate the checksum used to verify integrity. If NAT updates the checksum, ESP
authentication will fail. If NAT does not update the checksum, TCP/UDP verification
will fail.” (http://www.isp-planet.com/technology/nat_ipsec_p2.html) This problem can
be solved if you have the ability to turn of checksums, which assumes that one of the
endpoints is under your control. Since the integrity check does not involve data from the
IP header, it is still possible to verify the packet data.
There is still one problem which could prevent ESP from working when using
NAT. That problem is the Internet Key Exchange (IKE). IKE is a protocol that automates
the process of setting up the security association between two devices employing IPsec,
including mutual authentication and the creation of a private shared key. The most
common method authentication day involves using a pre-shared key. Unfortunately, that
key relies upon a packet’s source IP address. As we learned above, NAT tends to muddle
the source IP address, and it does so again here, causing the automated IKE to fail. There
are several work-arounds for this problem, including using a different method of IKE
authentication, or setting up IPsec at the source of the NAT. At this point in time, many
devices allow the latter, and have both NAT and IPsec built into the same component.
However, it is quite obvious that NAT is currently a major stumbling block for IP
security.
For several reasons, IP security is often linked with IPv6, and thought to be
impossible for IPv4. One of the primary reasons is listed above, which is that IPv4 has
caused the propagation of NAT devices. Another reason is that IPv6 documents state that
IPsec is a requirement, while IPv4 documents make no such claim. In reality, IPsec is
independent of the IP version, and works equally well on both. This is not to say that
IPsec works transparently, but rather both IPv4 and IPv6 were considered equally when
writing the IPsec standard.
Another reason IP security is often linked with IPv6 is that many of the same
people worked on both projects. In fact, the AH header looks very similar to the IPv6
header, the only difference being that the AH header’s length field uses different units
than IPv6. On that same note, IPv6 supporters hate NAT, because it slows down the
spread of IPv6. This may be the primary reason for keeping AH, because it won’t work
with NAT and may cause some users to make the switch. This is possibly the source of
many of the false rumors that IPsec doesn’t work with IPv4 as well.
It is probably obvious by now that IP security is tricky business, mostly because
of the state of the technology it is being introduced into. If IPsec was launched on a brand
new clean Internet running IPv6 everything would smooth sailing. However, what makes
the Internet great, its openness and versatility, also makes it very difficult to implement
new technologies like IPsec. Additionally, despite many of the industries best efforts,
politics still seemed to play a part in the decisions on what to include in IPsec, as
demonstrated by AH. In a quote from Kaufman, Perlman, and Speciner’s book Network
Security, “At one of the final IETF meetings before AH and ESP were finalized, someone
from Microsoft got up and gave an impassioned speech about how AH was useless given
the existence of ESP.... Our impression of what happened next was that everyone in the
room looked around at each other and said, ‘Hmm. He’s right, and we hate AH also, but
if it annoys Microsoft let’s leave it in, since we hate Microsoft more than we hate AH.’”
Security implemented at the network layer, protecting Internet Protocol, improves
the safety of the Internet as a whole. In addition, it will allow applications to focus on the
advanced aspects of security instead of the basics because IPsec will employ those
measures inherently. IPsec provides the same level of security in both IP version 4 and
IP version 6, but for now Network Address Translation creates a major obstacle in
successfully using IPsec with IPv4. Once IP version 6 has taken over as the dominant
internet protocol, IPsec will become more useful because of its ease of implementation
with the new internet protocol version.
Bibliography
Deering, S. (1998) Internet Protocol, Version 6 (IPv6) Specification.
ftp://ftp.isi.edu/in-notes/rfc2460.txt
Cisco. (2002) Internet Protocols.
http://www.cisco.com/univercd/cc/td/doc/cisintwk/ito_doc/ip.htm
Gulati, Shvetima. (2000) The Internet Protocol.
http://www.acm.org/crossroads/columns/connector/july2000.html
Hinden, Robert. (1995) IP Next Generation Overview.
http://playground.sun.com/pub/ipng/html/INET-IPng-Paper.html
Kaufman, Charlie, Radia Perlman, Mike Speciner. (2002) Network Security: Private
Communication in a Public World. New Jersey: Prentice Hall PTR.
IETF. (2004) IP Security Protocol. http://www.ietf.org/html.charters/ipsec-charter.html
IPsec Working Group. (2004) IP Encapsulating Security Payload.
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-esp-v3-08.txt
IPsec Working Group. (2004) Negotiation of NAT-Traversal in the IKE.
http://www.ietf.org/internet-drafts/draft-ietf-ipsec-nat-t-ike-08.txt
mpier1213, bbarrera. (2004) IPSEC: AH/ESP and NAT.
http://www.broadbandreports.com/forum/remark,9811701~mode=flat
Network Working Group. (1998) IP Authentication Header.
http://www.ietf.org/rfc/rfc2402.txt
Phifer, Lisa. (2000) IP Security and NAT: Oil and Water?
http://www.isp-planet.com/technology/nat_ipsec.html
SearchNetworking. (2004) Internet Protocol.
http://searchnetworking.techtarget.com/sDefinition/0,,sid7_gci214031,00.html