diff options
Diffstat (limited to 'assignment7.tex')
| -rw-r--r-- | assignment7.tex | 92 |
1 files changed, 85 insertions, 7 deletions
diff --git a/assignment7.tex b/assignment7.tex index 5be9ff5..db38b5c 100644 --- a/assignment7.tex +++ b/assignment7.tex @@ -115,7 +115,7 @@ \begin{table}[h] \centering - \begin{tabular}{l | l | l | l} + \begin{tabular}{l l l l} Src. IP & Src. MAC & Dest. IP & Dest. MAC \\\hline 192.168.3.100 & 00.00.00.00.00.E0 & 192.168.3.2 & 88.88.88.88.88.00\\ 192.168.2.2 & 88.88.88.88.88.00 & 192.168.2.1 & 88.88.88.00.88.00\\ @@ -131,7 +131,7 @@ \begin{table}[h] \centering - \begin{tabular}{l | l | l | l | l} + \begin{tabular}{l l l l l} Src. IP & Src. MAC & Dest. IP & Dest. MAC & Protocol\\\hline 192.168.3.100 & 00.00.00.00.00.E0 & 192.168.3.2 & FF.FF.FF.FF.FF.FF & ARP\\ 192.168.3.2 & 88.88.88.88.88.00 & 192.168.3.100 & 00.00.00.00.00.E0 & ARP\\ @@ -144,13 +144,91 @@ \section{Self-learning} \begin{enumerate}[label=(\roman*)] - \item %todo - \item %todo - \item %todo - \item %todo + \item The switch learns the MAC address of host B. Since it doesn't know + where host E is, it forwards the frame to all links (except the one of B). + \item The switch learns the MAC address of host E. Since it knows where host + B is, it forwards the frame only to that host. + \item The switch learns the MAC address of host A. Since it knows where host + B is, it forwards the frame only to that host. + \item The switch knows where host A is, it forwards the frame only to that + host. \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} |