RFC 3514 - The Security Flag in the IPv4 Header 日本語訳

原文URL : https://datatracker.ietf.org/doc/html/rfc3514
タイトル : RFC 3514 - IPv4ヘッダーのセキュリティフラグ
翻訳編集 : 自動生成

[要約] RFC 3514は、IPv4ヘッダーの未使用ビット（Reservedビット）を使用して、パケットが悪意（Evil）を持っているかを示す「Evilビット」を定義しています。攻撃パケットには1を、良性パケットには0を設定することで、セキュリティ・デバイスが容易にフィルタリングできるようにするという提案です。※注：このドキュメントは「エイプリルフールRFC」であり、セキュリティ対策の現実的な難しさを風刺したものです。

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.

このメモは、インターネットコミュニティに情報を提供します。いかなる種類のインターネット標準も規定していません。このメモの配布は無制限です。

著作権表示

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].

このドキュメントに記載されているキーワードは、必須、必須、必須、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に任されていません。

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)。（仕様のこの部分は、多くの一般的なデスクトップオペレーティングシステムですでに実装されていることを付記しておきます。）

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.

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.

一部のアプリケーションは、独自のパケットを手作りします。これらのパケットが攻撃の一部である場合、アプリケーションはそれ自体で悪ビットを設定しなければなりません (MUST)。

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）。

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.

ファイアウォールなどのデバイスは、evilビットが設定されているすべての着信パケットをドロップしなければなりません (MUST)。 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は偽陰性と偽陽性を起こしやすいことが知られているため、悪ビットを評価する際には確率的な補正係数を適用しなければなりません (MUST)。悪ビットがセットされている場合は、その試行をログに記録すべきかどうかを決めるために、適切な乱数生成器[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は、偽陽性値は低くなりますが、偽陰性値は高くなります。オペレーターがこれらの値をリセットできるように、適切な管理インターフェースを提供しなければなりません (MUST)。

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.

前述のとおり、悪質なパケットのホスト処理はオペレーティングシステムに依存します。ただし、すべてのホストはその性質に応じて適切に反応しなければなりません (MUST)。

5. 関連作業

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値のセキュリティ要素の動作を定義しています。ビットの他の値の動作は、IETFコンセンサス[RFC2434]によってのみ定義できます。

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.

セキュリティメカニズムが正しく機能するかどうかは、悪意のあるビットが適切に設定されているかどうかに大きく依存します。障害のあるコンポーネントが適切なときにevilビットを1に設定しない場合、ファイアウォールは適切にジョブを実行できません。同様に、ビットが1に設定されるべきではないときに1に設定されていると、サービス拒否の状態が発生する可能性があります。

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.

[CBR03] W.R. Cheswick, S.M. Bellovin, and 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. and 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. and 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. and 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. and K. Egevang、「Traditional IP Network Address Translator（Traditional NAT）」、RFC 3022、2001年1月。

9. Author's Address

9. 著者のアドレス

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

10. Full Copyright Statement

10. 完全な著作権表示

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から提供されています。