|Network Working Group S. Bellovin |Request for Comments: 3514 AT&T Labs Research |Category: Informational 1 April 2003 | | | The Security Flag in the IPv4 Header IPv4ヘッダのセキュリティフラグ | |Status of this Memo このメモのステータス | | This memo provides information for the Internet community. It does | not specify an Internet standard of any kind. Distribution of this | memo is unlimited. このメモはインターネットコミュニティに情報を提供する。それはどのよ うな種類のインターネット標準にも指定しない。このメモの配布は無制限 である。 (※訳注 この翻訳verはあまりにも恥ずかしいので配布しないでT_T） | |Copyright Notice | | Copyright (C) The Internet Society (2003). All Rights Reserved. | |Abstract 摘要 | | Firewalls, packet filters, intrusion detection systems, and the like | often have difficulty distinguishing between packets that have | malicious intent and those that are merely unusual. We define a | security flag in the IPv4 header as a means of distinguishing the two | cases. ファイアウォール、パケットフィルター、侵入検知システム等が抱える難題 として、悪意に満ちたパケットと単なる異常なパケットの区別がある。私達 は、それら2つのケースを区別するためのセキュリティフラグをIPv4ヘッダに 定義する。 | |1. Introduction 1.序論 | | Firewalls [CBR03], packet filters, intrusion detection systems, and | the like often have difficulty distinguishing between packets that | have malicious intent and those that are merely unusual. The problem | is that making such determinations is hard. To solve this problem, | we define a security flag, known as the "evil" bit, in the IPv4 | [RFC791] header. Benign packets have this bit set to 0; those that | are used for an attack will have the bit set to 1. ファイアウォール [CBR03]、パケットフィルター、侵入検知システム等が 抱える難題として、悪意に満ちたパケットと単なる異常なパケットの区別 がある。問題は、そのような定義づけをすることが難しいことである。私 達はこの問題を解決するために、セキュリティフラグ（"邪悪な"ビット） をIPv4［RFC791］ヘッダに定義する。害のないパケットは、このビットを 0に設定する; 攻撃に使用するならば、このビットを1に設定する。 | |1.1. Terminology 1.1. 専門用語 | | The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, | SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this | document, are to be interpreted as described in [RFC2119]. MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、 RECOMMENDED、MAY、および OPTIONAL というキーワードがこの文書に出現 する時には、［RFC2119］において説明されているように解釈しなければ ならない。 | |2. Syntax 2. シンタックス | | The high-order bit of the IP fragment offset field is the only unused | bit in the IP header. Accordingly, the selection of the bit position | is not left to IANA. IPフラグメントオフセットフィールドの上位ビットは、IPヘッダで唯一未使用 のビットである。したがって、ビット位置の選択はIANAに委任されない。 （※訳注 したがって〜 以下よくわからないT_T IANAの手を借りるまでもないと言 うこと？？） | | The bit field is laid out as follows: このビットフィールドを次の通りに割り当てる： | | 0 | +-+ | |E| | +-+ | | Currently-assigned values are defined as follows: 現在割り当てられる値を次の通りに定義する： | | 0x0 If the bit is set to 0, the packet has no evil intent. Hosts, | network elements, etc., SHOULD assume that the packet is | harmless, and SHOULD NOT take any defensive measures. (We note | that this part of the spec is already implemented by many common | desktop operating systems.) 0x0 このビットが0に設定されていれば、パケットは悪意を持っていない。 ホスト、ネットワーク要素等は、パケットが無害であると仮定するべき で(SHOULD)、どのような防御手段も適用するべきではない(SHOULD NOT)。 （この部分の仕様が、既に多くの共通デスクトップOSに実装されている ことを私たちは特筆する。） (※訳注 "仮定する"の他に"(証拠はないが)決めつける"という意味があるそうな。 盲目的にそうしろということらしい（ｗ) | | 0x1 If the bit is set to 1, the packet has evil intent. Secure | systems SHOULD try to defend themselves against such packets. | Insecure systems MAY chose to crash, be penetrated, etc. | 0x1 このビットが1に設定されていれば、パケットは悪意を持っている。 安全なシステムはこのようなパケットから自らを守ることに挑む べきである(SHOULD)。安全ではないシステムは、クラッシュしたり 侵入等されるほうを選択することができる(MAY)。 |3. Setting the Evil Bit 3. 邪悪ビットの設定 | | There are a number of ways in which the evil bit may be set. Attack | applications may use a suitable API to request that it be set. | Systems that do not have other mechanisms MUST provide such an API; | attack programs MUST use it. 邪悪ビットを設定するにはいくつかの方法がある。攻撃アプリケーションは 適切なAPIを用いて設定するよう要求できる。それ以外のメカニズムをもた ないシステムは、そういったAPIを提供しなければならない(MUST); 攻撃プ ログラムはこれを使わなければならない(MUST)。 | | Multi-level insecure operating systems may have special levels for | attack programs; the evil bit MUST be set by default on packets | emanating from programs running at such levels. However, the system | MAY provide an API to allow it to be cleared for non-malicious | activity by users who normally engage in attack behavior. 複数のレベルがある、安全ではないシステムは、攻撃プログラムのために 特別なレベルを持つことができる; そのようなレベルで動作しているプロ グラムから発出されるパケットには、ディフォルトで邪悪ビットを設定し なければならない(MUST)。しかしながらそのシステムにおいて、普段攻撃 行動に携わっているユーザーらの、悪意のない活動のためにその解除を許 可するAPIを提供することができる(MAY)。 | | Fragments that by themselves are dangerous MUST have the evil bit | set. If a packet with the evil bit set is fragmented by an | intermediate router and the fragments themselves are not dangerous, | the evil bit MUST be cleared in the fragments, and MUST be turned | back on in the reassembled packet. それ自体が危険なフラグメントは、邪悪ビットを設定しなければならない (MUST)。もし邪悪ビットが設定されたパケットが中間のルータによってフ ラグメント化され、それ自体が危険ではなくなった場合は、フラグメント の邪悪ビットを解除しなければならず(MUST)、リアセンブル時に再設定し なければならない(MUST)。 | | Intermediate systems are sometimes used to launder attack | connections. Packets to such systems that are intended to be relayed | to a target SHOULD have the evil bit set. 中間的なシステムは、しばしば攻撃の接続元を隠蔽するために使用される。 ターゲットへの中継を意図してそのようなシステムに送信するパケットに は、邪悪ビットを設定すべきである(SHOULD)。 | | Some applications hand-craft their own packets. If these packets are | part of an attack, the application MUST set the evil bit by itself. いくつかのアプリケーションから生成されたパケット。もしこれらのパケ ットが攻撃の一部であるならば、このアプリケーション自身で邪悪ビット を設定しなければならない(MUST)。 （※訳注 hand-craftってどう訳せば・・・・T_T） | | In networks protected by firewalls, it is axiomatic that all | attackers are on the outside of the firewall. Therefore, hosts | inside the firewall MUST NOT set the evil bit on any packets. ファイアウォールによって防衛されているネットワーク内であるならば、 全ての攻撃者はファイアウォールの外側にいることが自明の理である。 したがって、ファイアウォール内のホストは、いかなるパケットに対し ても邪悪ビットを設定してはならない(MUST NOT)。 | | Because NAT [RFC3022] boxes modify packets, they SHOULD set the evil | bit on such packets. "Transparent" http and email proxies SHOULD set | the evil bit on their reply packets to the innocent client host. それはNAT [RFC3022] ボックスがパケットを加工するからで、それらで 邪悪ビットを設定するべきである(SHOULD)。"透過的な" httpおよびemail プロキシは、汚れを知らないクライアントホストへの応答パケットに対 して邪悪ビットを設定するべきである(SHOULD)。 | | Some hosts scan other hosts in a fashion that can alert intrusion | detection systems. If the scanning is part of a benign research | project, the evil bit MUST NOT be set. If the scanning per se is | innocent, but the ultimate intent is evil and the destination site | has such an intrusion detection system, the evil bit SHOULD be set. 侵入検出システムで警報を出すことが可能な方法によって、他のホストを スキャンするいくつかのホスト。もしそのスキャンが、害のない研究プロ ジェクトの一部であるならば、邪悪ビットを設定してはならない(MUST NOT)。もしそのスキャンがそれ自体は悪意がないものの最終的に有害なも のになるとして、宛先ホストがそのような侵入の検出システムを持ってい るならば、邪悪ビットを設定するべきである(SHOULD)。 （※訳注 ・・・１文が長すぎます・・・ T_T タシケテ） | |4. Processing of the Evil Bit 4. 邪悪ビットの処理 | | Devices such as firewalls MUST drop all inbound packets that have the | evil bit set. Packets with the evil bit off MUST NOT be dropped. | Dropped packets SHOULD be noted in the appropriate MIB variable. ファイアウォール等のデバイスは、邪悪ビットが設定されている外部からの パケットを全てドロップしなければならない(MUST)。邪悪ビットが設定され ていないパケットはドロップしてはならない(MUST NOT)。ドロップされたパ ケットはそれにふさわしいMIB変数で示されなければならない(SHOULD)。 | | Intrusion detection systems (IDSs) have a harder problem. Because of | their known propensity for false negatives and false positives, IDSs | MUST apply a probabilistic correction factor when evaluating the evil | bit. If the evil bit is set, a suitable random number generator | [RFC1750] must be consulted to determine if the attempt should be | logged. Similarly, if the bit is off, another random number | generator must be consulted to determine if it should be logged | despite the setting. 侵入検出システム(IDS)はより難しい問題を持っている。IDSには誤拒否や 誤肯定といった傾向が既知としてあるため、邪悪ビットの評価時には確率 論的な訂正係数を適用しなければならない(MUST)。邪悪ビットが設定され ている場合は、それに即した乱数ジェネレータ [RFC1750] を参照し、記 録するかどうか判定しなけばならない(MUST)。また同様に、邪悪ビットが 設定されていない場合は、もう一つの乱数ジェネレータを参照し、設定に かかわらず記録するかどうかを判定しなければならない、(MUST)。 | | The default probabilities for these tests depends on the type of IDS. | Thus, a signature-based IDS would have a low false positive value but | a high false negative value. A suitable administrative interface | MUST be provided to permit operators to reset these values. これらの検査におけるディフォルトの確率は、IDSのタイプに依存する。 要するに、シグネイチャベースのIDSは、誤肯定であるという確率を低 く、誤拒否であるという確率を高く持つ。オペレータに対しては、これ ら確率の再設定を許可する、適切な管理インターフェースが提供されて いなければならない(MUST)。 （※訳注 文中では"value"とありますが、"probabilities"という言葉に 続くので"value"も"確率"としました） | | Routers that are not intended as as security devices SHOULD NOT | examine this bit. This will allow them to pass packets at higher | speeds. 安全なデバイスとしてそのように意図されていないルータは、このビット を検査するべきではない(SHOULD NOT)。これは、より高速なパケット通過 を可能にする。 （※訳注 "as as" ってなに？？？・・・T_T） | | As outlined earlier, host processing of evil packets is operating- | system dependent; however, all hosts MUST react appropriately | according to their nature. この上なく早く要点を述べると、邪悪なパケットの処理を行うホストはOS に依存している; しかしながら、全てのホストはそれらの性質に応じて、 適切に作用しなければならない(MUST)。 （※訳注 "As outlined earlier"も・・・T_T） | |5. Related Work 5. 関連するワーク | | Although this document only defines the IPv4 evil bit,there are | complementary mechanisms for other forms of evil. We sketch some of | those here. この文書ではIPv4の邪悪ビットを定義するが、これ以外の形式で邪悪な物に 対しても補えるメカニズムが存在している。私達はここでそれらからいくつ かの概要を述べる。 | | For IPv6 [RFC2460], evilness is conveyed by two options. The first, | a hop-by-hop option, is used for packets that damage the network, | such as DDoS packets. The second, an end-to-end option, is for | packets intended to damage destination hosts. In either case, the | option contains a 128-bit strength indicator, which says how evil the | packet is, and a 128-bit type code that describes the particular type | of attack intended. IPv6 [RFC2460] では、邪悪な性質は2つのオプションによって伝達される。 1つ目がhop-by-hopオプションで、DDoSパケットなどの、ネットワークに ダメージを与えるパケットに使用される。2つ目がend-to-endオプションで、 宛先ホストにダメージを与えることを意図したパケットに使用される。その いずれのケースにおいても、パケットがどれだけ邪悪かを示す128ビットの 強度計と、意図している攻撃方法の詳細を示す128ビットのタイプコードを 含む。 | | Some link layers, notably those based on optical switching, may | bypass routers (and hence firewalls) entirely. Accordingly, some | link-layer scheme MUST be used to denote evil. This may involve evil | lambdas, evil polarizations, etc. いくつかのリンク層、特に光スイッチングに基づくものに関しては、ルー タ(そしてその故にファイアウォール)を完全に迂回できるかもしれない。 したがって、いくつかのリンク層のスキームに対しては、邪悪を意味す るように使用されなければならない(MUST)。これは邪悪な波長や偏光な どにも関わることかもしれない。 | | DDoS attack packets are denoted by a special diffserv code point. DDoS の攻撃パケットは、diffservの特別なコードポイントによって示 される。 | | An application/evil MIME type is defined for Web- or email-carried | mischief. Other MIME types can be embedded inside of evil sections; | this permit easy encoding of word processing documents with macro | viruses, etc. application/evil MIMEタイプは、Webやemailによって伝送される危害のた めに定義される。その他のMIMEタイプは、邪悪セクション中に埋め込まれる; これはマクロウィルスを含むワープロ文書等のエンコードを容易に可能とす る。 | |6. IANA Considerations 6. IANA規約 | | This document defines the behavior of security elements for the 0x0 | and 0x1 values of this bit. Behavior for other values of the bit may | be defined only by IETF consensus [RFC2434]. この文書は、このビットにおける0x0、0x1という値に対する、セキュリティ 要素の作用を定義する。それ以外の値に対しての作用は、IEFT合意 [RFC2434] のみによって定義される。 （※訳注 IETF合意ってなんですか？先生・・・T_T） | |7. Security Considerations 7. セキュリティ考察 | | Correct functioning of security mechanisms depend critically on the | evil bit being set properly. If faulty components do not set the | evil bit to 1 when appropriate, firewalls will not be able to do | their jobs properly. Similarly, if the bit is set to 1 when it | shouldn't be, a denial of service condition may occur. セキュリティメカニズムの正常動作は、邪悪ビットが適切に設定されている かどうかに、決定的に依存している。もし不完全なコンポーネントが、邪悪 ビットを1へと適切に設定しなかった場合、ファイアウォールは正常な処理を 行えないだろう。また同様に、そのはずがないものを0へと適切に設定しなか った場合、サービスの拒否という状態が発生するだろう。 | |8. References 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. | | [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. Author's Address | | 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 | |10. Full Copyright Statement | | 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. | |Acknowledgement | | Funding for the RFC Editor function is currently provided by the | Internet Society. （※訳注 以下は私が付け加えた、泣き言^H ^H^H ^H^H ^H 改版履歴です・・・ 翻訳＝Necky(T.Okabuchi) Apr. 2,'03 第1版 適当だけどなんとか形にはなった・・・疲れた・・T_T) 7.5Hかかってるのは内緒。 Apr. 3,'03 第2版 気に入らないところ手直し、手直し、手直し・・・・T_T) それだけで5H....もうダメぽ。・・・・タシケテ・・・ 神様、私をお許し下さい。 Apr. 3,'03 第3版 もう3つのサイトでRFC3514の和訳見たときは愕然と・・・ 神よ!! ・・・・ IDSでの、訂正に関するところを知り合いと 小1Hばかり相談してちょっと修正してみました・・・T_T) カタコトの日本語からはいまだ脱出できてない・・・ Apr. 4,'03 第4版 "(MUST)"が一箇所抜けてましたT_T） とりあえず1Hかけてちょこちょこと手直し・・・