*35C3 preroll music*
Herald-Angel: The next talk is by Hannes Mehnert, you can see him here already.
It's called Transmission Control Protocol, also known as TCP and Hannes Mehnert works
at a non-profit organization in Berlin. It's called Center for the cultivation of
technology. And he also works on an open ... no, Mirage OS. If you don't know it,
maybe you can find out what it is. And he researches in several engineering areas
such as: programming languages, network protocols, security protocols and many
many more. So give him a warm applause for his talk.
*Applause*
Hannes Mehnert: Thank you. Yes, today I
want to talk a bit about the Transmission Control Protocol and the Internet Protocol
suite. So, what is it all about? It's a foundation talk here, so if you already
know TCP/IP by heart then maybe only the last five minutes will be of interest for
you, otherwise. So, if you want to connect your laptop or if you want to browse to a
Web site somewhere, you want to read that Web site, it is that, the client on your
laptop or the browser that sends an HTTP request to the web server host. So it sends
an HTTP request which is specified by the HTTP protocol. It's maybe GET /. It's a
common method of getting the main page of a website, but how is this information
actually transmitted to the server? That is the question and the motivation for
this talk. So that is something I want to go deep into the answer for the question.
So let's look a bit at the network topology. So, on the left hand side we
have the laptop which sends to some server a GET request. You can see that by the
dashed arrow and the laptop itself is connected, likely via a wireless network
to the Internet. But what is actually the Internet? Well, the Internet is a
collection of computers and your laptop or anyone's mobile phone is likely connected
to a router, a router is just a normal computer which has some knowledge about
the network and that router is likely connected via fiber or a satellite or any
other link, can also be an ethernet cable to another router or to several routers.
And in this picture you can only see two routers, the router A and router B, but
there may be any number of routers or nearly any number of routers in between
you and the server. So here the router B is connected via Ethernet, which is just a
physical cable to the server and Ethernet is a protocol which is talked over the
cable. So I won't to go into the physical network connectivity like fibers and
satellite and cables and copper cables, in this talk at all but I will start with the
layer which is on top of the physical medium. So the first one is the data link
layer. And, well, what is the data link layer? What's task is it? It has a scope
of a network and it only spans over the local network to which a host is
connected. So in this picture, only the laptop and the router A share the same
data link layer as well as the router B and the router A, they share the same data
link layer. It's also the case that router B and the server share the same data link
layer. What is the task of the data link layer? Well it's pretty easy, it just
moves Internet layer packets between two different hosts that sit on the same link.
So, the data link layers really it's only purpose is to provide an abstraction over
the physical thing and how many bytes you can transport on the physical media over
the link. So the next layer is already the Internet layer. The internet layer which
task is to transport packets across multiple networks. So as you have seen in
the diagram there are router A and router B, they are both connected to several data
link layers and they use the Internet layer in order to transport packets
across. The Internet layer solves already the issue of addressing by providing for
every host an IP address. IP address is actually the Internet Protocol address and
the Internet layer provides another task or solves another task which is routing so
it forwards packets to the next router which is hope fully closer to the final
destination. That is the task. The Internet layer also has support for
fragmentation. So if your higher layer sends something which is way too big for
the data link layer, then the Internet layer can fragment that and the other side
has to reassemble it. What is on top of the Internet layer is the transport layer.
So the transport layer establishes host to host connectivity. It does multiplexing
usually using source and destination ports and there are two widely used transport
layer protocols, which I will go into more detail in this talk, which is the user
datagram protocol and the transmission control protocol, that's UDP and TCP and
they have different properties. So UDP is unreliable and it is not ordered and it is
only an abstraction over datagrams and it has on the advantage side, a very low
overhead. Whereas TCP is a reliable and ordered byte stream, so you have a
reliable byte stream which you can work on. The downside of TCP is that it's
connection establishment and teardown is slightly more complex. In UDP, you just
don't have to establish a connection and teardown and connect. But in TCP you have
to synchronize the two hosts. Then on top of the transport layer we have the
application layer and the application layer just exchanges application data over
the transport layer. So some examples for application layers are HTTP or TLS or DNS.
So in the first example we saw there was HTTP and HTTP was used to send the GET
request. So that is all application layer, which I won't focus on in this talk at
all. For the lower layers the application layers, just payload so it's just some
arbitrary data. So if we look again at that picture and we draw the different
layers which are supported or which are used by the different devices, we end up
with a diagram similar to that. So here on the left we have the laptop again which
has all four layers and then we have the routers in the middle which are only using
the data link and the Internet layer and then on the right hand side we have the
server which also has all four layers. So the transport layer is really host to
host, so the TCP we saw earlier, the TCP is establishing a connection from the
laptop to the server and on top of TCP. So on top of the transport layer there is the
process to process communication so the application layer which is the web browser
talking to the web server. So only on the highest layer here, we have the GET
request. And the routers in the middle they don't have to inspect or they don't
have to use information of the transport or application layer from the laptop or
the server. So the routers just for using the Internet layer they forward packets to
the next router or to the final destination. So the laptop first sends the
whole TCP segment or a TCP packet to the router and the router A decides, oh yeah
we'll forward it to router B because router B is more closer to the final
destination than myself and the router B says, oh yeah well I actually know and I'm
connected via ethernet to the final destination so I will just forward it to
the server. That's how the data flow of such a connection would look like. How
does a packet actually look like? So we have seen that at the application layer we
have the application data, which is here in blue and that one is just the GET
request. Then the transport layer actually prefixes the application data with a
header which is a common header that encodes some data, we will look into the
TCP header in more detail soon, then the Internet layer also adds a header, a
prefix: the IP header, which is just put in front of the TCP header. And then the
data link layer, well that is the lowest layer we actually care about and that one
will likely prepend a header and append a footer in order to synchronize or to make
sure that the physical wire only has only sees a single packet at a time. So as you
can see from the layering from those two pictures on the one side you have the
bottom two up layer and every layer if you go down from the application to the
transport, to the Internet, to data link, they basically add some header information
and the Internet layer for example that takes the TCP header, so the transport
layer and the application layer as payload, so it doesn't care that it is
TCP, it could as well be UDP in this case. So what is actually in the. So I will not
go into the data link layer details at all, but here is the header of an IP
version 4 frame or packet and that one is at least 20 bytes, it contains various
fields. The first one is a four bit version, which usually is version 4 in our
current world. Then it has a 4 bits header length, which is a header length invert,
so in multiples of 32 bits. Then it has some not really used stuff I won't deal
with in this talk. It has the total length field with just 16 bits and it describes
how long the entire IP frame is. Then it has an identification, which is also a 16
bit unique number and the 16 bits for fragmentation flags and offset. And that
is crucial. So, if the IP header decides: oh yeah well the package, the application
data you sent me is way too big for this data link, I need to fragment it, then it
will just reuse the very same identification number and then use here
the 16 bits in the fragmentation flags and offset in order to portion that
application data into multiple IP fragments. Then it has a field which is 8
bit, so 1 entire byte, it's the time to live and it's actually not a timestamp but
it's only a count. So how many routers should this package live. How long should
this package live and every router decreases that time to live by 1. Then it
has a 1 byte protocol field which specifies what is the type of the payload
carried by this IP version 4 packet, then it has a 16 bit header checksum which is
the CRC checksum to avoid that some bits got flipped on the transport. Then we can
see the source IP address and the destination IP address which is, yeah I
mean, the source IP address is the IP address of my laptop and the destination
IP address, is the IP address of the server. And then after those 20 bytes you
have either IP options, if the header length was more than 20 bytes or you have
directly the payload. Now for the protocol field here there are various types and
various types are predefined. 1 is ICMP which is the internet control message
protocol, I will talk a bit about that which is the product field, there the
number set to 1, then for TCP it's set to 6 and for UDP it's 17. We have other
protocols which can be carried over an IP frame or an IP packet but I won't go into
the details here. As you can see there are at least 255 numbers here in the product
field. So because it's 8 bit long, you can store up to 256 different numbers in
there. So ICMP is a protocol I haven't talked about at all but it is the internet
control message protocol. So it sits on top of IP and its purpose is on the one
side, to deliver error messages such as destination host unreachable or time to
live exceeded and on the other side it can also carry operational information like
diagnostics. There's one program which you may know which is called ping. The purpose
of ping is to send an ICMP echo request to a remote host and the remote host is then
supposed to send the very same packet with only 1 single bit flipped and send that back
to you and that is an ICMP echo reply. And if you can successfully ping another host
you can verify that the other host has at least ip connectivity up and online. OK,
Let's look into the next layer which is the transport layer. And at first we will
look into a UDP header. A UDP header has only eight bytes. it contains. It consists
of a source port, the destination port. Then the length of the entire UDP frame
and the checksum the checksum is again a 16 bit field computed over the entire
payload and the header plus some IP pseudo header. So this actually carries the
information of the source and destination ip address inside of itself. UDP as I
mentioned is unreliable, unordered and its advantage is that the low overhead data
grams as you can see it adds 8 bytes to the to the payload whereas IP already added 20
bytes to the payload. Here's a simple Unix program which is a UDP client. This
program does not compile because I left out some bits but in order to see what how
do you actually use this whole IP stack. So the IP stack the TCP IP stack is
usually embedded in the kernel and as a programmer as an API programmer you have the
API provided by the Unix sockets API. And that one usually contains of the very same
five or seven functions which is the first one is a socket socket opens or creates a
file descriptor and you specifie the address family and the socket type. So
this is the adress family Internet and the socket is a datagram socket. It's called
DGRAM in Unix. Once that is created then you for a UDP client and you just say Oh I
will use the function "send to" which takes a socket file descriptor. So just
the file descriptor and then some data and will just send it to the other side since
it's unreliable it's just fire and forget. Then afterwards we close the socket file
descriptor because we are nice here and we try to be nice the other side. So if you
don't have a UDP client but if you want to implement a UDP server or a UDP listener
what do you do is you again create a socket then you have the function which is
called bind. Bind binds it to a combined into a specific IP address on your server
or on your network stack then you say receive from recieve from takes the socket
file descriptor and a buffer and some maximum size and an offset. And yeah you
just receive from will only return once you actually receive the UDP frame on that
IP address and port and then you then we print out that we received some packets
and we close the socket file descriptor. So that's UDP. UDP is used for a variety
of protocols and that's crucial to have it TCP on the other hand is a bit bigger. So
instead of eight bytes header TCP adds another 20 bytes of header what does the
TCP header contain? Well similar to UDP it contains a source port and Destination Port
both again 16 bits then it contains two sequence numbers one is the sequence
number itself it's a 32 bit number and one is the acknowledgement number which is the
last sequence number we have seen from the other side then TCP contains a data offset
date offset is similar to the header length field so TCP a TCP segment may also
contain some options so the header may contain options before a payload. That's
why we need a data set field in order to be able to find out where this extra
payload start then TCP has certain flags and some of these flags a some of these
flags are just a single bit of values and some of them I mentioned down here of
which I will go into more detail later which is acknowledgement or ACK
synchronize or SYN and finished or FIN there is also reset and some urgent stuff
I will not go into detail of that then we have a six sixteen bit field which is the
window size which is the size of the receive buffer then we have again sixteen
bit field checksum and then we have some space for the urgent stuff I will not go
into detail. A TCP client if you program it in a Unix way. You have a very similar
API as we have seen in the UDP. So we first call. We first create a file
descriptor using the socket system call which we give again the adress family INET
and the SOCK_STREAM which is the since we are stream oriented. It's it's the name of
the TCP. It's the name for TCP socket. Then as a TCP client we connect using the
socket file descriptor to a remote host. And then once we are connected so connect
will only return once a TCP session has been established. Then we say here receive. So
we receive on the socket file descriptor. The specific buffer buffer then we print
it and then we close the socket file descriptor again. The TCP listener is very
similar. So well first we create a socket. Then we bind it and bind specifies the IP
address and also the port number. Then we use a function called listen on the socket
file descriptor and then we enter a loop. And so now we wait for client connections
which appear at some point. And for every client connection we well we call accept
and accept returns whenever there was a client which successfully established a
TCP connection. What accept returns is a new file descriptor so another file
descriptor not the same as a socket file descriptor. So the socket file descriptor
we call again except on it at a later point. Usually you then handle any work on
the client connection on this new_fd. You handle that in a separate process or set a
separate thread or a separate task in order to enable the server to accept
another connection while you are handling the the one client connection. Then we
just do some printf output and we send hello world to the client to the client
connection so to this new file descriptor then we close it and we start from the
while(1) and we accept a new client socket. So that is TCP listener as we have
seen it as you will see it in an in any network program. Now TCP as I mentioned it
has to do some work in order to establish a section a session and to tear down the
main work which needs to be done is to synchronize the initial sequence numbers
because we have seen in the header that we have this sequence number and somehow we
need to transform that information to the other side. So here's the TCP state machine
which is which has initially been part of the RFC, which is the specification
for TCP and also duplicated in books like Stevens design and implementation of the
of TCP IP and TCP IP illustrated and so on. So you can see it is it has here one
specific state which is listen and listen is as we've seen in the server
implementation if you call listen then you are in the listen stand in the listen
state and you always start well you always end up in the in the closed state after
you've called Close. Basically I will go into more detail of connection
establishment and teardown right now. So on the connection establishment we have
seen on the client side we start with the socket in the closed state. Then we say
the Unix call connect on that socket and that connect. Does send an initial TCP
segment to the server side which has the synchronized flag set to true or set to
one and the sequence number is some artificial number some random 32 bits
integer number. So just call it "a" here. The State of the file descriptor goes from
closed to SYN_SENT and SYN_SENT yeah well we just have sent out the the synchronize
segment so aTCP segment which doesn't carry any data but only the TCP header on the
server side. We had prepared previously. We started in a closed state then we
called Listen. Then we end up in a listen state. Now in the listen state we call
accept and accept blocks until the SYN is received and once the SYN is received, a
new socket is a new file descriptor spawned and that one ends up in the
SYN_RECIEVED state. The server sends out the TCP segment again without any data but
the SYN and acknowledgement flags are set and the sequence number is sent to some b
and the acknowledgement number is set to a+1. So the acknowledgement number
acknowledges that the SYN was received with the sequence number a +1. Upon
the client receiving that SYN and ACK, it is in the established state and it will send out
an acknowledgement segment so that the other side the server knows. Oh yeah. My
segment has been received and that one is sent with the sequence number of a+1
because a was already used here and the SYN flag consumes one one byte or 1 in the
sequence number range and the acknowledgement number is also set to
b + 1. So that is the sequence number from here plus 1. Once that is received
the server ends up in the established state. Sequence numbers. Yeah well it's a
good idea of both. Pick a random initial sequence number for each connection
otherwise we can get into some nasty attacks. The acknowledgement number is the
next sequence number from the other hosts and the sequence numbers always increased
for each byte of data. And for the SYN and FIN flags which only a single bits each
sequence number must be not acknowledged and each sent packet is retransmited unless
it is acknowledged after a certain timeout and after certain retransmit time after trying
it several times at some point the TCP stack gives up the trardown since I am a
bit short on time I will skip that. TCP provides us with the flow control. What
does that mean. Well every network stack has received so the Kernel has a receive
buffer for each TCP connection and that buffer is size limited to avoid Kernel
memory exhaustion which means that whenever the application so the web server
or the web browser is reading data some buffer spaces are reclaimed and when TCP
segments are arriving. Some of that buffer is consumed. It's a sliding window and we
have seen in the TCP header is is a windows size so there is a 16 bit field
called window size which specifies how many more bytes my TCP Stack has for
receiving data from the other side to avoid deadlocks there is also a timer in a
timer called the persist timer which is started when the window is when the window
size is zero and that then at a time out try retransmits TCP segment in order to
get information about the new window size from the other side. Congestion control
I will also skip a bit but the main idea is to control the rate of data entering the
network because if you're using multiple routers at some point you may saturate
some of the network links and that is avoided in TCP by doing by applying
congestion control which measures for example the time between segments sent and
acknowledgement received also has to do with a slow start and how your window size
your window buffer grows. Acknowledgments. Well there are some
strategys the basic one is every segment is acknowledged individually there's
delayed ACK where you collect multiple segments to acknowledge them at a certain
time then you have also selective acknowledgements where you can acknowledge
discontinuous segments which helps for lowering the amount of retransmissions. TCP
also carries some maximum segment size to avoid fragmentation. Actually on the IP
layer because to this partially open there's some struggle because you have
simultaneous open so what if both parties want to open a connection at the very same
time. Then you have a flag which is called the reset in order to terminate a
connection. There are some extensions like Window scaling and fast open to improve
the throughput and also to lower the delay. There are some attacks like denial
of service. So if your server implementation accepts something and
allocates a lot of memory for a client which doesn't do a lot but just sending a
SYN frame that is bad and leads to denial of service connection hijacking if you can
predict the sequence numbers then you can hijack and emit data into an established
connection. There have been some blind in- window attacks. What does that mean that
even without knowing the sequence number you can do something on an established TCP
connection such as, yeah sending a reset or sending a FIN frame and tearing that
connection down. The specification for TCP is written in English prose in a
collection of RFC and there are some widely deployed implementations. During
some research work in Cambridge over the last years me and various colleagues
implemented a formal model developed in the interactive theorem prover HOL4, which
has a precise specification with implementation looseness and we really use
that as an input so the sockets API and interface for getting the TCP control
block, which is the host internal state of the TCP and then the wire interface which
is data received and sent on that. And we use that formal model to validate itself,
so we used actual implementations to do that, we use it to draw some diagrams
where you can see the rules which fires on the left hand side, when something
happened like there was a CONNECT called and then the logical rule connect_1 was
used in the label transition system. Then we see here as well some TCP segments
which are going out and then what are the contributions of the network semantics, we
checked the model, we validated the model by recording traces and executing them. We
published a paper called Engineering with Logic: Rigorous Test-Oracle Specification
and Validation for TCP/IP and the unix Sockets API. The specification itself is
typeset in 384 pages, that's all the transitions you basically need. So roughly
10000 lines of HOL4 code and a lot of comments, where we embedded a lot of
LaTex code. And the Unix TCP/IP stack has usually around 15000 lines of code, the
TCP state machine we saw earlier, is here in this paragraph, in this diagram and we
try to draw a more correct TCP state machine which led us to this picture,
which is a bit more complicated. We have this state NONEXIST up here and we have
much more transitions due to timers and so on. So the state machine used in common
literature is actually not complete or not precise and we have a revision for that.
The conclusion is you have all TCP/IP widely deployed. I hope I managed to give
you some insight how TCP/IP actually works. It's a layered architecture which
is agnostic of underlying layers and in the network semantics working, we had an
executable specification. That's all I have to say and I welcome you to ask any
questions, either now or offline. *Applause*
Herald-Angel: Thank you. So, if you have any questions just go to the microphones.
We have two here and two on the right side. And do we have some question from
the Internet? No questions? No questions? Yeah, 1 question, come on, don't be shy.
Microphone 1: Right. Hi thanks, that was a very interesting talk. So your model, does
it allow synthesizing a implementation from the specification, or is it used
mostly for validating? HM: It's at the moment used for validation
because we have the specification looseness. So we have an implementation
looseness. So at some point in implementation you have to choose whether you take one
transition or the other one. So if you go into a failure state or if you go into a
success or if you transmit some piece of data and go into a success state. So we
don't have synthesized any implementation but there is ongoing work to use it as the
implementation, as a base for an implementation.
Mic: Okay. And do you think that such an implementation can be made, can it be made
efficient as well, once synthesized? HM: Yes.
Mic 1: Okay, thanks. *Applause*
Herald-Angel: Yeah, your question please.
Microphone 2: Yeah, thank you. How independent is TCP from IP? I mean, can
you integrate TCP over different protocols like Bluetooth or something like that?
HM: *Sighs* Since TCP requires for error messages, a
bit of ICMP, I haven't seen any TCP implementation on top of any other medium
than IP. Mic 2: Okay.
HM: So, I don't know, but I can think of it. Could work.
Herald-Angel: Okay, your question please. Microphone 3: Thank you. Hello. So you
used HOL4 for the specification part. Did you actually need the higher order logic
part of HOL, or would it be possible to just use predicate logics?
HM: *Sighs* I, I will have to reread. I think we need
actually some higher order logic for it, for the whole state and the transitions.
Mic 3: It would be interesting to meet and...
HM: Yes, well, the paper has been published at the journal of ACM and
luckily scihub.is is available and you can download it for free from there.
*Laughs* Mic 3: Okay, thanks.
Herald-Angel: Any more questions? No? Then, thank you Hannes. A warm applause
for Hannes please. *Applause*
*postroll music*
subtitles created by c3subtitles.de in the year 2018. Join, and help us!