ネットワーク WG
Request for Comments: 3514
分類: 情報提供

S. Bellovin
AT&T Labs Research
2003年 4月 1日

English

IPv4 ヘッダーにおけるセキュリティフラグ
(The Security Flag in the IPv4 Header)

本書の位置付け

本書は、インターネットコミュニティに対して情報を提供します。何らインターネット標準を規定するものではありません。本書の配布に制限はありません。

著作権表記

Copyright (C) The Internet Society (2003). All Rights Reserved.

要旨

ファイアウォール [CBR03]、パケットフィルタ、IDS のようなものにとって、悪意ある試みのパケットと、ほとんど異常でないパケットを区別することは困難です。我々は、この 2つの場合を区別する意味を持つ IPv4 [RFC791] ヘッダーのセキュリティフラグを定義します。

1. はじめに English

ファイアウォール [CBR03]、パケットフィルタ、IDS のようなものにとって、悪意のある試みのパケットと、ほとんど異常でないパケット を区別することは困難です。この問題は、その決定をしますことが困難なことに起因します。この問題を解決するため、IPv4 [RFC 791] ヘッダーに「evil bit」として知られるセキュリティフラグを定義します。悪意から出たわけではないパケットは 、このビットを 0 にセットします。; 攻撃に使われるもののビットには、1 がセットされます。

1.1 用語法 English

本書中の MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, OPTIONAL は、[RFC2119] に記述されたように解釈されるべきものです。

2. 構文 English

IPヘッダーで、IPフラグメントオフセットフィールドの高位のビットだけが使われていません。よって、ビット位置の選択は、IANA に残されていません。

そのビットフィールドは、以下のように配置されます。:

0
+-+
|E|
+-+

現在割り当てられている値は、以下に定義されるとおりです。:

0x0

ビットが0にセットされている場合、パケットに悪意はない。ホスト、ネットワークの要素等は、このパケットが無害であると仮定する必要があり(SHOULD)、防護手段を講じるてはいけません(SHOULD NOT)。(スペックのこの部分は、既に多くの一般的なデスクトップ OS に実装されていることに注目しました。)

0x1

そのビットが1の場合、パケットに悪意があります。セキュアなシステムは、そのようなパケットに対して自身を防護するよう努める必要があります(SHOULD)。インセキュアなシステムはクラッシュしますか、侵入される等を選択することができます(MAY)

 

3. evil bit のセット English

evil bit をセットするために数多くの方法があります。攻撃用アプリケーションは、それをセットすることを要求するのにふさわしい API を使う可能性があります。それ以外のメカニズムを持たないシステムは 、そのような API を提供しなければなりません(MUST)。; 攻撃プログラムは、それを利用しなければなりません(MUST)

複数のレベルのインセキュアなOSは、攻撃プログラムにとって特別なレベルを持つ可能性があります。そのようなレベルで動作するプログラムから発せられるパケットには、デフォルトで evil bit がセットされなければなりません(MUST)。しかし、普段攻撃をするユーザによる悪意のない行動については、それをクリアできるようにする API を提供することができます(MAY)

それ自身危険なフラグメントは、evil bit がセットされていなければなりません(MUST)。 evil bit がセットされたパケットが途中のルータによりフラグメントされており、かつフラグメント自身が危険でない場合、フラグメント中の evil bit はクリアされなければならず、それは再構成されたパケットにつけられねばなりません(MUST)

しばしば、途中のシステムがロンダリング攻撃の接続に使われることがあります。そのようなシステムがターゲットへリレーする試みるようなパケットには、evil bit がセットされる必要があります(SHOULD)

いくつかのアプリケーションは自身のパケットを自分で作ります。これらのパケットが攻撃の一部である場合、アプリケーションは、自ら evil bit をセットしなければなりません。

ファイアウォールで守られたネットワークの中では、すべての攻撃者はファイアウォールの外から来ることは自明です。それゆえ、ファイアウォールの中にあるホストは、いかなるパケットにも evil bit を立ててはなりません(MUST NOT)

NAT [RFC3022] ボックスは、パケットを変更するため、それはそのようなパケットに evil bit を立てる必要があります(SHOULD)。透過的な http や電子メールのプロキシは、無知なクライアントホストへのリレーパケットに evil bit を立てる必要があります(SHOULD)。

いくつかのホストは、IDS に警告させるかもしれない方法で別ホストをスキャンします。スキャンが良い研究プロジェクトの一部である場合、evil bit を立ててはなりません(MUST NOT)。スキャンが邪心なく行われたが最終的には悪意があり、かつ目的サイトが IDS のようなものを持っている場合、evil bit が立てられる必要があります(SHOULD)

 

4. evil bit の処理 English

ファイアウォールのようなデバイスは、evil bit が立った侵入パケットをすべて棄却しなければなりません(MUST)。 evil bit がオフのすべてのパケットは、棄却してはなりません(MUST NOT)。棄却されたパケットはしかるべき MIB によって知らされます。

IDSは、より困難な問題をかかえています。偽のネガティブと偽のポジティブの傾向が知られているため、IDS が evil bit を評価するときには確率的な修正を適用しなければなりません(MUST)。 evil bit がセットされている場合、その試みをログに残すべきかどうかは適切な乱数生成器 [RFC1750] に決定を委ねなければなりません。そのビットがオフの場合、その試みをログに残すべきかどうかを別の乱数生成器による決定に従います。

これらのテストに対するデフォルトの確率は、IDS のタイプに依存します。従って、シグネイチャによる IDS は、偽のポジティブな結果は少ないが偽のネガティブな結果が多いでしょう。これらの値をリセットすることをオペレータに許可する適切な管理インターフェイスが提供されなければなりません(MUST)

セキュリティデバイスと見なされないルーターは、このビットを見てはいけません(SHOULD NOT)。これにより、パケット通過速度をより高くすることができます。

以 前に概観したように、ホストによる悪意あるパケットの処理は、OS に依存します。; しかし、すべてのホストは、自然なふるまいで適切に処理しなければなりません(MUST)

 

5. 関連する作業 English

本書は、IPv4 の evil bit についてのみを定義していますが、別の形態の悪に対して補完的なメカニズムが存在します。そのいくつかを、ここに示します。

IPv6 [RFC2460] については、悪意は、2つのオプションによって伝達されます。最初のものは、hop-by-hop オプションであり、ネットワークに打撃を与える DDoS のようなパケットに使われます。2つめは、「エンドtoエンド」オプションであり、相手ホストに打撃を与えるようなパケットのためにあります。いずれの場合も、そのオプションは 、どのような悪いパケットなのかを述べる 128bit 長の表示と、予定した攻撃の特定の型を示す128bit 長を含みます。

いくつかのリンクレイヤ、とりわけ光学スイッチを基礎とするものでは、完全にルーター(や、それゆえファイアウォール)を迂回する可能性があります。その結果、いくつかのリンクレイヤのスキームは悪であると いう印が付けられなければなりません(MUST)。これは、悪い波長や悪い偏光等を含む可能性があります。

DDoS 攻撃(分散型サービス妨害攻撃)のパケットは、特別なコードポイントで表示されます。

web や電子メールで運ばれる危害のため、application/evil の MIME タイプが定義されます。別の MIME タイプを悪のセクションの内側に組みこむことができます。; これにより、マクロウイルス等を含むワープロ文書のエンコードが容易になります。

 

6. IANA の考察 English

本書は、このビットの 0x0 と 0x1 の値のためのセキュリティ要素のふるまいについて定義しています。そのビットが、それ以外の値である場合のふるまいは、IETF のコンセンサス [RFC2434] によってのみ定義される可能性があります。

 

7. セキュリティに関する考慮事項 English

セキュリティ機構が正しく機能するか否かは、evil bit が適切にセットされるか否かに決定的に依存します。そのようにするのが適切な場合に誤ったコンポーネントが evil bit を 1 にセットしないならば、ファイアウォールは、きちんとその仕事をできないでしょう。同様に、そうすべきでないのにそのビットを 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, 1981年 9月.
 
[RFC1750] Eastlake, D., 3rd, Crocker, S. and J. Schiller,
「セキュリティのための乱雑さについての推奨事項(Randomness Recommendations for Security)」,
RFC 1750, 1994年12月.
 
[RFC2119] Bradner, S.,
「RFC において要請の程度を示すために用いるキーワード(Key words for use in RFCs to Indicate Requirement Levels)」,
BCP 14
, RFC 2119, 1997年3月.
 
[RFC2434] Narten, T. and H. Alvestrand,
"Guidelines for Writing an IANA Considerations Section in RFCs",
BCP 26
, RFC 2434(English), 1998年10月.
 
[RFC2460] Deering, S. and R. Hinden,
"Internet Protocol, Version 6 (IPv6) Specification",
RFC 2460, 1998年12月.
 
[RFC3022] Srisuresh, P. and K. Egevang,
"Traditional IP Network Address Translator (Traditional NAT)",
RFC 3022, 2001年1月.

 

9. 著者のアドレス

Steven M. Bellovin
AT&T Labs Research
Shannon Laboratory
180 Park Avenue
Florham Park, NJ 07932

電話: +1 973-360-8656
EMail: bellovin@acm.org

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail: miyakawa@ipa.go.jp

 

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.

謝辞

Funding for the RFC Editor function is currently provided by the Internet Society.