Netzwerke Marcel Waldvogel

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 2 Netzwerke Verbinden Endgeräte (End Systems) (Mobil-)Telefone, Terminals, Rechner Verbindungen zwischen Schaltknoten (Intermediate Systems) Router, Switches, Gateways, Firewalls, NATs,...

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 3 Vorteile Nutzung entfernter Resourcen Rechenleistung Information (Datenbanken) Anfragen, Synchronisation Ein-/Ausgabegeräte Personen Sofortige Verbindung

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 4 Basisdienste Verbindung ("Best Effort") Adressierung Telefonnummern Internet-Adressen Routing (Leitweglenkung) Qualität ("QoS") Mindestbandbreite Maximale Verzögerung, Jitter Bitfehler, Paketverluste

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 5 Applikationen Datentransfer Fernbenutzung/-steuerung Remote Login/Telnet Namenszuordnung Chat Fernabfrage Gopher, WWW,...

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 6 Leitweglenkung Ziel: Kenntnis des besten Pfades zu jedem Endsystem im Netz Probleme Internet mehrere 100 Millionen Rechner Mobiltelefonie: ~100 Millionen Telefone Wenn für wenige Promille davon pro Minute die Pfadinformation ändert, ist das Netz mit Aktualisieren allein bereits überlastet Neuer Rechner/Einwahl ins Netz Beenden der Verbindung Verschieben

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 7 Skalierung Lösung im Internet: Aggregation Rechner werden zu Netzen zusammengefasst; nur Information pro Netzwerk, nicht pro Endsystem Netzwerke werden hierarchisch weiter zusammengefasst, je weiter man davon weg ist Beispiel Uni Konstanz: Einige 100 Netze, ausserhalb der Uni nicht sichtbar Beispiel Internet Service Provider: Am Ort X mehrere kleine Firmen mit benachbarten Adressen; innerhalb Details bekannt, am Ort Y nur summarische Information zu X Ausserhalb ISP: Nur summarische Information zum Gesamtnetz

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 8 Skalierung (2) Lösung Mobiltelefonie: Heimbasis Selten neue Verbindungen; selten grosse Reisedistanzen während einer Verbindung Bei Bewegungen wird Heimbasis über aktuelle Position informiert Bei Anruf (Verbindungsaufbau) wird Heimbasis kontaktiert, welche dann aktuelle Position für Datenaustausch liefert Innerhalb einer Gruppe von benachbarten Basisstationen Übergabe und Nachführung ohne Heimbasis Verwendung auch bei Mobile IP

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 9 Distanz-Vektor Regelmässige "Hallo"-Meldungen So entdeckte direkte Nachbarn tauschen untereinander Routinginformationen aus Bekannte Ziele und "Distanz" (oft "Kosten" genannt) dorthin Lokale Bestimmung des "kürzesten" Pfades zu allen Zielen und des dafür zuständigen Nachbarn ("Vektor") Informiere Nachbarn, wenn Distanz ändert RIP: Einsatz typischerweise nur in sehr kleinen Netzen Problem: Count-to-Infinity

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 10 Pfad-Vektor Wie Distanz-Vektor, aber Liste aller zu durchlaufender Router Vermeidet Count-to-Infinity BGP: Border Gateway Protocol Globales Routing im Internet (zwischen ISPs) Pfad listet Autonomous Systems (etwa ISPs), nicht Router

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 11 Link-Zustand Information: Nachbarliste jedes Routers Verteilung durch Fluten ("Flooding") Jeder Router kennt so gesamte Topologie Pfadsuche im lokalen Graphen OSPF: Einsatz in grösseren Netzwerken (Unis, ISPs, Mittel-/Grossfirmen) Kein Count-to-Infinity Erweiterbar Alternative Pfade QoS

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 12 Mehrere Applikationen? Typischerweise mehrere Applikationen pro Rechner Well-Known Services Nur ein Anbieter pro Service und Rechner http: HyperText Transfer Protocol ftp: File Transfer Protocol telnet, rlogin, rsh, ssh: Secure/Remote Shells smtp: Simple Mail Transfer Protocol domain: Domain Name Service (DNS) ntp: Network Time Protocol nfs: Network File System Dienstadressen (Ports)

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 13 Anforderungen der Applikationen Eigenschaften von Kommunikationskanälen? Zuverlässigkeit Datenverlust Übertragungsfehler Reihenfolge Latenzzeit Übertragungsrate Datenpakete und -ströme Maximierung aller Eigenschaften gleichzeitig?

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 14 Kompromiss Zwei Protokolle im Internet TCP (Transmission Control Protocol) Zuverlässig Verbindungsorientierter Datenstrom Latenzzeit und Datenrate "netzwerkfreundlich" UDP (User Datagram Protocol) Unzuverlässige Einzelpakete Optionaler Fehlererkennung Alles andere Aufgabe der Applikation

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 15 Wahl des Protokolls Telnet Virtuelle Terminalverbindung Zuverlässiger TCP-Strom von Zeichen NTP (Network Time Protocol) Möglichst verzögerungsfreie Übertragung von einzelnen Zeitstempeln NFS (Network File System) Zuverlässiger Dienst Klassisch UDP (wieso?), heute meist TCP

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 16 File Transfer Protokoll Getrennte Verbindungen für Steuerung und Daten TCP Vierbuchstabiges textbasiertes Interface USER PASS (...word) LIST PORT oder PASV (passive) RETR (...ieve) QUIT Dreistellige Codes

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 17 SMTP Eine TCP-Verbindung für Steuerung und Daten ASCII-basierte Befehle mit vier Buchstaben HELO oder EHLO (Extended HELO für ESMTP) MAIL FROM: RCPT TO: DATA QUIT Dreistellige Codes

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 18 HTTP TCP-basiert ASCII-Interface mit Versionsverwaltung Befehle GET HTTP/ POST HEAD... und Header ("Titelzeilen"); Zusatzinfos Host: User-Agent: If-Modified-Since: Dreistellige Zifferncodes ab Version 1.0 erst nach HTTP/ Vor HTTP/1.1 nur eine Anfrage " Content-Type: " Content-Length: " Date:

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 19 Namen und Adressen Internet: "dotted-quad"-Adressen Menschen: Mnemonische Namen Umsetzung Name Ø Adresse hosts.txt bis ein paar tausend Rechner Suche nach neuem Mechanismus Verteilte Server Verteilte Administration Skalierbar Erweiterbar

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 20 DNS Hierarchische Struktur Punkte als Hierarchietrenner Struktur analog Dateisystem /de/uni-konstanz/inf/www Einträge Delegationen für "Unterverzeichnisse" (NS) Adressen (A) weitere Informationen (MX, CNAME, TXT, KEY,...) Wurzel redundant (z.Z. 13 Server) Möglichst direkte Anfragen Aggressives Caching mit Time-To-Live Rückwärtsumsetzung > in-addr.arpa

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 21 DNS: Domain Name System Personen: Viele Identifikationen Name, Telefon-, Passnummer Rechner+Router im Internet: IP-Adresse (32 bit) - Adressierung von Datenpaketen Name, z.B. konstanz.de für Menschen Frage: Umsetzung? Domain Name System: Verteilte Datenbank: Hierarchie von vielen Name Servers Applikationsprotokoll: Rechner, Router und Name Servers kommunizieren Merke: Kernfunktion des Internets implementiert auf Applikationsebene Ziel: Komplexität an den Rand des Netzwerks Erstes binäres Protokoll

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 22 DNS Name Server Kein Server hat alle Namens-IP- Umsetzungen Lokale Name Server Jeder ISP, jede Organisation hat Lokale (Standard-) Name Server Anfrage zuerst an Lokalen Server Originale Name Server: Offizieller Verwalter einer Umsetzung Wieso kein zentrales DNS? "Single Point of Failure" Verkehrsvolumen Entfernte Datenbank Unterhalt Vertrauensfrage Skaliert nicht

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 23 DNS: Wurzelserver Anfrage von lokalen Servern Wurzelserver Verbindet zu offiziellem Name Server, falls Umsetzung nicht bekannt 13 Wurzelserver weltweit

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 24 Einfaches DNS-Beispiel Rechner surf.ethz.ch will IP- Adresse von neo.arl.wustl.edu 1. Anfrage an lokalen Server, dns1.ethz.ch 2. dns1.ethz.ch fragt Wurzelserver falls nötig 3. Wurzelserver fragt offiziellen Server (ns1.wustl.edu) falls nötig Anfrage surf.ethz.ch neo.arl.wustl.edu Wurzelserver Offizieller Server ns1.wustl.edu Lokaler Server dns1.ethz.ch

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 25 DNS-Beispiel Wurzelserver: kennt u.U. offiziellen Nameserver nicht kennt aber Zwischenliegende Name Server: jemanden, der bei der Suche weiterhelfen kann Anfrage surf.ethz.ch neo.arl.wustl.edu Wurzelserver Lokaler Server dns1.ethz.ch Offizieller Server dns.arl.wustl.edu Zwischenliegender Server ns1.wustl.edu 7 8

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 26 DNS: Rekursion und Iteration Rekursive Anfrage: Belastet den angefragten Server mit der gesamte Aufgabe Zustand und Timer für Wiederholungen Hohe Last Liefert auch offiziellen Server für weitere direkte Anfragen Iterative Anfrage: Angefragter Server antwortet mit Name und Adresse des Servers für den nächsten Schritt "Keine Ahnung, aber frag mal den da" Lokaler Server kennt den offiziellen Server Distanzen? requesting host surf.ethz.ch neo.arl.wustl.edu root name server local name server dns1.ethz.ch authoritative name server dns.arl.wustl.edu intermediate name server ns1.wustl.edu 7 8 iterated query

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 27 DNS: Zwischenspeicher und Aktualisieren Sobald ein Server eine Zuordnung kennt, speichert er dieses Wann ist Caching gut? (locality of reference) Timeout (TTL) Aktives Update RFC 2136 and Nicht für Caches (zu viel Zustandsinformation) Sicherheit von DNS DNS kritisch zur Identifikation von Servern ("spoofing") DNSsec-Arbeitsgruppe der IETF RFCs

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 28 DNS: Erfolg des Caches Anfrage von surf.ethz.ch trinity.arl.wustl.edu Lokaler Server dns1.ethz.ch 1 2 Offizieller Server dns.arl.wustl.edu 3 4 Anfrage von browse.ethz.ch Lokaler Server dns1.ethz.ch 1 2 neo.arl.wustl.edu?trinity.arl.wustl.edu? Effizienter für ähnliche Anfragen (sowohl an der Quelle, als auch am Ziel)

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 29 DNS-Einträge DNS: Verteilte, hierarchische Datenbank für "resource records" (RR). Delegation durch NS. Typ=NS name ist Domäne (z.B. example.com) value ist Name des offiziellen Servers; Adresse im "Additional"-Abschnitt Format der RR: (name, value, type, ttl) Typ=A name ist hostname value ist IP-Adresse Typ=CNAME name ist ein Alias für einen "kanonischen" value CNAMEs werden als Nebeneffekt aufgelöst; Exklusivitätsanspruch Typ=MX value ist Hostname (und Priorität) des Mailservers für die Domäne name SOA, HINFO, TXT, PTR

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 30 DNS-Protokoll, -Nachrichten DNS-Protokoll: Anfragen und Antworten im selben Format Nachrichtenkopf: identification: 16 bits; Antwort benutzt selbe ID flags: Frage oder Antwort Rekursion erwünscht Rekursion möglich Antwort ist offiziell RFC 1035

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 31 DNS-Protokoll, -Nachrichten Name, Typ der Anfrage RRs der Antwort Wer ist offizieller Server Zusätzliche hilfreiche Information Sequenznummer, minimale Sicherheit Befehl und Resultat

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 32 DNS-Anfrage % dig tik2.ethz.ch any ; > DiG 8.2 > tik2.ethz.ch any ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUERY SECTION: ;; tik2.ethz.ch, type = ANY, class = IN ;; ANSWER SECTION: tik2.ethz.ch. 11h23m2s IN A ;; AUTHORITY SECTION: ethz.ch. 6d23h38m19s IN NS dns1.ethz.ch. ethz.ch. 6d23h38m19s IN NS dns3.ethz.ch. ethz.ch. 6d23h38m19s IN NS dns2.ethz.ch. ;; ADDITIONAL SECTION: dns1.ethz.ch. 23h38m19s IN A dns3.ethz.ch. 23h38m19s IN A dns2.ethz.ch. 23h38m19s IN A ;; Total query time: 1 msec ;; FROM: neo.arl.wustl.edu to SERVER: default ;; WHEN: Thu Sep 21 14:18: ;; MSG SIZE sent: 30 rcvd: 158 Umgekehrte Anfrage? Nicht erfragt, müsste aber erfragt werden. } Mehrere Einträge mit gleichem Namen und Typ, zufällig sortiert (Laustausgleich) }

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 33 Umgekehrte Anfrage Wieso braucht jemand den Namen zu einer Adresse? Wieso sprecht ihr eure Freunde mit Namen an und nicht mit der Telefon- oder Personalnummer? Authentisierung (einzelner Rechner oder ganze Domäne, z.B. *.inf.uni-konstanz.de) Logdateien Delegation? Hierarchie? DNS-names: ASCII-Zeichenketten, little endian IP-Addressen: Bit strings (oder "Dotted Quads"), big endian Trick: Reversal of dotted quad, append pseudo-domain in-addr.arpa (PTR RR) Sicherheit? Einfacher: Frage den Host (Lösung in IPv6)

Basiert auf Folien zu Kurose und Ross: Computer Networks - A Top-Down Approach Featuring the Internet 34 % dig -x ; > DiG 8.2 > -x ;; res options: init recurs defnam dnsrch ;; got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 4 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 3, ADDITIONAL: 3 ;; QUERY SECTION: ;; in-addr.arpa, type = ANY, class = IN ;; ANSWER SECTION: in-addr.arpa. 1D IN PTR tik2.ethz.ch. ;; AUTHORITY SECTION: in-addr.arpa. 5w6d16h IN NS dns1.ethz.ch in-addr.arpa. 5w6d16h IN NS dns2.ethz.ch in-addr.arpa. 5w6d16h IN NS dns3.ethz.ch. ;; ADDITIONAL SECTION: dns1.ethz.ch. 1D IN A dns2.ethz.ch. 1D IN A dns3.ethz.ch. 1D IN A ;; Total query time: 4091 msec ;; FROM: neo.arl.wustl.edu to SERVER: default ;; WHEN: Thu Sep 21 14:23: ;; MSG SIZE sent: 46 rcvd: 197 Umkehrfrage

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 35 Wer macht Internet- Standards? Urzeit (~1970) Mitteilungen an andere Benutzer als nummerierte "Requests for Comment (RFC)" Heute IETF (Internet Engineering Task Force) Daneben IRTF (R=Research) für experimentelles Unterteilt in Gebiete (Areas) Unterteilt in Arbeitsgruppen (Working Groups) Jeder kann mitmachen (keine Mitgliedschaft) Diskussion von Vorschlägen in öffentlichen Mailinglisten Internet-Drafts Evt. zu RFC (z.Z. > 3000) Etliche Jahre später evt. zu STD (Standard; ~20)

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, , 36 IETF-Grundlagen Grundlage für ein RFC Rough consensus and running code Zunehmende Komplexität des Netzwerkes und der Interaktionen mit Protokollen Always think very hard before messing with TCP. And then don't. –Matt Crawford