Zusammenfassung

  • Revision 02 von draft-ietf-bfd-rfc5883-bis ersetzt das pauschale Verbot von BFD Echo über mehrere Hops durch eine Bedingung: Es bleibt bei möglicher Zwischenrücksendung verboten und ist nur zulässig, wenn die Umgebung diese verhindert.
  • Das Dokument ist weiterhin ein Internet-Draft der Arbeitsgruppe und kein verabschiedeter Ersatz für RFC 5883. Die neue HPE-Implementierungstabelle enthält ungeprüfte Angaben eines Beitragenden, keine Einsatz- oder Interoperabilitätsnachweise.

Ein Echo-Paket kann erfolgreich zurückkehren und dennoch die falsche Strecke geprüft haben. Sendet ein Router auf halbem Weg das Paket zum Ursprung zurück, sieht die Sitzung gesund aus, obwohl der Abschnitt dahinter nie erreicht wurde.

Aus diesem Grund untersagt RFC 5883 seit 2010 die BFD-Echo-Funktion über mehrere Hops vollständig. Revision 01 des möglichen Nachfolgers behielt diese Regel bei. Die am 19. August verfügbare Revision 02 macht sie vom Verhalten der Weiterleitungsumgebung abhängig.

Echo darf dem neuen Absatz zufolge nicht verwendet werden, wenn Kapselung oder Weiterleitung bewirken könnten, dass ein Zwischenknoten das Paket an den Absender zurückgibt. Es darf nur eingesetzt werden, wenn die Umgebung sicherstellt, dass dies nicht geschieht. Eine Kapselung als Source-Routing-Paket nennt der Entwurf als Beispiel, nicht als universelles Sicherheitsrezept.

Die Änderung ist damit keine allgemeine Freigabe. Die Anzahl der Hops ist nicht mehr das einzige Kriterium, doch der Betreiber muss eine stärkere Eigenschaft belegen: Die Antwort darf erst entstehen, nachdem das Paket den gesamten vorgesehenen Pfad durchlaufen hat.

Ein strukturierter Vergleich der offiziellen XML-Dateien zeigt, dass dieser Echo-Absatz die einzige normative Änderung im Haupttext zwischen Revision 01 und 02 ist. Hinzu kommt eine Implementierungsangabe von HPE neben einem bereits vorhandenen ZTE-Eintrag. Solche Angaben helfen bei der technischen Begutachtung, ersetzen aber keinen unabhängigen Versuch.

HPE bezeichnet eine proprietäre Junos OS BFD Implementation als Mature und meldet beliebige Pfade, Kapselung und Authentifizierung als implementiert. Out-of-Band-Signalisierung des Diskriminators und unidirektionale Links sind dagegen nur teilweise und ausschließlich für MPLS-LSPs umgesetzt. Implementierungserfahrung wird nicht angegeben.

Der Entwurf begrenzt die Aussagekraft selbst: Die IETF hat die von Beitragenden gelieferten Informationen nicht verifiziert, die Aufnahme ist keine Empfehlung und die Rubrik kein Produktkatalog. „Mature“ ist deshalb eine Selbstauskunft, keine Zertifizierung, Verbreitungsstatistik oder Interoperabilitätsaussage.

Schon Revision 01 enthielt einen ZTE-Bericht über unaffiliated BFD Echo. Er beschrieb Echo-Pakete in einem Segment Routing Header und erklärte, sie könnten so mehrere Hops durchlaufen, obwohl der normative Absatz den Einsatz damals ausnahmslos untersagte. Revision 02 führt nun eine umgebungsbezogene Bedingung ein; die Quellen sagen jedoch nicht, dass der ZTE-Bericht die Änderung ausgelöst hat.

Auch der Begleitentwurf für allgemeine BFD-Anwendungen wechselte am selben Tag zu Revision 02. Seine einzige substanzielle Ergänzung ist eine weitere HPE/Junos-Tabelle. Sie meldet breite Unterstützung, kennzeichnet OSPF Virtual Links aber als nicht implementiert und nennt keine Betriebserfahrung. Der Vergleich kann Inkonsistenzen zwischen allgemeinen und Multihop-Angaben sichtbar machen, beweist jedoch keine Kommunikation zwischen unabhängigen Produkten.

Die Datatracker-Seiten führen sowohl den Multihop-Entwurf als auch den allgemeinen Entwurf als aktive Internet-Drafts der BFD-Arbeitsgruppe mit IESG-Status I-D Exists. Sie würden RFC 5883 und RFC 5882 nur nach Genehmigung und Veröffentlichung ablösen.

Die übrigen Betriebsgrenzen bleiben bestehen. BFD ist ein Werkzeug für Betrieb, Administration und Wartung von Netzen, kein allgemeiner Anwendungstest über das Internet. Falsch dimensionierte Paketraten können Überlast und Fehlalarme erzeugen. Mit der Hop-Zahl wächst zudem die Angriffsfläche für Spoofing, weshalb starke kryptografische Authentifizierung wichtig bleibt.

Keine offizielle Quelle dieser Revisionen zeigt, dass die neue Echo-Bedingung in einem Produkt aktiviert, zwischen Herstellern getestet oder auf einem Produktionspfad vermessen wurde. Eine universell sichere Kapselung wird ebenfalls nicht definiert. Nötig ist nun ein Paketnachweis für den vollständigen Pfad, der auch bei Umleitungen, Ausfällen und Richtlinienänderungen Bestand hat.

Quellen