2019 samenvatting - Lars Lemmens

Met dank aan de Github van Martijn en Lars Lemmens

Hoofdstuk 2

2.1 Principes van netwerkapplicaties

2.1.1 Structuren van netwerkapplicaties

Client-server structuur

P2P-structuur

2.1.2 Communicerende processen

Client – en serverprocessen

Interface tussen proces en computernetwerk

Adresseren van processen

2.1.3 Transportdiensten voor applicaties

| Data Integriteit:

Timing:

Diensten van TCP & UDP

 

68747470733a2f2f65787465726e616c2d636f6e74656e742e6475636b6475636b676f2e636f6d2f69752f3f753d6874747073253341253246253246692e726564642e6974253246716b30716171666135786d32312e6a706726663d31266e6

Beveiligen van TCP

TCP gebruikt SSL/TLS → TCP met SSL/TLS → doet niet alleen wat oorspronkelijke TCP doet → levert ook beveiliginsdiensten voor communicerende processen → SSL niet een 3e transportprotocol voor internet is dat op zelfde niveau werkt als UDP & TCP → uitbreiding van TCP → uitbreidingen geimplementeerd in applicatielaag

Diensten die niet geleverd worden door internettransportprotocollen

2.1.5 Protocollen voor applicatielaag

In applicatielaag volgende aspecten gedefinieerd:

2.1.6 Netwerkapplicaties die in dit boek beschreven worden

2.2 Web & HTTP

2.2.1 Meer over HTTP

68747470733a2f2f65787465726e616c2d636f6e74656e742e6475636b6475636b676f2e636f6d2f69752f3f753d687474702533412532462532467777772e63656c6c62696f6c2e636f6d25324662696f696e666f726d61746963735f77656

2.2.2 Non-persistente en persistente verbindingen

Non persistent

Basis HTML-file met volgende url: http://www.someschool.edu/someDepartment/home.index

  1. HTTP-client starts TCP-verbinding met server → client & server gebruiken socket
  2. HTTP-client verzendt HTTP-verzoekbericht naar HTTP
  3. HTTP-serverproces ontvangt verzoekbericht
  4. HTTP-serverproces TCP opdracht → verbreek verbinding als bericht ontvangen
  5. HTTP-client ontvangt antwoordbericht
  6. Herhaal stap 1-4 voor elk object

RTT → tijd die packet nodig heeft → client naar server & omgekeerd

Klikt op een hyperlink → 3-way handshakeproces nodig:

  1. Client verzendt TCP-segment naar server

  2. Server bevestigt & antwoord met TCP-segment

  3. Client verzendt 2e bevestiging naar server

    → 1 RTT

Persistent

2.2.3 Indeling HTTP-berichten

HTTP-verzoekbericht

HTTP-antwoordbericht

68747470733a2f2f65787465726e616c2d636f6e74656e742e6475636b6475636b676f2e636f6d2f69752f3f753d68747470732533412532462532467777772e7265736561726368676174652e6e657425324670726f66696c652532464d6f7

2.2.4 Interactie gebruikers & servers: cookies

  1. Cookieheaderregel in HTTP-antwoordbericht
  2. Cookieheaderregel in HTTP-verzoekbericht
  3. Cookiebestand opgeslagen op host gebruiker & browser van gebruiker beheerd
  4. Back-enddatabase op website

2.2.5 Webcaching

Netwerkentiteit die HTTP-verzoeken afhandelt names oorspronkelijke webserver waar verzoek oorspronkelijk naartoe is gestuurd

Browser object http://www.someschool.edu/campus.gif

  1. Browser start TCP-verbinding met webcache & verzendt HTTP-verzoek voor object naar webcache
  2. Webcache checks → exemplaar opgevraagde object aanwezig? → if yes → webcache verzendt object in HTTP-antwoordbericht naar browser client
  3. Opgevraagde object niet op webcache → TCP-verbinding met oorspronkelijke server → webcache verzendt HTTP-verzoek voor object via TCP-verbinding → wanneer server ontvangen → verzendt object in HTTP-antwoordbericht naar webcache
  4. Opslaan kopie lokaal & stuurt een exemplaar naar browser

2 redenen webcaching

CDN (Content Distribution Networks) → veel geografische verspreide cachegeheugens in internet → groot deel dataverkeer lokaal

2.2.6 The conditional GET

  1. Client maakt get request
  2. Server reageert met header
  3. Client checkt de Last-Modified header
  4. ls Last nieuwer is dan cache → haal pagina opnieuw op & zet opnieuw in cache
  5. anders → laad van cache
GET /index.html HTTP/1.1\r\n
Host: www-net.cs.umass.edu\r\n
User-Agent: Firefox/3.6.10\r\n
Accept: text/html,application/xhtml+xml\r\n
Accept-Language: en-us,en;q=0.5\r\n
Accept-Encoding: gzip,deflate\r\n
Accept-Charset: ISO-8859-1,utf-8;q=0.7\r\n
Keep-Alive: 115\r\n
Connection: keep-alive\r\n
\r\n

HTTP/2

Goal: vertraging verlagen in multi-object HTTP requests HTTP1.1** :** meerdere, pipelined GETs over 1 TCP connectie

HTTP/2** :** flexibiliteit verhogen server in versturen van objects naar client Goal: vertraging verlagen in multi-object HTTP requests

68747470733a2f2f65787465726e616c2d636f6e74656e742e6475636b6475636b676f2e636f6d2f69752f3f753d68747470732533412532462532466d69726f2e6d656469756d2e636f6d2532466d617825324631363430253246302a6e684

HTTP/2 to HTTP/3

Goal: vertraging verlagen in multi-object HTTP requests

HTTP/2 over single TCP connectie wil zeggen:

2.3 E-mail op het internet

2.3.1 SMTP

Werking:

  1. Alice → UA opdracht verstuur bericht
  2. Alice's UA stuurt bericht mailserver→ in berichtenwachtrij
  3. Clientzijde van SMTP opent TCP-verbinding met Bob's e-mailserver
  4. SMTP-client verzendt het bericht van Alice via de TCP-verbinding
  5. Bob's mailserver plaatst het bericht in Bob's mailbox
  6. Bob roept zijn user agent aan om bericht te lezen

68747470733a2f2f65787465726e616c2d636f6e74656e742e6475636b6475636b676f2e636f6d2f69752f3f753d687474702533412532462532467777772e61667465726e6572642e636f6d253246626c6f6725324677702d636f6e74656e7

2.3.2 Vergelijking met HTTP

SMTP

HTTP

2.3.3 Formats e-mailberichten

2.3.4 Mail accessprotocollen

SMTP: levering/opslag van e-mailberichten op de server van de ontvanger

Mail Access Protocol: Ophalen server

IMAP: Internet Mail Access Protocol [RFC 3501]: berichten opgeslagen op de server, IMAP biedt ophalen, verwijderen, mappen met opgeslagen berichten op de server

HTTP: Gmail, Hotmail, Yahoo! Mail, etc. biedt webgebaseerde interface bovenop STMP (om te verzenden), IMAP (of POP) om e-mailberichten op te halen

POP3

UA → TCP-verbinding naar mailserver

  1. Autorisatiefase: UA → verstuurt username & password → identitetit gebruiker vaststellen
  2. Transactiefase: UA haalt berichten op
  3. Updatefase: client opdracht quit → POP3-sessie closed

IMAP

Webmail

Ontvanger wil mailbox bekijken → bericht van mailserver naar browser van gebruiker verzonden → behulp van HTTP-protocol

2.4 DNS

2.4.1 Diensten van DNS

DNS verzorgt aantal andere diensten naast vertalen hostnamen in IP-adressen:

(Een MX-record (Mail eXchange-record) is een gegevenstype in het Domain Name System (DNS). Het specificeert de mail server die e-mailverkeer voor het betreffende domein afhandelt. Een domein kan meerdere MX-records hebben met een verschillende prioriteit waardoor het mogelijk is om bijvoorbeeld een back-up mailserver aan te geven als de computer met de hogere prioriteit niet bereikbaar blijkt. De naam die in het MX-record wordt gevonden kan via DNS op zijn beurt in een ip-adres worden vertaald. Src: Wikipedia)

2.4.2 Overzicht van de werking van het DNS

Gecentraliseerd ontwerp levert volgende problemen op:

Een gedistribueerde, hiërarchische database

DNS-caching

DNS-server → in verzoekberichtenketen → wanneer DNS-antwoord ontvangt → verwijzing in lokale cachegeheugen plaatsen

2.4.3 DNS-records en -berichten

DNS-servers bevatten bronrecords → (Naam, Waarde, Type, TTL)

  1. If Type = A then naam bevat hostnaam en Waarde bevat IP-adres van hostnaam
  2. If Type = NS then naam bevat domeinnaam en Waarde bevat hostnaam van authoritative DNS-server die de hostnaam en IP combinaties voor de hosts in dat domein weet
  3. If Type = CNAME then waarde is canonieke hostname voor aliashostname
  4. IF Type = MX then waarde is canonieke naam van mailserver met alias hostname name

Een authoritative DNS-server bevat een A-record

Een niet-authoritative DNS-server bevat een NS-record voor het domein waarin de DNS-server zich bevindt en ook een A-record met het IP-adres van de DNS-server die in het veld Waarde van het NS-record staat

DNS-berichten

  1. Eerste veld is een uniek 16 bit getal waarmee het verzoek geïdentificeerd kan worden. Dat getal word gekopieerd in het antwoordbericht, zodat de client het antwoord en het verzoek kan kopellen
  2. Vlaggen veld bevat een aantal vlaggen. Een 1-bit verzoek/antwoord-vlag (verzoek = 1 en antwoord = 0), 1-bit authoritative-vlag wordt in een antwoordbericht gezet als de DNS-server de authoritative DNS-server voor de hostnaam is, 1-bit recursienoodzaak-vlag wordt gebruikt als de client vraagt om recursief te werken als het gevraagde record niet op die DNS-server staat en een 1-bit recursiemogelijkheids-vlag die in het antwoordbericht staat na een verzoekbericht met een recursienoodzaak-vlag
  1. Bevat een naamveld met de naam waarvoor het IP-adres wordt gezocht
  2. Bevat een typeveld met het type verzoek (Type A, Type NS…)

 

DNS-Security

DDOS-attack:

TLD servers bombarderen:

Aanvallen omleiden

DNS voor DdoS exploiteren

Laatste 2 vormen DNSSEC

2.5 Peer-to-peer bestandsdistributie

P2P file distributie: BitTorrent

Peer neemt deel aan torrent → meldt bij tracker → peer informeert tracker met regelmaat of nog aanwezig in torrent → nieuwe peer → tracker random # peers → verzendt IP-adressen van # peers → naar nieuwe peer → proberen TCP-verbinding met peers op lijst → bepaald tijdstip → elke peer → # chunks bestand → verschillende peers → verschillende verzamelingen chunks hebben → na een bepaalde tijd → gebruiker vraagt elke peer om lijst met chunks die ze hebben → gebruiker vraagt de "missing chunks" van de peerst → zeldzaamste eerst of Rarest first

Tit-for-tat principe:

Gebruiker stuurt chunks naar die vier peers die momenteel haar chunks in het hoogste tempo verzenden → andere peers gestikt door gebruiker (ontvangen geen chunks van gebruiker) → herbeoordeeld top 4 elke 10 seconden

Elke 30 seconden → selecteert willekeurig een andere peers, begint met verzenden van chunks → optimistisch unchocked deze peer → nieuwe gekozen peer kan lid worden van top 4

2.6 Videostreaming en content distribution networks

Internetvideo

2.6.1.1 Streaming stored video

Simpel Scenario:

Hoofddoelen:

2.6.1.2 Streaming stored video : challenges

Continuous playout constraint → zodra play-out van client begint → afspelen overeenkomen met oorspronkelijke timing → maar network delays variabel (jitter) → heeft buffer aan clientzijde nodig om aan play-out vereisten te voldoen

Andere challenges

Client interactiviteit → pause, voortspoelen, terugspelen, verder in video gaan → video packets loss mogelijk → opnieuw verzonden

HTTP-streaming en DASH

D ynamic A daptive S treaming over H TTP

STREAMING VIDEO = CODERING + DASH + PLAYOUT BUFFERING

Content Distribution Networks (CDNs)

Challenge: Hoe content streamen naar 100 tot 1000'en gebruikers tegelijk

Hoofdstuk 8: Security in computer networks

8.1 Wat is netwerkbeveiliging

  1. Vertrouwelijkheid : Alleen zender & beoogde ontvanger inhoud van verzonden bericht begrijpen
  2. Berichtintegriteit : de afzender en ontvanger zeker zijn dat inhoud van communicatie niet wordt gewijzigd
  3. Authenticatie op eindpunt: zender & ontvanger identiteit andere partij vaststellen zeker te zijn dat ander is wie hij beweert
  4. Operationele beveiliging: bijna alle organisaties hebben netwerken aangesloten op het openbare internet.Deze netwerken kunnen daarom mogelijk worden aangetast.

8.2 Principes van cryptografie

Verzender ( X ) verstuurt bericht naar ontvanger (Y)

  1. X gebruikt sleutel K** A**→ invoer versleutelalgoritme
  2. Versleutelalgoritme gebruikt sleutel → onversleutelde bericht m → versleutelde tekst → K** A****(m)**
  3. KA onderling afspreken
  4. Y ook sleutel K** B **** →**invoer onsleutelalgoritme → versleutelde bericht X → plaintext
  5. Y ontvangen versleutelde bericht KA(m) → ontsleutelen → berekenen van Kb(Ka(m)) = m

8.2.1 Cryptografie met symmetrische sleutels

  1. First → Caeser cipher → elke letter in platte tekst → letter → k-letters in alfabet te vervangen
  2. Daarna → monoalfabetisch cijfer → lettervervanging maar moet uniek zijn

Bruteforce-benadering→ uitproberen alle 10^26 → teveel werk

Polyalfabetische codering → verschillende monoalfabetische ciphers gebruikt → afwisselend ingezet → bepaalde positie in onversleutelde bericht te versleutelen

Block ciphers (DES = data encryption standard, 3DES, AES= advanced encryption standard)

2 categorieën van symmetrische versleuteltechnieken

Blockciphers

  1. versleutelen bericht → verwerkt blokken k bits
  2. IF k = 64 → bericht opgesplitst in 64 blokken → elk blok onafhankelijk versleuteld
  3. Codering 1 op 1 toewijzing om k-bit blok cleartext toe te wijzen aan k-bit blok Ciphertext

Hoeveel mogelijke verwijzingen?

Zeer moeilijk uit te voeren. Voor k = 64 moeten Alice en Bob een tabel onderhouden met 2^64 invoerwaarden → onmogelijk → blokcoderingen meestal functies die willekeurig gepermuteerde tabellen simuleren.

Cipher-block chaining (CBC)

Blockcipher → twee of meer blokken identiek zijn→aanvaller mogelijk cleartext raden en misschien het hele bericht decoderen. → solution → willekeur in ciphertext

Werkwijze:

  1. voor bericht versleutelt → genereert Afzender een willekeurige k-bit string,initialisatievector (IV) = c(0) genoemd→ afzender stuurt IV naar ontvanger in leesbare vorm
  2. Eerste blok berekent de afzender m(1) + c(0) → exclusieve OR van eerste blok onversleutelde tekst & IV. → verzender verwerkt met BC → bijhorende blok als versleutelde tekst c(1)=Ks(m(1)+c(0) → verzender versleutelde blok (c1) naar ontvanger
  3. Voor het i-blok genereert de afzender c(i) = Ks(m(i) + c(i-1))

8.2.2 Cryptografie met openbare sleutel

Diffie-Hellman key exchange

  1. Alice haalt Bob's publieke sleutel
  2. Alice versleutelt bericht (m) aan Bob → door public key van Bob en bekend encryptie-algoritme K+B(m).
  3. Bob ontvangt → gecodeerde bericht van Alice → gebruikt private key & bekend decoderingsalgoritme → gecodeerde bericht decoderen
  4. Bob berekent K-B( K+B(m)).
  5. Berekenen van Kb-(Kb+(m)) resulteert in m

Note : each party generates a public/private key pair and distributes the public key. After obtaining an authentic copy of each other's public keys, Alice and Bob can compute a shared secret offline. The shared secret can be used, for instance, as the key for a symmetric cipher.

68747470733a2f2f75706c6f61642e77696b696d656469612e6f72672f77696b6970656469612f636f6d6d6f6e732f7468756d622f342f34632f5075626c69635f6b65795f7368617265645f7365637265742e7376672f32353070782d50756

RSA

Maken van publieke en private RSA keys:

  1. Kies 2 grote priemgetallen p & q → hoe groter de waarden hoe moeilijker RSA-algoritme te kraken
  2. Bereken n = p * q
  3. Bereken z = (p – 1) * (q-1)
  4. Kies nummer e, dat kleiner is dan n & geen factoren (buiten 1 ) gemeenschappelijk heeft met z
  5. Zoek een getal d, zodanig dat ed – 1 precies deelbaar is door z. Wij kiezen d zodanig dat e*d mod z = 1
  6. Openbare sleutel (K+B) is het paar van de getallen (n, e)
  7. The private key(K-B) is the pair of the numbers (n, d)

NOTE: Diffie-Hellman niet zo veelzijdig als RSA omdat het niet gebruikt kan worden om berichten met willekeurige lengte te coderen → toegepast om symmetrische sessiesleutel tot stand te brengen → daarna coderen berichten

Berichtintegriteit en digitale handtekeningen

8.3.1 Cryptografische hashfuncties

H(x) = H(Y)

8.3.2 Berichtauthenticatiecode

berichtintegriteit uit te voeren→Alice en Bob→ naast gebruik van cryptografische hashfuncties, → gedeeld geheim nodig→niets meer dan een reeks bits = verificatiesleutel.→ door gedeelde geheim kan berichtintegriteit als volgt worden uitgevoerd:

8.3.3 Digitale handtekeningen

Certificering van openbare sleutels

Certificate authority → echtheid identiteiten authenticeert & certificaten uitgeeft

  1. Een certification authority controleert of een entiteit is wie het zegt dat het is.

  2. certificeringsinstantie identiteit van entiteit verifieert, maakt certificeringsinstantie een certificaat → openbare sleutel van de entiteit aan de identiteit bindt → certificaat bevat openbare sleutel + wereldwijd unieke identificerende informatie over eigenaar van openbare sleutel. Het certificaat digitaal ondertekend door certification authority.

Authenticatie op het eindpunt

Eindpuntverificatie →proces waarbij de ene entiteit zijn identiteit aan een andere entiteit bewijst via een computernetwerk.

8.4.1 Authenticatieprotocol ap1.0

Trudy (indringer) stuurt bericht naar Bob → zegt "ik ben Alice" → Bob weet niet of het werkelijk Alice is 8.4.2 Authenticatieprotocol ap2.0 Alice bekend netwerkadres waaruit ze altijd communiceert→ Bob proberen Alice te verifiëren → bronadres IP-datagram met verificatiebericht overeenkomt met het bekende adres van Alice.

niet moeilijk om IP-datagram te maken, zet elk IP-bronadres dat we willen in het IP-datagram.

8.4.3 Authenticatieprotocol ap3.0

Het wachtwoord is een gedeeld geheim tussen de authenticator en de persoon die wordt geverifieerd.

8.4.4 Authenticatieprotocol ap3.1

Door het wachtwoord te versleutelen→voorkomen Trudy Alice's wachtwoord leert→aannemen dat Alice en Bob een symmetrische geheime sleutel delen, KA – B,dan kan Alice het wachtwoord versleutelen en haar identificatiebericht en het gecodeerde wachtwoord naar Bob sturen. Bob decodeert vervolgens het wachtwoord en verifieert Alice.

De fout: the playback attack : Trudy hoeft alleen maar de communicatie van Alice af te luisteren, de gecodeerde versie van het wachtwoord op te nemen en de gecodeerde versie van het wachtwoord af te spelen naar Bob om te doen alsof ze Alice is.

8.4.5 Authenticatieprotocol ap4.0

Een nonce is een getal dat een protocol maar één keer in een leven zal gebruiken. Dat wil zeggen dat zodra een protocol een nonce gebruikt, het het nummer nooit meer zal gebruiken. Onze ap4.0 gebruikt een nonce in als volgt:

  1. Alice verzendt bericht 'ik ben Alice' aan Bob
  2. Bob kiest een nonce en verzendt die naar Alice
  3. Alice versleutelt de nonce met de symmetrische sleutel van Alice en Bob, KA– B,en stuurt de gecodeerde nonce KA_B(R) terug naar Bob.
  4. Bob ontsleutelt het ontvangen bericht. Als de gedecodeerde nonce gelijk is aan de nonce die hij Alice stuurt, dan is Alice geauthenticeerd

8.5 E-mail beveiligen

8.5.1 Ontwerp van veilige e-mail

Vertrouwelijkheid (Systeem 1)

  1. Gebruikt geheime sleutel Kb-→ verkrijgen symmetrische sleutem Ks
  2. Symmetrische sleutel Ks → ontsleutelen bericht

Sessie key = inefficient

1. Berichtintegriteit

The 2 combined:

8.5.2 PGP

PGP-software gebruikt:

Als PGP installed:

  1. Openbaar sleutelpaar voor gebruiker
  2. Openbare sleutel → website gebruiker of openbare sleutelserver

PGP → mogelijkheid bericht digitaal ondertekenen

8.6 TCP-verbindingen beveiligen

Noodzaak SSL:

SSL lost problemen op door volgende bovenop TCP uit te voeren:

  1. Vertrouwelijkheid
  2. Gegevensintegriteit
  3. Serverauthenticatie
  4. Clientauthenticatie

SSL → eenvoudige API vergelijkbaar API van TCP

8.6.1 Het hele verhaal, maar vereenvoudigd

Fase 1: Handshake

  1. Bob TCP-verbinding met Alice maken
  2. Verzekeren dat Alice echt Alice is
  3. Alice geheime mastersleutel zenden → Alice & Bob gebruiken → symmetrische sleutel genereren → nodig voor SSL

Fase 2: Verkrijgen van een sleutel

Alice & Bob moeten MS gebruiken om vier sleutels te genereren:

Fase 3: Gegevensoverdracht

Geen goed idee → integriteit alle gegevens tijdens hele sessie dat Bob gestuurd heeft controleren

  1. SSL splitst gegevensstream → records
  2. SSL voegt berichtauthenticatiecode toe aan elk record → versleutelt combinatie
  3. Maken van berichtauthenticatiecode → Bob hashfunctie toe → combinatie recordgegevens & sleutel Mb
  4. Versleutelen → Bob gebruikt sessievercijfersleutel Eb

Man in the middle attack ( MITM) : kansegmenten in de TCP-stream vervangen, invoegen en verwijderen tussen Alice en Bob.

Aannemen dat elk TCP-segment exact 1 record verpakt is → kijken hoe Alice segmenten verwerkt

  1. TCP in host Alice → denkt alles is OK → 2 records aan SSL-sublaag
  2. SSL in host Alice → 2 records ontsleutelen
  3. SSL in host Alice →berichtauthenticatiecode in elk record gebruiken → integriteit van gegevens in 2 records
  4. SSL → ontsleutelde bytestream van 2 records doorgeven → applicatielaag → door Alice ontvangen bytestream → gevolg verwisseling records → niet in juiste volgorde

Oplossing: gebruik volgnummers.

  1. Bob onderhoudt een reeksnummerteller, die begint bij nul en wordt verhoogd voor elke SSL-record die hij verzendt.
  2. Wanneer hij de MAC berekent,neemt hij het volgnummer op in de MAC-berekening.

Zo is MAC = hash van gegevens + MAC-toets + huidig volgnummer.

Alice kan Bob's volgnummers opsporen, zodat ze de gegevensintegriteit kan verifiëren.

SSL record

Bestaat uit → typeveld, versieveld, lengteveld, gegevensveld & berichtauthenticatiecode

8.6.2 Het hele verhaal, maar wat minder vereenvoudigd

SSL handshake

Alice & Bob begin SSL-sessie zelf afspraken maken over cryptografische algoritmen → aka handshakeprocedurefase → + Alice & Bob zenden elkaar nonces toe → gebruikt bij maken van sessiesleutels (EB,MB,EA,MA)

Handshakeprocedure bij SSL:

  1. Client verzendt lijst → versleutelalgoritmen die hij ondersteunt & zelfgekozen nonce
  2. Server kiest uit ontvangen lijst algoritme voor → symmetrische sleutel, openbare sleutel & berichtauthenticatiecode → server verstuurt bericht met voorkeuren, certificaat & zelfgekozen nonce
  3. Client authenticeert certificaat + berekent openbare sleutel server + genereert geheime pre-mastersleutel (PMS) → versleutelt PMS met openbare sleutel server → verzendt versleutelde PMS naar server
  4. Afgesproken functie bepalen sleutel → berekenen client & server onafhankelijk → geheime mastersleutel met PMS & nonces → geheime mastersleutel in stukken gehakt → 2 coderingssleutels & 2 berichtauthenticatiecodes genereren → gekozen symmetrische codering werkt met cipher-block-chaining → 2 initialisatievectoren gemaakt → geheime mastersleutel → daarna alle berichten versleuteld & geauthenticeerd
  5. Client verzendt berichtauthenticatiecode → alle handshakeprocedureberichten
  6. Server verzendt berichtauthenticatiecode → alle handshakeprocedureberichten

Alleen nonces → niet mogelijk "replay attack" te voorkomen

Verbinding verbreken

Iemand geeft in het typeveld aan of de record dient om de SSL-sessie te beëindigen. Door zo'n veld op te nemen, zou Alice weten dat als ze een TCP FIN zou ontvangen voordat ze een SSL-sluitingsrecord zou ontvangen, ze weet dat er iets grappigs aan de hand is.

8.7 Beveiliging op netwerklaag: IPsec & VPN

8.7.1 IPsec & VPN

Met VPN → interne dataverkeer van de instelling verzonden via het publiekelijk toegankelijke internet in plaats van via een fysiek gescheiden netwerk. → dataverkeer eerst versleuteld

CHECK PAGINA 597 IN HANDBOEK VOOR AFBEELDING

8.7.2 Authentication header-protocol en het encapsulation security payload-protocol

Protocolsuite IPsec → Authentication header (AH-protocol) & encapsulation security payload (ESP-protocol)

AH-protocol → bronauthenticatie & gegevensintegriteit maar geen vertrouwelijkheid ESP-protocol → bronauthenticatie & gegevensintegriteit & vertrouwelijkheid Vertrouwelijkheid essentieel bij VPN & andere IP-sec applicaties

8.7.3 Beveiligingsassociaties

IPsec-datagrammen → verzonden tussen 2 netwerkentiteiten → voor bronentiteit IPsec-datagrammen verstuurt → 2 entiteiten → logische verbinding tot stand = beveiligingsassociatie → logische simplexverbinding → unidirectioneel van bron naar bestemmingsentiteit → beide entiteiten beveiligde datagrammen naar elkaar willen verzenden → noodzakelijk om 2 beveiligingsassociaties tot stand te brengen → voor elke richting 1

8.7.4 Het IPsec-datagram

2 verschillende packetvormen → tunnelmodus & transportmodus PAGINA 589 HANDBOEK

8.7.5 sleutelbeheer in IPsec (IKE)

IKE kent twee fase

Fase1:

opmerking: IKE SA anders dan IPsec SA ook bekend als ISAKMP security association

Fase 2:

fase 1 heeft twee modi: agressieve modus en hoofdmodus

IKE-berichtenuitwisseling voor algoritmen, geheime sleutels, SPI-nummers

 

8.8 Securing wireless LANs

8.8.1 Wired equivalent privacy

LEER VANUIT SLIDES $rarr; DUIDELIJKER

8.9 Operationele beveiliging: firewalls & intrusion-detectionsystemen

8.9.1 Firewalls

3 doelen:

Traditionele packetfilters

Filterbeslissingen meestal genomen op basis van:

Organisatie kan filteren op:

Filterpolicy kan gebaseerd zijn op combinatie van adressen & poortnummers

Stateful packetfilters

Bewaken alle bestaande TCP-verbindingen → firewall kan nieuwe verbinding detecteren → door 3-wayhandshake (SYN, SYNACK & ACK) → + eind verbinding detecteren → FIN-packet → firewall kan ook veronderstellen → verbinding niet meer nodig is → geen activiteit

Packet bereikt firewall

  1. Firewall controleert lijst met toegangsbeheer ( traditionele packetfilters )
  2. Verbindingstabel controleren voor packet in netwerk van organisatie kan komen
  3. Controleert verbindingstabel → geen deel van lopende TCP-verbinding → weigert
  4. IF webserver stuurt packet terug → firewall controleert tabel → overeenkomstige verbinding → packet passeren

Application gateway

Firewalls moeten packetfilters combineren met applicatiegateways → die kijken verder dan headers van IP, TCP & UDP → beslissingen op basis van applicatiegegevens Applicatiegateway → applicatiespecifieke server die door alle applicatiegegevens gepasseerd moet worden → verschillende applicatiegateways kunnen op dezelfde host uitgevoerd worden → elke gateway afzonderlijke server met eigen processen

Stel:

Firewall → geselecteerde groep interne gebruikers → Telnet-verbindingen met externe netwerken → tegelijk voorkomen → externe clients → Telnet-verbinding maken met interne host

Stel nu:

Interne gebruiker wil verbinding tot stand brengen met buitenwereld

  1. Gebruiker Telnet-sessie starten met applicatiegateway → op gateway draait applicatie → wacht voor inkomende Telnet-sessies tot stand komen
  2. Applicatie vraagt username & password
  3. IF informatie = correct → applicatiegateway checkt IF gebruiker = gerechtigd is → als dat het geval is
  4. Gateway vraagt gebruiker → hostname externe host ingeven
  5. Gateway Telnet-sessie → tussen gateway & externe host
  6. Gateway verzendt alle gegevens afkomstig van externe host naar gebruiker & omgekeerd

8.9.2 Intrusion-detectionsystems

IDS + IPS = IDS

Organisatie → meerdere IDS's sensoren implementeren → meestal samenwerkend → sturen verdachte verkeersactiviteit → centrale IDS-processor → verzamelt info → alarmen verzendt naar netwerkbeheerder wanneer nodig

Pagina 619 afbeelding 3.6

Organisatie → 2 delen opgesplitst

  1. Streng beveiligd deel → afgeschermd door → packetfilter & applicatiegateway → bewaakt door IDS sensoren
  2. Minder streng beveiligd deel →gedemilitariseerde zone (DMZ)→ alleen beveiligd door packetfilter maar ook bewaakt door sensoren IDS (is een netwerksegment dat zich tussen het interne en externe netwerk bevindt. Het externe netwerk is meestal het Internet. Een DMZ is feitelijk een andere naam voor een extranet, een gedeelte van het netwerk dat voor de buitenwereld volledig toegankelijk is. Op het netwerksegment van de DMZ zijn meestal servers aangesloten die diensten verlenen die vanuit het interne en externe netwerk aangevraagd kunnen worden)

Sensoren voor IDS → verderop in systeem → elke sensor deel van dataverkeer → gemakkelijker taak uitvoeren

IDS systemen in 2 categorieën

  1. Systemen die werken met handtekeningen

Beperkingen:

  1. dit soort IDS → alleen als voorkennis over aanval is → gebruikt nauwkeurige handtekening te vervaardigen → blind als er nieuwe aanvallen zijn

  2. packet → zelfs als er bekende handtekening is → niets te maken met een aanval → false-positive warning

  3. IDS kan overvoerd geraken → elk packet vergeleken moet worden → uitgebreide verzameling handtekeningen → kan zover komen dat IDS schadelijke packets niet detecteert

  4. Op anomalie gebaseerde systemen

Snort

Maakt gebruik van generieke sniffingsinfterface, libpcap

Enorme groep gebruikers & beveiliginsexperts → houden handtekeningdatabase actueel

9 Multimedianetwerken

9.1 Multimedianetwerkapplicaties

9.1.1 Eigenschappen van video

9.1.2 Eigenschappen van audio

9.1.3 Soorten multimedianetwerkapplicaties

Streamen van opgeslagen audio / video

Streamen van opgeslagen video 3 belangrijke onderscheidende kenmerken

VOIP

Timing is belangrijk → spraak- en videoapplicaties → vertragingsgevoelig → meeste multimedianetwerkapplicaties → bestand tegen een zekere mate van gegevensverlies → resulteert in korte onderbrekingen van audio of video

Streamen van live audio & video

Meestal via CDN's → zelfde snelheid weergeegven als orgineel → gegevens op tijd van server ontvangen → voor moment client moet weergeven → anders haperingen → omdat evenement = live → vertraging probleem zijn → timingeisen minder streng dan voor spraakgebrekken

9.2 Streamen van opgeslagen video

2 belangrijke voordelen bufferen door client

  1. Fluctuaties in vertraging tussen server en client opvangen
  2. Banbreedte tussen server & client → daalt onder sneheid → waarmee videocontent wordt weergegeven → blijven kijken zolang buffer van clientcomponent niet leegraakt

9.2.1 Streamen met UDP

Kleine buffer op clientcomponent van applicatie gebruikt → net groot genoeg voor minder dan seconde video → server die video aan UDP-verbinding vertrouwt → stukjes video verpakken in transportpackets speciaal ontworpen voor transporteren audio & video → Realtime Transport Protocol ( RTP )

Server & client → onderhouden verbinding voor videostream → ook afzonderlijke besturingsverbinding die door client wordt gebruikt geven opdrachten

Systeem 3 belangrijke nadelen:

  1. Streamen met constante snelheid → voor continue weergave → problemen opleveren als gevolg van onvoorspelbaare & wisselende beschikbare bandbreedte
  2. Streamen met UDP → server nodig om media te besturen → interactieve verzoeken tussen client en server afhandelen & toestand client bewaren → voor elke sessie
  3. Veel firewalls geconfigureerd om UDP verkeer te blokkeren

9.2.2 Streamen met HTTP

Video in HTTP server → gewoon bestand met specifieke URL → gebruiker wil video zien

  1. Client start TCP-verbinding met server
  2. Verzendt HTTP-GET-bericht
  3. Server verzendt video bestand in HTTP-antwoordbericht
  4. Clientcomponent applicatie verzamelt bytes in buffer
  5. Zodra # bytes in buffer > bepaalde drempelwaarde
  6. Client begint met weergave + videoframes periodiek uit buffer opgehaald & gecomprimeerd

Packets → vertraagd als gevolg opnieuw verzenden packets

Gebruik van HTTP over TCP → firewalls en NAT's gemakkelijker gepasseerd kunnen worden → van het UDP-dataverkeer tegen houden → HTTP-dataverkeer door te laten → streamen HTTP geen mediabesturingsserver nodig (RTSP-server) → kosten lager → meeste videostreamapplicaties werken met HTTP over TCP als streamprotocol

Prefetchen van video

Client probeert video downloaden → snelheid hoger dan weergavesnelheid → voorraad krijgen van videoframes → toekomst worden weergegeven

Buffers van clientcomponent van de applicatie & TCP-buffers

Volledige client applicatie buffer → legt indirect limiet op rate → video verstuurd van server naar client wanneer streamen over HTTP

Analyse van clientcomponent van applicatie en TCP-buffers

If beschikbare rate < video rate → continue weergave afgewisseld worden → periodes beeld stilstaat → wanneer beschikbare rate in netwerk > video rate → na initiele buffering vertraging → continous playout tot einde video

Vroegtijdige beëindiging van weergave & verplaatsen van weergavetijdstip

HTTP-byterange-headerveld in HTTP-get-verzoekbericht → bevat informatie → bereik in bytes van gewenste video → client wil ontvangen → If gebruik springt naar ander tijdstip in video → client verzendt nieuw HTTP-verzoekbericht → in byterangeheaderveld van bericht → clientapplicatie specifieert vanaf welke byte in bestand → gegevens wil ontvangen → server nieuw HTTP-verzoek ontvangt → alle eerdere verzoeken weg & bytes verzenden

9.2.3 Dynamic Adaptive Streaming over HTTP (DASH)

Gebruikt meerdere versies → zelfde video → elk een bepaalde snelheid waarmee gestreamd wordt → gecomprimeerd → CDN's vaak gebruikt distribueren opgeslagen & live video

9.3 Voice-over-IP (VoIP)

9.3.1 Beperkingen van best-effortdienst van IP

IP → zo snel mogelijk van bron naar bestemming → geen beloften → vertraging of packet loss → belangrijke consequenties → ontwerp realtime spraakapplicaties → gevoelig voor packetvertraging, jitter & verlies

  1. Verzender genereert bytes met snelheid → 8000 bytes/seconde → iedere 20 ms verzamelt bytes in stuk → chunk
  2. Chunk + speciale header → verpakt in UDP-segment → elke 20 ms UDP-segment verzonden

Als packet ontvanger bereikt → constante end-to-endvertraging → packets 20 ms na elke spraakactie van andere partij arriveren → ideale situatie → ontvanger elke chunk direct bij aankomst weergeven → sommige packets kwijt + niet zelfde end-to-endvertraging

Ontvanger moet

  1. Bepalen wanneer chunk moet weergegeven worden
  2. Bepalen wat er moet gebeuren als chunk ontbreekt

Packetverlies

Verlies zou voorkomen → packets over TCP versturen → mechanismen opnieuw verzenden packets → niet geschikt voor VoIP → vergroten end-to-endvertraging

Packetloss tussen 1% en 20% is acceptabel → afhankelijk hoe spraakgegevens gecodeerd & verzonden zijn → manier hoe ontvanger verlies maskeert → Forward Error Correction (FEC) → hulpvol zijn packetverlies maskeren

End-to-endvertraging

Totaal van

Ontvanger bij VoIP-applicatie → packets negeren die vertraging groter dan bepaalde drempelwaarde

Packetjitter

Variatie in queuing delays → packet in netwerkrouters ondervindt = cruciaal → deze vertragingen variëren → dus ook verstreken tijd tussen moment → verzenden packet & ontvangen packet → fenomeen = jitter → compenseren aan de hand van volgnummers , tijdstempels & weergavevertraging

9.3.2 Jitter voor audio compenseren bij ontvanger

Gedaan door 2 mechanismes combineren

  1. Elke chunk vooral laten gaan door tijdstempel → verzender voegt aan elk nieuw gegenereerd packet → informatie over tijdstip → packet werd gegenereerd
  2. Weergave chunks → bij ontvanger vertragen → weergave ontvangen chunks → vertraagd worden → zodat grootste deel packets ontvangen is voor weergeven

1) Onveranderlijke weergavevertraging

Ontvanger kan weergavevertragingen variëren

Chunk tijdstempel bij afzender op tijdstip t → ontvanger speelt chunk (q) af op tijdstip t + q → assuming chunk tegen die tijd gearriveerd → packets na hun geplande speeltijd arriveren → weggegooid

2) Variabele weergavevertraging

Door initiële weergavevertraging groot te maken → meestg packets op tijd aankomen → verloren packets = klein →weergavevertraging variëren aan begin elke spraaksessie → stiltes voorafgaand aan spraaksessie → verkort of verlengd → niet hoorbaar wanneer verleningen / verkortingen stiltes niet te groot zijn

9.3.3 Compenseren van packetverlies

Forward Error Correction ( FEC )

Mechanisme 1:

Verzendt redundant gecodeerde 'chunk' na elke n chunks → geconstrueerd door exclusieve OR-bewerking uit te voeren op n oorspronkelijke chunk.

Als willekeurig packet van groep n+1 kwijtgeraakt → ontvanger verloren packet reconstrueren → meer dan 2 niet mogelijk → verhoogt overdrachtssnelheid & weergavevertraging

Mechanisme 2:

Versturen van lagere resolutie audio stream → verzender genereert n-de packet door n-de chunk van nominale stream achter (n-1) de chunk van redundante stream te plaatsen → wanneer meerdere niet opeenvolgende packets kwijtraken → ontvanger verlies compenseren door chunk met lage bitsnelheid → volgende packet "meelift" geven → lagere geluidskwaliteit

Interleaving

Verzender verstuurt eenheden audiogegevens in andere volgorde → oorspronkelijk aangrenzende eenheden in verzonden stream gescheiden zijn door afstand → effect packetverlies verkleinen → if packetloss → meeste van elke orginele chunk → geen redundantie overhead → verhoogt playout delay → voordeel → benodigde bandbreedte voor een stream niet vergroot

Maskeren van fouten

Herhalen van packets → ontvanger vervangt kwijtgeraakte packets door kopieën

Interpolatie → kwijtgeraakte packet berekend p basis van voorgaande & volgende packet in stream

9.3.4 Casus: VoIP met Skype

Meeste thuisnetwerken → NAT netwerken → NAT voorkomt host buiten thuisnetwerk verbinding met host binnen thuisnetwerk → beide Skype-bellers NAT → probleem

Super peers lossen probleem op

  1. Alice logt in → superpeer buiten netwerk toegewesen → Alice & superpeer besturingsberichten uitwisselen → idem voor Bob
  2. Alice belt Bob → informeert Alice superpeer → superpeer Bob informeert → brengt Bob op hoogte → inkomende oproep Alice
  3. Bob accepteert → 2 superpeers kiezen 3e superpeer zonder NAT → gegevens Alice en Bob uitwisselen aan elkaar koppelen

Conference calls → elke gebruiker verzendt audiostream naar deelnemer die gesprek start → deelnemer combineert audiostreams tot 1 enkele stroom → verzendt kopie van elk gecomineerde stream → elk van andere N-1 deelnemers → video elke deelnemer → gestuurd in servercluster

9.4 Protocollen voor realtime spraakapplicaties

9.4.1 RTP

Gebruikt PCM,MP3,... te transporteren

Basisprincipes van RTP

RTP boven op UDP

  1. Verzendende component verpakt chunk media-gegevens in RTP-packet
  2. Verpakt packet in UDP-segment → naar IP
  3. Ontvangende haalt RTP-packet uit UDP-segment
  4. Chunk → mediaplayer → decodeert & weergeven
  5. Verzendende omponent voegt voor elke chunk audiogegevens → RTP-header toe
  1. RTP packet → in UDP socket interface
  2. Ontvanger → applicatie ontvangt RTP van socket interface
  3. Applicatie filtert audiogegevens & headervelden van RTP packet → gegevens decoderen & afspelen

RTP geen mechanismen → tijdige bezorging van gegevens of kwaliteit diensten → geen garantie of packets aankomen of juiste volgorde

RTP → elke bron → eigen onafhankelijke RTP-packetstream → routers geen onderscheid tussen IP-datagrammen met RTP-packets & zonder RTP-packets

Headervelden van RTP-packet

9.4.2 SIP

Gesprek tot stand brengen met bekend IP-adres

  1. Alice stuurt Bob → SIP INVITE bericht → over UDP naar poort 5060 voor SIP → geeft poort aan
  2. INVITE-bericht identificatie voor Bob + indicatie huidig IP van Alice & preferred codering
  3. Bob antwoord met 200 OK bericht → poort weer, IP & preferred codering
  4. Na ontvangen Bob antwoord → SIP ontvangst bericht → erna praten

SIP kan over TCP of UDP verstuurd worden → default port 5060 → SIP berichten verstuurd en ontvangen in sockets → andere dan voor media data

SIP berichten → ASCII leesbaar → lijken op HTTP-ber

SIP-berichten

Kijk pagina 663. Voor voorbeeld

Vertalen van namen en het traceren van een gebruiker

Alice kent alleen e-mailadres Bob → dit adres ook voor SIP-gesprekken

Hoe kent proxyserver het huidige IP-adres van bob@domain.com

Elke SIP-gebruiker → registrar gekoppeld

  1. Gebruiker start SIP-applicatie
  2. Applicatie verzendt SIP-registerbericht naar registrar → informatie huidig IP gebruiker
  3. Registrar Bob → bijhouden huidig IP-adres Bob → ander SIP-apparaat → nieuw registerbericht met nieuw IP

Gebruik langere tijd → register blijft registerberichten sturen → registrar overeenkomsten met DNS-name-server → vertaalt vaste hostnamen naar vaste IP → SIP-registrar vaste menselijke identificatiegegevens → dynamische IP-adressen → SIP-registrars & proxy's op zelfde host

 

 

 

Hoe kan SIP proxy huidige IP-adres van Bob achterhalen

  1. Alice verstuurt INVITE-bericht → SIP-proxy Bob
  2. Proxy stuurt bericht naar SIP-apparaat van Bob
  3. Bob ontvangt Alice INVITE-bericht → kan antwoord sturen naar Alice

Jim@umass.edu (217.123.56.89) wil VoIP starten met Keith@upenn.edu (197.87.54.21)

  1. Jim verzendt INVITE-bericht naar SIP-proxy van umass
  2. Proxy → DNS-lookup voor SIP-registrar upenn.edu → verzendt bericht naar registrarserver
  3. Keith.upenn.edu → niet bekend bij registrar upenn → registrar omleidingsantwoordbericht → melding → umass keith.nyu.edu moet proberen
  4. Proxy umass → INVITE-bericht → SIP-registrar van NYU
  5. Registrar NYU → kent IP van keith@upenn.edu→ stuurt INVITE-bericht door naar host 197.87.54.21 → SIP-client van Keith uitvoert.
  6. Verzendt SIP-antwoordbericht → registrars/proxy's → terug naar SIP-client → 217.123.56.89
  7. Idem 6
  8. Idem 6
  9. Media → rechtstreeks tussen 2 clients verzonden → ook ACK

9.5 Netwerkondersteuning voor multimedia

9.5.1 Best-effortnetwerken dimensioneren

Eerste manier kwaliteit multimedia-applicaties te verbeteren →

Meer geld uitgeven

Bij multimedia in netwerken → voorkomen tekort aan recources → als linkcapaciteit → groot genoeg → packets door huidige internet getransporteerd → zonder queuing delays of kans op vermissing

Vraag is → hoeveel capaciteit nodig? → kosten leveren benodigde bandbreedte → reële zakelijke optie is voor ISP's → hoe groot capaciteit netwerklinks → bepaalde topologie → bepaalde end-to-endperformance te leveren = netwerkdimensioneringsprobleem

Volgende problemen moeten opgelost worden om performance van applicatielaag tussen 2 eindpunten in netwerk te kunnen voorspellen

  1. Modellen van het benodigde dataverkeer tussen eindpunten in het netwerk
  1. Goed gedefinieerde performance-eisen
  1. Modellen om end-to-endperformance bij een bepaald netwerkbelastingsmodel te voorspellen en technieken om zo gering mogelijke kosten zodanig bandbreete toe te wijzen dat aan alle eisen van de grebruikers wordt voldaan

9.5.2 Verschillende soorten diensten verlenen

Eenvoudigste uitbreiding → dataverkeer voor unitaire & egalitaire best-effortdienst → huidige internet opsplitsen in categorieën → bij dienstverlening aan verschillende categorieën → verschillende niveaus

Een paar scenarios

Principe 1: Packet markering → markeren van packets → router packets die horen bij verschillende dataverkeercategorieën van elkaar onderscheiden → originele doel (ToS) veld in IPv4

Principe 2: Isolatie dataverkeer → zekere mate van isolatie tussen categorieën implementeren → ene klasse niet nadelig beïnvloed kan worden → als iets mis is met andere categorie

2 aanpakken mogelijk:

  1. Dataverkeerpolicy → als dataverkeercategorie moet voldoen aan bepaalde criteria → controlemechanisme → zorgen policy nageleefd → als applicatie niet aan criteria houdt → mechanisme handelend optreden → dataverkeer netwerk binnenkomt voldoet aan criteria
  2. Packetschedulingmechanisme op datalinklaag → expliciet een constante hoeveelheid van linkbandbreedte te laten reserveren → elke categorie

Principe 3: Belangrijk categorieën van elkaar scheiden → wenselijk recources → efficiënt mogelijk te benutten → manier packets in wachtrij voor verzending over link worden geselecteerd = link-schedulingmethode

Leaky bucket

Policing = belangrijk QoS-mechanisme

3 policycriteria:

  1. Gemiddelde snelheid: Netwerk kan gemiddelde snelheid van packets van stream langere tijd beperken → cruciale factor → tijdsduur waarover de gemiddelde snelheid zal worden geregeld → bron begrensd 100 packets per seconde → sneller afgeremd dan bron 6000 packets/min → zelfs beide bronnen → zelfde gemiddelde snelheid
  2. Maximale snelheid: beperking van gemiddelde snelheid → begrenst hoeveelheid dataverkeer → in netwerk gezonden kan worden → relatief lange periode → beperking van maximale snelheid → begrenst # packets verzonden in korte periode
  3. Burstgrootte → Netwerk kan ook max # packets → begrenzen → dat gedurende extreem korte periode via netwerk wordt verzonden

Buckets bestaan uit → bucket dat max b tokens bevat

  1. Nieuwe tokens → in bucket → snelheid van r tokens per seconde genereerd
  2. IF bucket < b tokens → token direct in bucket
  3. Else → token genegeerd → bucket blijft gevuld met b tokens

Stel packet voor het verzonden wordt → token uit bucket halen

Omdat maximaal b tokens in bucket zitten → maximale burstgrootte voor een met leaky bucket begrense stream gelijk aan b packets

Tokens genereerd met snelheid r → maximale aantal packets → netwerk kan binnenkomen in willekeurige periode met lengte t → rt + b → snelheid r waarmee tokens genereerd worden → maat om gemiddelde snelheid → packets netwerk kunnen binnenkomen op lange termijn → begrenzen

9.5.3 Diffserv

Diffserv → differentiatie in dienstverlening → mogelijkheid verschillende categorieën dataverkeer → internet schaalbare manier

2 functionele elementen

  1. Functies aan de edge: → classificeren en coditioneren van dataverkeer → ingaande edge netwerk ( bij Diffserv-host die dataverkeer genereert of eerste Diffserv-router waarlangs dataverkeer passeert) → arriverende packets gemarkeerd
  2. Functies in de core → doorverzenden → wanneer Diffserv gemarkeerd packet → arriveert Diffserv router → doorverzonden naar volgende hop → volgens 'per-hop' voorschrift → geldt voor betreffende categorie packets → 'per-hop' voorschrift uitsluitend gebaseerd op markering van packet ( Diffserv-model)

Packets die bij edgerouter aankomen → gaclassificeerd & gemarkeerd (AFBEELDING p.679)

  1. Classificeerder selecteert packets → basis 1 of meer waarden in headervelden
  2. Verzendt packet naar betreffende markeerfunctie

Sommige gevallen host afgesproken → packetverzendsnelheid → sturen → voldoet aan bepaald dataverkeerprofiel → kan limiet op maximale overdrachtsnelheid bevatten of maximale # packets verzonden in korte tijd

Zolang gebruiker packets verzendt → voldoen aan overeengekomen waarden in dataverkeerprofiel → packets voorkeursbehandeling → wanneer verzender niet houdt aan dataverkeerprofiel, packets buiten overeenkomst vallen → andere markering of vertraagd worden of zelfs genegeerd worden aan edge netwerk

Meetfunctie → ingaande stream vergelijken met overeengekomen dataverkeerprofiel → bepalen packet binnen dat profiel past → eigenlijke beslissing over packets → netwerkbeheerder

In per-hop gedrag belangrijke overwegingen

2 'per-hop' voorschriften gedefinieerd

  1. Expedited forwarding → 'per-hop' voorschrift → vertreksnelheid van categorie → bij router = > dan geconfigureerde snelheid
  2. Assured forwarding → 'per-hop' voorschrift → verkeer in 4 categorieën → elke AF-categorie gegarandeerd → bepaalde minimale hoeveelheid bandbreedte & buffers

End-to-end-Diffserv-dienst leverren → alle ISP's tussene eind systemen → service leveren & samenwerken & afspraken maken → klant → gedifferentieerde end-to-end dienst te bieden

 

9.5.4 Per verbinding Qos-garanties geven: recources reserveren & streams toelaten

Principe 4: Nood aan nieuwe netwerk mechanics en protocollen → duidelijk wanneer stream gegearandeerde service moet ontvangen zodra gestart is

  1. Recources reserveren → enige manier garanderen → stream beschikken over benodigde recources → recources gereserveerd → stream naar behoefte benutten → gedurende gereserveerde tijd ongeacht behoeften andere streams
  2. Streams toelaten → recources gereserveerd → netwerk mechanisme hebben → streams verzoeken kunnen richten → recources niet oneindig → verzoek stream afgewezen → als gevraagde recources niet beschikbaar zijn
  3. Signaleren set-up streams → toelatingsproces → stream die QoS nodig heeft → voldoende recources reserveren → elke netwerkrouter tussen bron & bestemming → zeker zijn end-to-end-QoS-eisen hebben → elke router → lokale recources voor nieuwe stream nodig zijn berekenen → bekijken hoeveel beschikbare recources in gebruik zijn → opgestarte streams → of bepalen beschikbare per hop → toereikend QoS-eisen → honoreren Signaliseringsprotocol nodig activiteiten coördineren = call-setupprotocol → RSVP-protocol → voorgesteld voor dit doel binnen internetarchitectuur (PAGINA 683 AFBEELDING)

Active vs Passive FTP

Active FTP

  1. Client contacteert server op command poort
  2. Server stuurt ACK terug naar client's commandpoort
  3. Server initieert connectie op lokale datapoort → naar datapoort client eerder aanduidde
  4. Client stuurt ACK terug

 

Passive FTP

  1. Client contacteert server op command poort
  2. Server antwoord met poort 2024 → server verteld welke poort luisterd voor data connectie
  3. Client initieert data connectie van zijn datapoort → gespecifieerde data poort
  4. Server stuurt ACK terug naar client's datapoort

Active → SYN door client Passive → SYN door client

Revision #5
Created 17 June 2021 13:57:47 by Jasper G.
Updated 30 December 2021 19:13:38 by Jasper G.