Zusammenfassung
- RFC 5920 beschreibt den MPLS/GMPLS-Core eines Providers als eigene Vertrauenszone; ein Interprovider-Nachbar kann autorisiert und dennoch nicht vertrauenswürdig sein.
- Authentisierung stellt Identität fest, erteilt aber keine pauschale Befugnis für Routen, Labels, Signalisierung, Reservierungen oder OAM.
- Der Nutzen der Kopplung bleibt erhalten, wenn jedes ASBR nur vereinbarte Zwecke zulässt und Filter, Ratenbegrenzung, Beobachtung und Trennungsrecht lokal bleiben.
Ein Vertrag verschiebt keine technische Grenze
Eine Peering-Vereinbarung erlaubt einen bestimmten Austausch. Sie bescheinigt nicht die Korrektheit jeder Konfiguration und jeder Nachricht aus dem Partnernetz. Im Referenzmodell von RFC 5920 endet die Vertrauenszone jedes Providers an seinen ASBRs. Der andere Provider ist bekannt und zur Kommunikation zugelassen, bleibt aber eine eigenständige Autorität außerhalb dieser Zone.
Über dieselbe Verbindung fließen Nutzen und Fehler. Kunden erhalten Reichweite über mehrere Netze; Provider können gemeinsam Dienste bereitstellen. Zugleich können gefälschte Updates, fehlerhafte Nachrichten, übermäßige Anforderungen, falsche Querverbindungen oder Ressourcenlast die Grenze passieren. Ein Defekt oder eine Kompromittierung beim Partner kann so zur lokalen Gefährdung werden, obwohl nie allgemeine interne Befugnis übertragen wurde.
Auch das MPLS-Label beweist die Herkunft nicht. RFC 5920 hält fest, dass Labels lokal bedeutsam sind und die MPLS-Datenebene keine zur Quellenauthentisierung geeignete Absenderkennung trägt. Ein plausibles Label belegt weder Ursprung noch Zweck oder Berechtigung. Identität muss über das passende Kontroll- oder Managementverfahren festgestellt werden; danach entscheidet weiterhin die Interconnection-Richtlinie.
Identität, Erlaubnis und Vertrauen sind getrennte Entscheidungen
Authentisierung beantwortet, wer sendet. Autorisierung bestimmt, was diese Identität tun darf: ein Protokoll nutzen, eine LSP-Klasse einrichten, eine Route ankündigen, OAM senden, Bandbreite reservieren oder Rechenkapazität beanspruchen. Vertrauen beschreibt, wie viel Verhalten ohne weitere Prüfung angenommen wird. Die drei Fragen brauchen unterschiedliche Nachweise.
Wer sie zusammenfasst, schafft stillschweigende Macht. Dann legitimiert eine authentisierte Sitzung jedes technisch mögliche Objekt, und ein erlaubter Dienst macht den gesamten fremden Core vermeintlich vertrauenswürdig. Das ASBR verliert seine Funktion als Risikogrenze. RFC 5920 weist in die andere Richtung: Beziehung erhalten, Quellen, Protokolle, Mengen und Ressourcen aber einzeln begrenzen.
Dazu gehört ein Bündel von Kontrollen: Sitzungsauthentisierung, Routing-Policy, Filter in beide Richtungen, Behandlung fehlerhafter Pakete, Grenzen je Interface oder Provider, selektive Protokollfreigabe und Monitoring. Kryptografie schützt Identität und Integrität, verhindert jedoch nicht jede CPU- oder Bandbreitenerschöpfung und verursacht Schlüssel- und Betriebsaufwand. Filter können legitime Wiederherstellung blockieren. Rate Limits können Kapazität schützen und eine echte Lastspitze verschärfen. Diese Zielkonflikte verlangen verantwortliche Entscheidungen.
Nutzen und Last sind ungleich verteilt
Kunden profitieren von netzübergreifender Erreichbarkeit, Provider von größerer Abdeckung. Die Teams an den ASBRs tragen dagegen Konfigurations-, Schlüssel-, Kapazitäts-, Telemetrie- und Übungskosten sowie das Risiko falscher Sperren. Eine enge Regel schützt den Core und kann einen Kundendienst unterbrechen; eine weite Regel hält ihn kurzfristig offen und lässt möglicherweise unerwarteten Zustand eindringen.
Der Sender hat einen Anreiz zur schnellen Annahme, der Empfänger trägt das unmittelbare Verarbeitungsrisiko. Deshalb muss die bilaterale Vereinbarung erlaubte Protokolle, Objekte, Raten, Änderungsbefugnis, Beweissicherung und Isolationsrechte festlegen. Die Identität des Gegenübers entscheidet nichts davon automatisch.
Das Gegenbild zeigt die übertragene Macht
Ohne Interconnection entfällt dieses Risiko, aber auch der gemeinsame Dienst. Aussagekräftiger ist eine Verbindung, in der Autorisierung als Vertrauen behandelt wird. Im Normalbetrieb wirkt sie einfach; bei Fehler oder Kompromittierung wird fremder Zustand leichter zu internem Zustand, Ressourcenerschöpfung oder großflächiger Störung.
„Autorisiert, aber nicht vertrauenswürdig“ erklärt den Nachbarn nicht zum Gegner. Es erkennt ihn als getrennte Autorität an. Der Empfänger nimmt nur an, was für den vereinbarten Zweck nötig ist, beobachtet Abweichungen und behält die Eindämmung. Interne Zusicherungen des Partners ersetzen die eigene Sorgfalt an der Grenze nicht.
Belege und Grenzen
Die technischen Tatsachen stammen aus RFC 5920; RFC 5921 liefert MPLS-TP-Kontext, RFC 5718 grenzt das Thema vom vorherigen In-Band-Management-Beitrag ab. RFC 5920 ist informativ. Verantwortungsmodell und Betriebsentscheidungen sind Elias Wards Analyse.
Es gibt keine Behauptung über einen benannten Provider, Hersteller oder ein Live-Netz. Die Quellen belegen weder heutige Verbreitung noch eine konkrete Konfiguration, Vorfallhäufigkeit, gemessene Wirksamkeit oder eine aktuell geeignete Kryptosuite. Ohne aktuelle Betriebsbelege bleiben diese Punkte unbekannt.
Quellen
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten

