12. Considerazioni di sicurezza

I pacchetti RTP che usano il formato di payload definito in questa specifica sono soggetti alle considerazioni generali di sicurezza discusse in RTP [3], sezione 9.

Negli scenari comuni di streaming sono desiderati l'autenticazione dei messaggi, l'integrità dei dati, la protezione da replay e la riservatezza.

L'assenza di autenticazione può consentire attacchi man-in-the-middle e replay, che possono essere molto dannosi per la ritrasmissione RTP. Ad esempio: pacchetti RTCP manomessi possono innescare ritrasmissioni inappropriate che riducono effettivamente la quota di bitrate allocata al flusso dati originale; pacchetti RTP di ritrasmissione manomessi potrebbero far crashare il decoder del client; richieste di ritrasmissione manomesse possono invalidare il meccanismo di associazione SSRC descritto nella sezione 5 di questo documento. D'altra parte, pacchetti ripetuti potrebbero portare a falsi riordini e misurazioni RTT (necessarie per la strategia di richiesta di ritrasmissione) e possono far traboccare il buffer del ricevente.

Inoltre, per garantire la riservatezza dei dati, il payload originale deve essere crittografato. In realtà non c'è bisogno di crittografare i 2 ottetti dell'intestazione di payload per la ritrasmissione poiché non forniscono indizi sul contenuto dei dati.

Inoltre, è RECOMMENDED che i meccanismi crittografici usati per questo formato di payload forniscano protezione contro attacchi a testo noto. RTP raccomanda che il timestamp RTP iniziale SHOULD essere casuale per proteggere il flusso da attacchi a testo noto. Questo formato di payload non segue questa raccomandazione poiché il timestamp iniziale sarà il timestamp del media del primo pacchetto ritrasmesso. Tuttavia, poiché il timestamp iniziale del flusso originale è esso stesso casuale, se il flusso originale è crittografato, il timestamp del primo pacchetto ritrasmesso sarebbe casuale anche per un attaccante. Pertanto, la riservatezza non sarebbe compromessa.

Se la crittografia è usata per fornire servizi di sicurezza sul flusso originale, gli stessi servizi, con forza crittografica equivalente, MUST essere forniti sul flusso di ritrasmissione. L'uso della stessa chiave per il flusso ritrasmesso e quello originale può portare a problemi di sicurezza, ad esempio two-time pads. Si rimanda alla sezione 9.1 del Secure Real-Time Transport Protocol (SRTP) [12] per una discussione delle implicazioni dei two-time pads e su come evitarli.

Al momento della stesura di questo documento, SRTP non fornisce tutti i servizi di sicurezza menzionati. Vi sono almeno due motivi: 1) la comparsa di two-time pads e 2) il fatto che questo formato di payload opera tipicamente sotto il profilo RTP/AVPF mentre SRTP supporta solo RTP/AVP. Una variante adattata di SRTP dovrebbe risolvere queste carenze in futuro.

Le considerazioni sul controllo della congestione con l'uso della ritrasmissione sono trattate nella sezione 7 di questo documento.