Zusammenfassung

  • RFC 2186, veröffentlicht im September 1997 von Wessels und Claffy als Informational RFC, beschreibt ICPv2 als leichtgewichtigen Austausch von URL-Existenzhinweisen zwischen benachbarten Caches. Der normale Objekttransfer folgt über HTTP.
  • Ein HIT unterstützt eine Auswahlentscheidung, ist aber kein Nachweis für Ursprung, Frische, Identität, vollständige Bytes, sichere Darstellung, beste Quelle, spätere Verfügbarkeit, Zustellung an eine Anwendung oder ein geschäftliches Ergebnis.
  • Die Aussagekraft von MISS, MISS_NOFETCH, DENIED, Echo, Source RTT und ausbleibenden UDP-Antworten unterscheidet sich deutlich. Diese Zustände dürfen weder technisch noch analytisch zusammengezogen werden.
  • HIT_OBJ ist eine ausdrücklich optionale und missbilligte Abkürzung: Sie kann ein Objekt in der ICP-Antwort mitführen, umgeht dabei HTTP-Autorisierung und Age Validation und vergrößert wegen der fehlenden Authentisierung von ICP-Antworten die Folgen von Spoofing.

Der Zweck liegt vor der Zustellung

Die entscheidende Funktion von ICPv2 liegt zeitlich vor dem eigentlichen Objektabruf. Ein Cache sendet eine Anfrage für eine exakt bezeichnete URL an einen oder mehrere Nachbarn. Deren Antworten können anschließend beeinflussen, welche Quelle für den Abruf gewählt wird. Damit stellt das Protokoll eine kleine Entscheidungshilfe bereit, nicht einen End-to-End-Nachweis.

Der Unterschied ist grundlegend. Ein HIT dokumentiert eine Antwort des Nachbarn auf eine konkrete ICP-Anfrage. Im normalen Ablauf wird das Objekt danach über HTTP beschafft. Zwischen diesen beiden Ereignissen können weitere Bedingungen relevant werden, die ICP weder prüft noch garantiert.

Deshalb darf ein HIT nicht stellvertretend für den gesamten späteren Ablauf stehen. Es sagt nicht, dass das Objekt bereits übertragen wurde. Es sagt nicht, dass ein nachfolgender HTTP-Abruf erfolgreich sein wird. Und es sagt nichts darüber aus, ob die Anwendung am Ende tatsächlich verwendbare Inhalte erhält.

Gerade für die Bewertung technischer Evidenz ist diese Trennung wesentlich. Das beobachtete ICP-Ereignis gehört zu einer bestimmten Beziehung zwischen anfragendem und antwortendem Cache. Ein späterer HTTP-Transfer ist ein anderes Ereignis mit einer anderen Provenienz. Anwendungserfolg oder geschäftliche Wirkung liegen nochmals weiter entfernt.

Das Format ist bewusst kompakt

ICPv2 verwendet einen 20 Oktette langen Header. Eine vollständige Nachricht darf höchstens 16.384 Oktette groß sein. Die Anfrage enthält die exakte URL, auf die sich die Entscheidung beziehen soll.

Die Request Number dient zur Zuordnung von Anfrage und Antwort. Sie ist opak; die Antwort übernimmt sie. Daraus entsteht keine zusätzliche Aussage über Identität oder Vertrauen. Ein gleichlautender oder zurückgesendeter Wert macht eine Antwort nicht stärker belegt, als es die übrigen Eigenschaften des Protokolls erlauben.

Auch die Adressfelder verlangen eine genaue Lesart. Die Sender Host Address ist gegenüber der vom Transport beobachteten Peer-Adresse nicht vertrauenswürdig. Ihr Zweck blieb mehrdeutig, und das Feld wurde praktisch nicht verwendet. Es ist deshalb keine belastbare Alternative zur Adresse der tatsächlich beobachteten Gegenstelle.

Die Requester Host Address der Anfrage ist davon getrennt. Sie kann vollständig aus Nullen bestehen. Ein solcher all-zero-Wert bedeutet, dass die Requester Host Address nicht angegeben wurde. Dieser Sonderwert gehört ausschließlich zu diesem Feld und darf nicht der Sender Host Address zugeschrieben werden.

Schweigen liefert keine Ursachenanalyse

Für ICP-Anfragen ist eine Wartezeit von typischerweise ein bis zwei Sekunden vorgesehen. Bleibt innerhalb dieses Fensters eine Antwort aus, entsteht zunächst nur eine operative Konsequenz: Der betreffende Nachbar wird für diese Auswahl im Moment nicht herangezogen.

Mehr lässt sich aus dem Schweigen allein nicht sicher ableiten. Es identifiziert weder einen bestimmten Fehlerzustand noch eine konkrete Ursache. Insbesondere ersetzt das Ausbleiben einer Antwort keine explizite MISS-, MISS_NOFETCH- oder DENIED-Antwort.

Damit entsteht eine wichtige Evidenzregel: Nicht beobachtete Antwort und beobachtete Negativantwort sind verschiedene Sachverhalte. Ein Monitoring-System, das beide zusammenfasst, verliert Information und kann anschließend Entscheidungen mit einer Genauigkeit begründen, die das ursprüngliche Ereignis nicht besitzt.

HIT ist ein Signal mit klarer Obergrenze

Ein HIT bedeutet, dass das angefragte Objekt beim antwortenden Cache als vorhanden und für die Verwendung zugelassen gemeldet wird. Das macht den Nachbarn für die nächste Auswahlentscheidung interessant.

Die Aussage endet jedoch dort. Ein HIT beweist nicht, woher das Objekt ursprünglich stammt. Er bestätigt weder dessen Frische noch die Identität einer Gegenstelle. Er garantiert nicht, dass ein späterer Transfer sämtliche Bytes liefert, und er beweist keine sichere Darstellung beim Empfänger.

Auch die Rangfolge möglicher Quellen ist nicht absolut in das HIT eingebaut. Ein HIT zeigt, dass ein Nachbar als Kandidat in Betracht kommt; es beweist nicht, dass er unter allen Kriterien die beste Quelle ist. Ebenso wenig garantiert das Signal, dass das Objekt bei einem späteren Abruf noch verfügbar sein wird.

Am Ende der Kette bleibt die Beweisgrenze ebenso deutlich: Ein HIT bestätigt nicht, dass eine Anwendung die Daten erhalten hat, und schon gar nicht, dass daraus ein bestimmtes geschäftliches Resultat entstanden ist.

HTTP-Cache-Semantik bleibt eine andere Schicht

Die Trennung von ICP und HTTP ist auch für Frische und Validierung entscheidend. HTTP verfügt über seine eigene Cache-Semantik. Aussagen über Alter, Frische oder Validierung eines HTTP-Objekts dürfen deshalb nicht allein aus einem ICP-HIT abgeleitet werden.

ICP beantwortet die kleinere Frage, ob ein Nachbar für die Auswahl relevant erscheint. HTTP behandelt den eigentlichen Abruf und seine eigenen Cache-Regeln. Wer beide Ebenen zusammenführt, macht aus einem Nachbarschaftshinweis eine Aussage über Objektzustände, die das ICP-Signal selbst nicht trägt.

MISS lässt Optionen offen

Ein MISS ist kein universelles Urteil, dass ein Cache für den Request wertlos sei. Der Cache meldet keinen HIT, kann aber dennoch eine Weiterleitung oder Beschaffung des fehlenden Objekts erlauben.

Damit enthält MISS mehr operative Offenheit, als eine binäre Einteilung in „brauchbar“ und „unbrauchbar“ vermuten lässt. Für die Quellenauswahl muss berücksichtigt werden, welche Rolle der betreffende Nachbar bei einem Miss übernehmen darf.

Diese Eigenschaft zeigt erneut, warum Antworttypen nicht auf bloße Erfolgs- oder Fehlercodes reduziert werden sollten. ICP kodiert unterschiedliche Verhaltensmöglichkeiten einer Cache-Beziehung.

MISS_NOFETCH beschreibt einen erreichbaren, aber begrenzten Nachbarn

MISS_NOFETCH bedeutet, dass der antwortende Cache verfügbar ist, für einen Miss aber kein Objekt beschafft. Der Zustand unterscheidet sich damit sowohl von Schweigen als auch von einem gewöhnlichen MISS.

Für den anfragenden Cache ist diese Information unmittelbar nützlich: Der Nachbar lebt und kann antworten, wird aber den fehlenden Inhalt nicht für diesen Request holen. Daraus lässt sich eine konkrete Auswahlentscheidung ableiten, ohne den Nachbarn als vollständig ausgefallen zu klassifizieren.

Gerade hier zeigt sich der Wert sauberer Ereignisprovenienz. Ein erreichbarer Cache mit eingeschränktem Fetch-Verhalten ist etwas anderes als ein Cache, von dem innerhalb des Auswahlfensters überhaupt keine Antwort eintrifft.

DENIED ist eine aktuelle Ablehnung, keine dauerhafte Diagnose

DENIED zeigt eine begrenzte Ablehnung der Anfrage. Auch dieses Signal sollte nicht zu einer dauerhaften Aussage über den Cache oder die gesamte Beziehung hochgestuft werden.

Ein hoher Anteil von DENIED-Antworten kann vielmehr auf eine Fehlkonfiguration hindeuten. Die Antwort ist damit nicht nur ein Auswahlhinweis, sondern möglicherweise auch ein Anlass für betriebliche Prüfung. Sie benennt jedoch nicht selbst die Ursache.

Die saubere Reaktion besteht daher darin, das Muster zu untersuchen. Aus vielen DENIED-Antworten folgt nicht automatisch eine bestimmte organisatorische oder sicherheitspolitische Erklärung.

Echo beantwortet nur eine kleinere Frage

ICP-Echo kann Erreichbarkeit prüfen. Das Ergebnis sagt jedoch nicht, dass die eigentliche Cache-Anwendung für einen nachfolgenden Objektabruf korrekt arbeitet.

Ein erreichbarer Protokollendpunkt und ein funktionierender Objektpfad sind zwei verschiedene Beobachtungen. Wer Echo als vollständigen Anwendungstest behandelt, erweitert seine Aussage über das, was tatsächlich geprüft wurde.

Das gilt besonders für Diagnoseketten: Ein erfolgreiches Echo kann eine mögliche Ursache ausschließen oder eingrenzen, ersetzt aber keinen Nachweis über den späteren Abruf und keine Aussage über die Anwendungsverarbeitung.

Source RTT ist Zusatzinformation, keine harte Voraussetzung

Source RTT kann als Information gespeichert sein, null sein oder fehlen. Seine Ermittlung darf die ICP-Antwort nicht verzögern.

Diese Bedingung begrenzt seine Rolle deutlich. Der Wert kann eine Auswahlentscheidung unterstützen, soll aber nicht den eigentlichen Antwortpfad blockieren. Ein fehlender oder null gesetzter Wert darf deshalb nicht automatisch als Beleg für schlechte Erreichbarkeit oder ungeeignete Leistung interpretiert werden.

Ebenso wenig macht ein vorhandener Source-RTT-Wert den späteren Objekttransfer vorhersehbar. Er bleibt ein Hilfssignal innerhalb einer engeren Entscheidungssituation.

HIT_OBJ verändert mehr als nur die Paketgröße

HIT_OBJ ist eine Sonderform, bei der ein Objekt direkt zusammen mit der ICP-Antwort transportiert werden kann. Dadurch entfällt für diesen Fall der sonst folgende HTTP-Abruf.

Diese Abkürzung verändert die Sicherheits- und Validierungsbedingungen. HIT_OBJ umgeht HTTP-Autorisierung, also die Prüfung, ob der Zugriff auf den Inhalt erlaubt ist, und umgeht außerdem die Age Validation. Diese beiden Punkte sind von der fehlenden Authentisierung der ICP-Antwort selbst zu unterscheiden.

ICP-Antworten sind nicht authentisiert. Das ist eine eigenständige Eigenschaft des Protokolls. HIT_OBJ hingegen verschiebt zusätzlich Funktionen, die beim normalen Weg über HTTP relevant wären.

Der Mechanismus kann außerdem MTU-bedingte Fragmentierung auslösen. Er ist deshalb discouraged und nur als Opt-in vorgesehen. Der Einsatz soll also nicht stillschweigend zum Standardpfad werden.

Kann ein Objekt nicht vollständig als HIT_OBJ geliefert werden, darf nicht der Eindruck einer vollständigen Objektübertragung entstehen. In diesem Fall wird auf einen regulären HIT zurückgefallen. Die Antwort sagt dann wieder nur, dass der Nachbar das Objekt als vorhanden meldet und für einen späteren Abruf in Betracht kommt.

Fehlende Authentisierung wirkt bereits vor dem Transfer

RFC 2187 macht deutlich, dass manipulierte ICP-Antworten die Auswahl selbst beeinflussen können. Ein gefälschtes HIT kann einen Cache in Richtung einer bestimmten Quelle lenken.

Die Gegenrichtung ist ebenso relevant. Gefälschte MISS_NOFETCH- oder DENIED-Antworten können dafür sorgen, dass eigentlich mögliche Nachbarn aus der Auswahl ausscheiden. Ein Angriff muss also nicht den späteren HTTP-Transfer übernehmen, um die Pfadentscheidung zu verändern.

Für Multicast ist die Beziehung enger gefasst: Antworten eines unbekannten Multicast-Nachbarn sollen ignoriert werden. Damit wird sichtbar, dass die bekannte Nachbarschaft ein Teil der Interpretation ist. Ein Paket, das technisch empfangen wurde, erhält nicht allein dadurch den Status eines gültigen Beziehungssignals.

Spoofing und HIT_OBJ verschieben das Risiko bis zum Inhalt

Die Kombination aus fehlender Authentisierung und HIT_OBJ ist besonders folgenreich. Solange ICP lediglich eine Quelle auswählt, beeinflusst eine gefälschte Antwort zunächst die Entscheidung darüber, wohin der anschließende Abruf geht.

Transportiert die ICP-Antwort über HIT_OBJ dagegen selbst den Inhalt, kann Spoofing zur Vergiftung des gelieferten Objekts führen. Aus einer manipulierten Auswahlinformation kann dadurch eine Manipulation des Inhalts werden.

Das erklärt, warum die optionale Abkürzung nicht nur nach Leistungsgesichtspunkten betrachtet werden darf. Sie verschiebt die Stelle, an der Vertrauen benötigt wird, und erhöht die Wirkung einer gefälschten Antwort.

Die Grenze des Beweises ist Teil des Protokolls

ICPv2 ist am nützlichsten, wenn seine Signale nicht über ihre vorgesehene Rolle hinaus aufgeladen werden. HIT, MISS, MISS_NOFETCH, DENIED, Echo, Source RTT und Schweigen geben jeweils unterschiedliche, begrenzte Hinweise.

Ein HIT kann eine Quelle für einen anschließenden Abruf attraktiver machen. Mehr folgt daraus nicht automatisch. Es beweist weder Ursprung noch Frische, Identität, vollständige Bytes, sichere Darstellung, beste Quelle, zukünftige Verfügbarkeit, erfolgreiche Zustellung an eine Anwendung oder ein Geschäftsergebnis.

Die Stärke von RFC 2186 liegt damit gerade in der schmalen Aufgabe des Protokolls. ICPv2 versucht nicht, die gesamte Lieferkette zu beglaubigen. Es liefert genügend Information für eine lokale Auswahlentscheidung und lässt andere Fragen den Protokoll- und Anwendungsebenen, auf denen sie tatsächlich beobachtet werden können.