1. CS 5565 Network Architecture and Protocols
Lecture 12
Godmar Back

2. Announcements Homework 2 due Mar 16 Project 1B due Mar 14
Reminder: can be done as a team, can switch teams between projects, use forum if you’re looking for team members
CS 5565 Spring 2012
9/17/2018

3. Study of TCP: Outline segment structure reliable data transfer
delayed ACKs
Nagle’s algorithm
timeout management, fast retransmit
flow control + silly window syndrome
connection management
[ Network Address Translation ]
[ Principles of congestion control ]
TCP congestion control
CS 5565 Spring 2012
9/17/2018

4. Connection Management
TCP
Connection Management

5. TCP Connection Management
Recall: TCP sender, receiver establish “connection” before exchanging data segments
initialize TCP variables:
seq. #s
buffers, flow control info (e.g. RcvWindow)
client: connection initiator
connect(s, &dstaddr, …)
server: contacted by client
cl=accept(sv, &caddr,…);
Three way handshake:
Step 1: client host sends TCP SYN segment to server
specifies initial seq #
no data
Step 2: server host receives SYN, replies with SYNACK segment
server allocates buffers
specifies server initial seq. #
Step 3: client receives SYNACK, replies with ACK segment, which may contain data
CS 5565 Spring 2012
9/17/2018

6. TCP 3-way handshake TCP connection establishment:
Q1: why 3-way and not 2-way handshake?
Q2: how do sender & receiver determine initial seqnums?
CS 5565 Spring 2012
9/17/2018

7. 3-way Handshake & Delayed Dups
Normal operation
Old SYN appearing out of nowhere.
Duplicate SYN and duplicate ACK following SYN.
3-way handshake required to deal with scenarios (b) and (c)
CS 5565 Spring 2012
9/17/2018

8. Sequence Number Reuse Idea: Tie initial TCP seq numbers to clock
Increment every 4s, guards against previous incarnations of a connection with identical sequence numbers
Must also guard against sequence number prediction attack
Use PRNG see [RFC 1948], [CERT ]
RFC 1948: ISN = 4s clock val + F(src, dst, sport, dport, random())
CS 5565 Spring 2012
9/17/2018

9. When Sequence Numbers Attack
Suppose attacker A can predict sequence number a host B is going to use next
By using spoofed source IP C, A can engage in successful 3-way handshake with B
B believes it is talking to C, might grant permissions based on C’s IP address
Attacker on A must suppress the RST packets C is likely to send – use a denial-of-service attack for that
A sends message to compromise B
CS 5565 Spring 2012
9/17/2018

10. When SYNs Attack Servers receiving SYN must allocate resources
Opens up possibility of denial-of-service attack where server is flooded with bogus SYN packets with forged IP source addresses
Solution:
SYN cookies
Server creates ACK number, sends ACK – but does not allocate buffers
If client continues with SYNACK, check if ACK could have been sent, then allocate buffers if correct
CS 5565 Spring 2012
9/17/2018

11. Sequence Number Summary
Goals Set 1:
Guard against old duplicates in one connection -> don’t reuse sequence numbers until after it’s reasonably certain that old duplicates have disappeared
Even after a crash restart -> hence tie to time -> but don’t use global clock -> hence need 3-way handshake were each side verifies the sequence number chosen by the other side before successful connection occurs
Goals Set 2:
Don’t allow high-jacking of connections unless attacker can eavesdrop – use PRNG for initial seq number choice
Don’t allow SYN attacks – compute, but don’t store initial sequence number
CS 5565 Spring 2012
9/17/2018

12. TCP Connection Management (cont.)
Closing a connection:
client closes socket: close(s);
Step 1: client end system sends TCP FIN control segment to server
Step 2: server receives FIN, replies with ACK. Closes connection, sends FIN.
client
FIN
server
ACK
close
closed
timed wait
CS 5565 Spring 2012
9/17/2018

13. TCP Connection Management (cont.)
Step 3: client receives FIN, replies with ACK.
Enters “timed wait” - will respond with ACK to received FINs
Step 4: server, receives ACK. Connection closed.
Note: with small modification, can handle simultaneous FINs.
client
server
closing
FIN
ACK
closing
FIN
ACK
timed wait
closed
closed
CS 5565 Spring 2012
9/17/2018

14. TCP Connection FSM
The heavy solid line is the normal path for a client.
The heavy dashed line is the normal path for a server.
The light lines are unusual events.
Each transition is labeled by the event causing it and the action resulting from it, separated by a slash.
CS 5565 Spring 2012
9/17/2018

15. TCP Connection Management (cont’d)
TCP client lifecycle
TCP server lifecycle
CS 5565 Spring 2012
9/17/2018

16. Closing a Connection Note: previous charts showed normal case
Can we reliably close a connection if packets (FIN, ACK) can be lost?
No: Famous two-army problem
CS 5565 Spring 2012
9/17/2018

17. Summary TCP segments, acknowledgements & retransmission
Delayed ACKs, Nagle’s algorithm
Fast retransmit
RTT estimation & Karn’s algorithm
Flow Control & Silly Window Syndrome
Connection Management in TCP
Attacks against TCP’s connection management scheme
SYN attack
Sequence number prediction attacks
CS 5565 Spring 2012
9/17/2018

18. TCP Miscellaneous MSS Maximum Segment Size Option
Client/server agree on larger than default (536 outside same subnet) MSS, option on SYN
SACK – selective acknowledgements
WSCALE – scale factor for receive window to allow for LFN (“elefant”) – Large Fat Networks
RFC 1323 timestamps for accurate RTT measurement, PAWS for protection against wrap-around for sequence numbers …
CS 5565 Spring 2012
9/17/2018