Netzwerke Marcel Waldvogel. Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz,...

Netzwerke

Marcel Waldvogel

Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz, 15.10.2001, 2

Netzwerke

Verbinden Endgeräte (End Systems) (Mobil-)Telefone, Terminals, Rechner

Verbindungen zwischen Schaltknoten(Intermediate Systems)

Router, Switches, Gateways, Firewalls, NATs, ...


Vorteile

Nutzung entfernter Resourcen Rechenleistung Information (Datenbanken)

Anfragen, Synchronisation

Ein-/Ausgabegeräte Personen

Sofortige Verbindung


Basisdienste

Verbindung ("Best Effort") Adressierung

Telefonnummern Internet-Adressen

Routing (Leitweglenkung)

Qualität ("QoS") Mindestbandbreite Maximale Verzögerung, Jitter Bitfehler, Paketverluste


Applikationen

Datentransfer

Fernbenutzung/-steuerung Remote Login/Telnet

E-Mail

Namenszuordnung

Chat

Fernabfrage Gopher, WWW, ...


Leitweglenkung

Ziel: Kenntnis des besten Pfades zujedem 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


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 XAusserhalb ISP: Nur summarische Information zum Gesamtnetz


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


Distanz-Vektor

Regelmässige "Hallo"-MeldungenSo 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


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


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


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)


Anforderungen der Applikationen

Eigenschaften von Kommunikationskanälen?

Zuverlässigkeit Datenverlust Übertragungsfehler Reihenfolge

Latenzzeit Übertragungsrate Datenpakete und -ströme

Maximierung aller Eigenschaften gleichzeitig?


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


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


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


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


HTTP

TCP-basiertASCII-Interface mit

Versionsverwaltung Befehle

GET <URL> HTTP/<Version> POST HEAD

... und Header ("Titelzeilen"); Zusatzinfos Host: User-Agent: If-Modified-Since:

Dreistellige Zifferncodes ab Version 1.0 erst nach HTTP/<Version>

Vor HTTP/1.1 nur eine Anfrage

Content-Type: Content-Length: Date:


Namen und Adressen

Internet: "dotted-quad"-Adressen 134.34.57.32

Menschen: Mnemonische Namen www.inf.uni-konstanz.de

Umsetzung Name Adressehosts.txt bis ein paar tausend

RechnerSuche nach neuem Mechanismus

Verteilte Server Verteilte Administration Skalierbar Erweiterbar


DNS

Hierarchische Struktur Punkte als Hierarchietrenner

www.inf.uni-konstanz.de 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

134.34.57.32 -> 32.57.34.134.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 IdentifikationenName, Telefon-, Passnummer

Rechner+Router im Internet:IP-Adresse (32 bit) - Adressierung von Datenpaketen“Name”, z.B. www.inf.uni-konstanz.de für Menschen

Frage: Umsetzung?

Domain Name System:Verteilte Datenbank: Hierarchie von vielen Name Servers

Applikationsprotokoll: Rechner, Router und Name Servers kommunizierenMerke: Kernfunktion des Internets implementiert auf ApplikationsebeneZiel: Komplexität an den Rand des NetzwerksErstes binäres Protokoll


22

DNS Name Server

Kein Server hat alle Namens-IP-Umsetzungen

Lokale Name ServerJeder ISP, jede Organisation hat Lokale (Standard-) Name ServerAnfrage zuerst an Lokalen Server

Originale Name Server:

Offizieller Verwalter einer Umsetzung

Wieso kein zentrales DNS?"Single Point of Failure"VerkehrsvolumenEntfernte DatenbankUnterhaltVertrauensfrageSkaliert nicht


23

DNS: Wurzelserver

Anfrage von lokalen Servern

WurzelserverVerbindet zu offiziellem Name Server, falls Umsetzung nicht bekannt

13 Wurzelserver weltweit


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.chneo.arl.wustl.edu

Wurzelserver

Offizieller Serverns1.wustl.edu

Lokaler Serverdns1.ethz.ch

1

23

4

5

6


25

DNS-Beispiel

Wurzelserver:kennt u.U. offiziellen Nameserver nicht

kennt aber Zwischenliegende Name Server: jemanden, der bei der Suche weiterhelfen kann

Anfragesurf.ethz.ch

neo.arl.wustl.edu

Wurzelserver


1

23

4 5

6

Offizieller Serverdns.arl.wustl.edu

Zwischenliegender Serverns1.wustl.edu

7

8


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 hostsurf.ethz.ch

neo.arl.wustl.edu

root name server

local name serverdns1.ethz.ch

1

23

4

5 6

authoritative name serverdns.arl.wustl.edu

intermediate name serverns1.wustl.edu

7

8

iterated query


27

DNS: Zwischenspeicher und Aktualisieren

Sobald ein Server eine Zuordnung kennt, speichert er dieses

Wann ist Caching gut? (“locality of reference”)

Timeout (TTL)

Aktives UpdateRFC 2136 and 2137

http://www.ietf.org/html.charters/dnsind-charter.html

Nicht für Caches (zu viel Zustandsinformation)

Sicherheit von DNSDNS kritisch zur Identifikation von Servern ("spoofing")

DNSsec-Arbeitsgruppe der IETF

http://www.ietf.org/html.charters/dnssec-charter.html

RFCs 2535 ... 2541


28

DNS: Erfolg des Caches

Anfrage vonsurf.ethz.ch trinity.arl.wustl.edu


1

2

Offizieller Serverdns.arl.wustl.edu

3

4

Anfrage vonbrowse.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)


29

DNS-Einträge

DNS: Verteilte, hierarchische Datenbank für "resource records"(RR). Delegation durch NS.

Typ=NSname 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=Aname ist hostnamevalue ist IP-Adresse

Typ=CNAMEname ist ein Alias für einen "kanonischen" valueCNAMEs werden als Nebeneffekt aufgelöst; Exklusivitätsanspruch

Typ=MXvalue ist Hostname (und Priorität) des Mailservers für die Domäne name

SOA, HINFO, TXT, PTR


30

DNS-Protokoll, -Nachrichten

DNS-Protokoll: Anfragen und Antworten im selben Format

Nachrichtenkopf:identification: 16 bits; Antwort benutzt selbe ID

flags:Frage oder AntwortRekursion erwünschtRekursion möglichAntwort ist offiziell

RFC 1035

32 bits


31

DNS-Protokoll, -Nachrichten

Name, Typ der Anfrage

RRs der Antwort

Wer ist offizieller Server

Zusätzliche hilfreicheInformation

32 bitsSequenznummer,

minimale Sicherheit

Befehl und Resultat


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 129.132.119.132 ;; 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 129.132.98.12dns3.ethz.ch. 23h38m19s IN A 129.132.250.2dns2.ethz.ch. 23h38m19s IN A 129.132.250.220 ;; Total query time: 1 msec;; FROM: neo.arl.wustl.edu to SERVER: default -- 128.252.153.107;; WHEN: Thu Sep 21 14:18:14 2000;; MSG SIZE sent: 30 rcvd: 158 Umgekehrt

eAnfrage?

Nicht erfragt,müsste abererfragt werden.}

Mehrere Einträge mitgleichem Namen undTyp, zufällig sortiert(Laustausgleich)

}


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-domain129.132.1.11 ® 11.1.132.129.in-addr.arpa (PTR RR)

Sicherheit?

Einfacher: Frage den Host (Lösung in IPv6)


34

% dig -x 129.132.119.132; <<>> 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:;; 132.119.132.129.in-addr.arpa, type = ANY, class = IN ;; ANSWER SECTION:132.119.132.129.in-addr.arpa. 1D IN PTR tik2.ethz.ch. ;; AUTHORITY SECTION:132.129.in-addr.arpa. 5w6d16h IN NS dns1.ethz.ch.132.129.in-addr.arpa. 5w6d16h IN NS dns2.ethz.ch.132.129.in-addr.arpa. 5w6d16h IN NS dns3.ethz.ch. ;; ADDITIONAL SECTION:dns1.ethz.ch. 1D IN A 129.132.98.12dns2.ethz.ch. 1D IN A 129.132.250.220dns3.ethz.ch. 1D IN A 129.132.250.2 ;; Total query time: 4091 msec;; FROM: neo.arl.wustl.edu to SERVER: default -- 128.252.153.107;; WHEN: Thu Sep 21 14:23:17 2000;; MSG SIZE sent: 46 rcvd: 197

Umkehrfrage


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)


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

Netzwerke Marcel Waldvogel. Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz,...

Documents

Transcript of Netzwerke Marcel Waldvogel. Marcel Waldvogel, IBM Zurich Research Laboratory, Universität Konstanz,...