Zusammenfassung

  • Der Kunde wählt zulässige CE-Endpunkte und fordert eine Verbindung an; der Betreiber prüft die Richtlinie, berechnet das Kernsegment und weist Ressourcen zu.
  • Vertragliche CE-Zuordnung, Protokollauthentisierung, ausgelesener Cross-Connect und beobachtete Nutzdatenankunft sind eigenständige Belege.

Der Auftrag enthielt Ziele, aber keine Durchfahrtsrechte

Ein Kunde klickt auf zwei Standorte und löst den Aufbau aus. Das sieht nach Kontrolle über ein Netz aus. Tatsächlich kontrolliert er eine Anforderung.

RFC 5253 zieht die Grenze präzise. Der Kunde kann den Aufbau, die Änderung und den Abbau von Verbindungen zwischen berechtigten CEs verlangen. Das PE-zu-PE-Segment steht vollständig unter Kontrolle des Providers. Dieser kann den Pfad sofort berechnen, einen vorberechneten Pfad wählen oder ein bereits eingerichtetes Segment verwenden. Versucht der CE, mit einem Explicit Route Object den internen Providerpfad festzulegen, wird die Vorgabe verworfen.

Beide Seiten besitzen also echte, aber verschiedene Befugnisse. Der Kunde bestimmt den gewünschten Zusammenhang. Der Provider bestimmt seine technische Realisierung. Self-Service überträgt die zweite Befugnis nicht; er verkürzt nur den Weg der ersten bis zur Providergrenze.

Ein gemeinsamer Status „aktiv“ verschleiert diese Trennung. Eingang der Anforderung, Zulassung, Reservierung, Schaltzustand und tatsächliche Übertragung sind verschiedene Ereignisse.

Weniger Routingwissen bedeutet nicht weniger Abhängigkeit

Im Basic Mode tauschen CE und PE keine Routinginformationen aus. Der CE erhält entfernte CPIs über Konfiguration, Verzeichnis oder ein L1VPN-spezifisches Verfahren. Im Providernetz läuft weiterhin Routing; PEs können Mitgliedschaftsinformationen verteilen.

Das schützt den Kern vor direktem Kundeneinfluss und den Kunden vor unnötiger Komplexität. Zugleich hängt die Verbindung von unsichtbaren Providerzuständen ab: PIT, Mitgliedschaft, Verbindungsregel, physische Kapazität und Berechnungsversion.

Ein PE, ein PCE oder ein Managementsystem kann den Pfad berechnen. Zwischen denselben PEs können mehrere Segmente liegen. Ein Path Key kann ein vertrauliches Segment bezeichnen, ohne seinen Verlauf offenzulegen.

Diese Abstraktion ist sinnvoll. Sie begrenzt aber auch die Aussage eines positiven Signals. Ein Schlüssel beweist keine aktuelle Faserfolge. Eine RSVP-Antwort zeigt nicht, welche Richtlinie entschied. Ein reserviertes Segment zeigt nicht, was die Geräte tatsächlich geschaltet haben.

Der Betreiber muss deshalb intern Auftrag, Richtlinie, Berechnung, Zulassung, Reservierung, Schaltung und Messung verbinden. Der Kunde braucht keinen Kernplan, aber einen auf sein gekauftes Ergebnis bezogenen Nachweis.

Geheimhaltung ist in beide Richtungen unterschiedlich

Der Provider kann interne Routen verbergen: Es gibt keine Routeverteilung an den CE, RRO-Daten dürfen gefiltert, interne Notify-Adressen ersetzt und vertrauliche Segmente durch Schlüssel bezeichnet werden.

Umgekehrt kennt der Provider mindestens Adressen und Standorte der CEs. Ohne diese Daten könnte er Ports weder dem richtigen L1VPN zuordnen noch Verbindungsbeschränkungen anwenden. Andere Kundentopologie kann verborgen bleiben; die Anschlusspunkte bleiben sichtbar.

Diese Asymmetrie ist zunächst eine technische Notwendigkeit, aber zugleich Informationsmacht. CE-Standorte können kritische Betriebsstätten, Konzentration und Ausweichkonzepte erkennen lassen. Ihre Nutzung braucht Zweckbindung, minimale Berechtigungen, Aufbewahrungsregeln und Protokollierung.

Kernvertraulichkeit darf auf der anderen Seite nicht jede Leistungsbehauptung unprüfbar machen. Knoten können geheim bleiben, während der Provider Diversitätsklasse, Wiederherstellungsziel und Messergebnis belegt. Geheim und unbeweisbar sind nicht dasselbe.

Ein Vertragseintrag authentisiert keine spätere Nachricht

Beim Hinzufügen eines CE wird die Instanz im Rahmen des Dienstvertrags identifiziert und ein Steuerkanal eingerichtet. RFC 5253 stellt klar: Ohne die vorgesehenen RSVP-TE-Verfahren ist der Signalisierungspartner damit noch nicht authentisiert.

Der Vertrag sagt, wer den Dienst nutzen soll. Die Konfiguration sagt, welche Adresse ihn repräsentiert. Authentisierung bindet eine Nachricht an Zugangsdaten. Integrität schützt ihren Inhalt. Autorisierung entscheidet, ob auch eine echte Nachricht diese Verbindung verlangen darf.

Ein Feld „vertrauenswürdiger Kunde“ beantwortet keine dieser Fragen sauber. Ein alter Schlüssel kann nach Vertragsende weiterleben. Ein echter Kunde kann ein unzulässiges Zielpaar verlangen. Eine geschützte Nachricht kann zu einer Fehlschaltung führen.

Auch ein physisch getrennter Steuerkanal ist kein endgültiger Beleg. Er kann als sicher gelten, doch stärkere Mechanismen wie IPsec müssen verfügbar bleiben. Bei gemeinsam genutzten Kanälen sollen Schutzverfahren nicht nur vorhanden, sondern durchgesetzt sein.

Späte Ablehnung ist politisch korrekt und betrieblich teuer

Eine Verbindungsbeschränkung kann am Eingangs- oder Ausgangs-PE geprüft werden. Beide Varianten verhindern das unzulässige Endergebnis. Nur die Eingangsprüfung stoppt eine bereits erkennbare Fehlanforderung vor dem Kern.

Wird erst am Ausgang abgelehnt, haben Zwischenknoten Signalisierung verarbeitet und möglicherweise vorläufigen Zustand angelegt. Der RFC benennt diesen verschwendeten Aufwand. Eine Statistik über blockierte Versuche kann daher gut aussehen, obwohl jeder Versuch maximal teuer wurde.

Zu messen sind Ablehnungsort, berührte Systeme, Lebensdauer des Zwischenzustands und Konkurrenz zu legitimen Anforderungen. Die Ausgangsprüfung bleibt als zweite Linie sinnvoll. Sie ersetzt keine stabile Eingangsregel.

Schutz braucht eine benannte Fehlergrenze

Basic Mode kann Schutz für das PE-PE-Segment, Links und den Steuerkanal nutzen. Nicht jede Kombination ist möglich. Eine Linkschutzanforderung kann nicht isoliert nur CE-PE oder nur PE-PE schützen. Edge-Link-Recovery und Core-Segment-Recovery lassen sich in diesem Modell nicht beliebig kombinieren. Vollständige Dual-Homing-Wiederherstellung über verschiedene PEs liegt außerhalb des Umfangs.

„Geschützt“ muss deshalb den Fehler benennen: Zugang, Kernsegment, Gerät, Standort oder Shared-Risk-Gruppe. Ein angenommenes Schutzattribut beweist keine physische Trennung. Wiederhergestellte Signalisierung beweist keine geänderte optische Matrix. Licht beweist keine wiederhergestellte Anwendung.

Jede Phase benötigt eine eigene Uhr. Nur so lässt sich Verantwortung der richtigen Steuerfläche zuordnen.

Eine dedizierte Leitung kann falsch enden

Optische Verbindungen sind schwerer abzugreifen, und die Bindung an ein L1VPN schafft Isolation. Trotzdem nennt RFC 5253 die Fehlschaltung als Sicherheitsrisiko. Ein falscher Cross-Connect kann Daten an einen falschen Empfänger liefern und weiterhin exklusiv aussehen.

Mitgliedschaftsregeln begrenzen Verbindungen auf CEs desselben L1VPN. Sie beobachten aber nicht den endgültigen Lichtweg. Für sensible Daten soll der Kunde seine eigene Schicht schützen, etwa IP-Verkehr mit IPsec.

Starke Evidenz entsteht aus beiden Blickrichtungen. Der Provider liest Schaltungen und Ressourcen zurück. Der Kunde authentisiert die Gegenstelle und prüft die Lieferung. Keine Seite erklärt ihren ACK zum Nachweis für den unsichtbaren Bereich der anderen.

Zwei Zuständigkeiten brauchen zwei Belegketten

Pro Verbindung gehören Vertragsrevision und berechtigte CEs, Steuerkanal-Zugangsdaten, verlangte Endpunkte, Eingangsentscheidung, Segment und Berechnungsversion, Zulassung, beidseitiger Readback, Schutzumfang, gefilterte Topologiedaten und Nutzdatenprobe in getrennte Felder.

Der Kunde kann ein Ergebnis bestreiten, ohne den Kernplan zu verlangen. Der Provider kann zeigen, dass der Kunde nie interne Pfadhoheit erhielt, ohne den Plan zu veröffentlichen. Beide brauchen einen vor dem Vorfall vereinbarten Verknüpfungsnachweis.

RFC 5253 vermischt die Kontrolle nicht. Es setzt eine Naht zwischen Absicht und Ausführung. Wird sie prüfbar gehalten, bleibt ein verborgener Pfad ein erklärbarer Dienst.

Sources