Øvingseksamen · TTM4100

Øvingseksamen 8

Del I: 14 flervalgsoppgaver (42 poeng). Del II: 5 åpne oppgaver (58 poeng). Totalt 100 poeng. Svar på egenhånd — åpne fasiten etterpå.

Temaer i dette settet

RTT, HTTP HEAD og DNS-caching (kap. 1 og 2)
rdt 3.0-timer og demultipleksering i transportlaget (kap. 3)
CIDR-oppslag og DHCP DORA (kap. 4)
ICMP-typer (kap. 5)
Ethernet ramme-størrelse, kollisjons- vs. broadcast-domener (kap. 6)
2.4 GHz vs. 5 GHz WiFi (kap. 7)
Nonce, VPN-typer og TLS-MITM-resistens (kap. 8)
Nyquist-sampling, web-caching og hop-for-hop-adresser (kap. 9 og oppsummering)

Del I — Automatisk rettede spørsmål

14 spørsmål · 3 poeng per spørsmål · 42 poeng totalt

Klikk på alternativet du mener er riktig — du får umiddelbart vite om du svarte riktig, og forklaringen åpner seg automatisk.

Spørsmål 1 3 poeng Kap. 1

Hva er den korrekte definisjonen av RTT (Round-Trip Time)?

A Tiden det tar for én pakke å nå destinasjonen — såkalt one-way delay målt i applikasjonen
B Tiden mellom at en pakke sendes og en korresponderende kvittering returnerer til senderen — tur-retur-tiden
C Lenkens fysiske avstand delt på lyshastigheten i mediet — den rene propagasjonsforsinkelsen
D Variasjonen i forsinkelse over tid, målt som standardavvik mellom etterfølgende pakker

Vis fasit

Riktig svar: B

RTT er den fulle tur-retur-tiden — fra senderen sender en pakke til den får tilbake en respons (typisk en ACK). Den inkluderer alle forsinkelseskomponenter (transmission, propagation, kø, prosessering) på begge veier.

RTT brukes bl.a. som basis for TCPs timeout-beregning, for å estimere båndbreddeforsinkelsesproduktet og som mål på «opplevd» nettverkskvalitet (ping-tid).

Alternativ A er ensretningsforsinkelse (one-way delay), C er propagasjonsforsinkelse, og D er jitter.

Pensum: Kap. 1 — Forsinkelsesbegreper

Spørsmål 2 3 poeng Kap. 2

Hva er forskjellen mellom HTTP-metodene GET og HEAD?

A HEAD ber om bare ressursens header-felter — uten selve innholdet i body
B HEAD er den krypterte varianten av GET
C HEAD oppdaterer en ressurs på serveren, GET henter
D HEAD krever autentisering, GET ikke

Vis fasit

Riktig svar: A

HEAD er identisk med GET, bortsett fra at serveren ikke returnerer ressursens body — bare statuslinje og headerlinjer. Brukes typisk til å sjekke om en ressurs eksisterer, hvor stor den er (Content-Length), eller når den sist ble endret (Last-Modified) — uten å betale båndbredden for å laste den ned.

Eksempler: linkkontrollere, debugging-verktøy, og scenariobeslutning før man bestemmer seg for å gjøre full GET.

Pensum: Kap. 2 — HTTP-metoder

Spørsmål 3 3 poeng Kap. 2

DNS-svar har et TTL-felt (Time to Live) som indikerer hvor lenge et svar kan caches. Hvilket konkret kompromiss styrer valg av TTL-verdi?

A Lav TTL gir bedre sikkerhet mot DNS-spoofing fordi resolveren da må kontakte autoritativ server oftere og verifisere svarene på nytt
B Høy TTL → mindre DNS-trafikk og raskere oppslag, men endringer i records (f.eks. ny IP) tar lenger tid å spre seg ut til brukerne
C TTL-verdien styrer kun hvor lenge eieren har retten til å bruke domenet hos registraren, og påvirker ikke hvordan resolverne cacher svar
D TTL er et eldre felt fra tidlig DNS som i moderne implementasjoner ignoreres av resolverne, og caching styres i stedet av lokale policyer

Vis fasit

Riktig svar: B

Høy TTL (timer/dager): færre DNS-spørringer går til autoritativ server, raskere brukeroppslag fra cache, mindre belastning på DNS-infrastrukturen — men endringer av A-records tar opp til TTL-verdien å nå frem til alle brukere som har en eldre cachet kopi.

Lav TTL (sekunder/minutter): endringer spres raskt — nyttig for fail-over og dynamiske CDN — men gir høy belastning på autoritativ server og økt oppslagsforsinkelse for brukere med kald cache.

Typiske TTL-er: 24 timer for stabile A-records, 60 sek eller mindre for tjenester med rask fail-over.

Pensum: Kap. 2 — DNS-caching og TTL

Spørsmål 4 3 poeng Kap. 3

Hvilken funksjon har timeren i rdt 3.0 (Stop-and-Wait med alternating bit)?

A Mottakeren bruker timeren til å vente på flere pakker før den ACK-er, slik at den kan kvittere flere segmenter samtidig og spare båndbredde
B Timeren er en ren rate-begrenser hos senderen som sikrer at pakker sendes med jevne mellomrom uavhengig av ACK-flyten
C Senderen retransmitterer pakken når timeren utløper, siden den ikke kan skille mellom tap av data og tap av ACK
D Mottakeren bruker timeren til å beregne sin egen NAK-respons og varsle senderen om manglende segmenter ved tap

Vis fasit

Riktig svar: C

I rdt 3.0 håndteres tap (av data eller ACK) ved at senderen starter en timer når den sender en pakke. Hvis ingen ACK ankommer før timeren utløper, sender senderen pakken på nytt. Senderen vet ikke om det var data- eller ACK-tap — men begge tilfellene løses av samme strategi.

Mottakeren bruker alternating bit (sekvensnummer 0/1) til å oppdage om en mottatt pakke er en ny pakke eller et duplikat (forrige ble retransmittert pga. tapt ACK). Duplikater ACK-es på nytt, men leveres ikke til applikasjonen en andre gang.

Pensum: Kap. 3 — rdt 3.0 / Stop-and-Wait

Spørsmål 5 3 poeng Kap. 3

Hvilken kombinasjon av felter bruker TCP for å demultiplekse innkommende segmenter til riktig socket?

A Bare destinasjons-port — kjernen finner riktig socket via porttabellen på destinasjonsverten
B Kilde-IP og destinasjon-IP brukes sammen som nøkkel i socket-oppslaget
C 4-tuppelet (kilde-IP, kilde-port, destinasjons-IP, destinasjons-port)
D 4-tuppelet kombinert med MAC-adressen til mottakerens nettverkskort

Vis fasit

Riktig svar: C

I TCP er en forbindelse identifisert av hele 4-tuppelet. Det betyr at en server kan ha mange samtidige TCP-forbindelser til samme portnummer (f.eks. 443 for HTTPS) fra ulike klienter — hver forbindelse skiller seg ved kilde-IP og kilde-port.

UDP derimot bruker bare 2-tuppelet (destinasjons-IP, destinasjons-port) for å demultiplekse — to UDP-pakker fra forskjellige avsendere til samme port-IP havner i samme socket.

Pensum: Kap. 3 — Multipleksing/demultipleksing

Spørsmål 6 3 poeng Kap. 4

IP-adressen 192.168.45.137 tilhører subnettet med prefiks /26. Hvilken er nettverksadressen?

A 192.168.45.0
B 192.168.45.128
C 192.168.45.137
D 192.168.45.192

Vis fasit

Riktig svar: B — 192.168.45.128

/26 betyr 26 bits nettverksdel og 6 host-bits. I siste oktett bruker prefikset 2 bits — dvs. blokkstørrelsen er 2⁶ = 64. Mulige nettverksadresser i .45 er: 0, 64, 128, 192.

137 = 128 + 9. Siden 128 ≤ 137 < 192, ligger adressen i nettet som starter på 128.

Nettverksadresse: 192.168.45.128. Broadcast = 192.168.45.191. Adresserbare verter: .129 – .190 (62 stk).

Pensum: Kap. 4 — CIDR og subnetting

Spørsmål 7 3 poeng Kap. 4

Hva er den korrekte rekkefølgen av meldingene i DHCPs «DORA»-sekvens?

A Discover, Offer, Reply, ACK
B Detect, Open, Renew, Acknowledge
C Discover, Offer, Request, ACK
D Decode, Output, Receive, Apply

Vis fasit

Riktig svar: C — Discover, Offer, Request, ACK

DORA er det vanlige akronymet for de fire DHCP-meldingene:

Discover (klient → broadcast): «Er det noen DHCP-server her?»
Offer (server → klient): «Jeg tilbyr deg IP X.X.X.X med disse parametrene.»
Request (klient → broadcast): «Jeg aksepterer tilbudet — også et signal til andre servere om at deres tilbud kan slippes.»
ACK (server → klient): «Bekreftet — du eier IP-adressen i lease-tiden.»

Discover og Request sendes som broadcast siden klienten enten ikke har IP ennå, eller skal informere alle DHCP-servere på nettet om sitt valg.

Pensum: Kap. 4 — DHCP

Spørsmål 8 3 poeng Kap. 5

Hva er forskjellen i bruk mellom ICMP type 3 (Destination Unreachable) og type 11 (Time Exceeded)?

A Type 3 sendes når TTL utløper på en ruter underveis, og type 11 sendes når en pakke ankommer en destinasjon som ikke eksisterer eller har en lukket port
B Type 3 sendes når et endesystem (vert eller ruter) ikke kan levere pakken til destinasjonen (ukjent vert, lukket port, blokkert nett); type 11 sendes når TTL går til null på en ruter underveis
C Begge meldingene sendes i nøyaktig samme situasjon og inneholder samme informasjon — de er duplikater bevart av historiske grunner i ICMP-spesifikasjonen
D Type 3 brukes utelukkende av ping for å rapportere uoppnåelige verter, mens type 11 brukes utelukkende av traceroute for å kartlegge ruterne underveis

Vis fasit

Riktig svar: B

De to typene løser ulike problemer:

Type 3 — Destination Unreachable. Pakken kunne ikke leveres til endemålet. Underkoder presiserer årsaken: kode 0 = nettverk ukjent, 1 = vert ukjent, 3 = port lukket, 4 = fragmentering nødvendig osv.
Type 11 — Time Exceeded. En ruter dekrementerer TTL og finner at den er null. I stedet for å videresende, kastes pakken og en Time Exceeded sendes til kilden.

Traceroute utnytter type 11 ved å sende pakker med stadig økende TTL — hver ruter underveis sender Time Exceeded når TTL utløper, og kartleggingen er gjort.

Pensum: Kap. 5 — ICMP-typer

Spørsmål 9 3 poeng Kap. 6

Hva er minimum og maksimum data-payload i en standard Ethernet (IEEE 802.3) ramme — uten jumbo frames og uten 802.1Q-tag?

A 0–65 535 byte
B 46–1 500 byte
C 64–1 518 byte
D 1–1 024 byte

Vis fasit

Riktig svar: B — 46 til 1 500 byte

Ethernet-rammens header er 14 byte (6 dest-MAC + 6 kilde-MAC + 2 type/length) og CRC er 4 byte — totalt 18 byte overhead. For at ramen skal nå minimum 64 byte (kreves for at CSMA/CD-kollisjonsdeteksjon skal fungere), må payload være minst 64 − 18 = 46 byte. Mindre payload puttes inn med padding.

Maksimum payload er 1 500 byte, noe som gir maksimalt 1 518 byte total ramme (1 500 + 18). Dette er Ethernets MTU.

Alternativ C beskriver hele rammens størrelse (inkl. headere/CRC), ikke payload alene.

Pensum: Kap. 6 — Ethernet-rammeformat

Spørsmål 10 3 poeng Kap. 6

Et nettverk består av tre LAN-segmenter, hver med en egen 4-ports switch og 4 verter, koblet sammen via én ruter med tre porter (én port per LAN). Hvor mange kollisjonsdomener og broadcast-domener er det totalt?

A 1 kollisjonsdomene · 1 broadcast-domene
B 12 kollisjonsdomener · 1 broadcast-domene
C 12 kollisjonsdomener · 3 broadcast-domener
D 3 kollisjonsdomener · 3 broadcast-domener

Vis fasit

Riktig svar: C — 12 kollisjonsdomener, 3 broadcast-domener

Hver port på en switch er sitt eget kollisjonsdomene (full-duplex, ingen kollisjon mellom forskjellige porter). 3 switcher × 4 porter med vert = 12 kollisjonsdomener.

En switch deler ikke broadcast-domene — alle verter på samme switch ser ARP/DHCP-broadcast. En ruter, derimot, deler broadcast-domener fordi den ikke videresender L2-broadcast. 3 LAN-segmenter, hvert med egen ruter-port = 3 broadcast-domener.

Kort: switch deler kollisjon, ruter deler både kollisjon og broadcast.

Pensum: Kap. 6 — Switch vs. ruter

Spørsmål 11 3 poeng Kap. 7

Hvilken påstand om 802.11-frekvensbåndene 2.4 GHz og 5 GHz er korrekt?

A 2.4 GHz har generelt høyere maksrate fordi det har bredere kanaler tilgjengelig, mens 5 GHz har lengre rekkevidde fordi høyere frekvenser bærer signalet bedre gjennom vegger
B 2.4 GHz har lengre rekkevidde og bedre vegg-penetrasjon, men mer interferens og lavere maksrate; 5 GHz har høyere maksrate og mer tilgjengelig spektrum, men kortere rekkevidde
C Båndene er fysisk identiske og brukes om hverandre av AP-er, og forskjellen er kun et formelt valg av kanalnummer ved oppsett av nettverket
D 5 GHz er ved internasjonal regulering forbeholdt innendørs bruk i alle land og kan ikke brukes utendørs uten spesiell lisens fra myndighetene

Vis fasit

Riktig svar: B

De fysiske egenskapene til de to båndene gir ulike avveininger:

Egenskap	2.4 GHz	5 GHz
Rekkevidde / vegg-penetrasjon	Bedre	Dårligere (signal absorberes mer)
Tilgjengelig spektrum	Smalt — kun 3 ikke-overlappende kanaler (1, 6, 11)	Bredt — mange kanaler tilgjengelige
Maksimal datarate	Lavere (typisk 802.11n-rater)	Høyere (802.11ac/ax)
Interferens fra andre enheter	Mye (Bluetooth, mikrobølgeovner, naboers WiFi)	Mindre

Praktisk: 2.4 GHz gir bedre dekning i store/komplekse hus, mens 5 GHz gir høyere ytelse i nærhet til AP-et.

Pensum: Kap. 7 — 802.11-frekvensbånd

Spørsmål 12 3 poeng Kap. 8

Hva er hovedformålet med en nonce i en kryptografisk autentiseringsprotokoll?

A Et synonym for hash-verdi som identifiserer en autentiseringsmelding entydig på tvers av sesjoner
B En tilfeldig engangsverdi som motvirker at en angriper kan «spille av» tidligere fanget kommunikasjon — hindrer replay-angrep
C Et ekstra langt og tilfeldig generert passord som brukes i stedet for vanlige passord for å motstå ordbok-angrep
D En bredbåndsmåling sendt fra klienten til AP-et som brukes til å forhandle frem en passende krypteringsnøkkel

Vis fasit

Riktig svar: B

«Nonce» = number used once. En part trekker en tilfeldig verdi som inkluderes i en autentiseringsmelding, og motparten må svare med en funksjon av nonce-en (f.eks. en signatur eller MAC). Selv om en angriper fanger en gammel autentiseringsmelding og prøver å «spille den av igjen» senere, vil den nye nonce-en være forskjellig — angriperen kan ikke gjenta svaret.

Nonces er brukt i bl.a. WPA2 4-veis handshake, TLS handshake (ClientRandom/ServerRandom), CHAP-autentisering og Kerberos. Det er viktig at de er tilfeldige og unike per sesjon — gjenbruk åpner for angrep.

Pensum: Kap. 8 — Autentisering og replay-angrep

Spørsmål 13 3 poeng Kap. 8

Hva er forskjellen mellom site-to-site VPN og remote-access VPN?

A Site-to-site forbinder to faste nettverk via en kryptert tunnel mellom to gateways; remote-access lar én individuell bruker logge seg inn til et nettverk fra en hvilken som helst plass
B Site-to-site bruker alltid IPSec på nettverkslaget, mens remote-access alltid bruker SSL/TLS på applikasjonslaget — denne protokollskillet er en del av VPN-standarden og kan ikke fravikes
C Site-to-site krypterer all trafikk mellom gatewayene, mens remote-access er en ukryptert tunnel som kun gir ruting inn til det interne nettet uten konfidensialitetsbeskyttelse
D De er ulike navn for samme oppsett som har oppstått fordi ulike leverandører har valgt forskjellig terminologi for den samme grunnleggende VPN-arkitekturen

Vis fasit

Riktig svar: A

Site-to-site: en VPN-tunnel mellom to faste lokasjoner (typisk to kontorers gateways). All trafikk mellom de interne nettene rutes gjennom tunnelen — for brukerne ser det ut som ett sammenhengende nett. Vanlig protokoll: IPSec i tunnel mode.

Remote-access: en individuell bruker (med VPN-klient på sin laptop) bygger en kryptert tunnel til bedriftens VPN-konsentrator. Brukeren får da en intern IP og kan nå interne ressurser. Vanlige protokoller: SSL/TLS-VPN (OpenVPN, WireGuard), IKEv2/IPSec.

I praksis bruker bedrifter ofte begge: site-to-site mellom kontorer, remote-access for hjemmekontor og reisende ansatte.

Pensum: Kap. 8.7 — IPSec og VPN

Spørsmål 14 3 poeng Kap. 9

Standard telefoni bruker PCM med 8 kHz sampling. Hvilket grunnleggende prinsipp begrunner at dette er tilstrekkelig for menneskelig tale?

A Shannon-Hartley-teoremet om maksimal kanalkapasitet ved gitt båndbredde og signal-til-støy-forhold
B Nyquist-prinsippet: et signal med båndbredde B kan rekonstrueres fullstendig med samplingrate ≥ 2B
C Heisenbergs uskarphetsprinsipp anvendt på tids- og frekvensoppløsning i diskrete signaler
D Reed-Solomon-koding som korrigerer feil i digitaliserte lydprøver ved hjelp av redundans

Vis fasit

Riktig svar: B

Nyquist-Shannons samplingteorem sier at et signal med båndbredde B må samples minst 2B ganger per sekund for å kunne rekonstrueres uten tap. Menneskelig tale har det meste av sin energi under 3,4 kHz, og telefoni filtrerer signalet til ca. 4 kHz. Sampling på 8 kHz (= 2 × 4 kHz) er derfor akkurat nok.

Hvis samplingraten er for lav, oppstår aliasing: høyere frekvenser foldes ned i hørbart område og forvrenger lyden.

Til sammenligning bruker CD-lyd 44,1 kHz sampling for å dekke det fulle hørbare området (opp til ca. 20 kHz).

Pensum: Kap. 9 — VoIP og digitalisering av tale

Del II — Åpne oppgaver

5 oppgaver · 58 poeng totalt

Åpne, skriftlige svar. Begrunn svarene dine. Vis utregning der det er relevant. Klikk «Vis fasit» for å sammenligne med modellbesvarelsen.

Oppgave 1 10 poeng Kap. 2

En bedrift har 50 ansatte som hver i snitt sender 1 HTTP-forespørsel per sekund med gjennomsnittsobjekt på 200 kB. Bedriften har én Internett-link på 50 Mbps med RTT 100 ms til typiske webservere. Du vurderer å installere en lokal web-cache.

a) Beregn gjennomsnittlig trafikkintensitet (ρ) på Internett-linken uten cache. (3p)

b) En lokal cache med hit-rate 0,4 (40 % av forespørslene treffer cache) installeres. Beregn ny trafikkintensitet på Internett-linken. Anta at intern trafikk til/fra cachen er ubegrenset. (3p)

c) Anslag forventet ende-til-ende-forsinkelse for en cache-miss og en cache-hit (cache-hit har RTT ≈ 1 ms til lokal cache, ingen Internett-tur). Hvor stor er gjennomsnittlig forventet forsinkelse for en typisk forespørsel etter installasjonen? (4p)

Vis fasit

a) Trafikkintensitet uten cache:

Total forespørselsrate: 50 ansatte × 1/s = 50 forespørsler/s.

Per forespørsel: 200 kB = 1 600 kbit = 1 600 000 bit.

Total trafikkrate: 50 × 1 600 000 = 80 × 10⁶ bps = 80 Mbps.

Linjekapasitet: 50 Mbps. ρ = 80 / 50 = 1,6 — over 1, dvs. linjen er overbelastet, store køer og pakketap.

b) Med cache (hit-rate 0,4):

40 % av forespørslene besvares lokalt, 60 % må ut på Internett.

Internett-trafikk: 0,6 × 80 = 48 Mbps. ρ = 48 / 50 = 0,96.

Fortsatt høy intensitet (96 %), men under 1 — systemet er stabilt, om enn med betydelig kø-forsinkelse.

c) Forventet forsinkelse:

Cache-miss: RTT 100 ms + transmisjonstid (ignoreres ved kort transmisjon, men ved 200 kB / 50 Mbps = 32 ms) + kø-forsinkelse (kan bli betydelig ved ρ = 0,96 — anta f.eks. 100 ms i snitt). Total ≈ 100 + 32 + 100 ≈ ~230 ms.

Cache-hit: 1 ms (lokal). Transmisjonstid på lokalt LAN er neglisjerbar. Total ≈ ~1 ms.

Vektet snitt: 0,4 × 1 + 0,6 × 230 ≈ 0,4 + 138 ≈ ~138 ms. Vesentlig bedre enn uten cache (der trafikk ikke konvergerer).

I tillegg er besparelsen i Internett-båndbredde betydelig — bedriften kan klare seg med samme link i lengre tid.

Pensum: Kap. 2 — Web-caching

Oppgave 2 12 poeng Kap. 3

Den enkle TCP-throughput-formelen i steady-state med periodiske tap er ofte gitt som:

B ≈ (1,22 · MSS) / (RTT · √p), der p er sannsynligheten for tap per segment.

a) En TCP-forbindelse har MSS = 1 460 byte og RTT = 80 ms. Tap-rate p = 0,001 (0,1 %). Beregn maksimal forventet gjennomsnittlig throughput. (5p)

b) Hva blir throughput hvis tap-raten øker til p = 0,01 (1 %)? Hva sier resultatet om sammenhengen mellom tap og TCP-ytelse? (3p)

c) Forklar hvordan formelen «forklarer» den klassiske sagtannmodellen: hvor kommer faktoren √p fra (intuitivt)? (4p)

Vis fasit

a) MSS = 1 460 byte = 11 680 bits, RTT = 0,08 s, p = 0,001:

√p = √0,001 ≈ 0,0316.

B ≈ (1,22 × 11 680) / (0,08 × 0,0316) = 14 250 / 0,00253 ≈ 5,63 × 10⁶ bps

≈ 5,6 Mbps.

b) p = 0,01:

√p = 0,1.

B ≈ (1,22 × 11 680) / (0,08 × 0,1) = 14 250 / 0,008 ≈ 1,78 × 10⁶ bps

≈ 1,78 Mbps — ca. en tredjedel av før.

Konklusjon: en tidobling av tap-raten halverer ikke throughput, den senker den med faktor 1/√10 ≈ 0,32. Selv små økninger i tap kan halvere TCP-ytelse — derfor er TCP svært følsomt for tap på lange, høyt-belastede ruter.

c) Hvor kommer √p fra:

I AIMD-fasen øker cwnd lineært med 1 MSS per RTT. Etter et visst antall RTT-er treffer cwnd verdien W (i MSS) der det skjer et tap, og cwnd halveres til W/2. Antall pakker sendt mellom to tap er da omtrent (W/2 + W) · (W/2) / 2 — i størrelsesorden W²/2.

Tap-raten p = 1 / (antall pakker per «syklus») ≈ 2 / W², dvs. W ≈ √(2/p).

Gjennomsnittlig cwnd ≈ ¾ · W, og throughput = (gjennomsnittlig cwnd · MSS) / RTT ∝ MSS / (RTT · √p). Derav den karakteristiske 1/√p-skaleringen.

Sagtannmodellen gir altså formelen — det er ikke en empirisk tilpasning, men direkte konsekvens av AIMD med periodiske tap.

Pensum: Kap. 3 — TCP throughput

Oppgave 3 15 poeng Kap. 4 · 6

Vert A (IP 10.1.1.5, MAC aa:01) er på subnett 10.1.1.0/24. Vert B (IP 10.2.2.7, MAC bb:07) er på subnett 10.2.2.0/24. Mellom dem er en ruter R med to interfaces:

R-eth0: IP 10.1.1.1, MAC r1:01 (mot subnett A)
R-eth1: IP 10.2.2.1, MAC r2:01 (mot subnett B)

A skal sende en IP-pakke til B. ARP-tabeller på A og R er allerede oppdatert.

a) Hvilke kilde-/destinasjons-MAC-adresser og kilde-/destinasjons-IP-adresser har rammen idet den forlater A? (3p)

b) Hvilke MAC- og IP-adresser har rammen idet den mottas av R på R-eth0? (2p)

c) Hvilke MAC- og IP-adresser har rammen idet den forlater R på R-eth1? (3p)

d) Hvilke MAC- og IP-adresser har rammen idet den mottas av B? (2p)

e) Forklar prinsippet bak dette mønsteret: hvorfor endres MAC-adressene ved hver hop, mens IP-adressene forblir uendret? (5p)

Vis fasit

a) Forlater A:

Felt	Verdi
Kilde MAC	aa:01 (A)
Dest. MAC	r1:01 (R-eth0 — A's standard gateway)
Kilde IP	10.1.1.5 (A)
Dest. IP	10.2.2.7 (B — endelig mottaker)

A vet at B er på et annet subnett (sammenlikner sin egen IP/maske med B's IP). A sender derfor rammen til standard gateway, hvis MAC den allerede har lært via ARP.

b) Mottas av R på R-eth0:

Identisk med a) — innholdet i rammen endres ikke i transit. Kilde MAC = aa:01, dest. MAC = r1:01, kilde IP = 10.1.1.5, dest. IP = 10.2.2.7.

c) Forlater R på R-eth1:

Felt	Verdi
Kilde MAC	r2:01 (R-eth1)
Dest. MAC	bb:07 (B — funnet via ARP på subnett B)
Kilde IP	10.1.1.5 (A — uforandret)
Dest. IP	10.2.2.7 (B — uforandret)

R kapsler IP-pakken inn i en ny ramme på utgangs-interface, med MAC-adresser som passer til subnett B.

d) Mottas av B:

Som c). Kilde MAC = r2:01, dest. MAC = bb:07, kilde IP = 10.1.1.5, dest. IP = 10.2.2.7.

e) Prinsippet:

MAC-adresser er lokale for ett LAN-segment (én lenke). For at en ramme skal nå én eller annen vert på lenken, må dest. MAC stemme med en vert som faktisk er på den lenken — enten endelig mottaker eller en gateway som leder videre. Ved hver hop blir rammen «pakket inn på nytt» med nye MAC-er som passer det aktuelle segmentet.

IP-adresser er derimot ende-til-ende. De identifiserer den opprinnelige kilden og endelige mottakeren av pakken. Rutere i mellom skal ikke endre dem — IP er den globale «postadressen», MAC er det lokale «hus-nummeret» på hver gate som rutes gjennom.

Konsekvens: ved feilsøking kan du følge IP-adressene gjennom tcpdump på flere ruter-grensesnitt — de er like overalt — mens MAC-adressene bytter ved hver hop.

Pensum: Kap. 4 · Kap. 6 — Lag-2 vs. lag-3-adressering

Oppgave 4 11 poeng Kap. 8

a) En angriper, Eve, sitter mellom Alice og en webserver og prøver å utføre et MITM-angrep mot Alices HTTPS-økt. Hvilke konkrete egenskaper ved TLS hindrer at Eve kan (i) lese trafikken og (ii) utgi seg for serveren overfor Alice? (5p)

b) Bedrift A og bedrift B vil koble sammen sine to interne nettverk slik at all trafikk mellom dem er kryptert og autentisert — uten at hver enkelt klient/server trenger sin egen TLS-konfigurasjon. Hvilken type løsning anbefaler du, og på hvilket lag i protokollstakken arbeider den? (3p)

c) Forklar forskjellen mellom autentisering av server og gjensidig autentisering i TLS. I hvilke situasjoner brukes gjensidig autentisering vanligvis? (3p)

Vis fasit

a) TLS-egenskaper mot MITM:

(i) Lesing av trafikken: TLS Record Protocol krypterer all applikasjonsdata med en sesjonsspesifikk symmetrisk nøkkel som ble forhandlet under handshake (typisk via Diffie-Hellman). Eve som passivt lytter ser bare krypterte bytes — ingen lesbar tekst. DH-baserte handshakes gir også forward secrecy: selv om Eve senere får tak i serverens private nøkkel, kan tidligere opptak ikke dekrypteres.

(ii) Utgi seg for serveren: Serveren presenterer et X.509-sertifikat under handshake, signert av en CA i Alices trust store. Eve kan presentere et hvilket som helst sertifikat hun vil — men hvis hun ikke har en CA-signert sertifikat for det riktige domenet, vil Alices nettleser oppdage misforholdet og advare. Eve kan heller ikke kopiere det ekte sertifikatet og utgi seg som server, fordi handshake krever at hun beviser eierskap til den private nøkkelen (signerer en handshake-melding). Uten serverens private nøkkel feiler dette.

b) Anbefalt løsning:

En site-to-site IPSec-VPN mellom de to bedriftenes gateways. IPSec arbeider på nettverkslaget (lag 3) i tunnel mode: hele IP-pakker mellom de interne nettene kapsles inn i nye, eksternt-rutbare IP-pakker, krypteres og autentiseres med ESP. Klienter og servere på de interne nettene trenger ingen ekstra konfigurasjon — for dem ser nettverkene ut som direkte koblet.

c) Server-autentisering vs. gjensidig autentisering:

I vanlig TLS (f.eks. HTTPS-webside): kun serveren presenterer et sertifikat. Klienten verifiserer servern, men serveren vet ikke hvem klienten er — typisk skjer brukerautentisering etterpå med passord/2FA over den krypterte kanalen.

Ved gjensidig autentisering (mTLS) presenterer også klienten et sertifikat. Begge sider verifiserer hverandre via PKI før forbindelsen aksepteres. Dette brukes typisk i:

Bedriftsintern API-trafikk (server-til-server-kommunikasjon)
VPN-løsninger og Zero-Trust-arkitekturer
Bank/finans-API-er der både parter må kunne identifiseres

Det er sterkere sikkerhet, men krever utstedelse og forvaltning av klientsertifikater.

Pensum: Kap. 8.6 — TLS · Kap. 8.7 — IPSec/VPN

Oppgave 5 10 poeng Kap. 9

En utvikler bygger en sanntidslyd-applikasjon. Brukerne sender lyd til hverandre med følgende kjente parametere: bitrate 32 kbps (tale-koding), RTT typisk 50 ms, pakketapsrate 5 % på den trådløse delen av nettverket, og brukernes opplevde latensbudsjett er 200 ms én vei.

a) Foreslå en konkret transport- og applikasjonsstrategi for lydstrømmen: hvilken protokoll bør brukes, hvor stor bør hver pakke være, og hvilke teknikker mot tap er relevante? Begrunn valgene mot kravene. (6p)

b) RTT øker plutselig til 200 ms. Hvilke av valgene fra a) må revurderes, og hva slags forsinkelsesbudsjett er igjen? (4p)

Vis fasit

a) Anbefaling:

Transport: RTP over UDP. TCP er uegnet — retransmisjon utløst av tap ankommer for sent (etter timeout og full RTT) og forsinker hele strømmen pga. hodet-av-køen-blokkering.
Pakkestørrelse: 20 ms tale per pakke gir 32 kbps × 0,02 s = 640 bits = 80 byte payload. Mindre pakker (10 ms) reduserer tap-merkbarheten men gir høyere overhead-andel; større pakker (40 ms+) gir bedre overhead-effektivitet men gjør hver tap mer hørbar. 20 ms er et standard kompromiss.
Tap-resiliens: Med 5 % tap er ren tap-styring nødvendig. Anbefalinger: (1) FEC i form av lav-bitrate backup-kopi av forrige pakke i hver ny pakke (gir vesentlig bedre opplevelse ved enkelt-pakketap, til kostnad av ~30 % ekstra båndbredde); (2) interleaving (sprer samples) er nyttig hvis tap er bursty; (3) god lyd-koding som tåler enkelt-pakketap (f.eks. Opus, som har innebygd PLC).
Adaptiv playout-buffer: Med RTT 50 ms og 200 ms latensbudsjett er det ca. 100 ms å bruke på buffer + behandling. En buffer på 40–60 ms absorberer typisk jitter mens den holder seg innenfor budsjettet.

b) RTT øker til 200 ms:

Latensbudsjettet (200 ms én vei) er nå nesten brukt opp av selve transit-tiden. Dette er kritisk — én-vei-forsinkelsen kommer typisk i nærheten av 100 ms (≈ halv RTT pluss kø). Med 100 ms én-vei-transit er det bare ca. 100 ms igjen til buffer + behandling, men VoIP «føles» allerede dårligere over 150 ms én vei.

Det som må revurderes:

Mindre playout-buffer. Reduser fra 40–60 ms til 20–30 ms — mindre jitter-toleranse, men mindre tilleggslatens.
Sterkere fokus på FEC enn på retransmisjon. Selv hvis vi vurderte selektiv retransmisjon, vil det neppe rekke fram i tide.
Mulig vurdering av kortere pakker (10 ms) for å redusere innkapslingsforsinkelsen — men dette øker pakkraten og dermed båndbreddeforbruket.

Hvis RTT vedvarer høyt, vil opplevelsen uansett bli merkbart dårligere enn ved 50 ms — det er en grense for hva applikasjonsteknikker kan kompensere for når selve nettet er treigt.

Pensum: Kap. 9 — VoIP-design