·
Sequence numbers
are generated differently by operating systems based on coded algorithms
o SEQ and ACK number fields are 32-bits which makes
a possibility of 2^32 = 4E9
·
When new connection
is started, the sender has to generate Initial Sequence Number (ISN)
o It's important to generate random ISN to avoid
hijacking TCP session. How it works?
·
NMAP can be used to
identify how easy is the algorithm to generate ISN
o ISN will be seen in SYN TCP packet sent
from sender ---> receiver & receiver ----> sender
·
Let's examine full
session
Packet#1 (3-WAY TCP Handshake S -----> SYN -----> R)
Packet#2 (3-WAY TCP Handshake S <----- SYN/ACK <----- R)
Packet#3 (3-WAY TCP Handshake S -----> ACK -----> R)
Packet#4 (Data Transmission S -----> R)
o Because this is SSL session the client is sending
Client Hello
o This packet and previous packet were from sender
to receiver and have same SEQ=1
· Because previous sender to receiver segment size was zero bytes (SYN/ACK packets don't carry application data)
Packet#5 (R -----> ACK -----> S)
o Next packet from receiver has ACK = SEQ (1) + 205
= 206 bytes, i.e. the receiver got the previous 205-bytes segment and waiting
for next one
o This receiver packet and previous receiver packet
are having same SEQ=1
· This is because previous segment from receiver to sender size was zero bytes (Packet#2)
Packet#6 (Data Transmission R -----> S)
o As part of SSL handshake, the server responds
with Server Hello
·
Because Server Hello contains server certificate chains, the
application data size is greater than sender MSS value (1460 bytes)
·
Accordingly you will
notice that Packets 6 - 8 and 10 - 12 are TCP segments which
belong to single application data (labeled as reassembled PDU)
§ To recap, this is the reason for encapsulating
application data over transport layer instead of sending it directly over IP
layer because application layer don't have mechanisms for error/flow control.
Sending such large data as one packet over IP layer will get it dropped because
typical Ethernet networks are limited to 1500-bytes without fragmentation.
Transport layer manages the segmentation and transportation of this data.
o The receiver could have sent Server Hello
before Previous ACK (Packet#5) because the
sender window size in Packet#4 was 66048 bytes
·
The order of
sending packets is subject to the operating system
·
The only
caveat is to make sure that ACK is sent before retransmission timer
expires at sender
o SEQ is still '1' because previous segment size was
zero bytes
o ACK is still '206' because not data received from
sender yet
·
Note that receiver
keeps sending ACK flag although previous ACK already sent. This is to avoid sender retransmission timer expiry
o Segment Size is 93 bytes
Packet#7 (Data Transmission R -----> S)
o As mentioned earlier, this packet is continuation
of same application data
o SEQ = 1 + 93 = 94 bytes
o ACK = 206 bytes (no segments received from
sender)
o Segment size = 1360-bytes
Packet#8 (Data Transmission R -----> S)
o As mentioned earlier, this packet is continuation
of same application data
o SEQ = 94 + 1360 = 1454 bytes
o ACK = 206 bytes (no segments received from
sender)
o Segment size is 1360 bytes
o You can see that receiver sent 93 +
1360 + 1360 = 2813 bytes to sender without receiving ACK yet because sender
window size in Packet#4 was 66048 bytes
Packet#9 (Data Transmission S -----> R)
o This is an ACK packet from sender to
receiver before receiver retransmission timer expiry
o SEQ = 206-bytes
o ACK = 1454 + 1360 = 2814 bytes
o Segment size = 0-bytes because SYN/ACK packets
don't carry application data
