Øvingseksamen · TTM4100

Øvingseksamen 4

Del I: 14 flervalgsoppgaver (42 poeng). Del II: 5 åpne oppgaver (58 poeng). Totalt 100 poeng. Settet vektlegger trafikkintensitet, RTT-estimering, longest prefix matching, og brannmurer/IPSec/RTP.

Temaer i dette settet
  • Køforsinkelse, trafikkintensitet og pakketap (kap. 1)
  • Cookies og rekursive vs. iterative DNS-spørringer (kap. 2)
  • TCP RTT-estimering og fast retransmit (kap. 3)
  • Longest prefix matching, IP-header og TTL (kap. 4)
  • Link-state-rutingens generelle ide (kap. 5)
  • CRC og lenkelagets feildeteksjon (kap. 6)
  • WiFi-assosiering og rammeformat (kap. 7)
  • IPSec, VPN og brannmurer (kap. 8)
  • RTP og sanntidsstrømming (kap. 9)

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

En ruter mottar pakker med snittrate L · a, og linkraten ut er R. Trafikkintensiteten ρ = La/R brukes som mål på køoppførsel. Hva skjer når ρ > 1?

  • A Køen er alltid tom og pakker går rett gjennom uten forsinkelse
  • B Køen vokser uten øvre grense og pakker vil før eller siden tapes
  • C Pakker repliseres for å øke ende-til-ende-gjennomstrømning
  • D Linkraten økes automatisk for å håndtere overskudd
Vis fasit
Riktig svar: B

Når ρ > 1 ankommer pakker raskere enn linken kan sende dem ut. Køen vokser ubegrenset i et idealisert system; i realiteten har køen en endelig størrelse, så når den fylles, må nye pakker droppes — dette er pakketap pga. køoverflyt.

Når ρ er nær 1 (men < 1) er køforsinkelsen sterkt voksende — derfor er det viktig å designe nettverk slik at gjennomsnittlig ρ holdes godt under 1.

Pensum: Kap. 1 — Trafikkintensitet og kø

Spørsmål 2 3 poeng Kap. 2

Hvordan brukes cookies typisk i en nettløsning?

  • A For å la HTTP unngå nye TCP-handshakes mellom klient og server ved senere forespørsler
  • B For at HTTP skal kunne holde tilstand: serveren gir en unik ID som klienten returnerer ved hvert kall
  • C For å erstatte DNS-oppslag og slik gjøre lasting av nettsider raskere på klienten
  • D For å kryptere brukernavn og passord før de sendes over nettet til serveren
Vis fasit
Riktig svar: B

HTTP er tilstandsløs i seg selv. For at en server skal kunne "huske" en pålogget bruker eller en handlekurv, sender den en cookie med Set-Cookie-headeren ved første respons. Klienten lagrer cookien og inkluderer den i Cookie-headeren på alle senere forespørsler til samme domene. Serveren bruker cookien som nøkkel inn i sin egen sesjonsdatabase.

Cookies handler altså om tilstand på applikasjonsnivå — de påvirker ikke TCP-laget, ikke DNS, og er ikke en krypteringsmekanisme.

Pensum: Kap. 2 — Cookies

Spørsmål 3 3 poeng Kap. 2

Hva er forskjellen mellom rekursive og iterative DNS-spørringer?

  • A Rekursiv: serveren returnerer enten endelig svar eller en henvisning videre. Iterativ: serveren tar fullt ansvar for å finne svaret
  • B Rekursiv: serveren tar fullt ansvar for å finne det endelige svaret. Iterativ: serveren returnerer enten svaret eller en henvisning til neste server som spørreren selv må kontakte
  • C Rekursiv brukes bare i offline DNS, iterativ bare online
  • D Rekursiv DNS bruker UDP, iterativ DNS bruker TCP
Vis fasit
Riktig svar: B

I en rekursiv spørring sier spørreren: "finn ut svaret for meg uansett hvor mye arbeid det krever". Den lokale DNS-resolveren tar typisk imot rekursive spørringer fra klienter og gjør hele jobben.

I en iterativ spørring sier spørreren: "gi meg det beste svaret du har akkurat nå". Hvis den spurte serveren ikke vet svaret, returnerer den en henvisning (referral) til en annen server som spørreren må gå videre til selv. Iterativ er det vanlige mønsteret mellom rotservere → TLD → autoritative servere.

Pensum: Kap. 2 — DNS rekursiv vs. iterativ

Spørsmål 4 3 poeng Kap. 3

TCP estimerer RTT med EstimatedRTT = (1 − α) · EstimatedRTT + α · SampleRTT. Hva er hovedformålet med formelen?

  • A Garantere at hver enkelt RTT-måling er millisekundnøyaktig, slik at TCP kan reagere på enhver forsinkelse
  • B Glatte ut tilfeldige variasjoner og gi en stabil verdi som timeoutverdien (RTO) kan bygges på
  • C Eliminere helt RTT-bidraget på lange linker ved å trekke fra propageringsforsinkelsen i α-leddet
  • D Tillate sender å overstige rwnd når den estimerte RTT-en er stabil over flere målinger
Vis fasit
Riktig svar: B

Formelen er et eksponensielt veid glidende gjennomsnitt (EWMA) — den gir mye vekt til historiske verdier (1 − α) og mindre vekt til den nyeste prøven (α, typisk 0,125). Dette filtrerer bort enkeltmålinger som er ekstreme (f.eks. en pakke som tilfeldigvis sto lenge i kø).

I tillegg estimeres RTT-variasjon (DevRTT). Selve TCP-timeouten settes til RTO = EstimatedRTT + 4 · DevRTT — robust nok til å unngå unødvendige retransmisjoner, men kort nok til å reagere raskt ved reelle tap.

Pensum: Kap. 3 — RTT-estimering i TCP

Spørsmål 5 3 poeng Kap. 3

Hva er en fast retransmit i TCP?

  • A Sender venter på en bevisst forkortet RTO og retransmitterer alle utestående segmenter samtidig for å gjenopprette flyten raskt
  • B Sender retransmitterer det manglende segmentet etter 3 duplicate ACKs uten å vente på timeout
  • C Sender øker cwnd raskere enn vanlig slow start tillater ved å doble vinduet for hver mottatte ACK
  • D Mottakeren sender et eksplisitt negativ-ACK (NAK) direkte til sender med sekvensnummeret som mangler
Vis fasit
Riktig svar: B

Når mottakeren får ut-av-rekkefølge-segmenter, gjentar den den siste gyldige ACK-verdien. Hvis senderen ser tre duplikate ACK-er — det vil si fire totalt med samme verdi (1 original + 3 dupliserte) — tolker den dette som et sterkt signal om at neste segment er tapt, og retransmitterer umiddelbart uten å vente på at RTO går ut.

Fast retransmit reduserer ventetiden ved tap betydelig på lenker med høy RTT.

Pensum: Kap. 3 — Fast retransmit

Spørsmål 6 3 poeng Kap. 4

En ruter har følgende oppføringer i forwarding-tabellen:
10.0.0.0/8 → port 1
10.20.0.0/16 → port 2
10.20.32.0/20 → port 3
Hvilken port brukes for destinasjonsadressen 10.20.34.10?

  • A Port 1
  • B Port 2
  • C Port 3
  • D Adressen matcher ingen oppføringer
Vis fasit
Riktig svar: C — Port 3

10.20.34.10 matcher alle tre prefiks: /8, /16 og /20. Longest prefix match velger den lengste — /20 → port 3.

Sjekk /20: 10.20.32.0/20 dekker fra 10.20.32.0 til 10.20.47.255. 10.20.34.10 ligger innenfor → match. Den mest spesifikke ruten vinner.

Pensum: Kap. 4 — Longest prefix matching

Spørsmål 7 3 poeng Kap. 4

Hva representerer feltet TTL (Time to Live) i en IPv4-pakke?

  • A Maksimal tid pakken kan eksistere, målt i sekunder
  • B Maksimum antall rutere/hopp pakken kan passere før den forkastes
  • C Antall ganger pakken kan retransmitteres
  • D Levetiden til TCP-forbindelsen pakken tilhører
Vis fasit
Riktig svar: B

Til tross for navnet "Time to Live" er TTL implementert som en hop counter. Hver ruter dekrementerer den med 1 — ikke med en faktisk tidsmåling. Når TTL går fra 1 til 0, forkastes pakken og avsenderen får en ICMP Time Exceeded.

Formålet er å hindre at pakker sirkulerer for evig i ruting-løkker (f.eks. midlertidige feilkonfigureringer i ruting-protokoller).

Pensum: Kap. 4 — IPv4-header og TTL

Spørsmål 8 3 poeng Kap. 5

I en link-state-protokoll: hvilken algoritme brukes typisk for å beregne korteste vei fra én ruter til alle andre, gitt full topologi-informasjon?

  • A Bellman-Ford
  • B Dijkstra
  • C Floyd-Warshall
  • D Round-robin
Vis fasit
Riktig svar: B — Dijkstra

Når en ruter har full oversikt over topologien (alle lenker og kostnader), beregner den korteste vei til hver destinasjon med Dijkstras algoritme. Algoritmen er en grådig algoritme som steg for steg utvider mengden av noder med kjent korteste vei.

Bellman-Ford ligger bak distance-vector-protokoller. Floyd-Warshall beregner korteste vei mellom alle par — overkill for en enkelt ruters behov.

Pensum: Kap. 5 — Link-state-ruting

Spørsmål 9 3 poeng Kap. 6

CRC (Cyclic Redundancy Check) brukes i lenkelaget for feildeteksjon. Hvilken påstand er riktig om CRC?

  • A CRC kan rette opp alle feil som oppdages, så lenge generatorpolynomet er lengre enn feilburst-en
  • B CRC oppdager alle enkeltbitsfeil og typisk burst-feil opp til en gitt lengde, men kan ikke rette opp feilene
  • C CRC krypterer payload med en nøkkel utledet av generatorpolynomet og motvirker dermed avlytting
  • D CRC brukes kun i transportlaget (TCP/UDP-checksum), aldri i lenkelagsrammer som Ethernet eller WiFi
Vis fasit
Riktig svar: B

CRC er en kraftig feildeteksjonsmekanisme — basert på polynomdivisjon i GF(2). Med en valgt generatorpolynom på r+1 bits oppdager CRC alle enkeltbits-feil, alle dobbelbits-feil (gitt riktig generator), alle burst-feil av lengde ≤ r, og en stor andel andre feilmønstre.

Men CRC er kun deteksjon, ikke korreksjon — ved feil må rammen kastes og enten retransmitteres eller ignoreres avhengig av lag/policy. (Forward Error Correction, f.eks. Reed-Solomon, brukes der korreksjon trengs uten retransmisjon.)

Pensum: Kap. 6 — Feildeteksjon og CRC

Spørsmål 10 3 poeng Kap. 7

Hva er den korrekte rekkefølgen når en ny WiFi-enhet kobles til et 802.11-aksesspunkt (typisk hjemmenett)?

  • A Authentication → Association → DHCP → ARP
  • B DHCP → Authentication → Association → ARP
  • C ARP → Authentication → Association → DHCP
  • D DHCP → ARP → Authentication → Association
Vis fasit
Riktig svar: A

Tilkoblingsprosessen i 802.11:

  1. Skanning: enheten finner aksesspunkter via beacon-frames eller probe requests.
  2. Authentication: en lenkelagshandshake mellom enhet og AP (med eller uten kryptografisk autentisering, f.eks. WPA2/WPA3-EAPOL-handshake).
  3. Association: enheten "hekter seg på" AP — enheten er nå offisielt en del av BSS-en.
  4. DHCP: enheten henter IP-adresse og parametre. Krever at lenkelagsnivå er klart.
  5. ARP kommer først når enheten skal sende sin første pakke til en annen vert (typisk gateway).

De første tre stegene er alle på lenkelaget i 802.11. DHCP og ARP kjører oppe på IP- / applikasjonsnivå.

Pensum: Kap. 7 — WiFi-assosiering

Spørsmål 11 3 poeng Kap. 8

Hva er forskjellen mellom transport mode og tunnel mode i IPSec?

  • A Transport mode bruker AES-kryptering ende-til-ende, mens tunnel mode kun gir integritetsbeskyttelse uten konfidensialitet av nyttelasten
  • B Transport mode beskytter kun payload (originale IP-headere bevares); tunnel mode innkapsler hele IP-pakken inni en ny IP-pakke (vanlig i VPN)
  • C Transport mode brukes utelukkende mellom rutere i kjernenettet, mens tunnel mode kun aktiveres når en sluttbruker kobler seg på fra hjemmenett
  • D Tunnel mode kapsler IPSec inn i UDP for NAT-traversering, mens transport mode alltid kjører over TCP for pålitelig nøkkelutveksling
Vis fasit
Riktig svar: B

I transport mode beskyttes kun payload (TCP/UDP-segmentet) av IPSec, mens originale IP-headere er synlige. Brukes typisk vert-til-vert.

I tunnel mode innkapsles hele den originale IP-pakken (inkludert headere) i en ny IP-pakke. Den ytre headeren brukes for ruting mellom IPSec-gateways. Dette er det vanlige modus for VPN (site-to-site eller klient-til-site), fordi det skjuler den interne nettstrukturen og lar private adresseområder traversere offentlig nett.

Pensum: Kap. 8 — IPSec og VPN

Spørsmål 12 3 poeng Kap. 8

Hvilken av følgende er ikke en oppgave for en tradisjonell pakkefilter-brannmur (stateless firewall)?

  • A Tillate eller blokkere trafikk basert på kilde- og destinasjons-IP-adresser
  • B Tillate eller blokkere trafikk basert på TCP/UDP-port
  • C Tillate eller blokkere trafikk basert på IP-protokollnummer (TCP, UDP, ICMP …)
  • D Inspisere og forstå applikasjonsdata, som å oppdage en bestemt phishing-URL i en HTTP-request
Vis fasit
Riktig svar: D

En tradisjonell pakkefilter-brannmur opererer på pakke-headere — IP-adresser, porter, protokollnummer, flagg (f.eks. SYN/ACK). Den ser ikke inn i applikasjonsinnholdet.

For å inspisere applikasjonsinnhold trengs en application gateway (proxy) eller en deep packet inspection (DPI)-løsning. Pensum nevner application gateway som en separat kategori.

Pensum: Kap. 8 — Brannmurer (pakkefilter, stateful, application gateway)

Spørsmål 13 3 poeng Kap. 9

Hva er hovedfunksjonen til RTP (Real-time Transport Protocol)?

  • A Garantere pålitelig levering av lyd- og videopakker ved å legge til retransmisjon og flytkontroll, akkurat som TCP gjør for filoverføring
  • B Tilføre headerfelt som sekvensnummer, tidsstempel og payload-type for sanntidsstrømmer (kjører typisk over UDP)
  • C Erstatte IP for sanntidsapplikasjoner med en egen pakkeformat optimalisert for lav jitter på operatørnettverk
  • D Kryptere lyd- og videostrømmer ende-til-ende ved hjelp av en innebygd nøkkelutveksling før mediet sendes
Vis fasit
Riktig svar: B

RTP gir en standard rammeverk for å transportere sanntids medie-data. Headeren inneholder bl.a.:

  • Sekvensnummer — for å oppdage tap og rekkefølgefeil
  • Tidsstempel — for å re-synkronisere medie-strømmer hos mottaker (avgjørende for jitter-buffer og A/V-sync)
  • Payload type — angir kodeken (PCM, Opus, H.264 osv.)
  • SSRC — identifikator for kilden i en multipart-strøm

RTP gir ikke pålitelig levering eller QoS — det er opp til underliggende lag og applikasjonen. RTP kjører typisk over UDP for å unngå TCPs retransmisjoner som ville økt forsinkelsen.

Pensum: Kap. 9 — RTP

Spørsmål 14 3 poeng Kap. 9

Hvorfor brukes UDP — og ikke TCP — typisk for VoIP-trafikk?

  • A UDP gir innebygd ende-til-ende-kryptering av nyttelasten, mens TCP sender alle lydpakker i klartekst over nettet
  • B UDP er den eneste transportprotokollen som garanterer pålitelig levering av sanntidsmedia uten tap eller duplikater
  • C UDP unngår retransmisjoner og congestion-relaterte forsinkelser; en sterkt forsinket lydpakke er ubrukelig uansett
  • D UDP har større headere som reserverer mer plass til kvalitetsmetadata og dermed gir bedre lydopplevelse
Vis fasit
Riktig svar: C

VoIP er sanntid: en lydpakke som kommer 300+ ms for sent er bortkastet — den hadde uansett ikke kunnet spilles av. TCP ville prioritert pålitelighet og retransmittert tapte segmenter, men det medfører ekstra RTT(er) og blokkering av etterfølgende data (head-of-line blocking) — uakseptabelt for sanntid.

UDP slipper denne overheaden. Eventuell pakketap håndteres av audio-kodeken (skjules ved interpolering eller redundans) eller aksepteres som kvalitetsfall.

Pensum: Kap. 9 — VoIP og valg av transport

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. 1 · 3

a) En TCP-forbindelse går mellom A og B. Banen har RTT 200 ms og flaskehalskapasitet 10 Mbps. Beregn båndbredde-forsinkelsesproduktet (BDP) i bits og i bytes. (3p)

b) For at TCP skal kunne fylle linjen i steady state, hvor stort må senderens vindu (uavhengig av rwnd / cwnd-detaljer) minst være? (2p)

c) Anta at mottakeren annonserer rwnd = 64 KB og cwnd er stor nok. Hva blir maksimalt oppnåelig gjennomstrømning, og hvorfor er den lavere enn 10 Mbps? (3p)

d) Foreslå én konkret tiltak (uten å bytte til en annen protokoll enn TCP) for å øke gjennomstrømningen. (2p)

Vis fasit

a) BDP:

BDP = kapasitet × RTT = 10 × 106 bps × 0,2 s = 2 × 106 bits = 2 000 000 bits

I bytes: 2 × 106 / 8 = 250 000 byte ≈ 244 KiB

b) Minimum vindu for å fylle linjen:

Senderen må kunne ha hele BDP i ukvitterte bytes underveis: vindu ≥ BDP = 250 000 byte. Hvis vinduet er mindre, blir senderen tomgangsbegrenset (vinduet "tømmes" før første ACK kommer tilbake).

c) Maks gjennomstrømning med rwnd = 64 KB:

Senderen begrenses til 64 KB ukvittert per RTT: 65 536 byte × 8 / 0,2 s = 2 621 440 bps ≈ 2,6 Mbps

Dette er bare ~26 % av flaskehalskapasiteten. Vinduet er for lite for stien — typisk problem på "long fat networks" (LFN).

d) Tiltak:

Aktivere TCP window scaling (RFC 1323) — en TCP-opsjon som lar rwnd-feltet effektivt være større enn 64 KB. (Andre gyldige svar: øke socket buffer-størrelser i applikasjonen, bruke flere parallelle TCP-forbindelser, redusere RTT med en CDN nærmere klienten.)

Pensum: Kap. 1 — Gjennomstrømning · Kap. 3 — TCP-vindu og BDP

Oppgave 2 15 poeng Kap. 4

En ISP har følgende forwarding-tabell i en kjerneruter:
10.0.0.0/8 → port 1
10.128.0.0/9 → port 2
10.130.0.0/15 → port 3
10.130.4.0/22 → port 4
0.0.0.0/0 → port 5 (default)

a) Skriv subnettmaske i dotted-decimal for hver oppføring. (4p)

b) Bruk longest prefix matching og bestem utgangsport for følgende destinasjoner. Begrunn for hver:

  • 10.10.20.30
  • 10.130.5.100
  • 10.130.10.5
  • 10.200.1.1
  • 172.16.0.1

(7p)

c) Beskriv kort hva som skjer i ruteren mellom å motta en pakke og å sende den ut igjen — inkludert IP-headerendringer. (4p)

Vis fasit

a) Subnettmasker:

PrefiksMaske
/8255.0.0.0
/9255.128.0.0
/15255.254.0.0
/22255.255.252.0
/00.0.0.0

b) Longest prefix matching:

  • 10.10.20.30 — matcher /8 (10.0.0.0–10.255.255.255). Ikke /9 (10.128.0.0–10.255.255.255 — utenfor 10.10.x.x). → port 1
  • 10.130.5.100 — matcher /8, /9 (10.128.0.0/9 dekker 10.128.0.0–10.255.255.255), /15 (10.130.0.0/15 dekker 10.130.0.0–10.131.255.255), /22 (10.130.4.0/22 dekker 10.130.4.0–10.130.7.255). Lengst: /22 → port 4
  • 10.130.10.5 — matcher /8, /9, /15, men ikke /22 (utenfor 10.130.4.0–10.130.7.255). Lengst: /15 → port 3
  • 10.200.1.1 — matcher /8, /9. Lengst: /9 → port 2
  • 172.16.0.1 — matcher kun /0 → port 5 (default)

c) Behandling i ruteren:

  1. Motta ramme på inngangsport, fjerne lenkelagshoder.
  2. Sjekke IP-headerintegritet (header checksum).
  3. Dekrementer TTL med 1. Hvis TTL = 0, forkast pakken og send ICMP Time Exceeded.
  4. Slå opp i forwarding-tabellen med longest prefix matching og finn utgangsport + neste-hop.
  5. Hvis nødvendig, fragmenter pakken hvis MTU på utgangslink er mindre enn pakkestørrelse (og DF-flagget ikke er satt).
  6. Beregn ny header checksum (siden TTL endret seg).
  7. Slå opp neste-hops MAC via ARP, bygg ny lenkelagsramme og send ut på utgangsporten.

Pensum: Kap. 4 — IP-forwarding

Oppgave 3 10 poeng Kap. 6 · 7

a) Forklar — gjerne i punkter — den fullstendige sekvensen av lenkelagsoperasjoner som skjer når en bærbar PC er nylig assosiert med et WiFi-aksesspunkt og skal sende sin første IP-pakke (etter at den har fått IP via DHCP) til en server på Internett. Anta at PC-ens IP-stakk allerede vet at pakken må gå via default gateway. (6p)

b) Hvorfor må PC-en kjenne til MAC-adressen til gatewayen og ikke til den endelige destinasjonen, selv om destinasjonens IP er målet? (4p)

Vis fasit

a) Sekvens av lenkelagsoperasjoner:

  1. Konstruere IP-pakken: kilde-IP = PC, destinasjon-IP = serverens IP.
  2. ARP-oppslag for gateway: PC-en sjekker sin ARP-cache. Hvis gatewayens MAC ikke er der, sender den en ARP Request som broadcast i 802.11-rammen (destinasjons-MAC = ff:ff:ff:ff:ff:ff). Aksesspunktet videresender broadcasten til alle andre i BSS-en, og gatewayen svarer med ARP Reply (unicast).
  3. CSMA/CA — vente på ledig medium: PC-en utfører carrier sense. Hvis mediet er ledig, venter PC-en DIFS + tilfeldig backoff (counts down i ledige slots, fryser ved opptatt medium).
  4. Send 802.11-ramme: payload = IP-pakken; mottaker-MAC i rammen = gatewayens MAC; rammen sendes til AP først (siden vi er i infrastrukturmodus).
  5. Vent på ACK fra AP: 802.11 har lenkelags-ACK. Hvis ingen ACK kommer innen SIFS-grensen, retransmitter PC-en (med eksponentiell backoff).
  6. AP videresender til gateway: AP-en mottar rammen, fjerner 802.11-rammen og videresender pakken (med ny lenkelagsramme om nødvendig) i retning av gatewayen.

b) Hvorfor MAC-adressen til gatewayen?

MAC-adresser er kun lokalt meningsfulle — de gjelder innenfor ett lenkelagsdomene (LAN/BSS). Serveren ute på Internett er ikke i samme broadcast-domene som PC-en. ARP-broadcasten ville aldri nådd serveren — den stoppes ved første ruter.

I lenkelagsrammen må mottaker-MAC være neste hop langs ruten — i dette tilfellet gatewayen. Pakken sendes da til gatewayen, som bytter ut MAC-headeren for sitt utgående interface og sender pakken videre. IP-adressene endres ikke (kilde- og destinasjons-IP forblir konstant ende til ende, modulo NAT), men lag-2-adressene byttes ut for hver lenke.

Dette er essensen av lagdeling: lag 2 vet ikke (og trenger ikke vite) noe om Internett-topologien — det er lag 3-arbeid.

Pensum: Kap. 6 — Lenkelagsramme og ARP · Kap. 7 — 802.11 sending

Oppgave 4 10 poeng Kap. 8

Du skal hjelpe en liten bedrift med å sikre nettet sitt. Bedriften har en webserver (port 80/443) i en DMZ, og interne ansatte skal kunne surfe på Internett (men ingen tjenester skal være eksponert utenfra mot det interne nettet).

a) Foreslå et sett med pakkefilter-brannmurregler som beskriver hva som skal slippes inn og ut. Bruk en tabell med felter som «retning», «protokoll», «kildeport/IP», «destinasjonsport/IP», «aksjon». Du trenger ikke skrive perfekt syntaks — det viktige er logikken. (5p)

b) Forklar hvorfor en stateful brannmur er bedre egnet enn en stateless ved at den kan implementere "established connections" enkelt og trygt. (3p)

c) Bedriften vil i tillegg gi hjemmekontorbrukere sikker tilgang til interne ressurser. Hvilken løsning anbefaler du, og hva oppnår man med den? (2p)

Vis fasit

a) Forslag til regler (anta tre soner: INSIDE, DMZ, OUTSIDE):

#RetningProtokollKildeDestinasjon (IP/port)Aksjon
1OUTSIDE → DMZTCPanyDMZ-server : 80, 443ALLOW
2DMZ → OUTSIDETCPDMZ-server : 80, 443any (etablerte svar)ALLOW
3INSIDE → OUTSIDETCP/UDPINSIDE-nettany : 80, 443, 53ALLOW
4OUTSIDE → INSIDEanyanyINSIDE-nettDENY
5DMZ → INSIDEanyDMZ-serverINSIDE-nettDENY
6 (default)anyanyanyanyDENY

Logikken: kun web-trafikk fra Internett til DMZ-serveren tillates inn. INSIDE-nett kan initiere utgående trafikk på vanlige porter (80, 443 = web; 53 = DNS). Alt annet er stengt — særlig viktig: INSIDE skal aldri være direkte målbar utenfra.

b) Stateful brannmur:

En stateful brannmur sporer aktive forbindelser i en tilstandstabell. Når en intern bruker initierer en forbindelse ut (f.eks. TCP-handshake til en webserver), legges forbindelsen i tabellen. Returpakker som tilhører den allerede etablerte forbindelsen slippes automatisk gjennom — uten å trenge en eksplisitt regel som åpner alle høye porter inn.

En stateless brannmur ville måtte tillate ALL trafikk inn på høye porter for at returtrafikk skulle nå tilbake — en stor sikkerhetsrisiko. Stateful brannmur ser også sammenhengen i protokollen (f.eks. at en ACK må følge et SYN) og kan oppdage uregelmessigheter.

c) Løsning for hjemmekontor:

En VPN-løsning basert på IPSec (tunnel mode) eller TLS-VPN (f.eks. OpenVPN). Hjemmebrukere oppretter en kryptert tunnel til selskapets VPN-gateway og får en intern IP-adresse. Trafikken til interne ressurser går da kryptert over Internett gjennom tunnelen. Dette gir konfidensialitet (kryptering), integritet (autentiseringskode) og autentisering (mutual auth ved sertifikater eller pre-shared keys), samtidig som interne ressurser ikke trenger å eksponeres direkte mot Internett.

Pensum: Kap. 8 — Brannmurer, IPSec og VPN

Oppgave 5 13 poeng Kap. 7 · 9

a) En 802.11-ramme har plass til opptil fire MAC-adressefelt, mens en Ethernet-ramme har bare to. Forklar hvorfor 802.11 trenger flere — bruk infrastrukturmodus (BSS med AP) som eksempel og beskriv hvilke adresser som settes når en stasjon i BSS-en sender til en mottaker utenfor BSS-en. (5p)

b) En sanntids-VoIP-strøm har sendrate 64 kbps og pakkeintervall på 20 ms. Hvor stor er hver lyd-payload (i byte)? Hva slags problemer kan oppstå hvis det er stor jitter på linjen, og hvordan kan en adaptiv playout-buffer håndtere dette? (5p)

c) Forklar hvorfor RTP-tidsstemplet er viktig nettopp for sanntidsstrømmer — i hvilke situasjoner brukes det, og hva ville skjedd uten? (3p)

Vis fasit

a) Hvorfor fire adressefelt i 802.11?

I infrastrukturmodus passerer all trafikk via aksesspunktet. Når stasjon A i BSS-en sender til en host R utenfor BSS-en, må rammen inneholde:

  • Address 1 (Receiver): MAC-adressen til neste lenkelagsmottaker = AP (BSSID).
  • Address 2 (Transmitter): MAC til den som faktisk sender rammen = A.
  • Address 3 (final endpoint i lenkelaget): MAC til ruteren / gatewayens interface som ligger innenfor samme broadcast-domene som AP — dvs. neste hop ut av LAN-et.
  • Address 4: brukes kun i ad-hoc / WDS / mesh-konfigurasjoner (når trafikk vandrer mellom flere AP-er på 802.11-nivå). I infrastrukturmodus er den ikke i bruk.

I Ethernet er det enklere: src og dst MAC er nok fordi Ethernet ikke har en "mellomstasjon" som AP — svitsjen forwarder transparent uten å manipulere headeren.

b) VoIP-payload og jitter:

Sendrate × intervall = bits per pakke = 64 000 bps × 0,020 s = 1 280 bits = 160 byte per lyd-payload. (Pluss header for RTP/UDP/IP/lenkelag, men spørsmålet gjaldt payload.)

Stor jitter betyr at noen pakker ankommer mye senere eller tidligere enn forventet. Konsekvenser uten håndtering: pause/glipp i avspilling (manglende pakke ved playout-tidspunkt), eller tap av rytme. Adaptiv playout-buffer håndterer dette ved at:

  • Pakkene legges i en buffer ved ankomst og spilles av med en konstant forsinkelse p målt fra senders tidsstempel.
  • Verdien av p justeres adaptivt — hvis jitter er høy, økes p; hvis lav, kan p reduseres for å minske ende-til-ende-forsinkelse.
  • Justering skjer fortrinnsvis i pauser mellom snakketurer (talkspurts) for at brukeren ikke skal merke det.

c) Hvorfor RTP-tidsstempel?

Tidsstemplet representerer tidspunktet for samples i opprinnelseskilden — ikke tiden pakken ble sendt. Dette lar mottakeren:

  1. Spille av lyden med konsistent rytme uavhengig av nettverks-jitter (ankomstrekkefølge eller -tidspunkt har ingen direkte avhengighet av samples-tiden).
  2. Synkronisere flere medie-strømmer (f.eks. lyd + video).

Uten RTP-tidsstempel måtte mottaker ha gjettet samples-tider basert på ankomsttid, noe som ville gitt unaturlig avspilling under jitter eller tap.

Pensum: Kap. 7 — 802.11-rammeformat · Kap. 9 — RTP og playout-buffer