1. TCP/IP Vulnerabilities

2. Contents Vulnerabilities in IP protocol ICMP attacks Routing attacks
TCP attacks
Sequence number prediction
TCP SYN flooding
Congestion control with a misbehaving receiver

3. Historical perspectives
TCP/IP and their associated protocols were designed without any security consideration in mind.
“Security problems in the TCP/IP Protocol Suite” by S. M. Bellovin
This paper was written in It gave the security perspective on TCP/IP protocols in the early days.
It acted as a wakeup call for network researchers, listing many security vulnerabilities.

4. Vulnerabilities in IP protocol
Fundamental flaw in IP protocol is to use IP address as authentication.
IP source address can be easily spoofed.
It is easy for attackers to impersonate another host in the same network.

5. Basic attacks C A B Server 2.0.0.0 2.1.1.1 Internet 1.1.1.1 1.1.1.2
Server
How can the server know that the packet is originated from A?
Can B overhear?
Can B impersonate A to the server?
Can C impersonate A to the server?

6. IP fragmentation attack
In the regular IP layer operations, a host stores fragmented packets until entire packets arrive.
Attack: send only one fragmented packet. Then the host will wait indefinitely, wasting memory to store them.
Countermeasure?

7. Smurf attack
Send a packet with a broadcast address to a network with source address as a victim’s address.
All hosts on the network will send reply packets to the victim.
This is called a reflector attack. In this case the reflector also performs traffic amplification.

8. ICMP attacks
ICMP is the basic network management tool of the TCP/IP protocol suite.
It poses potential threats for abuse.
ICMP redirect message
Attacker sends false ICMP redirect message to a host to redirect traffic for a destination through another gateway.
ICMP destination unreachable
DoS attack
ICMP TTL exceed

9. Routing Attacks Source routing attack
Not possible today’s networks
Routing information protocol attack
An attacker sends bogus routing information to a target router to impersonate a particular router.
It is necessary to authenticate every routing information packets.
BGP routing attacks

10. TCP attacks: Sequence number prediction
Normal TCP precedure
C → S: SYN(ISNc)
S → C: SYN(ISNs). ACK(ISNc)
C → S: ACK(ISNs)
C → S: data and/or
S → C: data
If an intruder X can predict ISNs, X can impersonate T:
X → S: SYN(ISNx). SRC=T
S → T: SYN(ISNs). ACK(ISNx)
X → S: ACK(ISNs), SRC=T
X → S: ACK(ISNs), SRC=T, nasty-data

11. How to decide ISN? Are these good choices for next TCP ISN?
Always start at the same ISN
After each connection, increment ISN
ISN = (c1+c2*(current time)) mod 232
Better choice for ISN?
ISN = rand() function of C library?
Current ISN = H(prev ISN)?
ISN = DESK(counter++)?

12. TCP hijacking and poisoning
If TCP sequence number is known, attacker can inject malicious message into TCP stream.
TCP poisoning
Inject random data into TCP stream to shut down TCP connection
Does sequence number need to be known?

13. TCP SYN Flooding Normal TCP precedure SYN flooding C → S: SYN(ISNc)
S → C: SYN(ISNs). ACK(ISNc)
C → S: ACK(ISNs)
C → S: data and/or
S → C: data
SYN flooding
The server S needs to keep state after receiving initial SYN packet.
Attacker floods server with SYN packets, but does not follow up with ACK packets to complete TCP handshake.
The server keeps state waiting for ACK, consequently exhausting resources.

14. SYN Flooding Dos Attack
It was the first serious DoS attack, single attacker could tie up server resources to prevent other clients from connecting to server.

15. SYN Flood Details Why does server exhaust resources?
Need to store requests for 511 seconds
Server has finite-size queue for incomplete connections, usually 1024 entries
Memory is cheap, why not store all requests?
With 160 bytes for syncache data structure, still consumes a lot of memory (736 bytes previously)
Why store any information at all?
If SYN ACK dropped by network, server re-sends SYN ACK until timeout or client sends ACK, otherwise legitimate clients will wait
In some cases TCP options (performance enhancements) need to be stored.
Attacker could simply send ACK only if no information stored, hope server will allocate resources for connection

16. Solution: TCP SYN Cookie
Server computes ISN based on the client’s addresses, which is called SYN cookie, and avoid to keep the client’s state.
Server does not remember the cookie or any other state info corresponding to the SYN.
Client sends ACK.
Server verifies ISN. If correct, it allocates connection state.
How to compute SYN cookie?
Cookie=H(SIP, CIP, Sport, Cport, skey), skey is a secrete number only known to the server.

17. “Defining Strategies to Protect Against TCP SYN Denial of Service Attacks,”
“SYN Cookies,” D. Bernstein,

18. Questions:
What if SYN segment has some relevant information to the client state such as TCP option?
What if attackers return valid ACK for each SYN ACK? This will cause the server to establish fully open TCP connections.
This “completed handshake attack” can be more difficult to defend than the classical SYN flooding attack.

19. Congestion control with a misbehaving receiver
“TCP congestion control with a misbehaving receiver”, Savage, Cardwell, Wetherall, and Anderson

20. Slow Start Control parameters Slow Start
Awnd (advertised window by receiver)
Cwnd (congestion window)
Determine how many segments can be sent without receiving ACKs..
Slow Start
Initialize: cwnd = 1 MSS (max. segment size);
Every time each ACK arrives:
cwnd = cwnd + 1 MSS until min(cwnd, awnd)
TCP는 window를 통해 데이터의 흐름을 조절한다.
Window
어느 순간에 상대편으로부터 데이터를 받을 수 있는 버퍼의 크기
window advertisement
상대편에게 window의 크기, 즉 가용 버퍼의 크기를 알려 주는 것을 말한다.
매번 ACK 세그먼트를 보낼 때 마다 window advertisement를 한다.
Slow start
두개의 파라메터에 의한다.(단위는 세그먼트의 수)
Receiver’s advertisement window(awnd)
처음 연결이 설정되면 수신측은 송신측에 자신의 버퍼의 크기를 알려 준다.
초기의 awnd는 이 값으로 할당된다.
Congestion window(cwnd)
현재의 순간에 송신측의 window 크기
초기에 cwnd =1 로 할당한다.

21. ACK Division Attack
Upon receiving a segment, a receiver divides an ACK into multiple ACKs. Then the sender increases the congestion window by SMSS (Sender Max Segment Size) for each ACK received

22. Fast retransmission
If 4 consecutive ACKs(3 dupacks) are received before timeout, then TCP does not wait for timeout and retransmit the segment immediately.

23. Fast recovery algorithm (avoiding initial slow start phase)
1. When the third duplicate ACK is received,
Set ssthresh = cwnd / 2;
Retransmit the missing segment;
cwnd = ssthresh + 3 segment size ;
2. Each time another duplicate ACK arrives,
Increment cwnd by the segment size;
Transmit a new segment (if allowed by the new cwnd value);
3. When the next ACK arrives that acknowledges the new data,
cwnd = ssthresh ;
cwnd = cwnd + 1 every roundtrip time ;

24. Duplicate ACK Spoofing
Fast retransmit and fast recovery should mitigate the effect of packet loss that is not due to congestion, but an attacker can exploit it to get more data
Send extra duplicate ACKs
Sender sends 1 packet for each duplicate ACK
Preserves reliability

25. Optimistic ACKing Attack
Receiver can send ACKs for data not yet received, or even not yet sent
Does not provide reliability

26. Countermeasures: