Zusammenfassung

  • Randy Bush verlangt in RFC 7115 vor einem ROA für einen übergeordneten Block die Prüfung aller Unterzuteilungen, die andere ASes ankündigen. Ohne passende ROAs können Kundenankündigungen als Invalid gelten.
  • Die Änderung läuft über validierende Caches zu Routern und trifft dort auf die lokale Routing-Policy. Bush empfiehlt mehrere Caches mit mindestens einem lokalen Exemplar sowie regelmäßige Synchronisation.

Eine vergessene Zeile reist um die Welt

Der Adressinhaber sieht den großen Block in seinem Verzeichnis. Der Kunde sieht darin einen kleineren Bereich, den er über sein eigenes autonomes System bekanntgibt. Beide schauen auf echte Einträge, doch in der ROA-Vorbereitung fehlt der zweite Blick. Der Inhaber signiert den Block; der neue Datensatz wandert durch die RPKI-Caches. Auf einem validierenden Router kann neben der Kundenroute plötzlich Invalid stehen. Die Kundenankündigung ist dieselbe geblieben. Der Eintrag für den übergeordneten Block hat sich geändert.

Das steht im RFC 7115, Bushs Best-Current-Practice-Dokument vom Januar 2014. Vor der Ausstellung eines ROA für einen Superblock muss der Betreiber sicherstellen, dass jede von einem anderen AS angekündigte Unterzuteilung ein korrektes ROA besitzt. Sonst erscheinen die Ankündigungen ohne passende Kinder-ROAs als Invalid. Solange Empfänger ihre eigenen Einträge registrieren, darf der Blockinhaber aktuelle BGP-Daten als Grundlage für vorläufige ROAs verwenden. Die Reihenfolge ist klar: erst die Mieter erfassen, dann die Haustür sichern.

Im RFC 6811 sind die drei Ergebnisse der Herkunftsprüfung beschrieben: Valid, NotFound und Invalid. Ein Router vergleicht Präfix und Ursprung-AS einer Ankündigung mit validierten ROA-Daten. Ein neues, umfassendes ROA kann eine spezifischere Kundenroute in Konflikt mit Ursprung oder erlaubter Präfixlänge bringen. Was der Router danach mit Invalid tut, legt der Netzbetreiber in seiner lokalen Policy fest. Wo Invalid verworfen wird, entscheidet der Fehler in der Kundenliste über Erreichbarkeit.

Bush schrieb mit Rob Austein auch den RFC 6810, das Protokoll zur Übertragung validierter Herkunftsdaten vom Cache zum Router. In RFC 7115 rät er zu mehr als einem Cache pro Router, mindestens einer davon lokal. Lokale Caches, die Routingentscheidungen speisen, sollten mindestens alle vier bis sechs Stunden miteinander synchronisiert werden. Wer Daten aus einem Upstream-Cache bezieht, sollte sie erneut validieren. Eine Signatur entfaltet ihre Wirkung also durch einen verteilten Betriebsablauf.

Die RIPE-NCC-Biografie verortet Bush in jahrzehntelanger Arbeit an Routing-Sicherheit und RPKI. Sein RFC liest sich entsprechend wie eine Betriebsanweisung: Unterzuteilungen zählen, ROAs abgleichen, Caches beobachten, Policy kennen. Das namentlich zugeordnete RIPE-NCC-Foto lieferte die Vorlage für das redaktionelle Porträt; die zwei Geräteschränke im Hintergrund sind erfunden.

Der Star dieser Geschichte ist keine Signatur. Es ist eine unspektakuläre Tabelle mit Kundenpräfixen und ihren Ursprung-ASes. Eine fehlende Zeile kann einem Router am anderen Ende der Welt eine andere Bewertung liefern. Bush stellte den Abgleich vor die Veröffentlichung. So endet die Feier über die neue Sicherheitsschicht nicht mit einem Kunden, der fragt, warum seine Route plötzlich rot markiert ist.