CHRIS CHAMBERS, JUSTIN DOLSKE, and JAYARAMAN
IYER
Department of Computer and Information Science, Ohio State University, Columbus, Ohio 43210
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.
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.
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.
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.
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.
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:
Figure
11. Chaining of IPv6 Header
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.
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]
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.
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.
The Diffie-Hellman algorithm has two
distinct advantages, that could be made use of in protocols.
The original Diffie-Hellman algorithm
has a known set of weaknesses.
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
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.
Figure
12. IPv6 Authentication 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.
Figure
14. The ESP Header
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.
Department of Computer and Information Science, Ohio State University, Columbus, Ohio 43210
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.
| Options | Padding | ||||
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.
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.
(from TCP/IP Illustrated, Vol. 1 by W. Richard Stevens)
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.
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.
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.
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.
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.
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 | |||
| Payload Length | Next Header | Hop limit | ||
- Hop-by-hop options header
- Routing Header
- Fragment Header
- Authentication Header
- Encrypted security payload
- Destination options header
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
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.
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 |
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.
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.
