Øvingseksamen 6

Riktig svar: B

Transportlaget (TCP/UDP) har som hovedoppgave å bringe data mellom prosesser på to verter. Den bruker portnumre som «adresse» til prosessene, slik at flere applikasjoner samtidig kan dele samme IP-adresse — det kalles multipleksering (sender-side) og demultipleksering (mottaker-side).

A er nettverkslaget (ruting), C er lenkelaget, og D er en applikasjonslag-tjeneste (DNS).

Pensum: Kap. 1 — Protokollstakken og lagansvar

Riktig svar: C — Fiber til hjemmet

FTTH/PON gir typisk symmetriske eller nær-symmetriske rater i hundrevis av Mbps eller flere Gbps i hver retning. ADSL er asymmetrisk og har lav uplink (typisk < 1 Mbps), kabel-modem har høyere downlink enn uplink og er delt i nabolaget, og 56k-modem er obsolet.

Felles for alle: kapasiteten er en kombinasjon av fysisk medium (kobber/koaks/fiber/luft) og delingsstrategi (dedikert/delt med naboer).

Pensum: Kap. 1 — Aksessnett

Riktig svar: B

HTTP-forespørselens første linje kalles request line og består av tre felter:

• Metode: GET, POST, HEAD, PUT, DELETE osv.
• URL/sti: ressursen som ønskes (f.eks. /index.html)
• HTTP-versjon: typisk HTTP/1.1 eller HTTP/2

Status line (alternativ A) er svarets første linje: HTTP/1.1 200 OK. Header lines kommer etter request/status line og inneholder kolon-separerte felt-par. Body inneholder selve dataene.

Pensum: Kap. 2 — HTTP-meldingsformat

Riktig svar: A

En A-record kobler et hostnavn direkte til en IPv4-adresse. AAAA (quad-A) gjør det samme for IPv6.

En CNAME-record (Canonical Name) er et alias — den peker fra ett domenenavn til et annet. Et oppslag på www.eksempel.no som er en CNAME til eksempel-prod.cdn-leverandor.no gjør at klienten må slå opp CNAME-målet for å få den endelige IP-adressen.

CNAME brukes mye sammen med CDN-er, der CDN-leverandøren styrer hvilken faktisk IP brukeren skal få basert på geografi/last.

Pensum: Kap. 2 — DNS-recordtyper

Riktig svar: B

DevRTT estimerer hvor mye SampleRTT typisk avviker fra EstimatedRTT (en glidende absoluttverdi-avstand). Formelen er:

DevRTT = (1 − β) · DevRTT + β · |SampleRTT − EstimatedRTT| (typisk β = 0,25)

TimeoutInterval blir da EstimatedRTT pluss 4 ganger DevRTT — en sikkerhetsmargin som er stor i ustabile nettverk og liten i stabile. Hadde man brukt en fast timeout, ville den enten blitt for liten (mange falske retransmisjoner) eller for stor (sen reaksjon på reelle tap).

Pensum: Kap. 3 — Beregning av timeout og RTT

Riktig svar: B

AIMD = Additive Increase, Multiplicative Decrease. I congestion avoidance-fasen øker cwnd med 1 MSS per RTT (additiv økning) — dette gir lineær vekst. Når et tap oppdages via tre dupliserte ACK-er (TCP Reno), halveres cwnd til cwnd/2 (multiplikativ reduksjon).

Resultatet er den karakteristiske sagtanngrafen: gradvis økning, plutselig halvering, gradvis økning igjen — om og om igjen. Dette mønsteret er også grunnlaget for at flere TCP-flyt deler kapasitet relativt rettferdig.

A beskriver slow start (eksponentiell). Ved timeout går cwnd faktisk helt ned til 1 MSS — men det er ikke AIMD, det er den mer drastiske reaksjonen TCP tar ved timeout.

Pensum: Kap. 3 — AIMD og TCP congestion control

Riktig svar: B

Routing tilhører kontrollplanen: rutere utveksler informasjon (link-state, distance-vector, BGP) og beregner hvilke veier som finnes til alle destinasjoner. Resultatet er forwarding-tabellen i hver ruter. Dette er en relativt langsom og periodisk prosess.

Forwarding tilhører dataplanen: når en pakke ankommer en ruter, slås destinasjonsadressen opp i forwarding-tabellen, og pakken videresendes på riktig utgangsport. Dette må skje i hardware-hastighet — millioner av pakker per sekund.

Pensum: Kap. 4 — Forwarding vs. routing

Riktig svar: B

IPv6-headeren er forenklet sammenlignet med IPv4: fast lengde 40 byte, færre felt, og ingen header-checksum (overlater integritet til underliggende lag og transportlag). Fragmenteringsfelt er fjernet fra hovedheaderen — kilde-vert må selv finne minste MTU langs ruten (Path MTU Discovery) og lage pakker som passer.

IPv4-headeren er minst 20 byte (med opsjoner mer), har Identification/Flags/Fragment Offset til ruterfragmentering, og en checksum som rutere må oppdatere ved hver hop (TTL endres).

Begge protokoller har et hop-limit-felt — kalt TTL i IPv4 og «Hop Limit» i IPv6.

Pensum: Kap. 4 — IPv4 vs. IPv6

Riktig svar: A

ICMP Redirect (type 5) sendes av en ruter til en vert på samme subnett når ruteren oppdager at verten har valgt en suboptimal første-hop. Eksempel: vert sender pakke til R1, men R1 ser at en annen ruter R2 (også på samme subnett) er nærmere destinasjonen. R1 videresender pakken som vanlig, men sender også en ICMP Redirect til verten med beskjed om å bruke R2 ved fremtidige pakker til samme destinasjon.

I praksis er ICMP Redirect ofte slått av eller filtrert bort av sikkerhetsgrunner — en angriper kunne bruke den til å omdirigere trafikk gjennom en kompromittert ruter.

Pensum: Kap. 5 — ICMP-meldingstyper

Riktig svar: C

Når en switch ikke har en oppføring for destinasjons-MAC-adressen, gjør den flooding: rammen kopieres ut på alle porter unntatt innkommende. Dermed når rammen frem til destinasjonen uansett hvor på switch-fabrikken den befinner seg.

Når destinasjonen svarer (eller når kilden senere blir destinasjon), lærer switchen MAC↔port-koblingen og legger til en oppføring i tabellen. Da slipper man å flode senere.

Switchen lærer altså kilde-MAC fra alle innkommende rammer (port hvor de ankom) og bruker tabellen for å finne destinasjon-MAC.

Pensum: Kap. 6 — Self-learning switches

Riktig svar: B — ca. 1/e ≈ 0,37

I slotted ALOHA er tiden delt i diskrete tidsluker, og hver stasjon kan kun starte sending ved begynnelsen av en luke. Sannsynligheten for vellykket sending (én og bare én stasjon prøver i en gitt luke) maksimeres når totalbelastningen er N·p = 1, og maksimal effektivitet blir 1/e ≈ 0,37.

Til sammenligning: ren (unslotted) ALOHA, der stasjoner kan starte når som helst, har maks effektivitet 1/(2e) ≈ 0,18 — halvparten av slotted, fordi kollisjonsvinduet er dobbelt så langt.

Pensum: Kap. 6 — ALOHA og random access

Riktig svar: B

Klient og AP deler en pre-shared key (PSK), men sender den aldri direkte. 4-way handshake utveksler tilfeldige nonces, og begge sider kombinerer disse med PSK lokalt for å utlede en sesjonsnøkkel (PTK — Pairwise Transient Key) som brukes til å kryptere all trafikk i sesjonen.

Hver sesjon får dermed en unik nøkkel — selv om en angriper i ettertid skulle få tak i PSK, kan ikke gamle, lagrede sesjoner dekrypteres uten nonce-verdiene. Dette er ikke perfekt forward secrecy, men gir en viss isolasjon mellom sesjoner.

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

Riktig svar: B

En application-layer gateway opererer på applikasjonslaget og forstår protokollen som passerer (HTTP, SMTP, FTP osv). Den kan filtrere basert på reelt innhold — f.eks. blokkere visse URL-er, fjerne vedlegg av visse typer, eller skjule interne brukernavn fra utgående trafikk.

Sammenlignet med en pakkefilter-brannmur (alternativ A) som kun ser IP/port: en application gateway gir mye finere kontroll, men er tregere og mer komplisert (én proxy per protokolltype).

Pensum: Kap. 8.9 — Brannmurtyper

Riktig svar: C

Konversasjonell sanntid (telefoni, videokonferanse): forsinkelseskrav er strengt — over ca. 200 ms én vei føles samtalen unaturlig. Klient kan ikke bygge opp stor buffer fordi det ville innført ekstra latens.

Lagret video-streaming: brukeren venter typisk noen sekunder på oppstart, og klienten kan buffre 10–30 sekunder med video for å absorbere jitter og kortvarig båndbreddevariasjon. Brukeropplevelsen domineres av om avspillingen pauser («rebuffering»), ikke av strikt ende-til-ende-forsinkelse.

Begge bruker typisk UDP-baserte transporter (RTP for sanntid, eller HTTP/TCP-basert i adaptive streaming som DASH). Begge bruker variable bitrate-kodinger.

Pensum: Kap. 9 — Multimedia-applikasjonsklasser

a) Trafikkintensitet ρ = L·λ / R:

L = 1 000 byte = 8 000 bits. R = 10 Mbps = 10⁷ bps.

For λ = 1 000 pakker/s: ρ = 8 000 × 1 000 / 10⁷ = 8 × 10⁶ / 10⁷ = 0,8

For λ = 1 250 pakker/s: ρ = 8 000 × 1 250 / 10⁷ = 10⁷ / 10⁷ = 1,0

b) Kurven ρ vs. køforsinkelse:

For små ρ (under ca. 0,5) er køforsinkelsen tilnærmet null — pakker passerer rett gjennom uten ventetid. Når ρ nærmer seg 1, vokser køforsinkelsen svært raskt (asymptotisk mot uendelig). Karakteristisk «hockeystick»-form: nesten flat lenge, så plutselig bratt.

Grunnen: selv om gjennomsnittlig last er under kapasitet, oppstår sporadiske kødannelser pga. tilfeldige ankomstmønstre. Når ρ er liten, hentes køen raskt igjen i ledige perioder. Når ρ → 1, er det ingen ledig kapasitet til å «hente igjen», så små ankomstvariasjoner akkumuleres.

c) ρ > 1 over tid:

Hvis ankomstraten varig overstiger linkkapasiteten (ρ > 1), vokser køen i prinsippet ubegrenset. I praksis er bufferen begrenset, så pakker droppes (tail drop). Dette signaliserer congestion til endesystemene (TCP), som reduserer sendraten — og bringer systemet tilbake mot ρ ≤ 1.

Stor buffer: færre tap, men høyere kø-forsinkelse (bufferbloat). Liten buffer: lav latens, men flere tap. En realistisk dimensjonering balanserer disse.

Pensum: Kap. 1 — Trafikkintensitet og køforsinkelse

a) Beregning steg for steg:

Etter SampleRTT = 110 ms:

• EstimatedRTT = 0,875 · 100 + 0,125 · 110 = 87,5 + 13,75 = 101,25 ms
• |110 − 100| = 10. DevRTT = 0,75 · 20 + 0,25 · 10 = 15 + 2,5 = 17,5 ms

Etter SampleRTT = 95 ms:

• EstimatedRTT = 0,875 · 101,25 + 0,125 · 95 = 88,59 + 11,875 ≈ 100,47 ms
• |95 − 101,25| = 6,25. DevRTT = 0,75 · 17,5 + 0,25 · 6,25 = 13,125 + 1,5625 ≈ 14,69 ms

Etter SampleRTT = 130 ms:

• EstimatedRTT = 0,875 · 100,47 + 0,125 · 130 ≈ 87,91 + 16,25 ≈ 104,16 ms
• |130 − 100,47| ≈ 29,53. DevRTT = 0,75 · 14,69 + 0,25 · 29,53 ≈ 11,02 + 7,38 ≈ 18,40 ms

TimeoutInterval = 104,16 + 4 · 18,40 ≈ 104,16 + 73,60 ≈ 177,8 ms

b) Hvorfor ikke måle RTT for retransmitterte segmenter:

Når et segment er sendt på nytt og en ACK kommer inn, vet senderen ikke om ACK-en gjelder originalen (som da ble forsinket) eller retransmisjonen. Hvis den var en sen ACK for originalen, vil målt SampleRTT være kunstig høy (inkluderer hele timeout-perioden). Hvis det er ACK for retransmisjonen, vil SampleRTT være kort. I begge tilfeller er målingen tvetydig og kan trekke estimatet feil vei.

Karn's algorithm: ignorér SampleRTT for alle segmenter som har blitt retransmittert minst én gang.

c) Eksponentiell backoff:

En timeout antyder at nettverket allerede er overbelastet. Hvis senderen umiddelbart sender på nytt med samme timeout, kan den bidra til å holde overbelastningen ved like (TCP-sløyfe). Dobling av TimeoutInterval gir nettverket tid til å «hente seg inn» og unngår overdrevne retransmisjonsstormer.

Pensum: Kap. 3 — RTT-estimering, Karn's algorithm

a) Aggregat for /24-er 16, 17, 18, 19:

Skriv tredje oktett binært:

• 16 = 00010000
• 17 = 00010001
• 18 = 00010010
• 19 = 00010011

Felles 6 første bits: 000100. De siste 2 bitene varierer over alle 4 kombinasjoner. Tredje oktett må altså matche prefikset 000100xx (6 bits faste).

Prefikslengde totalt = 16 (de første to oktettene 200.10) + 6 (felles bits i tredje oktett) = /22.

Aggregat: 200.10.16.0/22. Dekker 200.10.16.0 – 200.10.19.255.

b) Kan vi inkludere 200.10.20.0/24?

20 binært i tredje oktett = 00010100. Skal vi dekke 200.10.16, 17, 18, 19, 20 må prefikset også matche 20. Et /22 dekker bare 16–19 (binært 0001 00xx). For å inkludere 20, må vi gå opp til /21 → 000100xx 1 bit kortere, men /21 dekker 16–23 (0001 0xxx) — det inkluderer 20, 21, 22, 23 også. Hvis ISP-en ikke eier 21, 22, 23, vil aggregatet «utgi seg for» å dekke adresser ISP-en ikke har — andre prefikser fra resten av Internett kan kollidere.

Konklusjon: 20 kan ikke inkluderes i et minimalt aggregat sammen med 16–19 uten å ta med flere /24-er enn ISP-en eier. Den må annonseres som separat /24 eller man må vente til 21–23 også er ISP-ens.

c) Hvorfor CIDR-aggregering er viktig:

Uten aggregering ville hver eneste /24 i Internett kreve en oppføring i kjerneruterens forwarding-tabell. Det ville vært titalls millioner oppføringer — for treigt og for dyrt. Med CIDR kan en ISP annonsere én /20 i stedet for 16 separate /24-er, og kjerneruterne får én oppføring i stedet for 16. Dette er essensielt for at BGP-ruterne i Internetts kjerne skal klare seg med ca. 1 million oppføringer i stedet for 100+ ganger flere.

Pensum: Kap. 4 — CIDR og hierarkisk adressering

a) Tabell etter hver ramme:

Steg	Aksjon i switch	Tabell etter steg
1: A → B	Lærer aa:aa på P1. Destinasjon bb:bb er ukjent → flooder ut på P2, P3, P4.	aa:aa → P1
2: B → A	Lærer bb:bb på P2. Destinasjon aa:aa er kjent → videresender kun ut på P1.	aa:aa → P1, bb:bb → P2
3: D → C	Lærer dd:dd på P4. Destinasjon cc:cc er ukjent → flooder ut på P1, P2, P3.	aa:aa → P1, bb:bb → P2, dd:dd → P4
4: C → A	Lærer cc:cc på P3. Destinasjon aa:aa er kjent → videresender kun ut på P1.	aa:aa → P1, bb:bb → P2, cc:cc → P3, dd:dd → P4

b) Læring fra kilde, videresending fra destinasjon, og aging:

Logikken er trygg: kilde-MAC i en ramme forteller pålitelig hvilken port som leder til den verten (rammen kom faktisk inn på den porten). Switchen kan dermed bruke det videre når en annen vert sender til samme MAC.

Aging trengs fordi verter kan flyttes (kobles om til en annen port) eller slås av. Uten aging-timer ville en gammel oppføring sende rammer til feil port — eller ut på en port der verten ikke lenger finnes. Typisk aging-tid: noen minutter.

Pensum: Kap. 6 — Self-learning switches

a) Sertifikatvalidering:

Et X.509-sertifikat inneholder bl.a. domenenavn (CN/SAN), serverens offentlige nøkkel, gyldighetsperiode og en signatur fra en utstedende sertifikatmyndighet (CA).

Validering steg for steg:

1. Domenematch: Nettleseren sjekker at domenet i URL (nettbank.no) matcher CN/SAN i sertifikatet.
2. Gyldighetsperiode: Sjekkes mot dagens dato.
3. Signaturkjede: Sertifikatet er signert av en CA. Det kan være en mellomliggende CA («intermediate CA»), som igjen er signert av en root CA. Nettleseren bygger kjeden tilbake til en CA hvis sertifikat ligger i nettleserens/operativsystemets trust store (rotsertifikatlager).
4. Verifisere signatur: Hver signatur i kjeden verifiseres med utsteder-CA-ens offentlige nøkkel. Til slutt valideres rotsertifikatet — det er selv-signert og tillates fordi det allerede er installert som «klarert».

Hvis kjeden brytes (mangler ledd, ugyldig signatur, ukjent rot), avviser nettleseren forbindelsen.

b) CRL og OCSP:

Et sertifikat kan kompromitteres før gyldighetsperioden er ute (privat nøkkel lekket, organisasjonen avvikles). Det må da tilbakekalles.

• CRL (Certificate Revocation List): CA-en publiserer en liste over tilbakekalte sertifikater. Klienter kan laste ned CRL-en og sjekke om sertifikatet er på listen.
• OCSP (Online Certificate Status Protocol): Klienten spør CA-en direkte om status for dette ene sertifikatet — raskere enn å laste ned hele CRL-en.

Problem som løses: en angriper med en stjålet, men fortsatt-tidsgyldig privat nøkkel kan ikke bruke sertifikatet etter tilbakekall.

c) DASH og adaptiv videostreaming:

MPD-manifestet (Media Presentation Description, en XML-fil) lister tilgjengelige kvalitetsversjoner av videoen — typisk 240p, 480p, 720p, 1080p, 4K — og hvilke små chunks (typisk 2–10 sek) som finnes for hver versjon, med URL-er.

Klienten måler kontinuerlig hvor raskt forrige chunk ble lastet ned (oppnådd båndbredde) og hvor mye buffer som er igjen. Eksempel: dersom klienten har 30 sek i bufferen og siste chunk gikk i 8 Mbps, kan den be om en 1080p-versjon ved neste chunk. Faller bufferen mot 5 sek pga. nedgang til 3 Mbps, byttes neste chunk til en lavere kvalitet (480p) for å unngå at avspillingen stopper.

MPD-ens rolle: gi klienten en katalog med alle alternativer, slik at klienten kan ta valget lokalt — uten serverens involvering. Dermed skalerer DASH bra (CDN cacher chunks, ingen state per klient), og klienten kan reagere raskt på endrede forhold.

Pensum: Kap. 8 — Sertifikater, TLS · Kap. 9 — DASH