Zusammenfassung

  • RFC 9607 registriert audio/scip und video/scip, bildet sie auf SDP ab und verlangt, dass das Netz die variable Nutzlast ohne Transkodierung, Formfilter oder Änderung transparent weiterleitet.
  • SDP handelt die Nutzung von SCIP aus, nicht den inneren Codec oder Sicherheitszustand; RTP-Ankunft, Zusammenbau, Integritätsannahme, SCIP-Aushandlung, Peer-Identität und Wiedergabe bleiben getrennt.
  • Der RFC hält ausdrücklich fest, dass die IETF keine Sicherheitsprüfung von SCIP vorgenommen und die Sicherheitsbehauptungen des Dokuments nicht verifiziert hat.

Die unbekannte Nutzlast durfte diesmal unbekannt bleiben

Ein Session Border Controller hatte früher die ihm unbekannte scip-Zeile aus SDP entfernt. Der Rest der Signalisierung lief weiter, seine eigenen Prüfungen waren grün, doch die SCIP-Endgeräte konnten nicht arbeiten. Nach der Anpassung blieb die Zuordnung erhalten und RTP erreichte die Gegenseite.

Der Erfolg besteht nicht darin, dass der Controller SCIP gelernt hätte. Er lernte die Grenze seiner Zuständigkeit. Er kann den deklarierten Medientyp gemäß lokaler Richtlinie zulassen und die Bytes unverändert befördern, ohne das verschlüsselte Anwendungsprotokoll zu interpretieren.

Diese Quittung ist wichtig, aber begrenzt. Sie sagt nichts über die vollständige Wiederzusammensetzung, kompatible Versionen, abgeschlossene Schlüsselarbeit, den beabsichtigten Peer oder hörbare Sprache. Das Netz hat eine mögliche Sitzung nicht verhindert; die Endpunkte müssen sie weiterhin herstellen.

Die SDP-Zuordnung ist eine Sitzungskoordinate

Für audio/scip gilt eine 8000-Hz-Uhr, für video/scip 90000 Hz. m= benennt Audio oder Video, a=rtpmap bindet eine dynamische Nummer an scip und die Taktung. In Offer/Answer drückt die Reihenfolge eine Präferenz aus.

Eine dynamische Nummer besitzt außerhalb dieser Vereinbarung keine feste Bedeutung. Payload Type 96 kann in der nächsten Sitzung einen anderen Inhalt bezeichnen. Wer nur RTP speichert, aber Offer und Answer verwirft, verliert den Schlüssel zur Interpretation des äußeren Umschlags.

Auch eine vollständige SDP-Einigung bestimmt den inneren Codec nicht. SCIP führt seine eigene Fähigkeits- und Versionsaushandlung in Kontrollnachrichten. Äußere Bereitschaft, innerer Modus und sichere Sitzung sind drei Entscheidungen, nicht ein Statusfeld.

Inhaltskenntnis im Middlebox-Pfad wäre technische Verschuldung

SCIP-Verkehr ändert Größe, Abstand und Gestalt je nach Protokollzustand und eingeschlossenem Medium. RFC 9607 verbietet Transkodierung, verlustbehaftete Kompression, Änderung sowie Filterung nach heute beobachteter Struktur. Das Netz soll einen transparenten Klar-Kanal für verschlüsselte Daten bereitstellen.

Ein Hersteller kann aus aktuellen Mitschnitten scheinbar nützliche Erkennungsregeln gewinnen. Sobald diese Regeln in Firewalls, Verträge und Freigaben einziehen, wird jede legitime Weiterentwicklung abhängig von alten Geräten. Eine neue SCIP-Version sieht anders aus und wird gerade deshalb blockiert, weil sie nicht der vergangenen Chiffretext-Silhouette entspricht.

Opazität ist hier kein Mangel an Kontrolle. Das Netz behält Zugriffspolitik, Ressourcen-, Bandbreiten- und Überlastungsregeln. Es verzichtet nur auf eine semantische Behauptung, für die ihm die Beobachtung fehlt.

Ein MTU-gerechtes Datagramm schließt keine Nachricht

Die SCIP-Anwendung übergibt RTP Material unterhalb der MTU. Empfangsseitig identifiziert, ordnet und setzt die SCIP-RTP-Schicht Pakete zusammen. Bei Bedarf erkennt die Anwendung Fehler und veranlasst Wiederholungen.

Damit entstehen getrennte Nachweise: zulässige Sendelänge, Datagrammankunft, vollständige Sequenz, geschlossene Rekonstruktion, Integritätsannahme, rechtzeitige Wiederholung und Decoder-Ausgabe. Eine geringe mittlere Verlustrate kann ein fehlendes Fragment verbergen, das eine ganze Kontrollnachricht offen hält.

Auch umgekehrt darf ein zunächst abgewiesenes und danach erfolgreich wiederholtes Objekt nicht als dauerhafter Sitzungsfehler stehen bleiben. Telemetrie braucht Übergänge, Fristen und Objektbezüge statt nur Zählerstände.

Integrität schafft ein lokales Nein

Eine Änderung der SCIP-Nutzlast wird vom Endpunkt als Integritätsverletzung erkannt. Das kann Wiederholung auslösen und bei fortdauernder Störung die Kommunikation beenden. Die Empfangsseite behält damit die Autorität über akzeptierte Bytes; ein Zwischenknoten kann den Chiffretext nicht still verbessern.

Die Verletzung ist kein fertiger Ursachenbericht. Beschädigung, Zustandsversatz, Implementierungsfehler und Angriff bleiben zu unterscheiden. Sie belegt nicht den Erfolg der Wiederholung. Fehlende Alarme belegen weder Vollständigkeit noch richtige Peer-Identität oder verständliche Ausgabe.

Der Datensatz sollte Richtung, Objekt, RTP-Sequenzbereich, Prüfergebnis, Wiederholungsanforderung, Ersatzankunft und Anwendungsergebnis verbinden. Erst dann ist sichtbar, ob nur das Veto oder auch die Sitzung funktionierte.

Die innere Verschlüsselung umfasst nicht den ganzen RTP-Umschlag

SCIP verschlüsselt den in der RTP-Nutzlast transportierten Inhalt. RTP-Header und RTCP-Pakete sind dadurch nicht geschützt. Anwendungen können SRTP ergänzen, wenn diese Oberflächen Schutz verlangen; RFC 9607 macht diese Ergänzung nicht verpflichtend.

AVP, AVPF, SAVP und SAVPF sind deshalb eigenständige Entscheidungen. Verlustfeedback über AVPF oder SAVPF bleibt optional, weil SCIP bestimmte verlorene oder fehlerhafte Pakete selbst wiederholt. Innere Wiederholung und äußeres Feedback haben unterschiedliche Zustände und Zeitbudgets.

Das Wort „Secure“ im Namen darf fehlende Belege nicht erzeugen. Innere Vertraulichkeit, Header-Schutz, RTCP-Schutz, Quellenauthentizität und Peer-Autorisierung sind jeweils konkret nachzuweisen.

Der Standards-Track-Status ersetzt keine nicht erfolgte Prüfung

RFC 9607 sagt ausdrücklich, dass die IETF SCIP nicht sicherheitsgeprüft und die Aussagen des Dokuments nicht verifiziert hat. Standardisiert wurde die RTP/SDP-Nahtstelle samt Medienregistrierung, nicht das gesamte innere Sicherheitsprotokoll.

Diese Offenlegung ermöglicht präzise Konformität. Untertyp, Uhr, SDP-Abbildung, transparente Weiterleitung und Nichtveränderung lassen sich gegen den RFC testen. Schlüsselverwaltung, Peer-Authentisierung, Vertraulichkeit oder Angriffsresistenz brauchen andere Spezifikationen und Prüfungen.

Wer „RFC-9607-konform“ als vollständigen Sicherheitsnachweis beschafft, gibt einer dünnen Interoperabilitätsvereinbarung eine Autorität, die das Dokument selbst ablehnt. Jede erwartete Eigenschaft benötigt ihren ausführenden Eigentümer und ihre eigene Quittung.

Quellen