Zusammenfassung

  • SAND Revision 04 verlangt BPSec-Integrität, überlässt dem werbenden Knoten aber die Auswahl von Nachrichtentypen und Instanzen nach Underlayer Network, Termination Point und BP-Ziel; Nachbarn können dadurch rechtmäßig nicht überlappende Sichten erhalten.
  • Erfolgreicher Empfang ist keine Nutzungsfreigabe. Der Empfänger autorisiert und verwirft lokal, während eine geschützte Router Advertisement noch keine Berechtigung zur Installation einer Route darstellt.
  • Ein belastbarer Vergleich braucht einen Projektionsbeleg, der Source, Security Source, Previous Node, Ziel, Schnittstellenkontext, Filterversion, Reference Time, Gültigkeit, Supersession und Empfängerentscheidung verbindet.

Authentifizierung reduziert eine wichtige Unsicherheit: Wer steht hinter einer geschützten Aussage? Sie beseitigt nicht alle anderen Unsicherheiten. Sie sagt nicht automatisch, ob die Aussage vollständig, für jeden Beobachter gleich, für Routing zugelassen oder im Datenpfad erfolgreich ist.

Genau diese Trennung wird bei Bundle Protocol Secure Advertisement and Neighborhood Discovery entscheidend. SAND soll BPv7-Knoten helfen, Nachbarn, Credentials, Underlayer Networks, Convergence Layers, Ressourcen, lokale Topologie, Routing-Bereitschaft und Endpoints zu entdecken. Das Protokoll verteilt jedoch keine universelle Masteransicht. Es transportiert lokal ausgewählte Aussagen an lokal entscheidende Empfänger.

Wer zwei Sichten vergleichen will, muss deshalb zuerst beweisen, dass ihre Entstehungsbedingungen vergleichbar waren.

Drei Identitätsrollen dürfen nicht verschwimmen

Ein SAND Bundle besitzt eine Source EID und als Ziel entweder die SAND Group EID oder eine andere SAND Singleton EID. Für Nachrichten an unmittelbare Nachbarn wird ein Hop Limit von eins verwendet. Doch ein kurzer Weg garantiert nicht, dass Ursprung und letzter Sender identisch sind.

Bei Weiterleitung verlangt Revision 04 eine positive Identifikation des Previous Node. Vorrang hat eine authentifizierte Identität der Convergence Layer. Fehlt sie, kann ein authentifizierter Previous Node Extension Block dienen. Für den ersten Hop kommt auch die authentifizierte Source Node ID infrage.

Jedes SAND Bundle muss einen Block Integrity Block für den Payload tragen. Die Security Source dieses BIB muss denselben Knoten bezeichnen wie die Bundle Source EID, kann aber aufgrund lokaler Identity Policy eine andere EID verwenden. Ein Previous Node Block wird separat geschützt; seine Security Source gehört zum vorherigen Knoten.

Damit existieren mindestens drei Rollen: der Urheber des Bundles, der Sender des letzten Hops und die kryptographische Identität für den jeweiligen Block. Eine Datenbank kann diese Rollen verbinden, darf aber die Originalwerte und die angewandte Verknüpfungsregel nicht löschen.

BPSec belegt Integrität und Zuordnung der geschützten Aussage. Es belegt nicht, dass der Absender sein gesamtes Wissen offengelegt hat.

Eine Anfrage besitzt keine Offenlegungshoheit

Data Solicitation signalisiert Interesse an bestimmten Daten. Sie darf laut Entwurf die lokale Policy des werbenden Knotens nicht überschreiben. Der Knoten entscheidet allein, welche Nachrichtentypen er sendet und welche Instanzen darin erscheinen.

Diese Auswahl kann banal sein: ein deaktivierter Termination Point, ein unverändertes Zertifikat, eine auf dieser Technologie nutzlose CL Instance. Sie kann zugleich eine Sicherheitsgrenze darstellen. Eine Gruppennachricht zeigt nur genug für den Kontaktaufbau; eine besser geschützte Singleton Destination erhält weitere Credentials oder Adressen.

Context-Specific Advertisement Filtering kann nach ULN, Termination Point, BP-Source oder BP-Destination unterscheiden. Ein Zertifikat aus einer privaten PKIX-Hierarchie erscheint nur dort, wo seine Trust Root relevant ist. IPv6-bezogene CL Instances können auf eine IPv6-Termination beschränkt bleiben. Mehrere Filter lassen sich kombinieren.

Der Entwurf beschreibt die Folge ausdrücklich als eine Art „split brain“: verschiedene Nachbarn beobachten verschiedene, möglicherweise vollständig nicht überlappende Datenmengen desselben Knotens. Dieser Satz ist keine Entschuldigung für willkürliche Falschangaben. Er ist eine Warnung, lokale Abwesenheit nicht als globale Nichtexistenz zu behandeln.

Auch Vertraulichkeit spricht für asymmetrische Sichten. Beim initialen Zero-Configuration Group Messaging ist der Payload ohne zusätzliche Verschlüsselung beobachtbar. Ein Hop Limit von eins verhindert keine Beobachtung durch Middleboxes. DNS-Namen, Adressen, Nachbarn, CL Instances oder Zertifikate gezielt auszublenden, kann daher eine korrekte Schutzmaßnahme sein.

Der Empfänger erzeugt seine eigene Projektion

Ein korrekt transportierter SAND Message muss nicht vollständig genutzt werden. Die Strukturen sind für Implementierungen interpretierbar zu machen; ihre Nutzung bleibt jedoch eine lokale Entscheidung.

Empfangsautorisierung kann von Message Type, Source, Destination, CL-Eigenschaften oder früher entdeckten Daten abhängen. Anschließend darf ein Knoten irrelevante Elemente cullen. Ein IP-only-System kann Non-IP-Parameter verwerfen. Eine derzeit nicht erreichbare Adresse kann aus der aktiven Darstellung verschwinden.

Solches Culling ist kein universelles Sachurteil. Eine Routingänderung kann die Adresse später erreichbar machen. Neue Software kann einen zuvor unbekannten Parameter verstehen. Ein zentrales Inventar muss deshalb unterscheiden, ob der Absender etwas verschwieg, der Empfänger es nicht autorisierte, die Implementierung es nicht unterstützte oder die lokale Lage es vorübergehend unbrauchbar machte.

Kontextbezogene Autorisierung verlangt außerdem die Verbindung des Messages zum ursprünglichen Bundle und zur lokalen CL Instance der Ankunft. Der Entwurf räumt ein, dass nicht jede BPA–Application-Schnittstelle diese Tiefe liefert. Dann kann eine konfigurierte Regel mangels Laufzeitbeleg nicht korrekt entscheiden.

Die gespeicherte Topologie ist somit mindestens eine Projektion zweiter Ordnung: Filter des Senders, danach Policy des Empfängers.

Gültige Signatur bedeutet nicht aktuelle Zuständigkeit

SAND Messages enthalten für einen Typ den vollständigen Datensatz des werbenden Knotens statt inkrementeller Änderungen. Dies macht Verarbeitung idempotent und toleriert erwartete Duplikate. Gleichzeitig braucht das System eine strikte Supersession-Regel.

Nach der Verarbeitung speichert der Empfänger Reference Time nach Bundle Source und Message Type; ersatzweise dient der Creation Timestamp. Vor der Verarbeitung eines weiteren Messages wird verglichen. Gleiche oder ältere Werte müssen ignoriert werden. Die Ordnung folgt DTN Time und Sequence Number. Ein ignorierter superseded Message gilt nicht als fehlerhaft.

Zwei Bundles können daher beide BPSec-valid sein, während nur eines den aktuellen Zustand verändern darf. Replay kann Ressourcen kosten, sollte aber keinen neueren Zustand zurückdrehen. Umgekehrt kann bei rein ereignisgesteuertem Senden eine alte Sicht bestehen bleiben, wenn der ersetzende Message verloren geht.

Validity Duration, Repetition Interval, periodische Timer und Change Trigger bestimmen gemeinsam, was Schweigen bedeutet. Der Zeitpunkt der Aufnahme in ein Data Warehouse ersetzt weder Reference Time noch Gültigkeit.

SYMMETRIC ist ein kleinerer Beleg als sein Name vermuten lässt

Local Topology Advertisement kann Nachbarn als HEARD, SYMMETRIC oder LOST beschreiben. HEARD bedeutet, dass eine Nachricht vom Peer einging, dieser Knoten sich aber noch nicht in dessen beworbener Topologie sah. SYMMETRIC bedeutet, dass der Peer diesen Knoten bewirbt und daher mindestens eine Nachricht in jede Richtung gelangte. LOST bedeutet, dass innerhalb eines implementierungsdefinierten Timeouts keine Nachricht eintraf.

Keiner dieser Zustände belegt dauerhafte Kapazität, Applikationserfolg oder Ende-zu-Ende-Lieferung. Routing Metrics zwischen gegenseitigen Nachbarn sind nicht synchronisiert. Selbst bei gleichen Metric-Typen werden identische Werte weder garantiert noch erwartet. Wie ein System sie zusammenführt, bleibt Implementierungssache.

Router Advertisement hat eine ähnlich begrenzte Autorität. Ein Knoten kann Willingness von null bis sechs und Attached-Network-Patterns ankündigen, bis hin zu *:** als Gateway-Muster. Der Entwurf warnt, dass nur ein passendes Stub Network eine solche Gateway-Anzeige sehen sollte.

Das Speichern einer Anzeige, ihre Autorisierung für Routing und die Installation einer Route sind getrennte Vorgänge. Ohne Autorisierung bleiben Route-Leak- und Hijacking-Risiken bestehen. Für BP Routing existiert laut Entwurf kein RPKI-Äquivalent. Eine authentifizierte Anzeige ist ein zurechenbarer Input, keine Routingvollmacht.

Ein Projektionsbeleg macht Unterschiede untersuchbar

Die operative Ergänzung ist ein Advertisement Projection Receipt. Dieses Belegmodell ist eine Governance-Empfehlung und kein von Revision 04 vorgeschriebenes Wire Format.

Der Beleg speichert Hash und Identität des geschützten Bundles, Source EID, BIB Security Source, Previous Node, Destination, Hop Limit, Creation Timestamp und Empfangszeit. Er hält fest, welcher Identity-Validation-Pfad verwendet wurde, und verknüpft die Aussage mit ULN, Termination Point und CL Instance.

Für jeden Message Type werden Instanzen, Reference Time, Validity Duration, Repetition Interval und Supersession-Ergebnis festgehalten. Wenn verfügbar, kommt die Filter- oder Configuration Epoch des Senders hinzu. Auf Empfängerseite werden Authorization und Culling samt Begründung sowie ein Hash der tatsächlich gespeicherten Projektion dokumentiert.

Eine Routingentscheidung erhält einen separaten Beleg. Forwarding und Application Outcome werden später beobachtet. Die Schichten zu trennen verhindert, dass ein einziges authenticated=true unbemerkt Vollständigkeit, Erlaubnis, Installation und Wirkung behauptet.

Mit zwei Belegen lässt sich eine Abweichung als beabsichtigter Scope, andere Policy Epoch, Staleness, Supersession, lokales Culling, fehlende Unterstützung, Verlust, Fehlkonfiguration oder ungeklärte Divergenz klassifizieren. Ohne Belege bleiben nur Screenshots und Vermutungen.

Der Dokumentstatus bleibt Teil der Grenze

Datatracker führt Revision 04 als aktiven Internet-Draft der DTN Working Group, veröffentlicht am 8. September 2026 und gültig bis 12. März 2027. Der Header nennt Standards Track; das Datatracker-Feld für intended RFC status war beim Freeze leer. Der Text ist kein RFC und keine endgültige Zuweisung.

Die Implementation-Status-Sektion nennt einen Proof of Concept. Dieselbe Sektion sagt, dass die Angaben von Mitwirkenden stammen, nicht verifiziert wurden, keinen Katalog bilden und keine IETF-Billigung darstellen. Dieser Artikel behauptet keine Adoption, Interoperabilität, Produktkonformität, reale Attacke, Route Leak oder Störung.

RFC 9171 liefert BPv7, RFC 9172 BPSec, RFC 8949 und RFC 8610 CBOR/CDDL. RFC 6130 bietet den Vergleich zur MANET-Nachbarerkennung. RFC 4593, RFC 7908 und RFC 6480 beschreiben Routingbedrohungen, Leaks und RPKI. Keiner dieser Texte erhebt eine SAND-Projektion zur globalen Karte.

Die belastbare Aussage ist enger: Authentifizierung ordnet eine kontextgebundene Aussage zu. Vollständigkeit, Routingautorität und Ergebnis brauchen weitere Evidenz.