Eksamensprediksjon 7 av 7 · våren 2026

Prediksjon 7 — «Pensum-eksperimentene»

Etter fem eksamener begynner et mønster å bli slitt. Fagstaben må skifte. Dette settet henter fra deler av pensum som er tydelig i innholdsfortegnelsen (kap 2 conditional GET, kap 3 Selective Repeat / cwnd-graf, kap 5.6 ICMP-typer, kap 6 Spanning Tree, kap 8.6 TLS, kap 8.7.1 IPSec/VPN, kap 8.8 WPA/WPA3, kap 9.3 VoIP/RTP), men som aldri eller knapt har vært på eksamen 2023–2025. Sannsynligheten for at noe herfra dukker opp er høy. Del I: 14 spørsmål (42 p). Del II: 5 oppgaver (58 p).

Strategi for dette settet

Pensum-pekere du bør pugge: kap 8.6 TLS-handshake, kap 8.7.1 IPSec, kap 8.5.1 PGP, kap 5.6 ICMP-typer, kap 3.4 SR vs GBN.
«Aldri vært, men i pensum»: Conditional GET (304), TCP fast retransmit, IPv4-fragmenteringsfelt, Spanning Tree, WPA-evolusjon. Hver gang en eksaminator skifter ut én oppgave er sjansen stor for at noe herfra inntar plassen.
Husk: Pensum-listen ekskluderer Bittorrent, ECN, SDN, VLAN — så ikke pugg de.

Del I — Automatisk rettede spørsmål

14 flervalg (3p) + 1 sant/usant-blokk (5p) + 1 koble-oppgave (4p) · 51 poeng totalt

Tema som er i pensum, men har vært stille på eksamen — overmodne for ny historie. Avsluttes med sant/usant og koble-oppgave for ICMP-typer.

Spørsmål 1 3 poeng Kap. 2 · Conditional GET

En klient sender en HTTP GET med If-Modified-Since: ...-header for et objekt den allerede har i cache. Hvis serveren ser at objektet ikke er endret, hva sender den tilbake?

A 200 OK med hele objektet på nytt
B 304 Not Modified — uten objektet i kroppen
C 404 Not Found — objektet er stale
D 301 Moved Permanently

Vis fasit

Riktig svar: B — 304 Not Modified

Conditional GET er kjernen i web-cache-effektiviteten. Klienten (eller proxy-cache) sjekker om kopien er fersk — server svarer raskt med 304 og ingen objekt-payload, slik at båndbredde og latens spares. Klienten serverer den lokale kopien til brukeren.

Felle: A er hva en server uten conditional-GET-støtte ville gjort; B er standard oppførsel og bærer pensumet i kap. 2.2.

Pensum: Kap. 2.2 — HTTP Conditional GET

Spørsmål 2 3 poeng Kap. 2 · E-posthenting

Hvilket utsagn skiller IMAP fra POP3 korrekt?

A POP3 lagrer e-posten på serveren og lar brukeren bla mellom mapper; IMAP laster ned alt og sletter på server
B IMAP holder meldingene på serveren og støtter mappestruktur og delvis nedlasting; POP3 laster ned og fjerner typisk fra server
C IMAP og POP3 er identiske — bare to navn for samme protokoll
D POP3 bruker UDP, IMAP bruker TCP

Vis fasit

Riktig svar: B

POP3 er enkel: «last ned, slett, ferdig» — passet en tid med PC-er som var offline mesteparten av dagen. IMAP er rikere: meldingene bor på server, klienten viser dem dynamisk, mapper synkroniseres mellom enheter, klienten kan be om bare header eller kun en del av en melding.

Begge bruker TCP. POP3 = port 110 (alt 995 over TLS); IMAP = port 143 (alt 993 over TLS).

Pensum: Kap. 2.3 — E-postprotokoller

Spørsmål 3 3 poeng Kap. 3 · TCP cwnd

Hva karakteriserer slow start-fasen til TCP?

A cwnd vokser lineært (ett MSS per RTT)
B cwnd vokser eksponentielt (dobles per RTT) frem til ssthresh nås, eller tap inntreffer
C cwnd holdes konstant, mens rwnd justeres
D cwnd halveres hver RTT for å være «forsiktig»

Vis fasit

Riktig svar: B — eksponentiell vekst

Slow start: cwnd starter på 1 MSS, dobler per RTT (legger til 1 MSS per ACK). Ved cwnd = ssthresh skifter TCP til AIMD (lineær vekst, +1 MSS per RTT). Navnet er misvisende: slow start er faktisk raskere enn AIMD. «Slow» refererte til at det starter fra 1.

Felle: D er hva som skjer ved 3 dup ACK i Reno (cwnd halveres), ikke en del av slow start.

Pensum: Kap. 3.7 — TCP congestion control

Spørsmål 4 3 poeng Kap. 3 · SR vs GBN

I et Selective Repeat-skjema får mottakeren pakke 5 i orden, men pakke 3 og 4 har ikke ankommet. Hva gjør mottakeren?

A Forkaster pakke 5 — bare den neste forventede pakken aksepteres
B Sender ACK 5 og bufrer pakken til 3 og 4 ankommer; ACK-en bekrefter spesifikt pakke 5
C Sender ACK 2 (siste i orden) og forkaster pakke 5
D Re-transmitterer pakke 3 og 4 selv

Vis fasit

Riktig svar: B

SR aksepterer og bufrer pakker som er innenfor mottakers vindu — selv om noen forangående mangler. Hver ACK bekrefter en spesifikk pakke (ikke kumulativ).

Til kontrast: Go-Back-N ville gjort C — kun kumulativ ACK på siste i orden, alle out-of-order pakker forkastes. SR er mer effektiv ved enkelt-pakke-tap, men trenger mer minne i mottakers buffer.

Pensum: Kap. 3.4.4 — Selective Repeat

Spørsmål 5 3 poeng Kap. 5 · Routing

Hvilket utsagn er korrekt om forskjellen mellom distance vector- og link-state-routing?

A Link-state-rutere kjenner bare avstanden til naboene; distance-vector-rutere har full topologi
B Distance-vector-rutere utveksler informasjon om distansen til alle destinasjoner kun med naboer; link-state-rutere kringkaster topologi-informasjon til alle, og hver kjører selv et korteste-vei-algoritme (typisk Dijkstra)
C Begge algoritmene krever sentralisert beregning av rutene
D Distance-vector kan bare brukes innenfor ett autonomt system; link-state kun mellom AS-er

Vis fasit

Riktig svar: B

Distance vector (RIP): hver ruter sier til naboene «jeg kan nå X med kostnad Y». Iterativt sprer informasjonen seg. Konvergerer langsommere; lider av «count to infinity».

Link state (OSPF): hver ruter måler kostnad til naboer, kringkaster denne info via flooding. Alle har samme topologi-bilde og kjører Dijkstra lokalt. Mer båndbredde-tunge oppdateringer, men raskere konvergens.

D er feil: RIP og OSPF er begge intra-AS-protokoller. BGP er inter-AS og er en variant av path vector.

Pensum: Kap. 5.2 — Routing-algoritmer

Spørsmål 6 3 poeng Kap. 4 · IP-fragmentering

Hvilket felt i IPv4-headeren brukes til å holde alle fragmenter av samme originaldatagram sammen ved reassembly?

A Total Length
B Time-to-Live
C Identifier
D Header Checksum

Vis fasit

Riktig svar: C — Identifier

Avsender setter samme 16-bit Identifier i alle fragmenter av samme originaldatagram. Mottakeren grupperer fragmenter med samme (kilde-IP, dest-IP, protokoll, identifier) og bruker Fragment Offset + More Fragments-flag til å sortere og avgjøre når alt er mottatt.

Felle: Total Length angir bare det enkelte fragmentets størrelse.

Pensum: Kap. 4.3 — IPv4-fragmentering

Spørsmål 7 3 poeng Kap. 5.6 · ICMP

Hvilken ICMP-meldingstype utløses når TTL i et datagram når 0 ved en ruter, og som traceroute utnytter til å kartlegge stien?

A Echo Reply (type 0)
B Destination Unreachable (type 3)
C Time Exceeded (type 11)
D Redirect (type 5)

Vis fasit

Riktig svar: C — Time Exceeded

Når TTL går til 0 kaster ruteren pakken og sender ICMP Time Exceeded tilbake til kilden — med kilde-IP fra ruteren selv. Traceroute sender pakker med TTL = 1, 2, 3, ... og samler ICMP-svarene for å lære stien hopp for hopp.

Echo Request (type 8) / Reply (type 0) er det ping bruker. Destination Unreachable kommer ved nettverk/host/port-uoppnåelig (UDP-port stengt — også brukt av traceroute for å detektere endepunktet).

Pensum: Kap. 5.6 — ICMP

Spørsmål 8 3 poeng Kap. 6 · STP

Hva er hovedformålet med Spanning Tree Protocol (STP) i et bryter-nettverk?

A Velge en raskere vei mellom rutere
B Hindre uendelige loops av broadcast-rammer ved å deaktivere redundante lenker logisk, mens en aktiv «tre»-topologi opprettholdes
C Kryptere lenkelags-trafikk
D Tildele MAC-adresser dynamisk

Vis fasit

Riktig svar: B

I et bryter-nett uten loop-forebygging vil en broadcast-ramme (eks. ARP-request) sirkulere i evighet og dupliseres. STP velger ut en root-bridge og deaktiverer logisk de redundante lenkene slik at det aktive grafen blir et tre — ingen loop. Hvis en aktiv lenke faller, kan en deaktivert tas i bruk.

Til kontrast: rutere bruker TTL i IP-headeren for å unngå evige loops.

Pensum: Kap. 6.4 — Lenkelag-svitsjer

Spørsmål 9 3 poeng Kap. 8.6 · TLS

Hvilken funksjon har serverens X.509-sertifikat i TLS-handshakingen?

A Det inneholder den symmetriske sesjonsnøkkelen klienten skal bruke
B Det binder en offentlig nøkkel til serverens identitet, signert av en betrodd CA — slik at klienten kan autentisere serveren og trygt utveksle nøkkel-materialet
C Det krypterer all senere trafikk mellom klient og server
D Det inneholder en SHA-256-hash av all data klienten skal sende

Vis fasit

Riktig svar: B

Sertifikatet = (offentlig nøkkel, identitet, gyldighet, signatur). CA-en signerer det med sin private nøkkel; klienten har CA-ens offentlige nøkkel forhåndsinstallert og kan dermed verifisere at sertifikatet ikke er forfalsket. Resultat: server-autentisering.

Selve sesjonsnøkkelen (symmetrisk) etableres separat — typisk via Diffie-Hellman eller (ved RSA) ved at klienten krypterer en pre-master secret med serverens offentlige nøkkel.

Pensum: Kap. 8.6 — TLS

Spørsmål 10 3 poeng Kap. 8.7 · IPSec

Hvilket utsagn om IPSec er korrekt?

A IPSec opererer på applikasjonslaget og krever endring av hver applikasjon
B IPSec opererer på nettverkslaget og kan brukes til å bygge VPN-tunneler mellom to gateways — typisk transparent for applikasjonene
C IPSec er en variant av TLS som kjører over UDP
D IPSec krever at alle rutere langs stien støtter den

Vis fasit

Riktig svar: B

IPSec sikrer IP-datagrammer direkte. To moduser:

Transport mode: bare payload krypteres/integritetsbeskyttes; original IP-header beholdes. Brukes typisk host-til-host.
Tunnel mode: hele original IP-pakken krypteres og pakkes inn i en ny IP-header. Brukes typisk mellom to gateways for site-to-site VPN.

Mellomliggende rutere ser bare den ytre IP-headeren — derfor er D feil.

Pensum: Kap. 8.7.1 — IPSec og VPN

Spørsmål 11 3 poeng Kap. 8.5 · Sikker e-post

Alice vil sende en e-post til Bob med konfidensialitet, integritet og autentisering. Hva er den vanlige rekkefølgen av kryptografiske operasjoner (à la PGP)?

A Alice signerer hash av meldingen med Bobs private nøkkel; krypterer meldingen med egen offentlig
B Alice signerer hash med egen privat; krypterer meldingen med en symmetrisk sesjonsnøkkel; krypterer den symmetriske nøkkelen med Bobs offentlige nøkkel
C Alice sender meldingen i klartekst — autentisering oppnås ved IP-adresse
D Alice krypterer meldingen direkte med RSA og Bobs offentlig — symmetrisk kryptografi er ikke nødvendig

Vis fasit

Riktig svar: B

Hybridmodellen: symmetrisk kryptografi for selve meldingen (rask, selv ved store data), offentlig nøkkel kun for å bytte sesjonsnøkkelen. Signaturen (hash + Alice's privat) gir integritet + opprinnelsesautentisering. Bob dekrypterer den symmetriske nøkkelen med sin egen private, dekrypterer meldingen, og verifiserer signaturen med Alice's offentlige.

D er upraktisk fordi RSA er tregt for store data — derfor brukes hybrid.

Pensum: Kap. 8.5.1 — Sikker e-post

Spørsmål 12 3 poeng Kap. 8.8 · WiFi-sikkerhet

Hvilket utsagn om WPA-utviklingen er korrekt?

A WEP er sikrere enn WPA fordi den er eldre og mer testet
B WPA2 (basert på 802.11i) bruker AES-CCMP for kryptering og gir vesentlig sterkere sikkerhet enn WEP og WPA
C WPA3 fjerner kravet til pre-shared key — alle nettverk er åpne uten passord
D WPA2-standarden er identisk med WPA bortsett fra navnet

Vis fasit

Riktig svar: B

WEP (1997) var grunnleggende ødelagt — RC4 + svake initialiseringsvektorer. WPA (2003) fikset det meste midlertidig (TKIP). WPA2 (2004, 802.11i) introduserte AES-CCMP og er fortsatt utbredt. WPA3 (2018) la til SAE/Dragonfly-håndtrykk som motstår offline-ordbokangrep og forward secrecy — men beholder PSK-konseptet i WPA3-Personal.

Pensum: Kap. 8.8 — Sikre trådløse LAN

Spørsmål 13 3 poeng Kap. 9 · RTP

Hvilken funksjon har tidsstempelet (timestamp) i en RTP-header?

A Det forteller mottakeren klokketiden da pakken ble sendt
B Det indikerer når media-prøven (audio sample, video frame) ble laget hos avsenderen — slik at mottaker kan spille av media på riktig tidspunkt og synke flere strømmer
C Det er et sekvensnummer som identifiserer pakken
D Det brukes til kryptografisk integritetsbeskyttelse av pakken

Vis fasit

Riktig svar: B

RTP-timestamp har en media-spesifikk klokke (eks. 8 000 Hz for 8 kHz audio). Mottakers playout-buffer bruker timestamps til å reprodusere riktig timing til tross for jitter, og til å synke audio + video som har separate RTP-strømmer.

Felle: A sammenblander wall-clock og media-time. Sekvensnummer (C) er et eget felt i RTP-headeren.

Pensum: Kap. 9.4.1 — RTP

Spørsmål 14 3 poeng Kap. 3 · TCP fast retransmit

Hvorfor reagerer TCP på tre dupliserte ACK-er ved å gjenoverføre segmentet umiddelbart, i stedet for å vente på timeout?

A Tre dup ACK-er er et sterkt tegn på at én spesifikk pakke er tapt mens senere pakker har kommet frem — derfor er rask gjenoverføring trygg
B Tre dup ACK-er antyder at hele forbindelsen er nede, så TCP starter i slow start umiddelbart
C Det er tilfeldig — bare en optimalisering uten teoretisk begrunnelse
D Tre dup ACK-er signaliserer at mottakers buffer er full

Vis fasit

Riktig svar: A

Hvis bare én pakke (sekvensnr X) gikk tapt og resten kom frem, vil mottakeren sende ACK X for hver påfølgende pakke (siden ACK er kumulativ — den siste i orden er fortsatt X−1 → ACK X). Tre slike duplikater → høyt sannsynlig tap. TCP gjenoverfører X umiddelbart (fast retransmit), halverer cwnd, og fortsetter i AIMD (fast recovery i Reno).

B er feil — det er hva timeout signaliserer.

Pensum: Kap. 3.7 — Fast retransmit

Spørsmål 15 5 poeng Kap. 2–9 · Pensum

Avgjør om hver av påstandene er sann eller usann. 1 poeng per riktig svar.

Vis fasit

Riktige svar

Usant — server svarer 304 Not Modified (uten kropp) hvis innholdet ikke har endret seg siden tidspunktet i If-Modified-Since.
Sant — det er nettopp dette som skiller SR fra GBN. Mottaker bufrer ut-av-orden-pakker innen vinduet og leverer dem i orden når hullet fylles.
Sant — alle fragmenter av samme originaldatagram deler ID. Fragment Offset (i 8-byte-enheter) gir rekkefølgen, og MF-flag forteller om det er flere fragmenter.
Sant — TLS 1.3 sender klient-nøkkel-share med ClientHello, så server kan svare med sertifikat + Finished i én runde. 0-RTT bruker PSK fra forrige sesjon.
Usant — det er IMAP som har mappestruktur og synkronisering. POP3 laster ned og fjerner typisk fra server.

Pensum: Kap. 2.2–2.3 · Kap. 3.4 · Kap. 4.3 · Kap. 8.6

Spørsmål 16 4 poeng Kap. 5.6 · ICMP

Koble hver situasjon til ICMP-meldingen som typisk utløses. Velg én bokstav per rad. 1 poeng per riktig kobling.

Selectable Items

Echo Request / Reply (type 8 / 0)
Time Exceeded (type 11)
Destination Unreachable, Port Unreachable (type 3, kode 3)
Destination Unreachable, Network Unreachable (type 3, kode 0)
Redirect (type 5)

#	Situasjon	Ditt valg
1	Du kjører `ping ntnu.no` og får svar tilbake fra server
2	En ruter forkaster pakken fordi TTL gikk til 0 underveis
3	Traceroute (UDP-basert) når destinasjonshosten på en lukket UDP-port
4	Pakke til et nettverk som ingen rute fører til (rute mangler i forwarding-tabell, ingen default)

Merk: én av de fem ICMP-typene er en distraktor.

Vis fasit

Riktige koblinger

Situasjon	ICMP-type
1 ping-svar	a — Echo Request/Reply
2 TTL = 0	b — Time Exceeded
3 traceroute treffer endepunkt	c — Port Unreachable
4 Ingen rute	d — Network Unreachable

Distraktor: e — Redirect, som en ruter sender for å fortelle en host «du burde sende til en annen gateway for denne destinasjonen». Sjelden i moderne nett.

Pensum: Kap. 5.6 — ICMP

Del II — Åpne oppgaver

5 oppgaver · 58 poeng totalt

Vekt på pensum-tema som har vært stille på eksamen — vis at du kan dem.

Oppgave 1 14 poeng Kap. 3 · TCP cwnd

En TCP Reno-forbindelse har følgende historikk for cwnd (i MSS) gjennom 20 RTT-runder:

Runde 0: cwnd = 1, ssthresh = 16
Runde 0–4: dobler hver runde (slow start)
Runde 4: cwnd = 16; ssthresh nås. AIMD starter (lineær +1 per runde).
Runde 10: cwnd = 22. 3 dup ACK inntreffer. ssthresh = 11; cwnd = 11; AIMD fortsetter.
Runde 16: cwnd = 17. Timeout. ssthresh = 8; cwnd = 1; slow start.
Runde 16–19: slow start dobler (1→2→4→8). Når ssthresh = 8 nås, AIMD starter.

a) Tegn (eller beskriv ledd for ledd) cwnd-grafen fra runde 0 til runde 20. (5p)

b) Identifiser intervaller der TCP er i slow start, AIMD, og fast recovery. (4p)

c) Forklar hvorfor reaksjonen på 3 dup ACK er mindre aggressiv (cwnd = ssthresh, ikke 1) enn reaksjonen på timeout (cwnd = 1). (3p)

d) Hva er gjennomsnittlig cwnd over de 20 rundene? Hvilken intuitiv «sage-tooth»-form gir TCP Reno? (2p)

Vis fasit

a) cwnd-tabell:

Runde	cwnd	Hendelse
0	1	Start, slow start
1	2	SS
2	4	SS
3	8	SS
4	16	Når ssthresh, skifter til AIMD
5–10	17–22	AIMD (+1 per runde)
10	22	3 dup ACK → ssthresh = 11, cwnd = 11
11–16	11–17	AIMD (fast recovery)
16	17	Timeout → ssthresh = 8, cwnd = 1
17	2	SS
18	4	SS
19	8	SS når ssthresh, AIMD
20	9	AIMD

b) Intervaller:

Slow start: runde 0–4, og runde 16–19.
AIMD (congestion avoidance): runde 4–10, og 11–16, og 19–20.
Fast recovery: runde 10–11 (umiddelbart etter 3 dup ACK; cwnd halveres og AIMD fortsetter).

c) Hvorfor mindre aggressiv ved 3 dup ACK:

3 dup ACK-er betyr at noen pakker fortsatt går igjennom — bare én er tapt. Forbindelsen er fortsatt levende. Halvering av cwnd (ikke reset til 1) holder ytelsen oppe.

Timeout antyder at hele forbindelsen kan ha brutt sammen (ingen ACK-er kommer i det hele tatt). Da er det tryggere å starte forsiktig fra cwnd = 1 og finne nettverkets nye kapasitet på nytt.

d) Sage-tooth:

Sum av cwnd over alle 21 rundene (0–20) ≈ 1+2+4+8+16+17+18+19+20+21+22+11+12+13+14+15+16+17+1+2+4+8+9 = ca. 270. Snitt ≈ 12,9 MSS.

Sage-tooth: cwnd vokser lineært, blir kuttet ned, vokser igjen. Mønsteret er typisk for AIMD og er grunnen til at TCP holder seg «rettferdig» med andre TCP-strømmer.

Pensum: Kap. 3.7 — TCP Reno

Oppgave 2 12 poeng Kap. 3 · Reliable transfer

Avsender sender 6 pakker med sekvensnumre 0, 1, 2, 3, 4, 5 — i den rekkefølgen. Pakke 2 går tapt. Vinduet er av størrelse 4.

a) Beskriv hva som skjer ved Go-Back-N: hva sender mottakeren, og hva må avsenderen gjøre? (5p)

b) Beskriv hva som skjer ved Selective Repeat: hva sender mottakeren, og hva må avsenderen gjøre? (5p)

c) Hvilken er mer effektiv ved enkelt-pakke-tap, og hva er prisen for det? (2p)

Vis fasit

a) Go-Back-N:

Mottakeren har kumulative ACK-er. Etter 0 og 1: ACK 1. Pakke 2 tapt. Pakker 3, 4, 5 ankommer ut av orden — mottakeren forkaster alle og sender ACK 1 tre ganger til (duplikat-ACK).

Avsender venter på timeout for pakke 2 (eller fast retransmit ved 3 dup ACK). Når den oppstår, gjenoverfører avsender alle ubekreftede pakker fra og med 2: altså 2, 3, 4, 5.

Bortkastet båndbredde: 3 og 4 og 5 sendes på nytt selv om de allerede har kommet frem.

b) Selective Repeat:

Mottakeren ACK-er hver pakke individuelt. Etter 0, 1, 3, 4, 5 ankommer: ACK 0, ACK 1, ACK 3, ACK 4, ACK 5. Mottakeren bufrer 3, 4, 5 i mottaksvinduet (de er innenfor vinduet — antar SR med vindu 4).

Avsender ser at ACK 2 mangler. Etter timeout for pakke 2 alene: gjenoverfør kun pakke 2.

Mottaker mottar pakke 2, leverer 2, 3, 4, 5 til applikasjonen i orden, og sender ACK 2.

c) Effektivitet og pris:

SR er mer effektiv: bare den tapte pakken sendes på nytt. Prisen er kompleksitet — mottakers buffer må kunne holde ut-av-orden-pakker innen vinduet, og mottaker må kunne ACK individuelt. GBN holder mottaker enkel (tilstandsløs i praksis), men sløser båndbredde ved tap.

Pensum: Kap. 3.4 — Reliable data transfer

Oppgave 3 10 poeng Kap. 4 · IP-fragmentering

Et IP-datagram på 3 700 byte (inkludert 20-byte header) skal sendes over en lenke med MTU = 1 200 byte. ID-feltet er 0xABCD.

a) Hvor mange fragmenter blir det? Hva er total length og payload-størrelse for hvert? (4p)

b) Hva er Fragment Offset (i 8-byte-enheter) og MF-flag for hvert fragment? (4p)

c) Hvis fragment 2 går tapt, hva skjer hos mottakeren etter en stund? (2p)

Vis fasit

a) Antall fragmenter:

Hvert fragment har 20-byte IP-header. Maks payload per fragment = MTU − 20 = 1 180 byte. Men payload må være delelig med 8 (fragment offset er i 8-byte-enheter): 1 180 / 8 = 147,5 — runder ned til 1 176 byte payload (147 × 8).

Original payload = 3 700 − 20 = 3 680 byte.

3 680 / 1 176 ≈ 3,12 → trenger 4 fragmenter:

Fragment 1: total = 1 196 byte (20 header + 1 176 payload)
Fragment 2: total = 1 196 byte
Fragment 3: total = 1 196 byte
Fragment 4: total = 172 byte (20 header + 152 payload). 1 176 × 3 = 3 528, gjenstår 3 680 − 3 528 = 152 byte.

b) Offset og MF:

Fragment	Offset (8-byte-enheter)	MF	ID
1	0	1	0xABCD
2	147 (1 176/8)	1	0xABCD
3	294 (2 352/8)	1	0xABCD
4	441 (3 528/8)	0	0xABCD

c) Hvis fragment 2 tapes:

Mottakeren kan ikke reassemblere det fullstendige datagrammet — det starter en reassembly-timer. Når timeren utløper (typisk 60 sekunder), blir alle fragmentene kastet, og mottakeren sender ICMP «Time Exceeded — Fragment Reassembly Time Exceeded» (type 11, code 1) tilbake til avsender.

IP gjenoverfører ikke selv. Det er TCP/applikasjonens ansvar å oppdage og handle.

Pensum: Kap. 4.3 — IP-fragmentering

Oppgave 4 12 poeng Kap. 8.6 · TLS

a) Beskriv stegene i en TLS 1.2-handshaking på et høyt nivå. Hvilke meldinger sendes hver vei? (6p)

b) Hvorfor signerer CA-en sertifikatet med sin private nøkkel, og hva sjekker klienten for å verifisere det? (3p)

c) Hva er forskjellen på TLS 1.2 og TLS 1.3 i RTT-kostnad ved oppsett, og hvorfor? (3p)

Vis fasit

a) TLS 1.2-handshake (på høyt nivå):

ClientHello (klient → server): klient-tilfeldig nonce, støttede chiffersuiter, TLS-versjon.
ServerHello (server → klient): server-tilfeldig nonce, valgt chiffersuit, valgt TLS-versjon.
Certificate (server → klient): server sender sin sertifikat-kjede (signert av CA).
ServerHelloDone (server → klient).
ClientKeyExchange (klient → server): klient genererer pre-master secret, krypterer med serverens offentlige nøkkel (RSA), eller bidrar med Diffie-Hellman-data.
ChangeCipherSpec + Finished (klient → server): begge sider beregner master secret + sesjonsnøkler fra de tilfeldige nonsene + pre-master.
ChangeCipherSpec + Finished (server → klient): bekrefter.

Total: 2 RTT før første applikasjonsdata kan sendes.

b) Hvorfor signerer CA-en:

Sertifikatet inneholder serverens offentlige nøkkel, identitet (DNS-navn, organisasjon), gyldighetsperiode. CA-en signerer hele bunten med sin private nøkkel. Klienten har CA-ens offentlige nøkkel forhåndsinstallert (i nettlesernes / OS-ets root store) og verifiserer signaturen — hvis riktig, vet klienten at sertifikatet er ekte og at navnet hører til den offentlige nøkkelen.

Klienten sjekker også: navn-match med URL, gyldighetsperiode, sertifikatet er ikke revokert (CRL/OCSP).

c) TLS 1.2 vs TLS 1.3:

TLS 1.2: 2 RTT for full handshake. TLS 1.3: 1 RTT for full handshake — klienten sender sin nøkkel-share i ClientHello (anslår hvilken DH-gruppe serveren støtter), og servern svarer med sin share + sertifikat + Finished i én runde. Klienten sender Finished + første applikasjonsdata på neste melding.

Pluss TLS 1.3 0-RTT (resumption): kan sende applikasjonsdata direkte med PSK fra forrige sesjon — null RTT-forsinkelse, men har replay-svakheter for non-idempotente operasjoner.

Pensum: Kap. 8.6 — TLS

Oppgave 5 10 poeng Kap. 5.6 · ICMP

a) Forklar tre distinkte ICMP-meldinger og når de utløses. (4p)

b) Beskriv hvordan traceroute bruker TTL og ICMP til å kartlegge stien fra A til B. Hvorfor får vi typisk to typer ICMP-respons under én traceroute-kjøring? (4p)

c) En noter at ICMP-pakker «bæres direkte i IP» — hva betyr det, og hvorfor er ikke ICMP en transportprotokoll? (2p)

Vis fasit

a) Tre ICMP-meldinger:

Echo Request / Reply (type 8 / 0): brukes av ping. Klienten sender Echo Request, mottakeren svarer Echo Reply. Måler RTT og verifiserer at hosten er nåbar.
Time Exceeded (type 11): sendes av en ruter når TTL i et IP-datagram når 0. Brukes av traceroute.
Destination Unreachable (type 3): sendes når en ruter eller endenoden ikke kan levere pakken (network unreachable, host unreachable, port unreachable, fragment reassembly time exceeded).

b) Traceroute-mekanikk:

Traceroute sender pakker med TTL = 1, 2, 3, ... Hver gang TTL = N, kommer pakken til ruter N + 1 (relativ til kilden), TTL går til 0, ruteren kaster pakken og sender ICMP Time Exceeded tilbake. Kilde-IP i den ICMP-meldingen avslører ruterens IP. Slik kartlegges stien hopp for hopp.

Når pakken endelig når destinasjonen, vil destinasjonen ikke gi Time Exceeded (TTL var stor nok). I klassisk traceroute (UDP-basert) sendes pakkene til en høy UDP-port der ingen lytter — destinasjonen svarer ICMP Destination Unreachable, code 3 (Port Unreachable). Dette signaliserer slutten på sti-traversen.

(Windows-tracert bruker ICMP Echo Request i stedet — der kommer Echo Reply tilbake fra destinasjonen i stedet.)

c) ICMP og IP:

ICMP-meldinger pakkes direkte inn i IP-datagrammer (protokoll-felt = 1) — ingen TCP eller UDP-header mellom. ICMP regnes som en del av nettverkslaget selv om det ligger over IP, fordi det fyller kontroll- og diagnose-rollen for IP. Ingen porter, ingen pålitelighet, ingen forbindelse — derfor er det ikke en transportprotokoll.

Pensum: Kap. 5.6 — ICMP