TCP Connection Management 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 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 Socket clientSocket = new Socket("hostname","port number"); server: contacted by client Socket connectionSocket = welcomeSocket.accept(); Transport Layer

TCP Connection Management (cont.) Closing a connection: client closes socket: clientSocket.close(); 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 Transport Layer

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 Transport Layer

Acknowledgment Number TCP Packets TCP adds “sessions” or “connections” to the bare IP protocol: 15 16 31 Source Port Destination Port Sequence Number Acknowledgment Number Data Offset Flags Window Checksum Urgent Pointer Options Data Flags: URG: Urgent ptr valid RST: Reset flag ACK: ACK valid SYN: Synchronize seq #s PSH: Push function FIN: Finish of connection Transport Layer

(SYN|ACK, S-Seq, C-Seq+1) The 3-way handshake Labels below give (Flags, Seq#, Ack#): (SYN, C-Seq, 0) (SYN|ACK, S-Seq, C-Seq+1) (ACK, C-Seq+1, S-Seq+1) Server Client To establish connection, client must prove that it received the SYN|ACK packet! SYN|ACK packet routed to system with source address from first SYN packet Since based on routing, only secure back to the subnet of the source Note idea of a “nonce” to prove that these packets are part of this session Transport Layer

SYN Issues – Predictability Sequence numbers should be unpredictable Most systems today select random values that meet some necessary conditions Otherwise: To fake Src: (SYN|ACK, S-Seq, C-Seq+1) With fake Src: (SYN, C-Seq, 0) Conditions: Seq numbers must be basically increasing (ACK, C-Seq+1, Predict-S-Seq+1) Client Server Data pretending to come from fake Src Particularly dangerous when “fake Src” is a trusted IP address Transport Layer

SYN Issues – SYN Flooding Server Data Structures (SYN, C-Seq1, 0) (SYN|ACK, S-Seq1, C-Seq1+1) Half-open conn S-Seq1 (SYN, C-Seq2, 0) (SYN|ACK, S-Seq2, C-Seq2+1) Half-open conn S-Seq2 Client (SYN, C-Seq3, 0) (SYN|ACK, S-Seq3, C-Seq3+1) Half-open conn S-Seq3 . . . Server DoS isn’t due to traffic volume but to resource exhaustion (memory) in the server O.S. Early network stacks had a severely limited number of half-open structures available Can spoof SRC address with non-existent host Remember: Server must be able to verify whether the ACK from the 3rd part of the handshake is valid Transport Layer

TCP Limitations provides strict ordering of information result: Head of Line Blocking (HOL) problem what is needed in many cases, is only partial ordering of data byte oriented nature….inconvenience for telephony signaling no built-in support for multi-homed IP hosts vulnerability to SYN flooding attacks Transport Layer