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

Appendix B. Performance of Multiple DTLS Handshakes (複数の D TLS ハンドシェイクのパフォーマンス)

Appendix B. Performance of Multiple DTLS Handshakes (複数の DTLS ハンドシェイクのパフォーマンス)​

インライン鍵管理を行うセキュリティプロトコル (TLS、DTLS、SSH など) の標準的な慣行は、各基盤となるネットワークチャネル (TCP 接続、UDP ホスト/ポート 4 タプルなど) に対して個別のセキュリティアソシエーションを作成することです。これには、シンプルさと各チャネルのセキュリティコンテキストの独立性という二重の利点があります。

RTP セキュリティのコンテキストでこの戦略のオーバーヘッドについて、3 つの懸念が提起されています:

B.1 公開鍵操作のオーバーヘッド​

最初の懸念は、各チャネルに対して個別の公開鍵操作を行うことによる追加のパフォーマンスオーバーヘッドです。ここでの従来の手順 (TLS および DTLS で使用される) は、新しいアソシエーションのための新しいトラフィック鍵を導出するために使用できるマスターコンテキストを確立することです。TLS/DTLS では、これは "セッション再開" (session resumption) と呼ばれ、ピア間で透過的にネゴシエートできます。

B.2 ネットワーク帯域幅のオーバーヘッド​

2 番目の懸念は、後続の接続の確立および既存の接続の再ハンドシェイク (再鍵交換用) のネットワーク帯域幅オーバーヘッドです。特に、チャネルが再ハンドシェイクによってオーバーフローされるメディアに完全に割り当てられた非常に狭い容量要件を持つという懸念があります。TLS での再ハンドシェイク (再開あり) のサイズの測定は、完全な暗号スイートの選択が提供される場合、約 300-400 バイトであることを示しています。(完全なハンドシェイクのサイズは、証明書と鍵マテリアルの交換のために約 1-2 キロバイト大きくなります。)

B.3 追加のラウンドトリップ​

3 番目の懸念は、2 番目、3 番目、... のチャネルの確立に関連する追加のラウンドトリップです。TLS/DTLS では、これらはすべて並行して実行できますが、セッション再開を利用するためには、最初のチャネルが確立された後に実行する必要があります。

2 つのチャネルの場合、これは次のようなラダー図を提供します (括弧内の数字はメディアチャネル番号です):

Alice                                   Bob
-------------------------------------------
                  <-       ClientHello (1)
ServerHello (1)    ->
Certificate (1)
ServerHelloDone (1)
                  <- ClientKeyExchange (1)
                      ChangeCipherSpec (1)
                              Finished (1)
ChangeCipherSpec (1)->
Finished         (1)->
                                            <--- チャネル 1 準備完了

                  <-       ClientHello (2)
ServerHello (2)    ->
ChangeCipherSpec(2)->
Finished(2)        ->
                  <-  ChangeCipherSpec (2)
                              Finished (2)
                                            <--- チャネル 2 準備完了

したがって、チャネル 1 が準備完了になった後、チャネル 2 が準備完了になるまでに追加の 1 RTT (往復時間) があります。ピアが再開を放棄することをいとわない場合、ハンドシェイクをインターリーブして、チャネルを同時に準備完了にすることができます。

に最終更新