Tcpip Security

TCP/IP Security The TCP/IP protocols, the basis for today’s Internet, lack even the most basic mechanisms for security, such as authentication or encryption. As usage of the Internet and TCP/IP protocols increases, their lack of built-in security has become more and more problematic. This paper describes a variety of basic flaws in TCP/IP protocols and their implementations, and discusses solutions and work-arounds to these problems. Also covered is the new IPv6, the next-generation Internet protocol that, among other goals, seeks to fix many of the current flaws in the current Internet IPv4 protocol. Security in protocols and applications not essential to TCP/IP (such as HTTP, FTP, and SMTP) are not discussed in this paper. Introduction In the early 1980’s, specifications were finished for the TCP and IP protocols. These two protocols could be considered the most important in the world today – they are the basis of the Internet. Over the past decade, the Internet has grown from a small network connecting a small community of researchers to its present state – a gigantic global network connecting people of all types.

The huge success of the Internet has, for the most part, been quite beneficial. The Internet has evolved from a specialized project to a general-purpose tool. However, the growth of the Internet has created problems with security. The TCP and IP protocols were designed when the Internet was small, and users generally trusted each other. The protocols lack many features that are desirable or needed on an insecure network.

We Will Write a Custom Essay Specifically
For You For Only $13.90/page!


order now

In this paper, we present a number of problems that arise with using TCP/IP on today’s network, solutions or work-arounds for these problems, and how the protocols for tomorrow’s Internet, such as IPv6, will help eliminate these problems. 1. Introduction to TCP/IP TCP/IP is the backbone of the internet today. Comprised of two protocols, TCP and IP, the TCP/IP protocol suite is one of the most widely used. We present a brief introduction to the two protocols. For a detailed discussion of the two protocols we refer the reader to the RFC’s for IP [RFC 791], and TCP [RFC 793].

1.1. Internet Protocol The Internet Protocol (or IP as it generally known), is the network layer of the Internet. IP provides a connection-less service. The job of IP is to route and send a packet to the packet’s destination. IP provides no guarantee whatsoever, for the packets it tries to deliver.

The IP packets are usually termed datagrams. The datagrams go through a series of routers before they reach the destination. At each node that the datagram passes through, the node determines the next hop for the datagram and routes it to the next hop. Since the network is dynamic, it is possible that two datagrams from the same source take different paths to make it to the destination. Since the network has variable delays, it is not guaranteed that the datagrams will be received in sequence. IP only tries for a best-effort delivery.

It does not take care of lost packets; this is left to the higher layer protocols. There is no state maintained between two datagrams; in other words, IP is connection-less. Version IHL Type of Service Total Length Identification Flags Fragmentation Offset Time to Live Protocol Header Checksum Source Address Destination Address Options Padding Figure 1. IP Header The IP Header is shown in Figure 1. The Version is currently set to 4.

In order to distinguish it from the new version IPv6, IP is also referred to as IPv4. The source address and the destination address are 4-byte Internet addresses. The Options field contains various options such as source based routing, and record route. The source based routing allows the sender to specify the path the datagram should take to reach the destination. Record route allows the sender to record the route the datagram is taking. None of the IP fields are encrypted and there no authentication.

It would be extremely easy to set an arbitrary destination address (or the source address), and IP would send the datagram. The destination has no way of ascertaining the fact that the datagram actually originated from an IP address other than the one in the source address field. It is easy to see why any authentication scheme based on IP-addresses would fail. 1.2. Transmission Control Protocol Transmission Control Protocol (TCP) runs on top of IP, and provides a connection oriented service between the sender and the receiver. TCP provides guaranteed delivery, and ensures that the packets are delivered in sequence.

The underlying network IP, is highly unreliable and does not provide any guarantee for TCP. In order to provide reliability between the sender and the receiver, TCP uses various mechanisms, such as sequence numbers, acknowledgments, 3-way handshakes and timers. A TCP connection is identified by the 4-tuple ((destination-ip-address, destination-port), (source-ip-address, source-port)). Ports are the actual end-points of the TCP connection. The working of TCP could be described using a TCP state machine.

(see Figure 5). Transitions to different states are based on events received in the form of TCP segments. The TCP states are very closely associated with timers. There are various timers associated with connection establishment (or termination), flow control, and retransmission. In order to understand the security problems associated with TCP, it is necessary that we look at the state-machine in detail.

It is also important to get an overview of TCP implementations, and how they implement the TCP state-machine, the state-transitions and the associated timers. The TCP layer on either end maintains table entries corresponding to the 4-tuple (remote-ip-address, remote-port, source-ip-address, source-port). This 4-tuple uniquely identifies a connection. For every connection, the end-systems implementing TCP need to keep the TCP state information for the duration of the connection. 1.3.

TCP Sequence Numbers TCP is run over an unreliable IP, and IP does not guarantee delivery of packets, and does not necessarily deliver the packets in sequence. Delayed packets showing up is not uncommon. Given these conditions, TCP does not make any assumptions about the underlying network. In order to identify packets and ensure that they are delivered to the application layer in order, the sequence number is an important component of every TCP segment. Every byte of data that TCP sends is given a sequence number. By doing this, the sender and receiver can verify whether the data was delivered correctly.

They can also determine whether data was dropped, possibly because of loss in transit. Both the sender and the receiver exchange initial sequence numbers (ISN) during the connection setup phase. After a successful initial handshake, both the sender and the receiver know the sequence numbers that they have to use for communication. Since TCP allows for delayed segments, it must accept segments that are out of sequence, but within certain bounds, known as the receiver window size. The receiver window size is also exchanged during the initial handshake.

TCP will discard all segments that do not have a sequence number within the computed bounds. The TCP sequence number is a 32-bit counter. In order to distinguish between different connections between the same sender and receiver, it is important that the sequence numbers do not start at 0 or any other fixed number each time a connection is opened. Hence, it is important that the first byte of data from the sender to the receiver is using a random sequence number. Current implementations increment the sequence number by a finite amount every second. 1.4.TCP Header Every TCP segment must contain a TCP header.

The header format is the same for all TCP segments ( Figure 2). The header contains the source and destination port. The sequence number identifies the first byte of data following the header. The acknowledgment number indicates an acknowledgment up to (acknowledgment – 1) bytes by the receiver. There are six flag bits in the header, namely URG, ACK, PSH, RST, SYN and FIN. One or more of the flags can be set in any segment header.

16-bit source port number 16-bit destination number 32-bit sequence number 32-bit acknowledgment number header length and flags 16-bit window size 16-bit TCP checksum 16-bit urgent pointer Options (if any) Data (if any) Figure 2. TCP header format The window size indicates the receiver window size, used for flow control. The TCP header and the data are covered by the checksum. There are other optional fields, not relevant to our discussion. 1.5.

The Three Way Handshake Most network protocols follow the classical three way handshake to establish or terminate connections over a not-so-reliable link. A initiates a connection to B by sending a message. B responds with an acknowledgment. At this point, A sends another message back to B confirming that A received B’s acknowledgment. A and B connect successfully when B receives the second message from A (confirming B’s ack). The three way handshake is used by TCP both to establish connections as well as to terminate the connections.

When hosts A and B want to communicate using TCP, they need to establish a connection using the three-way handshake. Termination or closing a connection is also executed using the three-way handshake. The hosts on either end identify their TCP connection with the other using the (IP-address, port number) combination. A table entry is created on receiving the first segment from the remote host which has all the parameters to identify the connection. 1.6. Connection Setup TCP uses the 3-way-handshake to set up a successful connection. When host A wants to open a connection to host B, A sends an initial segment to B.

This initial segment has the Initial Sequence Number (ISN) that B needs to use to send data to A. This initial segment is identified by the SYN bit set to 1 in the TCP header. If the SYN bit is set, the 32-bit sequence number in the header is interpreted as the ISN. In all other cases (when the SYN bit is not set), the 32-bit sequence number identifies the sequence number of the first data byte contained in that segment. B on receiving the SYN from A, has to respond with another SYN, as well acknowledge the SYN sent by A.

This is indicated by SYN+ACK in the state machine diagram. Figure 3. Initial Connection establishment. 1.7. Connection release Connection release in TCP also uses the 3 way handshake.

Connection release uses the FIN in place of the SYN. Figure 4. Connection release in TCP 1.8. TCP Timers Timers are closely knit with the TCP states. Some values are specified by the RFC, but not all.

Some timers are left open to individual implementations. We will look at timers relevant to our discussion, which include the timers at connection establishment, and at connection termination. Connection Establishment Timer This timer is associated with the opening of a connection. It is started when the SYN is sent during the initial connection setup. In most TCP implementations, the value of this timer is set to 75 seconds.

If a time-out occurs, the connection is aborted. FIN WAIT timer A FIN WAIT 2 timer is started when there is a transition from the FIN WAIT 1 state to the FIN WAIT 2 state. The value of this timer is 10 minutes. A TCP segment with a FIN bit set is expected in the FIN WAIT 2 state. If a packet with a FIN bit set is received, the timer is cancelled.

On expiration of the timer, it is restarted with a value of 75 seconds. The connection is dropped if no packet with the FIN bit arrives within this period. TIME WAIT timer A Time-wait timer is started when the connection enters the TIME-WAIT state. This is to allow all the segments in transit to be removed from the network. The value of the timer is usually set to 2 minutes.

On expiration of the timer, the connection is terminated. KEEP ALIVE timer TCP usually does not send anything over the connection if there is no data to send. There is no way of distinguishing this silence from the case when the connection is broken. A keep-alive timer can be set which allows TCP to periodically check whether the other end of the connection is still active. The default value of this timer is 2 hours. After the expiration of the timer, probes are sent to the remote end.

The connection is dropped if the remote does not respond to the probes. 1.9. Problems with the TCP State machine The TCP statemachine is shown in Figure 5. There is a statemachine for every connection. Each connection logically starts in the CLOSED state, and makes transitions as shown in the diagram. After the connection is terminated, TCP returns to the CLOSED state.

For a detailed description of the statemachine, refer [RFC 793]. It is easy to exploit a few flaws in the state-machines, and create denial-of-service attacks. All the denial-of-service attacks created try to stall the TCP statemachine in a particular state either indefinitely or for a finite time. Figure 5. TCP State Machine (from TCP/IP Illustrated, Vol.

1 by W. Richard Stevens) 1.10. Absence of timers Looking at the state machine, we can see that there are no timers associated with certain states. As noted earlier, TCP does not send any data on the connection, unless used with a special option, the Keep-alive timer. This means that TCP state machine for a connection could be made to stay at such states forever.

Most implementations do not implement timers for those states. An example of such a state is the CLOSE WAIT state. If the keep-alive timer is used, TCP would be able to reset the connection. The default value of the keep-alive timer is set to 2 hours, which means that the state-machine is frozen atleast for a period of 2 hours. 1.11. Simultaneous connection establishment When two hosts, say A and B want to establish a connection and both of them simultaneously initiate the handshake, we have a case of simultaneous connection establishment [RFC 793].

Both hosts A and B send out SYN’s to each other. When the SYN’s are received by the corresponding peers, both of them send out a SYN+ACK. Both hosts A and B must detect that the SYN and SYN+ACK actually refer to the same connection. If both hosts A and B detect that the SYN+ACK belongs to the SYN that was recently sent, they switch off the connection establishment timer and move directly to the SYN RECVD state. This flaw could be used to stall a port on a host, using protocols such as FTP where the server initiates a connection to the client.

As an example, consider host X which has started a FTP connection to a server A. X and A are connected using the control-port. A initiates the connection establishment procedure to initiate data transfer with X. A sends a SYN to X, and makes a transition to SYN SENT state. A also starts the CONNECTION ESTABLISHMENT timer.

X receives the SYN, and responds back with another SYN. When A receives the SYN from X, it assumes that this is a case of a simultaneous open connection. So, it sends out SYN ACK to X, switches off the connection establishment timer, and transitions to the state SYN RCVD. X receives the SYN ACK from A, but does not send a reply. Since, A is expecting a SYN ACK in the SYN RCVD state, and there is no timer, A gets stalled in SYN RCVD state.

Thus, X here is able to create a denial-of-service attack using this flaw in TCP. 1.12. SYN+FIN The TCP specification does not specify clearly certain transitions and hence allows for some spurious state transitions. [Guha, Mukherjee]. These transitions could be used for a variety of attacks, especially the denial-of-service attacks. As an example, we will look at a scenario where a host receives a TCP segment with both the SYN and the FIN bit set.

On receiving a packet with the SYN and the FIN bit set, TCP makes a transition to the CLOSE WAIT state. There has been no successful connection establishment and hence TCP should not be making such a transition. Most implementations do this because the specifications have failed to address the issue. The transition is clearly a bad one, since CLOSE WAIT is a state with no timer associated. The receiver gets stalled in the CLOSE WAIT state.

2. Problems in the TCP/IP protocol suite When TCP/IP was designed in the early 1980’s, security was not a primary concern. However, in the years since their inception, the lack of security in the TCP/IP protocols has become more of a problem. The widespread use and availability of the TCP/IP protocol suite has exposed its weaknesses. Presented here are a number of well-known vulnerabilities of both TCP/IP itself, and of some protocols commonly used along with TCP/IP (such as DNS). 2.1.

TCP SYN attacks In an Internet environment, high message latency and loss are not uncommon, resulting in messages that arrive late or in nonsequential order. The TCP half of TCP/IP uses sequence numbers so that it can ensure data is given to the user in the correct order, regardless of when the data is actually received. These sequence numbers are initially established during the opening phase of a TCP connection, in the three-way handshake. SYN attacks (also known as SYN Flooding) take advantage of a flaw in how most hosts implement this three-way handshake [Guha, Mukherjee95]. When Host B receives the SYN request from A, it must keep track of the partially opened connection in a listen queue for at least 75 seconds. This is to allow successful connections even with long network delays.

The problem with doing this is that many implementations can only keep track of a very limited number of connections (most track only 5 connections by default, though some like SGI’s IRIX track up to 1024 [Luckenbach96]). A malicious host can exploit the small size of the listen queue by sending multiple SYN requests to a host, but never replying to the SYN&ACK the other host sends back. By doing so, the other host’s listen queue is quickly filled up, and it will stop accepting new connections, until a partially opened connection in the queue is completed or times out. This ability to effectively remove a host from the network for at least 75 seconds can be used solely as a denial-of-service attack, or it can be used as a tool to implement other attacks, like IP Spoofing. Figure 6.

SYN Flooding 2.2. IP Spoofing IP Spoofing is an attack where an attacker pretends to be sending data from an IP address other than its own [Morris85, Bellovin89]. The IP layer assumes that the source address on any IP packet it receives is the same IP address as the system that actually sent the packet — it does no authentication. Many higher level protocols and applications also make this assumption, so it seems that anyone able to forge the source address of an IP packet (called spoofing an address) could get unauthorized privileges. However, there are two catches. The first catch is that all communication is likely to be one-way.

The remote host will send all replies to the spoofed source address — not to the host actually doing the spoofing. So, an attacker using IP spoofing is unlikely to see output from the remote system (unless they have some other method of eavesdropping on the network between the other two hosts). The second catch is that an attacker needs to use the correct TCP sequence numbers if they plan on establishing a TCP connection with the attacked host (most common services, like Telnet, FTP, and r-commands use TCP). The final ACK in a three-way handshake must contain the other host’s ISN, otherwise the connection cannot complete; because the ISN in the SYN+ACK packet is sent to the real host, an attacker must get this ISN by some other method. If the attacker could eavesdrop on the packets send from the other host, he could see the ISN.

Similarly, if the attacker was unable to eavesdrop, but could somehow guess the other host’s ISN, he can complete the connection and conduct a one way conversation (this may be sufficient to initiate some other form of two-way communication). Unfortunately for the TCP/IP community, methods to overcome both challenges in IP Spoofing have been developed. 2.2.1. Sequence Guessing The sequence number used in TCP connections is a 32 bit number, so it would seem that the odds of guessing the correct ISN are exceedingly low. However, if the ISN for a connection is assigned in a predictable way, it becomes relatively easy to guess. This flaw in TCP/IP implementations was recognized as far back as 1985, when Robert Morris described how to exploit predictable ISN’s in BSD 4.2, a Unix derivative [Morris85].

In BSD 4.2, the ISN for a connection is assigned from a global counter. This counter is incremented by 128 each second, and by 64 after each new connection (i.e., whenever an ISN is assigned). By first establishing a real connection to the victim, the attacker can determine the current state of the system’s counter. The attacker then knows that the next ISN to be assigned by the victim is quite likely to be the predetermined ISN, plus 64. The attacker has an even higher chance of correctly guessing the ISN if he sends a number of spoofed IP frames, each with a different, but likely, ISN.

However, when the host receiving spoofed packets completes its part of the three-way handshake, it will send a SYN&ACK to the spoofed host. This host will reject the SYN&ACK, because it never started a connection — the host indicates this by sending a reset command (RST), and the attacker’s connection will be aborted. To avoid this, the attacker can use the aforementioned SYN attack to swamp the host it is imitating. The SYN&ACK sent by the attacked host will then be ignored, along with any other packets sent while the host is flooded. The attacker then has free reign to finish with his attack.

Of course, if the impersonated host happens to be off-line (or was somehow forced off-line), the attacker need not worry about what the victim is sending out. Figure 7. IP Spoofing via Sequence Guessing Incrementing the ISN counter more often, as other operating systems may do, does not appear to help. Even if the counter is incremented 250,000 times a second (as suggested by the TCP standard), an attacker may still be able to approximately predict the ISN. By repeatedly guessing, it is likely that the attacker will establish a connection with the correct ISN within a few hours [Bellovin89]. 2.2.2.

Source Routing Another variant of IP spoofing makes use of a rarely used IP option, Source Routing [Bellovin89]. Source routing allows the originating host to specify the path (route) that the receiver should use to reply to it. An attacker may take advantage of this by specifying a route that by-passes the real host, and instead directs replies to a path it can monitor (e.g., to itself or a local subnet). Although simple, this attack may not be as successful now, as routers are commonly configured to drop packets with source routing enabled. Figure 8.

Source Routing 2.3. Connecting Hijacking An interesting variant on IP spoofing allows a host to insert itself in the middle of a connection between two hosts — connection hijacking [Joncheray95]. IP spoofing alone may not bypass additional security, such as authentication by the Unix password mechanism, Kerberos, or one-time password systems like SKEY [RFC1760]. But with this attack, an attacker can allow normal authentication to proceed between the two hosts, and then seize control of the connection. Connection hijacking exploits a desynchronized state in TCP communication.

When the sequence number in a received packet is not the same as the expected sequence number, the connection is said to be desynchronized. Depending on the actual value of the received sequence number, the TCP layer may either discard or buffer the packet. There is a choice, because TCP uses a sliding window protocol to allow efficient communication even in the presence of packet loss and high network latency. So, if the received packet is not the one expected, but is within the current window, the packet will be saved on the premise that it will be expected later (various TCP mechanisms ensure that the expected packet will eventually arrive). If the received packet is outside of the current window, it will be discarded.

Thus, when two hosts are desynchronized enough, they will discard (ignore) packets from each other. An attacker can then inject forged packets with the correct sequence numbers (and potentially modify or add commands to the communication). Obviously, this requires the attacker to be located on the communication path between the two hosts so that he may eavesdrop, in order to replicate packets being sent. The key to this attack is creating the desynchronized state. Joncheray describes two possible ways to do this: one is during the three-way handshake, and the other is in the middle of an established connection. Note that ignored packets may actually generate ACKs, rather than being completely ignored.

When the other end receives packets with incorrect sequence numbers, it replies with an ACK packet containing the sequence number it is expecting. But the receiver of these ACK discards them, as they have the wrong sequence numbers! The receiver then sends its own ACK to notify the sender.. Thus, a large number of ACKs are generated in this attack. This signature of the attack could be used to detect connection hijacking. Figure 9.

Connection Hijacking 2.3.1. Desynchronization during connection establishment In this form of desynchronization, the attacker resets a connection during the three-way handshake. After host B sends the SYN&ACK packet to host A, the attacker forges new packets from B (to A) in which the connection is first closed via the RST bit, and then a new three-way handshake is initiated with A — identical to the original, real handshake but with different sequence numbers. Host B now ignores messages from A (because A is using the attacker’s new sequence numbers), and Host A ignores messages from B (because A is expecting messages with the attacker’s sequence numbers). The attacker then replicates new packets, with the correct sequence numbers, whenever A and B try to communicate. In doing so, the attacker may also modify the messages or inject his own.

2.3.2. Desynchronization in the middle of a connection The previous attack is limited to the initial connection. If a RST packet is sent in the middle of a connection, the connection is closed — and the application/user is notified of this. To cause desynchronization in the middle of a connection, without closing the connection, only the sequence number counters should be altered. The Telnet protocol, in particular, provides an interesting mechanism to do this. Telnet allows special NOP commands to be sent.

These commands do nothing, but the act of sending the bytes in the NOP command increments the expected sequence number counter on the receiver. By sending enough of these NOP commands, an attacker can cause the connection to become desynchronized. The attacker can then begin replicating new packets, with the correct sequence numbers, as before. 2.4. Routing (RIP) attacks Although it is not strictly a component of TCP/IP, the Routing Information Protocol (RIP) is often an essential component in a TCP/IP network [RFC1058].

RIP is used to distribute routing information within networks, such as shortest-paths, and advertising routes out from the local network. Like TCP/IP, RIP has no built in authentication, and the information provided in a RIP packet is often used without verifying it. Attacks on RIP [Bellovin89] are different from those of other common attacks because RIP attacks change where data goes to, not where it came from. For example, an attacker could forge a RIP packet, claiming his host X has the fastest path out of the network. All packets sent out from that network would then be routed through X, where they could be modified or examined.

An attacker could also use RIP to effectively impersonate any host, by causing all traffic sent to that host to be sent to the attacker’s machine instead. 2.5. ICMP attacks The Internet Control Message Protocol (ICMP) is used by the IP layer to send one-way informational messages to a host. One of the most common (and well-known) uses of ICMP is the ping utility. This utility sends an ICMP Echo Request to a host, and waits for that host to send back an ICMP Echo Reply message.

Other messages in ICMP are of similar complexity; that is, they are all quite simple. It’s not surprising that there is no authentication in ICMP, which leads to attacks using ICMP that can result in a denial of service, or allowing the attacker to intercept packets [Bellovin89]. Denial of service attacks primarily use either the ICMP Time exceeded or Destination unreachable messages. The Time exceeded message indicates that the Time-To-Live field in the IP header has expired; this can normally be caused by routing loops or trying to reach a host that is extremely distant. Destination unreachable messages can have several meanings (based on a sub-field in the ICMP message), but all basically indicate that packets cannot successfully be sent to the desired host. Both of these ICMP messages can cause a host to immediately drop a connection (this is the desired result if the ICMP message is legitimate). An attacker can make use of this by simply forging one of these ICMP messages, and sending it to one or both of the communicating hosts.

Their connection will then be broken. ICMP messages can also be used to intercept packets. The ICMP Redirect message is commonly used by gateways when a host has mistakenly assumed the destination is not on the local network (and is thus attempting to send the packet via the gateway to). If an attacker forges an ICMP Redirect message, it can cause another host to send packets for certain connections through the attacker’s host. This attack is similar to a RIP attack, except that ICMP messages only apply to existing connections, and the attacker (the host receiving redirected packets) must be on a local network.

2.6. DNS attacks The Domain Name Service (DNS) is a protocol widely used on the Internet. DNS is primarily used to map hostnames (i.e. foo.bar.com) to IP addresses (i.e. 192.34.12.7), but it can also be used to do the reverse; mapping IP addresses to hostnames.

An attacker can use the latter property to fool name-based authentication [Schuba, Spafford94; Bellovin89]. For example, an administrator at alice.bar.com may decide to allow only local connections. This is often specified by name, such as allow *.bar.com, rather than by IP address. Name-based authentication is easier to read, and allows easier administration if a domain contains multiple ranges of IP addresses. When a connection is established with alice.bar.com, alice uses DNS to convert the source IP address on the connection to a name, which is then checked using whatever form of name-based authentication the administrators have installed.

If an attacker has access to their local DNS server, they can cause DNS queries on their IP address to reply with any hostname and domain! So, an attacker who knows that alice.bar.com trusts connections from within *.bar.com can alter his DNS server so that his IP address appeared to map to trustme.bar.com. Today, this attack is often prevented by performing a second DNS query on the hostname returned by the first query. If the IP address returned by the second query does not match the source IP address from the original connection, the host knows that a DNS attack is likely being attempted. Proposals to modify DNS to include mechanisms to ensure data integrity and authentication may also mitigate the vulnerabilitie …