Øvingseksamen 10

Riktig svar: B — 20 ms

Propagasjonsforsinkelse = avstand / signalhastighet = (4 000 km) / (2 × 10⁸ m/s) = (4 × 10⁶ m) / (2 × 10⁸ m/s) = 0,02 s = 20 ms.

Til sammenligning er transmisjonsforsinkelsen for selve pakken: (1 250 × 8) / (100 × 10⁶) = 10 000 / 10⁸ = 100 µs = 0,1 ms — bare en brøkdel av propagasjonsforsinkelsen. Over lange avstander er det propagasjonen som dominerer, ikke pakkestørrelsen.

Dette er grunnen til at RTT for transatlantiske forbindelser ligger på ~70–100 ms uavhengig av båndbredden.

Pensum: Kap. 1 — Forsinkelsesbegreper

Riktig svar: B

I kretsesvitsjede nett (klassisk telefoni) reserveres ressurser ved oppringningstidspunktet. TDM gir hver samtale en egen tidsslott i en repetert ramme, FDM en egen frekvensbånd. Kapasiteten er din uansett om du faktisk snakker — derfor er kretsesvitsjing dårlig egnet for «bursty» datatrafikk.

A er feil — pakkesvitsjede pakker har headere. C og D beskriver pakkesvitsjede nett (kø-bygging og uavhengig forwarding per pakke).

Avveining: kretsesvitsjing gir garantert ytelse men sløser ressurser; pakkesvitsjing gir effektiv utnyttelse via statistisk multipleksing men krever kø-bygging og kan miste pakker.

Pensum: Kap. 1 — Krets- vs. pakkesvitsjing

Riktig svar: A

FTP er out-of-band: kontrollmeldinger (USER, PASS, RETR, STOR, QUIT) går på port 21, mens selve filinnholdet flyttes via en separat TCP-forbindelse på port 20.

I aktiv modus ber klienten om at serveren oppretter dataforbindelsen tilbake til klienten — dette skaper problemer med NAT/brannmur. I passiv modus (PASV) ber serveren klienten om å åpne dataforbindelsen til en port serveren har lyttet på — dette fungerer bedre med moderne NAT.

HTTP er motsatt: in-band, all kontroll og data går på samme TCP-forbindelse. Det gir én færre forbindelse å håndtere, men gjør at f.eks. avbrutte forespørsler er vanskeligere å håndtere kontrollert.

Pensum: Kap. 2 — FTP

Riktig svar: B

HTTP-statuskoder grupperes i klasser: 2xx = suksess, 3xx = redirect, 4xx = klientfeil, 5xx = serverfeil.

• 301 Moved Permanently: ressursen har fått ny permanent URL. Søkemotorer skal oppdatere indeksen sin; nettlesere kan oppdatere bokmerker.
• 302 Found (eller 307): midlertidig redirect. Klienten følger den, men oppdaterer ikke noe.
• Andre vanlige: 200 OK, 304 Not Modified (conditional GET), 404 Not Found, 500 Internal Server Error.

Når en stor nettside bytter domene, returnerer den 301 fra det gamle domenet til det nye — slik beholdes søkemotor-rangeringen og brukerne sendes automatisk til riktig sted.

Pensum: Kap. 2 — HTTP-statuskoder

Riktig svar: B

Hvis et segment retransmitteres og en ACK ankommer, vet senderen ikke om ACK-en svarer på det første eller det retransmitterte segmentet. RTT-målingen blir tvetydig — å bruke den kan gi feil estimat (for kort hvis vi tror den svarer på den siste; for lang hvis vi tror den svarer på den første).

Karns regel (1987): ignorer RTT-målinger fra retransmitterte segmenter. I stedet, ved hver retransmisjon, dobles RTO (timeout-verdien). Dette er en klassisk exponential backoff-strategi som gir et nett under last «pusterom» til å gjenopprette seg.

Når et nytt segment ikke trenger retransmisjon, gjenopptas vanlig RTT-måling og oppdatering av EstimatedRTT/DevRTT.

Pensum: Kap. 3 — RTT-estimering og Karns algoritme

Riktig svar: B

Med stop-and-wait (vindusstørrelse 1) er gjennomstrømningen begrenset til (1 segment) / RTT. Over en lenke med 100 Mbps og RTT 100 ms blir BDP = 100 Mbps × 0,1 s = 10 Mbit = 1,25 MB. Med MSS = 1 460 byte ville stop-and-wait gitt: 1 460 / 0,1 = 14,6 kB/s ≈ 117 kbps — under 0,2 % av kapasiteten.

Med sliding window kan senderen ha mange segmenter underveis samtidig. Optimal vindusstørrelse er rundt BDP / MSS ≈ 850 segmenter for å fylle linken. ACK-er ankommer kontinuerlig og lar nye segmenter sendes uten å vente på en hel RTT.

Både GBN og SR er sliding-window-protokoller; TCP er det også (med rwnd og cwnd som kontrollerer størrelsen).

Pensum: Kap. 3 — Sliding window og BDP

Riktig svar: B

Klassisk «port address translation» (PAT, en form for NAT). NAT-ruteren bygger opp en oversettelsestabell med oppføringer av typen:

Offentlig (utside)	Privat (innside)
83.5.10.20:60001 → 94.1.1.1:80	10.0.0.5:5000 → 94.1.1.1:80
83.5.10.20:60002 → 94.1.1.1:80	10.0.0.6:5000 → 94.1.1.1:80

Når en svarpakke kommer inn med destinasjons-port 60001, slår NAT-ruteren opp i tabellen og oversetter dest. til 10.0.0.5:5000 før videresending.

Slik kan flere hundre interne hoster dele én offentlig IP — NAT er hovedgrunnen til at det fortsatt fungerer å bruke IPv4 selv med adresseknapphet, men det gjør innkommende forbindelser komplisert (NAT-traversal kreves for P2P).

Pensum: Kap. 4 — NAT

Riktig svar: B

Ping er den enkleste diagnostiske bruken av ICMP: avsenderen sender en Echo Request (type 8), mottakeren svarer med Echo Reply (type 0). RTT måles som tiden fra request til reply.

Pakketap detekteres ved at en forventet reply uteblir (timeout). Tradisjonelt sender ping én pakke per sekund og rapporterer min/avg/max/jitter samt prosent tapt.

Type 11 (Time Exceeded) brukes av traceroute, type 3 av rutere/serverne for å rapportere uleverbare pakker. ICMP er sin egen lag-3-protokoll (parallelt med IP-payload), og den bruker ikke UDP eller TCP.

Pensum: Kap. 5 — ICMP og ping

Riktig svar: B

ARP-tabellen er en cache av nylig observerte IP-til-MAC-mappinger. Hvis topologien endres — en server flyttes mellom rack, en VM får ny vert, eller HSRP/VRRP overfører en virtuell IP fra én ruter til en annen — vil cachen være feil. Et tidsavløp (typisk 1–20 minutter) tvinger fram en ny ARP-utveksling og dermed oppdatert mapping.

Mange systemer bruker også gratuitous ARP: en vert som tar over en virtuell IP, sender en ARP-melding om sin egen IP-MAC-mapping uten å være spurt — slik at andre verter oppdaterer cachen umiddelbart i stedet for å vente på timeout.

Caching i seg selv finnes for å unngå én ARP-broadcast per pakke (ytelse + støy), men tidsavløpet handler om korrekthet over tid.

Pensum: Kap. 6 — ARP og ARP-cache

Riktige svar

1. Usant — radio-mottakeren i 802.11-utstyr kan i praksis ikke høre andres signaler mens den selv sender (hennes egen utgang er flere størrelsesordener sterkere). CSMA/CA prøver i stedet å unngå kollisjoner via tilfeldig backoff og positive ACK — vi vet at det var en kollisjon kun retroaktivt, ved at ACK uteblir.
2. Sant — innenfor samme Extended Service Set deler AP-ene samme SSID og bruker samme broadcast-domene (eller bro) i bakgrunnen. Klienten beholder IP og forbindelser — kun lenkelaget bytter AP. Ved bytte mellom ulike subnett trengs derimot DHCP og ofte mobile IP-mekanismer.
3. Usant — moderne 802.11 bruker rate adaptation: stasjoner og AP-er endrer datarate dynamisk basert på signalkvalitet og pakketap. Lengre fra AP-et brukes lavere, mer robust modulasjon (men lavere bitrate); tett ved AP-et brukes høy modulasjon (mer bit per symbol).
4. Sant — klienter signaliserer Power Save-modus i en flag i sendte rammer. AP-et buffrer da innkommende rammer for klienten og varsler i beacons (TIM-feltet) at det er ventende data. Klienten våkner periodisk, sjekker beacon, og henter dataen. Slik forlenges batterilevetiden uten å miste innkommende trafikk.
5. Sant — SAE (Dragonfly) erstatter PSK-baserte 4-veis handshake i WPA3-Personal. Ved SAE er det ikke lenger mulig å fange handshake-rammene og bryte passordet offline med en GPU-rig. Hvert forsøk krever interaksjon med AP-et og kan dermed begrenses gjennom rate-limiting. WPA3 introduserer også Forward Secrecy og 192-bit-suite for enterprise.

Pensum: Kap. 7 — 802.11, mobilitet, rate adaptation, WPA3

Riktig svar: A

Begge metodene brukes for å oppdage tilgjengelige AP-er rundt seg.

• Passiv: klienten hopper mellom kanaler og lytter etter beacon-rammer. Tregere — må vente på beacon (typisk hvert 100 ms) — men sender ingenting. Brukes for å unngå å avsløre at en enhet leter etter et bestemt SSID, eller når regulatoriske restriksjoner forbyr aktiv sending (DFS-kanaler).
• Aktiv: klienten sender Probe Request (kan inkludere et spesifikt SSID, eller wildcard for «alle»). AP-er som hører requesten svarer raskt med Probe Response. Raskere oppdaging, og brukes som standard.

Aktiv scanning kan lekke informasjon om hvilke nettverk en enhet tidligere har koblet seg til (preferred network list) — derfor forsøker iOS/Android å begrense dette.

Pensum: Kap. 7 — 802.11 scanning og association

Riktige koblinger

Oppgave	Riktig
1 Sertifikatverifisering	c — Autentisering
2 AES-GCM Record-kryptering	a — Konfidensialitet (GCM gir også integritet, men hovedformålet med kryptering av selve innholdet er konfidensialitet)
3 Signert kontrakt	e — Ikke-fornektelse
4 HMAC over ESP-payload	b — Integritet

Distraktor: d — Tilgjengelighet (CIA-triadens A) leveres ikke av kryptografiske mekanismer alene. Den oppnås gjennom redundans, DDoS-mottiltak, lastbalansering osv. — utenfor det de fire eksemplene dekker.

Merk særlig forskjellen mellom autentisering (oppgave 1: «Hvem er du?» — bekreftet via sertifikatet) og integritet (oppgave 4: «Er meldingen uforandret?» — bekreftet via HMAC).

Pensum: Kap. 8 — Sikkerhetsmål og mekanismer

Riktig svar: C — Timestamp

Mens sekvensnummer brukes for å oppdage tap og rekkefølge, gir timestamp selve sampling-klokken. Mottakeren bruker timestamp + en lokal jitter-buffer for å spille av samples i riktig tidspunkt. To pakker som ankommer 50 ms fra hverandre fra nettet, men har timestamps 20 ms fra hverandre, skal spilles av med 20 ms mellomrom — slik glattes jitter ut.

Andre felt: SSRC identifiserer kilden (én verdi per RTP-stream); Payload Type sier hvilken kodek som er brukt (Opus, G.711 osv.); Sequence Number brukes til å oppdage tap og duplikater.

Pensum: Kap. 9 — RTP-headerformat

a) One-way-forsinkelse C → S:

Pakkestørrelse: 1 250 byte = 10 000 bits.

• Transmisjon på C–R: 10 000 / (200 × 10⁶) = 50 µs = 0,05 ms
• Propagasjon på C–R: 2 ms
• Transmisjon på R–S: 10 000 / (50 × 10⁶) = 200 µs = 0,2 ms
• Propagasjon på R–S: 8 ms

Total: 0,05 + 2 + 0,2 + 8 = 10,25 ms.

b) Flaskehals:

Den langsomste lenken setter taket på lang sikt. Her er R ↔ S med 50 Mbps flaskehalsen. Maksimal vedvarende gjennomstrømning: 50 Mbps.

c) BDP for R–S:

RTT på R–S-segmentet: 2 × 8 ms = 16 ms. Men for end-to-end TCP er RTT = 2 × 10,25 ≈ 20,5 ms.

BDP (med flaskehals 50 Mbps og full e2e RTT): 50 × 10⁶ × 0,0205 ≈ 1,025 × 10⁶ bits ≈ 128 kB.

Konsekvens: TCP-vinduet (rwnd × cwnd) må være minst ~128 kB for å holde flaskehalsen mettet. Standard-rwnd uten window scaling er 64 kB — det halverer maksimal oppnåelig throughput. Derfor er TCP window scaling (RFC 1323) viktig på moderne lenker.

Pensum: Kap. 1 — Forsinkelse · Kap. 3 — BDP

a) Minste N for full utnyttelse:

BDP = 10 × 10⁶ × 0,1 = 10⁶ bits = 125 000 byte. Pakkestørrelse 1 000 byte → ≈ 125 pakker må være underveis samtidig for å fylle linken. Senderens vindu N må derfor være ≥ 125.

b) Med N = 10:

Senderen sender 10 pakker, og må deretter vente på første ACK før neste vindu kan begynne (sliding-effekten gir kontinuerlig sending så lenge ACK-er kommer like raskt som pakker sendes ut).

Transmisjonstid for 10 pakker: 10 × (8 000 / 10⁷) = 8 ms. Etter 8 ms har senderen sendt hele vinduet og må vente på ACK fra første pakke, som ankommer ca. RTT = 100 ms etter pakken ble sendt — dvs. ca. 100 ms etter senderen begynte. Senderen er altså aktiv 8 ms av 100 ms = 8 % av tiden.

Effektiv gjennomstrømning: 10 pakker × 8 000 bits / 100 ms = 800 kbps — kun 8 % av kapasiteten.

Vente-tid per syklus: ≈ 92 ms.

c) Konsekvens av tap (pakke n tapt midt i vinduet):

Go-Back-N: Mottakeren forkaster alle pakker etter n (ute av rekkefølge). Etter timeout retransmitterer senderen pakke n og alle påfølgende pakker som var i vinduet (n, n+1, n+2, …). Enkel mottaker (én buffer-posisjon), men sløsete på lenker med tap.

Selective Repeat: Mottakeren buffrer pakker etter n i mottaksvinduet. Når n retransmitteres og ankommer, leveres alle bufrede pakker i riktig rekkefølge til applikasjonen. Senderen retransmitterer kun pakke n. Mer komplisert mottaker (større buffer, individuelle ACK-er), men mye mer effektiv ved tap.

TCP er nærmere SR enn GBN: med SACK-opsjonen kan mottakeren rapportere hvilke spesifikke segmenter som mangler, og senderen retransmitterer kun disse.

Pensum: Kap. 3 — GBN og SR

a) NAT-tabell etter de 3 pakkene:

#	Internt (kilde-IP:port → dest)	Eksternt etter NAT (kilde-IP:port → dest)
1	192.168.1.10:5500 → 142.250.74.110:443	89.10.20.30:50000 → 142.250.74.110:443
2	192.168.1.20:5500 → 142.250.74.110:443	89.10.20.30:50001 → 142.250.74.110:443
3	192.168.1.10:5501 → 188.40.150.100:80	89.10.20.30:50002 → 188.40.150.100:80

Selv om X og Y har samme interne kilde-port (5500), gir NAT-ruteren dem ulike eksterne porter (50000 og 50001) — det er nettopp poenget med port translation.

b) Svarpakke til 89.10.20.30:50001:

1. NAT-ruteren slår opp i sin tabell: «Hvem hadde ekstern port 50001?» — finner Y (192.168.1.20:5500).
2. Endrer destinasjons-IP fra 89.10.20.30 til 192.168.1.20, og destinasjons-port fra 50001 til 5500.
3. Videresender pakken på interne grensesnitt mot Y.

Y mottar pakken som om den kom direkte til seg fra serveren — usynlig at NAT skjedde.

c) Innkommende forbindelser bak NAT:

Hvis serveren prøver å initiere en TCP/UDP-forbindelse inn til X uten at det allerede finnes en NAT-oppføring, vil pakken ankomme NAT-ruteren uten match i tabellen — ruteren vet ikke hvilken intern host den hører hjemme på, og kaster eller blokkerer pakken. Dette gjør P2P-applikasjoner og innkommende serverforbindelser vanskelige.

Vanlige løsninger:

• Port forwarding (statisk NAT): manuell konfigurasjon på ruteren — ekstern port 8080 mappes alltid til intern host:port. Brukes for hjemmekjørte servere.
• UPnP / NAT-PMP / PCP: applikasjoner ber dynamisk ruteren om å åpne et port-mapping.
• NAT-traversal (STUN/TURN/ICE): brukes av WebRTC, VoIP og spill — partene utveksler sine eksterne IP/port via en hjelpe-server, og prøver «hole punching» for å etablere direkte forbindelser.
• IPv6: i prinsippet trengs ikke NAT i det hele tatt fordi adresserommet er stort nok.

Pensum: Kap. 4 — NAT

a) Caesar med skift 7, klartekst HEI:

Bokstav	Posisjon	+7 mod 26	Chiffer
H	7	14	O
E	4	11	L
I	8	15	P

Resultat: HEI → OLP.

b) Vigenère med nøkkel NETT, klartekst HEMMELIG:

Nøkkelen N=13, E=4, T=19, T=19, gjentas: NETTNETT.

Klartekst	Pos	Nøkkel	Skift	Sum mod 26	Chiffer
H	7	N	13	20	U
E	4	E	4	8	I
M	12	T	19	31 mod 26 = 5	F
M	12	T	19	31 mod 26 = 5	F
E	4	N	13	17	R
L	11	E	4	15	P
I	8	T	19	27 mod 26 = 1	B
G	6	T	19	25	Z

Resultat: HEMMELIG → UIFFRPBZ.

c) Hvorfor Vigenère er sterkere — og hvor svakheten ligger:

I Caesar er hver bokstav skiftet med samme verdi, så bokstavfrekvenser i chifferet matcher klartekstens frekvenser eksakt (bare flyttet). Frekvensanalyse løser Caesar trivielt: norsk har «E» som vanligste bokstav, finner bokstaven du ser oftest, regner ut skiftet, ferdig.

I Vigenère har samme klartekstbokstav ulike chifferbokstaver avhengig av posisjonen i nøkkelen. Det glatter ut frekvensfordelingen. Men: så snart angriperen finner nøkkellengden k, blir hver k-te bokstav i chifferet kryptert med samme skift — altså redusert til Caesar. Frekvensanalyse anvendes da på hver «strøm» for seg.

Metoder for å finne k:

• Kasiski-test: let etter gjentatte bokstavmønstre i chifferet. Avstandene mellom gjentakelsene er ofte multipler av nøkkellengden.
• Indeks for sammenfall (IC): for hver mulig k, splitt chifferet i k strømmer og beregn IC. For riktig k vil IC ligge rundt verdien for ren språk-IC; for feil k er den lavere (mer uniform).

d) Kerckhoffs prinsipp:

«Et kryptosystem skal være sikkert selv om alt om systemet, unntatt nøkkelen, er kjent for angriperen.» Med andre ord: sikkerheten hviler kun på nøkkelens hemmelighet, ikke på algoritmens. Moderne kryptografi følger dette strengt: AES, RSA, SHA-256 osv. er offentlig spesifisert og dekket av tiår med kryptanalyse — den eneste hemmeligheten er nøkkelen.

«Security through obscurity» (skjul algoritmen) er motsatsen og regnes som dårlig praksis: fungerer kanskje på kort sikt, men kollapser så snart algoritmen lekker (omvendt utvikling, insider, nyhetsoppslag).

Pensum: Kap. 8 — Klassiske chiffer og Kerckhoffs prinsipp

a) Prinsippet bak ABR (Adaptive Bitrate):

Klienten ber om segmenter via HTTP-GET, og måler hvor lang tid hver nedlasting tok. Estimert tilgjengelig båndbredde = (segmentstørrelse i bits) / (nedlastingstid). Glatting med eksponentielt vektet snitt eller tilsvarende reduserer effekten av enkelt-«bumps».

I tillegg overvåker klienten buffer-fylling: hvor mange sekunder med video er klar til avspilling? Lavt buffer-nivå = fare for stalling, høyt nivå = trygt å satse på høyere kvalitet.

Beslutningsregelen kombinerer båndbredde-estimat (vil neste segment kunne lastes ned i tide?) og buffer-nivå (har vi margin til å eksperimentere?). Klassiske algoritmer er BBA (Buffer-Based Adaptation), MPC (Model Predictive Control) og Pensieve (RL-basert).

b) Velge variant under 3 Mbps:

Den nest høyeste varianten (2,5 Mbps) er fornuftig. Velger man 5 Mbps, vil nedlastingen ta lenger tid enn segmentets 4 sekunder, og bufferen tappes. Velger man 2,5 Mbps, har man margin: nedlastingen tar 4 × (2,5 / 3) ≈ 3,3 sekunder per 4-sekund-segment, så bufferen vokser sakte.

Marginen tjener flere formål: (1) variansen i båndbredden — momentane dropp er vanlige; (2) andre HTTP-objekter som konkurrerer om båndbredden; (3) ACK- og protokolloverhead som ikke er regnet inn i de nominelle bitratevariantene.

c) Strategi ved plutselig båndbreddefall:

Med 30 sekunder buffer kan klienten fortsette på samme bitrate i kort tid mens den observerer om båndbreddefallet er stabilt eller midlertidig. Buffer-nivået vil tappes med ca. 1 sek per sek for hver sek mens nedlasting går saktere enn forbruk.

Hvis fallet vedvarer, må klienten bytte til 400 kbps (under 700 kbps med margin). Hvis klienten venter for lenge, risikerer den buffer-tørke og rebuffering — det er den verste opplevelsen for brukeren (verre enn lavere kvalitet).

Dette er kjernen i ABR-tradeoffet: kvalitet vs. kontinuitet. En 30-sekunders buffer gir tid til å «test ride» problemet, men ikke uendelig tid. Smart algoritmer (MPC) modellerer både fremtidig båndbredde og buffer-nivå og optimaliserer en kostnadsfunksjon som inkluderer både opplevd kvalitet og rebuffering-tid.

Pensum: Kap. 9 — DASH og adaptiv bitrate