Zusammenfassung

  • RFC 2908 teilte die Multicast-Adressvergabe in drei Ebenen: Client zu Server, Koordination innerhalb einer Domäne und Vergabe zwischen Domänen. Das experimentelle RFC 2909 beschrieb MASC als Verfahren, mit dem Domänen befristet Adresspräfixe beanspruchen, unterteilen oder an Kinddomänen delegieren konnten.
  • RFC 2909 warnte, dass IPsec zwei Peers schützen kann, ohne den Ursprung eines weitergeleiteten UPDATE zu authentifizieren: Ein nicht vertrauenswürdiger MASC-Knoten an anderer Stelle der Topologie könnte schädliche Updates einspeisen. Die vorgesehene Grenze war administratives Vertrauen in Peers – kein Beleg für Einsatz, Angriff oder Datenverkehr.

Im September 2000 musste die Architektur für Multicast-Adressen zwei Fragen auseinanderhalten, die leicht ineinanderlaufen: Wer gibt einer Anwendung eine Gruppenadresse, und wer reserviert den größeren Bereich, aus dem sie stammt? RFC 2908 behandelte beides nicht als einen einzigen Vorgang. Es trennte die Arbeit in drei Ebenen. Ein Client fragt einen Zuweisungsserver an; Server koordinieren sich innerhalb einer Domäne; ein Inter-Domänen-Verfahren stellt den Domänen Adressbereiche bereit. MADCAP konnte die erste, AAP oder manuelle Konfiguration die zweite und MASC eine mögliche dritte Ebene bedienen.

Damit glich die Multicast-Vergabe nicht mehr einem einzigen globalen Zähler. Ein MASC-Knoten, meist auf einem Border Router erwartet, handelte für eine Domäne, die oft einem Autonomen System entsprach. Er wählte ein Präfix aus einem größeren Bereich, sandte seinen Claim an konfigurierte Peers und wartete auf kollidierende Claims. Die Eltern-Kind-Hierarchie erlaubte es, ein erhaltenes Präfix für lokale Zuweisungsserver aufzuteilen oder Teilpräfixe an Kinddomänen weiterzugeben. Das Präfix konnte außerdem in Multicast-Routeninformationen eingehen, die ein separates Routingprotokoll nutzen konnte.

Diese Steuerflächen hängen zusammen, sind aber nicht dasselbe: Eine MASC-Zuweisung erzeugt nicht automatisch eine Route, eine Empfänger-Mitgliedschaft oder zugestellte Pakete.

Claims liefen ab. Jedem Präfix war eine Lebensdauer zugeordnet; wer es weiterverwenden wollte, musste diese vor dem Ablauf verlängern. Wenn die Verlängerung scheiterte, sollte die Domäne das Präfix nicht mehr verwenden und den zugehörigen Routingzustand entfernen. Delegierter Adressraum war also nicht automatisch dauerhaft. Zuweisungszustand, Routingzustand und Anwendungsnutzung konnten sich dennoch auseinanderentwickeln, wenn ein Betreiber nur eine Ebene beobachtete. Ein Steuerungseintrag ist kein Paketmitschnitt.

Auch den Zielkonflikt bei knappem Adressraum legte die Architektur offen. Eine strikte Aufteilung kann Kollisionen zwischen Domänen sicher verhindern, doch Reserven für Netzpartitionen und Failover zersplittern den Pool. RFC 2908 priorisierte daher gute Auslastung und dauerhafte Verfügbarkeit gegenüber einer absoluten Garantie, dass es nie Kollisionen gibt. Angestrebt wurde eine sehr hohe, aber nicht hundertprozentige Kollisionsfreiheit. MASC-Claims, Vergleichsregeln, Wartezeit und ein neues Präfix nach einer Kollision setzten diese probabilistische Entscheidung um; mathematische Gewissheit boten sie nicht.

RFC 2909 benannte anschließend eine andere Grenze: die Herkunft von Updates. Ein UPDATE musste nicht bei dem Peer enden, der es zuerst empfing. MASC-Knoten speicherten und leiteten Updates zwischen Eltern, Geschwistern, Kindern und internen Peers weiter. RFC 2909 hält fest, dass IPsec die Verbindung zwischen zwei Peers absichern kann. Doch wenn irgendwo in der Topologie ein nicht vertrauenswürdiger MASC-Knoten angeschlossen ist, kann er schädliche UPDATEs einspeisen, die andere Knoten möglicherweise nicht als solche erkennen. Deshalb sollten MASC-Knoten nur mit vertrauenswürdigen Knoten Peering-Verbindungen eingehen.

Bei der Wiederherstellung nach einem Neustart gilt der Zustand von Eltern oder internen Peers typischerweise als vertrauenswürdig; eigene UPDATEs, die über Geschwister oder Kinder ankommen, darf ein Knoten verwerfen.

Das bedeutet nicht, dass „IPsec nichts bringt“. Linkschutz schützt eine konkrete Nachbarschaft. Die Lücke entsteht, sobald die Information darüber hinaus weitergereicht wird: Der nächste Hop kann wissen, von welchem Peer er sie bekam, aber nicht zwingend unabhängig feststellen, wer den Claim ursprünglich erzeugt hat oder ob jeder Zwischenknoten ihn weitergeben durfte. Zeitstempel und Ursprungsknoten-IDs helfen beim Vergleich konkurrierender Claims; RFC 2909 bezeichnet sie nicht als kryptografische Herkunftsauthentisierung. Es berichtet auch keinen tatsächlich erfolgten Angriff.

Es beschreibt ein Bedrohungsmodell und überlässt den Betreibern die Konfiguration des Peer-Graphen.

Das ist wichtig, weil ein Präfix-Claim mehrere Zuweisungsserver beeinflussen kann. Ein angenommener und weitergereichter UPDATE kann benachbarte Claims begrenzen und in den Multicast-Routingzustand einfließen, bevor eine Anwendung überhaupt eine Adresse anfordert. RFC 2909 schlägt keine globale Instanz vor, die jeden Claim zertifiziert. Es setzt stattdessen auf Peering nur mit vertrauenswürdigen Knoten und auf Regeln, die beim Annehmen weitergeleiteter Updates den Pfad berücksichtigen. Die wirksame Kontrolle liegt damit in Topologiedesign und Vertrauensverwaltung.

Die RFC-Statusangaben begrenzen auch die historische Aussage. RFC 2908 ist informativ und beschreibt eine vorgeschlagene Architektur; RFC 2909 ist ein experimentelles Protokoll, kein Internetstandard. Die Dokumente belegen, dass ihre Autoren ein mehrschichtiges Zuweisungsmodell und dessen Risiken formulierten. Sie zeigen nicht, wie viele Netze MASC implementierten, ob es verbreitet eingesetzt wurde oder ob ein schädliches Update einen Ausfall verursachte. GLOP aus RFC 3180 und die IANA-Registrierung nach RFC 3171 sind andere Zuweisungswege und belegen keinen MASC-Einsatz.

Die belastbare Lehre ist enger: Präfix-Claim, geschützte Verbindung, vertrauenswürdiger Ursprung, Route und tatsächlich empfangener Multicast-Strom sind verschiedene Tatsachen. Eine sichere Steuerungsebene muss angeben, welcher Nachweis den Übergang von einer zur nächsten erlaubt.

Quellen