Seminar: Computer Networks - Advanced Topics (SS 05) Location Tracking 1 Location Tracking Wolfgang Gassler Abstract Dieses Paper gibt einen Überblick über Methoden, die die geographische Position einer IP Adresse ermitteln oder approximieren können. Techniken wie GeoTrack, GeoPing, GeoCluster, Whois Abfragen oder eine DNS Erweiterung zur geographischen Ortsbestimmung von IP Adressen werden behandelt. Vor und Nachteile, empirische Daten und die eventuell bestehende Möglichkeit zur praktischen Verwendung der Technologien werden beleuchtet. Der zweite Teil des Papers beschreibt Vivaldi, ein dezentralisiertes Netzwerk Koordinaten System, das Hosts auf ein virtuelles Koordinatensystem aufträgt. Dieses System repräsentiert die Delay Informationen des darunterliegenden physikalischen Netzwerkes zwischen den jeweiligen aufgetragenen Knoten bzw. Hosts. I. EINFÜHRUNG Dieses Paper beinhaltet einen Überblick über Methoden, die es ermöglichen, aus einer IP Adresse auf die geographische Lage der IP Adresse zu schließen. Da eine IP Adressen an sich keine besonderen Merkmale oder Informationen zum geographischen Standpunkt beinhaltet, ist eine derartige Zuordnung von IP Adressen auf geographische Adresse wenn überhaupt, nur mit einem hohen Zusatzaufwand möglich. Interesse an diesem Thema besteht bereits seit langer Zeit, da ein Wissen über die geographische Lage von Internet Usern in vielen Bereichen Anwendung finden würde. So genannte location-aware Applications wie sie bereits bei Mobiltelefonen üblich sind, würden auch im Internet ermöglicht werden. Man denke nur an Wetter Informations- Seiten, die ihren Benutzern sofort die Werte für die richtige Region anzeigen können. Lokalisierte Werbung je nach Region würde auch kleinen regionalen Unternehmenden die Türe zur Online Werbung öffnen. Aber auch das territorial rights management, das Inhalte nur in bestimmten geographischen Regionen erlaubt würde von einen solchen funktionierenden Technologie stark profitieren. In diesem Paper werden im wesentlichen 4 Methoden zur Realisierung eines solchen Zuordnungs-Systems behandelt. Diese Systeme und Algorithmen werden meist unter dem Sammelbegriff IP2Geo [1] geführt. Die einfachste Methode eine ungefähre Positionierung Seminar: Computer Networks - Advanced Topics (SS 05) Leopold-Franzens-University of Innsbruck Institute of Computer Science, DPS Group, NSG team Presentation: 06/07/2005 Copyright 2005 vornehmen zu können, besteht aus dem Abruf bereits im Internet öffentlich verfügbaren Informationen zu IP Adressen. Verschiedene Datenbanken geben über die Besitzer der IP Adressen Auskunft. Leider besteht oft kein geographischer Zusammenhang zwischen Besitzer und aktuellem Benutzer der IP Adresse. Die zweite Methode beschreibt eine Erweiterung des bestehenden Domain Name Server (DNS) Standards um einen zusätzlichen Eintrag (Resource Record) im DNS File, der geographische Informationen zu einem Host beinhaltet. Die dritte Methode GeoTrack verwendet ebenfalls den DNS Standard und versucht den Host Name eines Knotens oder benachbarten Router/Knoten zu erhalten. In diesen DNS Namen befinden sich oft versteckte geographische Informationen, die von den Administratoren zur einfacheren Administration hinzugefügt werden. Zum Beispiel kann man von einem Host Name corerouter1.sanfrancisco.cw.net eines Routers auf dessen Standplatz in San Francisco schließen. GeoPing ist eine weitere Methode die den Zusammenhang zwischen Netzwerk-Delay und geographischer Positionierung nutzt. Durch Messungen der round trip time und Vergleiche mit bekannten Hosts kann die Position einer IP Adresse approximiert werden. Um die Fehlerquelle möglichst gering zu halten, existieren einige Algorithmen, die in den folgenden Kapiteln besprochen werden. Die abschließende IP2Geo Technik ist GeoCluster, die verschiedene IP Adressen in Clustern zusammenfasst und somit von geographisch bekannten Hosts/IP Adressen auf andere Clients im Cluster schließen kann. Die Einordnung in Clustern kann zum Beispiel über BGP (Border Gateway Protocol) erfolgen, beinhaltet jedoch damit auch eine große Fehlerquelle. Alle diese Methoden und Techniken haben ihre Vor- und Nachteile und beinhalten auch meist einige Fehlerquellen die in diesen Paper analysiert werden. Auch bereits durchgeführte Tests zu den jeweiligen Methoden werden hier zusammengefasst. Ein weiteres Thema in diesem Paper ist die Zuordnung von IP Adressen auf virtuelle Koordinaten. Diese Koordinaten haben jedoch keine Ähnlichkeit mit geographischen Daten sondern beinhaltet andere Parameter die in manchen Szenarien wichtig sind. In unserem Fall gehen wir auf das Vivaldi Netz ein, das ein dezentralisiertes Netzkoordinaten System darstellt. Dieses organisiert alle Knoten bzw. IP Adressen nach ihrer Lage in Bezug auf ihre Delay Werte zu den Nachbarknoten.
Seminar: Computer Networks - Advanced Topics (SS 05) Location Tracking 2 II. IP2GEO A. Proxy Problematik Die Grundvoraussetzung um aus einer IP Adresse geographische Angaben zu gewinnen, ist die IP Adresse an sich. Dies ist in der heutigen Zeit von Proxies und Firewalls nicht mehr so einfach. Beinahe alle großen Provider verwenden Proxies, auch wenn dies nicht auf den ersten Blick erkennbar ist. Transparente Proxies schalten sich auch ohne Wissen des Benutzers zwischen den gesamten Internet Verkehr. Aber auch Firewalls von größeren Unternehmen verhindern das Erkennen der korrekten IP Adresse des Benutzers. Greift nun ein Benutzer über einen Proxy auf ein Service zu, kann dieses Service nur die IP Adresse des Proxys sehen. Gerade bei großen Providern die global operieren, existiert teilweise nur eine zentrale Proxy Farm. Abbildung 1 zeigt die Entfernung zwischen der AOL Proxy Farm in Virginia und den AOL Clients in den USA. University of Innsbruck; EDV-Zentrum Technikerstrasse 13; A-6020 Innsbruck; Austria Walter Mueller Diese Informationen können jedoch bei großen Netzen irreführend sein. Viele global operierende Provider besitzen sehr große IP Ranges, die in vielen verschiedenen Staaten Verwendung finden, jedoch alle auf die gleiche geographische Position der Firmenzentrale registriert sind. Zum Beispiel wird somit der komplette IP Block 4.0.0.0/8 der weltweit tätigen Firma Level 3 auf Cambridge lokalisiert, obwohl dieser in einem viel größeren Gebiet verwendet wird. C. DNS Erweiterung In RFC 1876 [3] wird eine Erweiterung des Domain Name Service Standards vorgeschlagen, die aus zusätzlichen Feldern zur Angabe von geographischen Informationen von Hosts, Networks und Subnetworks dienen soll. Hierzu wird ein zusätzliches Feld (Resource Record) eingeführt, das folgende Komponenten enthält: - Versionsnummer (version) - 3 Felder zur Angabe der Präzision (size, horiz pre, vert pre) - Breitengrad (latitude) - Längengrad (longitude) - Höhenlage (altitude) Beispiel: curtin.edu.au LOC 32 7 19 S 116 2 25 E 10m Abbildung 1: Entfernungen zwischen AOL Clients (USA) und AOL Proxy in Virginia Venkata N. Padmanabhan und Lakshminarayanan Subramanian- An Seite 3 B. Whois Abfrage Die wahrscheinlich einfachste und am meist verbreitete Variante um eine IP Adresse mit einer geographischen Angabe zu verbinden ist die Whois Abfrage. Hier wird auf öffentlich zugängliche Datenbanken im Internet eine Anfrage gerichtet, die wiederum die Besitzerdaten inklusive Adressdaten zurückliefert. Meist handelt es sich hierbei um die IP Adressen Vergabestellen [2]. Eine Anfrage bei ripe.net über die IP Adresse des Servers www.uibk.ac.at (138.232.1.216) zeigt folgendes Ergebnis (Auszug): Um den Administrationsaufwand etwas zu verkleinern, ist es auch möglich Netzten oder Subnetzten geographische Informationen zuzuordnen. Dies erhöht jedoch den Suchaufwand des Clients, da sich dieser bei fehlender Host Information durch mehrere Ebenen suchen muss. Grundsätzlich sind diese Angaben in DNS Servern leider nur vereinzelt anzutreffen und oftmals auch veraltet, da bei der Änderungsfrequenz der Host Positionen ein großer administrativer Aufwand entsteht. Eine globale Liste der DNS Server, die diese Erweiterung anbieten findet man unter [4]. D. GeoTrack Die Geotrack Technik basiert auf den DNS Host Names der jeweiligen Clients bzw. nahe liegenden Routern. Netzwerkadministratoren fügen oft geographische Informationen zu den DNS Namen ihrer Router hinzu, um den verwaltungstechnischen Aufwand möglichst gering zu halten. Zum Beispiel beinhaltet der Host Name at-inn-tirolixhotze.chello.at eines Routers sehr viele geographische Informationen.:
Seminar: Computer Networks - Advanced Topics (SS 05) Location Tracking 3 - at: Österreich - inn: Innsbruck - tirolix: Tiroler Internet Exchange (Eduard-Bodem- Gasse, Innsbruck, Tirol, Österreich) Natürlich muss eine derartige Bezeichnung von Routern nicht zwingend durchgeführt werden und es gibt auch keine offiziellen Richtlinien dafür. Jeder Provider verwendet sein eigenes Muster, wodurch eine automatische Analyse natürlich erschwert wird. Eine große empirische Studie [1] hat jedoch festgestellt, dass die Bezeichnung mit geographischen Inhalten sehr verbreitet ist und auch manchen Mustern folgt. Die 3 meist verwendeten Typen von geographischen Codes sind City Codes, Airport Codes und Country Codes. Gerade Airport Codes bietet sich für diesen Bereich an, da diese weltweit standardisiert und eindeutig sind. Country Codes geben leider nur eine sehr ungenaue geographische Position an wodurch diese allein für den IP2Geo Zweck eher weniger geeignet sind. Sie können jedoch zur zusätzlichen Überprüfung von City Codes verwendet werden. Gerade bei City Codes ist die Verwechselungsgefahr sehr hoch. Aus der Studie geht hervor, dass alleine mindestens 12 Kürzel für die Stadt Chicago existieren (z.b.: chcg, chcgil, chi,...). Eine zusätzliche Schwierigkeit stellt die Position der geographischen Codes in den DNS Namen dar, da diese je Provider sehr unterschiedlich sein kann. Die folgenden zwei Beispiele zeigen wie schwer es auch für eine Person ist, die relevanten Daten auszulesen bzw. zu finden: - sl-bb10-sea-9-0.sprintlink.net containing (sea für Seattle) - 192.atm4-0.sr1.atl5.alter.net (atl für Atlanta) E. GeoTrack vs. Whois Eine Studie [1] verglich GeoTrack und Whois Abfragen mit dem Tool NetGeo. Getestet wurden 265 universitären Web Servern und 2380 Client IP Adressen eines Online TV Programführers (Foo-TV), die über die USA gleichmäßig verteilt und geographisch bekannt sind. Abbildung 2 beschreibt die Ergebnisse der durchgeführten Tests. Bei den Foo-TV Test IP Adressen ist das Ergebnis sehr ähnlich. NetGeo weist einen Fehler Median von 650 km auf, GeoTrack 590km. Dieses schlechte Testergebnis ist vor allem auf die vielen Proxies zurückzuführen, wodurch eine genaue Bestimmung der echten IP Adresse nicht möglich gewesen ist. Bei den universitären Servern, die nicht hinter Proxies liegen, wurde eine Fehler Median von 102km erreicht. Zusätzlich sind diese Server sehr gut an das Internet angebunden, wodurch Traceroutes eher beenden und die letzten Router meist näher an den Test IP Adresse liegen. F. GeoPing GeoPing versucht einen Zusammenhang zwischen Netzwerk Delay Werten und geographischen Positionen herzustellen. Hierzu wird die round trip time der Zieladresse von mehreren verschiedenen Hosts aus gemessen und anschließend aus diesen Messungen auf die geographische Position der Zieladresse geschlossen. Abbildung 2: Untesrchied GeoTrack vs. Whois/NetGeo Seite 5 Die weit verbreitete Meinung sagt, dass ein derartiger Zusammenhang nicht herstellbar ist. Da die Geschwindigkeit des Netzes ständig wächst und auch die Bottlenecks immer weniger werden, lässt sich nun jedoch ein Zusammenhang auch empirisch feststellen [1]. Abbildung 3: Messung von 3 versch. Orten, 1= nahe Seite 6
Seminar: Computer Networks - Advanced Topics (SS 05) Location Tracking 4 Eine Messung von drei verschiedenen Hosts von unterschiedlichen Orten (siehe Abbildung 3) ergibt jedoch keinen großen Unterschied. Um so näher die Messergebnisse an der Distanz 1 liegen, um so kürzer der gemessene Pfad. In Abbildung 3 liegt der Großteil aller Messpunkte nahe an 1 und die Messungen von den unterschiedlichen Ausgangspunkten lassen sich nur schwer unterschieden. Diese Messergebnisse sind vor allem auf Schwankungen im Netz zurückzuführen. Um hier mit einem realistischen Wert rechnen zu können, müssen mehrere Messungen durchgeführt werden. Aus empirischen Versuchen ergibt sich eine ideale Messgrundlage von 10-15 Messergebnissen, aus denen dann der minimale Wert ermittelt und für weitere Berechnungen verwendet wird. Natürlich setzt diese Messvariante ein schnelles kabelgebundenes Netzwerk, das keine Satelliten Links oder Einwahlverbindungen nutzt, voraus. Aus empirischen Messdaten [1] kann nun eine geographische Einteilung von rount trip time Daten erfolgen. In [1] wird eine Einteilung in 10ms Schritten verwendet. Zusätzlich kommt ein Bereich von 0-5ms zum Einsatz, da in diesem 90% aller Daten im Bereich von 50 km liegen. Abbildung 4 zeigt einige Beispielbereiche aus den gewonnen Messdaten. Eine grundsätzliche Übereinstimmung zwischen Delay und geographischer Distanz ist zu erkennen, jedoch reicht diese nicht für ein mathematisches Modell oder eine genaue geographische Bestimmung aus. Delay Werten von N Test-Hosts. Soll nun ein neuer Host T errechnet werden, werden die Delay Werte DV = (d 1,...,d N ) von den N Test-Hosts zu T berechnet. Anschließend sucht man den ähnlichsten Delay Vektor mit Hilfe der Euklidischen Distanz zwischen DV und DV. Es können auch andere Verfahren zur Berechnung der besten Übereinstimmung von den Messvektoren verwendet werden. In [10] wurden verschiedene Verfahren an 397 weltweit verteilten Hosts getestet. Die Canberra Distanz [10] zur Berechnung der Übereinstimmung zweier Vektoren konnte die besten Ergebnisse liefern, da sie auch bei kleinen Zahlen, die sich an Null annähern, noch immer relativ exakt ist. Weitere Testergebnisse [1] zu NNDS zeigen dass diese Methode durch die vielen Messquellen stabiler und genauer wird. Zusätzlich kann man die Delay Vektoren geographisch clustern, wodurch auch Hosts bei unterschiedlichen Providern in gleichen Städten besser erkannt werden. Abbildung 5 zeigt die Fehldistanzen abhängig von den verwendeten Test-Hosts (probes). Man kann erkennen dass ca. 7-9 Test-Hosts die besten Ergebnisse erreichen und im Bereich einer Fehlinterpretation von 500-1500km liegen. Abbildung 4 : Einteilung der Messungen in 10ms Bereiche Seite 7 Um nun von der Distanz auf eine geographische Position zu schließen, wird der Nearest Neighbor in Delay Space (NNDS) Algorithmus [1] verwendet. Dieser baut auf dem RADAR Algorithmus [5] zur örtlichen Bestimmung von Client ins Wireless LANs auf. NNDS verwendet die Tatsache, dass Clients mit ähnlichen Delay Werten in Bezug auf verschiedene andere Hosts, auch geographisch nahe aneinander liegen müssen. Dazu müssen nun Messwerte von verschiedenen Hosts vorliegen. Diese Messwerte bestehen aus geographischen Daten des Hosts und einem Delay Vektor DV = (d 1,...,d N ) mit den minimalen Abbildung 5: NNDS Fehler Distanz nach Test-Hosts Seite 8 G. GeoCluster GeoCluster verwendet im Gegensatz zu GeoPing und GeTrack keine Messungen sondern versucht den gesamten IP Raum in Clustern einzuteilen. Die im Cluster befindlichen IP Adressen sollen im Idealfall in einem gemeinsamen geographischen Gebiet liegen. Kennt man nun die geographische Lage von einigen IP Adressen im Cluster, kennt man auch die Lage aller anderen Adressen im selben Cluster. Wenn die Cluster richtig gewählt werden, kann man so auch auf Fehlinformationen schließen. Enthält ein Cluster x.x.x.0/24 10 IP Adressen in Innsbruck und eine aus Wien, ist die Wahrscheinlich sehr hoch, dass die geographische Information Wien falsch ist und eigentlich ebenfalls
Seminar: Computer Networks - Advanced Topics (SS 05) Location Tracking 5 Innsbruck lauten muss. Alle 256 Adressen in diesem Cluster können nun der geographischen Information Innsbruck zugeordnet werden. Die Schwierigkeit besteht nun darin, die richten IP Adressen in Clustern zusammenzufassen. Hier wird auf bereits vorhandene Informationen im Internet zurückgegriffen. Man behilft sich mit den Informationen des Border Gateway Protocol, das im Internet für das Inter-AS Routing verwendet wird. Das Internet besteht aus vielen AS (autonomous system), die bei den Vergabestellen verteilt werden. Meist stellen Provider oder große Unternehmen ein AS dar. Jedes AS besitzt wiederum ein oder mehrere APs (adress prefixes), die den jeweiligen IP Adressraum angeben. Die Universität Innsbruck (AS1110) besitzt den Adressraum 138.232.0.0-138.232.255.255 der als AP 138.232.0.0/16 angegeben wird und max. 65536 Adressen beinhaltet. Um nun den Weg in andere AS zu finden, wird das BGP für das Inter-AS Routing verwendet. In Abbildung 6 werden die BGP Aktivitäten des AP von AS 1110 der Universität Innsbruck dargestellt. Die aus den BGP gewonnenen AP Daten werden nun für die Cluster Zusammenfassung verwendet. Jeder AP bildet einen geographischen Cluster. Leider verwenden viele global operierende Provider APs für wesentlich größere geographische Gebiete, so dass die gewählten Cluster nicht mehr mit einem sinnvollen geographischen Gebiet übereinstimmen. Cluster 152.153.0.0/17 und einen Cluster 152.153.128.0/17 gesplittet. Anschließend wird jeder Unterraum wieder auf Unstimmigkeiten untersucht und gegebenenfalls weiter unterteilt. Schwellenwerte verhindern ein endloses Zerkleinern der Clustergrößen. Ein Limit (cthresh) beschreibt die minimale Größe eines Clusters bzw. wie viele Elemente mit geographischen Informationen in einem Cluster minimal enthalten sein müssen. Der zweite Schwellenwert (fthresh) beschreibt wie hoch die Übereinstimmung der verschiedenen IP-to-location Daten sein muss, bevor keine weitere Aufteilung erfolgt. Ein fthresh von 0.7 verlangt eine 70% Übereinstimmung der geographischen Informationen, andernfalls wird der Cluster weiter unterteilt. In Abbildung 7 werden die Testergebnisse aus [1] der zwei GeoCluster Varianten mit verschiedenen Parametern grafisch dargestellt. Der deutliche Unterschied zwischen BGPonly und BGP+subclustering ist auf die großen verteilten APs zurückzuführen, die bei vielen Providern zum Einsatz kommen. BGP+subclustering (20,0.7) erreicht eine Errordistanz von 0 bei 53% aller Test Adressen. Im Gegensatz dazu erhält man ohne Subclustering nur 36% korrekte Daten. Subclustering mit (5,0.6) liefert im Test das beste Ergebnis, wird jedoch in [1] als zu aggressiv für den alltäglichen Gebrauch gesehen. Interessant ist auch die Unterteilung in /24 Cluster ohne Beachtung von BGP Daten, die gegenüber BGPonly ein relativ gutes Ergebnis liefert. Abbildung 6: BGP Aktivitäten AS1110 erstellt mit [6] Um auch große verteile APs in sinnvolle Cluster aufzuteilen wurde die BGPonly Variante zur BGP-subclustering Variante erweitert. In dieser Variante werden alle AP Cluster zusätzlich untersucht und gegebenenfalls weiter unterteilt. Hierzu werden zuerst alle vorhandenen IP-to-location Informationen ausgewertet. Befinden sich in einem Cluster viele IP Adressen mit unterschiedlichen geographischen Informationen, ist die Wahrscheinlich hoch, dass dieser Cluster geographisch zu weit verteilt ist und eine zusätzliche Unterteilung benötigt. In diesem Fall wird der Cluster in zwei neue Cluster unterteilt. Ein Adressraum 152.153.0.0/16 wird zum Beispiel in einen Abbildung 7: GeoCluster Vrianten und Parameter Vergleich Seite 12 H. GeoTrack vs. GeoPing vs. GeoCluster Abbildung 8 zeigt die drei Technologien GeoTrack, GeoPink und GeoCluster im Vergleich bei 265 universitären Hosts [1]. Auf den ersten Blick ist bereits zu erkennen dass die GeoCluster Methode eine wesentlich bessere Ortung ermöglicht. Sie erkennt 88% aller Hosts. Betrachtet man den Median und das 80 Perzentil der Fehlerdistanz, liegt
Seminar: Computer Networks - Advanced Topics (SS 05) Location Tracking 6 Geocluster mit 28 / 226km deutlich vor GeoTrack mit 102 / 384km und GeoPing mit 382 / 1201km. Knoten. Die schwierigste Aufgabe ist nun die einordnung von neuen Knoten, die möglichst schnell ihren korrekten Platz im Koordinaten-System finden müssen. Dazu berechnet ein neuer Knoten die RTT zu einem Nachbarn und der daraus resultierende Fehler in Bezug auf die derzeitigen Koordinaten. Nun ändert der Knoten seine Koordinaten um eine Größe δ um den Fehler zu verkleinern. Die Wahl von δ ist nun entscheidet, da diese Größe des gesamten Raum beeinflussen kann. Wählt man δ zu groß, oszillieren die einzelnen Knoten da diese ständig Ihre Position überprüfen und zu große Sprünge im Raum tätigen. Dies hat zur folge dass auch andere Knoten wieder hohe Fehler berechnen und ebenfalls große Sprünge vollziehen. Um ein derartiges Szenario zu vermeiden bekommen neue Knoten große δ Werte, damit diese schnell die korrekten Koordinaten finden. Knoten mit korrekten Koordinaten erhalten im Gegenzug kleine δ Werte, um nicht von neuen schlecht orientierten Knoten in eine falsche Richtung geleitet zu werden. Abbildung 8: Vergleich GeoTrack, GeoPing, GeoCluster Seite 11 Allgemein ist GeoCluster die einzige Variante die man eventuell in der Praxis einsetzten kann. GeoPing und GeoTrack wird durch viele unberechenbare Einflüsse beeinträchtigt. Neben der starken Verzerrung durch die letzte Meile oder Satelliten Links, ist die GeoPing Methode zusätzlich auch noch mit einem hohen Messaufwand verbunden, der teilweise aus sicherheitstechnischen Gründen nur erschwert möglich ist. Zusätzlich werden ICMP Pakete (wird für Ping Protocol verwendet) in vielen Netzten nachrangig bearbeitet bzw. behandelt und verfälschen auch so das Ergebnis. III. VIVALDI Viele große und schnell skalierende Applikationen (z.b. Overlay Netze) benötigen oft Delay Informationen der Nachbarn oder anderen Teilnehmern der Applikation. Die einzelne Kontaktaufnahme mit den Nachbarn und Teilnehmern ist in den meisten Fällen zu aufwendig. Vivaldi [7] bietet hier einen anderen Lösungsansatz. Vivaldi bietet ein dezentralisiertes Netzwerk Koordinaten System, bei dem jeder Teilnehmer oder Knoten auf ein virtuelles Koordinaten System aufgetragen wird. Die Entfernungen der eingetragenen Knoten zueinander spiegeln die Delay Informationen (Round Trip Time) des darunter liegenden Netzes wieder. Die Schwierigkeit eines solchen Netzes liegt in der Wahl des virtuellen Raums, der Skalierbarkeit bei vielen und wenigen Hosts, der dezentrale Implementierung, einer möglichst geringen Kommunikation und der Anpassungsfähigkeit auf Änderungen im darunterliegenden physikalischen Netzwerk. Vivaldi verwendet ein zwei-dimensionales Koordinatensystem. Der Abstand zwischen zwei Knoten beschreibt genau die round trip delay time zwischen diesen Abbildung 9: Unterschied angepasstes u. nicht angepasste δ Werte auf c basierend Frank Dabek, Russ Cox, Frans Kaashoek, Robert Morris - Vivaldi: A Decentralized Network Coordinate System ) Seite 5 Abbildung 10: Unterschied angepasstes u. nicht angepasste δ Werte auf c basierend Frank Dabek, Russ Cox, Frans Kaashoek, Robert Morris - Vivaldi: A Decentralized Network Coordinate System ) Seite 6 Abbildung 9 zeigt den Unterschied zwischen angepassten und nicht angepassten δ Werten. Der erste Graph zeigt, dass eine zu klein gewählte Größe δ eine sehr langsame
Seminar: Computer Networks - Advanced Topics (SS 05) Location Tracking 7 Annäherung zur richtigen Position im Koordinatensystem zur Folge hat. Wählt man hingegen einen großen Wert, ist die Oszillierung deutlich zu erkennen. Im unteren Graph wird ein dynamisch angepasster Wert verwendet. Hier zeigt sich die schnelle Erkennungsrate von fehlerhaften Koordinaten bzw. deren Korrektur. Um eine weitere bessere Verteilung zu erhalten, sollten Knoten nicht nur mit nahen Nachbarn kommunizieren sondern auch einige Messungen zu weiter entfernten Knoten durchführen. Somit erhält man eine globalere Positionsbestimmung. In Abbildung 10 werden zwei Kommunikationsvarianten mit 400 Knoten verglichen. Die erste Variante kommuniziert nur mit den vier nähersten Nachbarn. Das zweite Modell verwendet zusätzlich zu den vier Nachbarn weitere vier Knoten die zufällig gewählt werden und weit entfernt liegen. Die einseitige Orientierung der ersten Variante ist deutlich zu erkennen. Vivaldi und die verschiedenen Parameter wurden ausführlich getestet [7]. Bei einer Simulation mit 100-1000 Knoten konnten sehr positive Eigenschaften ermittelt werden. Die Reaktion auf fehlerhafte Knoten und Delay Änderungen im darunterliegenden Netz erfolgt sehr rasch. Die durchschnittliche Fehlerquote bei den Tests lag bei ca. 20ms. Vivaldi wurde auch mit mehrdimensionalen Räumen getestet, es konnten jedoch keine Verbesserungen festgestellt werden. Eine zusätzliche Verbesserung des Modells konnte jedoch durch einen Höhen-Vektor erreicht werden. Dieser verhält sich ähnlich zu einer dritten Koordinate, ist jedoch immer positiv und hat einen minimalen Wert. Ist ein Knoten zum Beispiel von einigen Knoten zu nah umgeben, hätte dieser keinen Ausweg um sich von den diesen Knoten zu entfernen. Nun hat er die Möglichkeit den Höhenvektor zu vergrößern uns sich von den umliegenden Knoten zu entfernen. Die RTT besteht dann aus Entfernung zwischen den Knoten addiert mit den zwei Höhenvektoren der Knoten. Ein Versuch zeigte dass Knoten aus New York und Brasilien jeweils auf zwei verschiedenen Höhen Ebenen lagen und so das reale Netzt besser modellieren. IV. ZUSAMMENFASSUNG Die IP2Geo Methoden stellen einen sehr interessanten Ansatz zur Bestimmung von geographischen Daten aus IP Adressen da. Die messbasierten Methoden GeoTrack, GeoPing und GeoCluster werden jedoch auf Grund der Komplexität und großen Messfehlern in der Praxis keinen Einsatz finden. Ein zusätzlich großes Problem für alle IP2Geo Methoden stellen die Proxies und Firewalls dar, die auch in den Versuchen [1] immer wieder Messergebnisse verfälscht haben. Auch die Chance auf einen Einsatz in der Praxis bei Webportalen oder ähnlichen Projekten ist gering. Meist werden in diesen Bereichen genaue geographische Daten benötigt, die über eine Registrierung der Benutzer einfacher zu erhalten sind. Zusätzlich können auch andere Benutzer Informationen, die für das Projekt zusätzlichen Nutzen darstellt, erfragt werden. Ein möglicher Einsatz von GeoCluster könnte jedoch im Bereich von Besucher Analysen oder ähnlichen Bereichen, bei denen eine genaue geographische Positionierung nicht von Nöten ist, liegen. Auch die Implementierung, der Netzwerkverkehr und der damit verbundene Aufwand ist bei den meisten Methoden zu hoch um in der Praxis einen Einsatz zu finden. Diverse Firmen [8][9] bietet jedoch bereits Online IP2Geo Services an, die jedoch vermutlich nur auf Whois Abfragen und eigenen Datenbanken basieren. Die zukunftsträchtigste Lösung wäre natürlich die DNS Erweiterung, da die Einträge schnell abgefragt werden können und die genaueste Positionsangabe erlauben. Leider hat sich die Erweiterung nur vereinzelt durchgesetzt und bedarf natürlich einer regelmäßigen Wartung der Administratoren. Vivaldi ist einfach, dezentralisiert und passt sich schnell an die jeweiligen Gegebenheiten an. Es ist Netzwerkunabhängig und kann auf jeder Netzwerkstruktur betrieben werden, benötigt keine speziellen Vorrausetzungen und kann mit geringfügigem Aufwand auch in bestehende Applikationen implementiert werden. Gerade in stark skalierenden Applikationen, wie zum Beispiel File Sharing Programmen, könnte Vivaldi zum Einsatz kommen bzw. als Grundlage für eine erweiterte Methode benutzt werden. REFERENZEN [1] Venkata N. Padmanabhan und Lakshminarayanan Subramanian An Investigation of Geographic Mapping Techniques for Internet Hosts - SIGCOMM 01, August 27-31, 2001, San Diego, California, USA [2] IP Vergabestellen: www.ripe.net, www.arin.net, www.apnic.net, www.lacnic.net [3] C. Davis, P. Vixie, T. Goodwin, I. Dickinson - January 1996 - RFC 1876 A Means for Expressing Location Information in the Domain Name System [4] www.ckdhr.com/dns-loc/ - More information about DNS LOC [5] P. Bahl and V.N. Padmanabhan. RADAR: An In-Building RF-Based User Location and Tracking System. IEEE Infocom, March 2000 [6] GPlay - graphical visualisation of BGP update http://bgplay.routeviews.org/bgplay/ [7] Frank Dabek, Russ Cox, Frans Kaashoek, Robert Morris - Vivaldi: A Decentralized Network Coordinate System - SIGCOMM 04, Aug. 30 Sept. 3, 2004, Portland, Oregon, USA [8] www.geobytes.com/iplocator.htm - IP Address Locator Tool [9] www.maxmind.com - MaxMind GeoIP Products deliver information on the geographic location of Internet visitors, leveraging industry-leading open source IP geolocation technology and continuously updated databases.
Seminar: Computer Networks - Advanced Topics (SS 05) Location Tracking 8 [10] Artur Ziviani, Serge Fdida, Jos'e F. de Rezende and Otto Carlos M. B. Duarte - Toward a Measurement-based Geographic Location Service PAM April 19-20, 2004