[要約] 要約：RFC 3514は、IPv4ヘッダーにセキュリティフラグを追加するための提案です。このフラグは、パケットの送信元と宛先のセキュリティ状態を示すために使用されます。目的：RFC 3514の目的は、IPv4ヘッダーにセキュリティフラグを追加することで、ネットワークセキュリティの向上を図ることです。このフラグにより、攻撃者が特定のホストを標的にすることが困難になります。
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.
このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
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ヘッダーにセキュリティフラグを定義します。
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に設定されます。
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].
このドキュメントに記載されているキーワードは、必須、必須、必須、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、およびOPTIONALであり、[RFC2119]で説明されているように解釈されます。
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に任されていません。
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）。 （仕様のこの部分は、多くの一般的なデスクトップオペレーティングシステムによって既に実装されています。）
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）。安全でないシステムは、クラッシュしたり侵入したりすることを選択したかもしれません。
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.
evil bitを設定する方法はいくつかあります。攻撃アプリケーションは、適切なAPIを使用して、設定を要求する場合があります。他のメカニズムを持たないシステムは、そのようなAPIを提供する必要があります。攻撃プログラムはそれを使用しなければなりません。
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.
マルチレベルの安全でないオペレーティングシステムには、攻撃プログラムのための特別なレベルがある場合があります。そのようなレベルで実行されているプログラムから発せられるパケットには、デフォルトで悪ビットが設定されている必要があります。ただし、システムは通常攻撃動作に従事しているユーザーによる悪意のないアクティビティに対してそれをクリアできるAPIを提供する場合があります。
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.
それ自体が危険なフラグメントには、evilビットを設定する必要があります。悪ビットが設定されたパケットが中間ルーターによってフラグメント化され、フラグメント自体が危険でない場合は、悪ビットをフラグメントでクリアし、再構成されたパケットで再びオンにする必要があります。
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.
一部のアプリケーションは、独自のパケットを手作りします。これらのパケットが攻撃の一部である場合、アプリケーションはそれ自体で悪ビットを設定する必要があります。
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および電子メールプロキシは、無害なクライアントホストへの応答パケットに悪ビットを設定する必要があります（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.
一部のホストは、侵入検知システムに警告できる方法で他のホストをスキャンします。スキャンが良性の研究プロジェクトの一部である場合、evil bitを設定してはなりません（MUST NOT）。スキャン自体は無害ですが、最終的な意図が悪であり、宛先サイトにそのような侵入検知システムがある場合、悪ビットを設定する必要があります（SHOULD）。
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.
ファイアウォールなどのデバイスは、evilビットが設定されているすべての着信パケットをドロップする必要があります。 evil bitがオフのパケットはドロップしてはなりません（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は悪ビットを評価するときに確率的補正係数を適用する必要があります。悪ビットが設定されている場合、適切な乱数ジェネレータ[RFC1750]を調べて、試行をログに記録する必要があるかどうかを判断する必要があります。同様に、ビットがオフの場合は、別の乱数ジェネレータを調べて、設定に関係なくログを記録する必要があるかどうかを判断する必要があります。
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は、偽陽性値は低くなりますが、偽陰性値は高くなります。オペレーターがこれらの値をリセットできるように、適切な管理インターフェースを提供する必要があります。
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 outlined earlier, host processing of evil packets is operating-system dependent; however, all hosts MUST react appropriately according to their nature.
前述のとおり、悪質なパケットのホスト処理はオペレーティングシステムに依存します。ただし、すべてのホストはその性質に応じて適切に反応する必要があります。
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つ目のホップバイホップオプションは、DDoSパケットなど、ネットワークに損傷を与えるパケットに使用されます。 2番目のエンドツーエンドオプションは、宛先ホストに損傷を与えることを目的としたパケット用です。どちらの場合も、オプションには、パケットの悪さを示す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.
一部のリンク層、特に光スイッチングに基づくものは、ルーター（およびファイアウォール）を完全にバイパスする場合があります。したがって、いくつかのリンク層スキームを使用して悪を示す必要があります。これには、邪悪なラムダ、邪悪な分極などが含まれる場合があります。
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.
アプリケーション/悪質なMIMEタイプは、Webまたは電子メールで運ばれるいたずらに対して定義されます。他のMIMEタイプは、悪のセクションの中に埋め込むことができます。これにより、マクロウイルスなどでワープロドキュメントを簡単にエンコードできます。
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値のセキュリティ要素の動作を定義しています。ビットの他の値の動作は、IETFコンセンサス[RFC2434]によってのみ定義できます。
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.
セキュリティメカニズムが正しく機能するかどうかは、悪意のあるビットが適切に設定されているかどうかに大きく依存します。障害のあるコンポーネントが適切なときにevilビットを1に設定しない場合、ファイアウォールは適切にジョブを実行できません。同様に、ビットが1に設定されるべきではないときに1に設定されていると、サービス拒否の状態が発生する可能性があります。
[CBR03] W.R. Cheswick, S.M. Bellovin, and A.D. Rubin, "Firewalls and Internet Security: Repelling the Wily Hacker", Second Edition, Addison-Wesley, 2003.
[CBR03] W.R. Cheswick、S.M. Bellovin、およびA.D. Rubin、「Firewalls and Internet Security：Repelling the Wily Hacker」、第2版、Addison-Wesley、2003年。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC791] Postel、J。、「インターネットプロトコル」、STD 5、RFC 791、1981年9月。
[RFC1750] Eastlake, D., 3rd, Crocker, S. and J. Schiller, "Randomness Recommendations for Security", RFC 1750, December 1994.
[RFC1750] Eastlake、D.、3rd、Crocker、S。およびJ. Schiller、「Randomness Recommendations for Security」、RFC 1750、1994年12月。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、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, October 1998.
[RFC2434] Narten、T。およびH. Alvestrand、「RFCでIANAの考慮事項セクションを作成するためのガイドライン」、BCP 26、RFC 2434、1998年10月。
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[RFC2460] Deering、S。およびR. Hinden、「インターネットプロトコル、バージョン6（IPv6）仕様」、RFC 2460、1998年12月。
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network Address Translator (Traditional NAT)", RFC 3022, January 2001.
[RFC3022] Srisuresh、P。およびK. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。
Steven M. Bellovin AT&T Labs Research Shannon Laboratory 180 Park Avenue Florham Park, NJ 07932
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
Copyright (C) The Internet Society (2003). All Rights Reserved.
Copyright（C）The Internet Society（2003）。全著作権所有。
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.
RFC Editor機能への資金提供は、現在Internet Societyから提供されています。