Slides supporting the "Computer Networking: Principles, Protocols and Practice" ebook. The slides can be freely reused to teach an undergraduate computer networking class using the open-source ebook.
Today's web pages
Source: https://httparchive.org/reports/page-weight.org
• Can you order the different elements of web
pages in terms of importance ( smallest average
volume first) ?
• CSS
• Font
• HTML
• Images
• Javascript
• Video
HTTP/2
• Why changing HTTP ?
• Reduce page load time
• Minimize data exchanged
• Reduce network load
• Fewer transport connections
• Reduce risks of attacks from ASCII
parsing
HTTP/2.0
• Key changes from HTTP/1.x
• Binary protocol instead of ASCII
• Support multiple datastreams over the
underlying transport connection
Basics of HTTP/2
• Main modifications compared to HTTP/1.1
• Binary framing protocol
• Will be used over TLS anyway
• One connection for several objects
• Several objects can be multiplexed
• Server push
• Data compression for requests and
responses
A single TCP
connection
• One TCP connection for all objects for a
given client-server pair
• Minimize in-network and server
resources
• Beware of head-of-line blocking
• Can we do better than HTTP/1.1 ?
Issues with HTTP/1.1
• Can use a single connection per server
but
• Client decides the order of the requests
• Server sends objects in order
requested by client
• A large object (e.g. image) may block
smaller but more important objects
(e.g. css/javascript)
HTTP/2 streams
• Benefits
• Client can send multiple requests in
parallel
• Server can decide the optimal delivery
order
• Server can interleave multiple objects
and prioritise them
Transport layer
• Objectives
• Improve service provided to
applications
• Multiplexing
Physical Physical
Datalink Datalink
Network
Network
Physical
Datalink
Network
Segments
Transport Transport
UDP protocol
Source Port Destination port
UDP length UDP Checksum
8 bytes
Payload
32 bits
Constraint
Each UDP segment must
fit inside a single IP packet
Used to identify the
application that will receive
this segment on destination
host
Checksum computed over the entire
UDP segment and part of the IP
header to detect transmission errors.
0 means that the sender did not
compute a checksum.
Used to identify the
application that sent this
segment on sending host
UDP : limitations
• Maximum length of UDP SDUs depends on
maximum size of IP packets
• Unreliable connectionless service
• SDUs can get lost but transmission errors
will be detected
• UDP does not preserve ordering
• UDP does not detect nor prevent
duplication
Usage of UDP
• Request-response applications
• DNS, RPC, NFS, ..
• Applications with short delay
• Games
• Multimedia transfer
• Voice over IP
• Video over IP
Attacks against DNS
• DNS is key, if an attacker can change the
responses returned by resolvers, this
could have a major impact
• Users rely on their resolver to obtain
name-to-address mappings
Packet spoofing
• On the Internet, every device has one IP
address
• All the packets sent by this device use its
IP address as their source
• Is it possible for Trudy to send a packet
using Alice’s IP address ?
Countering spoofing
attacks
Identification Flags
32 bits
Number of additional
Number of authority
Number of answers
Questions
(variable number of resource records)
Number of questions
Answers
(variable number of resource records)
Authority
(variable number of resource records)
Additional information
(variable number of resource records)
Source port Dest. port
UDP Length Checksum
UDP
header
DNS
message
Alice should use random
source port in her queries and
verify the server response
Alice should use random
identifiers and verify the
server response
Total: 32 bits of randomness
https://tools.ietf.org/html/rfc6056
Other approaches
• DNSSEC
• DNS extensions that allows servers to sign their
reponse using public keys
• DNS responses sent in clear over UDP
• Alice can verify the cryptographic signature
• DNS over TLS or DNS over HTTPS
• Request/Response sent over TLS session(encrypted
and authenticated)
• cannot be hijacked by Trudy
Denial of Service
attacks
• How can Trudy saturate Alice’s link to
make it impossible for her to use Internet
?
• Naive approach
T
A
Lots of traffic
sent by
Trudy
Can Trudy hide the
attack and amplify it ?
https://www.cloudflare.com/en-gb/learning/ddos/famous-ddos-attacks/
What was the largest
known DDoS attack ?
Amplification attack
• Protocol designers, beware !
B
T
A
S=B,D=A www.bob.net=...
Trudy will try to send a
short request that triggers
a large response from Bob
TCP
• Service provided
• Connection-oriented
• Reliable
• No losses, no errors, no duplications
• Bytestream
TCP port numbers
Server : S
Client : C
Source Port : 1234
Destination Port: 5678
Request
Response
Source Port : 5678
Destination Port: 1234
Established TCP connections on client
Local IP Remote IP Local Port Remote Port
C S 1234 5678
Established TCP connections on server
Local IP Remote IP Local Port Remote Port
S C 5678 1234
Multiple connections
Client: A
Client : B
Server : S
TCP connections on server
IP local IP remote Port local Port remote
S A 80 1234
S A 80 1235
S B 80 1235
TCP connections on host A
IP local IP remote Port local Port remote
A S 1234 80
A S 1235 80
TCP connections on host B
IP local IP remote Port local Port remote
B S 1235 80
TCP segment
Source port Destination port
Payload
32 bits
Checksum Urgent pointer
THL Reserved Flags
20 bytes
Sequence number
Optional header extension
Window
Flags :
used to indicate the function of a segment
SYN : used during establishment
FIN : used during connection release
RST : used in case of problems
ACK : if true, means that the Acknowledgement
number inside the segment is valid
Computed over the entire
segment and part of the IP
header
Acknowledgement number
Segment header length
Reliable data transfer
DATA.req ("abcd")
DATA.ind("abcd")
(seq=123,"abcd")
DATA.req ("jkl")
(seq=132,"jkl")
(seq=127,"efg")
DATA.req ("efg")
(ack=127)
(ack=135)
DATA.ind("efghijkl")
DATA.req ("hi")
(seq=130,"hi")
Which ack is returned ?
Which ack is returned ?
Which ack
is returned ?
Initial sequence
number
• First approach
• Each TCP host has a clock that
increments the iss every 4 microsecond
• Current approach
• Each TCP host picks a random number
as its initial sequence number
The problem with
trusted addresses
B
T
A
ACK(seq=x+1, ack=y+1)
SYN+ACK(ack=x+1,seq=y)
SYN(seq=x)
Connection comes
from Alice’s IP
address don’t need
to ask username
and password
DATA(seq=x+1, ack=y+1)
Can Trudy hijack this
connection ?
TCP and spoofing
• Can Trudy create a fake TCP connection
by spoofing Alice's IP when she is away
?
• Trudy can send spoofed IP packets to
Bob using Alice’s address
• But Trudy cannot receive the packets
sent by Bob to Alice
TCP and spoofing
• Trudy's view of the transfer
SYN+ACK(Dst=A,ack=x+1,seq=y)
SYN(Src=A,seq=x)
ACK(seq=x+1, ack=y+1)
Data(Src=A,seq=x+1)
Trudy Alice
Ignored if Alice is offline
Can Trudy predict y ?
Bob
Countering DoS attacks
• Principle of the solution
• Server should not create any state
before being sure that the client can
receive the segments that it sends
SYN(Src=C,seq=x)
SYN+ACK(Dest=C,ack=x+1,seq=y)
ACK(Src=A,seq=x,
ack=y+1)
CONNECT.req
Server does not
store anything
Server checks
that third ACK is
valid
and creates state
TCP options
Source port Destination port
Payload
32 bits
Checksum Urgent pointer
THL Reserved Flags
20 bytes
Sequence number
Optional header extension
Window
Acknowledgement number
Space in the
header with new
fields which can
be exchanged
over a
connection
Each TCP Option encoded as:
• Type
• Length
• Value
Negotiating the utilization
of TCP Options
ACK(seq=x+1, ack=y+1)
CONNECT.req
CONNECT.ind
SYN+ACK(ack=x+1,seq=y) Option K
CONNECT.resp
CONNECT.conf
Initial sequence number (x)
Option K proposed
Initial sequence number (y)
Option K accepted
SYN(seq=x),Option K
Connection established
Option accepted
Connection established
The sequence numbers of all
segments A->B will start at x+1
The sequence numbers of all
segments B->A will start at y+1
The MSS Option
ACK(seq=x+1, ack=y+1)
CONNECT.req
CONNECT.ind
SYN+ACK(ack=x+1,seq=y) MSS=1000
CONNECT.resp
CONNECT.conf
Initial sequence number (x)
Will not accept segments longer
than 1200 bytes
Initial sequence number (y)
Will never send segments longer than
1200 bytes
Will not accept segments longer
than 1000 bytes
SYN(seq=x),MSS=1200
Connection established
Option accepted
Connection established
Will never send segments longer than
1000 bytes
The sequence numbers of all
segments A->B will start at x+1
The sequence numbers of all
segments B->A will start at y+1
Agenda
• Internet applications
• Web
• UDP
• TCP
• Connection establishment
• Reliable data transfer (more details)
• Connection release
RTT measurements
• Solution (Karn/Partridge)
• Do not measure rtt of retransmitted segments
(seq=123,"abcd")
(seq=120,"xyz")
(ack=123)
(ack=128)
measured rtt
Timer
which is the good rtt ?
(seq=123,"abcd")
Delayed acks
• Sending an ack per segment is costly
• Tradeoff
• In sequence data segment
• no ack waiting, delay by up to 50 msec
• one ack waiting, send immediately
• Out-of-sequence data segment
• send ack immediately
What is the benefit of delayed
acks ?
When to send data ?
• When should a segment be sent ?
• Option 1
• After each write system call
• Lowest delay for application
• Option 2
• When there is a full segment of data
• Lowest overhead for network
Nagle algorithm
• A new data segment can be sent if either
• This is a full segment (MSS bytes)
• There are no unacknowledged bytes
Window scaling
• Window maintained as a 32 bits integer
by TCP implementations
• But sent as a scaled 16 bits in
segments
• Scaling factor announced in WScale
option in SYN/SYN+ACK segments
Agenda
• Internet applications
• Web
• UDP
• TCP
• Connection establishment
• Reliable data transfer
• Connection release (more details)
TCP connection
release
FIN Wait1
SYN RCVD
CLOSE Wait
Established
FIN Wait2
LAST-ACK
TIME Wait
Closing
Closed
?FIN/!ACK
!FIN
?ACK
Timeout[2MSL]
?FIN/!ACK
?ACK
!FIN
?ACK
?FIN/!ACK
!FIN
The computation of the UDP checksum is defined in :
R. Braden, D. Borman, C. Partridge, Computing the Internet Checksum, RFC1071, Septembre 1988
UDP is mainly used for applications where either short messages are exchanged or losses or not a severe problem (either because they can be supported by the application or because they are used in LAN environment where there are almost no losses)
Domain Name System, Network File System (NFS), Remote Procedure Call (RPC), jeux
Multimedia (conversational) applications such as VoIP or VideooverIP often use UDP. In this case, UDP is often combined with RTP
H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson.RTP: A Transport Protocol for Real-Time Applications. RFC1889, Jan 1996
The biggest DDoS attack to date took place in September of 2017. The attack targeted Google services and reached a size of 2.54 Tbps. Google Cloud disclosed the attack in October 2020.
The attackers sent spoofed packets to 180,000 web servers, which in turn sent responses to Google. The attack was not an isolated incident: the attackers had directed multiple DDoS attacks at Google's infrastructure over the previous six months.
Urgent pointer is rarely used and will not be described.
The THL is indicated in blocs of 32 bits. The TCP header may contain options, these will be discussed later.
MSL in IP networks : 120 seconds
MSL in IP networks : 120 seconds
Don’t forget that TCP’s acknowledgements are cumulative.
See e.g.
RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.
MSL in IP networks : 120 seconds
Most TCP implementations today have fixes for those problems. We will discuss them later.
Most TCP implementations today have fixes for those problems. We will discuss them later.
This utilization of a hash function to compute the value of the initial sequence number is usually called a SYN cookie.
In practice, the computation of the SYN cookie is slightly more complex than a simple hash function because the server must also remember inside the cookie the following information :
- the MSS value advertised by the client
- the optional utilization of TCP options such as RFC1323 large windows or timestamps or SACK by the sender
The original discussions that lead to the development of the SYN cookie solution may be found in :
http://cr.yp.to/syncookies/archive
Urgent pointer is rarely used and will not be described.
The THL is indicated in blocs of 32 bits. The TCP header may contain options, these will be discussed later.
MSL in IP networks : 120 seconds
MSL in IP networks : 120 seconds
The computation of TCP’s retransmission timer is described in
RFC2988 Computing TCP's Retransmission Timer. V. Paxson, M. Allman. November 2000.
Usual values for alpha and beta are 1/8 and 1/4.
See
P. Karn, C. Partridge, Improving round-trip time estimates in reliable transport protocols, Proc. ACM SIGCOMM87, August 1987
Les timestamps TCP ont étés introduits dans :
RFC1323 TCP Extensions for High Performance. V. Jacobson, R. Braden, D. Borman. May 1992.
L'utilisation de ces timestamps est négociée lors de l'établissement de la connexion TCP. La plupart des implémentations TCP actuelles supportent ces extensions.
See e.g.
RFC2001 TCP Slow Start, Congestion Avoidance, Fast Retransmit, and Fast Recovery Algorithms. W. Stevens. January 1997.
RFC2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996.
RFC2018 TCP Selective Acknowledgement Options. M. Mathis, J. Mahdavi, S. Floyd, A. Romanow. October 1996.
Urgent pointer is rarely used and will not be described.
The THL is indicated in blocs of 32 bits. The TCP header may contain options, these will be discussed later.
Some heavily loaded web servers, use abrupt release to close their connection to avoid maintaining state for 2*MSL seconds.