Øvingseksamen 7

Riktig svar: C

Jitter er variasjonen («skjelvet») i ende-til-ende-forsinkelse fra pakke til pakke. To pakker som sendes med 20 ms mellomrom kan komme fram med 18 ms eller 25 ms mellomrom — forskjellen skyldes ulik køforsinkelse og ulike ruter underveis.

Jitter er kritisk i sanntidsapplikasjoner: en VoIP-mottaker som spiller av samples med ujevne mellomrom høres ut som forvrengt tale. Løsningen er en playout-buffer som absorberer jitter ved å forsinke avspillingen noen titalls millisekunder.

Pensum: Kap. 1 — Forsinkelse, jitter og pakketap

Riktig svar: B

HTTP/1.1 med pipelining tillater å sende flere forespørsler etter hverandre på samme forbindelse, men responsene må komme i samme rekkefølge — én treg respons blokkerer alle som kommer etter («head-of-line blocking» på applikasjonsnivå). HTTP/2 deler hver request/response opp i mindre «frames» merket med stream-ID, slik at frames fra ulike strømmer kan flettes om hverandre. En liten respons kan komme før en stor — uten å vente.

Merk at HTTP/2 fortsatt går over TCP og kan derfor rammes av TCP-nivå head-of-line-blocking ved pakketap. HTTP/3 (over QUIC/UDP) løser også det.

Pensum: Kap. 2 — HTTP-evolusjon

Riktig svar: B

Klienten konfigureres (typisk via DHCP) med adressen til en lokal DNS-server — ofte ISP-ens eller f.eks. 8.8.8.8 (Google) eller 1.1.1.1 (Cloudflare). Klienten sender alle DNS-spørringer dit. Den lokale serveren utfører iterative oppslag mot rot-, TLD- og autoritative servere på vegne av klienten, og cacher svarene (med TTL) slik at gjentatte oppslag for populære navn kan besvares umiddelbart.

Den lokale serveren er altså ikke autoritativ for noe — den er en proxy/cache som forenkler oppslagsprosessen for klientene.

Pensum: Kap. 2 — DNS-hierarki

Riktig svar: B

AIMD-fasens additive økning gir like store steg uavhengig av forbindelsens nåværende rate. Men den multiplikative reduksjonen (halvering ved tap) reduserer mer hos den med høyest rate. Over tid konvergerer dette mot lik fordeling — den klassiske «sagtann»-grafens diagonal i fairness-rommet.

Dette er en heuristikk, ikke en garanti. Forbindelser med ulik RTT får ulik andel (kortere RTT vinner), og det finnes utvidelser/varianter (CUBIC, BBR osv.) med annen oppførsel.

Pensum: Kap. 3 — TCP-fairness

Riktig svar: A

I TCP betyr ACK = N at mottakeren har mottatt og kvittert alle bytes med sekvensnummer mindre enn N — og venter neste byte med sekvensnummer N. En enkelt ACK kan derfor bekrefte en lang sammenhengende strøm. Hvis et segment går tapt, kan ikke ACK-tallet flyttes forbi det tapte byte-rommet før hullet tettes.

I praksis bruker TCP i tillegg delayed ACKs (vente opptil 500 ms eller til neste segment ankommer) for å redusere ACK-trafikk, og SACK (Selective ACK) som tillegg for å rapportere ut-av-orden mottakelser.

Pensum: Kap. 3 — TCP-segmentet og ACK-er

Riktig svar: B

TCP behandler applikasjonens data som en kontinuerlig byte-strøm. Senderens 100-byte send + 200-byte send kan ankomme mottakeren som ett 300-byte read, eller flere mindre read-er — TCP bevarer ingen meldingsgrenser. Applikasjonsnivå-protokoller (HTTP, SMTP osv.) må selv markere grensene (f.eks. Content-Length-header eller delimeter som tom linje).

UDP, derimot, er datagram-basert: ett sendt datagram = ett mottatt datagram (eller tapt), grenser bevart.

Pensum: Kap. 3 — TCP-tjenester

Riktig svar: A — 2001:db8::1

IPv6-forkortelsesregler:

• Ledende nuller i hver 16-bits gruppe kan fjernes: 0db8 → db8
• Én sammenhengende gruppe av nullgrupper kan erstattes med :: (men kun én gang i adressen — ellers blir det tvetydig)

Originaladressen har 6 etterfølgende null-grupper mellom db8 og 1. De erstattes med ::. Resultat: 2001:db8::1.

Alternativ C er ulovlig (to ::-grupper). B utelater for mange nuller uten å bruke ::.

Pensum: Kap. 4 — IPv6-adresseformat

Riktig svar: B

En DHCP-relay-agent (typisk konfigurert i ruteren) lytter etter DHCP-broadcast på sitt grensesnitt og pakker dem inn som unicast til den kjente sentrale DHCP-serveren — og pakker ut serverens svar tilsvarende. Slik trenger man bare én DHCP-server selv om nettet har mange subnett.

Relay-agenten legger inn sin egen IP i Giaddr-feltet, slik at DHCP-serveren vet hvilket subnett klienten er på (og dermed kan velge riktig IP-pool).

Pensum: Kap. 4 — DHCP og relay

Riktig svar: B

I distance-vector (Bellman-Ford-baserte algoritmer som RIP) snakker hver ruter bare med sine direkte naboer og deler sin egen «distansetabell» til alle destinasjoner. Den lærer ikke nettets faktiske struktur — bare avstander.

Link-state (Dijkstra-baserte som OSPF) krever derimot at alle rutere kjenner hele topologien (via flooding av link-state-pakker), og hver ruter beregner selv kortest vei.

Distance-vector kan lide av langsom konvergens og «count-to-infinity»-problemer, mens link-state typisk konvergerer raskere men trenger mer minne og prosessering.

Pensum: Kap. 5 — Routing-algoritmer

Riktig svar: C

De første 24 bitene er OUI — IEEE tildeler dette til produsenten av nettverksadapteret. F.eks. 00:1A:11 tilhører Google, F0:18:98 tilhører Apple. De siste 24 bitene tildeles av produsenten selv slik at hvert adapter får en unik 48-bits adresse globalt.

Dermed er MAC-adresser «flate» — de bærer ingen topologisk informasjon, og to adaptere fra samme produsent har samme OUI, uavhengig av hvor i verden de befinner seg.

Pensum: Kap. 6 — MAC-adresser

Riktig svar: B

Power management lar en mobilenhet (telefon, laptop) gi beskjed til AP-et om at den går i sleep mode. AP-et buffrer da eventuelle innkommende rammer for klienten. Ved jevne mellomrom våkner klienten kort, leser AP-ets beacon (med TIM — Traffic Indication Map), og dersom det er buffrede rammer, hentes de inn — ellers går klienten tilbake i sleep.

Dette gir vesentlig batterisparing for klienten, til prisen av noen titalls millisekunders ekstra forsinkelse.

Pensum: Kap. 7 — 802.11 power management

Riktig svar: B

De tre grunnleggende sikkerhetsegenskapene:

• Konfidensialitet: ingen andre enn legitim mottaker kan lese meldingen (oppnås ved kryptering).
• Integritet: meldingen er ikke endret underveis (oppnås med MAC, HMAC eller digital signatur).
• Autentisering: mottakeren kan bekrefte hvem avsenderen er (oppnås med digitale signaturer eller MAC kombinert med kjent identitet).

Disse er uavhengige: en melding kan være konfidensiell uten å være autentisert (du leser den, men vet ikke hvem som sendte den), eller autentisert uten å være konfidensiell (alle kan lese, men du vet hvem som sendte).

Pensum: Kap. 8.1 — Hva er nettverkssikkerhet?

Riktig svar: A

Når en TLS-sesjon settes opp, kjører Handshake Protocol: ClientHello/ServerHello med versjon og chiffer-suiter, sertifikatutveksling, nøkkelutveksling (typisk DH-basert), og avslutter med en ferdig-melding på begge sider — etter dette har begge en delt symmetrisk sesjonsnøkkel.

Etter handshake går all applikasjonsdata gjennom Record Protocol: data deles i records, krypteres med sesjonsnøkkelen, MAC-es og sendes. Mottakeren utfører motsatt prosess — sjekker MAC, dekrypterer og leverer til applikasjonen.

Pensum: Kap. 8.6 — TLS

Riktig svar: B

HTTP/TCP-baserte streaming-arkitekturer har flere praktiske fordeler i Internett anno 2024:

• Brannmur/NAT-vennlig: port 80/443 er nesten alltid åpen, mens RTP-porter ofte blokkeres.
• CDN-vennlig: chunks er ordinære HTTP-objekter — kan caches i eksisterende HTTP-CDN-infrastruktur.
• Adaptasjon: klienten velger kvalitet per chunk basert på målt båndbredde — krever ingen ny serverlogikk.
• Akseptabel TCP-retransmisjon: klienten har typisk 10–30 sek buffer, så små TCP-pauser er ikke synlige for brukeren.

RTP/UDP er fortsatt foretrukket for konversasjonell sanntid (videosamtaler, VoIP) der enhver retransmisjon ankommer for sent til å være nyttig.

Pensum: Kap. 9 — Streaming Stored Video

Standardresultater for fildistribusjon (Kurose & Ross):

Klient-server: D_cs = max{ N·F / u_s, F / d_min }

P2P: D_P2P = max{ F / u_s, F / d_min, N·F / (u_s + Σu_i) }

a) Klient-server, N = 50:

N·F / u_s = 50 × 100 Mbit / 30 Mbps = 5000 / 30 ≈ 166,7 s

F / d_min = 100 / 5 = 20 s

Maks: 166,7 s. Flaskehalsen er serverens uplink — den må sende 50 kopier av filen sekvensielt.

b) P2P, N = 50:

F / u_s = 100 / 30 ≈ 3,33 s

F / d_min = 100 / 5 = 20 s

Σu_i = 50 × 2 = 100 Mbps. Total opplastningskapasitet = 30 + 100 = 130 Mbps.

N·F / (u_s + Σu_i) = 50 × 100 / 130 ≈ 38,5 s

Maks: ca. 38,5 s. Vesentlig raskere enn klient-server (166,7 s).

c) N = 100:

Klient-server: 100 × 100 / 30 ≈ 333 s (skalerer lineært med N — verre).

P2P: u_s + Σu_i = 30 + 200 = 230 Mbps. N·F/total = 100 × 100 / 230 ≈ 43,5 s. F/d_min = 20 s ≪ . Maks ≈ 43,5 s.

P2P skalerer mye bedre — hver ny peer bidrar både med last og kapasitet.

Pensum: Kap. 2 — P2P-fildistribusjon

a) Fire-veis FIN-handshake:

Anta at A initierer close mot B.

1. FIN (A→B): A sender FIN-segment. A går til FIN_WAIT_1.
2. ACK (B→A): B kvitterer FIN-en. B går til CLOSE_WAIT; A går til FIN_WAIT_2. På dette punktet er A→B-retningen lukket, men B→A er fortsatt åpen — B kan sende mer data hvis den har noe ufullført.
3. FIN (B→A): Når B også er ferdig, sender den sin egen FIN. B går til LAST_ACK.
4. ACK (A→B): A kvitterer B's FIN. A går til TIME_WAIT. B mottar ACK og går til CLOSED.

Etter 2·MSL går A også til CLOSED.

b) Hvorfor TIME_WAIT i 2·MSL:

To grunner:

1. Tap av siste ACK: Hvis A's siste ACK går tapt, vil B retransmittere FIN. A må fortsatt være «levende» for å kunne svare — TIME_WAIT sikrer det.
2. Forsinket «sen» segment: Et gammelt segment fra denne forbindelsen kan fortsatt være underveis i nettet. Hvis port-paret gjenbrukes umiddelbart for en ny forbindelse, kan det gamle segmentet bli forvekslet med et legitimt nytt. 2·MSL gir tid til at alle gamle segmenter dør ut (TTL utløper).

c) Halv-lukket TCP-forbindelse:

Etter at A har sendt FIN, kan B fortsatt sende data til A (B→A-retningen er åpen). Dette er nyttig når B trenger å fullføre overføring av data den allerede holdt på med, før den selv lukker. Klassisk eksempel: A sender en HTTP-forespørsel og «shut-downer» send-siden for å signalisere at forespørselen er ferdig — B kan fortsette å sende svaret før den lukker B→A.

Pensum: Kap. 3 — TCP-forbindelsesstyring

a) DNS-problem:

Siden ping 8.8.8.8 (direkte IP) virker, fungerer både IP-laget og ICMP. Problemet er på applikasjonsnivå: DNS-oppslag av navnet feiler. Mulige årsaker: feil DNS-server konfigurert, DNS-server nede, ingen Internett-tilgang for DNS, lokal hosts-fil-feil, eller blokkering av port 53.

b) Hop 7 viser «* * *»:

Tre vanlige forklaringer:

• Ruteren på hop 7 svarer ikke på ICMP Time Exceeded — mange rutere er konfigurert til ikke å sende ICMP til kilden, eller raterbegrenser slike svar. Pakken videresendes likevel, og hop 8 svarer.
• Brannmur/ACL filtrerer utgående ICMP fra denne ruteren.
• Asymmetrisk routing: svarpakken tar en annen vei tilbake der den blir filtrert.

Det at hop 8 og videre svarer, viser at trafikken faktisk passerer hop 7 — det er bare ICMP-svaret som mangler.

c) ICMP-typer i ping/traceroute, og hvorfor blokkere:

Ping bruker ICMP Echo Request (type 8) og venter Echo Reply (type 0). Traceroute sender pakker med stadig økende TTL (1, 2, 3, …). Når TTL utløper hos en ruter, sender den ICMP Time Exceeded (type 11) tilbake til kilden — slik kartlegges hver hop. Når pakken når destinasjonen, returneres typisk ICMP Echo Reply (Linux/Unix) eller ICMP Port Unreachable (type 3) (klassisk Unix-traceroute som bruker UDP til ubrukt port).

Hvorfor noen blokkerer ICMP:

• Fortåen at ICMP avslører nettverksstruktur og letter rekognosering før et angrep.
• Beskytte mot ICMP-baserte DoS-angrep (smurf, ping flood).
• Skjule eksistensen av interne rutere/verter.

Ulempen er at PMTU Discovery slutter å virke (Path MTU baseres på «Fragmentation Needed»-meldinger), feilsøking blir vanskeligere, og noen ICMP-meldinger er nyttige for transport-/applikasjonslag.

Pensum: Kap. 5 — ICMP og diagnostikk

a) WEP → WPA → WPA2:

WEP (1999) brukte RC4 med en kort 24-bits IV som inngikk i krypteringsnøkkelen. IV-rommet var lite nok til at IV-er ble gjenbrukt i et travelt nett — dette gjorde det mulig å gjenfinne nøkkelen via statistisk analyse. Mangler også reell integritetssikring (CRC32 er ikke kryptografisk).

WPA (2003) var en overgangsløsning som la til TKIP — fortsatt RC4, men med per-pakke-nøkkel og MIC for integritet. Hindret WEP-spesifikke angrep men hadde fortsatt RC4-svakheter.

WPA2 (2004) bruker AES i CCMP-modus — moderne, godt analysert blokkchiffer. Dette er fortsatt den mest utbredte standarden, og er sikker mot klassiske krypteringsangrep når PSK-en er sterk. WPA3 (2018) løser i tillegg svakheten i punkt c).

b) 4-veis handshake formål og nonce:

Begge sider deler PSK fra før. Handshaken etablerer en sesjons-spesifikk PTK (Pairwise Transient Key) ved å kombinere PSK med to nonces — én fra AP (ANonce) og én fra klient (SNonce) — pluss begge MAC-adresser. Hver sesjon får dermed unik nøkkel selv om PSK-en er den samme. Handshaken bekrefter også implisitt at begge sider faktisk kjenner PSK-en (ellers feiler integritetssjekken på meldingene).

c) Offline brute-force og motvirkning:

Angriperen som har fanget 4-veis handshake har MAC-adressene, nonces og MIC-verdiene (alle sendt i klartekst utenom kryptering). Med en gjettet PSK kan angriperen lokalt regne ut hva PTK og MIC ville blitt, og sammenligne med det observerte. Dette er rask offline regning — millioner av forsøk per sekund med GPU.

Motvirkning: bruk lange, tilfeldige passord (24+ tegn) eller bytt til WPA3 som bruker SAE (Simultaneous Authentication of Equals) — en passord-autentisert nøkkelutvekslings-protokoll som er resistent mot offline brute-force.

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

a) Klassifisering — krav per klasse:

Klasse	Forsinkelse	Jitter	Tap
Streaming stored video	Sekunder OK ved oppstart; langt mindre kritisk under avspilling pga. stor klient-buffer	Bufferen jevner ut	TCP retransmitterer; akseptabelt så lenge bufferen ikke tømmes
Conversational (VoIP/videosamtale)	Strengt: < 150 ms én vei foretrukket, > 400 ms ubrukelig	Lav toleranse — adaptiv playout-buffer trenger fortsatt små buffer	Tåler 1–10 % tap med god koding/FEC
Streaming live (sport, nyheter)	Mellom: typisk 5–30 sek forsinkelse aksepteres for stabil avspilling	Bufferen reduserer påvirkning	TCP-basert (HLS/DASH): retransmisjon brukes

b) FEC og interleaving:

FEC sender ekstra (redundant) informasjon med talepakkene slik at en mottaker kan rekonstruere innholdet selv om noen pakker mangler. Et enkelt eksempel: send en lavkvalitets backup-versjon av forrige pakke i hver ny pakke. Kostnad: økt båndbreddebruk (typisk +20–50 %).

Interleaving «sprer» samples utover flere pakker i en kjent rekkefølge. Hvis én pakke går tapt, mangler kun spredte samples — ikke et sammenhengende segment. Resulterende «hull» er korte og mer estetisk akseptable. Kostnad: økt forsinkelse fordi mottakeren må vente på flere pakker før de kan re-arrangeres.

FEC og interleaving brukes ofte sammen.

c) CDN-valg via DNS:

YouTube-videoens URL slås opp i DNS. CDN-leverandøren har autoritative DNS-servere som svarer dynamisk basert på hvem som spør. Når den lokale DNS-serveren i Norge gjør oppslaget, ser CDN-DNS-en på:

• Geografisk plassering av spørrende DNS-server (omtrent kjent via IP-prefikset).
• Nettverkstopologi — hvilken CDN-node er nærmest i AS-hops/RTT.
• Belastning og tilgjengelighet — om noden er nede eller overbelastet, velg en annen.

CDN returnerer en IP til en optimalisert node — kanskje fysisk i Oslo eller Stockholm. Klienten kobler seg dit, ofte uten at brukeren merker forskjellen.

Resultatet: lavere RTT, mindre belastning på opprinnelsesserveren, og bedre robusthet ved feil i én node.

Pensum: Kap. 9 — Multimedia og CDN