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 Host altijd-aan (server) & handelt verzoeken van andere hosts (clients) af Meestal datacenters → anders overbelasting P2P-structuur Infrastructuurservers die altijd aan zijn → minimaal of afwezig Maakt gebruik van rechtstreekse communicatie → periodiek met elkaar verbonden hosts → peers Zelfschaalbaarheid & goedkoper 2.1.2 Communicerende processen Processen in 2 verschillende hosts → communiceren met elkaar door berichten uit te wisselen → verzendend proces creëert & verzendt berichten over netwerk → ontvangend proces ontvangt berichten en verzendt eventueel antwoordbericht Client – en serverprocessen Voor elk paar comunnicerende processen → 1 van de 2 processen  client  & andere  server Definitie client- en serverprocessen: In context van een communicatiesessie tussen 2 processen noemen we het proces dat de communicatie initieert de  client . Het wachtende proces noemen we de server In P2P kan een proces ophalen en beschikbaar stellen Interface tussen proces en computernetwerk Proces verzendt berichten naar en ontvangt berichten van het netwerk via een netwerkinterface → socket AKA API ( Application Programming Interface) Socket = soort deur → proces bericht naar ander proces sturen → bericht door deur (socket) naar buiten → verzendende proces neemt aan → andere kant deur → infrastructuur aanwezig is waarmee bericht → bij deur van huis van bestemming zal bezorgd worden → zodra bericht arriveert bij ontvangende host → passeert het de toegangsdeur van ontvangende proces → waarna ontvangende proces bericht verwerkt Adresseren van processen Om ontvangende proces te kennen moet het 2 gegevens bevatten: Het adres van de host Unieke aanduiding van ontvangende proces in ontvangende host 2.1.3 Transportdiensten voor applicaties |  Data Integriteit: Transportlaagprotocol → mogelijk een betrouwbare gegevensoverdracht tussen processen aan applicatie leveren → verzendend proces gegevens in socket duwen & is zeker van geen fouten Als er geen betrouwbare gegevensoverdracht is → mogelijkheid dat deel gegevens niet aankomen bij ontvangend proces →**verliestolerante apps (**Skype,...) |  Doorvoer Sommige apps (bijv. multimedia) vereisen een minimale verwerkingscapaciteit om "effectief" te zijn =  bandbreedtegevoelige apps   →  stellen eisen aan doorvoercapaciteit Elastische apps gebruiken de doorvoercapaciteit die op het moment beschikbaar is Timing: Sommige apps (bijv. internettelefonie, interactieve games) hebben een korte vertraging nodig om 'effectief' te zijn  Security Encryptie, data integriteit,... Diensten van TCP & UDP   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 Huidig internet presteert goed voor tijdgevoelige apps → geen garanties voor timing of doorvoercapaciteit Internettelefonieapps kan enig verlies verwerken maar wel minimale snelheid eisen om te kunnen werken → Internettelefonieapps meestal UDP → grotendeel van firewalls blokkeren UDP → ontworpen voor TCP → als back-up communicatie via UDP niet lukt 2.1.5 Protocollen voor applicatielaag In applicatielaag volgende aspecten gedefinieerd: Soorten berichten die uitgewisseld worden, request & antwoordberichten Syntaxis van verschillende soorten berichten, velden in bericht & manier waarop velden van elkaar gescheiden worden Semantiek van velden → betekenis informatie in velden Regels voor bepalen wanneer en hoe proces berichten verzendt & beantwoordt 2.1.6 Netwerkapplicaties die in dit boek beschreven worden 2.2 Web & HTTP 2.2.1 Meer over HTTP Webpagina bestaat uit aantal objecten → object is een bestand HTTP definieert hoe webclient een webserver verzoekt om een webpagina op te zoeken & hoe servers webpagina's versturen naar een client HTTP → TCP als transportprotocol HTTP-client initieert TCP-verbinding met server → verbinding tot stand → processen van browser & server TCP via socketinterfaces → client verzendt HTTP-verzoekberichten door socket → server ontvangt op zelfde manier HTTP-verzoekberichten via socket & verzendt HTTP-antwoordberichten door socket HTTP is staatloos → Server houdt geen informatie bij over eerdere clientaanvragen 2.2.2 Non-persistente en persistente verbindingen Non persistent Basis HTML-file met volgende url:  http://www.someschool.edu/someDepartment/home.index HTTP-client starts TCP-verbinding met server → client & server gebruiken socket HTTP-client verzendt HTTP-verzoekbericht naar HTTP HTTP-serverproces ontvangt verzoekbericht HTTP-serverproces TCP opdracht → verbreek verbinding als bericht ontvangen HTTP-client ontvangt antwoordbericht 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: Client verzendt TCP-segment naar server Server bevestigt & antwoord met TCP-segment Client verzendt 2e bevestiging naar server → 1 RTT Na 1&2 → verzendt client HTTP-verzoekbericht + 3e deel van 3way-handshake Totale responstijd = 2 RTT's + transmissietijd HTML-bestand server Persistent Bij non persistent → elk opgevraagd object een nieuwe verbinding tot stand gebracht & gehouden worden Bij non persistent → elk object 2 RTT's vertraging → 1 voor TCP-verbinding starten & 1 om TCP-verbinding object op te vragen & ontvangen HTTP 1.1 persistent → server laat TCP-verbinding intact na respons 2.2.3 Indeling HTTP-berichten HTTP-verzoekbericht Eerste regel → requestregels Volgende regels → headerregels Host → host waar opgeslagen object is Connection: close → geen persistente verbinding nodig User Agent: → type browser POST → stuurt velden dat gebruiker heeft ingevuld door GET → 2 velden ( x & y ) → structuur URL → www.eensite.nl/zoekIets?x&y HEAD → server reageert HTTP-bericht zonder opgevraagde object te verzenden HTTP-antwoordbericht Statusregel, 6 headerregels & entity body Connection: close → client weet TCP-verbinding weg na bericht verstuurd Server: → geeft aan gegenereerd door Apache-webserver Last-Modified: cachen objecten → lokaal & server Content-length: → grootte object 2.2.4 Interactie gebruikers & servers: cookies Cookieheaderregel in HTTP-antwoordbericht Cookieheaderregel in HTTP-verzoekbericht Cookiebestand opgeslagen op host gebruiker & browser van gebruiker beheerd 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 Browser start TCP-verbinding met webcache & verzendt HTTP-verzoek voor object naar webcache Webcache checks → exemplaar opgevraagde object aanwezig? → if yes → webcache verzendt object in HTTP-antwoordbericht naar browser client 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 Opslaan kopie lokaal & stuurt een exemplaar naar browser 2 redenen webcaching Responstijd clientverzoek verkorten Webcaches belasting van link van instituut verlagen CDN  (Content Distribution Networks) → veel geografische verspreide cachegeheugens in internet → groot deel dataverkeer lokaal 2.2.6 The conditional GET Verzoekbericht methode GET Verzoekbericht bevat If-Modified-Since Client maakt get request Server reageert met header Client checkt de Last-Modified header ls Last nieuwer is dan cache → haal pagina opnieuw op & zet opnieuw in cache 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 Server antwoord in-order (  FCFS  :  first-come-first-served scheduling  ) naar GET requests Met FCFS, mogelijkheid dat kleine objects moeten wachten voor transmissie (Head-of-line (HOL) blocking) achter grote objects Herstel van loss (retransmissie van verloren TCP segmenten) stalls object transmissie HTTP/2 ** :** flexibiliteit verhogen server in versturen van objects naar client  Goal:  vertraging verlagen in multi-object HTTP requests Methoden, status codes, meeste header velden onveranderd tov HTTP 1.1 verzendvolgorde van aangevraagde objecten op basis van door de klant opgegeven objectprioriteit (Niet noodzakelijk FCFS) Push unrequested objects naar cleint Verdeel objects in frames, plan frames om HOL-blokkering te verminderen HTTP/2 to HTTP/3 Goal:  vertraging verlagen in multi-object HTTP requests HTTP/2 over single TCP connectie wil zeggen: Herstel packet loss vertraagt nog steeds alle objecttransmissies In HTTP 1.1 browsers → stimulans om meerdere TCP-verbindingen te openen → vertraging verminderen → algehele doorvoer te verhogen Geen security over vanilla TCP-verbinding HTTP/3 → adds security → per object fout- & congestie-controle ( meer pipelining) over UDP 2.3 E-mail op het internet 2.3.1 SMTP Werking: Alice → UA opdracht verstuur bericht Alice's UA stuurt bericht mailserver→ in berichtenwachtrij Clientzijde van SMTP opent TCP-verbinding met Bob's e-mailserver SMTP-client verzendt het bericht van Alice via de TCP-verbinding Bob's mailserver plaatst het bericht in Bob's mailbox Bob roept zijn user agent aan om bericht te lezen 2.3.2 Vergelijking met HTTP SMTP Transfers files van 1 mail server naar een andere mail server PUSH  protocol: verzendende e-mailserver duwt bestand naar e-mailserver van ontvanger Elk bericht moet in 7-bit ASCII zijn Plaatst alle bericht objecten in 1 bericht HTTP Transfers files van web server naar web client PULL  protocol: Iemand zet informatie op een webserver & gebruiker gebruikt HTTP om informatie van server ophalen wanneer het hem uitkomt Restrictie niet nodig Encapsuleert elk object in zijn eigen HTTP response message 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 Autorisatiefase: UA → verstuurt username & password → identitetit gebruiker vaststellen Transactiefase: UA haalt berichten op Updatefase: client opdracht quit → POP3-sessie closed IMAP Koppelt elk bericht aan een map Biedt opdrachten → UA afzonderlijke componenten van bericht 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 Een gedistribueerde database → geïmplementeerd in hiërarchie van DNS-servers Applicatielaagprotocol waarmee hosts & DNS-servers kunnen communiceren om vertaalslag ( omzetten IP → "te onthouden" adres & omgekeerd) DNS verzorgt aantal andere diensten naast vertalen hostnamen in IP-adressen: Host-aliasing:  1 of meerdere aliassen wanneer hostname te lastig is → canonieke hostnaam → aliashostnamen gebruikt → gemakkelijker te onthouden dan canonieke hostnamen Mailserver-aliasing:  Hostnaam van een mailserver (bv. Yahoo) → moeilijker dan → eenvoudige Yahoo.com → DNS kan door mailapplicatie gebruikt worden → achterhalen canonieke hostnaam v/e bepaalde host + IP-adres van host → MX record maakt mogelijk dat mailserver & webserver van bedrijf dezelfde hostnamen hebben → mailserver & webserver van bedrijf kunnen dus bv. enterprise.com heten. (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) Loadbalancing:  Belasting van gerepliceerde servers te verminderen → gerepliceerde webservers een serie IP-adressen gekoppeld aan canonieke hostname → DNS-database bevat serie IP-adressen 2.4.2 Overzicht van de werking van het DNS Gecentraliseerd ontwerp levert volgende problemen op: Single point of failure:  als DNS crashed hele internetonbruikbaar Netwerkbelasting  : 1 DNS-server → alle DNS-verzoekberichten verwerken ( alle HTTP-verzoekberichten & e-mails van honderden miljoenen hosts) Afstand tot gecentraliseerde database  : 1 enkele DNS-server kan niet 'in de buurt' van alle verzoekende clients staan → centrale DNS bijvoorbeeld in Antwerpen → verzoeken uit Nieuw-Zeeland → kan vertraging veroorzaken Onderhoud  : die DNS-server informatie over alle internethosts moeten beheren → database wordt dan heel groot & telkens bijgewerkt moeten worden wanneer nieuwe host wordt aangemeld. Een gedistribueerde, hiërarchische database Root-DNS-servers:  meer dan 400 root-nameservers verspreid over de wereld → door 13 verschillende organisaties gemanaged → leveren IP adressen van TLD-servers Topleveldomein (TLD) -servers:  voor elk TLD (com,org,net,edu,...) & landTLD(nl,fr,ca,...) → is er een TLD → TLD leveren IP-adressen voor authoritative DNS-servers Authoritative DNS-servers:  eigen DNS-server(s) van de organisatie, die gezaghebbende hostnaam biedt aan IP-toewijzingen voor de benoemde hosts van de organisatie + kan Dutch translation. kakjkworden onderhouden door organisatie of dienstverlener Lokale DNS-server behoort niet tot hiërarchie maar wel belangrijk voor DNS-structuur → elke ISP zoals een standaard ISP of ISP van instituut → lokale DNS-server → wanneer host verbinding tot stand wil brengen met ISP → ISP geeft aan die host IP-adressen van 1 of meer van diens lokale DNS-server → lokale DNS-server niet ver weg van host → bij residentiële ISP DNS-server → gescheiden enkele routers van host van client → host verzoekbericht aan DNS verzendt → doorgestuurd lokale DNS-server → fungeert als proxy → verzoek verder gestuurd in DNS-serverhiërarchie Recursief DNS-verzoek = host stuurt verzoek aan lokale DNS-server, die op zijn beurt een verzoek doet aan de root-server, die op zijn beurt een verzoek doet aan de TLD-server … (zie p127) Iteratief DNS-verzoek = host stuurt verzoek aan lokale DNS-server, die op zijn beurt een verzoek doot aan de root-server, de root-server stuurt antwoord naar lokal DNS-server die op haar beurt een verzoek doet aan de TLD-server… (zie p126) 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) If Type = A  then naam bevat hostnaam en Waarde bevat IP-adres van hostnaam 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 If Type = CNAME  then waarde is canonieke hostname voor aliashostname 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 Eerste 12 bytes voor de header: 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 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 Vraagveld bevat informatie over het verzonden verzoek: Bevat een naamveld met de naam waarvoor het IP-adres wordt gezocht Bevat een typeveld met het type verzoek (Type A, Type NS…) In een antwoordbericht staat in het antwoordveld de bronrecords van het oorspronkelijke DNS-verzoek Het autorisatieveld bevat gegevens van andere authoritative DNS-servers Het aanvullingsveld bevat aanvullende bronrecords (Het antwoordveld in een antwoord op een MX-verzoek bevat een bronrecord met de canonieke hostnaam van de mailserver en het aanvullingsveld bevat het een Type A record met het IP-adres van de canonieke hostnaam van de mailserver   DNS-Security DDOS-attack: root servers belasten met verkeer Tot op heden niet succesvol Verkeersfiltering Lokale DNS-servers cache-IP's van TLD-servers waardoor rootserver bypassed TLD servers bombarderen: Kan gevaarlijker zijn maar moeilijker → TLD servers niet zo gemakkelijk bypassed Aanvallen omleiden Man in the middle → DNS queries intercepten DNS poisoning → valse afhankelijkheden verzenden naar dns-server, die cachen DNS voor DdoS exploiteren Queries versturen met vervalste bronadres → target IP Vereist versterking 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 Video → sequentie van afbeeldingen → afgebeeld constante snelheid Bijvoorbeeld: 24 afbeeldingen / seconde Digital image → array van pixels Elke pixel gerepresenteerd door bits Coding: Gebruikt redundantie binnen en tussen afbeeldingen om # bits te verminderen die worden gebruikt om abeeldingen te gebruiken Spatial → binnen afbeelding Temporal → van 1 afbeelding naar volgende CBR → constant bit rate → video encoding rate is fixed VBR → variable bit rate → wijzigingen in videocoderingssnelheid als hoeveelheid spatial, temporal codering wijzigt 2.6.1.1 Streaming stored video Simpel Scenario: Hoofddoelen: Server to client bandbreedte varieert over tijd met veranderende netwerkcongestieniveaus → ( in huis, in acces network, network core, video server) pakketverlies en vertraging als gevolg van congestie zullen de play-out vertragen of resulteren in een slechte videokwaliteit 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 Server Deelt video bestand in meerdere chunks Elke chunk stored, gecodeerd met verschillende snelheden Manifestbestand  : biedt URL's voor verschillende chunks Client Meet periodiek server-naar-client bandbreedte Adviesmanifest, vraagt 1 chunk tegelijk Kiest voor max coderingssnelheid duurzaam gezien huidige bandbreedte Kan verschillende coding rates kiezen op verschillende punten in tijd → afhankelijk vrije bandbreedte STREAMING VIDEO = CODERING + DASH + PLAYOUT BUFFERING Content Distribution Networks (CDNs) Challenge: Hoe content streamen naar 100 tot 1000'en gebruikers tegelijk Optie 1: 1 grote server Single point of failuire Punt van netwerkcongestie Lange weg naar clients die verweg zijn meerdere kopieën van video verzonden via uitgaande link Deze oplossing  schaalt niet Optie 2: meerdere kopieën van video's opslaan/weergeven op meerdere geografisch gedistribueerde sites → (CDN) Enter deep → push CDN servers diep in veel access networks → dichtbij users Bijvoorbeeld: Akamai → 240k in meer dan 120 landen Bring home: kleinere nummers (10's) of grotere clusters in POP's dichtbij access netwerken CDN → slaagt kopieen van content op aan CDN nodes Subscriber vraagt content van CDN → gericht nabijgelegen kopie & haalt inhoud op kan een andere kopie kiezen als het netwerkpad overbelast is Hoofdstuk 8: Security in computer networks 8.1 Wat is netwerkbeveiliging Vertrouwelijkheid  : Alleen zender & beoogde ontvanger inhoud van verzonden bericht begrijpen Berichtintegriteit  : de afzender en ontvanger zeker zijn dat inhoud van communicatie niet wordt gewijzigd Authenticatie op eindpunt:  zender & ontvanger identiteit andere partij vaststellen zeker te zijn dat ander is wie hij beweert 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) X gebruikt sleutel  K ** A**→ invoer versleutelalgoritme Versleutelalgoritme gebruikt sleutel → onversleutelde bericht m → versleutelde tekst →  K ** A****(m)** KA onderling afspreken Y ook sleutel  K ** B **** →**invoer onsleutelalgoritme → versleutelde bericht X → plaintext Y ontvangen versleutelde bericht KA(m) → ontsleutelen → berekenen van Kb(Ka(m)) = m Symmetrische sleutelsystemen → sleutels X & Y identiek en geheim Openbare sleutelsystemen → 2 verschillende sleutels → 1 v/d 2 zowel bij X als Y bekend 8.2.1 Cryptografie met symmetrische sleutels First  → Caeser cipher → elke letter in platte tekst → letter → k-letters in alfabet te vervangen Daarna  → monoalfabetisch cijfer → lettervervanging maar moet uniek zijn Bruteforce-benadering → uitproberen alle 10^26 → teveel werk Aanval met alleen versleutelde tekst  → indringer beschikt alleen over onderschepte versleutelde tekst → niet over informatie van inhoud → onversleutelde bericht Aanval met bekende onversleutelde tekst  → Indringer (Z) → kent enkele combinaties van onversleutelde & versleutelde tekst Aanval met specifieke onversleutelde tekst   →  Z kiest onversleuteld bericht → corresponderende versleutelde tekst krijgen → als Z → X een bepaalde zin kan laten verzenden → versleutelmethode verbroken 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 Stream cipher Block cipher Blockciphers versleutelen bericht → verwerkt blokken k bits IF  k = 64 → bericht opgesplitst in 64 blokken → elk blok onafhankelijk versleuteld Codering 1 op 1 toewijzing om k-bit blok cleartext toe te wijzen aan k-bit blok Ciphertext Hoeveel mogelijke verwijzingen? k = 3 dan zijn er 23 mogelijke ingangen. Deze ingangen kunnen in 8 worden gepermuteerd! = 40 320. 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: voor bericht versleutelt → genereert Afzender  een willekeurige k-bit string,initialisatievector (IV) = c(0)  genoemd→ afzender stuurt IV naar ontvanger in leesbare vorm 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 Voor het i-blok genereert de afzender  c(i) = Ks(m(i) + c(i-1)) 8.2.2 Cryptografie met openbare sleutel 2 partijen delen gedeeld geheim →Symmetrische sleutel voor encryptie & decryptie Diffie-Hellman key exchange Alice haalt Bob's publieke sleutel Alice versleutelt bericht (m) aan Bob → door public key van Bob en bekend encryptie-algoritme K+B(m). Bob ontvangt → gecodeerde bericht van Alice → gebruikt private key & bekend decoderingsalgoritme → gecodeerde bericht decoderen Bob berekent K-B( K+B(m)). 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 . RSA Maken van publieke en private RSA keys: Kies 2 grote priemgetallen p & q → hoe groter de waarden hoe moeilijker RSA-algoritme te kraken Bereken n = p * q Bereken z = (p – 1) * (q-1) Kies nummer e, dat kleiner is dan n & geen factoren (buiten 1 ) gemeenschappelijk heeft met z Zoek een getal d, zodanig dat ed – 1 precies deelbaar is door z. Wij kiezen d zodanig dat e*d mod z = 1 Openbare sleutel (K+B) is het paar van de getallen (n, e) The private key(K-B) is the pair of the numbers (n, d) Encrypteren → C = me mod n Decrypteren → m = cd mod n. Which requires the use of the private key (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 Rekentechnisch onmogelijk → 2 verschillende berichten x en y te vinden → waarbij H(x) = H(Y) Onmogelijk voor indringer → bericht vervangen door ander bericht dat beveiligd is met hashfunctie Om veiligheidsredenen  hebben we een krachtigere hash-functie nodig dan een checksum → het  MD5-hash-algoritme.  Het berekent een 128-bits hash in een proces in  vier stappen  dat bestaat uit: een opvulstap een toevoegstap een initialisatie van een accumulator een laatste loopingstap waarin de blokken van 16 woorden van het bericht in vier rondes worden verwerkt Het tweede belangrijke hash-algoritme is het  Secure Hash Algorithm (SHA1).  Het produceert een 160-bits berichtcijfer. De langste output maakt SHA1 veiliger. 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: Alice maakt bericht m, samenvoegt s met m om m + s te maken en berekent de hash (m+s). → berichtverificatiecode (MAC =  Message Authentication Code  ) Alice voegt vervolgens de MAC toe aan het bericht m, maakt een uitgebreid bericht (m, H(m+s)) en stuurt het naar Bob Bob ontvangt het bericht (m, h) en weet s, berekent de MAC H(m+s). Als H(m+s) = h, dan is alles in orde met de boodschap 8.3.3 Digitale handtekeningen Certificering van openbare sleutels Certificate authority → echtheid identiteiten authenticeert & certificaten uitgeeft Een certification authority controleert of een entiteit is wie het zegt dat het is. 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. Alice stuurt haar geheime wachtwoord naar Bob. De beveiligingsfout hier is dat als Trudy Alice's communicatie afluistert, ze Alice's wachtwoord kan leren. 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: Alice verzendt bericht 'ik ben Alice' aan Bob Bob kiest een nonce en verzendt die naar Alice 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. 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) Bericht versleutelen → symmetrische sleuteltechnologie (DES) → ontvanger bericht ontsleutelen Alternatief → cryptografie openbare sleutel (RSA) Om dit efficiëntieprobleem op te lossen, maken we  gebruik van een sessie   key: Alice selecteert een willekeurige symmetrische sessiesleutel (Ks) Versleutelt haar bericht m met de symmetrische sleutel Versleutelt de symmetrische sleutel met Bob's openbare sleutel K+b Voegt het gecodeerde bericht en de gecodeerde symmetrische sleutel samen om een pakket te vormen stuurt het pakket naar Bob's e-mailadres.  (zie p 586 onderaan voor schema) Bob ontvangt pakket: Gebruikt geheime sleutel Kb-→ verkrijgen symmetrische sleutem Ks Symmetrische sleutel Ks → ontsleutelen bericht Sessie key = inefficient 1. Berichtintegriteit Digitale handtekeningen: Alice past hashfunctie H toe Versleutelt resultaat met hashfunctie → met geheime sleutel KA- → digitale handtekening Oorspronkelijke bericht samen met handtekening → 1 pakket Verzend pakket → e-mail Bob Bob ontvangt het pakket Openbare sleutel Alice KA+ → op ondertekende hash Vergelijkt resultaat bewerking met eigen hash H van bericht The 2 combined: Alice maakt eerst een voorlopig pakket, dat bestaat uit haar originele bericht samen met een digitaal ondertekende hash van het bericht Vervolgens behandelt ze dit voorlopige pakket als een bericht op zich en stuurt dit nieuwe bericht via  de stappen van de afzender van (a) , waardoor een nieuw pakket wordt gemaakt dat naar Bob wordtverzonden  (zie schema p   586 ** )** 8.5.2 PGP PGP-software gebruikt: MD5 of SHA → berekenen hash CAST, Triple-DES of IDEA → versleutelen symmetrische sleutel RSA versleuteling openbare sleutel Als PGP installed: Openbaar sleutelpaar voor gebruiker Openbare sleutel → website gebruiker of openbare sleutelserver Persoonlijke sleutel beschermd → wachtwoord PGP → mogelijkheid bericht digitaal ondertekenen 8.6 TCP-verbindingen beveiligen Noodzaak SSL: Geen versleuteling → indringer Bobs bestelling onderscheppen → creditcardgegevens achterhalen Integriteit gegevens niet gecontroleerd → bestelling veranderen Server niet geauthenticeerd → Valse website maken → gegevens stelen SSL lost problemen op door volgende bovenop TCP uit te voeren: Vertrouwelijkheid Gegevensintegriteit Serverauthenticatie Clientauthenticatie SSL → eenvoudige API vergelijkbaar API van TCP 8.6.1 Het hele verhaal, maar vereenvoudigd Fase 1: Handshake Bob TCP-verbinding met Alice maken Verzekeren dat Alice echt Alice is 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: EB:  session encryption key  for data sent from Bob to Alice MB:  session MAC key  for data sent from Bob to Alice EA: session encryption key for data sent from Alice to Bob MA: session MAC key for data sent from Alice to Bob Fase 3: Gegevensoverdracht Geen goed idee → integriteit alle gegevens tijdens hele sessie dat Bob gestuurd heeft controleren SSL splitst gegevensstream → records SSL voegt berichtauthenticatiecode toe aan elk record → versleutelt combinatie Maken van berichtauthenticatiecode → Bob hashfunctie toe → combinatie recordgegevens & sleutel Mb 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 TCP in host Alice → denkt alles is OK → 2 records aan SSL-sublaag SSL in host Alice → 2 records ontsleutelen SSL in host Alice →berichtauthenticatiecode in elk record gebruiken → integriteit van gegevens in 2 records SSL → ontsleutelde bytestream van 2 records doorgeven → applicatielaag → door Alice ontvangen bytestream → gevolg verwisseling records → niet in juiste volgorde Oplossing: gebruik volgnummers . Bob onderhoudt een reeksnummerteller, die begint bij nul en wordt verhoogd voor elke SSL-record die hij verzendt. 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: Client verzendt lijst → versleutelalgoritmen die hij ondersteunt & zelfgekozen nonce Server kiest uit ontvangen lijst algoritme voor → symmetrische sleutel, openbare sleutel & berichtauthenticatiecode → server verstuurt bericht met voorkeuren, certificaat & zelfgekozen nonce Client authenticeert certificaat + berekent openbare sleutel server + genereert geheime pre-mastersleutel (PMS) → versleutelt PMS met openbare sleutel server → verzendt versleutelde PMS naar server 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 Client verzendt berichtauthenticatiecode → alle handshakeprocedureberichten 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 R1 voegt achter aan oorspronkelijke IPv4-datagram een ESP-trailerveld toe R1 versleutelt resultaat met behulp van het algoritme & de sleutel die voor de beveiligingsassociatie zijn overeengekomen R1 voeg aan voorkant van versleutelde geheel → veld toe → ESP-header → Resulterende pakket → enchilada R1 voegt berichtauthenticatiecode toe aan achterkant van versleutelde geheel → alles te samen → inhoud van payloadveld R1 creëert een nieuwe IP-header met alle klassieke IPv4-headervelden → voegt voor payloadveld toe 8.7.5 sleutelbeheer in IPsec (IKE) IKE kent twee fase Fase1: Vaststellen bidirectionele IKE SA opmerking: IKE SA anders dan IPsec SA ook bekend als ISAKMP security association Fase 2: ISAKMP wordt gebruikt om veilig te onderhandelen over IPsec-paar SA's fase 1 heeft twee modi: agressieve modus en hoofdmodus Agressieve modus gebruikt minder berichten Hoofdmodus biedt identiteitsbescherming en is flexibeler IKE-berichtenuitwisseling voor algoritmen, geheime sleutels, SPI-nummers AH- of ESP-protocol (of beide) AH biedt integriteit, bronverificatie ESP-protocol (met AH) biedt bovendien versleuteling IPsec-peers kunnen twee eindsystemen zijn, twee routers/firewalls, of een router/firewall en een eindsysteem   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: Alle dataverkeer van buiten naar binnen & omgekeerd passeert firewall Alleen geauthenticeerd dataverkeer → gedefinieerd in lokale beveiligingspolicy's mag passeren Firewall kan niet zelf benaderd worden Traditionele packetfilters Filterbeslissingen meestal genomen op basis van: IP-bronadressen of IP-bestemmingsadressen Typeveld in IP-datagram TCP- of UDP-bronpoorten en -bestemmingspoorten TCP-vlagbits: SYN, ACK,... ICMP-berichttype Verschillende regels voor datagrammen die netwerk binnenkomen en verlaten Verschillende regels voor verschillende routerinterfaces Organisatie kan filteren op: TCP-SYN-segmenten → geen inkomende TCP-verbindingen toestaan behalve voor publieke webserver → alle TCP-SYN-segmenten blokkeren behalve → TCP-SYN-segmenten bestemmingspoort 80 & bestemmings-IP overeenkomt met webserver TCP-ack-bit → interne clients verbinden met externe servers → externe clients niet verbinden met interne servers 2e mogelijkheid → DNS-packets netwerk kunnen binnenkomen & verlaten → blokkeert al het dataverkeer → behalve webdataverkeer binnen organistatie & DNS-dataverkeer 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 Firewall controleert lijst met  toegangsbeheer  ( traditionele packetfilters ) Verbindingstabel controleren voor packet in netwerk van organisatie kan komen Controleert verbindingstabel → geen deel van lopende TCP-verbinding → weigert 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 Gebruiker Telnet-sessie starten met applicatiegateway → op gateway draait applicatie → wacht voor inkomende Telnet-sessies tot stand komen Applicatie vraagt username & password IF informatie = correct → applicatiegateway checkt IF gebruiker = gerechtigd is → als dat het geval is Gateway vraagt gebruiker → hostname externe host ingeven Gateway Telnet-sessie → tussen gateway & externe host Gateway verzendt alle gegevens afkomstig van externe host naar gebruiker & omgekeerd 8.9.2 Intrusion-detectionsystems Intrusiondetectionsysteem  (IDS) → waarschuwt wanneer mogelijk schadelijk dataverkeer detecteerd Intrusion-preventionsysteem  (IPS) → Apparaat dat schadelijk dataverkeer blokkeert 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 Streng beveiligd deel → afgeschermd door → packetfilter & applicatiegateway → bewaakt door IDS sensoren 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 Systemen die werken met handtekeningen database met aanvalskenmerken (handtekeningen) → elke handtekening → verzameling regels → gebruikt verdachte activiteit → kan lijst met kenmerken 1 packet → vergelijkt packets met handtekening in database → overeenkomst in database → waarschuwing Beperkingen: dit soort IDS → alleen als voorkennis over aanval is → gebruikt nauwkeurige handtekening te vervaardigen → blind als er nieuwe aanvallen zijn packet → zelfs als er bekende handtekening is → niets te maken met een aanval → false-positive warning IDS kan overvoerd geraken → elk packet vergeleken moet worden → uitgebreide verzameling handtekeningen → kan zover komen dat IDS schadelijke packets niet detecteert Op anomalie gebaseerde systemen Creëert profiel → normale verloop → gecontroleerde dataverkeer → zoekt packetstreams statisctisch ongebruikelijk zijn Niet afhankelijk van voorkennis bestaande aanvallen Wel moeilijk → efficiënt onderscheid maken → normaal dataverkeer & statistisch ongebruikelijk verkeer 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 Hoge bit rate  : 100kbps voor low-quality video conferencing → 3 Mbps streaming high-definition movies. → bitsnelheidvereisten van video belangrijk ontwerpen netwerkvideotoepassing Een niet-gecomprimeerde, digitaal gecodeerde afbeelding → reeks pixels→ elke pixel gecodeerd in aantal bits om luminantie en kleur weer te geven. 2 Types redundantie in video → exploited door video compressie Tijdelijke redundantie   →  werkt met verschillen tussen opeenvolgende afbeeldingen Spatial redundancy   →  redundantie binnen een bepaalde afbeeling 9.1.2 Eigenschappen van audio Digitale audio → lagere bandbreedte nodig dan video → Pulse Code Modulation (PCM) → coderen spraak → 8000 samples/seconde & 8 bits per sample → bitsnelheid 64 kbps Compressietechniek voor stereomuziek → MP3 → bitsnelheid 128 kbps → geluidskwaliteit slechter Advanced Audio Coding (AAC) → meerdere versies vooropgenomen audio stream kan gemaakt worden → elke klein verschil bit rate 9.1.3 Soorten multimedianetwerkapplicaties Streamen van opgeslagen audio / video Streamen van opgeslagen video 3 belangrijke onderscheidende kenmerken Streamen → client begint video → binnen enkele seconden na ontvangst weer te geven → client video weergeeft → bepaalde plaats in opname & tegelijk latere delen van die opname ontvangt van server =  streamen Interactiviteit → media vooraf opgenomen → gebruiker weergave onderbreken, doorspoelen,... → voor aanvaardbare gebruikskwaliteit → tijd tussen moment gebruiker actie start & uitvoering actie → enkele seconden Continue weergave → zelfde snelheid weergeegven als orgineel → gegevens op tijd van server ontvangen → voor moment client moet weergeven → anders haperingen Gemiddelde doorvooercapaciteit → netwerk streamapplicatie → gemiddelde doorvoorcapaciteit bieden → ten minste even groot als bitsnelheid video 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 Fluctuaties in vertraging tussen server en client opvangen 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: Streamen met constante snelheid → voor continue weergave → problemen opleveren als gevolg van onvoorspelbaare & wisselende beschikbare bandbreedte Streamen met UDP → server nodig om media te besturen → interactieve verzoeken tussen client en server afhandelen & toestand client bewaren → voor elke sessie 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 Client start TCP-verbinding met server Verzendt HTTP-GET-bericht Server verzendt video bestand in HTTP-antwoordbericht Clientcomponent applicatie verzamelt bytes in buffer Zodra # bytes in buffer > bepaalde drempelwaarde 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 Verzender genereert bytes met snelheid → 8000 bytes/seconde → iedere 20 ms verzamelt bytes in stuk →  chunk 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 Bepalen wanneer chunk moet weergegeven worden 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 Transmission delay Processing delay Queing delays routers Propagation delays in verbindingen Processing delays hosts 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 Elke chunk vooral laten gaan door tijdstempel → verzender voegt aan elk nieuw gegenereerd packet → informatie over tijdstip → packet werd gegenereerd 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 Schatting van de pakketvertraging ( di ) = schatting gemiddelde netwerkvertraging moment i-de packet arriveert bij ontvanger Schatting gemiddelde afwijking van vertraging ( vi ) = geschatte gemiddelde afwijking vertraging ten opzichte van de geschatte gemiddelde vertraging → di gemiddelde werkelijke netwerkvertragingen $rarr; r1 - t1,...,ri-ti Schattingen di & vi berekend elk ontvangen pakket → als packet i → 1e packet in spraaksessie → weergavemoment pi berekend $rarr; pi = ti + di + Kvi Term Kvi → weergavemoment zover in toekomst verschoven → klein gedeelte packets te laat arriveren in spraaksessie Stel dat qi = tj + qi → tijd tussen moment 1e packet in spraaksessie genegeerd & moment packet weergegeven → als packet j ook hoor bij spraaksessie → wergegeven op tijdstip → pj = tj + qi 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 Skype werkt met hiërarchisch overlaynetwerk Peer kan "superpeer" of gewone peer zijn Werkt met index → koppelt IP-adressen aan gebruikers Index gedistribueerd over superpeers Alice belt Bob → Skype client zoekt distribueerde index → Bob's IP adres bepalen Meeste thuisnetwerken → NAT netwerken → NAT voorkomt host buiten thuisnetwerk verbinding met host binnen thuisnetwerk → beide Skype-bellers NAT → probleem Super peers lossen probleem op Alice logt in → superpeer buiten netwerk toegewesen → Alice & superpeer besturingsberichten uitwisselen → idem voor Bob Alice belt Bob → informeert Alice superpeer → superpeer Bob informeert → brengt Bob op hoogte → inkomende oproep Alice 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 Verzendende component verpakt chunk media-gegevens in RTP-packet Verpakt packet in UDP-segment → naar IP Ontvangende haalt RTP-packet uit UDP-segment Chunk → mediaplayer → decodeert & weergeven Verzendende omponent voegt voor elke chunk audiogegevens → RTP-header toe Type van audiocodering Volgnummer Tijdstempel RTP packet → in UDP socket interface Ontvanger → applicatie ontvangt RTP van socket interface 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 Volgnummerveld (16 bits) → verhoogt met 1 voor elk verstuurde RTP-packet → gebruikt door ontvanger om packet loss & volgorde van packets herstellen Tijdstempelveld (32 bits) → ontvanger tijdstempels → packetjitter compenseren & packets met zelfde snelheid weergeven als waarin verzonden → als applicaties 160 gecodeerde samples maakt → tijdstempelveld verhoogt met 160 voor elk RTP-packet wanneer bron actief → tijdstempelveld klok loopt met constante snelheid → zelfs if bron = inactief Bronidentificatieveld / (  Synchronization Source Identifier  of  SSRC  (32 bits) → identificeerd bron van RTP stream → elke RTP sessie heeft unieke bronidentificatie 9.4.2 SIP Levert mechanismen → gesprekken over IP-netwerk → beller kan diegene die gebeld wordt waarschuwen → gesprek wil → beide partijen afspraken maken over codering van media → beide deelnemers ook gesprek beëindigen Mechanismen → beller huidige IP-adres bepalen van gebelde → gebruikers geen vast IP → dynamisch toegewezen → verschillende IP-apparaten Mechanismen → beheren gesprekken → bv. Toevoegen nieuwe mediastreams, doorschakelen van gesprekken, ... Gesprek tot stand brengen met bekend IP-adres Alice stuurt Bob → SIP INVITE bericht → over UDP naar poort 5060 voor SIP → geeft poort aan INVITE-bericht identificatie voor Bob + indicatie huidig IP van Alice & preferred codering Bob antwoord met 200 OK bericht → poort weer, IP & preferred codering 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 Gebruiker start SIP-applicatie Applicatie verzendt SIP-registerbericht naar registrar → informatie huidig IP gebruiker 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 Alice verstuurt INVITE-bericht → SIP-proxy Bob Proxy stuurt bericht naar SIP-apparaat van Bob 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) Jim verzendt INVITE-bericht naar SIP-proxy van umass Proxy → DNS-lookup voor SIP-registrar upenn.edu → verzendt bericht naar registrarserver Keith.upenn.edu → niet bekend bij registrar upenn → registrar omleidingsantwoordbericht → melding → umass keith.nyu.edu moet proberen Proxy umass → INVITE-bericht → SIP-registrar van NYU Registrar NYU → kent IP van  keith@upenn.edu → stuurt INVITE-bericht door naar host 197.87.54.21 → SIP-client van Keith uitvoert. Verzendt SIP-antwoordbericht → registrars/proxy's → terug naar SIP-client → 217.123.56.89 Idem 6 Idem 6 Media → rechtstreeks tussen 2 clients verzonden → ook ACK 9.5 Netwerkondersteuning voor multimedia Beste maken van de best-effortdienst  → toenames van vraag voorspeld → ISP's extra bandbreedte & switches in → acceptabele mate vertraging & packetloss te garanderen Diensten in verschillende categorieën aanbieden   →  1 type van verkeer → kan hogere prioriteit krijgen dan een ander type Per verbinding andere QoS-garanties geven  → per verbiending QoS garantie → elke instantie van applicatie → bandbreedte reserveren → garanties end-to-endperformance →  harde garantie  → applicatie zeker de gevraagde QoS zal ontvangen →  Zachte garantie  → grote waarschijnlijkheid de gevraagde QoS zal ontvangen 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 Modellen van het benodigde dataverkeer tussen eindpunten in het netwerk Mogelijk modellen gedefinieerd worden op gespreksniveau Goed gedefinieerde performance-eisen Performance eis stellen dat gevoelig is voor vertraging → kans end-to-endvertraging van packets groter is dan max te tolereren vertraging 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: 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 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: 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 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 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 Nieuwe tokens → in bucket → snelheid van r tokens per seconde genereerd IF bucket < b tokens → token direct in bucket 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 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 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) Classificeerder selecteert packets → basis 1 of meer waarden in headervelden 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 'per-hop' voorschrift → zorgen verschillende categorieën dataverkeer → verschillende diensten Per-hop voorschrift verschilt → behandeling tussen categorieën definieert → geen expliciete informatie hoe voorschrift uitvoeren Verschillen in performance moeten dus zichtbaar & meetbaar zijn 2 'per-hop' voorschriften gedefinieerd Expedited forwarding  → 'per-hop' voorschrift → vertreksnelheid van categorie → bij router = > dan geconfigureerde snelheid 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 Recources reserveren  → enige manier garanderen → stream beschikken over benodigde recources → recources gereserveerd → stream naar behoefte benutten → gedurende gereserveerde tijd ongeacht behoeften andere streams Streams toelaten  → recources gereserveerd → netwerk mechanisme hebben → streams verzoeken kunnen richten → recources niet oneindig → verzoek stream afgewezen → als gevraagde recources niet beschikbaar zijn 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 Client contacteert server op command poort Server stuurt ACK terug naar client's commandpoort Server initieert connectie op lokale datapoort → naar datapoort client eerder aanduidde Client stuurt ACK terug   Passive FTP Client contacteert server op command poort Server antwoord met poort 2024 → server verteld welke poort luisterd voor data connectie Client initieert data connectie van zijn datapoort → gespecifieerde data poort Server stuurt ACK terug naar client's datapoort Active → SYN door client Passive → SYN door client