Zusammenfassung
- RFC 3408 erlaubte im zuverlässigen Modus nur die Abbildung von R-0 auf ein Paket ohne Header und verlangte, dass eine Hilfsschicht die fehlende Typ- und Sequenzinformation bereitstellt.
- Sobald diese Rekonstruktion unsicher wurde, sperrte
SN_breakden Null-Byte-Pfad, bis eine bestätigte Aktualisierung jenseits der Bruchstelle lag.
Die Motivation war keine abstrakte Jagd nach maximaler Kompression. Manche ältere Funkschnittstellen arbeiteten mit festen Paketgrößen. Fügte man einer kleinen Sprachprobe den kleinsten ROHC-Header von einem Oktett hinzu, konnte die Übertragung in die nächste physische Größenklasse rutschen. RFC 3243 beschränkte den Anspruch deshalb auf Anwendungen, deren Verhalten zu solchen Links passte.
RFC 3242 hatte den headerfreien Betrieb für U- und O-Modus beschrieben. Dabei wurde die ausgelassene Information nicht als überflüssig behandelt. Eine Hilfsschicht musste dem Dekompressor mitteilen, ob ein Paket NHP oder ein gewöhnliches ROHC-Paket war, die vorausgesetzte Reihenfolge sichern und jeden relevanten Verlust melden. Die Bits verschwanden aus dem Datenpfad; ihre Beweisfunktion wanderte an eine Schichtgrenze.
RFC 3408 übertrug diese Konstruktion auf den R-Modus. Nur R-0 durfte durch NHP ersetzt werden. Der Empfänger bildete die RTP-Sequenznummer aus der letzten sicheren Referenz und einem Offset. Wie dieser Offset entstand, blieb absichtlich link-spezifisch und musste in der jeweiligen Implementierungsspezifikation festgelegt werden.
Ein Link konnte seit der letzten erfolgreichen Kontextaktualisierung alle nicht aktualisierenden Pakete und Verlustanzeigen zählen. Ein anderer konnte die RTP-Sequenz aus einer stabilen Beziehung zur Link-Zeit ableiten. Beide Verfahren zeigen denselben Grundsatz: Wird das Feld nicht übertragen, muss eine andere beobachtbare Quelle seinen Inhalt liefern.
Die Hilfsschicht konnte den Zustand für unsicher erklären, obwohl der Kompressor NHP grundsätzlich noch zuließ. Sie speicherte dann die betroffene Sequenz als SN_break und stellte auf Pakete mit Header zurück. Erst wenn die gewöhnliche Sicherheitsbedingung wieder erfüllt war und SN_ACKed die Bruchstelle überschritten hatte, durfte sie NHP erneut verwenden. Eine alte Bestätigung galt nicht für einen neuen Unsicherheitszeitraum.
Passives Warten auf das nächste Kontextupdate konnte lange dauern. Darum empfahl RFC 3408 eine optionale Schnittstelle für update_request. Die Hilfsschicht konnte den Kompressor bitten, das nächste Paket als Kontextaktualisierung zu senden. Ging die Bitte zwischen getrennten Komponenten verloren, verzögerte sich die Rückkehr zur Effizienz. Die sichere Referenz wurde dadurch weder geändert noch ersetzt.
R-Modus hielt die Zustandsgrenze sauber. NHP und Verlustanzeigen aktualisierten weder Kompressor- noch Dekompressorkontext. R-0 trug ohnehin keine CRC, sodass keine entfernte Prüffunktion wie bei U/O ersetzt werden musste. R-0-CRC beim Umlauf der sechs Bit langen Sequenz sorgte bereits regelmäßig für Kontextprüfung.
Selbst der Feedback-Pfad konnte die Optimierung ausschalten. Eingestreute Feedbackpakete unterbrachen die RTP-Sequenz und deaktivierten NHP vorübergehend; deshalb wurden sie für ACKs nicht empfohlen. Falsche Context Check Packets mit zufälliger CRC konnten außerdem scheinbare Prüfungsfehler, Kontextinvalidierung, Feedback und Refresh auslösen. Der Angreifer musste keine Sprache fälschen, um den Effizienzgewinn zu zerstören.
Spätere ROHC-Frameworks, ROHCv2 und Dokumente zu umordnenden Kanälen erweiterten die Architektur. Das IANA-Register bewahrt die Profilkennungen. Keine dieser Quellen belegt jedoch eine konkrete Einführung oder Dienstgüte. RFC 3408 ist historisch wichtig, weil es die unsichtbare Rechnung des fehlenden Bytes offenlegte: Weniger Übertragung bedeutete mehr ausdrücklich zugewiesene Verantwortung.
Sources
- https://www.rfc-editor.org/rfc/rfc3408.html
- https://www.rfc-editor.org/rfc/rfc3408.txt
- https://www.rfc-editor.org/info/rfc3408/
- https://datatracker.ietf.org/doc/rfc3408/
- https://datatracker.ietf.org/doc/rfc3408/history/
- https://datatracker.ietf.org/doc/rfc3408/references/
- https://www.rfc-editor.org/errata_search.php?rfc=3408
- https://www.rfc-editor.org/rfc/rfc3242.html
- https://www.rfc-editor.org/rfc/rfc3243.html
- https://www.rfc-editor.org/rfc/rfc3095.html
- https://www.rfc-editor.org/rfc/rfc4995.html
- https://www.rfc-editor.org/rfc/rfc5795.html
- https://www.rfc-editor.org/rfc/rfc5225.html
- https://www.rfc-editor.org/rfc/rfc4224.html
- https://www.rfc-editor.org/rfc/rfc3759.html
- https://www.rfc-editor.org/rfc/rfc2508.html
- https://www.rfc-editor.org/rfc/rfc1144.html
- https://www.iana.org/assignments/rohc-pro-ids/rohc-pro-ids.xhtml
- https://heng.lu/running-code-primary-the-patch-needed-to-preserve-the-internet-original-design/
- https://heng.lu/minimum-initial-specification-localized-future-decision-voluntary-adoption-internet-coordination-system/
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
