Øvingseksamen 1

Riktig svar: C

Pakkesvitsjing lar mange brukere dele den samme linken dynamisk — ressursene brukes bare når noen faktisk sender data. Dette kalles statistisk multipleksing. Siden nettverkstrafikk er "bursty" (ikke jevn), kan man i praksis betjene langt flere brukere enn det dedikerte linjer ville tillatt.

Ulempen er at forsinkelse og pakketap kan variere, siden pakker deler kapasitet med andre. Linjesvitsjing gir garantert kapasitet (A og B), men sløser ressurser når ingen sender.

Pensum: Kap. 1 — Pakkesvitsjing vs. linjesvitsjing

Riktig svar: B — 4 ms

Formel: Transmisjonstid = L / R = 2 000 bits / 500 000 bps = 0,004 s = 4 ms

Transmisjonstiden er tiden det tar å skyve alle bitene i pakken ut på linken. Den avhenger ikke av distansen — det er propageringsforsinkelsen som avhenger av avstand.

Pensum: Kap. 1 — Transmisjonsforsinkelse (d_trans = L/R)

Riktig svar: C

DNS fungerer som Internetts telefonkatalog: du slår opp et navn (f.eks. www.ntnu.no) og får tilbake en IP-adresse (f.eks. 129.241.0.1). Datamaskiner bruker IP-adresser for ruting, ikke navn.

A beskriver DHCP, D beskriver ruting-protokoller som OSPF/BGP.

Pensum: Kap. 2 — DNS

Riktig svar: B

Stateless betyr at serveren ikke lagrer noen kontekst mellom forespørsler fra samme klient. Hvert HTTP-request behandles som helt uavhengig — serveren "husker ikke" at du akkurat lastet ned en annen side.

Cookies (og sessions) er nettopp et lag over HTTP laget for å simulere tilstand på toppen av en tilstandsløs protokoll — det er ikke en del av selve HTTP-protokollen.

Pensum: Kap. 2 — HTTP

Riktig svar: C — SMTP

SMTP (Simple Mail Transfer Protocol) brukes til å sende og videresende e-post — fra klient til utgående server, og mellom servere. IMAP og POP3 brukes til å hente ned e-post fra en server til en klient.

Protokoll	Retning	Typisk port
SMTP	Sender → Server (og Server → Server)	25 / 587
IMAP	Server → Klient (synkronisert)	143 / 993
POP3	Server → Klient (laster ned)	110 / 995

Pensum: Kap. 2 — E-post: SMTP, IMAP, POP3

Riktig svar: C — denne påstanden er feil

UDP (User Datagram Protocol) garanterer ikke levering i riktig rekkefølge, og heller ikke at pakker kommer frem i det hele tatt. Det er nettopp dette som gjør UDP raskere — ingen sekvensnummering, ingen ACK, ingen retransmisjoner.

A, B og D er alle korrekte påstander om UDP. DNS bruker UDP fordi oppslag er korte og hastighet er viktigere enn garantert levering.

Pensum: Kap. 3 — TCP vs. UDP

Riktig svar: B

rwnd (receive window) er verdien mottakeren annonserer til senderen i TCP-headeren, og representerer hvor mye ledig plass det er i mottakerens buffer. Senderen begrenser mengden ukvitterte data til rwnd for å unngå å oversvømme mottakeren.

Dersom rwnd = 0 stopper senderen å sende ny data og sender i stedet periodiske 1-byte-segmenter for å sjekke om bufferen har frigjort plass (probe-segmenter).

Pensum: Kap. 3 — TCP flytkontroll

Riktig svar: C — 32 bits

En IPv4-adresse er 32 bits lang, skrevet som fire grupper på 8 bits (oktetter) i desimalform, f.eks. 192.168.1.100. Dette gir 2³² ≈ 4,3 milliarder mulige adresser.

48 bits er lengden på en MAC-adresse (Ethernet). 128 bits er IPv6-adresselengden — innført nettopp fordi IPv4-rommet er uttømt.

Pensum: Kap. 4 — IPv4-adressering

Riktig svar: C — 14 verter

Et /28-subnett har 32 − 28 = 4 host-biter, som gir 2⁴ = 16 adresser totalt. Av disse er to reservert:

• Nettverksadresse: 192.168.10.0 (alle host-biter = 0)
• Broadcast-adresse: 192.168.10.15 (alle host-biter = 1)

Adresserbare verter = 16 − 2 = 14

Pensum: Kap. 4 — CIDR og subnetting

Riktig svar: C

Forwarding er den lokale operasjonen i en ruter: når en pakke ankommer, slår ruteren opp destinasjons-IP-adressen i forwarding-tabellen og bestemmer hvilken utgangslink (interface) pakken skal videresendes på. Dette skjer i dataplanen (data plane).

B beskriver routing — prosessen som bygger forwarding-tabellen og kjøres i kontrollplanen (control plane). D beskriver ARP.

Pensum: Kap. 4 — Forwarding vs. routing

Riktig svar: C

ICMP er nettverkslagets "feilrapporterings"-protokoll. Kjente bruksområder:

• ping bruker ICMP Echo Request / Echo Reply for å teste tilgjengelighet og måle RTT
• traceroute bruker ICMP Time Exceeded-meldinger (TTL utløpt) for å kartlegge ruten
• Rutere sender ICMP "Destination Unreachable" når de ikke kan videresende en pakke

Pensum: Kap. 5 — ICMP

Riktig svar: C

Lenkelaget trenger MAC-adressen for å konstruere en Ethernet-ramme. ARP løser dette: når vert A vil sende til IP-adresse 192.168.1.5, sender den en ARP-broadcast ("Hvem har 192.168.1.5?"). Vert B med den IP-adressen svarer med sin MAC-adresse. A cacher svaret i ARP-tabellen sin.

A beskriver DHCP, B beskriver DNS.

Pensum: Kap. 6 — ARP

Riktig svar: B

I CSMA/CD (Carrier Sense Multiple Access / Collision Detection): en stasjon lytter (carrier sense) om mediet er ledig, og sender dersom det er stille. Dersom to stasjoner begynner å sende nesten samtidig, kolliderer signalene. Stasjonene oppdager kollisjonen (collision detection), avbryter sendingen, sender et jam-signal og venter en tilfeldig tid (binary exponential backoff) før de prøver igjen.

Pensum: Kap. 6 — CSMA/CD

Riktig svar: B

I asymmetrisk kryptografi har hver part et nøkkelpar: en offentlig nøkkel (kan deles fritt) og en privat nøkkel (hemmelig). Det som krypteres med den offentlige nøkkelen, kan bare dekrypteres med den tilhørende private nøkkelen.

I symmetrisk kryptografi bruker begge parter samme hemmelige nøkkel — utfordringen er å bli enige om nøkkelen uten at noen avlytter nøkkelutvekslingen.

I praksis bruker TLS/HTTPS asymmetrisk kryptografi for å utveksle en symmetrisk sesjonsnøkkel — deretter brukes den raskere symmetriske kryptografien for selve dataoverføringen.

Pensum: Kap. 8 — Symmetrisk vs. offentlig nøkkel

a) De fire typene nodal forsinkelse:

Type	Formel / Forklaring
Prosesseringsforsinkelse	Tid ruteren bruker til å sjekke headerintegritet og bestemme utgangslink. Typisk µs-rekkevidde.
Køforsinkelse	Ventetid i utgangsbufferen mens andre pakker sendes. Varierer med trafikkintensitet (ρ = La/R).
Transmisjonsforsinkelse	dtrans = L / R, der L = pakkestørrelse (bits), R = linkrate (bps)
Propageringsforsinkelse	dprop = d / s, der d = distanse, s ≈ 2×108 m/s (lyshastighet i kobber/fiber)

b) Beregning:

Topologi: A → R1 → R2 → B (3 linker, store-and-forward)

Transmisjonsforsinkelse per link: d_trans = 1 000 bits / 1 000 000 bps = 1 ms

Med store-and-forward og 3 linker: total transmisjonsforsinkelse = 3 × 1 ms = 3 ms

Total propagasjonsforsinkelse = 3 linker × 5 ms = 15 ms

Total forsinkelse = 3 ms + 15 ms = 18 ms

Pensum: Kap. 1 — Forsinkelse og gjennomstrømning

a) Tre-veis handshake:

1. SYN (klient → server): Klienten velger et tilfeldig initialt sekvensnummer (ISN) og setter SYN-flagget. Formål: informere serveren om at klienten vil opprette en forbindelse, og annonsere klientens ISN.
2. SYN-ACK (server → klient): Serveren bekrefter klientens SYN (ACK = klientens ISN + 1) og velger sitt eget ISN. Formål: bekrefte klientens forespørsel og annonsere serverens ISN.
3. ACK (klient → server): Klienten bekrefter serverens SYN (ACK = serverens ISN + 1). Forbindelsen er nå etablert i begge retninger.

b) SYN-pakken går tapt:

Klienten mottar ingen SYN-ACK. Etter en timeout (TCP retransmission timer, starter typisk på 1 sekund og dobles ved hver feilede forsøk — exponential backoff) sender klienten SYN på nytt. Antall forsøk er begrenset av OS-innstillinger (typisk 5–6 ganger).

c) Flow control vs. congestion control:

	Flow control	Congestion control
Hensikt	Beskytte mottakerens buffer mot oversvømmelse	Beskytte nettverket mot overbelastning
Styrt av	Mottakerens rwnd-verdi	cwnd (congestion window), tapssignaler

Pensum: Kap. 3 — TCP-forbindelsesstyring, flow control, congestion control

Steg 1 — DHCP (kap. 2 / applikasjonslaget, over UDP)

PC-en har ingen IP-adresse og sender en DHCP Discover-melding som broadcast (255.255.255.255). DHCP-serveren svarer med en Offer (tilbyr IP, subnettmaske, gateway, DNS-server). PC-en sender DHCP Request; serveren bekrefter med DHCP ACK. PC-en har nå: IP-adresse, subnettmaske, standard gateway-adresse og DNS-serveradresse.

Steg 2 — ARP (kap. 6 / lenkelaget)

PC-en vil sende til standard gateway (for å nå DNS-serveren utenfor lokalnettet). Den kjenner gateway-IP, men ikke MAC-adressen. Den sender en ARP Request-broadcast ("Hvem har gateway-IP?"). Gatewayens ARP Reply gir MAC-adressen. PC-en cacher dette i ARP-tabellen.

Steg 3 — DNS (kap. 2 / applikasjonslaget, UDP port 53)

PC-en sender en DNS-spørring til DNS-serveren: "Hva er IP-adressen til www.example.com?". DNS-serveren svarer (mulig med iterative/recursive oppslag i DNS-hierarkiet) med IP-adressen, f.eks. 93.184.216.34.

Steg 4 — TCP tre-veis handshake (kap. 3 / transportlaget)

PC-en oppretter en TCP-forbindelse til webserveren på port 80 (HTTP) via SYN → SYN-ACK → ACK.

Steg 5 — HTTP GET (kap. 2 / applikasjonslaget)

PC-en sender GET / HTTP/1.1. Webserveren svarer med HTTP/1.1 200 OK etterfulgt av HTML-innholdet. Nettleseren parser HTML og kan sende ytterligere GET-forespørsler for CSS, bilder osv.

Steg 6 — TCP-avslutning

Etter overføring avsluttes TCP-forbindelsen med en fire-veis FIN-handshake (FIN → ACK → FIN → ACK). Med HTTP/1.1 persistent connections kan dette utsettes til ingen flere forespørsler er planlagt.

Merk: I hele prosessen håndterer lenkelaget (Ethernet) innkapsling i rammer med MAC-adresser, og nettverkslaget (IP) håndterer routing mellom subnett.

Pensum: Kap. 2 · Kap. 3 · Kap. 4 · Kap. 6

a) Prefikslengde og subnettmaske:

8 subnett krever 2³ = 8 → 3 ekstra bits. Ny prefikslengde: /16 + 3 = /19

Subnettmaske: de første 19 bitene er 1 → 255.255.224.0

(11111111.11111111.11100000.00000000)

b) Nettverksadressene for alle 8 subnettene:

Hvert subnett spenner over 2³²⁻¹⁹ = 2¹³ = 8192 adresser. Tredje oktett øker med 32 (256/8):

Subnett	Nettverksadresse	Adresserange
1	172.20.0.0/19	172.20.0.0 – 172.20.31.255
2	172.20.32.0/19	172.20.32.0 – 172.20.63.255
3	172.20.64.0/19	172.20.64.0 – 172.20.95.255
4	172.20.96.0/19	172.20.96.0 – 172.20.127.255
5	172.20.128.0/19	172.20.128.0 – 172.20.159.255
6	172.20.160.0/19	172.20.160.0 – 172.20.191.255
7	172.20.192.0/19	172.20.192.0 – 172.20.223.255
8	172.20.224.0/19	172.20.224.0 – 172.20.255.255

c) Broadcast for subnett 5 (172.20.128.0/19):

Siste adresse i rekken: 172.20.159.255

d) Adresserbare verter per subnett:

2¹³ − 2 = 8192 − 2 = 8 190 verter

e) Hvilket subnett tilhører 172.20.130.45?

Tredje oktett er 130. Subnett 5 spenner fra .128.0 til .159.255. 128 ≤ 130 ≤ 159 → Subnett 5 (172.20.128.0/19)

Pensum: Kap. 4 — CIDR, subnetting, longest prefix matching

a) Kryptering: DATANETT, k = 4

Enkode: hvert bokstav flyttes 4 plasser fremover i alfabetet (mod 26). Bruker A=0, B=1 … Z=25.

Klartekst	Pos (0-ind.)	+4 (mod 26)	Chiffertekst
D	3	7	H
A	0	4	E
T	19	23	X
A	0	4	E
N	13	17	R
E	4	8	I
T	19	23	X
T	19	23	X

Kryptert: HEXERIXX

b) Dekryptering: HEXERIXX, k = 4

Dekode: flytt 4 plasser bakover (pos − 4 + 26) mod 26:

Chiffertekst	Pos	−4 (mod 26)	Klartekst
H	7	3	D
E	4	0	A
X	23	19	T
E	4	0	A
R	17	13	N
I	8	4	E
X	23	19	T
X	23	19	T

Resultat: DATANETT ✓

c) Hvorfor er Caesar svak?

Caesar-cipher er en substitusjonschiffer med bare 25 mulige nøkler (k = 1…25). En angriper kan prøve alle 25 kombinasjoner (brute force / uttømmende søk) og finne klarteksten på sekunder. I tillegg bevarer den bokstavfrekvensene fra klarteksten, noe som gjør frekvensanalyse effektivt.

d) Man-in-the-middle (MITM) og offentlig nøkkel:

I et MITM-angrep posisjonerer en angriper (Eve) seg mellom Alice og Bob. Eve utgir seg for å være Bob overfor Alice og Alice overfor Bob — og kan avlytte og endre all kommunikasjon. Offentlig nøkkel-kryptografi er sårbar for MITM dersom Alice ikke kan verifisere at den offentlige nøkkelen hun mottar faktisk tilhører Bob og ikke Eve. Løsningen er sertifikater (PKI) — en betrodd tredjepart (CA) signerer at "denne offentlige nøkkelen tilhører Bob".

Pensum: Kap. 8 — Kryptografi, Caesar, offentlig nøkkel, MITM