1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
|
\documentclass[a4paper,9pt]{article}
\author{Camil Staps\\\small{s4498062}}
\title{Networking\\\large{Assignment 7}}
\date{May 22, 2016}
\usepackage{polyglossia}
\setmainlanguage{english}
\usepackage{geometry}
\usepackage[hidelinks]{hyperref}
\usepackage{amsmath}
\usepackage{enumitem}
\usepackage{subcaption}
\usepackage{verbatimbox}
\begin{document}
\maketitle
\section{Cyclic Redundancy Checks}
\begin{enumerate}[label=\alph*)]
\item It computes the remainder of $(D\cdot2^r\oplus R) \div G$, and checks
that it equals $0$.
\item See \autoref{fig:longdiv:b}. The answer is \texttt{111}.
\item See \autoref{fig:longdiv:c}. The answer is \texttt{010}.
\item See \autoref{fig:longdiv:d}. The answer is \texttt{111}.
\end{enumerate}
\begin{figure}[h]
\small
\begin{subfigure}[b]{.32\linewidth}
\centering
\begin{verbbox}
1001010101 000
1001
0000010101 000
1001
0000000111 000
100 1
0000000011 100
10 01
0000000001 110
1 001
0000000000 111
\end{verbbox}
\theverbbox%
\caption{\label{fig:longdiv:b}}
\end{subfigure}
\begin{subfigure}[b]{.32\linewidth}
\centering
\begin{verbbox}
0101101010 000
1001
0001001010 000
1001
0000000010 000
10 01
0000000000 010
\end{verbbox}
\theverbbox%
\caption{\label{fig:longdiv:c}}
\end{subfigure}
\begin{subfigure}[b]{.32\linewidth}
\centering
\begin{verbbox}
1010100000 000
1001
0011100000 000
1001
0001110000 000
1001
0000111000 000
1001
0000011100 000
1001
0000001110 000
1001
0000000111 000
100 1
0000000011 100
10 01
0000000001 110
1 001
0000000000 111
\end{verbbox}
\theverbbox%
\caption{\label{fig:longdiv:d}}
\end{subfigure}
\caption{Computing CRC using long division\label{fig:longdiv}}
\end{figure}
\section{Address Resolution Protocol}
\begin{enumerate}
\item We call the left router R and the right router S. Let $R_i$ be the
interface of router $R$ for subnet $i$. Then:
A --- 192.168.1.100; B --- 192.168.1.200;\\
C --- 192.168.2.100; D --- 192.168.2.200;\\
E --- 192.168.3.100; F --- 192.168.3.200;\\
R$_1$ --- 192.168.1.1; R$_2$ --- 192.168.2.1;\\
S$_2$ --- 192.168.2.2; S$_3$ --- 192.168.3.2;\\
\item
A --- 00.00.00.00.00.A0; B --- 00.00.00.00.00.B0;\\
C --- 00.00.00.00.00.C0; D --- 00.00.00.00.00.D0;\\
E --- 00.00.00.00.00.E0; F --- 00.00.00.00.00.F0;\\
R$_1$ --- 88.88.88.00.00.00; R$_2$ --- 88.88.88.00.88.00;\\
S$_2$ --- 88.88.88.88.00.00; S$_3$ --- 88.88.88.88.88.00.
\item Host E looks up the MAC address of the first hop router (S$_3$), and
sends the datagram there. Router S receives the datagram, figures out that
the next hop is router R, looks up the MAC address of R$_2$ and sends the
datagram there. Router R then forwards the datagram in a frame to host B on
interface R$_1$. Concretely, the following frames are sent:
\begin{table}[h]
\centering
\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\\
192.168.1.1 & 88.88.88.00.88.00 & 192.168.1.200 & 00.00.00.00.00.B0\\
\end{tabular}
\end{table}
\item The same happens, but before E can send the frame to S$_3$, it has to
get to know its address. It sends an ARP request to the broadcast address
with the request for 192.168.3.2's (that is, S$_3$'s) MAC address. The
router replies with an ARP packet. After this, E has all the addresses it
needs (and all other nodes as well), so the same as above happens.
\begin{table}[h]
\centering
\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\\
192.168.3.100 & 00.00.00.00.00.E0 & 192.168.3.2 & 88.88.88.88.88.00 & IP\\
192.168.2.2 & 88.88.88.88.88.00 & 192.168.2.1 & 88.88.88.00.88.00 & IP\\
192.168.1.1 & 88.88.88.00.88.00 & 192.168.1.200 & 00.00.00.00.00.B0 & IP\\
\end{tabular}
\end{table}
\end{enumerate}
\section{Self-learning}
\begin{enumerate}[label=(\roman*)]
\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}
\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}
|
