Skip to main content
Docs

MANRS-Compliance.

DATAHUB-IX nimmt am MANRS IXP Programme teil. Jede Aktion des Programms ist umgesetzt und wird jährlich auditiert.

Mutually Agreed Norms for Routing Security (MANRS) ist eine Initiative der Internet Society zur Härtung des globalen Routings gegenüber Leaks, Spoofing und Bogon-Traffic. Das IXP Programme definiert fünf konkrete Aktionen – wir erfüllen alle fünf.

Aktion 1 · Routenfilterung

Alle Route-Server-Sessions filtern auf Basis IRR-registrierter AS-SETs und Prefix-Listen. Mitglieder müssen ihr AS-SET (z. B. AS-YOURASN) vor der Inbetriebnahme bei RIPE, RADB oder ARIN registrieren. Filter werden täglich neu generiert.

Aktion 2 · Anti-Spoofing

Mitglieder sind verpflichtet, BCP38/SAVE auf kundenseitigen Interfaces zu implementieren. Wir führen unaufgefordert Spoof-Tests zweimal pro Quartal durch und nutzen RIPE-Atlas-Anchors als Quelle.

Aktion 3 · Koordination

NOC-Kontakte der Mitglieder werden in PeeringDB und im Member Portal aktuell gehalten. Operative Mitteilungen werden per signierter PGP-Mail und über die öffentliche Status-Seite verteilt.

Aktion 4 · Globale Validierung (RPKI)

Drei unabhängige Routinator-Validatoren versorgen die Route Server. Invalid-Announcements werden verworfen. Mitglieder müssen ROAs für jedes announcete Prefix publizieren.

Aktion 5 · IXP-spezifische Filterung

An den Route Servern filtern wir Bogons, Default-Route, RFC1918 sowie nicht zugewiesene/reservierte Bereiche. Maximum-Prefix-Limits werden durchgesetzt und sind je Mitglied einstellbar.

Warum das wichtig ist

Ein Leak oder Hijack auf einem IXP propagiert global innerhalb von Minuten. Filter-Disziplin ist nicht optional – sie ist der Unterschied zwischen einer Peering-Fabric, die das Internet stärkt, und einer, die es schwächt. MANRS-Audits halten uns ehrlich.

Für Mitglieder

Der Beitritt zu DATAHUB-IX impliziert die Verpflichtung auf die MANRS-Network-Operator-Aktionen. Wir verlangen keine Zertifizierung, erwarten aber:

  1. Aktuelle IRR-Objekte mit strikter AS-SET-Hierarchie.
  2. RPKI-ROAs für jedes announcete Prefix mit konservativem maxLength.
  3. BCP38-Filterung an allen kundenseitigen Interfaces.
  4. Aktueller peeringdb.com-Eintrag mit erreichbaren NOC-Kontakten.

Ressourcen