Zusammenfassung

  • Die SCHC-Arbeitsgruppe hat am 29. September draft-ietf-schc-schclet-01 vorgelegt. Wo Fassung 00 in Abschnitt 6 lediglich „TBD“ schrieb, verweist die neue Fassung auf RFC 8724 und verlangt einen sicheren, durch die SCHClet-Konfiguration bestimmten Umgang mit Eingaben ohne passende unterstützte Rule.
  • Der modulare Ansatz, die Pflicht zur Angabe der unterstützten Konfiguration und die nur bedingte Interoperabilität standen bereits in Fassung 00. Das Dokument ist weiterhin ein Internet-Draft mit IESG-Status I-D Exists, kein verabschiedeter RFC und kein Nachweis laufender Geräte.

Bei knappen Ressourcen kann es sinnvoll sein, nur die benötigte Kompressions- oder Fragmentierungsfunktion von Static Context Header Compression einzubauen. Ein SCHClet ist nach dem Entwurf eine solche Teilfunktion innerhalb eines Stratum und einer SCHC Instance. Schon die Januarfassung verlangte, dass eine SCHClet-Spezifikation ihre Konfiguration festlegt. Ein vollständiges Gegenstück kann nur dann mit ihr zusammenarbeiten, wenn Konfiguration und Auslegung zueinander passen. Die neueste Fassung hat diese Architektur nicht erfunden.

Der nachweisbare Unterschied ist der ausgefüllte Sicherheitsabschnitt. Fassung 01 übernimmt ausdrücklich die Security Considerations aus RFC 8724 und weiteren verwendeten SCHC-Spezifikationen. Implementierende sollen Eingaben, die zu keiner unterstützten Rule passen, sicher behandeln. Als Beispiele nennt der Text Zurückweisen oder Durchreichen, jeweils so, wie es die SCHClet Configuration festlegt. Er schreibt nicht eine Maßnahme für alle Eingaben vor, legt keine Prüfsuite vor und berichtet nicht von produktiven Installationen.

Ein Teilsystem besitzt damit eine operative Grenze, die ein allgemeines Kompatibilitätsversprechen leicht verdeckt. Entscheidend sind die konkret unterstützten Rules, die Art der Eingabe, der Verarbeitungsschritt der Nichtübereinstimmung und die Konfiguration des Gegenübers. Zwei Implementierungen können sich auf SCHC berufen und trotzdem an genau dieser Grenze unterschiedliche Erwartungen haben. Die bedingte Interoperabilitätsaussage des Entwurfs ist keine Bescheinigung für beliebige Gerätepaare.

Auch das Wort „Durchreichen“ hat keine grenzenlose Bedeutung. RFC 8724 Abschnitt 12.1.1 behandelt ein gefälschtes SCHC-Paket mit nicht zugewiesener RuleID am Dekompressor und sieht dessen stilles Verwerfen vor. Eine Eingabe außerhalb der von einem begrenzten SCHClet unterstützten Rules kann eine andere Eingabeklasse an einer anderen Stelle sein. Aus der neuen Formulierung folgt weder eine Erlaubnis, jenes gefälschte Paket weiterzuleiten, noch bereits ein belegter Widerspruch zum RFC. Dafür müssten Paketart und Verarbeitungspfad genauer feststehen.

Die Governance-Neuigkeit ist folglich eine sichtbar gemachte Verantwortung, keine abgeschlossene Sicherheitslösung. Daniel Kade empfiehlt als redaktionellen Prüfmaßstab einen gemeinsamen Nachweis für unterstützte Rules, Eingabeklasse, Ablehnung oder Durchreichen, Peer-Konfiguration, Softwarestand und Testergebnis. Das ist keine vom IETF beschlossene Zusatzpflicht. Die Fassung ergänzt zudem normatives Schlüsselwort-Boilerplate und bereinigt Referenzen, fordert aber keine sofortige IANA-Maßnahme. Belege für einen Angriff, Ausfall, abgeschlossene WG-Prüfung oder eine Freigabe als Standard fehlen.

Quellen