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

• 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

14

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???

• 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

24

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

28

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

30

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.

33

34

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

35

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

• 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 2.4.28: 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

• 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 2.4.18: add 1– Nokia IPSO: add 1

44

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

50

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.)

55

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.

58

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