summaryrefslogtreecommitdiff
path: root/assignment7.tex
diff options
context:
space:
mode:
Diffstat (limited to 'assignment7.tex')
-rw-r--r--assignment7.tex76
1 files changed, 75 insertions, 1 deletions
diff --git a/assignment7.tex b/assignment7.tex
index fc55fe4..db38b5c 100644
--- a/assignment7.tex
+++ b/assignment7.tex
@@ -155,6 +155,80 @@
\end{enumerate}
\section{All things learned put together}
-%todo
+\begin{enumerate}
+ \item We need an IP address. We will use DHCP for this. We create a DHCP
+ request message (stack: DHCP, UDP, IP, Ethernet). We sent this from port 68
+ to 67, with source IP 0.0.0.0 (we don't have an IP yet) to the broadcast IP
+ address (255.255.255.255, because we don't know the DHCP server's IP
+ address). On the link layer, we send from our MAC to the broadcast address
+ FF:FF:FF:FF:FF:FF.
+ \item If there are switches in between us and the DHCP server, they forward
+ this to everywhere because of the broadcast address.
+ \item The DHCP server (we'll assume this is the router and the gateway as
+ well) receives the frame with the broadcast address, reads the IP datagram
+ with the broadcast address, reads the UDP packet, and finally the DHCP
+ server process reads the DHCP packet and responds to it with a DHCP ACK
+ message. This contains the DHCP server's IP, and the assigned IP. This
+ traverses down the layers and is sent back to the client. The switches have
+ now learned our MAC address and don't broadcast this.
+ \item We can now save our IP, the DHCP server's IP and also the DNS servers
+ suggested. We will now use that DHCP server as the default gateway.
+ \item In the next step we'll need the gateway's MAC address. We do this with
+ ARP. We send an ARP query with as target IP the gateway's IP, source IP our
+ IP, source MAC our MAC, and destination MAC the broadcast address
+ FF:FF:FF:FF:FF:FF. Switches relay this to all nodes as above. The gateway,
+ recognising its IP, will reply with an ARP reply. This reply has as source
+ MAC and IP the addresses of the gateway and as destination MAC and IP the
+ addresses of our host. The switches relay this back to us.
+ \item Suppose we want to access www.google.nl. We then need to lookup the IP
+ address for that host using DNS. We send a DNS query for the A record of
+ www.google.nl to the DNS server advertised by the DHCP server (say
+ 8.8.8.8). We thus send a UDP segment to 8.8.8.8:53 requesting the IP
+ address of www.google.nl. We send this datagram to the default gateway,
+ which forwards it into the internet (through different routers, using
+ different routing protocols, possibly using inter-AS routing, etc.). In the
+ end, we receive a reply containing that IP address.
+
+ In dns.pcap, we see two requests being made: one for A records and one for
+ AAAA records. We thus receive both IPv4 and IPv6 addresses for
+ www.google.nl. The first response lists several IPs. For IPv4, for example,
+ 64.15.117.26 but also 64.15.117.24.
+
+ See \autoref{fig:dns} or dns.pcap.
+ \item We then create an HTTP GET request for www.google.nl. We put this in a
+ TCP package with source IP our IP, destination IP the IP for www.google.nl
+ just received, and destination port 80. This is sent to the gateway router,
+ which manages to forward it to the Google servers (as above to 8.8.8.8).
+ The Google server receives the request, parses and handles it, and crafts
+ an HTTP response which is encapsulated in another TCP packet. This packet
+ has as destination IP and port the source IP and port of the request, and
+ vice versa. It is sent to the destination IP through routers, and
+ eventually gets received by our host. Our host then handles the reply (for
+ example, in a browser, by drawing a graphical representation of the HTML in
+ the response and making additional requests for images, JS, CSS, etc.).
+
+ In reality, we're using HTTPS, so we can't follow the HTTP stream. However,
+ we do see (in https.pcap) that requests are being made to the address we
+ found in the previous step (64.15.117.26). We now use port 443 because of
+ HTTPS. Generally, some packets will hold the initial request and reply. The
+ request takes up one packet, the reply four. After that, the browser reads
+ the HTML and sees it needs some pictures, JavaScript scripts and style
+ sheets. It then sends many more requests.
+
+ See \autoref{fig:https} or https.pcap.
+\end{enumerate}
+
+If our router uses NAT, it will rewrite addresses and ports in a fashion
+described in an earlier exercise.
+
+\begin{figure}[h]
+ \includegraphics[width=\linewidth]{assignment7/dns}
+ \caption{DNS capture\label{fig:dns}}
+\end{figure}
+
+\begin{figure}[h]
+ \includegraphics[width=\linewidth]{assignment7/https}
+ \caption{HTTPS capture\label{fig:https}}
+\end{figure}
\end{document}