メインコンテンツまでスキップ

RFC 6347 - 3. DTLS の概要 (Overview of DTLS)

3. Overview of DTLS​

DTLS の基本設計思想は「データグラムトランスポート上の TLS」を構築することである. TLS をデータグラム環境で直接使えない理由は, パケットが失われたり順序が入れ替わったりするからにほかならない. TLS はこの種の非信頼性を扱う内部機能を持たないため, データグラムトランスポートに載せ替えると実装が破綻する. DTLS の目的はこの問題を修正するために TLS に必要最小限の変更のみを加えることである. 可能な限り DTLS は TLS と同一である. 新機構が必要な場合でも TLS のスタイルを保つよう努める.

非信頼性は TLS に二つのレベルで問題を生む:

  1. TLS は個々のレコードを独立して復号できない. 完全性検査はシーケンス番号に依存するため, レコード N を受信できなければ, レコード N+1 の完全性検査は誤ったシーケンス番号に基づき失敗する (TLS 1.1 より前は明示的 IV もなく復号も失敗する).

  2. TLS ハンドシェイク層はハンドシェイクメッセージが信頼して配送されることを前提とし, 失われると破綻する.

本節の残りは DTLS がこれらを解決する手法を述べる.

3.1. Loss-Insensitive Messaging​

TLS のトラフィック暗号化層 (TLS レコード層) ではレコードは独立していない. 二種類のレコード間依存がある:

  1. 暗号コンテキスト (ストリーム暗号のキーストリーム) がレコード間で保持される.

  2. 反リプレイとメッセージの並べ替え保護はシーケンス番号を含む MAC によって提供されるが, シーケンス番号はレコード内では暗黙的である.

DTLS は第一の問題をストリーム暗号の禁止で解決する. 第二の問題は明示的シーケンス番号の追加で解決する.

3.2. Providing Reliability for Handshake​

TLS ハンドシェイクはロックステップの暗号ハンドシェイクである. メッセージは定義された順序で送受信されなければならず, それ以外はエラーである. これは順序入れ替えや損失と両立しない. さらに TLS ハンドシェイクメッセージは与えられたデータグラムより大きくなりうるため IP 分断の問題を生む. DTLS は両方に対処しなければならない.

3.2.1. Packet Loss​

DTLS はパケット損失に単純な再送タイマーを用いる. 下図はハンドシェイクの最初の段階で概念を示す.

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

                                X<-- HelloVerifyRequest
                                                 (lost)

        [Timer Expires]

        ClientHello           ------>
        (retransmit)

クライアントが ClientHello を送信すると, サーバからの HelloVerifyRequest を期待する. サーバのメッセージが失われた場合, ClientHello か HelloVerifyRequest のいずれかが失われたと判断し再送する. サーバが再送を受けると再送すべきと分かる.

サーバも再送タイマーを維持し, 期限で再送する.

タイムアウトと再送は HelloVerifyRequest には適用されない. サーバに状態を作る必要があるからである. HelloVerifyRequest は自身が分断されないほど小さく設計され, 複数の交錯を避ける.

3.2.2. Reordering​

DTLS では各ハンドシェイクメッセージにハンドシェイク内の特定のシーケンス番号が付与される. ピアがメッセージを受信すると, 次に期待するメッセージかすぐに判定できる. そうなら処理し, そうでなければ先行メッセージがすべて揃うまでキューに入れる.

3.2.3. Message Size​

TLS/DTLS のハンドシェイクメッセージは非常に大きくなりうる (理論上 2^24-1 バイト, 実務では数キロバイト). 一方 UDP データグラムは IP 分断を避けると多くの場合 1500 バイト未満に制限される. この制限を補うため, 各 DTLS ハンドシェイクメッセージは複数の DTLS レコードに分断でき, 各レコードは 1 つの IP データグラムに収める想定である. 各メッセージはフラグメントオフセットとフラグメント長を含む. すべてのバイトを揃えた受信者は元の未分断メッセージを再構成できる.

3.3. Replay Detection​

DTLS はレコードのリプレイ検出を任意でサポートする. 手法は IPsec AH/ESP と同じく, 受信レコードのビットマップウィンドウを維持する. ウィンドウに収まらない古いレコードと既に受信したレコードは黙って破棄する. パケット複製は常に悪意ではなく経路エラーによる場合もあるため任意である. アプリケーションは重複パケットを検出し送信戦略を変えうる.

に最終更新