Network Working Group S. Bellovin Request for Comments: 3514 AT&T Labs Research Category: Informational 1 April 2003 IPv4 ヘッダにおけるセキュリティフラグ The Security Flag in the IPv4 Header このメモの位置付け このメモはインターネットコミュニティに対し情報を提供する。いかな る種類のインターネットの標準を規定するものでもない。このメモの配 布は制限されない。 著作権の表示 Copyright (C) The Internet Society (2003). All Rights Reserved. 要約 ファイヤウォールやパケットフィルター、侵入検知装置、または、それに 類するもので、悪意のあるパケットと単に珍しいだけのパケットを判別す るのは、しばしば困難である。われわれは、この 2 つを判別する手段と して、IPv4 ヘッダにセキュリティフラグを定義する。 1. 導入 ファイヤウォール [CBR03] やパケットフィルター、侵入検知装置、または それに類するもので悪意のあるパケットと単に珍しいだけのパケットを判 別するのは、しばしば困難である。この問題は、そのような決断をするの が難しいということである。この問題を解決するため、われわれは、IPv4 [RFC791] ヘッダに「悪」のビットとして知られる、セキュリティフラグを 定義する。良性のパケットはこのビットを 0 に設定し、攻撃のために使わ れるパケットはこのビットを 1 に設定する。 1.1. 用語法 この文書の中の「なければならない(MUST)」、「してはならない(MUST NOT)」、「必要となる(REQUIRED)」、「だろう(SHALL)」、「ないだろう (SHALL NOT)」、「すべきだ(SHOULD)」、「すべきでない(SHOULD NOT)」、 「推奨される(RECOMMENDED)」、「てもよい(MAY)」、「オプションの (OPTIONAL)」というキーワードは [RFC2119] の記述のとおりに解釈される べきだ。 2. 文法 IP 断片のオフセットフィールドの高次ビットは IP ヘッダにおいて唯一使 われていないものである。したがって、このビットの位置の選択は IANA に任されていない。 Bellovin Informational [Page 1] RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 このビットフィールドは以下のように配置される。: 0 +-+ |E| +-+ 現行、規定されている値は以下のように定義される: 0x0 このビットが 0 に設定されていたら、そのパケットは悪意がない。 ホストやネットワーク装置等は、パケットは無害であると想定「すべ き」であり、いかなる防衛対策もとる「べきでない」。(われわれは、 本仕様のこの部分はすでに多くの一般的デスクトップオペレーティン グシステムで実装されていることを銘記する。) 0x1 このビットが 1 に設定されていたら、そのパケットは悪意がある。 セキュアなシステムはそのようなパケットから自分自身を守ろうと 「すべきだ」。セキュアでないシステムは、クラッシュしたり、素通 りさせたり等し「てもよい」。 3. 「悪」のビットを設定する 「悪」のビットを設定する方法はいくつかある。攻撃アプリケーションは それが設定された要求に適合する API を使うかも知れない。それ以外の機 構を持たないシステムはそのような API を提供し「なければならない」。 攻撃プログラムはそれを利用し「なければならない」。 多層非セキュアオペレーションシステムは攻撃プログラムのために特別な 層を持っているかもしれない。その層で動作するプログラムから送出され るパケットは、「悪」のビットがデフォルトで設定され「なければならな い」。しかし、システムは、攻撃行動に標準的に従事するユーザによる悪 意のない活動に対し、それがクリアされることを許すような API を提供し 「てもよい」。 それ自体が危険である断片は「悪」のビットをセットし「なければならな い」。「悪」のビットがセットされたパケットが途中のルータで断片化さ れて、断片自体が危険でない場合は、「悪」のビットはその断片において クリアされ「なければならない」し、再併合されたパケットにおいてはフ ラグを元に戻さ「なければならない」。 途中のシステムはたまに攻撃の接続を洗浄するために使われる。標的に中 継されるために意図されたそのようなシステムへのパケットは「悪」のビッ トがセットされる「べきだ」。 いくつかのアプリケーションは自分のパケットを細工する。そのようなパ ケットが攻撃の一部であるなら、アプリケーションは自分で「悪」のビッ トを設定し「なければならない」。 ファイヤウォールで保護されたネットワークでは、すべての攻撃者がファ イヤウォールの外にいることが自明である。よって、ファイヤウォールの 内側のホストは、如何なるパケットにも「悪」のビットを設定「してはな らない」。 Bellovin Informational [Page 2] RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 NAT [RFC3022] 装置はパケットを改変するので、そのようなパケットに対 し「悪」のビットを設定「すべきだ」。「透過的な」 http や電子メール のプロキシは無垢なクライアントホストに対する応答パケットに「悪」の ビットを設定「すべきだ」。 あるホストが別のホストを侵入検知装置が警報できるような方法でスキャ ンする。スキャニングが良性の調査計画の一部であるなら、「悪」のビッ トは設定「されてはならない」。SE によるスキャニングが無垢なものであっ ても、究極的な目的が悪で、宛先サイトがそういう侵入検知装置を持って いる場合は「悪」のビットは設定「すべきだ」。 4. 「悪」のビットの処理 ファイヤウォールのような装置は、すべての「悪」のビットが設定された 流入パケットを落さ「なければならない」。「悪」のビットがオフに設定 されたパケットは落「してはならない」。落されたパケットは適当な MIB 変数に記録される「べきだ」。 侵入検知装置 (IDS) にはより難しい問題がある。フォールスネガティブや フォールスポジティブとしてよく知られた傾向のために、IDS は、「悪」 のビットを評価するときに確率的修正因子を適用「しなければならない」。 「悪」のビットが設定されていたら、その試みが記録されるべき稼働かを 決定するために、適切な乱数生成器 [RFC1750] は助言を求められるなけれ ばならない。同様に、そのビットがオフだったら、他の乱数生成器が、そ の設定を無視して記録されるべきかどうかを決定するために助言を求めら れなければならない。 これらのテストにための無指定時の確率は IDS の形態に依存する。それゆ え、シグネーチャーベースの IDS は低フォールスポジティブ値だが高フォー ルスネガティブ値である。適当な管理インターフェースは運用者がこれら の値を設定し直すことを許すように提供され「なければならない」。 セキュリティ装置がそうであるようには意図されていないルータはこのビッ トを確かめる「べきでない」。このことにより、高速でパケットが通過で きるだろう。 すでに概観したとおり、ホストが「悪」のパケットを処理することはオペ レーティングシステムに依存する。すべてのホストはその本性のとおり、 適切に反応し「なければならない」。 5. 関連する研究 本文書は、IPv4 の「悪」のビットのみを定義するが、それ以外の悪の形態 のための類似の機構が存在する。われわれは以下にその概略を述べる。 IPv6 [RFC2460] については、2 つのオプションにより「悪」は搬送される。 1 つめのホップバイホップオプションは、ネットワークに悪影響を与える ようなパケット、例えば DDoS パケットのために使われる。2 つめのエン ドツーエンドオプションは宛先ホストに悪影響を与えるためのパケットの ためのものである。いずれの場合も、オプションは 128 ビット長のそのパ Bellovin Informational [Page 3] RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 ケットがどれだけ「悪」か標識と、意図された攻撃の個別の型を示す 128 ビットのタイプコードを含む。 あるリンク層、とくに光スイッチで構成されたものはルータ (とヘンスファ イヤウォール(hense firewall???))を完全にバイパスするかもしれない。 したがって、リンク層のスキームは「悪」を表示するために使うことがで き「なければならない」。これは「悪」のラムダ、「悪」の分極等を意味 するかもしれない。 DDoS 攻撃パケットは特別な diffserv コードポイントによって表示される かもしれない。 application/evil MIME タイプは Web により、または電子メールにより伝 播するいたずらのために定義される。ほかの MIME タイプは evil セクショ ンの中に埋め込まれうる。これはマクロウィルスを含むワープロ文書等の エンコードを容易にする。 6. IANA の考察 本文書はこのビットの 0x0 と 0x1 の値に対するセキュリティ要素の振る 舞いを定義する。ビットのこれら以外の値に対する振る舞いは IETF にお ける合意によってのみ定義されうる [RFC2434]。 7. セキュリティの考察 セキュリティ機構の正確な機能は正しく設定された「悪」のビットに依存 する。不完全なコンポーネントが適切なときでも「悪」のビットを設定し ないなら、ファイヤウォールは自分の仕事をきちんとすることができなく なるだろう。同様に、そうすべきでない時にこのビットが 1 に設定される なら、サービス不能状態が発生するかもしれない。 8. 参考文献 [CBR03] W.R. Cheswick, S.M. Bellovin, and A.D. Rubin, "Firewalls and Internet Security: Repelling the Wily Hacker", Second Edition, Addison-Wesley, 2003. [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC1750] Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. Bellovin Informational [Page 4] RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001. 9. 著者の連絡先 Steven M. Bellovin AT&T Labs Research Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932 Phone: +1 973-360-8656 EMail: bellovin@acm.org Bellovin Informational [Page 5] RFC 3514 The Security Flag in the IPv4 Header 1 April 2003 10. 完全な著作権表示 Copyright (C) The Internet Society (2003). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 謝辞 RFC 編集者機構の資金は現在、インターネットソサエティから供給されて いる。 Bellovin Informational [Page 6]