Passa al contenuto principale

RFC 6347 - 3. Panoramica di DTLS (Overview of DTLS)

3. Overview of DTLS​

La filosofia di base è costruire "TLS su trasporto a datagramma". TLS non può essere usato direttamente perché i pacchetti possono perdersi o essere riordinati. TLS non ha strutture interne per questa inaffidabilità; le implementazioni si rompono su datagrammi. DTLS apporta solo le modifiche minime necessarie. Per quanto possibile DTLS è identico a TLS.

L'inaffidabilità crea due problemi a TLS:

  1. TLS non consente decifrazione indipendente dei singoli record: il controllo di integrità dipende dal numero di sequenza; se manca N, il controllo su N+1 usa il numero sbagliato e fallisce (prima di TLS 1.1 mancava anche l'IV esplicito).

  2. Il livello di handshake assume consegna affidabile dei messaggi.

Il resto della sezione descrive come DTLS risolve questi problemi.

3.1. Loss-Insensitive Messaging​

Nella TLS Record Layer i record non sono indipendenti: contesto crittografico (flusso di chiave di cifrario a flusso) tra record; anti-replay e riordino tramite MAC con numeri di sequenza impliciti.

DTLS vieta i cifrari a flusso e aggiunge numeri di sequenza espliciti.

3.2. Providing Reliability for Handshake​

L'handshake TLS è sincrono; qualsiasi altro ordine è errore. Incompatibile con perdita e riordino. I messaggi possono superare un datagramma (frammentazione IP). DTLS risolve entrambi.

3.2.1. Packet Loss​

DTLS usa un timer di ritrasmissione semplice. Esempio nella prima fase di handshake:

        Client                                   Server
        ------                                   ------
        ClientHello           ------>

                                X<-- HelloVerifyRequest
                                                 (lost)

        [Timer Expires]

        ClientHello           ------>
        (retransmit)

Dopo ClientHello il client si aspetta HelloVerifyRequest dal server. Se il messaggio del server si perde, il client ritrasmette. Il server mantiene un timer e ritrasmette. HelloVerifyRequest non usa timeout (creerebbe stato sul server) ed è progettato piccolo per non frammentarsi.

3.2.2. Reordering​

Ogni messaggio di handshake ha un numero di sequenza; se non è il prossimo atteso, viene accodato.

3.2.3. Message Size​

Messaggi grandi; UDP spesso <1500 byte. DTLS frammenta su più record con offset e lunghezza di frammento.

3.3. Replay Detection​

Opzionale, come IPsec AH/ESP con finestra a bitmap; record troppo vecchi o duplicati scartati silenziosamente.

Ultimo aggiornamento il