Zusammenfassung

  • Die auf den 1. Oktober datierte Fassung 05 des SAVNET-Entwurfs trennt Betreiber-Provisionierung von der Übernahme von Informationen aus dem Routing. Für BYOIP- oder anderweitig extern bezogene Präfixe soll der Betreiber den Kunden um Benennung und um einen Nachweis bitten, dass er sie als Quelladressen nutzen darf. Das gilt auch ohne konfigurierte oder angekündigte Route.
  • Der Text ist weiterhin ein aktiver, als informativ vorgesehener Internet-Draft. Er ist weder verabschiedeter RFC noch Einsatzbericht und legt weder ein allgemeingültiges Beweisformat noch ein neues Inter-AS-Protokoll oder automatisches Verwerfen aller beanstandeten Pakete fest.

Der Router sieht ein Paket an einem konkreten Kundenanschluss. Seine Routingtabelle beantwortet dagegen vor allem Fragen nach Erreichbarkeit und Weiterleitung. Aus einer Zielroute folgt nicht zwingend die Erlaubnis, das Präfix als Quelle an genau diesem Anschluss zu verwenden. Umgekehrt kann einem berechtigten Kunden ein Quellpräfix zustehen, das in der betreffenden Routingansicht fehlt. Für eine brauchbare Eingangskontrolle muss der Betreiber diese unterschiedlichen Tatsachen in einer Regel pro Schnittstelle zusammenführen.

Bereits die Juni-Fassung der Architektur nannte asymmetrische Wege, verborgene Präfixe und die Grenzen von Routinginformationen als Berechtigungsnachweis. Sie beschrieb auch den logischen SAV Agent. Die Neuerung von Fassung 05 liegt deshalb nicht in der allgemeinen Erkenntnis, dass Route und Autorisierung auseinanderfallen können. Sie ordnet die Informationsgewinnung genauer: Kundendaten, Adresszuweisungen und Konfigurationen können über die Provisionierung genutzt werden; relevante Routingdaten können zusätzlich aus dem Routing-System stammen. Beides lässt sich kombinieren.

Ein im Routing fehlendes Recht kann das Routing selbst jedoch nicht nachliefern.

Die BYOIP-Passage verortet den Nachweis beim Kundenverhältnis. Bringt ein Kunde ein eigenes oder von einem anderen Anbieter erhaltenes Präfix mit, soll der AS-Betreiber es erfassen und Belege für seine Nutzung als Quelle anfordern. Diese Berechtigung muss auch dann in den Eingang des SAV Agent gelangen, wenn der Kunde dafür keine Route ankündigt. Der Entwurf erklärt weder eine ROA noch einen Registereintrag zum allein ausreichenden Beweis. Welches Material der Betreiber akzeptiert und wie er es einem Kunden und seinen Anschlüssen zuordnet, bleibt eine konkrete Betriebsentscheidung.

Das Beispiel der neuen Fassung zeigt Kunde C an i1 und i2. P1 und P2 können aus geeigneten Routing- oder Betriebsdaten stammen. H ist ein verborgenes Präfix, das nur als Quelle gebraucht wird und im Routing fehlt. Wenn C alle drei nutzen darf, müssen die Erlaubnislisten an beiden Anschlüssen dies abbilden; für H braucht der Betreiber eine ausdrückliche Berechtigungsinformation. Änderungen an Präfixzuweisung, Anschlusszuordnung oder Quellberechtigung müssen die betroffenen Regeln erreichen. Der Fall ist ein Modell, kein Bericht über eine reale Installation.

Die Architektur empfiehlt Erlaubnislisten, warnt jedoch zugleich vor unvollständigen Eingaben, die legitimen Verkehr sperren können. Die Behandlung als ungültig klassifizierter Pakete ist lokale Politik und hängt vom Einführungsstand ab; Beobachtung oder Protokollierung kann einem strikten Drop vorausgehen. Weder Algorithmus noch Standort des SAV Agent werden festgelegt. Im Datatracker steht das Dokument auf I-D Exists. Entscheidend ist damit nicht allein, ob gefiltert wird, sondern ob sich die Kette vom Kundenbeleg bis zur installierten Schnittstellenregel prüfen lässt.

Quellen