Network Working Group M. Tuexen INTERNET DRAFT Siemens AG A. Jungmaier University of Essen Expires December 22, 2001 June 22, 2001 SCTP上のTLS このメモの位置付け このドキュメントはインターネットドラフトであり、[RFC2026]の第10章に記載 されているすべての条項に従う。 インターネットドラフトは、Internet Engineering Task Force(IETF)とその エリア、そしてそのワーキンググループにおいて作成中のドキュメントのこと である。その他のグループが、作成中のドキュメントをインターネットドラフト として配布することも認められている。 インターネットドラフトは最大6ヶ月間有効で、その後アップデートや置き換え をすることができる。もしくは、他のドキュメントによりいつでも無効にする ことができる。インターネットドラフトを参考文献として引用すること、もし くは "work in progress" 以上の扱いで引用するのは適切ではない。 現在のインターネットドラフトは、次のところからアクセスすることができる。 http://www.ietf.org/ietf/1id-abstracts.txt インターネットドラフトのミラーサイトのリストは、次のところからアクセス することができる。 http://www.ietf.org/shadow.html 要旨 本ドキュメントでは、[RFC2246]で定義されるTransport Layer Security (TLS)を [RFC2960]で定義されるStream Control Transmission Protocol (SCTP)上で使用 する方法について記述する。 TLSのユーザは、SCTPで提供される以下のような特長を利用することができる。 - ヘッド・オブ・ライン・ブロッキングを避けるためのマルチストリーム のサポート。 - ネットワークレベルでのフォールトトレランスのための、マルチホーミング のサポート。 - IPアドレス動的再構成のサポート。 1. はじめに 1.1. 概要 本ドキュメントでは、[RFC2246]で定義されるTransport Layer Security (TLS)を [RFC2960]で定義されるStream Control Transmission Protocol (SCTP)上で使用 する方法について記述する。 TLSは、信頼性があり、順序どおりの配送を行うバイトストリーム指向の転送 プロトコル上で動作するように設計されている。それゆえ、TLSは現在のところ 主に、[RFC793]で定義されるTransmission Control Protocol (TCP)上で使用 されている。 TCPとSCTPを比較すると、後者は前者の付加機能を提供している。そのため 本ドキュメントではTLSユーザに対し、これらの付加機能を利用するために SCTP上でTLSをどのように使用すべきかについて記述する。 本ドキュメントでは、以下の定義を行う。 - SCTPのマルチストリーム機能の使用方法。 - SCTPのメッセージ指向という特徴の処理方法。 TLSユーザは、SCTPのマルチホーミングサポートを利用することができることは 特記すべきであろう。また[SCTPEXT]で記述されているIPアドレスの動的再構成 についても、記述されている方法により使用することができる。 本ドキュメントで記述している方法では、TLSやSCTPの変更を必要としない。 唯一必要となるのは、SCTP実装では、オプショナル機能とされているSCTP ユーザメッセージのフラグメンテーション機能のサポートが要求されること である。 1.2. 用語 本ドキュメントでは、以下の用語を使用する。 アソシエーション: SCTPのアソシエーション。 コネクション: TLSのコネクション。 セション: TLSのセション。 ストリーム: SCTPアソシエーションの片方向ストリーム。これはストリーム識別子 により識別される。 1.3. 略号 MTU: Maximum Transmission Unit SCTP: Stream Control Transmission Protocol TCP: Transmission Control Protocol TLS: Transport Layer Security 2. 慣用表現 本ドキュメントに現れるキーワードMUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、 SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONALは、RFC2119[1]で示される ように解釈されなければならない。 3. SCTPにおける要件 3.1. インバウンド、アウトバウンドのストリーム番号 TLSにより使用されるアソシエーションが確立されるときには、SCTPユーザは SCTP層に対し、インバウンドストリームとアウトバウンドストリームを同じ数だけ 要求しなければならない(MUST)。このルールにより、アソシエーションでは両方 の方向のストリームを同じ数だけ持つことが確実となる。同じストリーム識別子を 持つ2つのストリームペアは、1つの双方向ストリームと見なされ、使用される。 それゆえ1つのSCTPアソシエーションは、複数の双方向ストリームの集合と 考えることができる。 3.2. ユーザメッセージのフラグメント TLS処理の内部においてMTUに関する知識を持ち、その処理を行わなければならなく なることを避けるために、SCTPは、[RFC2960]ではオプショナルとされている機能 であるユーザメッセージのフラグメンテーション機能を提供しなければならない (MUST)。SCTPはメッセージ指向プロトコルであるため、すべてのTLSレコードを SCTPユーザメッセージとして送受信できなければならない。それゆえSCTPユーザ メッセージでサポートする最大長は、少なくとも 2^14 + 2048 + 5 = 18437 バイトでなければならない(MUST)。この長さは、[RFC2246]で定義されている TLSCiphertextの最大長に基づく。 それゆえ、IPフラグメントを避けるために、SCTPではTLSレコードのフラグメント と再アセンブルについて注意を払うことになる。 4. コネクションと双方向ストリーム TLSは、それぞれの双方向ストリーム上でコネクションを確立することで、複数の 双方向ストリームを利用することができる。これはすなわち、1つのアソシエー ションで確立することのできるコネクションの数は、双方向ストリームの数に 制限されることを意味する。 TLSハンドシェイクプロトコルは、それぞれの双方向ストリームごとに別々に 行われる。それぞれのハンドシェイクでは、以下のことを行うことができる。 - 完全なハンドシェイク、もしくは - (同一アソシエーションまたは他のアソシエーションにおける)他の コネクションのセションIDを使用した、TLSセションを再利用する 簡略ハンドシェイク。 コネクションのハンドシェイクが完了した後、双方向ストリームを使用して、 TLSに基づくユーザデータ送受信を行うことができる。さらに、コネクション間の ハンドシェイクは独立しており、双方向ストリームがユーザデータ送受信に 使用されてから他のコネクションのハンドシェイクを開始してもよいことは 特記すべきである。 5. 使用例 以下に示す例では、1つのアソシエーションに2つの双方向ストリームがある 場合について考察する。 5.1. 完全ハンドシェイクを行う2つの双方向ストリーム アソシエーションが確立されたすぐ後に、クライアントは双方向ストリーム0と1 上で、2つのClientHelloメッセージを送信する。そしてそれぞれの双方向スト リームで完全ハンドシェイクが完了した後、TLSに基づくユーザデータ送受信を 行うことができる。双方向ストリーム0上でのハンドシェイクが完了した後には、 双方向ストリーム1上でのハンドシェイクが完了していなくても、ユーザデータ 送受信を行うことができる。またその逆も同様である。 5.2. 簡略ハンドシェイクを行う2つの双方向ストリーム アソシエーションが確立した後、クライアントは双方向ストリーム0上で完全 ハンドシェイクを開始する。サーバは、セションIDを提供することで、セション の再利用を可能にする。完全なハンドシェイクが完了した後、クライアントは 双方向ストリーム0上で行ったハンドシェイクのセションIDを使用して、双方向 ストリーム1上で簡略ハンドシェイクを開始する。双方向ストリーム0上では、 ユーザデータの送受信が可能であるが、双方向ストリーム1上は、この時点では ユーザデータを送受信することはできない。双方向ストリーム1上での簡略ハンド シェイクが完了した後、2つのストリーム上でユーザデータを送受信することが できる。 SCTPアソシエーション上におけるTLSコネクションのセットアップフェーズの間に 簡略ハンドシェイクを行うか行わないかは、さまざまな要因に依存する。 - ハンドシェイク初期処理の複雑さとその期間(これはコネクション 数にも依存する) - ネットワークパフォーマンス(ラウンドトリップ時間、帯域幅) ハンドシェイクの複雑な計算がリソース制約となる場合、簡略ハンドシェイクに より、この複雑な計算を大幅に削減することができる。多数のコネクションの 確立が必要な場合には、TLSのセション再利用機能の使用は有利であろう。 一方、簡略ハンドシェイクを行う前には完全ハンドシェイクが完了している必要 がある。ネットワークにおけるラウンドトリップ時間遅延が大きい場合には、 多数の完全ハンドシェイクを並行して行う方が望まれるであろう。それゆえ、 どちらの方法を利用してもよい。 5.3. 時間差のある簡略ハンドシェイクを行う2つの双方向ストリーム この例は先の例に似ているが、双方向ストリーム0上での完全ハンドシェイクが 完了しても、双方向ストリーム1上での簡略ハンドシェイクをすぐには開始しない。 ユーザデータ送受信には、双方向ストリーム0を使用することができる。ユーザが 双方向ストリーム1上でデータを送受信したいと考えたときのみに、双方向スト リーム1上での簡略ハンドシェイクが開始される。 これにより、すべての双方向ストリームを開始時点から使用するわけではない場合 には、TLSのユーザはそれらのリソースをアソシエーションの開始時点ですべて 取得しておく必要なしに、多数の双方向ストリームを利用することができる。 5.4. 完全ハンドシェイクを行わない2つの双方向ストリーム 上記2番目と3番目の例に似ているが、両方の双方向ストリームにおいて簡略ハンド シェイクを行う。この場合には、他のアソシエーションで処理されたコネクション における有効なセションIDが必要となる。 6. セキュリティに関する考察 SCTP上でTLSを使用しても、[RFC2246] と [RFC2960] で議論された以外の新しい セキュリティ問題が発生することはない。 7. 謝辞 P. Calhoun, E. Rescorla, J. Wood, そして他の方々の、非常に貴重なコメントや 提案に感謝する。 8. 参考文献 [SCTPEXT] R. R. Stewart, Q. Xie, M. Tuexen, I. Rytina, "SCTP Extensions for Dynamic Reconfiguration of IP Addresses and Enforcement of Flow and Message Limits", , February 2001. [RFC793] J. Postel (ed.), "Transmission Control Protocol", STP 7, RFC 793, September 1981. [RFC2119] S. Bradner, "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2026] S. Bradner, "The Internet Standards Process -- Revision 3", RFC 2026, October 1996. [RFC2246] T. Diercks, C. Allen, "The TLS Protocol Version 1.0", RFC 2246, January 1999. [RFC2960] R. R. Stewart et al., "Stream Control Transmission Protocol", RFC 2960, November 2000. 9. 著者のアドレス Michael Tuexen Tel.: +49 89 722 47210 Siemens AG e-mail: Michael.Tuexen@icn.siemens.de ICN WN CS SE 5 D-81359 Munich Germany Andreas Jungmaier Tel.: +49 201 1837636 University of Essen e-mail: ajung@exp-math.uni-essen.de Networking Technology Group at the IEM Ellernstrasse 29 D-45326 Essen Germany このインターネットドラフトは、2001年12月22日に有効期限切れとなる。 日本語訳 西原 啓輔 2002年11月 訳者は、訳出した文書を利用することにより発生したいかなる損害に対しても 責任を負いません。 本文書には、技術的あるいは翻訳上の誤りがある可能性があります。技術的に 正しい知識を獲得しなければならない場合は、InterNIC/IETFから発行されて いる原文を参照してください。