Analyse von Paketaufzeichnungen 1

Eine Möglichkeit Schleifen zu finden, besteht in der Analyse von Paketaufzeichnungen eines Knoten im Netz. Eine Paketaufzeichnung stellt ein lückenloses Abbild des aufgezeichneten Intervalls dar. Es ist offensichtlich, dass der Knoten der Aufzeichnung ein Mitglied der gefundenen Schleife sein muss.

Ein Algorithmus zum Auffinden von Schleifen in Paketaufzeichnungen wird in [61]

beschrieben:

1. Auffinden von replizierten Paketen: Ein repliziertes Paket enthält die identischen Nutzdaten (Payload) und bis auf TTL und Header-Checksum einen identischen IP-Header. Die TTL muss dabei eine Abweichung von mindestens 2 enthalten. Oftmals werden nur die ersten z.B. 40 Bytes eines Pakets aufgezeichnet, um das Datenvolumen zu minimieren und/oder eine aus juristischen Gründen notwendige Anonymisierung zu erreichen (siehe Kapitel 2.4.2). Um die fehlende Payload trotzdem zuverlässig vergleichen zu können, wird die TCP- oder UDP-Checksumme verglichen, die im Gegensatz zur IP-Checksumme aus TCP-Header und der TCP-Payload berechnet wird.

2. Replizierte Datenströme validieren: Als Beweis für eine Routing-Schleife in einer Paketaufzeichnung müssen zwei Bedingungen erfüllt sein. Zunächst müssen mindestens mehr als zwei replizierte Pakete vorhanden sein. Es kann durch Fehler vorkommen, dass ein Paket durch die Link-Layer-Schicht dupliziert wird. Z.B. wenn

ein fehlerhaft konfigurierter SONET-Protection-Layer das Paket auf der eigentlichen und der redundanten Verbindung weiterleitet. Weiterhin muss bestimmt werden, ob das replizierte Paket zum Zeitfenster der vermuteten Schleife gehört.

Das längste Präfix bei Tier-1 ISPs besitzt eine Länge von 24-Bits, d.h. replizierte Pakete mit einer Übereinstimmung der ersten 24-Bits in der Zieladresse, werden zu replizierten Datenströmen zusammengefasst (Replica Streams).

3. Zusammenfassen der replizierten Datenströme: Die identifizierten Datenströme aus Schritt 2 sind ein Indiz für eine aufgetretene Schleife. Replizierte Datenströme mit der gleichen Zieladresse und einer zeitlichen Überlappung sind mit höchster Wahrscheinlichkeit einer Schleife zuzuordnen und ein Kriterium für die Zusammenfassung. Weiterhin werden Datenströme mit der gleichen Zieladresse und einem zeitlichen Abstand von einer Minute einer Schleife zugeordnet, um den Fall abzufangen, dass es eine kurze Pause im Datenverkehr gab.

3.2.1.1 S

BGP-E

In [77] wird eine Methodik vorgestellt, um BGP-Events den gefundenen Schleifen zuzuordnen. BGP-Statusänderungen können temporäre Schleifen erzeugen z.B. eine Änderung im AS_PATH oder NEXT_HOP, die aufgrund zeitlicher Verzögerungen von Timern (z.B. Route Flap Dampening) oder Übertragungszeiten noch nicht durch das gesamte Netz propagiert wurden. Eine Änderung im AS_PATH oder NEXT_HOP ist eine notwendige aber nicht hinreichende Bedingung. Die Formulierung einer hinreichenden Bedingung benötigt die kompletten BGP-Tabellen aller Nachbarn zur Überprüfung. Aus diesem Grund wird in [77] nur eine Änderung im AS_PATH oder NEXT_HOP inkl. einer zeitlichen Nähe zur resultierenden Schleife überwacht.

Die benötigten BGP-Updates werden von einem passiven Empfänger mitgeschnitten, der sich im Sprint Backbone befindet und als Client eines Route Reflectors alle BGP-Updates innerhalb des Sprint-Netzwerks empfangen kann. Zudem werden Daten des Routeview-Projekts [78] zur Unterstützung herangezogen. Das Routeviews-Projekt sammelt externe BGP-Updates und liefert somit eine breitere Datengrundlage.

Jedes BGP-Update durchläuft folgende Schritte, um Assoziationen mit gefundenen Schleifen zu erkennen [77]:

1. Es wird geprüft, ob die Zieladresse der betroffenen Pakete (d.h. Pakete in der Schleife) zu propagierten (Advertised) oder zurückgezogenen (Withdrawn) Präfixen des BGP-Updates passt (Longest Prefix Match).

2. Das BGP-Update muss in einer zeitlichen Nähe von 2 Minuten zur gefundenen Schleife liegen.

3. Ein Zebra-Router (Projektseite: www.zebra.org) wird mit dem BGP-Update versorgt, um zu überprüfen, ob der BGP-Entscheidungsprozess die Attribute NEXT_HOP oder AS_PATH für das Zielpräfix ändert.

Das Verfahren ist sowohl für temporäre als auch persistente Schleifen geeignet. Bei persistenten Schleifen kann das verursachende BGP-Update schon länger zurückliegen und dementsprechend nicht im Datenstrom aufgezeichnet worden sein.

3.2.1.2 D

Z

-A

P

In [77] werden im Jahr 2003 mehrere Paketaufzeichnungen von OC-48 Links zwischen Backbone-Routern aus dem SprintLink Netzwerk analysiert. Drei Aufzeichnungen sind 1 Stunde und drei 12 Stunden lang (Abbildung 32). Als Bedingung für persistente Schleifen, müssen diese eine Woche lang bestehen. Nach dem Finden der Schleifen in den Aufzeichnungen werden Traceroutes zu verschiedenen Zeitpunkten über eine Woche ausgeführt, um die Dauer zu ermitteln.

Abbildung 32: Anzahl der in Schleifen geratenen Pakete (2003) [77]

Auffällig ist, dass die Anzahl in extremen Größenordnungen variiert (Abbildung 33). Es wird versucht, gesammelte BGP- und IS-IS-Updates als Ursache den gefundenen Schleifen zuzuordnen. BGP-Updates werden zum einen selbst gesammelt und zugeordnet, zum anderen werden Informationen des Routeviews-Projekts herangezogen, und diese versucht den Schleifen zuzuordnen. Es kann kein einziges IS-IS Routing-Update den gefundenen Schleifen zugeordnet werden. Die Autoren gehen davon aus, dass die Konvergenzzeit bei IS-IS zum einen nicht kritisch ist und das Feature Equal-Cost Multi-Path das schnelle Auffinden von Alternativen ermöglicht.

Abbildung 33: Erfolgsrate der Zuordnung der BGP-Updates zu Schleifen (2003) [77]

Die starke Varianz der erfolgreichen Zuordnung lässt sich aus mehreren Gründen ableiten.

Zum einen können Schleifen schon vor der Aufzeichnung existieren und das verursachende BGP-Update konnte nicht aufgezeichnet werden. Weiterhin kann eine Schleife durch externe BGP-Updates verursacht werden. 50,8% bzw. 80,6% der gefundenen Schleifen in NYC-20 und NYC-22 sind persistent, jedoch kann keine Zuordnung zu BGP-Updates gefunden werden (Abbildung 33). Ein Sonderfall besitzt NYC-25. Hier können alle persistenten Schleifen (15,5% aller gefundenen Schleifen) einem BGP-Update zugeordnet werden (Abbildung 33). In NYC-24 und NYC-23 können keine persistenten Schleifen gefunden werden, was nicht die Abstinenz beweist, sondern auf andere Faktoren schließen lässt, die die Erkennungstechnik beeinflusst haben (Abbildung 33).

Abbildung 34: Erfolgsrate bei der Zuordnung nach Quelle der BGP-Updates (2003) [77]

Um externe Updates als Ursache miteinzubeziehen, werden die aufgezeichneten BGP-Updates des Routeviews-Projekts zugeordnet und die Erfolgsrate verglichen (Abbildung 34).

Eine Verbesserung von 7% bei NYC-23 lässt auf vermehrt externe Ursachen schließen (Abbildung 34), was wiederum die niedrige Erfolgsrate bei der Zuordnung aufgezeichneter BGP-Updates aus dem SprintLink-Netzwerk erklärt. Unterstützt wird diese Annahme durch die durchschnittliche Anzahl durchlaufener AS der gefundenen Schleifen, die bei NYC-23 am höchsten ist (Abbildung 35).

Abbildung 35: Durchschnittlich Anzahl durchlaufener AS in Schleifen (2003) [77]

Abbildung 36: Verteilung der Zieladressen der Schleifen auf AS# (2003) [77]

Abbildung 36 beschreibt die Verteilung der Zieladressen auf die Anzahl der Autonomen Systeme. Die Mehrheit der Zieladressen der Schleifen in NYC-21 (78%) und NYC-22 (81%)

gehören zu einem AS. Das AS in NYC-21 gehört zu einem Kunden und im Fall von NYC-22 ist das AS Teil des SprintLink-Netzwerks, was die Trefferquote von 99,4% bei der Zuordnung erklärt, da alle BGP-Updates aufgezeichnet werden konnten (Abbildung 33).

Zieladressen der Schleifen in NYC-20 sind über mehrere AS verteilt, wobei zwei dominante AS (verantwortlich für 50% bzw. 39% der Schleifen) hervorstechen. In NYC-24 und NYC-25 verteilt sich die Dominanz auf weitere AS. Die meiste Variation bietet NYC-23 und liefert eine weitere Erklärung für die niedrige Erfolgsrate bei der Zuordnung aufgezeichneter BGP-Updates.

Abbildung 37: Charakteristika der Schleifen in NYC-21 (2003) [77]

Sind nur wenige BGP-Updates für die Schleifenentstehung verantwortlich, verteilt sich das TTL-Delta auf ein kleineres Spektrum. Ist die Anzahl der für Schleifen verantwortlichen BGP-Updates relativ klein, ist die Verteilung der Zieladressen ebenfalls klein. Ein großer Teil der Schleifen folgt somit dem gleichen Pfad, was sich in einer schmaleren Verteilung der Schleifengrößen widerspiegelt.

Abbildung 38: Charakteristika der Schleifen in NYC-20 (2003) [72]

Abbildung 37 (5a) zeigt, dass 74% der Schleifen in NYC-21 eine Größe von 10 und 18% eine Größe von 8 haben. Diese schmale Verteilung sollte implizieren, dass nur wenige

BGP-einzigen BGP-Update verbunden (Index 8 in Abbildung 37 (5b)). Das BGP-Update mit dem Index 8 erzeugt Schleifen mit einem TTL-Delta von 10 und 8 (Abbildung 37 (5c)).

50,8% der Schleifen in NYC-20 haben ein TTL-Delta von 14 (Abbildung 38).

Interessanterweise existieren diese vor der Aufzeichnung, sodass keine verursachenden Updates aufgezeichnet werden konnten. Abbildung 38 (6b) zeigt wiederum, dass das BGP-Update mit dem Index 2 an der Bildung der meisten Schleifen beteiligt ist und durchschnittlich Schleifen der Größe 9,5 formt.

Abbildung 39: Charakteristika der Schleifen in NYC-25 (2003) [77]

Die Gegenprobe bilden die Charakteristika der Schleifen in NYC-25. Hier sind eine große Anzahl an BGP-Updates für die Schleifenbildung verantwortlich Abbildung 39 (9b), was sich in einem größeren Spektrum an TTL-Deltas ausdrückt Abbildung 39 (9a).