1. ITIS 6167/8167: Network Security
Weichao Wang

2. Contents ICMP protocol and attacks UDP protocol and attacks
TCP protocol and attacks

3. TCP: Transmission Control Protocol
The most loved and hated protocol
Various protocols have been developed to replaced it, but not work very well

4. The need for stream delivery
Out of order
Packet delay
Packet loss
Packet duplicate

5. TCP’s properties Stream orientation Virtual circuit connection
TCP treats data as continuous flow of bytes
The sequence of the sent and received data are exactly the same
Virtual circuit connection
Buffered transfer
Application can determine the size of the pieces of the information it wants to transfer
Protocol software will divide the information into segments
Usually use a segment with a reasonable size
Can use “push” option to force transfer without buffering

6. Unstructured stream
TCP does not honor structured data stream
It is the application’s responsibility to understand the data structure
Full duplex connection: transfer in both directions (can close one direction while keeping the other active)
Reliability
Positive acknowledgement with retransmission

7. Layer structure

8. TCP ports TCP uses ports to identify applications
A connection is identified by four items
Source IP and protocol port number
Destination IP and protocol port number
A given TCP port number can be shared by multiple connections on the same machine because they will have different source IP and port numbers

9. Reserved TCP port number
Port number can be 0 to 65535
0 to 1024 are reserved for well known services
7: echo
13: Daytime
21: FTP
22: SSH
23: TELNET
25: SMTP
53: DNS
79: Finger
80: HTTP

10. TCP segment format

11. HLEN: length of segment header measured in 32 bits
Checksum: over (pseudo header, TCP header, TCP data)

12. CODE Bits: the purpose and contents of the segment

13. Sliding window mechanism
Used for flow control
Operate at the byte level, instead of packet or segment level (why)
An example of the sliding window

15. In the window: Octets through 2 have been sent and acknowledged
Octets 3 to 6 have been sent but not acknowledged
Octets 7 to 9 have not been sent but can be sent
Octets 10 and above cannot be sent

16. Receiver’s window:
Receiver maintains a window, it is different from the sender’s window
It indicates how many more bytes the receiver can accept
Bytes falling out of the window will be discarded

17. TCP allows the window size to change over time
In each acknowledgement, the WINDOW size identifies how many more octets the receiver can accept. It can be viewed as the buffer size at the receiver side.
If the window size increases, the sender move the sliding window forward and send more octets
If the window size decreases, stop sending new bytes to the remote side. (not necessarily back move the window)
Window size can be 0

18. Out of band data
TCP treats data like streams, what if we have some data of emergency and cannot wait till the end of the stream?
Example: Control-C to stop the program
Urgent code bit can be used to specify this kind of data
Urgent pointer: specify where the data ends

19. Acknowledgement number: the next byte the receiver expects to receive
The ACK focuses on the continuous data that have been received. The isolated pieces will not be acknowledged.
There are versions supporting selective retransmission

20. Timeout and retransmission
The packets can get lost because of various reasons
A timer will be started for every sent segment
If timer expires, we will resend the segment
Figuring out the appropriate timeout:
If it is too short, too many resend
If it is too long, cannot respond to packet lost properly

21. Deriving the timeout
Measure the round trip time b/w the packet and ack
Using a weighted average value
Timeout = constant * RTT
How to handle resent packets?
There are tens of papers discussing this issue

22. Congestion control
The sender and receiver windows only handle problems at the end points. Packet may get lost at the intermediate routers
TCP uses congestion window
allowed win = min(receiver win, congestion win)
Routers drop packets when congestion happens, leading to retransmission

23. Retransmission leads to worse congestion
To reduce congestion, TCP uses two methods
Multiplicative decrease congestion avoidance: when a packet loss happens, reduce the congestion window by half. Back off the retransmission timers for the packets still in window
Slow start recovery: for a new connection or after a congestion, start the window at one segment, increase the window by one segment after every received ack
Is this slow enough???

24. Other schemes for congestion control
Congestion avoidance: after the congestion window reaches a threshold, add one segment after each RTT
Fast retransmission: resend packets when multiple ACK with the same ACK number received
Fast recovery: reduce the window to the threshold

25. Silly window and countermeasures
The receiver’s window is full
It fetches one byte from the window every time and sends an ACK
One more byte will be sent from the sender
Very low efficiency
How to avoid silly window:
Receiver’s view
Sender’s view

26. PUSH bit: forcing data delivery
If we are using TCP for an interactive terminal, holding data may lead to bad interfaces. User cannot see key stroke results.
TCP provides a PUSH bit to force data delivery without delay
The PUSH bit also tells the receiver to handle the data immediately

27. Establishing TCP connection: 3 way hand shake
Three way hand shake accomplish two things:
Both sides ready for the transmission
Both sides agree the initial sequence number
Initial sequence number
Each machine should choose this at random
Non-random sequence has security problems

29. Closing a TCP connection
TCP can close the connection in one direction by sending a FIN packet
Once the connection is closed, TCP will not accept more data. Data can still flow in the opposite direction.
When both ends close the connection, the resources can be released

31. The above figure only illustrates the perfect world
Timed wait period in the state machine of TCP
For emergency condition, use connection RESET

32. TCP Connection reset
Abnormal condition arise and we need to break the connection.
Send a segment with RST bit set
Both sides will cut the connection and release all the resources.
If not authenticated, can be used for attack.

34. The problem of TCP connection over very high speed connection:
the Window size is too small.

36. Attacks on TCP SYN flood The earliest DoS attacks
Attacker sends the first SYN packet, initiates the connection
Never bother to send the ack
The victim allocates resources and maintains the half-open connection for a duration of time (75 sec in many systems)
The SYN packets with spoofed IP source address

37. Security of Initial Sequence Number (ISN)
The data falling out of the receiver’s window will be discarded. So guessing the current window is an important step for many attacks on TCP.
Inject invalid packet to the TCP connection
Blind reset attack
Security of Initial Sequence Number (ISN)
The attacker wants to know what the ISN is
If on the same network, sniff the packet
Otherwise, guess the sequence number

38. Is it hard to guess the sequence?
It is a 32 bit number
If the window size is w, you need to send (2^32) / w packets.
If w = 16K byte, you need to send (2^32) / (2^14) = 2^18 packet = 262K pkt
If you can send out 4K pkt/second, you will need about 65 seconds

39. Initial window size for various OS and the packets needed to guess the sequence number
Win 2K Sp4, Win XP Sp1: 64K Byte (66K pkt)
HP-UX11: 32K Byte (131K pkt)
Nokia IPSO, Cisco IOS 12.x, Win 2K Sp1, Win 2K Sp3: 16K Byte (262K pkt)
Linux : 5.8 K byte (735K pkt)

40. Windows 2K, Linux, and Solaris: can adjust the initial window size

41. Guess the source port:
Every TCP connection is labeled by two pairs of (IP, port number)
If the attack packet is not correctly labeled by the IP and port, it will be discarded
It is not too difficult to determine 3 out of the 4 parameters:
Destination IP and port number (server side)
Source IP (this is your victim)

42. If the ports are randomly assigned at the source side, there are thousands of possibilities.
It will be very difficult for the attacker to correctly guess both valid window sequence and the port number: if identify sequence number needs 1 minute, now we need thousands of minutes.
So many scan packets can be easily identified
Most connections will not last for thousands of minutes

43. Several examples of relationship b/w allocated port numbers
Unfortunately, most OS allocate port numbers in order (Windows and Linux). OpenBSD starts to use random numbers since 1996.
Several examples of relationship b/w allocated port numbers
Cisco IOS 12.x: add 1 or add 512
Windows 2000 and XP: add 1
Linux : add 1
Nokia IPSO: add 1

45. ICMP attacks on TCP
ICMP error reporting packets contain the IP header and first 8 bytes of the original packet
Include the source port, destination port, and sequence number of TCP
How can we authenticate the packet
Several attacks
Blind connection reset
Blind throughput reduction
Blind performance degrading

46. RFC 1122 classifies the ICMP error messages into those reporting “hard errors” and “soft errors”
ICMP has the source quench messages
RFC 1191 defines Path MTU discovery to figure out the MTU along a path. It uses (fragment needed but DF set) to figure this out.
ICMP for IPv6 may still be vulnerable to some attacks

47. RFC 1122 requires that TCP must respond to ICMP error messages
Thus, the source IP and port, and destination IP and port will be in the ICMP packet
No authentication methods are defined
Attacker can generate fake ICMP packets to impact TCP connections

48. Possible solutions and their restraints
RFC 1812 says that “ICMP message should contain as much information as possible from the original packet as long as it is not longer than 576 bytes”
The original IP packet cannot be authenticated if we do not have the whole packet
Authentication b/w
End nodes
End node and routers

49. TCP should check the following fields in the original IP packet causing the ICMP message before taking action
TCP sequence number (already implemented in Linux, OpenBSD, FreeBSD, and NetBSD)
TCP port randomization
Ingress and egress packet filtering

51. Blind connection reset attack
TCP handles ICMP error reports as follows:
If it is a hard error, abort the connection
If it is a soft error, retransmit data until connection timeout

52. In RFC 1122, it says
ICMP type 3 (destination unreachable), code 2 (protocol unreachable), code 3 (port unreachable), and code 4 (fragment but DF) are all hard errors
Attacker can use these ICMP messages to reset TCP connections even when they are off path
Some OS will extrapolate ICMP errors across TCP connections. And multiple connections can be impacted by a single ICMP packet

53. Countermeasures Reconsider the “hard” errors
Type 3, code 2 (protocol unreachable) should appear during the establishment procedure. Otherwise, treated as a soft error
Type 3, code 3 (port unreachable) should also be treated as soft errors if TCP has its own methods to handle port listening problems
Type 3, code 4 (fragment but DF): do not set this bit unless you have already figure out the MTU on the path
Implemented in FreeBSD, OpenBSD, NetBSD, and Linux

54. Delay the connection reset
Delay the reset until the packet has been received for a certain amount of time, and the data packets have been retransmitted for a certain number of times. (the idea is that if we are making progresses, there is no hard errors.)

56. Blind Throughput reduction
RFC 1122 requires nodes to react to source quench ICMP messages
Some OS will use slow start and set the size to one segment
Now we send one packet every RTT, the throughput is low

57. Countermeasures
RFC 1812 shows that source quench is ineffective to congestion
TCP has its own congestion control
Solution: ignore source quench ICMP
Linux, FreeBSD, OpenBSD, and NetBSD adopt this since 2004 and 2005.

59. Blind performance degrading attack
We can use (fragment but DF) to detect the path MTU
Attacker can use this ICMP message to attack TCP by sending a very small MTU value
Now the performance is impacted since the header/data ratio changes
If the MTU is set too small, no data can be actually sent

60. Countermeasures A method similar to the “delayed reset” will be used
The MTU will change only when the packet has been retransmitted for a certain number of times
Implemented in OpenBSD and NetBSD since 2005