Øvingseksamen 3

Riktig svar: B — 10 ms

Formel: d_prop = d / s = 2 000 × 10³ m / 2 × 10⁸ m/s = 10⁻² s = 10 ms

Propagasjonsforsinkelse avhenger kun av distansen og signalhastigheten i mediet — ikke av pakkestørrelse eller linkkapasitet. Dette er en viktig forskjell fra transmisjonsforsinkelse.

Pensum: Kap. 1 — Propagasjonsforsinkelse

Riktig svar: B

Lagdeling gir to hovedfordeler: modularitet (hvert lag kan utvikles, oppdateres eller byttes ut uavhengig av nabolagene, så lenge tjenestegrensesnittet er konstant) og abstraksjon (et lag trenger ikke vite detaljer om implementasjonen i lagene over og under).

Faktisk gir lagdeling overhead — hver header tar ekstra bytes — men gevinsten i utviklingsenkelhet og skalerbarhet er stor. Internett kunne ikke evolvert uten denne modulariteten (vurder f.eks. overgangen fra 802.3-koaks til 802.11 — applikasjoner trenger ikke endres).

Pensum: Kap. 1 — Lagdelt arkitektur

Riktig svar: D — MX

MX-records (Mail eXchange) brukes til å peke et domene til e-postservere som mottar e-post for det domenet, sammen med en prioritetsverdi.

Record	Funksjon
A	Domenenavn → IPv4-adresse
AAAA	Domenenavn → IPv6-adresse
CNAME	Domenenavn → annet domenenavn (alias)
NS	Domenenavn → autoritativ navneserver
MX	Domenenavn → mailserver med prioritet

Pensum: Kap. 2 — DNS resource records

Riktig svar: D — denne påstanden er feil

En web-cache kan tvert imot servere foreldede versjoner av en side hvis ressursen har blitt oppdatert siden cachen lagret den. For å redusere risikoen for foreldede svar, bruker HTTP conditional GET (med If-Modified-Since): cachen spør serveren "har dette endret seg siden tidspunkt T?". Hvis ikke, svarer serveren 304 Not Modified uten å sende selve dataen. Caching-headere som Cache-Control: max-age styrer hvor lenge cachen kan beholde et svar uten å sjekke.

A, B og C er alle reelle fordeler.

Pensum: Kap. 2 — Web-cache og conditional GET

Riktig svar: B

I GBN kvitterer mottakeren bare den siste i-rekkefølge-pakken. Når pakke 2 går tapt og pakke 3, 4, 5 ankommer ut av rekkefølge, forkaster mottakeren disse og resender en kumulativ ACK for sist mottatte i-rekkefølge-pakke (her: ACK 1, dvs. "alt opp til og med 1 er mottatt"). Senderen oppdager etter timeout for pakke 2 at noe er galt og retransmitterer alle pakkene fra og med pakke 2 — derav navnet "Go-Back-N".

Dette er enklere å implementere enn Selective Repeat, men kan være ineffektivt fordi pakker som kom frem må sendes på nytt.

Pensum: Kap. 3 — Go-Back-N

Riktig svar: B

UDP er en upålitelig (best-effort) transportprotokoll. Hvis checksum ikke stemmer, kastes datagrammet uten varsel — ingen retransmisjon, ingen NAK. Det er opp til applikasjonslaget å oppdage og håndtere tap (eller akseptere det).

Dette skiller UDP klart fra TCP, som ville forsøkt å reparere problemet via retransmisjon.

(Merk: UDPs checksum brukes til deteksjon av feil, ikke korreksjon. Den dekker pseudoheader + UDP-header + payload.)

Pensum: Kap. 3 — UDP og checksum

Riktig svar: C — DHCP Discover

DHCP-prosessen har fire steg (DORA):

1. Discover — klient sender broadcast: "Finnes det en DHCP-server her?"
2. Offer — DHCP-server svarer med en IP-adresse og parametre
3. Request — klient bekrefter ønsket tilbud (broadcast så andre servere vet at deres tilbud kan slippes)
4. ACK — server bekrefter tildelingen

Klienten har ingen IP ennå og må derfor bruke broadcast (255.255.255.255) som destinasjon — vanlig unicast-adressering ville kreve en gateway å sende gjennom.

Pensum: Kap. 4 — DHCP

Riktig svar: B — 3 fragmenter

MTU = 1500 byte er maksimum total pakkestørrelse, inkludert IP-header på 20 byte. Hver fragment kan da inneholde maksimalt 1500 − 20 = 1480 byte med data fra det opprinnelige IP-payloadet. Dessuten må fragment-payload være delelig på 8 (ettersom Fragment Offset-feltet teller i 8-byte-enheter), så maksimum payload per fragment er 1480 byte (delelig på 8 ✓).

Opprinnelig payload: 4000 − 20 = 3980 byte. Trengs 3980 / 1480 = 2,69 → 3 fragmenter.

Fragment	Payload	Offset	MF-flagg
1	1480 byte	0	1 (mer kommer)
2	1480 byte	185 (1480/8)	1 (mer kommer)
3	1020 byte	370	0 (siste)

Pensum: Kap. 4 — IPv4-fragmentering

Riktig svar: B

Eksempel: A — B — C, med kostnad 1 mellom A–B og 1 mellom B–C. Hvis link A–B bryter: B oppdager dette, men B har fortsatt en gammel oppføring fra C som sa "jeg kan nå A med kostnad 2 (via B)". B oppdaterer derfor til "jeg kan nå A med kostnad 3 via C". Når B annonserer til C, oppdaterer C til 4. Slik vandrer kostnaden oppover én linje av gangen — "counting to infinity" — istedenfor å konvergere raskt.

Løsninger: poisoned reverse (annonser ∞ tilbake til naboen som ruter via deg) og forskjellige hold-down/split-horizon-strategier.

Pensum: Kap. 5 — Distance-vector og count-to-infinity

Riktig svar: B

Hver ruter dekrementerer TTL med 1. Når TTL går fra 1 til 0, forkastes pakken og ruteren sender en ICMP "Time Exceeded"-melding (type 11) tilbake til opprinnelig avsender. Dette beskytter mot uendelige rutings-løkker.

traceroute utnytter dette ved å sende en sekvens av prøvepakker med TTL = 1, deretter 2, deretter 3 osv. Den første ruteren returnerer Time Exceeded for TTL = 1, den andre for TTL = 2, og så videre. Dermed kartlegges ruten hop for hop.

Pensum: Kap. 5 — ICMP og traceroute

Riktig svar: B

En svitsj opererer i lenkelaget (Layer 2). Den ser kun MAC-adresser og videresender rammer innenfor ett broadcast-domene (LAN/subnett). En svitsj endrer ikke pakke-headere — kun rammen for fysisk overføring.

En ruter opererer i nettverkslaget (Layer 3). Den ser IP-adresser, gjør routing-beslutninger basert på forwarding-tabellen, dekrementerer TTL og bytter ut MAC-headeren for neste link.

Rutere segmenterer broadcast-domener — broadcasts (f.eks. ARP) krysser ikke en ruter med mindre konfigurert (DHCP-relay).

Pensum: Kap. 6 — Svitsj vs. ruter

Riktig svar: B

Radiosignaler avtar med minst kvadratet av avstanden i fritt rom (free-space path loss ∝ 1/d²). Inne i bygninger er fall-off ofte enda raskere på grunn av vegger, multipath fading og refleksjoner — i typiske kontormiljøer regnes ofte med 1/d³ eller mer.

Dessuten varierer signalstyrken med tiden på grunn av interferens fra andre 2,4/5 GHz-kilder (mikrobølger, Bluetooth, andre WiFi-nett). Dette er et grunnleggende skille fra kabelnettverk og er årsaken til at trådløse linker har høyere bitfeilrate og krever lenkelags-ACK.

Pensum: Kap. 7 — Trådløse linker og signaltap

Riktig svar: B

En digital signatur lages slik:

1. Alice beregner et meldingsdigest h = H(M) med en kryptografisk hashfunksjon (f.eks. SHA-256). Dette gir en kort, fast lengde uavhengig av M.
2. Alice krypterer h med sin private nøkkel: signatur = KA−(h).
3. Alice sender (M, signatur) til Bob.
4. Bob beregner H(M) selv, dekrypterer signaturen med Alices offentlige nøkkel og sjekker at de to verdiene matcher.

Dette gir både integritet (manipulasjon endrer hash-verdien) og autentisering (kun Alice har den private nøkkelen). Hashfunksjonen er nødvendig fordi offentlig nøkkel-operasjoner er trege på lange meldinger.

Pensum: Kap. 8 — Digitale signaturer og hash

Riktig svar: B

Jitter er variasjonen i nettverksforsinkelse mellom påfølgende pakker — noen pakker kommer raskere, andre tregere, fordi køforsinkelsen varierer. For sanntids lyd/video må pakkene spilles av med jevn rytme.

Playout-bufferen utsetter avspillingen med en liten konstant forsinkelse (typisk 50–400 ms for VoIP). Pakkene som ankommer "for tidlig" venter i bufferen; pakker som kommer "for sent" (etter playout-tidspunktet) anses som tapt og forkastes.

Trade-off: stor buffer ⇒ mer robust mot jitter, men mer ende-til-ende forsinkelse ⇒ vanskeligere samtale. Adaptive playout-bufferalgoritmer justerer størrelsen dynamisk basert på målt jitter.

Pensum: Kap. 9 — Playout-buffer og jitter i VoIP

Konvensjon: Vi regner RTT-er fra klientens klokke. TCP-handshake bruker 1 RTT (SYN/SYN-ACK før klienten kan sende GET). HTTP-request + svar bruker ytterligere 1 RTT.

a) Non-persistent uten parallell:

To objekter (HTML + bilde), hvert med eget TCP-handshake og GET:

• HTML: 1 RTT (handshake) + 1 RTT (GET/respons) = 2 RTT
• Bilde: 1 RTT (handshake) + 1 RTT (GET/respons) = 2 RTT

Total: 4 RTT = 4 × 100 ms = 400 ms

b) Non-persistent, 2 parallelle TCP:

HTML hentes først (klienten må parse den for å vite om bildet): 1 RTT handshake + 1 RTT GET = 2 RTT. Deretter åpnes 2 TCP-er parallelt; men det er bare ett bilde, så:

• HTML: 2 RTT
• Bilde: 2 RTT (1 handshake + 1 GET)

Total: 400 ms (parallellitet hjelper bare når flere objekter henvises). Fordelen ville vært synlig med 5 bilder (samme tid som 3 sekvensielle objekter pga. parallellitet).

c) Persistent HTTP med pipelining:

Én TCP-handshake (1 RTT). Deretter sendes GET for HTML (svar etter 1 RTT). Klienten parser HTML og sender umiddelbart GET for bildet på samme forbindelse — bildet kommer 1 RTT senere. (Med ekte pipelining kunne klienten sendt begge GET-er samtidig dersom bildets URL var kjent på forhånd, men her må klienten først motta HTML.)

Total: 1 RTT (handshake) + 1 RTT (HTML) + 1 RTT (bilde) = 3 RTT = 300 ms

Pensum: Kap. 2 — HTTP RTT-analyse

a) Sammenligning:

	Stop-and-Wait	Go-Back-N	Selective Repeat
Vindu (sender)	1	N (alle pakker innen vinduet kan være ute)	N
Vindu (mottaker)	1	1 (forventer kun neste i-rekkefølge)	N (buffer ut-av-rekkefølge-pakker)
ACK	Per pakke	Kumulativ — siste i-rekkefølge	Selektiv — én per mottatt pakke
Ved tap	Timeout → resend	Timeout → resend hele vinduet fra tapet	Timeout → resend kun den manglende pakken
Kompleksitet	Lavest	Middels	Høyest (mer buffring og logikk)

b) Stop-and-Wait utnyttelse:

Transmisjonstid: t_trans = L/R = 8 000 / 10⁶ = 8 ms

Total tid for én pakke + ACK: t_trans + RTT = 8 + 30 = 38 ms

Utnyttelse U = t_trans / (t_trans + RTT) = 8 / 38 ≈ 0,21 (21 %)

Senderen er i tomgang i 79 % av tiden — venter på ACK. På høy-RTT-lenker (f.eks. satellitter, transatlantiske linker) blir utnyttelsen enda dårligere, derfor brukes pipelined protokoller med vindu N >> 1.

c) GBN vs. SR ved høy RTT og høy tapsrate:

SR er bedre. Ved høy RTT er hver retransmisjon dyr (krever en RTT til). GBN må retransmittere alle pakker fra den tapte og fremover, selv pakker som allerede har kommet frem — det forsterker problemet ved høy tapsrate. SR retransmitterer kun de tapte pakkene og buffer mottakerne kan beholde fremtidige pakker som er kommet frem. Trade-off: SR krever mer minne og mer kompleks logikk hos mottakeren.

Pensum: Kap. 3 — Pålitelig dataoverføring, Stop-and-Wait/GBN/SR

a) traceroute-prosess:

1. Klienten sender en pakke (UDP til en uutilgjengelig port — eller ICMP Echo Request avhengig av implementasjon) med TTL = 1 mot destinasjonen.
2. Den første ruteren langs ruten dekrementerer TTL til 0, forkaster pakken og returnerer en ICMP Time Exceeded-melding (type 11). Klienten ser kilde-IP til denne meldingen — det er ruterens IP. RTT for hopet måles.
3. Klienten sender en ny pakke med TTL = 2. Andre ruter returnerer Time Exceeded.
4. Prosessen gjentas til pakken endelig når destinasjonen. Når destinasjonen mottar pakken på en uutilgjengelig UDP-port, svarer den med ICMP Destination Unreachable: Port Unreachable. Det er signalet for at sluttdestinasjonen er nådd, og klienten avslutter.

b) Hvorfor tre prøver per TTL?

Tre prøver gir robusthet mot enkeltpakketap og lar verktøyet vise variasjon i RTT for det aktuelle hopet. Hvis én av tre svarer, har vi fortsatt informasjon om hvem ruteren er.

c) Mulige årsaker til "* * *":

1. Ruteren er konfigurert til ikke å svare med ICMP (rate-limiting eller policy — vanlig for sikkerhetspolicy/brannmurer).
2. Pakketap i den aktuelle hopet på det øyeblikket — alle 3 prøver gikk tapt.
3. (Andre gyldige svar: ruteren er overbelastet og svarer langsommere enn timeoutgrensen; brannmur dropper enten utgående eller innkommende ICMP.)

Pensum: Kap. 5 — ICMP og traceroute

a) Minste prefikslengde:

Krav verter	Trenger 2n−2 ≥ verter	Hostbit n	Prefiks	Adresser totalt
60	26−2 = 62 ✓	6	/26	64
28	25−2 = 30 ✓	5	/27	32
12	24−2 = 14 ✓	4	/28	16
5	23−2 = 6 ✓	3	/29	8

b) Tildeling fra 192.168.40.0/24, største først:

#	Behov	Subnett	Brukbart	Broadcast
1	60	192.168.40.0/26	.40.1 – .40.62	192.168.40.63
2	28	192.168.40.64/27	.40.65 – .40.94	192.168.40.95
3	12	192.168.40.96/28	.40.97 – .40.110	192.168.40.111
4	5	192.168.40.112/29	.40.113 – .40.118	192.168.40.119

Resterende ledig adresseplass: 192.168.40.120/29 til 192.168.40.255.

c) Adresser i pakken/rammen:

Subnett 1 og subnett 3 er forskjellige — pakken må gjennom (minst) én ruter. Anta én default gateway G som har et interface i hvert subnett. Senderens IP = S, mottakerens IP = D.

Sted	IP src	IP dst	MAC src	MAC dst
Forlater sender	S	D	MACS	MACG,subnett1
Ankommer mottaker	S	D	MACG,subnett3	MACD

IP-adressene (S og D) endres ikke fra ende til ende. MAC-adressene byttes ut for hver lenke — i lenkelaget er det neste nodes MAC som teller. Ruteren bruker ARP for å finne MAC-en i hver retning.

Pensum: Kap. 4 — VLSM · Kap. 6 — MAC vs. IP, ARP

a) Sikker e-post (PGP-aktig):

Alice gjør:

1. Beregner H(M) av meldingen M, og signerer: signatur = KA−(H(M)) — dette gir autentisering og integritet.
2. Lager en symmetrisk sesjonsnøkkel K_S (tilfeldig, kun for denne meldingen).
3. Krypterer (M, signatur) med K_S — gir konfidensialitet.
4. Krypterer K_S med Bobs offentlige nøkkel: KB+(KS) — slik at bare Bob kan lese den.
5. Sender begge til Bob: {KS(M, signatur), KB+(KS)}.

Bob gjør:

1. Dekrypterer K_S med sin private nøkkel.
2. Bruker K_S til å dekryptere (M, signatur).
3. Beregner H(M) og dekrypterer signaturen med Alices offentlige nøkkel — sjekker at de matcher. Match ⇒ meldingen er autentisk og uforandret.

b) Hvorfor symmetrisk for innholdet?

Asymmetrisk kryptografi (RSA, ElGamal, ECC) er flere størrelsesordener tregere enn symmetrisk. For lange meldinger ville det være upraktisk. Hybridtilnærmingen — bruk asymmetrisk til å sikre nøkkeldistribusjonen, deretter symmetrisk for selve dataen — gir både ytelse og sikkerhet.

c) Hashfunksjonens egenskaper:

1. Kollisjonsresistens — det skal være praktisk umulig å finne to ulike meldinger M ≠ M' med H(M) = H(M'). Hvis ikke, kunne en angriper laget en alternativ melding med samme hash som en lovlig signert melding.
2. Preimage-resistens — gitt h, skal det være praktisk umulig å finne M slik at H(M) = h. (Også: andre-preimage-resistens — gitt M, skal det være vanskelig å finne M' ≠ M med H(M) = H(M').)
3. (Andre egenskaper: rask å beregne, stort utgangsrom slik at brute-force er upraktisk.)

Pensum: Kap. 8 — Sikker e-post, hash, digitale signaturer