FREE ESSAY ON TCP/IP SECURITY

TCP/IP SECURITY

TCP/IP Security
The TCP/IP protocols, the basis for today's Internet, lack even the most basic mechanisms
for security, such as authentication or encryption. As usage of the Internet and TCP/IP
protocols increases, their lack of built-in security has become more and more
problematic. This paper describes a variety of basic flaws in TCP/IP protocols and their
implementations, and discusses solutions and work-arounds to these problems. Also covered
is the new IPv6, the next-generation Internet protocol that, among other goals, seeks to
fix many of the current flaws in the current Internet IPv4 protocol. Security in
protocols and applications not essential to TCP/IP (such as HTTP, FTP, and SMTP) are not
discussed in this paper.
Introduction
In the early 1980's, specifications were finished for the TCP and IP protocols. These two
protocols could be considered the most important in the world today - they are the basis
of the Internet. Over the past decade, the Internet has grown from a small network
connecting a small community of researchers to its present state - a gigantic global
network connecting people of all types. The huge success of the Internet has, for the
most part, been quite beneficial. The Internet has evolved from a specialized project to
a general-purpose tool. However, the growth of the Internet has created problems with
security. The TCP and IP protocols were designed when the Internet was small, and users
generally trusted each other. The protocols lack many features that are desirable or
needed on an insecure network. In this paper, we present a number of problems that arise
with using TCP/IP on today's network, solutions or work-arounds for these problems, and
how the protocols for tomorrow's Internet, such as IPv6, will help eliminate these
problems. 
1. Introduction to TCP/IP 
TCP/IP is the backbone of the internet today. Comprised of two protocols, TCP and IP, the
TCP/IP protocol suite is one of the most widely used. We present a brief introduction to
the two protocols. For a detailed discussion of the two protocols we refer the reader to
the RFC's for IP [RFC 791], and TCP [RFC 793]. 
1.1. Internet Protocol 
The Internet Protocol (or IP as it generally known), is the network layer of the
Internet. IP provides a connection-less service. The job of IP is to route and send a
packet to the packet's destination. IP provides no guarantee whatsoever, for the packets
it tries to deliver. The IP packets are usually termed datagrams. The datagrams go
through a series of routers before they reach the destination. At each node that the
datagram passes through, the node determines the next hop for the datagram and routes it
to the next hop. Since the network is dynamic, it is possible that two datagrams from the
same source take different paths to make it to the destination. Since the network has
variable delays, it is not guaranteed that the datagrams will be received in sequence. IP
only tries for a best-effort delivery. It does not take care of lost packets; this is
left to the higher layer protocols. There is no state maintained between two datagrams;
in other words, IP is connection-less. Version IHL Type of Service Total Length 
Identification Flags Fragmentation Offset 
Time to Live Protocol Header Checksum 
Source Address 
Destination Address 
Options Padding 
Figure 1. IP Header 
The IP Header is shown in Figure 1. The Version is currently set to 4. In order to
distinguish it from the new version IPv6, IP is also referred to as IPv4. The source
address and the destination address are 4-byte Internet addresses. The Options field
contains various options such as source based routing, and record route. The source based
routing allows the sender to specify the path the datagram should take to reach the
destination. Record route allows the sender to record the route the datagram is taking.
None of the IP fields are encrypted and there no authentication. It would be extremely
easy to set an arbitrary destination address (or the source address), and IP would send
the datagram. The destination has no way of ascertaining the fact that the datagram
actually originated from an IP address other than the one in the source address field. It
is easy to see why any authentication scheme based on IP-addresses would fail.
1.2. Transmission Control Protocol 
Transmission Control Protocol (TCP) runs on top of IP, and provides a connection oriented
service between the sender and the receiver. TCP provides guaranteed delivery, and
ensures that the packets are delivered in sequence. The underlying network IP, is highly
unreliable and does not provide any guarantee for TCP. In order to provide reliability
between the sender and the receiver, TCP uses various mechanisms, such as sequence
numbers, acknowledgments, 3-way handshakes and timers. 
A TCP connection is identified by the 4-tuple ((destination-ip-address,
destination-port), (source-ip-address, source-port)). Ports are the actual end-points of
the TCP connection. The working of TCP could be described using a TCP state machine. (see
Figure 5). Transitions to different states are based on events received in the form of
TCP segments. The TCP states are very closely associated with timers. There are various
timers associated with connection establishment (or termination), flow control, and
retransmission. 
In order to understand the security problems associated with TCP, it is necessary that we
look at the state-machine in detail. It is also important to get an overview of TCP
implementations, and how they implement the TCP state-machine, the state-transitions and
the associated timers. 
The TCP layer on either end maintains table entries corresponding to the 4-tuple
(remote-ip-address, remote-port, source-ip-address, source-port). This 4-tuple uniquely
identifies a connection. For every connection, the end-systems implementing TCP need to
keep the TCP state information for the duration of the connection. 
1.3. TCP Sequence Numbers 
TCP is run over an unreliable IP, and IP does not guarantee delivery of packets, and does
not necessarily deliver the packets in sequence. Delayed packets showing up is not
uncommon. Given these conditions, TCP does not make any assumptions about the underlying
network. In order to identify packets and ensure that they are delivered to the
application layer in order, the sequence number is an important component of every TCP
segment. Every byte of data that TCP sends is given a sequence number. By doing this, the
sender and receiver can verify whether the data was delivered correctly. They can also
determine whether data was dropped, possibly because of loss in transit. 
Both the sender and the receiver exchange initial sequence numbers (ISN) during the
connection setup phase. After a successful initial handshake, both the sender and the
receiver know the sequence numbers that they have to use for communication. Since TCP
allows for delayed segments, it must accept segments that are out of sequence, but within
certain bounds, known as the receiver window size. The receiver window size is also
exchanged during the initial handshake. TCP will discard all segments that do not have a
sequence number within the computed bounds. 
The TCP sequence number is a 32-bit counter. In order to distinguish between different
connections between the same sender and receiver, it is important that the sequence
numbers do not start at 0 or any other fixed number each time a connection is opened.
Hence, it is important that the first byte of data from the sender to the receiver is
using a random sequence number. Current implementations increment the sequence number by
a finite amount every second. 
1.4.TCP Header 
Every TCP segment must contain a TCP header. The header format is the same for all TCP
segments ( Figure 2). The header contains the source and destination port. The sequence
number identifies the first byte of data following the header. The acknowledgment number
indicates an acknowledgment up to (acknowledgment - 1) bytes by the receiver. There are
six flag bits in the header, namely URG, ACK, PSH, RST, SYN and FIN. One or more of the
flags can be set in any segment header. 16-bit source port number 16-bit destination
number 
32-bit sequence number 
32-bit acknowledgment number 
header length and flags 16-bit window size 
16-bit TCP checksum 16-bit urgent pointer 
Options (if any) 
Data (if any) 
Figure 2. TCP header format 
The window size indicates the receiver window size, used for flow control. The TCP header
and the data are covered by the checksum. There are other optional fields, not relevant
to our discussion.
1.5. The Three Way Handshake 
Most network protocols follow the classical three way handshake to establish or terminate
connections over a not-so-reliable link. A initiates a connection to B by sending a
message. B responds with an acknowledgment. At this point, A sends another message back
to B confirming that A received B's acknowledgment. A and B connect successfully when B
receives the second message from A (confirming B's ack). The three way handshake is used
by TCP both to establish connections as well as to terminate the connections. When hosts
A and B want to communicate using TCP, they need to establish a connection using the
three-way handshake. Termination or closing a connection is also executed using the
three-way handshake. 
The hosts on either end identify their TCP connection with the other using the
(IP-address, port number) combination. A table entry is created on receiving the first
segment from the remote host which has all the parameters to identify the connection. 
1.6. Connection Setup 
TCP uses the 3-way-handshake to set up a successful connection. When host A wants to open
a connection to host B, A sends an initial segment to B. This initial segment has the
Initial Sequence Number (ISN) that B needs to use to send data to A. This initial segment
is identified by the SYN bit set to 1 in the TCP header. If the SYN bit is set, the
32-bit sequence number in the header is interpreted as the ISN. In all other cases (when
the SYN bit is not set), the 32-bit sequence number identifies the sequence number of the
first data byte contained in that segment. B on receiving the SYN from A, has to respond
with another SYN, as well acknowledge the SYN sent by A. This is indicated by SYN+ACK in
the state machine diagram. 
Figure 3. Initial Connection establishment. 
1.7. Connection release 
Connection release in TCP also uses the 3 way handshake. Connection release uses the FIN
in place of the SYN. 
Figure 4. Connection release in TCP
1.8. TCP Timers 
Timers are closely knit with the TCP states. Some values are specified by the RFC, but
not all. Some timers are left open to individual implementations. We will look at timers
relevant to our discussion, which include the timers at connection establishment, and at
connection termination. 
Connection Establishment Timer 
This timer is associated with the opening of a connection. It is started when the SYN is
sent during the initial connection setup. In most TCP implementations, the value of this
timer is set to 75 seconds. If a time-out occurs, the connection is aborted. 
FIN_WAIT timer
A FIN_WAIT_2 timer is started when there is a transition from the FIN_WAIT_1 state to the
FIN_WAIT_2 state. The value of this timer is 10 minutes. A TCP segment with a FIN bit set
is expected in the FIN_WAIT_2 state. If a packet with a FIN bit set is received, the
timer is cancelled. On expiration of the timer, it is restarted with a value of 75
seconds. The connection is dropped if no packet with the FIN bit arrives within this
period. 
TIME_WAIT timer
A Time-wait timer is started when the connection enters the TIME-WAIT state. This is to
allow all the segments in transit to be removed from the network. The value of the timer
is usually set to 2 minutes. On expiration of the timer, the connection is terminated. 
KEEP_ALIVE timer
TCP usually does not send anything over the connection if there is no data to send. There
is no way of distinguishing this silence from the case when the connection is broken. A
keep-alive timer can be set which allows TCP to periodically check whether the other end
of the connection is still active. The default value of this timer is 2 hours. After the
expiration of the timer, probes are sent to the remote end. The connection is dropped if
the remote does not respond to the probes. 
1.9. Problems with the TCP State machine 
The TCP statemachine is shown in Figure 5. There is a statemachine for every connection.
Each connection logically starts in the CLOSED state, and makes transitions as shown in
the diagram. After the connection is terminated, TCP returns to the CLOSED state. For a
detailed description of the statemachine, refer [RFC 793]. It is easy to exploit a few
flaws in the state-machines, and create denial-of-service attacks. All the
denial-of-service attacks created try to stall the TCP statemachine in a particular state
either indefinitely or for a finite time. 
Figure 5. TCP State Machine
(from TCP/IP Illustrated, Vol. 1 by W. Richard Stevens)
1.10. Absence of timers 
Looking at the state machine, we can see that there are no timers associated with certain
states. As noted earlier, TCP does not send any data on the connection, unless used with
a special option, the Keep-alive timer. This means that TCP state machine for a
connection could be made to stay at such states forever. Most implementations do not
implement timers for those states. An example of such a state is the CLOSE_WAIT state. If
the keep-alive timer is used, TCP would be able to reset the connection. The default
value of the keep-alive timer is set to 2 hours, which means that the state-machine is
frozen atleast for a period of 2 hours. 
1.11. Simultaneous connection establishment 
When two hosts, say A and B want to establish a connection and both of them
simultaneously initiate the handshake, we have a case of simultaneous connection
establishment [RFC 793]. Both hosts A and B send out SYN's to each other. When the SYN's
are received by the corresponding peers, both of them send out a SYN+ACK. Both hosts A
and B must detect that the SYN and SYN+ACK actually refer to the same connection. If both
hosts A and B detect that the SYN+ACK belongs to the SYN that was recently sent, they
switch off the connection establishment timer and move directly to the SYN_RECVD state.
This flaw could be used to stall a port on a host, using protocols such as FTP where the
server initiates a connection to the client. 
As an example, consider host X which has started a FTP connection to a server A. X and A
are connected using the control-port. A initiates the connection establishment procedure
to initiate data transfer with X. 
A sends a SYN to X, and makes a transition to SYN_SENT state. A also starts the
CONNECTION ESTABLISHMENT timer. 
X receives the SYN, and responds back with another SYN. 
When A receives the SYN from X, it assumes that this is a case of a simultaneous open
connection. So, it sends out SYN_ACK to X, switches off the connection establishment
timer, and transitions to the state SYN_RCVD. 
X receives the SYN_ACK from A, but does not send a reply. 
Since, A is expecting a SYN_ACK in the SYN_RCVD state, and there is no timer, A gets
stalled in SYN_RCVD state. 
Thus, X here is able to create a denial-of-service attack using this flaw in TCP.
1.12. SYN+FIN 
The TCP specification does not specify clearly certain transitions and hence allows for
some spurious state transitions. [Guha, Mukherjee]. These transitions could be used for a
variety of attacks, especially the denial-of-service attacks. As an example, we will look
at a scenario where a host receives a TCP segment with both the SYN and the FIN bit set.

On receiving a packet with the SYN and the FIN bit set, TCP makes a transition to the
CLOSE_WAIT state. There has been no successful connection establishment and hence TCP
should not be making such a transition. Most implementations do this because the
specifications have failed to address the issue. The transition is clearly a bad one,
since CLOSE_WAIT is a state with no timer associated. The receiver gets stalled in the
CLOSE_WAIT state. 
2. Problems in the TCP/IP protocol suite 
When TCP/IP was designed in the early 1980's, security was not a primary concern.
However, in the years since their inception, the lack of security in the TCP/IP protocols
has become more of a problem. The widespread use and availability of the TCP/IP protocol
suite has exposed its weaknesses. Presented here are a number of well-known
vulnerabilities of both TCP/IP itself, and of some protocols commonly used along with
TCP/IP (such as DNS). 
2.1. TCP SYN attacks 
In an Internet environment, high message latency and loss are not uncommon, resulting in
messages that arrive late or in nonsequential order. The TCP half of TCP/IP uses sequence
numbers so that it can ensure data is given to the user in the correct order, regardless
of when the data is actually received. These sequence numbers are initially established
during the opening phase of a TCP connection, in the three-way handshake. 
SYN attacks (also known as SYN Flooding) take advantage of a flaw in how most hosts
implement this three-way handshake [Guha, Mukherjee95]. When Host B receives the SYN
request from A, it must keep track of the partially opened connection in a listen queue
for at least 75 seconds. This is to allow successful connections even with long network
delays. The problem with doing this is that many implementations can only keep track of a
very limited number of connections (most track only 5 connections by default, though some
like SGI's IRIX track up to 1024 [Luckenbach96]). A malicious host can exploit the small
size of the listen queue by sending multiple SYN requests to a host, but never replying
to the SYN&ACK the other host sends back. By doing so, the other host's listen queue is
quickly filled up, and it will stop accepting new connections, until a partially opened
connection in the queue is completed or times out. This ability to effectively remove a
host from the network for at least 75 seconds can be used solely as a denial-of-service
attack, or it can be used as a tool to implement other attacks, like IP Spoofing. 
Figure 6. SYN Flooding
2.2. IP Spoofing 
IP Spoofing is an attack where an attacker pretends to be sending data from an IP address
other than its own [Morris85, Bellovin89]. The IP layer assumes that the source address
on any IP packet it receives is the same IP address as the system that actually sent the
packet -- it does no authentication. Many higher level protocols and applications also
make this assumption, so it seems that anyone able to forge the source address of an IP
packet (called spoofing an address) could get unauthorized privileges. 
However, there are two catches. The first catch is that all communication is likely to be
one-way. The remote host will send all replies to the spoofed source address -- not to
the host actually doing the spoofing. So, an attacker using IP spoofing is unlikely to
see output from the remote system (unless they have some other method of eavesdropping on
the network between the other two hosts). The second catch is that an attacker needs to
use the correct TCP sequence numbers if they plan on establishing a TCP connection with
the attacked host (most common services, like Telnet, FTP, and r-commands use TCP). The
final ACK in a three-way handshake must contain the other host's ISN, otherwise the
connection cannot complete; because the ISN in the SYN+ACK packet is sent to the real
host, an attacker must get this ISN by some other method. If the attacker could eavesdrop
on the packets send from the other host, he could see the ISN. Similarly, if the attacker
was unable to eavesdrop, but could somehow guess the other host's ISN, he can complete
the connection and conduct a one way conversation (this may be sufficient to initiate
some other form of two-way communication). Unfortunately for the TCP/IP community,
methods to overcome both challenges in IP Spoofing have been developed. 
2.2.1. Sequence Guessing 
The sequence number used in TCP connections is a 32 bit number, so it would seem that the
odds of guessing the correct ISN are exceedingly low. However, if the ISN for a
connection is assigned in a predictable way, it becomes relatively easy to guess. This
flaw in TCP/IP implementations was recognized as far back as 1985, when Robert Morris
described how to exploit predictable ISN's in BSD 4.2, a Unix derivative [Morris85]. In
BSD 4.2, the ISN for a connection is assigned from a global counter. This counter is
incremented by 128 each second, and by 64 after each new connection (i.e., whenever an
ISN is assigned). By first establishing a real connection to the victim, the attacker can
determine the current state of the system's counter. The attacker then knows that the
next ISN to be assigned by the victim is quite likely to be the predetermined ISN, plus
64. The attacker has an even higher chance of correctly guessing the ISN if he sends a
number of spoofed IP frames, each with a different, but likely, ISN. 
However, when the host receiving spoofed packets completes its part of the three-way
handshake, it will send a SYN&ACK to the spoofed host. This host will reject the SYN&ACK,
because it never started a connection -- the host indicates this by sending a reset
command (RST), and the attacker's connection will be aborted. To avoid this, the attacker
can use the aforementioned SYN attack to swamp the host it is imitating. The SYN&ACK sent
by the attacked host will then be ignored, along with any other packets sent while the
host is flooded. The attacker then has free reign to finish with his attack. Of course,
if the impersonated host happens to be off-line (or was somehow forced off-line), the
attacker need not worry about what the victim is sending out. 
Figure 7. IP Spoofing via Sequence Guessing 
Incrementing the ISN counter more often, as other operating systems may do, does not
appear to help. Even if the counter is incremented 250,000 times a second (as suggested
by the TCP standard), an attacker may still be able to approximately predict the ISN. By
repeatedly guessing, it is likely that the attacker will establish a connection with the
correct ISN within a few hours [Bellovin89]. 
2.2.2. Source Routing 
Another variant of IP spoofing makes use of a rarely used IP option, Source Routing
[Bellovin89]. Source routing allows the originating host to specify the path (route) that
the receiver should use to reply to it. An attacker may take advantage of this by
specifying a route that by-passes the real host, and instead directs replies to a path it
can monitor (e.g., to itself or a local subnet). Although simple, this attack may not be
as successful now, as routers are commonly configured to drop packets with source routing
enabled. 
Figure 8. Source Routing
2.3. Connecting Hijacking 
An interesting variant on IP spoofing allows a host to insert itself in the middle of a
connection between two hosts -- connection hijacking [Joncheray95]. IP spoofing alone may
not bypass additional security, such as authentication by the Unix password mechanism,
Kerberos, or one-time password systems like SKEY [RFC1760]. But with this attack, an
attacker can allow normal authentication to proceed between the two hosts, and then seize
control of the connection. 
Connection hijacking exploits a desynchronized state in TCP communication. When the
sequence number in a received packet is not the same as the expected sequence number, the
connection is said to be desynchronized. Depending on the actual value of the received
sequence number, the TCP layer may either discard or buffer the packet. There is a
choice, because TCP uses a sliding window protocol to allow efficient communication even
in the presence of packet loss and high network latency. So, if the received packet is
not the one expected, but is within the current window, the packet will be saved on the
premise that it will be expected later (various TCP mechanisms ensure that the expected
packet will eventually arrive). If the received packet is outside of the current window,
it will be discarded. 
Thus, when two hosts are desynchronized enough, they will discard (ignore) packets from
each other. An attacker can then inject forged packets with the correct sequence numbers
(and potentially modify or add commands to the communication). Obviously, this requires
the attacker to be located on the communication path between the two hosts so that he may
eavesdrop, in order to replicate packets being sent. The key to this attack is creating
the desynchronized state. Joncheray describes two possible ways to do this: one is during
the three-way handshake, and the other is in the middle of an established connection. 
Note that ignored packets may actually generate ACKs, rather than being completely
ignored. When the other end receives packets with incorrect sequence numbers, it replies
with an ACK packet containing the sequence number it is expecting. But the receiver of
these ACK discards them, as they have the wrong sequence numbers! The receiver then sends
its own ACK to notify the sender... Thus, a large number of ACKs are generated in this
attack. This signature of the attack could be used to detect connection hijacking. 
Figure 9. Connection Hijacking
2.3.1. Desynchronization during connection establishment 
In this form of desynchronization, the attacker resets a connection during the three-way
handshake. After host B sends the SYN&ACK packet to host A, the attacker forges new
packets from B (to A) in which the connection is first closed via the RST bit, and then a
new three-way handshake is initiated with A -- identical to the original, real handshake
but with different sequence numbers. Host B now ignores messages from A (because A is
using the attacker's new sequence numbers), and Host A ignores messages from B (because A
is expecting messages with the attacker's sequence numbers). 
The attacker then replicates new packets, with the correct sequence numbers, whenever A
and B try to communicate. In doing so, the attacker may also modify the messages or
inject his own.
2.3.2. Desynchronization in the middle of a connection 
The previous attack is limited to the initial connection. If a RST packet is sent in the
middle of a connection, the connection is closed -- and the application/user is notified
of this. To cause desynchronization in the middle of a connection, without closing the
connection, only the sequence number counters should be altered. The Telnet protocol, in
particular, provides an interesting mechanism to do this. Telnet allows special NOP
commands to be sent. These commands do nothing, but the act of sending the bytes in the
NOP command increments the expected sequence number counter on the receiver. By sending
enough of these NOP commands, an attacker can cause the connection to become
desynchronized. The attacker can then begin replicating new packets, with the correct
sequence numbers, as before.
2.4. Routing (RIP) attacks 
Although it is not strictly a component of TCP/IP, the Routing Information Protocol (RIP)
is often an essential component in a TCP/IP network [RFC1058]. RIP is used to distribute
routing information within networks, such as shortest-paths, and advertising routes out
from the local network. Like TCP/IP, RIP has no built in authentication, and the
information provided in a RIP packet is often used without verifying it. Attacks on RIP
[Bellovin89] are different from those of other common attacks because RIP attacks change
where data goes to, not where it came from. For example, an attacker could forge a RIP
packet, claiming his host X has the fastest path out of the network. All packets sent out
from that network would then be routed through X, where they could be modified or
examined. An attacker could also use RIP to effectively impersonate any host, by causing
all traffic sent to that host to be sent to the attacker's machine instead.
2.5. ICMP attacks 
The Internet Control Message Protocol (ICMP) is used by the IP layer to send one-way
informational messages to a host. One of the most common (and well-known) uses of ICMP is
the ping utility. This utility sends an ICMP Echo Request to a host, and waits for that
host to send back an ICMP Echo Reply message. Other messages in ICMP are of similar
complexity; that is, they are all quite simple. It's not surprising that there is no
authentication in ICMP, which leads to attacks using ICMP that can result in a denial of
service, or allowing the attacker to intercept packets [Bellovin89]. 
Denial of service attacks primarily use either the ICMP Time exceeded or Destination
unreachable messages. The Time exceeded message indicates that the Time-To-Live field in
the IP header has expired; this can normally be caused by routing loops or trying to
reach a host that is extremely distant. Destination unreachable messages can have several
meanings (based on a sub-field in the ICMP message), but all basically indicate that
packets cannot successfully be sent to the desired host. Both of these ICMP messages can
cause a host to immediately drop a connection (this is the desired result if the ICMP
message is legitimate). An attacker can make use of this by simply forging one of these
ICMP messages, and sending it to one or both of the communicating hosts. Their connection
will then be broken. 
ICMP messages can also be used to intercept packets. The ICMP Redirect message is
commonly used by gateways when a host has mistakenly assumed the destination is not on
the local network (and is thus attempting to send the packet via the gateway to). If an
attacker forges an ICMP Redirect message, it can cause another host to send packets for
certain connections through the attacker's host. This attack is similar to a RIP attack,
except that ICMP messages only apply to existing connections, and the attacker (the host
receiving redirected packets) must be on a local network.
2.6. DNS attacks 
The Domain Name Service (DNS) is a protocol widely used on the Internet. DNS is primarily
used to map hostnames (i.e. foo.bar.com) to IP addresses (i.e. 192.34.12.7), but it can
also be used to do the reverse; mapping IP addresses to hostnames. An attacker can use
the latter property to fool name-based authentication [Schuba, Spafford94; Bellovin89].
For example, an administrator at alice.bar.com may decide to allow only local
connections. This is often specified by name, such as allow *.bar.com, rather than by IP
address. Name-based authentication is easier to read, and allows easier administration if
a domain contains multiple ranges of IP addresses. When a connection is established with
alice.bar.com, alice uses DNS to convert the source IP address on the connection to a
name, which is then checked using whatever form of name-based authentication the
administrators have installed. If an attacker has access to their local DNS server, they
can cause DNS queries on their IP address to reply with any hostname and domain! So, an
attacker who knows that alice.bar.com trusts connections from within *.bar.com can alter
his DNS server so that his IP address appeared to map to trustme.bar.com. Today, this
attack is often prevented by performing a second DNS query on the hostname returned by
the first query. If the IP address returned by the second query does not match the source
IP address from the original connection, the host knows that a DNS attack is likely being
attempted. Proposals to modify DNS to include mechanisms to ensure data integrity and
authentication may also mitigate the vulnerabilities in DNS [RFC2065]
2.7. The lack of unique identifiers 
When the Internet was still young, back in the 1980's, one could use an IP address to
safely identify and locate a host. Addresses were both spatially unique (no one else had
an identical address) and temporally unique (addresses didn't change). However, this is
no longer the case [RFC2101]. Today, IP addresses may exhibit seemly strange behavior
that makes identifying and locating hosts much harder. The widespread use of protocols
such as PPP/SLIP [RFC1990] and DHCP [RFC1541] allow a specific host's address to change
over time: per-connection in the case of PPP/SLIP, while DHCP allows hosts to lease IP
addresses for arbitrary lengths of time. On even larger time scales, details in the
current Internet routing structure (i.e., Classless InterDomain Routing, CIDR [RFC1519])
may require that if a domain changes service providers, they will have to change their
assigned range of IP addresses. Firewalls, proxy socket servers, and other Network
Address Translators further complicate the use of IP addresses as identifiers, because
they may translate addresses as traffic moves between the internal and external networks.
Different hosts may appear to be using identical IP addresses, or different IP addresses
may be the same host. Thus, IP addresses can no longer be used to uniquely identify a
host, even over short time periods. Any security schemes which rely upon IP addresses
remaining temporally or spatially unique may have vulnerabilities. 
3. Solutions to Problems 
There are a plethora of papers discussing theoretical weaknesses in the TCP/IP protocol,
with more being published all the time. For each paper which warns readers about Security
Weakness X, there seems to be a corresponding chunk of code that some individual has
written which utilizes this weakness in real life, on actual computers. Corresponding to
the SYN flooding attack there is a SYNflood.c freely available for download, which, when
compiled and run, will attempt to deny all access to a target host by flooding it with
connection requests. There are packages (spoofit is one) which offer menu-driven
interfaces for connection-hijacking. Indeed, there are actual, working implementations of
all security weaknesses discussed so far. Going from the paper to the exploit, as the
implementations are known, is sometimes not a trivial task; it often requires significant
hands-on networking knowledge. The user of the exploit, on the other hand, is not
required to understand all the details; the exploits are often well-documented and
user-friendly. With more people downloading them every day, it is unremarkable that we
have seen an increase in break-ins over the last few years [Bellovin92]. 
Given that there are often well-written, easy to use implementations of the security
vulnerabilities discussed so far, it should come as no surprise that much effort has gone
into the elimination of these vulnerabilities. Since TCP/IP is the medium linking the
entire Internet together, it is easy to see that billions of dollars worth of hardware
are at risk here, discounting entirely the monetary worth of the information on those
machines. It would be very nice to squelch these vulnerabilities. Unfortunately, most of
the attacks described in this paper are based on inherent vulnerabilities in the TCP/IP
protocol; without reworking TCP/IP, there may be little that can be done! While this may
indeed be what eventually solves these problems, it is not a task to be undertaken
lightly; if there is any way to avoid having to rebuild the Internet with a new version
of TCP/IP, people will prefer it. Let's explore what can be done within the current
incarnation of TCP/IP.
3.1. Problems with Accepting Connections 
The SYN attacks described earlier are used as a denial-of-service attack to prevent
anyone from using a particular host. Often times, this is used as a stepping stone
towards a more complicated spoofing attack. This first stepping stone is one of the
inherent vulnerabilities in TCP/IP, based on what it was designed to do. 
As a connection-oriented protocol used to link together machines across the world, TCP/IP
must accept some variance in connection-times; i.e. the computers in New York expect to
make connections with other computers in New York as well as computers across the globe.
Since the time for messages to pass back and forth between the computers may vary, it is
reasonable to allow a generous amount of time for the connection to be completed. As long
as this amount of time is finite, then a nearby computer will be able to send a large
number of uncompleted connection-requests, and eventually tie up the target host. The
very fact that we want TCP/IP to be friendly and connect to computers of varying
distances means that these SYN attacks are difficult to eradicate completely. 
There are, however, some choices that can be made to decrease vulnerability. Increasing
the number of allowable outstanding connections can make more work for the attacker (or
dynamically allocating them instead of relying on a fixed maximum). Another practical
solution is to decrease the timeout period (currently 75 seconds) to something smaller,
thereby increasing the workload for the attacker again. In practice, these solutions may
reduce the vulnerability to something negligible, but it should be noted that so long as
the timeout period and maximum number of incomplete connections is finite, the problem
still exists. 
3.2. Problems with Authentication 
The utter lack of authentication with IP packets is a general weakness with TCP/IP. 
Without authentication, there really is no guarantee that a packet comes from where its
source field claims it comes from. This is the foundation of all IP spoofing and
consequently, the major issue in IP security. There are many different ways to capitalize
on this weakness; we have provided an overview of the problems that come about from the
lack of authentication, but our discussion of the myriad ways this may be taken advantage
of could never really be complete. 
Since a lack of authentication is the broadest, more crippling weakness in TCP/IP, we
would really like to clamp down on it as much as possible. Since the conventional IP
version 4 does not typically use authentication, it is not possible to completely
eradicate the threat in the most ideal way, by providing it at the IP level. However, we
cannot simply throw up our hands in defeat; there are several techniques we may employ to
blunt this weapon.
3.2.1. Preventing Sequence Guessing 
For host A to successfully impersonate host B in a connection with host C, A must be able
to acquire the sequence number which C sends back (to B). There are a number of ways to
get at this number, but one popular technique is to simply guess the number that will be
used. If we could prevent people from being able to guess the next sequence number used
for a connection based on the previous sequence number used in a connection, we would be
able to nip this problem in the bud. 
In Bellovin's paper, Security Problems in the TCP/IP Protocol Suite, he outlines an
essential problem with the TCP specifications, at least from a security standpoint.
Berkeley systems are extremely easy to analyze; their method of incrementing the sequence
counter by a constant value every second, and incrementing it by half that for every
connection established is trivial to anticipate. But the Berkeley system does not follow
TCP specifications, which require the variable to be incremented approximately 250,000
times per second. Perhaps if we followed the specifications for the protocol we could
eliminate sequence guessing. 
Let us consider whether a counter that operated at a true 250,000 hz rate would help. For
simplicity's sake, we will ignore the problem of other connections occurring, and only
consider the fixed rate of change of this counter. To learn a current sequence number,
one must send a SYN packet, and receive a response. The first spoof packet, which
triggers generation of the next sequence number, can immediately follow the server's
response to the probe packet. The sequence number used in the response is uniquely
determined by the time between the origination of the message and the receipt at the
server of the message. But this number is precisely the round-trip time between [spoofer]
and [server]. Thus, if the spoofer can accurately measure (and predict) that time, even a
4 microsecond clock will not defeat this attack.
How accurately can the trip time be measured? If we assume that stability is 
good, we can probably bound it within 10 milliseconds or so. Clearly, the Internet does
not exhibit such stability over the long-term, but it is often good enough over the short
term. There is thus an uncertainty of 2500 in the possible value for [the guessed
sequence number]. If each trial takes 5 seconds, to allow time to re-measure the
round-trip time, and intruder would have a reasonable likelihood of succeeding in 7500
seconds, and a near certainty within a day. More predictable (i.e., higher quality)
networks, or more accurate measurements, would improve the odds even further in the
intruder's favor. Clearly, simply following the letter of the TCP specification is not
good enough. [Bellovin89]
So it appears that even following the TCP specifications will not work. What can be done?
Bellovin goes on to suggest that we utilize a random number generator, which would make
things hopefully harder to analyze. He further suggests that DES could be used in place
of a random number generator, since it is well-studied, and the encryptions of an
incrementing counter are quite varied and difficult to predict. Of course, all methods of
generating pseudorandom numbers are subject to analysis; if nothing else, once the seed
is discovered, the whole sequence is known. Whatever we choose as a solution, we should
certainly avoid using a simple, easily predicted sequence number generator.
3.2.2. The Benefits of Firewalls 
A firewall can be a powerful tool in the prevention of would-be spoofers. Putting aside
the proxy-services normally offered by firewalls, we concentrate on the benefits derived
from packet filtering techniques. The important part about firewalls from an IP spoofing
perspective is that they clearly delineate outside the firewall from inside the firewall;
everything inside must go through the 'inside' port on the firewall, and everything
outside must come in through the 'outside' port [Ranum92]. This means that the packet
filtering done in the firewall can drop suspicious packets! Suppose the filter sees a
packet come from the outside that claims to have a source inside the firewall. It's a
spoofed packet, and should be dropped; it's claiming to come from inside, but it's coming
from outside [Chapman92]. Likewise, if some packet attempts to leave the firewall
claiming to be from anywhere other than inside the known subnet, it can be dropped
immediately as well [Ranum92]. In a sense, this sort of filtering partitions the Internet
into little zones, none of which can spoof each other. However, even with this sort of
filtering going on, spoofing within the subnet cannot be prevented. 
3.2.3. The Benefits of TCP Wrappers 
Additional protection against authentication weaknesses can be gained from the use of TCP
wrappers. A TCP wrapper is a small program run in place of the services which the inet
daemon normally starts. For example, with TCP wrappers in place, when a user attempts to
rlogin, the standard rlogin program is not run directly; first, the tiny wrapper program
is run, which performs some security functions, and then, assuming everything checks out,
the actual rlogin program is run. These are a trivial thing to install, nothing like the
implementation of a firewall. 
A typical implementation provides tiny daemon wrapper programs that can be installed
without any changes to existing software or to existing configuration files. The wrappers
report the name of the client host and of the requested service; the wrappers do not
exchange information with the client or server applications, so are essentially invisible
to the users. [Venema92]
The usual benefit gained from installing a wrapper is that you can log information about

which users are requesting which services, and track suspicious behavior, or suspected
persons. Venema discusses how it is possible to add tripwires to the TCP wrapper
packages; instead of merely dropping users who are attempting to use some service when
they shouldn't, one can reverse-finger them to gain additional tracking information. Or,
one can turn on a more stringent security standard, expecting an attack. And there are
some added perks which help defeat some forms of spoofing: some of the inet services,
notably rsh and rlogin, rely on name-based authentication, which can be spoofed [Schuba
and Spafford94]. If a local copy of names and addresses is available, a TCP wrapper can
verify that someone starting up rsh or rlogin has an IP address that agrees with the name
they claim. Also, it is likely that a machine may not have local tables, and might have
to ask DNS for a name-IP correspondence... this leaves the machine very vulnerable to
anyone doing DNS spoofing. A TCP wrapper can be configured to ask multiple DNS servers
for the correspondence and wait for consensus. 
The benefits that can be gained from TCP wrappers are not in any way impregnable armor;
the consensus is that they are not useful in preventing the general case of IP spoofing.
However, they do provide some armor against specific variations on the spoofing problem,
and they provide a space for extra checks to be inserted where they may not be expected.
For a further discussion of this topic, see [Venema92].
3.2.4. Add-On Authentication: Kerberos 
Another method of limiting an attacker's spoofing abilities is to add authentication onto
the application layer. Of course, just adding authentication is not enough without adding
encryption; otherwise, after some initial application-level authentication, a hijacking
attack may still be successful. An authentication between two parties which exchanges a
session key, however is secure; even though the IP packets transmitted back and forth are
not individually authenticated, they are all encrypted with the secure session key. This
scheme is the goal of the Kerberos Authentication System, developed at MIT. The Kerberos
system uses cryptographic authentication algorithms to ensure that a user is really who
s/he claims to be, and once this is established, an exchanged session key is used to
encrypt all transmissions of whatever service the user has requested. Without knowledge
of this session key, it is impossible for an attacker to spoof meaningful transmissions
between sources. Since this key is generated based on secret keys known only to the
actual user and the trusted server, it is very hard for an attacker to acquire. The
Kerberos system is resilient to replay attacks as well. Kerberos is generally considered
to significantly increase the security of a network, although it is not a panacea. There
are problems using Kerberos to authenticate between two machines (instead of a user and a
machine), and there are difficulties involving where the keys are cached on a multiuser
machine. For a discussion of weaknesses in Kerberos, see [Bellovin, Merritt91] .
3.2.5. Encrypting Individual IP Packets (SKIP) 
Instead of exchanging a session key, as we might do via Kerberos for a telnet session, we
could choose to encrypt all IP packets, all the time, at the IP level. Naturally, we must
encrypt them in a way that the destination can successfully decrypt them. There is a
special key-distribution scheme designed for packet-level encryption called the Simple
Key-Management for Internet Protocols (SKIP). SKIP assumes that each site in the network
has a public key, which can be used to create many keys between two sites. The basic idea
of the algorithm is to encapsulate the packet-key (the key to decrypt that packet) inside
the packet, and encrypt that with shared secret between the two sites. The SKIP technique
also provides an easy method of changing the shared secret between two sites [Aziz,
Patterson96]. Since this method is not session-based, it can cover all aspects of TCP/IP
communication, not merely applications.
4. IP Version 6 
The problem of authentication within IPv4 is a challenging one. While firewalls,
wrappers, Kerberos and SKIP may help curb spoofers, they are add-ons designed to shore up
the deficiencies in IPv4. They are not guarantees of security, and they involve
significant efforts for each network that wants to implement them. Looking back, it would
have been better if security had been a goal of the TCP/IP protocol suite from the
beginning. 
Although it is not possible to go back in time and change history, we can look forward to
the future. In the 1990s, TCP/IP security is a concern, and a newer version of the
protocol has been developed with this concern in mind. In fact, it has been developed
with a number of new concerns in mind. One important motivating factor for the
development of a new protocol is that the address space is running out. A lot of
experience has been gained in the years of usage of IPv4 about what tasks IP should
perform, and the new version of IP is redesigned to reflect that experience. The new
version will eventually replace the current version. The current version of the protocol
is 4, and the new version designed is version 6, referred to as IPv6. IPv6 attempts to
address the newfound knowledge of the importance of routing, security, etc. It promises
to provide authentication and encryption on the Internet and could solve a lot of the
existing problems with TCP/IP. For a complete description of IPv6, we refer the reader to
[Huitema]. We will restrict our focus to the security features introduced in IPv6. 
IPv6 Header
The IPv6 header consists of 64-bit initial header fields, followed by 128-bit source
addresses and destination addresses. Version Priority Flow Label 
Payload Length Next Header Hop limit 
Source Address 
Destination Address 
1Figure 10. IPv6 Base Header 
The header shown in Figure 10 is the IPv6 base header. There are no options in the
base-header. Instead, the options are specified as extension headers. These extension
headers are placed between the base header and the payload. Payload here refers to the
data that is carried by IPv6. The current IPv6 specification defines six extension
headers: 
Hop-by-hop options header 
Routing Header 
Fragment Header 
Authentication Header 
Encrypted security payload 
Destination options header 
For example, if there was an authentication header following the IPv6 base header, we
will have a chain of headers as shown in Figure 11. Each header indicates the type of the
next header that immediately follows it. In Figure 11, the Base Header indicates that the
next header that follows itself is the Authentication header. The Authentication Header
indicates that the TCP header and data follow. 
Figure 11. Chaining of IPv6 Header 
Security options in IPv6
IPv6 includes two extension headers that serve as security options, the Authentication
Header and the Encryption header. The Authentication Header allows the recipient to
ascertain the identity of the sender and the encryption Header ensures that only the
recipient is able to look at the contents of the message. Both these options in IPv6
require that the sender and the receiver agree on parameters such as the key, the
authentication or the encryption algorithm, and the lifetime of the key. This is termed
as a security association in IPv6. The recipient of a packet has to verify or decrypt
only in the context of the security association between the sender and the receiver. The
security association or the security context is identified using the security parameter
index (SPI). The SPI is normally negotiated as part of the key-exchange procedure. 
The SPI is usually chosen by the receiver for every (sender, receiver) pair. The receiver
uses the SPI to identify the specific security context. In case of multi-casting, where
there are multiple receivers, the SPI will be common to all the members of the multicast
group. The SPI will be used by all the members to correlate the security context. 
Key Distribution in IPv6
The establishment of security associations is crucial to both authentication and
encryption. During a security association, the keys, other information about the keys
such as the life-time of the key, the authentication and the encryption algorithms are
exchanged between a receiver and a sender. In addition to this, this association context
can be later referred to using the SPI, the Security Parameter Index. Efficient
deployment of IPv6 security will rely on an efficient key distribution mechanism. It is
desirable that the key distribution be a zero-knowledge exchange, that is the sender and
the receiver should be able to exchange keys without agreeing on any secret a-priori. 
The Internet community has not yet agreed upon a key distribution method. The leading
proposal is called Photuris, which is a modification of the Diffie-Hellman key-exchange
algorithm. [Diffie, Hellman] 
Diffie Hellman Algorithm
Diffie-Hellman was the first public-key algorithm invented, and dates back to 1976. It
can be used to generate a secret key, but not for encrypting and decrypting messages. 
Assume parties A and B are involved and want to generate a secret key. A and B agree on a
large prime number, n and a generator g, such that g is primitive mod n. The two
integers, n and g do not have to be secret. A and B can agree to them over an insecure
channel. 
A chooses a large random number x, and computes
X = gx mod n
A then sends X to B. 
B chooses a large random, y and computes
Y = gy mod n
B sends Y to A. 
A computes
k = Yx mod n 
B computes
k' = Xy mod n 
After the initial exchange between A and B, A knows x and Y, and B knows X and y. Since
this is exchanged over an insecure link, X and Y could be found out by a third-party and
are public. But either x or y is not obtainable by the third party. Steps 3 and 4 yield
the session key Z,
Z = k = k' = gxy mod n 
The computed key Z, can then be used by either the encryption or the authentication
algorithm.
The Diffie-Hellman algorithm derives its security from the difficulty of calculating
discrete logarithms in a finite field, as compared with the ease of exponentiation in the
same field. It is difficult for a third-party to compute the discrete logarithm and
recover x or y. The choice of g and n is important, and n must be large. As observed
earlier, g must be primitive mod n. One could choose g as small as possible, and usually
it is a one-digit number. The security of the system is based on the difficulty of
factoring numbers the same size of n. Other mathematical techniques, such as elliptic
curve groups could also be used for the key exchange. 
ADVANTAGES OF DIFFIE-HELLMAN SCHEME
The Diffie-Hellman algorithm has two distinct advantages, that could be made use of in
protocols. 
The keys could be computed only when needed. This makes sure that there is no necessity
for a key to remain secret for a long period of time, thereby overcoming the problem of
keeping a secret! 
The key exchange does not require any key-server and can be easily deployed. 
DISADVANTAGES
The original Diffie-Hellman algorithm has a known set of weaknesses. 
There is no identity of the parties involved in the exchange. 
It is easily susceptible to man-in-the-middle attacks. A third party C, can exchange keys
with both A and B, and can listen to the communication between A and B. 
The algorithm is computationally intensive. Each multiplication varies as the square of
n, which must be very large. The number of multiplications required by the exponentiation
increases with increasing values of the exponent, x or y in this case. 
The computational nature of the algorithm could be used in a denial-of-service attack
very easily. 
Photuris
Photuris tries to rectify certain problems in the Diffie-Hellman algorithm. The algorithm
was named Photuris as a tribute to unknown engineers. The Internet draft, by Phil Karn
and Simpson describes Photuris. [Karn96]. It will probably be revised before being
published as an Internet RFC. 
KEY-EXCHANGE IN PHOTURIS
Photuris starts using a cookie exchange, which precedes the Diffie-Hellman key exchange.
After the keys are exchanged, signed messages are sent over the new protected channels. 
All Photuris messages are exchanged using UDP, the unreliable transport equivalent of
TCP. 
The Photuris key exchange 
A sends a cookie-request to B. 
Cookie-request ( initiator cookie, group list) 
The cookie request contains a 128-bit initiator cookie. The initiator cookie is a random
number used as an identification for the key-exchange. The cookie request also contains a
list of groups. These groups designate the finite fields over which the Diffie-Hellman
exchange is carried out. The current draft supports three groups: the elliptic curve
group, the exponential group based on a 1024-bit prime with 2 as the generator, and
another exponential group with 5 as the generator. 
B on receipt of the cookie-request, selects one of the groups provided by A and
constructs a cookie-response to send to A.
Cookie-response( initiator cookie, responder cookie, selected group, responder
attributes) 
The cookie-response from B contains the responder-cookie. The responder-cookie is
computed by applying a one-way function such as MD5 to a string composed of the source
address and the UDP port of the message, the initiator cookie and a secret number chosen
by B. B does not usually maintain any memory of the exchange. B also sends a list of
attributes to A. The list of attributes contains a set of transforms in order of B's
preference. This feature allows A and B to use any of the listed methods for signatures
and encryption. The standard specifies MD5 as the default one-way function to be used for
Authentication, and DES-CBC as the encryption scheme. 
A and B now enter the Diffie-Hellman exchange phase, where they exchange the half-keys
and generate a session key k. The Key-request message is sent by A to B. The message
contains A's security parameter index (SPI), in addition to the Diffie-Hellman public
value. A lifetime for the request is also sent in the key-request message. The initiator
transform field indicates the transforms chosen by A out of B's transform priorities. A
also sends its own transform priority list using the Initiator attributes. The Group
Index, indicates the mathematical group to be used in the Diffie-Hellman scheme. A
indicates its value for the Security Parameter Index in the initiator SPI field.
Key Request (Group Index, Initiator Lifetime, initiator SPI, Initiator Cookie, Responder
Cookie, Initiator Public Value, Initiator Transform, Initiator Attributes) 
B sends its Diffie-Hellman half-key using the Key-response message. The parameters to the
message are similar to the Key-request message.
Key Response ( Responder Lifetime, Responder SPI, Initiator Cookie, Responder Cookie,
Responder Transform, Responder Public Value, Key Transform) 
The cookie exchange and the Diffie-Hellman exchange do not protect against the
man-in-the-middle attack. This problem can be solved by requiring A to send its signature
to B, and B could verify the signature. This assumes that A has B's certificate, and B
has A's certificate. These certificates might have been signed by a trusted authority
outside the protocol. 
(initiator-cookie, responder-cookie, signature, certificate) : A B and B A
A signs the session-key concatenated with the public value of the key, B's public value,
and optionally the identifying public key, certificate, or the distinguishing name of A.
Inclusion of both public values in the signature guarantees that a third party, the
middle man has not substituted its own value. If B is able to verify A's signature
correctly, then B sends its own signature to A, for A to authenticate B. In case of a
failure, the security association is dropped. 
Key Distribution for Multicast groups
The Diffie-Hellman scheme can be easily extended for three or more parties. [Schneier96].
But for multi-casting, it is ideal to have a key-server distribute a single key to all
the parties concerned. 
The Authentication Header in IPv6
IPv6 uses the daisy chaining of options to support authentication as well. One of the
extension header that can be sent after the base header could be an authentication header
(AH). The AH has a very simple format as shown in Figure 12. The SPI or the Security
Parameters Index, denotes the security context of the sender and the receiver. SPI would
be used by the receiver to retrieve the security context of the sender. 
The sender computes a signature of the payload data, some fields of the IPv6 header and
the extension headers, and this signature is sent as the authentication data. The
algorithm used for the signature is negotiated as part of the key-exchange process. The
MD5 algorithm is specified as a default to make sure all implementations can at least use
one common algorithm. The receiver retrieves the appropriate security context, using the
SPI indicated and verifies the signature. 
There are intrinsic details in creating the signature that are interesting to note. The
Authentication header has to ensure that the entire IPv6 packet is not modified or
tampered with. But, there are certain fields in the IPv6 header that need to be modified
by routers on the way. For example, the hop count field is decremented at every hop. Some
hop by hop options may also be updated in transit. In order to take care of this, the
sender needs to prepare a special version of the message that is independent of the
changes that can take place in transit, such as setting the hop count to zero. 
The Authentication Option could be used between routers or between end-nodes. Using it
between routers could solve common routing attacks that are prevalent today. The IP
spoofing attacks could be prevented by using the Authentication option. Next Header
Length RESERVED 
Security Parameters Index (SPI) 
Authentication Data 
Figure 12. IPv6 Authentication Header
Encryption Header in IPv6
The Encrypted Security Payload (ESP) header, when used forms the last of the extension
headers in the chain of headers (see Figure 13). All data following the encryption header
is encrypted, and the data preceding the encryption header is in plain-text. The format
of the encryption header is shown in Figure 14. The SPI is used by the receiver to
retrieve the security context of the sender, and then decrypt the data following it. 
IPv6 Base Header 
Extension Headers 
ESP header 
Encryption header 
Figure 13. Encryption using the ESP header
The encryption scheme is negotiated during the key-exchange. DES-CBC is the default
encryption scheme that is supported. SPI (Security Parameter Index) 
Encrypted Data And Parameters 
Figure 14. The ESP Header
Application of Security Options in IPv6
IPv6 has introduced network layer authentication and encryption. This enables the use of
both encryption and authentication by all protocol layers above IPv6. The routing
protocols, that are totally insecure today, could be made secure using IPv6 security
options. Secure channels could be established over the insecure Internet. 
Securing Routing protocols
Network integrity depends on the integrity of the routing protocols. If the routing
protocols are not secure, then they cannot guarantee network integrity. The protocols
that are used today between routers, RIP, OSPF and others are run over an insecure link.
If intruders forge the routing updates, then they will be able to disrupt communication
or divert connections. IPv6 security options could be used to secure the routing
protocols. 
Securing Neighbor discovery
Neighbor discovery is an important characteristic of IPv6. This feature allows
auto-configuration, also known as, plug and play. A new host should be able to configure
its address automatically when it is plugged into a network. However, having this feature
also introduces new security holes. A host that is not authorized to the network may use
the services. Auto-configuration depends on neighbor discovery, an algorithm to enable a
host to find out its neighbors. A host may get updates from illegal nodes, and builds
wrong routing tables. 
The router advertisements come from an authorized router. 
The router advertisements are sent by the routers to the nodes to the 'all nodes'
multicast group, which tells the nodes the information about the network that they are
plugged into. This advertisement could be secured by having a secure association for that
group, defined by a SPI, and using an algorithm such as MD5 and a session key. This is a
feasible solution since the nodes on a network are going to communicate with a fixed set
of routers. 
The Neighbor advertisements come from an authorized station. 
Communication between two hosts on a local network such as a LAN requires that the
parties know each others media address. In the case of Ethernet, the media address will
be the Ethernet address. Neighbor advertisements are used by hosts to determine the media
address of a neighbor on the network. When a host A wants to communicate with host B,
host A sends a Neighbor Solicit message to all nodes on the local network. B on receiving
this responds with a Neighbor advertisement to A. 
There is a chicken-and-egg problem associated with neighbor advertisements. In order to
secure the neighbor advertisements, a security association is required between the two
parties. But, the neighbor advertisements are also the first packets exchanged between
the two neighbors. The two parties cannot exchange keys and do the neighbor
advertisements as well. The problem could be solved by a deferred security association.
Another solution would be to change the routing protocols such that the first next hop is
always fixed, which could be a router. The router could forward the first packet to the
required destination. Both the sender and receiver could later update their local tables
using authenticated redirects from the router. 
Securing tunnels between firewalls
At present, most organizations secure their intranet using firewalls. There is still a
problem when two geographically different divisions of the same organization that are
connected over the Internet. Both divisions have secure firewalls, but each division will
be insecure when they have to communicate over the Internet while communicating to the
other. A secure channel between the two firewalls is required. Using the IPv6 options, a
secure channel could easily be established between the two firewalls. 
Problems with IPv6 Security Options
The inclusion of the Authentication and the Encryption options the network layer is
certainly welcome, and proposes to solve a lot of the current TCP/IP security problems.
The design of IPv6 has considered the existing problems that prevail on the Internet.
There are certain problems, however, in implementing security in any network-layer
protocol today. The question of choosing between link-level encryption and
application-level encryption has always plagued the researchers. The network is growing
faster, and using encryption is going to slow down the protocols, thereby not utilizing
the entire bandwidth available. Thus, the Internet Engineering Task Force has yet to
decide on a Key Exchange protocol. 
5.0 Summary and Conclusions 
TCP/IP, as it exists today, has a general lack of security. Examples of implementations
of SYN flooding, IP Spoofing, Connection Hijacking, etc. show that this lack of security
has lead directly to the development of tools and techniques to exploit TCP/IP's
weaknesses. Fixing some of these flaws today is possible (with add-ons like TCP Wrappers,
Kerberos, and SKIP), but these fixes are not always in widespread, everyday use - your
host may implement them, but host you want to communicate with may not. Thus, most
communication on today's Internet is still unsecured. Migrating to a new protocol suite,
such as IPv6, may be the only answer to fixing the flaws in TCP/IP for good.