Prediksjon 2 — «Wireshark-hullet»

Riktig svar: B

Klientens neste seq er A+1 (siden SYN-flagget bruker ett sekvensnummer selv om det ikke er data). Klienten bekrefter serverens SYN ved å sette ack = B+1.

Etter denne ACK-en er forbindelsen etablert, og begge sider har allokert buffere. Server-buffere allokeres typisk allerede ved SYN-ACK (sårbarhet for SYN-flooding).

Pensum: Kap. 3 — TCP-handshake

Riktig svar: B

ARP oversetter IP → MAC innen ett subnett. Request: «hvem har IP X?» sendes som broadcast. Reply: «jeg er X, MAC er Y» sendes som unicast tilbake til avsenderen. Resultatet caches.

A er DNS sin jobb. C er feil — alle hosts har ARP-tabell. D er feil — ARP er begrenset til ett subnett.

Pensum: Kap. 6 — ARP

Riktig svar: B

Hierarkiet er Root → TLD → autoritativ. Root-tjenerne (13 logiske) kjenner TLD-tjenerne. TLD-tjeneren for .no kjenner autoritative tjenere for hver registrert domene. Den autoritative tjeneren for ntnu.no svarer med IP-adressen.

Lokal resolver gjør ofte rekursive spørringer på vegne av klienten og cacher resultatet basert på TTL.

Pensum: Kap. 2 — DNS-hierarki

Riktig svar: C

Hvis dest-MAC peker på samme port som rammen kom inn på, vil mottaker uansett ha sett rammen direkte på det delte segmentet — å sende den ut igjen ville bare doblet trafikken. Svitsjen forkaster den.

Dette er en del av self-learning + filtrering som gjør svitsjer plug-and-play og effektive.

Pensum: Kap. 6 — Switch self-learning

Riktig svar: D

TCP oppdager tap (via duplikat-ACKer eller timeout) og responderer ved å redusere cwnd, men det forårsaker ikke tap. De fire klassiske tap-årsakene er: (1) bitfeil, (2) buffer-overflyt, (3) lenke- eller node-feil, (4) kollisjon i delt media.

Pensum: Kap. 1

Riktig svar: B

De tre brannmur-kategoriene er: (1) traditional/stateless packet filter (per pakke, ACL på adresser/porter/flagg), (2) stateful packet filter (sporer aktive forbindelser via TCP-flagg-sekvenser → kan lukke ned «orphan»-trafikk), (3) application gateway (per applikasjon, terminerer trafikken og inspiserer applikasjonsdata).

Pensum: Kap. 8.9 — Brannmurer

Riktig svar: B

TCP-headeren har port-numre (kilde/dest), ikke IP-adresser. IP-adresser legges på i nettverkslaget der TCP-segmentet selv blir payload i et IP-datagram. Tilsvarende blir IP-datagrammet selv payload i en lenkelag-ramme der MAC-adressene står.

Dette er kjernen i kapsling — hvert lag adderer egne adresser/headere uten å vite om lagene under.

Pensum: Kap. 3 · Kap. 1 — Kapsling

Riktig svar: B

UDP-fordeler: ingen håndtryk-forsinkelse, mindre header (8 byte vs 20), ingen tilstand på server, ingen retransmisjon (gammel data er ofte ubrukelig i sanntid). Klassiske UDP-applikasjoner: DNS (små svar), VoIP/spill (sanntid), DHCP (broadcast før IP er tildelt).

Bank, e-post og filoverføring krever pålitelighet og bruker TCP.

Pensum: Kap. 3.3 — UDP

Riktig svar: B

Signal-asymmetrien (sendt >> mottatt) gjør at NIC-en knapt kan «høre» andres samtidige sending. I tillegg er kollisjonen som teller den hos mottaker — og pga skjult terminal og fading kan ikke sender alltid se den. Derfor brukes collision avoidance + eksplisitte ACK-er: hver vellykket data-ramme bekreftes; manglende ACK ⇒ retransmisjon.

Pensum: Kap. 7 — CSMA/CA

Riktig svar: B

Avsender krypterer (typisk en hash av meldingen) med egen privat nøkkel. Hvem som helst kan verifisere ved å dekryptere med avsenders offentlige nøkkel. Hvis dekrypteringen produserer riktig hash, vet vi at meldingen kommer fra eieren av den private nøkkelen og ikke har blitt endret.

For å vite at den offentlige nøkkelen virkelig tilhører avsender, kreves et sertifikat signert av en betrodd tredjepart (CA).

For store meldinger signeres en kryptografisk hash, ikke meldingen selv — av hastighetsgrunner.

Pensum: Kap. 8.3 — Digital signatur

Riktig svar: B

Slow start: cwnd dobles hver RTT (eksponentiell). Når cwnd ≥ ssthresh, går TCP over til congestion avoidance (additive increase) hvor cwnd øker med 1 MSS per RTT. Ved tap (timeout eller 3 dup-ACK) settes ssthresh = cwnd/2 og cwnd resettes (timeout) eller halveres (fast recovery).

Pensum: Kap. 3.7 — TCP congestion control

Riktig svar: B

Infrastructure: AP-en gir ofte også DHCP/DNS/ruting til kabelnett. Ad hoc (også kalt IBSS): noder snakker peer-to-peer uten AP, og må selv ta ansvar for oppslag og ruting i nettet.

Pensum: Kap. 7.3 — 802.11 arkitektur

Riktig svar: A

Dette er flytkontroll (flow control): en ende-til-ende-mekanisme som beskytter mottakerens buffer mot overflyt. Mottaker annonserer ledig plass via rwnd-feltet i ACK; sender begrenser den uavbestilte byte-mengden til min(cwnd, rwnd).

Forveksles ofte med congestion control (D-typen) — som handler om nettverk, ikke mottaker.

Pensum: Kap. 3.5 — Flow control

Riktig svar: D

Best effort gir ingen garantier — verken for levering, rekkefølge, forsinkelse eller båndbredde. Det betyr i praksis at TCP, applikasjonslaget eller link-laget må kompensere for ønsket kvalitet.

Pensum: Kap. 4 — IP best effort

a) DNS-oppslag for innsida.ntnu.no:

PC-en spør lokal DNS-resolver (annonsert via DHCP). Hvis resolveren ikke har cache-treff:

1. Resolver spør en root-tjener: «hvor er .no?» → får henvisning til .no TLD-tjenere.
2. Resolver spør en .no TLD-tjener: «hvor er ntnu.no?» → får henvisning til autoritative tjenere for ntnu.no.
3. Resolver spør den autoritative tjeneren: «hva er innsida.ntnu.no?» → får tilbake en A-record med IPv4-adressen (eller AAAA for IPv6).

Klienten mottar resultatet via et enkelt UDP-svar fra lokal resolver.

Caching: Lokal resolver lagrer svaret med en TTL (typisk minutter–timer). Senere oppslag på samme navn besvares fra cache uten å spørre hierarkiet — gir kraftig latens­reduksjon og avlaster autoritative tjenere.

b) TCP 3-veis håndtrykk:

1. SYN (klient → server): klient setter SYN=1, velger tilfeldig sekvensnummer A. Sier «jeg vil opprette en forbindelse, mitt seq starter på A».
2. SYN-ACK (server → klient): server setter SYN=1, ACK=1, velger eget sekvensnummer B, setter ack=A+1. Server allokerer buffere og sier «ja, jeg går med på dette, mitt seq starter på B, jeg har sett din SYN».
3. ACK (klient → server): klient setter ACK=1, ack=B+1, seq=A+1. Klient allokerer buffere. Forbindelsen er etablert i begge retninger.

Formål: Synkronisere sekvensnumre i begge retninger, bekrefte at begge sider er villige til å kommunisere, allokere buffere og kontrollvariabler.

c) TLS over TCP:

Etter TCP-håndtrykket utveksler klient og server et TLS-handshake. Server sender sitt X.509-sertifikat, signert av en betrodd CA, som binder serverens identitet til en offentlig nøkkel. Klienten verifiserer signatur­kjeden mot sin CA-rot.

Ved hjelp av offentlig nøkkel-kryptografi utveksles en symmetrisk sesjonsnøkkel. Selve HTTP-trafikken krypteres deretter med denne symmetriske nøkkelen (mye raskere enn offentlig kryptografi for store mengder data).

d) Tap av første HTTP-segment:

Server mottar aldri segmentet, så ingen ACK kommer tilbake. Klient venter på ACK; etter RTO (retransmission timeout — basert på estimert RTT med Karns/Jacobsons algoritme) sender klienten segmentet på nytt. Hvis duplikate ACK-er hadde dukket opp (3 dup-ACK), kunne fast retransmit ha skjedd raskere.

Etter tapet vil TCP-overbelastningskontrollen redusere cwnd (timeout: tilbake til 1, ssthresh = forrige cwnd/2).

Pensum: Kap. 2.4 — DNS · Kap. 3 — TCP · Kap. 8.6 — TLS

a) Self-learning:

Tabellen lagrer oppføringer av formen (MAC-adresse, port, tidsstempel). Når en ramme ankommer port p:

1. Les kilde-MAC. Oppdater tabellen: oppføringen (kilde-MAC, p, nå) legges til (eller eksisterende oppdateres). Dette er læringen.
2. Slå opp dest-MAC i tabellen:
   • (i) Ikke i tabell: ramme videresendes til alle porter unntatt inngangsporten — flooding.
   • (ii) I tabell, peker mot annen port: ramme sendes selektivt ut den porten — filtering.
   • (iii) I tabell, peker mot samme port som inngang: ramme forkastes — mottaker har allerede sett rammen direkte på det delte segmentet.

Oppføringer slettes etter timeout (typisk noen minutter), slik at tabellen forblir oppdatert hvis enheter flyttes.

b) PC sender til 10.0.0.5:

PC-en sjekker først: er 10.0.0.5 i samme subnett som meg (192.168.1.0/24)? Nei. Da må pakken sendes til default gateway.

Destinasjons-IP forblir 10.0.0.5 (ikke endret). Men destinasjons-MAC i Ethernet-rammen settes til MAC-adressen til gatewayen 192.168.1.1.

For å finne den MAC-adressen sjekker PC-en sin ARP-tabell. Hvis ikke der: send ARP-request som broadcast på subnettet — «hvem har 192.168.1.1?» Gatewayen svarer med sin MAC. Resultatet caches.

Når pakken når gatewayen, ruter den den videre på lag 3 — og lag 2 setter en ny dest-MAC for det neste hoppet. IP-adressene endres ikke underveis, men MAC-adressene endres på hvert hopp.

c) Transparent og plug-and-play:

Svitsjen har ingen IP- eller MAC-adresse selv (på dataplanet) — endenoder vet ikke at den finnes. Den krever ingen konfigurasjon — sett strøm på, koble inn kabler, og self-learning tar seg av resten. Rutere må derimot konfigureres med IP-adresser per grensesnitt og rutings­tabeller (eller dynamisk rutings­protokoll).

Pensum: Kap. 6.4 — Linklags-svitsjer · Kap. 6.4.1 — ARP

a) CRC-prinsipp:

Avsender og mottaker har avtalt en generator G på r+1 bit. Avsender sender bitsekvensen D · 2r (D etterfulgt av r nuller) og finner R = resten ved modulo-2-divisjon med G. Den faktiske rammen som sendes er D || R.

Modulo-2-divisjon = XOR-divisjon (ingen carry). Egenskapen vi utnytter: (D · 2r) − R er delelig på G med rest 0. Mottaker deler det hele på G; rest 0 ⇒ ingen oppdagede feil.

b) D = 110101, G = 1011, r = 3:

Append 3 nuller: 110101000. Divider med 1011 modulo-2:

  1 1 0 1 0 1 0 0 0
^ 1 0 1 1
  -----
    1 1 0 0 1 0 0 0
  ^ 1 0 1 1
    -----
      0 1 1 1 1 0 0 0
            (skift G videre)
        1 1 1 1 0 0 0
      ^ 1 0 1 1
        -----
          1 0 0 1 0 0
        ^ 1 0 1 1
          -----
            0 0 0 1 0 0
                  (kan ikke dividere mer; rest har ≤ r bit)

Trinnene er: 110101000 ⊕ 1011_____ → 011001000, deretter 11001000 ⊕ _1011____ → 01111000, deretter 1111000 ⊕ __1011___ → 0100000 ... fortsett til ≤ 3 bit gjenstår.

Resten blir R = 010. Den fulle rammen som sendes er D || R = 110101 010.

(Merk: nøyaktig samme prosedyre. Studenter får poeng for korrekt metode + rett rest. Hvis du regnet og fikk en annen rest, dobbeltsjekk hver XOR.)

c) Verifikasjon hos mottaker:

Mottaker deler hele bitsekvensen 110101 010 med G = 1011 modulo-2. Hvis resten er 0, ingen oppdaget feil — rammen aksepteres. Hvis resten er ulik 0, ble det oppdaget bitfeil og rammen forkastes (eller en høyere nivå-mekanisme retransmitterer).

CRC fanger alle 1-bits feil og de fleste flerbits-mønstre; valg av G påvirker hvor sterkt CRC-en er.

Pensum: Kap. 6.2.3 — CRC

a) Digital signatur:

Avsender bruker sin private nøkkel til å «kryptere» meldingen (eller en hash av den). Resultatet er signaturen. Hvem som helst kan dekryptere signaturen med avsenders offentlige nøkkel; hvis dekrypteringen produserer den forventede meldingen (eller hash), er signaturen gyldig.

Egenskaper signaturen gir:

• Autentisering: bare den som har privat nøkkel kan ha laget signaturen.
• Integritet: hvis meldingen var endret, ville hashen / dekrypterings­resultatet ikke matche.
• Ikke konfidensialitet — meldingen er fortsatt lesbar. Konfidensialitet krever separat kryptering.

Bonus: signaturen gir også ikke-fornektelse — avsender kan ikke senere benekte å ha sendt meldingen.

b) Hvorfor signere hashen?

Offentlig nøkkel-kryptografi er svært tregt for store meldinger. En kort hash (typisk 256 bit) er rask å kryptere. Mottaker hasher mottatt melding selv og sammenligner.

Hash-funksjonen må være kollisjons­resistent — det skal være beregnings­messig umulig å finne to ulike meldinger som gir samme hash. Ellers kunne en angriper bytte ut innholdet i meldingen mens signaturen forblir gyldig.

c) Sertifikat og CA:

Et sertifikat er en datastruktur som inneholder (typisk):

• Identitet (f.eks. domenenavn eller organisasjon)
• Den offentlige nøkkelen som tilhører identiteten
• Gyldighetsperiode
• En digital signatur fra en Certificate Authority (CA)

Klienten har en forhåndskonfigurert liste over betrodde CA-rotnøkler (i operativsystem/nettleser). Når klienten mottar et sertifikat, verifiserer den signaturen ved hjelp av CA-ens offentlige nøkkel. Hvis signaturen er gyldig, har klienten tillit til at den offentlige nøkkelen i sertifikatet virkelig tilhører den oppgitte identiteten.

Dette er kjernen i Public Key Infrastructure (PKI) og brukes blant annet i TLS/HTTPS.

Pensum: Kap. 8.3 — Integritet og digitale signaturer

a) Store-and-forward vs cut-through:

Store-and-forward: ruter mottar hele pakken før den kan starte å sende videre. Adderer L/R per ruter.

Cut-through: ruter starter å sende videre så snart den har lest header-feltene den trenger for å bestemme utport (typisk de første få byte). Bare en liten startforsinkelse k/R per ruter, deretter strømmer pakken gjennom uten å bli buffret hel.

Cut-through gir gevinst når pakker er store og lenker har samme hastighet. Krever at headeren som er nødvendig for forwarding er kort og ligger først. Begrensning: feildeteksjon på CRC kan ikke gjøres før hele pakken er sett — feilkilder kan dermed forplantes.

b) Beregning:

L/R = 10 000 / 10⁸ = 100 µs (full pakke).

k/R = 200 / 10⁸ = 2 µs (oppstartsforsinkelse per ruter).

Tidlinje for cut-through:

• A starter å sende ved t=0, siste bit forlater A ved t = L/R = 100 µs.
• R1 begynner å sende videre ved t = k/R = 2 µs.
• R2 begynner å sende videre ved t = 2 + 2 = 4 µs.
• Siste bit av pakken må fortsatt nå B; siste bit forlater A ved 100 µs, går «rett gjennom» R1 og R2 i samme rate, og lander hos B ved t = 100 + 2 + 2 = 104 µs.

Cut-through total: 104 µs.

Sammenligning med store-and-forward: 3·L/R = 3·100 = 300 µs.

Cut-through sparer ~196 µs i dette eksempelet — fordelaktig fordi pakken er stor (100 µs L/R) og oppstart bare er 2 µs per hopp.

Pensum: Kap. 1.4 — Forsinkelse, store-and-forward