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. 参考文献

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.