ITIS 61678167 Network Security Weichao Wang Contents ICMP

ITIS 6167/8167: Network Security Weichao Wang

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

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

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

• 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 5

• 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 6

• Layer structure 7

• 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 8

• 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 9

• TCP segment format 10

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

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

• 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 13

14

• 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 15

• 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 16

• 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 17

• 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 18

• 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 19

• 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 20

• 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 21

• 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 22

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

• 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

• 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 25

• 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 26

• 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 27

28

• 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 29

30

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

• 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. 32

33

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

35

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

• 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 37

• 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 = 16 K byte, you need to send (2^32) / (2^14) = 2^18 packet = 262 K pkt – If you can send out 4 K pkt/second, you will need about 65 seconds 38

• Initial window size for various OS and the packets needed to guess the sequence number – Win 2 K Sp 4, Win XP Sp 1: 64 K Byte (66 K pkt) – HP-UX 11: 32 K Byte (131 K pkt) – Nokia IPSO, Cisco IOS 12. x, Win 2 K Sp 1, Win 2 K Sp 3: 16 K Byte (262 K pkt) – Linux 2. 4. 28: 5. 8 K byte (735 K pkt) 39

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

• 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) 41

• 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 42

• Unfortunately, most OS allocate port numbers in order (Windows and Linux). Open. BSD 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 43

44

• 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 45

• 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 IPv 6 may still be vulnerable to some attacks 46

• 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 47

• 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 48

• 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, Open. BSD, Free. BSD, and Net. BSD) – TCP port randomization – Ingress and egress packet filtering 49

50

• 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 51

• 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 52

• 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 Free. BSD, Open. BSD, Net. BSD, and Linux 53

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

55

• 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 56

• Countermeasures – RFC 1812 shows that source quench is ineffective to congestion – TCP has its own congestion control – Solution: ignore source quench ICMP – Linux, Free. BSD, Open. BSD, and Net. BSD adopt this since 2004 and 2005. 57

58

• 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 59

• 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 Open. BSD and Net. BSD since 2005 60