Zusammenfassung

  • RFC 3340 trennte Kennungen, die nur innerhalb eines BEEP-Kanals galten, von Kennungen in APEX-Servicedaten, die das Ablösen der anfragenden Anwendung überdauern konnten.
  • Eine zweite Anwendung am selben Endpunkt konnte die alte Antwort empfangen; Name und Transaktionskennung belegten eine Zuordnung, aber weder Arbeitsbesitz noch fortbestehenden Willen oder Handlungsbefugnis.

Die entscheidende Passage steht in Abschnitt 6.1.1. Eine Anwendung kann sich als Endpunkt an das APEX-Relay-Netz ankoppeln, Daten mit einer eingebetteten Transaktionskennung an einen Dienst senden und sich später wieder lösen. Danach koppelt sich eine zweite Anwendung als derselbe Endpunkt an und sendet eigene Anfragen. Schließlich kann diese zweite Anwendung die Dienstantwort auf die Anfrage der ersten erhalten, einschließlich deren Kennung.

Das muss kein Routingfehler sein. Das Relay erreicht den aktuell am Endpunkt hängenden Empfänger, und die Kennung weist richtig auf eine frühere Anfrage. Die Beweislücke entsteht zwischen beidem: Der jetzige Empfänger ist nicht notwendig der damalige Auftraggeber. Ein dauerhafter Name kann den Austausch des handelnden Subjekts verdecken.

Zwei Geltungsdauern

APEX nutzte BEEP. Im Endpunkt-Relay- und Relay-Relay-Modus waren Transaktionskennungen nur während der Lebensdauer eines BEEP-Kanals bedeutungsvoll. Wird die Verbindung freigegeben, gibt es den Kanal nicht mehr und die Anwendung ist nicht länger an das Relay-Netz angekoppelt. Die Kennung einer attach-Operation besaß keinen Anspruch auf ein späteres Verbindungsleben.

Bei APEX-Diensten steckte die Kennung dagegen in den übertragenen Daten. Dienstverarbeitung und Antwort konnten nach dem Ende der ursprünglichen Verbindung fortbestehen. RFC 3340 nannte solche Kennungen deshalb potenziell langlebig und empfahl Werte, die unvorhersehbar erscheinen, um Mehrdeutigkeit zu vermindern.

Unvorhersehbarkeit ist jedoch kein Eigentumsnachweis. Sie verringert Kollisionen und erschwert Raten, sagt aber nicht, welcher Prozess den Wert erzeugte, ob die Anfrage zurückgenommen wurde oder ob die Nachfolgerin offene Arbeit übernommen hat. Endpunktidentität, Verbindungsgeneration, anfragender Prozess und Antwortempfänger brauchen getrennte Belege.

Das frühe ok

Auch die Reihenfolge im Relay hat enge Grenzen. Zuerst prüft es, ob der BEEP-Client im Namen des angegebenen Ursprungs senden darf, und verarbeitet datenbezogene Optionen. Danach gibt es ok zurück. Erst anschließend folgen ursprungsbezogene Optionen und die einzelnen Empfänger.

Liegt ein Empfänger in einer anderen administrativen Domäne, gilt er als verarbeitet, nachdem eine Sitzung zum zuständigen Relay hergestellt, die neue Nachricht übertragen und dessen ok empfangen wurde. Bei einem lokalen Empfänger muss der Zugriff erlaubt, der Endpunkt angekoppelt und das ok der Anwendung nach deren eigener Verarbeitung eingegangen sein. Diese Quittungen bezeichnen unterschiedliche Stufen. Keine von ihnen beweist automatisch das Ergebnis für Nutzer oder Geschäftsvorgang.

Mit statusRequest konnten betroffene Relays später statusResponse-Nachrichten über den Report-Dienst schicken. targetHop=all zeichnete den Weg durch das Netz nach. Dadurch entstand zusätzliche Evidenz; die erste Annahmebestätigung wurde nicht nachträglich zur End-to-End-Garantie. Solche Daten konnten interne Topologie offenlegen, weshalb RFC 3342 eine Deaktivierung außerhalb administrativer Ein- und Austrittspunkte erwog.

Authentifizierter Name, wechselnde Anwendung

DNS SRV diente der Relay-Suche. RFC 3340 machte die Integrität des Relayings damit von DNS und seiner Nutzung durch Anwendungen abhängig und nannte die Authentifizierung des BEEP-Listeners als zusätzliche Sicherheit. Ein authentifizierter Peer konnte die Befugnis erhalten, sich als bestimmter Endpunkt anzukoppeln. Für Ende-zu-Ende-Authentizität sollte der Inhalt selbst signiert werden.

Jeder Beleg hat einen Umfang. Er kann den Listener, den Peer, die Berechtigung zur Namensnutzung oder unveränderte Bytes bestätigen. Er beweist nicht, dass die aktuelle Prozessgeneration die alte Anfrage gestellt hat. Eine gültig signierte Antwort kann echt sein und dennoch einer Generation zufallen, die keine Befugnis besitzt, sie auszuführen.

Ein belastbares Register speichert daher logischen Endpunkt, authentifizierten Peer, Kanal, Anbindungsgeneration, Workload-Identität, Kennung und Erzeugungsmethode, Anfragehash, dauerhafte Dienstquittung, Relay-Bestätigungen, Statusmeldungen, Ablösung, neue Ankopplung, Antworthash, Empfängergeneration, Annahme- oder Quarantäneentscheidung, Idempotenzzustand und beobachtetes Resultat. Gemeinsame Schlüssel verbinden diese Stücke; sie ersetzen keines davon.

Der Weg zu Historic

RFC 3340 erschien im Juli 2002 auf dem Standards Track. Mit RFC 3341 bis RFC 3343 bildete er eine Familie aus Kern, Zugriffsdienst, Optionen und Präsenzdienst. Der Datatracker verzeichnet am 29. Juli 2012 die Umstufung aller vier Dokumente auf Historic. Nach bestem Wissen der IETF seien keine Implementierungen eingesetzt worden; die APEX-Funktionalität werde inzwischen von dem weit verbreiteten XMPP erbracht, dokumentiert in RFC 6120 und RFC 6121.

Diese Erklärung belegt einen Adoptionserfolg und eine qualifizierte Nichtverbreitung. Sie nennt nicht die Ursache jeder Implementierungsentscheidung und schreibt das Ergebnis nicht den langlebigen Kennungen zu. Historic ist deshalb kein Beweis für einen Defekt oder Vorfall. Das Lebensdauerbeispiel bleibt gerade für heutige Queues, Callbacks und Serviceidentitäten relevant.

Eine verspätete Antwort kann vollständig richtig sein. Vor einer Aktion fehlt trotzdem die Quittung, die den alten Auftrag mit der neuen Generation verbindet. Die Kennung beantwortet, worauf die Nachricht reagiert. Sie beantwortet nicht, wer ihre Folgen jetzt tragen darf.

Quellen