BGP-Experiment 2010: Standardkonformität als Verantwortungstest

Zusammenfassung

Ein gültiges optionales transitives BGP-Attribut wurde beschädigt, als betroffene IOS-XR-Systeme es weiterleiteten, und löste Downstream-Session-Resets sowie eine breitere Routing-Instabilität aus.
Die Rechenschaftspflicht folgt getrennten Kontrollpunkten: Umfang und Überwachung des Experiments, Produktverhalten und Reparatur, Kontinuitätskontrollen der Betreiber und Fehlerbehandlung des Protokolls.

Am 27. August 2010 arbeiteten Mitarbeiter von RIPE NCC, die den Routing Information Service (RIS) betreiben, mit einer Forschungsgruppe der Duke University an einem Live-Experiment zum Border Gateway Protocol. Die Forscher untersuchten ein Secure-Routing-Design, bei dem Zertifizierungsinformationen in einem optionalen transitiven Pfadattribut transportiert wurden. Um 08:41 UTC erzeugte RIPE NCC 93.175.144.0/24 von RIS AS12654 über Verbindungen an AMS-IX und GN-IX. Die Route wurde wie geplant um 09:08 UTC zurückgezogen.[1]

Die Ankündigung war ungewöhnlich, weil das Attribut im öffentlichen Internet neu war. Ungewöhnlich bedeutete jedoch nicht fehlerhaft. RIPE NCC und Cisco bezeichneten das auslösende Attribut als gültig beziehungsweise standardkonform.[1][2] Diese Unterscheidung bestimmt, wie das Ereignis analysiert werden muss. Das Experiment zeigte nicht nur, dass Router ungültige Eingaben verwerfen. Es zeigte, dass eine standardkonforme Eingabe formale Prüfungen bestehen, auf einen Fehler in eingesetzter Software treffen, während der Propagierung beschädigt werden und anschließend an anderer Stelle eine schwere Fehlerbehandlung auslösen konnte.

Cisco berichtete, dass betroffene IOS-XR-Systeme das gültige, aber nicht erkannte transitive Attribut beim Weitersenden fehlerhaft behandelten. Ein benachbarter Router konnte das daraus resultierende beschädigte UPDATE empfangen und die BGP-Peering-Session zurücksetzen. Da eine BGP-Session viele Routen trägt, konnte die Reaktion auf ein einzelnes fehlerhaftes UPDATE vorübergehend nicht zusammenhängende gültige Erreichbarkeitsinformationen entfernen.

Wenn der für die ausgehende Beschädigung verantwortliche Router seinen eigenen Fehler nicht erkannte, konnte er die problematische Information nach der Rückkehr der Session erneut ankündigen und die Instabilität erneuern.[2][3]

Die Messungen von RIPE NCC stützen einen begrenzten, aber materiellen Wirkungsbefund. Das Ereignis erzeugte Update-Raten bis zum Zwanzigfachen des umgebenden Ausgangsniveaus. RIPE schätzte, dass zusätzliche 0,5 Prozent der Präfixe länger als normal vollständig unerreichbar wurden. Der Anteil instabiler Präfixe erreichte mit 1,4 Prozent einen Höchststand, was fast 4.500 Präfixen und etwa dem Neunfachen des gewöhnlichen Niveaus um das Ereignis entsprach. Die Ergebnisse variierten je nach Collector und Standort, wobei am Wiener Collector besonders intensive Update-Aktivität sichtbar war.[1]

Diese Zahlen sind bedeutsam, aber sie berechtigen nicht zu der Behauptung, ein bekannter Prozentsatz von Nutzern, Routern, Netzen oder Verkehr sei verschwunden. Beobachtungen der Control Plane zählen Routing-Verhalten, nicht Menschen. Die DNSMON-Analyse von RIPE ergab keinen Root-Server-Ausfall.

Sie ergab begrenzten Abfrageverlust für einige überwachte Domains und deutlichere Probleme an Teilen der autoritativen Infrastruktur von.si und.fr, während redundante Server weiterhin antworteten.[1] Zeitgenössische Betreiberkommentare erwähnten Zugriffsprobleme und Änderungen des Austauschverkehrs, doch solche Berichte ergeben keine vollständige quantitative Darstellung.[4][6]

Die Lektion zur Rechenschaftspflicht ist deshalb enger und nützlicher als die Erzählung eines einzelnen Akteurs, der „das Internet lahmgelegt“ habe. RIPE NCC kontrollierte, ob seine Messinfrastruktur eine internetweit sichtbare experimentelle Route erzeugte, sowie Zeitplanung, Ankündigung, Überwachung und Rücknahme. Die Duke-Forscher kontrollierten das Forschungsdesign und die forschungsseitige Implementierung. Cisco kontrollierte die IOS-XR-Behandlung eines nicht erkannten gültigen Attributs, seine Produkttests, die Offenlegung und die Wartungsfixes.

Netzbetreiber kontrollierten ihre installierte Software, Routing-Richtlinien, Peer-Schutzmaßnahmen, Überwachung und Wiederherstellung innerhalb ihrer eigenen Netze. Die Protokollregeln der damaligen Zeit lieferten einen Verstärkungsmechanismus, indem ein einziges fehlerhaftes UPDATE einen Fehler auf Session-Ebene auslösen konnte.

Die Reparaturen gehörten ebenfalls zu getrennten Ebenen.

Cisco veröffentlichte noch am Tag des Ereignisses eine Sicherheitswarnung und bereitete Wartungs-Upgrades vor.[2] RIPE NCC bewahrte Evidenz, lieferte dem Hersteller Informationen, veröffentlichte eine Analyse und verpflichtete sich zu strengeren Kontrollen für künftige kooperative Experimente.[1] Der Vorstand unterstützte später die fortgesetzte Forschung und betonte gleichzeitig eine angemessene Kommunikation.[5] Die Produktkorrektur verringerte das Implementierungsrisiko; eine stärkere Experiment-Governance verringerte das Risiko, eine unbekannte Wechselwirkung über einen unnötig breiten öffentlichen Fehlerbereich zu entdecken.

Spätere Standards helfen zu erklären, wie die Branche aus dieser Fehlerklasse gelernt hat, aber sie können nicht als Beweis dafür dienen, was im August 2010 eingesetzt oder verlangt war.

RFC 7606 propagierte später eine engere Behandlung fehlerhafter BGP-UPDATEs, weil das Zurücksetzen einer gesamten Session viele gültige Routen verwerfen kann.[13] Betriebliche Empfehlungen zu expliziter externer Policy, Route-Leak-Prävention, Origin-Validierung, RPKI und BGPsec erhellen benachbarte Kontrollen, aber keine davon begründet rückwirkend Fahrlässigkeit, und keine allein korrigiert den präzisen Fehler der ausgehenden Beschädigung, den dieses Ereignis offenlegte.[14][15][16][17][18][19][20]

Die zentrale Schlussfolgerung ist zurückhaltend: Eine gültige experimentelle Ankündigung löste eine Kette aus, in der ein Implementierungsfehler Informationen beschädigte, die Fehlerbehandlung auf Session-Ebene diese Beschädigung verstärkte und unzureichend begrenzte Live-Experiment-Kontrollen die Wechselwirkung im öffentlichen Internet exponierten. Die Rechenschaftspflicht folgt der Zuweisung von Kontrolle, nicht der Einfachheit des ersten sichtbaren Auslösers.

1. Warum dieses Ereignis eine enge Analyse verdient

BGP-Vorfälle werden häufig zu Etiketten wie Leak, Hijack, Ausfall oder Fehlkonfiguration verdichtet. Diese Etiketten können nützlich sein, wenn die Evidenz zu ihnen passt, aber sie können auch den Mechanismus auslöschen, der tatsächlich zählt. Dieses Ereignis erfordert eine präzisere Abgrenzung.

Gegenstand ist ausschließlich das Experiment von RIPE NCC und der Duke University am 27. August 2010. Es ist keine Darstellung späterer Route Leaks, späterer Hijacks oder jedes nachfolgenden BGP-Fehlers. Die spätere Route-Leak-Taxonomie aus RFC 7908 ist nützlich, um Kategorien zu unterscheiden, sie rechtfertigt jedoch nicht, dieses Experiment ohne Evidenz dafür, dass die spezifizierten Leak-Bedingungen vorlagen, als konventionellen Route Leak zu bezeichnen.[16]

Das Experiment erzeugte eine bewusst konstruierte Route, die ein neues optionales transitives Attribut trug. Ihre öffentliche Sichtbarkeit war beabsichtigt. Die daraus resultierende Instabilität war es nicht. Diese Kombination wirft drei Fragen auf, die nicht zu einer einzigen verschmolzen werden sollten:

War das auslösende BGP-UPDATE gültig?
Welche Komponente veränderte gültige Informationen in beschädigte Informationen?
Welche Kontrollen ließen zu, dass sich der daraus resultierende Fehler über einen eng begrenzten Test hinaus ausbreitete?

Die verfügbaren Aufzeichnungen beantworten die ersten beiden Fragen mit relativ hoher Sicherheit. RIPE NCC und Cisco bezeichneten das ursprüngliche Attribut beide als gültig beziehungsweise standardkonform, während Cisco eine IOS-XR-Schwachstelle identifizierte, die eine Beschädigung während der Propagierung umfasste.[1][2] NVD führt das Produktproblem als CVE-2010-3035.[3]

Die dritte Frage ist verteilt. Die Forscher kontrollierten nicht jeden eingesetzten Router. Cisco entschied nicht, dass RIS die experimentelle Route erzeugt. Einzelne Betreiber gestalteten weder das Experiment noch die betroffene Implementierung. Internet-Knoten-Verbindungen stellten durch ihre bloße Existenz keine Genehmigung jedes über sie transportierten Attributs dar. Die Zuschreibung muss deshalb den tatsächlichen Kontrollpunkten folgen.

Dieses Ereignis ist wichtig, weil es eine bequeme, aber unsichere Annahme bricht: dass Standardkonformität am Ursprung ausreicht, um die Betriebssicherheit in einem heterogenen Routingsystem zu gewährleisten. Konformität ist notwendig, aber das tatsächlich eingesetzte Verhalten entscheidet darüber, ob ein Paket oder UPDATE den Kontakt mit laufendem Code übersteht. Das Experiment bestand eine Art von Gültigkeitsgrenze und scheiterte an einer anderen.

RIS selbst existiert, um Routing-Informationen von mehreren Beobachtungspunkten zu sammeln und bereitzustellen.[7][8] RIPEstat und RIPE Database liefern identifizierenden Kontext für AS12654, aber ein Autonomous-System-Eintrag kann nicht jedes Softwareverhalten offenlegen, das auf einem Propagierungsweg angetroffen wird.[9][10] Route-Collector-Systeme wie RIS und Route Views sind gerade deshalb wertvoll, weil kein einzelner Registereintrag, keine Peer-Aussage und kein lokales Protokoll das gesamte Interdomain-Routingsystem beschreiben kann.[11]

Die Lektion ist nicht, dass Standards irrelevant sind. Sie ist, dass ein Standard das geforderte Verhalten beschreibt, während Rechenschaftspflicht Evidenz dafür verlangt, dass Implementierungen, Deployments und betriebliche Kontrollen dieses Verhalten unter realen Bedingungen hervorbringen.

2. Chronologie: von einer geplanten Ankündigung zu einer unbeabsichtigten Störung

Vor 08:41 UTC: Design und Prüfung vor der Ankündigung

Die Duke-Forschungsgruppe untersuchte ein Secure-Routing-Design, bei dem Zertifizierungsinformationen in einem optionalen transitiven BGP-Pfadattribut transportiert werden sollten. Duke stellte im Rahmen des Forschungsvorhabens eine modifizierte Quagga-Implementierung bereit. Die Prüfungen vor der Ankündigung ergaben, dass das Attribut eine akzeptable Protokollform hatte, und eine zweite Quagga-Instanz reproduzierte das später an betroffenen eingesetzten Geräten beobachtete Verhalten nicht.[1]

Dieses Ergebnis war informativ, aber unvollständig. Es zeigte, dass die auslösende Implementierung und eine ähnliche Empfangsumgebung das Attribut verarbeiten konnten. Es zeigte nicht, dass jede Router-Familie, jedes Software-Release oder jeder Weiterleitungspfad im öffentlichen Internet das Attribut korrekt erhalten würde.

Dies war die entscheidende Erkennungslücke. Der Testpfad prüfte die formale Struktur und ein begrenztes Implementierungsverhalten. Er reproduzierte nicht die heterogene installierte Basis, durch die ein transitives Attribut wandern konnte. Vor allem legte er keinen Fehler offen, bei dem ein Router ein gültiges unbekanntes Attribut annahm, es aber beim Weitersenden beschädigte.

Die öffentlichen Aufzeichnungen belegen weder den vollständigen Genehmigungsverlauf noch jedes erwogene Risiko oder jede vor dem Ereignis diskutierte Kontrolle. Es wäre deshalb unangemessen, einen undokumentierten Entscheidungsprozess zu erfinden. Feststellbar ist, dass die vor der Ankündigung eingesetzten Kontrollen die Wechselwirkung, die die öffentliche Störung hervorrief, nicht erkannten.

08:41 UTC: Die Route wird sichtbar

Am 27. August 2010 um 08:41 UTC begann RIS AS12654, 93.175.144.0/24 mit dem experimentellen optionalen transitiven Attribut anzukündigen. Die Ankündigung lief über die Verbindungen von RIPE NCC an AMS-IX und GN-IX.[1]

Dieser Moment war das auslösende Ereignis. „Auslöser“ ist jedoch nicht gleichbedeutend mit „Grundursache“. Ein Auslöser ist das Ereignis, das einen latenten Zustand aktiviert. Wenn eine gültige Eingabe auf eine fehlerhafte Implementierung trifft, startet die gültige Eingabe die beobachtete Sequenz, aber der Fehler erklärt, warum die Sequenz vom spezifizierten Verhalten abweicht.

Die öffentliche Sichtbarkeit der Route schuf zugleich die Governance-Exposition des Experiments. Ein Test in einem geschlossenen oder eng begrenzten System kann einen Fehler offenlegen, ohne dass er eine breite Menge autonomer Netze durchläuft. Sobald die Route in die gewöhnliche Interdomain-Propagierung eintrat, hing das Ergebnis von Software und Richtlinien außerhalb der direkten Kontrolle der auslösenden Parteien ab.

Während der Propagierung: gültige Informationen werden beschädigt

Betroffene IOS-XR-Systeme empfingen ein Attribut, das sie nicht erkannten. Nach dem optional-transitiven Design von BGP war die fehlende Erkennung für sich genommen kein Grund, das Attribut zu verwerfen. Das relevante Verhalten bestand darin, es zu erhalten und weiterzuleiten.

Die Darstellung von Cisco identifizierte einen Fehler in diesem Propagierungsweg: Betroffene Systeme beschädigten das ansonsten gültige Attribut, während sie es an einen Nachbarn sendeten.[2] Die verfügbare Evidenz rechtfertigt nicht, für jeden betroffenen Pfad die präzise Mutation auf Byte-Ebene zu erfinden. Der belastbare Befund ist funktional: Gültige unbekannte Informationen gelangten in eine betroffene Implementierung, und bei der Propagierung traten beschädigte Informationen aus.

Diese Unterscheidung verortet den Produktfehler genauer als die Aussage, der Router habe das experimentelle Merkmal lediglich „nicht unterstützt“. Optionale Transitivität existiert, damit ein Router ein Attribut transportieren kann, ohne dessen volle Semantik zu verstehen. Eine konforme Implementierung muss nicht auf die Zertifizierungsinformationen reagieren. Sie muss das Attribut aber korrekt erhalten, wenn sie es weiterleitet.

Die Beschädigung überschritt anschließend eine Implementierungsgrenze. Ein Downstream-Nachbar empfing ein UPDATE, das nicht mehr dem gültigen UPDATE entsprach, das das Experiment erzeugt hatte.

Downstream-Empfang: Ein UPDATE bedroht eine ganze Session

Nach den Fehlerbehandlungsregeln der damaligen Standardbasis konnte ein fehlerhaftes Pfadattribut einen UPDATE Message Error und die Schließung der BGP-Session auslösen.[12] Diese Reaktion war konstruktionsbedingt schwerwiegend: Ein Router, der Routing-Informationen nicht sicher interpretieren konnte, schützte sich, indem er die Session beendete.

Der betriebliche Nebeneffekt war breit. Eine BGP-Session trägt gewöhnlich viele Routen, nicht nur das experimentelle Präfix. Die Schließung der Session konnte deshalb nicht zusammenhängende gültige Routen zurückziehen, die von diesem Peer gelernt worden waren. Netze suchten dann nach Alternativen, tauschten neue UPDATEs aus und konvergierten neu.

Ein weiterer Wiederholungsmechanismus war möglich. Der Router, der das ausgehende Attribut beschädigte, identifizierte sich nicht notwendigerweise selbst als Quelle der Beschädigung. Nachdem sich eine benachbarte Session erholt hatte, konnte dieselbe Route erneut angekündigt werden. Dieselbe Beschädigung konnte erneut auftreten, das Downstream-System konnte erneut zurücksetzen und die Routing-Instabilität konnte sich erneuern.[2]

Die Fehlerkette war folglich größer als das experimentelle Präfix:

Ein gültiges, aber unbekanntes Attribut gelangte in einen betroffenen Router.
Der Router beschädigte es während der Weiterleitung.
Ein Nachbar empfing ein fehlerhaftes UPDATE.
Der Nachbar konnte die BGP-Session beenden.
Vom Experiment unabhängige Routen konnten aus dieser Nachbarschaft verschwinden.
Die Neu-Konvergenz erzeugte ein größeres Update-Volumen.
Eine erneute Ankündigung konnte die Sequenz wiederholen.

Deshalb wurde das Ereignis eher zu einem Test der Rechenschaftspflicht als zu einer reinen Interoperabilitätskuriosität. Jede Stufe wurde von einer anderen Komponente oder Organisation kontrolliert.

09:08 UTC: geplante Rücknahme

RIPE NCC zog die experimentelle Ankündigung wie geplant um 09:08 UTC zurück.[1] Die Route war damit etwa siebenundzwanzig Minuten lang erzeugt worden.

Die Rücknahme war notwendig, aber eine Rücknahme ist kein sofortiger Radiergummi. BGP ist verteilt. Bereits akzeptierte oder weitergeleitete Updates müssen weitere Sessions durchlaufen, während Router Pfade neu berechnen und Nachbarschaften wiederherstellen. Eine geplante Rücknahme kann die fortgesetzte Erzeugung am Ausgangspunkt stoppen, ohne sofort jede Kopie, jedes wartende Update, jeden Reset oder jeden bereits laufenden Neu-Konvergenzprozess abzubrechen.

RIPE beschrieb die unbeabsichtigte betriebliche Auswirkung als etwa dreißig Minuten dauernd. Der Großteil der Instabilität normalisierte sich etwa zwanzig Minuten nach dem Experiment, statt exakt in der Sekunde der Rücknahme zu enden.[1] Diese Beschreibungen sollten als gemessene betriebliche Intervalle behandelt und nicht in die Behauptung umgewandelt werden, jeder betroffene Pfad habe sich gleichzeitig erholt.

Nach der Rücknahme: Reaktion der Betreiber und Beweissicherung

Betreiber beobachteten das Geschehen und reagierten aus ihren eigenen Netzen. Zeitgenössische Mailinglisten-Diskussionen enthielten Berichte über Zugriffsprobleme, Routing-Änderungen und Effekte auf den Austauschverkehr.[4][6] Solche Kommentare sind nützliche Evidenz dafür, dass die Störung betrieblich sichtbar war, aber sie haben strenge Grenzen. Sie zählen nicht jedes betroffene autonome System auf, normalisieren Beobachtungen nicht über Standorte hinweg und liefern keine vollständige Zahl verlorenen Verkehrs.

RIPE NCC behielt Experimentdaten und übergab gesammelte Evidenz an Cisco. Diese Aufbewahrung war wichtig, weil das Ereignis organisatorische Grenzen überschritt. Ein Log auf der Ursprungsseite konnte allein zeigen, was RIS gesendet hatte, aber nicht notwendigerweise, was eine zwischengeschaltete Implementierung ausgab. Ein Herstellerbericht konnte allein einen Fehler erklären, aber nicht internetweite Beobachtungen quantifizieren. Eine glaubwürdige Rekonstruktion erforderte Evidenz aus mehr als einer Kontrolldomäne.

22:00 UTC: Die Sicherheitswarnung von Cisco

Cisco veröffentlichte seine IOS-XR-Sicherheitswarnung am 27. August 2010 um 22:00 UTC.[2] Das Problem wurde als CVE-2010-3035 erfasst, und Cisco bereitete Wartungs-Upgrades der Software vor.[3]

Die Warnung am selben Tag etablierte eine öffentliche Reaktion auf Produktebene. Sie bewies für sich genommen weder, welches Release bei jedem betroffenen Betreiber installiert war, wie viele Geräte der Route begegneten noch ob jeder Betreiber eine sofort nutzbare Abhilfe hatte. Dies bleibt in der begrenzten Aufzeichnung unbekannt.

31. August und danach: öffentliche Analyse und Governance-Reaktion

RIPE NCC veröffentlichte seine Vorfall- und Messanalyse am 31. August 2010.[1] Die Darstellung beschrieb das Experiment, die Implementierungs-Wechselwirkung, beobachtete Routing-Effekte, DNSMON-Befunde und geplante Änderungen für künftige kooperative Experimente.

RIPE NCC erklärte, künftige Experimente würden strenger behandelt, einschließlich umfassender Auswirkungsbewertung, ausreichender Vorabinformation für Betreiber und eines verantwortungsvollen Umgangs mit Schwachstellen.[1] Der Vorstand unterstützte später die fortgesetzte Experimentierpraxis und betonte zugleich geeignete Kommunikation.[5]

Diese Reaktion bestritt nicht den Wert der Forschung. Sie erkannte an, dass ein nützliches Forschungsziel die Notwendigkeit nicht beseitigt, die betriebliche Exposition zu begrenzen. Die Governance-Reparatur lautete daher nicht „mit Experimenten aufhören“. Sie bestand darin, die Befugnis zur Einleitung eines öffentlichen Experiments an klarere Risiko-, Ankündigungs-, Eindämmungs- und Reaktionskontrollen zu knüpfen.

3. Was ein optionales transitives Attribut ist – und warum „unbekannt“ nicht „ungültig“ bedeutete

BGP-Pfadattribute tragen Informationen, die mit einer Route verbunden sind. Einige sind wohlbekannt und werden von BGP-Implementierungen erwartungsgemäß verstanden. Andere sind optional. Eine getrennte Unterscheidung betrifft die Transitivität: ob ein Attribut über BGP-Speaker hinweg weiterlaufen soll, auch wenn eine zwischengeschaltete Implementierung seine Bedeutung nicht erkennt.

RFC 4271 definiert das relevante Verhalten. Ein nicht erkanntes optionales nicht-transitives Attribut muss nicht weitergeleitet werden. Ein nicht erkanntes optionales transitives Attribut ist anders. Es wird akzeptiert und an andere BGP-Peers weitergegeben, wobei das Partial-Bit anzeigt, dass ein zwischengeschaltetes System das Attribut nicht vollständig erkannt hat.[12]

Dieser Mechanismus unterstützt Erweiterungen. Ohne ihn müsste jedes autonome System entlang eines Pfades gleichzeitig Software-Unterstützung haben, bevor ein neues transitives Merkmal das Internet durchqueren könnte. Optionale Transitivität erlaubt inkrementelle Einführung: Ein Router kann Informationen transportieren, ohne sie zu interpretieren.

Das Design schafft eine strenge Implementierungspflicht. Ein Router, der ein optionales transitives Attribut nicht versteht, muss seine Repräsentation dennoch sicher behandeln. Praktisch gesprochen darf er gültige opake Informationen nicht in fehlerhafte Informationen verwandeln.

Vier Konzepte müssen getrennt bleiben:

Erkennung.Versteht der Router die Semantik des Attributs?

Annahme.Hat das Attribut eine Form, die der Router nach den Protokollregeln sicher empfangen kann?

Propagierung.Muss oder darf der Router das Attribut weiterleiten?

Mutation.Verändert der Router das Attribut, und falls ja, ist diese Veränderung erlaubt und korrekt kodiert?

Das Ereignis von 2010 verlangte von betroffenen IOS-XR-Systemen nicht, das Forschungs-Zertifizierungsschema zu verstehen. Der Fehler betraf die Propagierung. Die Darstellung von Cisco war, dass betroffene Systeme das gültige, nicht erkannte transitive Attribut beim Weitersenden beschädigten.[2]

Dies erklärt, warum eine zweite Quagga-Instanz nicht ausreichte, um den Vorfall vorherzusagen. Zwei Implementierungen können sich über die Form eines Attributs einig sein, während eine dritte einen Fehler in einem anderen Codepfad enthält. Empfangen, Speichern und Serialisieren eines unbekannten Attributs können getrennte Operationen umfassen. Das Bestehen einer Konformitätsprüfung am Eingang beweist kein korrektes Verhalten am Ausgang.

Das Ereignis zeigt außerdem den Unterschied zwischen syntaktischer Gültigkeit und betrieblicher End-to-End-Sicherheit. Das auslösende UPDATE konnte am Ursprung gültig sein. Ein zwischengeschaltetes System konnte dann eine ungültige Repräsentation erzeugen. Ein Downstream-System konnte gemäß den ihm verfügbaren Regeln korrekt reagieren und dennoch eine schädliche betriebliche Konsequenz erzeugen, indem es eine gesamte Session schloss.

Keine einzelne Ebene erklärt allein die Auswirkung:

Das Experiment lieferte die unbekannte Eingabe.
Das betroffene Produkt lieferte die Beschädigung.
Die Downstream-Fehlerantwort lieferte den Session-Verlust.
Die BGP-Neu-Konvergenz lieferte die Update-Verstärkung.
Die öffentliche Propagierung lieferte den Fehlerbereich.

Das ursprüngliche Attribut als fehlerhaft zu bezeichnen, würde den Produktfehler auslöschen, sofern Paket-Evidenz nicht das Gegenteil beweist. Das gesamte Ereignis nur als Produktfehler zu bezeichnen, würde die Entscheidung auslöschen, eine unsichere Wechselwirkung im Live-Internet zu testen. Es nur als harte Protokollreaktion zu bezeichnen, würde die Implementierung auslöschen, die das fehlerhafte Downstream-UPDATE erzeugte.

Die zutreffende Beschreibung ist ein verketteter Fehler mit unterschiedlichen Kontrollinhabern.

4. Von einem beschädigten UPDATE zu weitreichender Routing-Instabilität

BGP verteilt Erreichbarkeit zwischen autonomen Systemen. Wenn eine Peering-Session schließt, können Routen, die ausschließlich oder bevorzugt über diese Session gelernt wurden, aus der lokalen Routing-Tabelle zurückgezogen werden. Der Router kann Alternativen auswählen und diese Änderungen anderen Peers ankündigen. Diese Peers wiederholen dann ihre eigenen Auswahlprozesse.

Das bedeutet, dass ein Fehler, der an einer Route hängt, Änderungen für viele Routen erzeugen kann, wenn die Reaktion eine ganze Nachbarschaft entfernt. Das experimentelle Präfix musste nicht das Ziel sein, das betroffene Nutzer suchten. Ein Reset konnte andere Erreichbarkeit stören, die über dieselbe Session gelernt worden war.

Das Update-Volumen des Ereignisses ist mit diesem Verstärkungsmechanismus vereinbar. RIPE beobachtete Update-Raten bis zum Zwanzigfachen des umgebenden Ausgangsniveaus.[1] Das ist eine Control-Plane-Messung: Router tauschten wesentlich mehr Routing-Änderungen aus. Sie sagt nicht direkt, wie viel Anwendungsverkehr verloren ging, aber sie zeigt, dass die Störung über eine stille Ablehnung eines einzelnen Präfix hinausging.

Die Wiederherstellung von Sessions konnte außerdem Wiederholungen erzeugen. Wenn der vorgelagerte betroffene Router die Route behielt und seine fehlerhafte Propagierung bei Rückkehr der Session wiederholte, konnte der Nachbar erneut auf das fehlerhafte UPDATE treffen. Der resultierende Zyklus verband:

Session-Aufbau;
Routenankündigung;
Beschädigung während der Propagierung;
Empfang eines fehlerhaften UPDATE;
Session-Schließung;
Routenrücknahme und Neu-Konvergenz; und
erneuter Session-Aufbau.

Nicht jeder Peer oder Pfad durchlief notwendigerweise jeden Schritt. Die Evidenz stützt einen Mechanismus, der sich wiederholenkonnte, sowie Beobachtungen erhöhter Instabilität; sie liefert keine vollständige paketweise Aufzeichnung für jedes autonome System.

Diese Unterscheidung ist bei der Wirkungszuweisung wichtig. Ein Route-Collector sieht Ankündigungen und Rücknahmen an seinem Beobachtungspunkt. Er sieht nicht jede Weiterleitungsentscheidung, jede Nutzersitzung oder jedes verworfenes Paket. Unterschiedliche Collectors sehen unterschiedliche Ausschnitte des Routingsystems. Die besonders intensive Aktivität am Wiener Collector veranschaulicht, dass der Effekt ungleichmäßig war.[1]

Ungleichmäßigkeit ist kein Fehler der Messung. Sie ist eine Eigenschaft der Topologie und der Richtlinien des Internets. Autonome Systeme wählen Routen lokal. Sie haben unterschiedliche Peers, Software, Filter und Alternativen. Eine fehlerhafte Ankündigung kann einen Pfad passieren, auf einem anderen blockiert und auf einem dritten nie ausgewählt werden.

Der korrekte analytische Schritt besteht daher nicht darin, den Spitzenwert eines Collectors auf das gesamte Internet hochzurechnen. Er besteht darin, Collectors zu kombinieren, die Verteilung zu beschreiben und die Grenzen der Schlussfolgerung zu bewahren.

5. Begrenzte Auswirkungen: Was die Evidenz belegt

Die Messungen von RIPE liefern drei Hauptindikatoren.

Erstens erreichten die Routing-Update-Raten bis zum Zwanzigfachen des umgebenden Ausgangsniveaus.[1] Dies zeigt außergewöhnliche Control-Plane-Aktivität während des Ereignisfensters. Die Formulierung „bis zu“ ist wichtig: Sie beschreibt einen Spitzenwert, keine einheitliche Rate an jedem Collector oder für den gesamten Zeitraum.

Zweitens schätzte RIPE, dass zusätzliche 0,5 Prozent der Präfixe länger als normal vollständig unerreichbar wurden.[1] Dies ist ein Sichtbarkeitsmaß auf Präfixebene. Es sollte nicht in 0,5 Prozent der Nutzer, des Verkehrs, der Router oder der wirtschaftlichen Aktivität übersetzt werden. Präfixe unterscheiden sich stark in Größe, Nutzung und Verkehr, und Route-Collectors beobachten nicht jeden Weiterleitungspfad.

Drittens erreichte der Anteil instabiler Präfixe mit 1,4 Prozent einen Höchststand. RIPE verband diesen Höchstwert mit fast 4.500 Präfixen, etwa dem Neunfachen des üblichen Niveaus.[1] „Instabil“ ist nicht identisch mit „überall unerreichbar“. Ein Präfix kann wiederholte Pfadwechsel erfahren und von einigen Orten aus erreichbar bleiben.

Diese Befunde stützen die Schlussfolgerung, dass das Ereignis materielle, messbare und verteilte Routing-Instabilität verursachte. Sie stützen nicht die Behauptung, 1,4 Prozent des Internets seien vollständig offline gegangen.

Eine zeitgenössische Kurzformel, das Ereignis habe etwa ein Prozent des Internets betroffen, mag die Größenordnung einiger Messungen erfassen, ist jedoch weniger präzise als die getrennten Indikatoren von RIPE. Sie sollte diese nicht ersetzen. Die Evidenz unterscheidet zusätzliche vollständige Unerreichbarkeit, beobachtete Instabilität und Update-Volumen.

Geografische und kollektorspezifische Unterschiede

Die Effekte variierten nach Standort und Collector. Der Wiener Collector zeigte besonders hohe Update-Aktivität.[1] Variation kann Topologie, Peer-Auswahl, Exposition gegenüber betroffenen Implementierungen und die Verfügbarkeit alternativer Pfade widerspiegeln.

Der Standort eines Collectors ist keine direkte Karte der Nutzerauswirkungen in dieser Stadt oder diesem Land. BGP-Beobachtungspunkte empfangen Routen von teilnehmenden Peers. Ihre Sicht kann Pfade umfassen, die entfernte Netze bedienen, und lokale Nutzer können Pfaden folgen, die für den Collector nicht sichtbar sind. Die Collector-Evidenz ist stark für Routing-Verhalten und schwächer für die Zuweisung einer geografischen Zahl betroffener Menschen.

DNS-Beobachtungen

RIPE nutzte DNSMON, um zu prüfen, ob die Routing-Störung sichtbare DNS-Effekte erzeugte. Es wurde kein Ausfall des Root-Server-Systems festgestellt.[1] Dieser Negativbefund ist wichtig, weil breite Routing-Instabilität nicht automatisch den Ausfall jedes kritischen Dienstes bedeutet.

Die Analyse beobachtete begrenzten Abfrageverlust für einige überwachte Domains und deutlichere Schwierigkeiten an Teilen der autoritativen Infrastruktur von.si und.fr. Redundante Server antworteten weiterhin.[1] Die Evidenz stützt daher partielle und ungleichmäßige DNS-Effekte, keinen universellen DNS-Ausfall.

Die fortgesetzte Verfügbarkeit redundanter Server erinnert außerdem daran, dass Routing-Rechenschaftspflicht auch die Service-Architektur umfasst. Eine Routing-Störung kann einen autoritativen Serverpfad erreichen, während ein anderer erreichbar bleibt. Redundanz beseitigt den Routing-Fehler nicht, kann aber verhindern, dass ein Komponentenfehler zu einem vollständigen Service-Ausfall wird.

Betreiberberichte

Zeitgenössische Betriebsforen verzeichneten Berichte über Zugriffsstörungen, Routing-Reaktionen und Verkehrsänderungen.[4][6] Diese Berichte helfen zu belegen, dass der Vorfall außerhalb der auslösenden Institutionen sichtbar war. Sie können außerdem Fragen für weitere Untersuchungen identifizieren.

Sie sind kein Ersatz für normalisierte Messungen. Ein Verkehrsrückgang an einem Austauschpunkt oder bei einem Betreiber kann Umleitung, Verlust, vorsorgliche Richtlinienänderungen oder eine andere lokale Reaktion widerspiegeln. Ohne abgeglichene Ausgangswerte, Topologie- und Verkehrsaufzeichnungen lässt er sich nicht in eine Gesamtzahl der Internetauswirkungen umrechnen.

Behauptungen, die die Evidenz nicht stützt

Die begrenzte Aufzeichnung belegt nicht:

eine vollständige Liste der damals eingesetzten betroffenen IOS-XR-Release-Stände;
eine genaue Zahl betroffener Router oder Geräte;
jedes autonome System, das eine Session zurücksetzte;
eine genaue Zahl betroffener Nutzer;
gesamten verlorenen Anwendungsverkehr;
einen universellen Ausfall des experimentellen Präfix;
einen Ausfall der DNS-Root;
böswillige Absicht von RIPE NCC, Duke, Cisco oder Betreibern;
eine vollständige Darstellung jeder Genehmigung vor dem Ereignis;
dass jeder Betreiber vor dem Ereignis über eine verfügbare Abhilfe verfügte; oder
rechtliche Haftung.

Dies sind keine unbedeutenden Haftungsausschlüsse. Sie definieren den Unterschied zwischen evidenzbasierter Infrastrukturberichterstattung und einer Ausfallgeschichte, die auf unbelegter Multiplikation aufbaut.

6. Rechenschaftspflicht durch Zuweisung von Kontrolle

Rechenschaftspflicht ist am stärksten, wenn sie fragt, wer jede folgenreiche Entscheidung, Implementierung und Wiederherstellungsmaßnahme kontrollierte. Sie wird schwächer, wenn sie die Nähe zum ersten sichtbaren Ereignis als Beweis alleiniger Verantwortung behandelt.

Kontrollbereich	Was der Beteiligte kontrollierte	Was der Beteiligte nicht kontrollierte	Für eine stärkere Bewertung erforderliche Evidenz
RIPE NCC	Nutzung der RIS-Infrastruktur, internetweit sichtbare Erzeugung, Zeitplanung, Kommunikation, Überwachung, Rücknahme, Beweissicherung und künftige Experimentrichtlinie	Softwareverhalten auf jedem externen Router und die Wiederherstellung jedes Betreibers	Genehmigungsunterlagen, Risikobewertung, Ankündigungsplan, Überwachungsschwellen, Rücknahmekriterien und aufbewahrte Beobachtungen
Duke-Forscher	Forschungsdesign, Konstruktion des experimentellen Attributs, forschungsseitige Quagga-Änderungen und forschungsseitige Tests	Eingesetzter IOS-XR-Code, Downstream-Session-Richtlinien und Software-Rollout der Betreiber	Testvektoren, erzeugte UPDATE-Bytes, Aufzeichnungen zur Forschungsimplementierung und Umfang der Interoperabilitätstests
Cisco	IOS-XR-Parsing, Speicher- und Propagierungsverhalten; Produkttestabdeckung; Offenlegung; Wartungsfixes	Die Entscheidung, das Experiment zu starten, und die Installationspläne der Betreiber	Fehleranalyse, Matrix betroffener Versionen, Regressionsergebnisse, Evidenz für korrigierten Code und Bereitstellungsleitfaden
Netzbetreiber	Installierte Software, Wartung, Import- und Exportrichtlinien, Peer-Kontrollen, Filterung, Überwachung und Wiederherstellung innerhalb ihrer Netze	Experimentdesign, vorgelagerter Anbieter-Code und der vollständige globale Propagierungsweg	Geräteprotokolle, Paketmitschnitte, Konfigurationen, Softwareversionen, Session-Historie und Wiederherstellungsaufzeichnungen
Downstream-BGP-Implementierungen	Lokale Behandlung des fehlerhaften UPDATE gemäß den Regeln, die sie implementierten	Die Erzeugung des ursprünglichen gültigen Attributs oder die vorgelagerte Beschädigung	UPDATE-Fehlerprotokolle, Session-Benachrichtigungen und Beleg für eine engere Behandlung, sofern unterstützt
Internet-Knoten	Konnektivität, über die beteiligte Netze Routen austauschten	Standardmäßig nicht Inhalt und Korrektheit der BGP-Ankündigung jedes Teilnehmers	Evidenz für eine konkrete Route-Server-, Filter- oder Betriebsrolle, bevor mehr Kontrolle zugewiesen wird

Die Kontrolle von RIPE NCC

RIPE NCC kontrollierte den Akt, der die experimentelle Route in die öffentliche Propagierung einführte. RIS AS12654 war der für den Test verwendete Ursprung, und die Ankündigung lief über Verbindungen von RIPE NCC an AMS-IX und GN-IX.[1] RIPE NCC kontrollierte außerdem die geplante Rücknahme, die Beweissicherung und die künftigen Regeln für ähnliche kooperative Forschung.

Diese Kontrolle begründet Rechenschaftspflicht für die Experiment-Governance. Sie begründet nicht, dass RIPE NCC den Produktfehler verursachte. Das auslösende Attribut wurde als gültig beschrieben. Die relevante Frage für RIPE NCC ist nicht, ob es den genauen undokumentierten Fehler mit Sicherheit hätte vorhersagen sollen. Sie ist, ob die Unsicherheit des Experiments im Verhältnis zu seiner möglichen öffentlichen Reichweite bewertet, kommuniziert, überwacht und eingedämmt wurde.

Die spätere Verpflichtung zu umfassenderer Auswirkungsbewertung, Vorabinformation der Betreiber und verantwortungsvollem Umgang mit Schwachstellen zeigt, dass RIPE NCC selbst Governance-Verbesserungen identifizierte.[1] Die Unterstützung des Vorstands für fortgesetzte Experimentierpraxis mit angemessener Kommunikation unterstreicht die Unterscheidung zwischen der Legitimität von Forschung und der Angemessenheit ihrer betrieblichen Kontrollen.[5]

Die Kontrolle von Duke

Die Duke-Forscher kontrollierten das Secure-Routing-Forschungsdesign und stellten die in ihrem Rahmen verwendete Quagga-Modifikation bereit. Ihre Arbeit half, die gültige experimentelle Eingabe zu schaffen. Die verfügbaren Aufzeichnungen zeigen nicht, dass sie die interne Behandlung von IOS XR oder die Fehlerantwort der Downstream-Router kontrollierten.

Die forschungsseitige Rechenschaftspflicht betrifft die Designannahmen und die Breite der Interoperabilitätstests. Eine zweite Quagga-Instanz konnte Verhalten in einer ähnlichen Softwareumgebung zeigen. Sie konnte nicht Sicherheit über alle relevanten eingesetzten Implementierungen hinweg herstellen.

Die öffentliche Evidenz legt die vollständige Aufteilung der Entscheidungen vor dem Ereignis zwischen Duke und RIPE NCC nicht offen. Es wäre unangemessen, eine solche zu erfinden. Jede granularere Zuweisung würde Experimentpläne, Testaufzeichnungen und Kommunikation erfordern, die zeigen, wer die Bedingungen der öffentlichen Propagierung genehmigte.

Die Kontrolle von Cisco

Cisco kontrollierte die betroffene IOS-XR-Implementierung. Seine Sicherheitswarnung identifizierte die Beschädigung eines gültigen, nicht erkannten transitiven Attributs während der Propagierung.[2] Dieses Verhalten liegt im Produktkontrollbereich: Parsing, Speicherung, Serialisierung, Behandlung der Attribut-Flags und Regressionstests.

Cisco kontrollierte außerdem seine Offenlegung und Wartungsreaktion. Die Warnung erschien am Tag des Vorfalls, und Wartungs-Upgrades der Software wurden vorbereitet.[2] CVE-2010-3035 liefert den öffentlichen Schwachstellen-Identifikator.[3]

Die Produkt-Rechenschaftspflicht sollte dennoch evidenzbasiert bleiben. Die Aufzeichnung belegt weder jeden eingesetzten Release-Stand noch die Zahl betroffener Geräte oder ob der Fehler früher entdeckt worden war. Eine stärkere Bewertung würde versionsspezifische Tests, Fehlerhistorie und Installationsevidenz erfordern.

Die Kontrolle der Betreiber

Jeder Netzbetreiber kontrollierte einen lokalen Teil des Systems: Softwareauswahl und -installation, Wartungszeitpunkt, Peering-Richtlinien, Filter, Überwachung, Session-Schutz und Wiederherstellung. Diese Kontrollen konnten Exposition und Erholung beeinflussen.

Das macht Betreiber nicht dafür verantwortlich, einen unbekannten Fehler der Anbieter-Beschädigung vorherzusehen. Es zeigt auch nicht, dass jeder Betreiber vor dem Experiment einen verfügbaren Patch oder eine Konfigurations-Abhilfe hatte. Die Rechenschaftspflicht der Betreiber ist an das gebunden, was zum relevanten Zeitpunkt erkennbar und kontrollierbar war.

Nach der Offenlegung ändert sich die erforderliche Evidenz für fortlaufende Zusicherung. Betreiber können aufgefordert werden, betroffene Releases zu identifizieren, Fixes anzuwenden, Verhalten zu testen und Nachweise aufzubewahren. Vor der Offenlegung würden Behauptungen über unangemessene Untätigkeit Evidenz erfordern, dass ein Risiko und eine realisierbare Abhilfe bereits bekannt waren.

Warum Internet-Knoten keine erfundene Rolle zugewiesen werden sollte

Das Experiment nutzte Verbindungen an AMS-IX und GN-IX.[1] Diese Tatsache belegt einen Propagierungsweg. Sie belegt ohne zusätzliche Evidenz nicht, dass einer der Knoten das Experiment entwarf, das Attribut genehmigte, einen betroffenen Router betrieb oder die Exportrichtlinien der Teilnehmer kontrollierte.

Infrastrukturberichterstattung verwechselt oft physischen oder logischen Transit mit Entscheidungsbefugnis. Ein namentlich genannter Austauschpunkt kann Teil des Routenwegs sein, ohne der Akteur zu sein, der das UPDATE erzeugte, beschädigte oder akzeptierte. Rechenschaftspflicht sollte nicht allein aus der Topologie abgeleitet werden.

7. Produktreparatur und Reparatur der Experiment-Governance sind verschieden

Eine vollständige Reaktion erforderte zwei Reparaturstränge.

Produktreparatur

Der Produktfehler war die Beschädigung eines gültigen, nicht erkannten transitiven Attributs während der Propagierung durch betroffene IOS-XR-Systeme. Die direkte Reparatur gehörte in die Software und ihre Tests.

Eine glaubwürdige Produktreparatur würde zeigen, dass:

ein gültiges unbekanntes optionales transitives Attribut empfangen werden kann;
es ohne destruktive Mutation gespeichert wird;
es in der vom Protokoll geforderten Form weitergeleitet wird;
die relevanten Attribut-Flags und Längenfelder konsistent bleiben;
wiederholter Session-Aufbau keine Beschädigung neu erzeugt;
fehlerhafte Varianten gemäß dem unterstützten Fehlerbehandlungsverhalten eingedämmt werden;
Regressionstests sowohl Erkennung als auch opake Propagierungspfade abdecken; und
das korrigierte Release für Betreiber identifizierbar ist.

Die Sicherheitswarnung und die Wartungs-Upgrades von Cisco waren die unmittelbaren öffentlichen Maßnahmen zu dieser Ebene.[2] Eine Warnung kommuniziert den Fehler; ein Upgrade ändert die Implementierung. Beides hängt zusammen, ist aber nicht austauschbar.

Verifizierung erfordert außerdem Deployment-Evidenz. Ein Hersteller kann belegen, dass ein korrigierter Build Regressionstests besteht, während ein Betreiber belegen kann, welcher Build auf einem bestimmten Router läuft. Keine der beiden Aufzeichnungen belegt allein sowohl Produktkorrektur als auch Feldübernahme.

Reparatur der Experiment-Governance

Der Governance-Fehler bestand nicht darin, dass geforscht wurde. Er bestand darin, dass eine unsichere Wechselwirkung über die öffentliche Routing-Infrastruktur getestet wurde, ohne dass Kontrollen ausreichten, den beobachteten Explosionsradius zu verhindern oder rasch zu begrenzen.

Die Reaktion von RIPE NCC benannte strengere künftige Anforderungen: umfassende Auswirkungsbewertung, ausreichend Vorlauf für Betreiber und verantwortungsvoller Umgang mit Schwachstellen.[1] Diese adressieren Entscheidungen vor und während eines Experiments.

Eine glaubwürdige Governance-Reparatur würde umfassen:

ein klar begrenztes technisches Ziel;
die Identifizierung jedes zu erzeugenden Attributs und jeder zu erzeugenden Route;
eine dokumentierte Propagierungsgrenze oder eine Erklärung, warum breitere Propagierung erforderlich ist;
heterogene Implementierungstests, die dem Risiko angemessen sind;
Vorabkommunikation an betroffene Betreiber, sofern machbar;
ein definiertes Testfenster;
Echtzeit-Beobachtung durch Route-Collectors;
Data-Plane- oder Service-Sonden, wo relevant;
quantitative Abbruchkriterien;
eine autorisierte Person, die sofort zurückziehen kann;
ein geprobtes Rücknahmeverfahren;
Kriterien für die Kontaktaufnahme mit Herstellern;
aufbewahrte Daten vor und nach dem Ereignis; und
einen öffentlichen Vorfallbericht, wenn unbeabsichtigte externe Auswirkungen auftreten.

Governance-Kontrollen können nicht garantieren, dass ein unbekannter Fehler nie auftritt. Ihr Zweck ist, die Wahrscheinlichkeit zu verringern, dass eine Entdeckung unkontrollierte externe Folgen erzeugt, und die Zeit zwischen Erkennung und Eindämmung zu verkürzen.

Warum eine Reparatur die andere nicht ersetzen kann

Wenn Cisco IOS XR korrigierte, die Experiment-Kontrollen aber unverändert blieben, könnte ein späteres Experiment einen anderen unbekannten Fehler in einer anderen Implementierung exponieren. Das spezifische Produktrisiko würde sinken, das Entdeckungsrisiko bliebe.

Wenn RIPE NCC die Experiment-Kontrollen stärkte, die betroffene Software aber unkorrigiert bliebe, könnte gewöhnlicher Internetverkehr, der ein anderes gültiges unbekanntes transitives Attribut trägt, weiterhin auf den latenten Fehler treffen. Das Risiko öffentlicher Tests würde sinken, das Produktrisiko bliebe.

Das Ereignis verlangt daher zwei unabhängige Abschlussfragen:

Ist der Implementierungsfehler korrigiert und dort eingesetzt, wo er relevant ist?
Sind künftige Live-Experimente begrenzt, beobachtbar und so gesteuert, dass sie ihrer Unsicherheit entsprechen?

Ein Bericht, der nur eine beantwortet, hat keine vollständige Reparatur nachgewiesen.

8. Spätere Standards als analytischer Kontext – kein rückwirkendes Urteil

Nach August 2010 veröffentlichte Standards helfen, bessere Eindämmungs- und Richtlinienpraktiken zu beschreiben. Sie beweisen nicht, dass diese Praktiken während des Ereignisses eingesetzt wurden, und sie können spätere Empfehlungen nicht rückwirkend in einen Fahrlässigkeitsbefund verwandeln.

RFC 4271: die historische Ausgangsbasis

RFC 4271 beschreibt BGP-4 einschließlich optionaler transitiver Attribute und Fehlerbehandlung.[12] Seine Propagierungsregeln erklären, warum ein nicht erkanntes transitives Attribut weitertransportiert werden sollte. Seine UPDATE-Fehlerbehandlung hilft außerdem zu erklären, warum ein fehlerhaftes Attribut zur Session-Beendigung führen konnte.

Diese Kombination erzeugte eine gefährliche Wechselwirkung. Erweiterbarkeit hing von sicherer opaker Propagierung ab, während fehlerhafte Eingaben eine breite Reaktion aktivieren konnten. Wenn eine zwischengeschaltete Implementierung opake Informationen beschädigte, stand das Downstream-System vor einem Fehlerzustand mit Konsequenzen, die größer waren als die eine Route.

RFC 7606: Eingrenzung des Fehlerbereichs

RFC 7606 überarbeitete später die BGP-UPDATE-Fehlerbehandlung, weil ein Session-Reset große Mengen gültiger Routen verwerfen und erhebliche Routing-Störungen verursachen kann.[13] Er propagiert im Allgemeinen engere Reaktionen, einschließlich der Behandlung betroffener Routen als zurückgezogen in definierten Fällen, statt automatisch die gesamte Session zu zerstören.

Als analytischer Kontext angewandt zeigt dies, wie der Fehlerbereich verkleinert werden kann. Wenn eine fehlerhafte Ankündigung auf die betroffene Route begrenzt werden kann, während Session und nicht zusammenhängende Routen bestehen bleiben, hat ein beschädigtes Attribut weniger Macht, eine Nachbarschaft zu destabilisieren.

Es wäre unzutreffend zu sagen, RFC 7606 sei die Regel gewesen, die das Ereignis von 2010 bestimmte. Er wurde später veröffentlicht. Es wäre ebenso unzutreffend anzunehmen, jede heutige Implementierung wende jede Empfehlung einheitlich an. Das RFC erklärt eine architektonische Reparaturrichtung; Deployment-Evidenz ist weiterhin erforderlich.

RFC 7454 und RFC 8212: explizite externe Richtlinien

RFC 7454 sammelt betriebliche Sicherheitsempfehlungen für BGP, während RFC 8212 eine explizite Policy-Erwartung für externe BGP-Ankündigungen und -Annahme etabliert.[14][15] Zusammen verstärken sie ein grundlegendes Kontrollprinzip: Externe Routen sollten nicht allein deshalb ausgetauscht werden, weil eine Session existiert.

Explizite Import- und Exportrichtlinien können versehentliche Propagierung verringern und beabsichtigte Beziehungen prüfbar machen. In einem begrenzten Experiment könnte eine sorgfältig zugeschnittene Policy helfen zu begrenzen, welche Peers eine Testroute erhalten.

Diese Maßnahmen korrigieren nicht direkt einen Router, der ein Attribut beschädigt, das er weiterleiten muss. Sie wirken an der Policy-Grenze, nicht innerhalb des fehlerhaften Serialisierungspfads. Sie können die Exposition verringern, aber nur, wenn Route oder Session unterschieden und eingeschränkt werden können, ohne das legitime Ziel des Experiments zunichte zu machen.

RFC 7908: Taxonomie für Route Leaks

RFC 7908 beschreibt Typen von Route Leaks.[16] Es ist hier vor allem als Abgrenzung gegen lockere Terminologie nützlich. Das Ereignis von 2010 umfasste eine absichtlich erzeugte experimentelle Route und einen Implementierungsfehler, der ein optionales transitives Attribut betraf. Die verfügbare Evidenz sollte nicht gedehnt werden, um es ohne Übereinstimmung mit den Kategorienbedingungen in eine spätere Leak-Kategorie einzuordnen.

Taxonomie unterstützt Rechenschaftspflicht, wenn sie verhindert, dass nicht zusammenhängende Mechanismen verschmolzen werden. Sie untergräbt Rechenschaftspflicht, wenn ein vertrautes Etikett die Kausalanalyse ersetzt.

RPKI-Origin-Validierung

RFC 6480 beschreibt die Resource-Public-Key-Infrastructure-Architektur, und RFC 6811 definiert die BGP-Präfix-Origin-Validierung.[17][18] Die Origin-Validierung fragt, ob ein Ursprungs-Autonomous-System durch eine relevante Route Origin Authorization für ein Präfix autorisiert ist.

Diese Kontrolle adressiert eine andere Frage als die hier exponierte. Eine Route kann eine akzeptable Origin-Beziehung haben und zugleich ein Attribut tragen, das ein zwischengeschaltetes Produkt später beschädigt. Origin-Validierung beweist nicht, dass jedes Pfadattribut korrekt kodiert oder erhalten ist.

Keine Schlussfolgerung zum tatsächlichen RPKI-Zustand des Experiments ist notwendig. Der analytische Punkt ist begrenzt: Origin-Validierung allein würde den betroffenen ausgehenden Behandlungspfad nicht testen.

BGPsec

RFC 8205 spezifiziert die BGPsec-Pfadvalidierung.[19] BGPsec adressiert den kryptografischen Schutz von Pfadinformationen in einer definierten Architektur. Es hängt mit dem breiteren Ziel sicheren Routings zusammen, das die Duke-Gruppe untersuchte, ist aber keine Evidenz dafür, was während dieses Experiments von 2010 eingesetzt wurde.

Es sollte auch nicht als automatische Korrektur für jeden Implementierungsfehler präsentiert werden. Sicherheitsmechanismen sind selbst in Software implementiert. Sicheres Parsing, Serialisierung, Fehlereindämmung und Interoperabilitätstests bleiben notwendig.

NIST-Leitfaden zur Routing-Sicherheit

NIST SP 800-189 liefert spätere Leitlinien zur Sicherung des Interdomain-Verkehrsaustauschs, einschließlich Routing-Schutz und betrieblicher Praktiken.[20] Es ist nützlich, um heutige Erwartungen an Filterung, Überwachung, Validierung und Reaktion zu strukturieren.

Es begründet keine rechtliche Pflicht von 2010 und beweist nicht, was ein Beteiligter damals wusste. Seine angemessene Verwendung ist prospektiv: zu fragen, welche Evidenz ein Netz heute aufbewahren sollte und welche Kontrollen ähnliche Fehlerketten verringern können.

9. Kontrafaktische Überlegungen: Welche geänderte Tatsache hätte die Auswirkungen verringert?

Kontrafaktische Analyse ist nur nützlich, wenn jedes Szenario eine definierte Bedingung ändert und die übrige Evidenz unverändert lässt. Sie kann nicht beweisen, was sicher geschehen wäre, aber sie kann hochwertige Kontrollen identifizieren.

Kontrafaktische Überlegung 1: IOS XR erhält das Attribut korrekt

Eine Tatsache ändern: Betroffene IOS-XR-Systeme empfangen das gültige, nicht erkannte transitive Attribut und leiten es ohne Beschädigung weiter.

Das fehlerhafte Downstream-UPDATE entsteht auf diesem Produktpfad nicht. Der Session-Reset-Mechanismus, der dem beschädigten UPDATE zugeschrieben wird, wird durch diesen Fehler daher nicht aktiviert. Die Ankündigung bleibt ungewöhnlich und experimentell, aber die dokumentierte Fehlerkette ist an ihrem wesentlichen Implementierungspunkt unterbrochen.

Dies ist die stärkste produktbezogene Kontrafaktik, weil sie den identifizierten Beschädigungsmechanismus entfernt. Sie beweist nicht, dass keine andere Implementierung schlecht reagiert hätte.

Kontrafaktische Überlegung 2: Heterogene Tests reproduzieren das eingesetzte Verhalten

Eine Tatsache ändern: Vorabtests vor der Veröffentlichung umfassen eine hinreichend repräsentative betroffene Implementierung und lösen die ausgehende Beschädigung aus.

Der Fehler kann untersucht werden, bevor die Route in die breite öffentliche Propagierung eintritt. Cisco kann den Testfall erhalten, während RIPE NCC und Duke entscheiden können, das Experiment zu verschieben, einzuschränken oder neu zu gestalten.

Die Grenze ist Repräsentativität. Kein Labor kann jeden Internetpfad reproduzieren. Der Wert liegt darin, über zwei ähnliche Quagga-Endpunkte hinauszugehen und gezielt das opake Empfangs- und Propagierungsverhalten über unterschiedliche Implementierungen hinweg zu testen.

Kontrafaktische Überlegung 3: Das Experiment läuft in einer begrenzten Routing-Umgebung

Eine Tatsache ändern: Dasselbe Attribut und dieselbe betroffene Software interagieren in einer geschlossenen oder eng kontrollierten Testumgebung statt über die gewöhnliche öffentliche Propagierung.

Der Fehler kann weiterhin eine Session zurücksetzen, aber die Zahl der exponierten nicht zusammenhängenden Routen und externen Netze kann begrenzt werden. Evidenz kann an jedem Hop erfasst werden.

Die Grenze ist Realismus. Eine begrenzte Umgebung kann Topologie-, Policy- oder Softwarekombinationen des öffentlichen Internets nicht reproduzieren. Deshalb ist gestufte Eskalation vorzuziehen: zuerst mit begrenzter Vielfalt beginnen und nur dann verbreitern, wenn Risiko und Evidenz es rechtfertigen.

Kontrafaktische Überlegung 4: Downstream-Router nutzen eine engere UPDATE-Fehlerbehandlung

Eine Tatsache ändern: Ein Downstream-Router dämmt die fehlerhafte Ankündigung ein, ohne die gesamte BGP-Session zu schließen, wo eine engere Reaktion späteren Stils anwendbar ist.

Die experimentelle Route kann verworfen werden, aber nicht zusammenhängende gültige, über die Session gelernte Routen bleiben verfügbar. Update-Verstärkung und Neu-Konvergenzdruck sollten wesentlich geringer sein.

Diese Kontrafaktik spiegelt die Richtung wider, die später in RFC 7606 formalisiert wurde.[13] Sie muss analytisch bleiben, weil dieses RFC nach dem Ereignis datiert und die genaue Behandlung von der Fehlerklasse und der Implementierung abhängt.

Kontrafaktische Überlegung 5: Vorabinformation erreicht betroffene Betreiber

Eine Tatsache ändern: Betreiber erhalten ausreichende technische Informationen über Präfix, Attribut, Zeitfenster, erwartetes Verhalten und Abbruchbedingungen.

Einige Betreiber können relevante Sessions genauer überwachen, Personal vorbereiten, Exposition einschränken oder nach dem Auftreten von Anomalien rasch koordinieren. Die Diagnose kann sich beschleunigen, weil die Route als Experiment erkannt wird statt als unerklärtes Ereignis.

Information repariert IOS XR nicht. Sie kann außerdem einen sorgfältigen Umgang mit Schwachstellen erfordern, wenn erwartet wird, dass ein Test unsicheres Verhalten exponiert. Kommunikation ist daher eine Abhilfe- und Koordinationskontrolle, kein vollständiger Eindämmungsmechanismus.

Kontrafaktische Überlegung 6: Quantitative Abbruchkriterien lösen eine frühere Rücknahme aus

Eine Tatsache ändern: Die Überwachung identifiziert abnormale Update-Raten oder Session-Resets früh genug, um vor 09:08 UTC eine vordefinierte Abbruchschwelle zu überschreiten.

RIPE NCC zieht früher zurück. Die fortgesetzte Erzeugung endet früher und kann Wiederholungen und Expositionszeit verringern.

Die Grenze ist der verteilte Zustand von BGP. Bereits weitergeleitete Updates würden weiterhin Rücknahme und Neu-Konvergenz erfordern. Früheres Handeln kann die Dauer verringern, würde aber nicht sofort alle betroffenen Pfade wiederherstellen.

Kontrafaktische Überlegung 7: Richtlinien begrenzen die Propagierung auf ausgewählte Peers

Eine Tatsache ändern: Import- und Exportrichtlinien beschränken die experimentelle Route auf ausdrücklich teilnehmende Netze.

Der Fehlerbereich wird kleiner, und teilnehmende Betreiber können Evidenz erfassen. Dies passt zur späteren Betonung expliziter externer Policy.[14][15]

Die Grenze ist die Forschungsfrage. Wenn das Ziel die Beobachtung vielfältiger öffentlicher Implementierungen verlangt, ändert strikte Eindämmung, was gelernt werden kann. Dieser Zielkonflikt sollte explizit getroffen und nicht wegdefiniert werden.

Kontrafaktische Überlegung 8: Route-Collectors und Service-Sonden liefern unmittelbar korrelierte Alarme

Eine Tatsache ändern: Control-Plane-Beobachtungen, Session-Telemetrie und relevante Service-Sonden werden in Echtzeit korreliert.

Ermittler können eine harmlose neuartige Ankündigung früher von Update-Verstärkung, Präfix-Unsichtbarkeit und Service-Effekten unterscheiden. Die Rücknahmeentscheidung wird evidenzgetrieben.

Dies verhindert nicht die erste Beschädigung. Es verbessert die Erkennung und verkürzt das Intervall, in dem Unsicherheit fortbesteht.

Kontrafaktische Überlegung 9: Das Experiment findet nie statt

Eine Tatsache ändern: Es erfolgt keine öffentliche Ankündigung.

Der Auslöser vom 27. August entfällt, und dieses Ereignis legt den Fehler nicht offen. Der Produktfehler kann dennoch latent bleiben und später durch ein anderes gültiges unbekanntes Attribut aktiviert werden.

Diese Kontrafaktik verdeutlicht, warum „nicht experimentieren“ keine ausreichende Sicherheitsstrategie ist. Den Test zu vermeiden, vermeidet diesen Vorfall, korrigiert aber keine laufende Software. Das bessere Ziel ist sichere Entdeckung: begrenzte Experimente kombiniert mit Produktreparatur.

10. Wie eine überprüfbare Reparatur aussähe

Eine Reparaturbehauptung sollte an Artefakte und Beobachtungen gebunden sein statt an Zusicherungen.

Produkt-Evidenz

Für die betroffene Implementierung würde glaubwürdige Evidenz umfassen:

die genauen korrigierten Software-Release-Stände;
eine Herstellerbeschreibung des fehlerhaften Behandlungspfads in angemessener Detailliefe;
Regressionstests mit gültigen unbekannten optionalen transitiven Attributen;
Tests, die byte-erhaltende oder anderweitig konforme Propagierung zeigen;
Tests mit fehlerhaften oder absichtlich beschädigten Varianten;
Evidenz, dass unterstützte enge Fehlerbehandlung nicht zusammenhängende Routen erhält, wo anwendbar;
wiederholte Session-Zyklus-Tests zur Erkennung von Wiederholungen;
Betreiberaufzeichnungen, die installierte Releases identifizieren; und
Beobachtungen nach der Installation, die zeigen, dass der Fehler nicht mehr reproduziert wird.

Die öffentliche CVE und die Sicherheitswarnung identifizieren Problem und Reaktion.[2][3] Sie sind der Beginn der Überprüfbarkeit, nicht der gesamte Beweis der Feld-Abschluss.

Experiment-Evidenz

Für ein künftiges Live-Routing-Experiment würde glaubwürdige Evidenz umfassen:

das Test-Präfix und den Ursprung;
die vorgeschlagene Attributkodierung;
teilnehmende Peers und der beabsichtigte Propagierungsumfang;
Interoperabilitätsergebnisse über wesentlich unterschiedliche Implementierungen hinweg;
eine Auswirkungsbewertung, die Control-Plane- und Service-Konsequenzen abdeckt;
eine Aufzeichnung der Vorabinformation;
quantitative Abbruchschwellen;
eine unmittelbare Rücknahmebefugnis;
eine Rücknahmeprobe;
Live-Collector-Überwachung;
relevante Data-Plane- oder Service-Prüfungen;
Zeitstempel für Anomalien und Entscheidungen;
aufbewahrte UPDATE-Daten; und
einen Nachbericht, der erwartetes und beobachtetes Verhalten vergleicht.

RIS und Route Views veranschaulichen den Wert mehrerer Routing-Beobachtungspunkte.[7][11] Sie ersetzen keine Geräteprotokolle oder Paketmitschnitte, können aber unabhängig zeigen, ob eine Ankündigung propagiert wurde, ob Rücknahmen sich vervielfachten und ob Effekte je nach Sichtpunkt unterschiedlich waren.

Betreiber-Evidenz

Ein Betreiber, der behauptet, sein Netz sei geschützt, sollte zeigen können:

ob betroffene IOS-XR-Software vorhanden ist oder war;
welches korrigierende Release installiert ist;
wie die externe Routenrichtlinie definiert ist;
wie fehlerhafte UPDATEs von der aktuellen Software behandelt werden;
wie Session-Resets erkannt werden;
wie der Verlust nicht zusammenhängender Routen gemessen wird;
welche Peer-Schutzmaßnahmen aktiviert sind;
wie Wiederherstellungsentscheidungen dokumentiert werden; und
ob ein kontrollierter Regressionstest abgeschlossen wurde.

Dies ist betriebliche Kontinuität in konkreter Form. Eine Konfigurationsaussage ohne Evidenz der laufenden Version ist unvollständig. Eine Softwareversion ohne Policy- und Beobachtungsevidenz ist ebenfalls unvollständig.

Abschlusskriterien

Das Ereignis kann als technisch verstanden gelten, wenn ursprüngliche Bytes, zwischengeschaltete Mutation und Downstream-Antwort durch Evidenz verbunden sind. Das Produktproblem kann als behoben gelten, wenn korrigierte Software relevante Regressionstests besteht und das Deployment dort nachgewiesen ist, wo es erforderlich ist. Das Governance-Problem kann als behoben gelten, wenn ein künftiges Experiment nicht ohne dokumentierten Umfang, Ankündigung, Überwachung, Abbruchbefugnis und Aufbewahrung fortfahren kann.

Diese Abschlusskriterien sind absichtlich getrennt. Ein öffentlicher Vorfallbericht sollte angeben, welche erfüllt sind und welche unbekannt bleiben.

11. Evidenz, die die Schlussfolgerung ändern würde

Die aktuelle Schlussfolgerung ist evidenzabhängig. Mehrere Entdeckungen würden eine wesentliche Überarbeitung erfordern.

Paketaufzeichnungen, die zeigen, dass das auslösende Attribut fehlerhaft war

Wenn autoritative Mitschnitte belegten, dass RIS AS12654 ein Attribut erzeugte, das fehlerhaft war, bevor es ein betroffenes IOS-XR-System erreichte, müsste der Befund geändert werden, dass eine gültige Eingabe erst während der Propagierung beschädigt wurde.

Die Verantwortung würde sich in Richtung Erzeugung und Validierung vor der Ankündigung verschieben, obwohl jede zusätzliche Mutation oder Verstärkung weiterhin eine getrennte Analyse erfordern würde. Die zentrale Anforderung wäre ein End-to-End-Byte-Vergleich: was der Ursprung sendete, was jedes zwischengeschaltete System empfing und was es ausgab.

Geräteprotokolle, die einen anderen Beschädigungspunkt identifizieren

Wenn Protokolle oder Mitschnitte zeigten, dass eine andere Implementierung, ein Route-Server oder ein Vermittler die Beschädigung erzeugte, müsste die Produktzuschreibung überarbeitet werden. Eine Cisco-Warnung kann einen echten Fehler identifizieren, ohne zu beweisen, dass derselbe Fehler jeden beobachteten Pfad erklärt.

Das Ereignis kann mehr als einen Fehlermodus enthalten haben. Nur pfadspezifische Evidenz kann feststellen, ob alle Resets einen einzigen Beschädigungspunkt teilten.

Kollektordaten, die die Auswirkungsschätzungen wesentlich ändern

Wenn aufbewahrte Kollektordaten zeigten, dass Ausgangsniveau, Zahl betroffener Präfixe oder Dauer wesentlich anders waren, sollte die begrenzte Auswirkungsbewertung aktualisiert werden. Korrekturen könnten den gemessenen Umfang erhöhen oder verringern.

Eine Überarbeitung würde den Implementierungsmechanismus nicht automatisch ändern. Ursache und Größenordnung sind zusammenhängende, aber unabhängige Evidenzfragen.

Genehmigungs- und Risikounterlagen, die zusätzliche Kontrollen zeigen

Wenn vollständige Experimentunterlagen eine wesentliche Eindämmung, Benachrichtigung oder Abbruchkontrollen zeigten, die im öffentlichen Bericht nicht sichtbar sind, sollte die Governance-Bewertung diese anerkennen. Sie müsste dann erklären, warum diese Kontrollen die beobachtete Störung nicht verhinderten oder verkürzten.

Umgekehrt würden Unterlagen, die zeigen, dass identifizierte Hochrisikofolgen ohne Abhilfe akzeptiert wurden, die Governance-Kritik stärken. Der öffentliche Bericht allein belegt keines der beiden Szenarien.

Produktunterlagen, die eine frühere Identifizierung und wirksame Kontrolle belegen

Wenn Produkttestunterlagen belegten, dass der Fehler vor dem Experiment identifiziert und wirksam kontrolliert worden war, würden sich Zeitlinie und Verantwortungszuweisung ändern. Ermittler müssten fragen, ob den betroffenen eingesetzten Systemen eine verfügbare Korrektur fehlte, ob Betreiber eine anwendbare Benachrichtigung erhalten hatten und ob das beobachtete Verhalten aus einem anderen Mechanismus stammte.

Die aktuelle Aufzeichnung belegt eine solche frühere Identifizierung nicht.

Evidenz für breitere oder engere Serviceauswirkungen

Vollständige Verkehrsmessungen, Betreiberprotokolle oder Service-Telemetrie könnten die Bewertung nutzersichtbarer Konsequenzen verbessern. Sie könnten zeigen, dass die Control-Plane-Instabilität mehr Anwendungsstörungen verursachte als derzeit dokumentiert, oder dass Redundanz die meisten Dienste trotz Routing-Churn verfügbar hielt.

Solche Evidenz würde den Auswirkungsabschnitt ändern, würde aber nicht rechtfertigen, die Gültigkeit des ursprünglichen UPDATE ohne Beleg auf Paketebene umzuschreiben.

12. Eine zurückhaltende Schlussfolgerung

Das RIPE-Duke-Experiment von 2010 war kein konventioneller böswilliger Route-Hijack, und die verfügbare Evidenz stützt nicht, es als solchen darzustellen. Es war auch kein bloß harmloser Standardtest, der zufällig auf irrationale Router traf.

Es war ein Live-Routing-Experiment, bei dem ein gültiges, unbekanntes optionales transitives Attribut auf eine betroffene IOS-XR-Implementierung traf. Diese Implementierung beschädigte das Attribut bei der Weiterleitung. Ein Downstream-Router konnte dann auf das fehlerhafte UPDATE reagieren, indem er eine BGP-Session zurücksetzte, nicht zusammenhängende gültige Routen zurückzog und zu wiederholter Neu-Konvergenz beitrug. Die Messungen von RIPE erfassten eine begrenzte, aber materielle Störung: außergewöhnliche Update-Raten, zusätzliche Präfix-Unsichtbarkeit und einen Höchststand von fast 4.500 instabilen Präfixen.[1][2]

Das Ereignis legte zwei Fehler in unterschiedlichen Kontrolldomänen offen. Der eine war ein Produktfehler in der Behandlung gültiger opaker Routing-Informationen. Der andere war eine Schwäche der Experiment-Governance: Begrenzte Vorabtests und unzureichend eingegrenzte öffentliche Exposition ließen eine unbekannte Wechselwirkung zu einem Internet-Routing-Vorfall werden.

Die Sicherheitswarnung und die Wartungs-Upgrades von Cisco adressierten den Produktfehler. Die Untersuchung, Beweissicherung und strengeren künftigen Experimentverpflichtungen von RIPE NCC adressierten den Governance-Fehler. Spätere Standards lieferten bessere Fehlereindämmung und Richtlinienleitlinien, aber sie sind Kontext, kein rückwirkender Beweis.

Die dauerhafteste Lektion betrifft Kontrolle. Standardkonformität am Ursprung garantiert kein sicheres End-to-End-Verhalten. Ein Register oder Route-Collector kann identifizieren, wer ein Präfix ankündigte, und zeigen, wie sich die Sichtbarkeit änderte, aber er kann keine zwischengeschaltete Implementierung zwingen, ein Attribut korrekt zu erhalten. Hersteller müssen sicheren laufenden Code nachweisen. Experimentinitiatoren müssen unsichere öffentliche Tests begrenzen. Betreiber müssen ihre Software, Richtlinien und ihren Wiederherstellungszustand kennen.

Beobachtungssysteme müssen genug Evidenz bewahren, um Auslöser, Beschädigung, Verstärkung und Wirkung zu unterscheiden.

Rechenschaftspflicht entsteht nicht dadurch, die erste Organisation der Chronologie zu benennen. Sie entsteht dadurch, jede folgenreiche Kontrolle einem Eigentümer zuzuordnen und Evidenz zu verlangen, dass die entsprechende Reparatur funktioniert.