TCP Protocols

TCP Protocol

v     The Need for Stream Delivery

Ø      Out of order packet delivery

Ø      Packet delay

Ø      Packet loss

Ø      Packet duplicates

v     Properties of   TCP

Ø      Stream Orientation

t         TCP thinks of the data as a stream of bits, divided into 8-bit octets

t         The stream delivery service on the destination machine passes to the receiver exactly the same sequence of octets that the sender passes to it on the source machine.

Ø      Virtual Circuit Connection

Ø      Buffered Transfer

t         To make transfer more efficient and to minimize network traffic, implementations usually collect enough data from a stream to fill a reasonably large datagram before transmitting it.

t         tPusht mechanism can force a transfer (and delivery) without buffering.

Ø      Unstructured Stream

t         TCP does not honor structured data streams.

t         Application programs must understand stream content and agree on stream format before they initiate a connection.

Ø      Full Duplex Connection: transfer in both directions

Ø      Reliability

t         Positive Acknowledgement with Retransmission.

v     Layering of the three major protocols

v     TCP ports, connections, and endpoints

Ø      Endpoint of communication is application program

Ø      TCP uses port number to identify application

Ø      TCP connection between two endpoints is identified by four items

t         Senderts IP address

t         Senderts protocol port number

t         Receiverts IP address

t         Receiverts protocol port number

Ø      A given TCP port number can be shared by multiple connections on the same machine, e.g., the following two connections share the same destination point:

t         (18.26.0.36, 1069) and (128.230.208.110 22)

t         (128.10.2.3, 1184) and (128.230.208.110 22)

v      TCP Segment Format

v      HLEN: length of the segment header measured in 32-bit multiples (it is needed because the OPTIONS field varies in length).

v      CODE BITS: specify the purpose and contents of the segment

Figure: Bits of the CODE field in the TCP header.

v      Sliding Window Mechanism:

Ø      Used for flow control

Ø      Operate at the octet level, not at the segment or packet level.

Ø      An example of the TCP sliding window is illustrated in the following figure:

Ø      In the above example,

t         Octets through 2 have been sent and acknowledge

t         Octets 3 through 6 have been sent but not acknowledged

t         Octets 7 through 9 have not been sent but will be sent without delay

t         Octets 10 and higher cannot be sent until the window moves

Ø      TCP allows the window size to very over time.

t         Each acknowledgement, which specifies how many octets have been received, contains a window advertisement (the WINDOW field) that specifies how many additional octets of data the receiver is prepared to accept. We think of the window advertisement as specifying the receiverts current buffer size.

t         In response to an increased window advertise, the sender increases the size of its sliding window and proceeds to send octets that have not been acknowledged.

t         In response to a decreased window advertisement, the sender decreases the size of its window and stops sending octets beyond the boundary.

t         Window size can be zero (receiver cannot accept additional data at present).

v      Out of Band Data

Ø      Although TCP is a stream-oriented protocol, it is sometimes important for the program at one end of a connection to send data out of band, without waiting for the program at the other end of the connection to consume octets already in the stream.

Ø      Example: Control-C interrupts or aborts signals.

Ø      URG code bit is used to specify such type of TCP data.

Ø      URGENG POINTER: specify the position in the segment where urgent data ends.

v      ACKNOWLEDGEMENT NUMBER: specify the sequence number of the next octet that  the receiver expects to receive

Ø      At any time, the receiver will have reconstructed zero or more octets contiguously from the beginning of the stream, but many have additional pieces of the stream from datagrams that arrived out of order. The receiver always acknowledges the longest contiguous prefix of the stream that has been received correctly (not including those that are out of order).

v      Timeout and Retransmission

Ø      Every time TCP sends a segment, it starts a timer and waits for acknowledgement.

Ø      If the timer expire, TCP assumes that the segment was lost or corrupted and retransmits it.

Ø      Adaptive retransmission algorithm: TCP monitors the performance of each connection and deduces reasonable values for timeouts.

v      Congestion Control

Ø      When congestion occurs, router begins to enqueue datagrams. When routerst queues reach their capacity, routers start to drop datagrams. This causes TCP retransmissions.

Ø      Retransmissions aggravate congestion instead of alleviating it.

Ø      To avoid congestion, the TCP standard now recommends using two techniques:

t         Multiplicative Decrease Congestion Avoidance: Upon loss of a segment, reduce the congestion window by half (down to a minimum of at least one segment). For those segments that remain in the allowed window, backoff the retransmission timer exponentially.

t         Slow-Start (Additive) Recovery: whenever starting traffic on a new connection or increasing traffic after a period of congestion, start the congestion window at the size of single segment and increase the congestion window by one segment each time an acknowledgement arrives.

v      Establishing a TCP Connection: three-way handshake

Ø      The 3-way handshake accomplishes two important functions

t         It guarantees that both sides are ready to transfer data.

t         It allows both sides to agree on initial sequence numbers.

v      Initial Sequence Numbers

Ø      Each machine must choose an initial sequence number at random.

Ø      Non-random sequence numbers have security consequence (discussed later).

v      Closing a TCP Connection

Ø      When an application program tells TCP that it has no more data to send, TCP will close the connection in one direction by sending a segment with the FIN bit set.

Ø      Once a connection has been closed in a given direction, TCP refuses to accept more data for that direction. Meanwhile, data can continue to flow in the opposite direction until the sender closes it.

Ø      When both directions have been closed, TCP at each endpoint deletes its record of the connection.

v      TCP Connection Reset

Ø      For normal shutting down a connection, use FIN.

Ø      Sometimes abnormal conditions arise that force an application program or the network software to break a connection. TCP provides a reset facility for such abnormal disconnections.

Ø      Segment with the RST bit in the CODE field set.

Ø      The other side responds to a reset segment immediately by aborting the connection.

Ø      A reset is an instantaneous abort that means that transfer in both directions ceases immediately, and resources such as buffers are released.

v      Forcing Data Delivery

Ø      Consider using a TCP connection to pass characters from an interactive terminal to a remote machine. The user expects instant response to each keystroke. If the sending TCP buffers the data, response may be delayed, perhaps for hundreds of keystrokes.

Ø      TCP provides a push operation that an application program can use to force delivery of octets currently in the stream without waiting for the buffer to fill.

Ø      In addition, a segment with the PSH bit set is sent to the receiver, so the data will be delivered to the application program on the receiving end without waiting for the buffer to be filled.

v      Reserved TCP Port Numbers

Ø      Port numbers range from 0 to 65536.

Ø      Port numbers 0 to 1024 are reserved for privileged services and designated as well-known ports (in other words, only root has the permission to use these reserved port numbers).

Ø      Example

t         22: SSH

t         23: telnet

t         80: http

TCP Attacks

v      SYN Flooding

Ø      An attacker sends many SYN packets to create multiple connections without ever sending an ACK to complete the connection.

Ø      The victim has to keep the half-opened connection in its memory for certain amount of time (e.g. 75 seconds).

Ø      If there are so many of these malicious packets, the victim quickly runs out of memory.

Ø      Denial of Service (DoS) attack

Ø      Those SYN packets usually use spoofed IP addresses.

v      TCP Session Hijacking (Mitnick Attack)

Ø      Discussion: Machine A and B. If a user rlogin from B to A, A will not ask for a password (e.g. .rhosts). You are an attacker. Can you login to A from your own machine?

t         Hint 1: sequence number

t         Hint 2: Bts role

Ø      Guessing the sequence numbers Session Hijacking

Ø      SYN flooding B.

Ø      Defense methods

t         Encryption is the only complete defense

t         Checksum carry a keyed hash.

v      TCP RST Attacks

Ø      Attackers inject an RST segment into an existing TCP connection, causing it to be closed.

Ø      The TCP Reset attack is made possible due to the requirements that a TCP endpoint must accept out of order packets that are within the range of a window size, and the fact that Reset flags should be processed immediately.

v      TCP Port Scanning

Ø      TCP SYN scan

Ø      TCP connect() scan

Ø      FIN, Xmas Tree or Null scan: closed ports are required to reply with an RST, while open ports must ignore the packets in question (RFC).

Ø      FIN Scan
The FIN scants tstealtht frames are unusual because they are sent to a device without first going through the normal TCP handshaking. If a TCP session isntt active, the session certainly cantt be formally closed!

Ø      The Xmas Tree Scan

The Xmas tree scan sends a TCP frame to a remote device with the URG, PUSH, and FIN flags set. This is called a Xmas tree scan because of the alternating bits turned on and off in the flags byte (00101001), much like the lights of a Christmas tree.

Ø      NULL Scan

The null scan turns off all flags, creating a lack of TCP flags that should never occur in the real world.

v      Fingerprinting hosts

Ø      What makes it possible?

t         Different OS choose unique values for certain fields, such as TTL, TOS, TCP window size, TCP options.

t         Different OS may choose different way to response (not exactly follow RFC).

Ø      Tool: nmap -O -v host : identify OS version and tell you how difficult it is to   predict initial sequence #.

Ø      The FIN probe: Here we send a FIN packet (or any packet without an ACK or SYN flag) to an open port and wait for a response. The correct RFC 793 behavior is to NOT respond, but many broken implementations such as MS Windows, BSDI, CISCO, HP/UX, MVS, and IRIX send a RESET back. Most current tools utilize this technique.

Ø      The BOGUS flag probe -- Queso is the first scanner to use this clever test. The idea is to set an undefined TCP 'flag' (bit 7 or 8, counting from the left) in the TCP header of a SYN packet. Linux boxes prior to 2.0.35 keep the flag set in their response. However, some operating systems seem to reset the connection when they get a SYN+BOGUS packet. This behavior could be useful in identifying them. Update: Bit 8 (and 9) are now used as the 'ECN field' for TCP congestion control.

Ø      TCP ISN Sampling -- The idea here is to find patterns in the initial sequence numbers chosen by TCP implementations when responding to a connection request. These can be categorized in to many groups such as the traditional 64K (many old UNIX boxes), Random increments (newer versions of Solaris, IRIX, FreeBSD, Digital UNIX, Cray, and many others), True 'random' (Linux 2.0.*, OpenVMS, newer AIX, etc). Windows boxes (and a few others) use a 'time dependent' model where the ISN is incremented by a small fixed amount each time period.

Ø      ICMP Message Quoting -- The RFCs specify that ICMP error messages quote some small amount of the IP packet that causes various errors. For a port unreachable message, almost all implementations send only the required IP header + 8 bytes back. However, Solaris sends back a bit more and Linux sends back even more than that. The beauty with this is it allows nmap to recognize Linux and Solaris hosts even if they don't have any ports listening.

Ø      IPID sampling

Ø      SYN Flood Resistance

Ø      Overlapping Fragmentation Handling

Ø      Don't Fragment bit

Ø      TCP Initial Window

Ø      ICMP Error Message Quenching

v      The Security of the Initial Sequence Number (ISN)

Ø      If an attacker can find out current sequence number that is being used by an existing TCP connection, it can inject a valid TCP segment into the existing TCP connection.

t         If the attacker is within the same LAN, it can sniff the sequence number.

t         If the attacker is not within the same LAN, it has to guess the sequence number.

Ø      To guess ISN:

t         All possible values for ISN: 2³².

t         We only need to make sure that the guessed ISN is within the receiverts current window; otherwise, the TCP packet with this guessed ISN will be discarded by the receiver.

t         If 16K window size is used, on average, it only takes 2³² / 2¹⁴ = 2¹⁸ = 262,144 tries to hit the window.

t         With a T1 line at 4,370 packets a second, the attacker would be able to exhaust all possible windows within only 60 seconds.

Ø      Initial window size for various operating systems (from Watson [2]). The packets required for a successful guess are based on the equation: (2^32 / Initial Window Size)

v      Adjusting Default TCP Window Size

Ø      Windows 2000: Tuning of Window size can be accomplished by adjusting registry settings. The registry keys of interest can be found in the registry at this location:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters

Ø      Solaris: Adjusting the default TCP window size in Solaris can be accomplished using the ndd command.

# ndd -set /dev/tcp tcp_xmit_hiwat [0C65535]

# ndd -set /dev/tcp tcp_recv_hiwat [0-65535]

Ø      Linux (2.4.x kernels): The following two variables can be added to the /etc/sysctl.conf file. The names trmemt and twmemt correspond to receive and transmit respectively. After settings these values, execute the tsysclt Cpt command to have them take effect.

net.core.rmem_default = [0C65535]

net.core.wmem_default = [0C65535]

v      Guessing the source port

Ø      When a TCP connection is made, the combination of the source port and IP address and the destination port and IP address results in a unique fingerprint that can be used to differentiate between all active TCP connections.

Ø      Most of the TCP attacks assume that the attacker already knows the destination port and IP address as well the source port and IP address. The destination port and IP address are easy, as they are generally published. The source IP address is also generally easy, as this is simply the client that is being spoofed. The only piece that can frequently be difficult to find is the source port.

Ø      For example, if an operating system randomly assigns source ports from a pool that ranges from 1025 through 49,152 (such as OpenBSD), this increases the difficulty of performing a reset attack 48,127 times as the attacker would have to try their sequence attack with every possible port number. In our example with 16k windows, we determined that with known endpoints it would require 262,144 packets to guarantee a successful reset attack. However, if using random ports as we've described, it would now require 262,144 times 48,127, or 12,616,204,288 packets. An attack of that size would all but certainly be detected and dealt with before a brute force reset would occur.

Ø      Unfortunately, most operating systems allocate source ports sequentially, including Windows and Linux. A notable exception is OpenBSD, which began randomizing source port allocation in 1996.

Ø      The following chart represents observations of source port selection from various Operating Systems (from Watson [2]):

v      ICMP Attacks against TCP

Ø       More details can be found at https://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html.

Ø      Thus, for ICMP messages generated by hosts, we can only expect to get the entire IP header of the original packet, plus the first 64 bits of its payload. For TCP, that means that the only fields that will be included are: the source port number, the destination port number, and the 32-bit TCP sequence number. This clearly imposes a constraint on the possible security checks that can be performed, as there is not much information available on which to perform them.

v      ICMP Blind Connection-reset attacks

Ø      The Host Requirements RFC [4] states that a host SHOULD abort the corresponding connection when receiving an ICMP error message that indicates a hard error.

Ø      A single ICMP packet could bring down all the TCP connections between the   corresponding peers.

Ø      Counter-measures

t         The following types of ICMP messages are not reasonable, should be ignored:

t         ICMP type 3 (Destination Unreachable), code 2 (protocol unreachable)

t         ICMP type 3 (Destination Unreachable), code 3 (port unreachable)

t         ICMP type 3 (Destination Unreachable), code 4 (fragmentation neededand DF bit set)

t         Delaying the connection-reset:

Rather than immediately aborting a connection, a TCP could abort a connection only after an ICMP error message indicating a hard error has been received a specified number of times, and the corresponding data have already been retransmitted more than some specified number of times.

v      Blind throughput-reduction attacks

Ø      The Host requirements RFC states hosts MUST react to ICMP Source  Quench messages by slowing transmission on the connection. Thus, an attacker could send ICMP Source Quench (type 4, code 0) messages to a TCP endpoint to make it reduce the rate at which it sends data to the other party. While this would not reset the connection, it would certainly degrade the performance of the data transfer taking place over it.

Ø      However, as discussed in the Requirements for IP Version 4 Routers RFC 1812, research seems to suggest ICMP Source Quench is an  ineffective (and unfair) antidote for congestion. Thus, we recommend hosts to completely ignore ICMP Source Quench messages.

References

Figures, texts, and tables used in this lecture notes come from the following sources.

Comerts TCP/IP slides

Slipping in the Window: TCP Reset attacks, by Paul A. Watson (https://www.osvdb.org/reference/SlippingInTheWindow_v1.0.doc).

Secrets of Network Cartography: a comprehensive guide to nmap 3.81 (https://www.networkuptime.com/nmap/index.shtml).

Remote OS detection via TCP/IP Stack FingerPrinting, by Fyodor (https://www.insecure.org/nmap/nmap-fingerprinting-article.html).

The TCP/IP Guide (https://www.tcpipguide.com/free/t_toc.htm).

ICMP attacks against TCP, by Gont, 2004. (https://www.gont.com.ar/drafts/icmp-attacks-against-tcp.html)