Network Working Group                                       D. Brezinski
Request for Comments: 3227                                      In-Q-Tel
BCP: 55                                                      T. Killalea
Category: Best Current Practice                                neart.org
                                                           February 2002
        
            Guidelines for Evidence Collection and Archiving
        

Status of this Memo

このメモの位置付け

This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.

このドキュメントはインターネットコミュニティのためのインターネットBest Current Practicesを指定し、改善のための議論と提案を要求します。このメモの配布は無制限です。

Copyright Notice

著作権表示

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

著作権(C)インターネット協会(2002)。全著作権所有。

Abstract

抽象

A "security incident" as defined in the "Internet Security Glossary", RFC 2828, is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident.

「インターネットセキュリティ用語集」で定義されている「セキュリティインシデント」、RFC 2828は、システムのセキュリティポリシーが従わなかっあるいは破られたセキュリティ関連のシステムイベントです。このドキュメントの目的は、このようなセキュリティインシデントに関連する証拠の収集及び保管上のガイドラインにシステム管理者に提供することです。

If evidence collection is done correctly, it is much more useful in apprehending the attacker, and stands a much greater chance of being admissible in the event of a prosecution.

証拠収集が正しく行われている場合、それははるかに便利な、攻撃者を逮捕であり、かつ起訴の際に許容さのはるかに大きなチャンスを立っています。

Table of Contents

目次

   1 Introduction.................................................... 2
     1.1 Conventions Used in this Document........................... 2
   2 Guiding Principles during Evidence Collection................... 3
     2.1 Order of Volatility......................................... 4
     2.2 Things to avoid............................................. 4
     2.3 Privacy Considerations...................................... 5
     2.4 Legal Considerations........................................ 5
   3 The Collection Procedure........................................ 6
     3.1 Transparency................................................ 6
     3.2 Collection Steps............................................ 6
   4 The Archiving Procedure......................................... 7
     4.1 Chain of Custody............................................ 7
     4.2 The Archive................................................. 7
   5 Tools you'll need............................................... 7
        
   6 References...................................................... 8
   7 Acknowledgements................................................ 8
   8 Security Considerations......................................... 8
   9 Authors' Addresses.............................................. 9
   10 Full Copyright Statement.......................................10
        

1 Introduction

1はじめに

A "security incident" as defined in [RFC2828] is a security-relevant system event in which the system's security policy is disobeyed or otherwise breached. The purpose of this document is to provide System Administrators with guidelines on the collection and archiving of evidence relevant to such a security incident. It's not our intention to insist that all System Administrators rigidly follow these guidelines every time they have a security incident. Rather, we want to provide guidance on what they should do if they elect to collect and protect information relating to an intrusion.

[RFC2828]で定義されるように、「セキュリティインシデント」とは、システムのセキュリティポリシーが従わなかったか、そうでなければ破られたセキュリティ関連のシステムイベントです。このドキュメントの目的は、このようなセキュリティインシデントに関連する証拠の収集及び保管上のガイドラインにシステム管理者に提供することです。これは、すべてのシステム管理者が厳格にこれらのガイドラインに彼らがセキュリティインシデントを持つたびに従うことを主張するために我々の意図はありません。むしろ、我々は、彼らが侵入に関する情報を収集し、保護することを選択した場合、彼らが何をすべきかについてのガイダンスを提供したいです。

Such collection represents a considerable effort on the part of the System Administrator. Great progress has been made in recent years to speed up the re-installation of the Operating System and to facilitate the reversion of a system to a 'known' state, thus making the 'easy option' even more attractive. Meanwhile little has been done to provide easy ways of archiving evidence (the difficult option). Further, increasing disk and memory capacities and the more widespread use of stealth and cover-your-tracks tactics by attackers have exacerbated the problem.

このようなコレクションは、システム管理者の一部にかなりの努力を表しています。大きな進歩は、オペレーティングシステムの再インストールをスピードアップするため、さらに魅力「簡単なオプション」を作り、「知られている」状態にシステムの復帰を容易にするために、近年で行われています。一方、少しはアーカイブの証拠(困難なオプション)の簡単な方法を提供するために行われました。さらに、攻撃者により、ディスクやメモリ容量を増加し、ステルスのより広範に使用してカバーし、あなたの-トラックを戦術は、問題を悪化させています。

If evidence collection is done correctly, it is much more useful in apprehending the attacker, and stands a much greater chance of being admissible in the event of a prosecution.

証拠収集が正しく行われている場合、それははるかに便利な、攻撃者を逮捕であり、かつ起訴の際に許容さのはるかに大きなチャンスを立っています。

You should use these guidelines as a basis for formulating your site's evidence collection procedures, and should incorporate your site's procedures into your Incident Handling documentation. The guidelines in this document may not be appropriate under all jurisdictions. Once you've formulated your site's evidence collection procedures, you should have law enforcement for your jurisdiction confirm that they're adequate.

あなたは、あなたのサイトの証拠収集手順を策定するための基礎として、これらのガイドラインを使用する必要があり、そしてあなたのインシデントハンドリングドキュメントにあなたのサイトの手順を組み込む必要があります。このドキュメントのガイドラインは、すべての管轄下に適切でないかもしれません。あなたのサイトの証拠収集手続を策定したら、あなたは彼らが十分だと確認し、あなたの管轄のための法執行を持っている必要があります。

1.1 Conventions Used in this Document
この文書で使用されている1.1表記

The key words "REQUIRED", "MUST", "MUST NOT", "SHOULD", "SHOULD NOT", and "MAY" in this document are to be interpreted as described in "Key words for use in RFCs to Indicate Requirement Levels" [RFC2119].

キーワード「REQUIRED」、「MUST」、「MUST NOT」、「SHOULD」、「SHOULD NOT」、要件レベルを示すためにRFCで使用するためのキーワード」で説明したように、この文書に解釈されるべきである「MAY」 "[RFC2119]。

2 Guiding Principles during Evidence Collection

証拠収集の間に2つの指針

      -  Adhere to your site's Security Policy and engage the
         appropriate Incident Handling and Law Enforcement personnel.
        

- Capture as accurate a picture of the system as possible.

- 可能な限りシステムの正確な画像としてキャプチャ。

- Keep detailed notes. These should include dates and times. If possible generate an automatic transcript. (e.g., On Unix systems the 'script' program can be used, however the output file it generates should not be to media that is part of the evidence). Notes and print-outs should be signed and dated.

- 詳細なメモをしてください。これらは、日付と時間を含める必要があります。可能であれば、自動トランスクリプトを生成します。 (例えば、Unixシステムの「スクリプト」プログラムを使用することができ、それが生成するが、出力ファイルは、証拠の一部であるメディアにあってはなりません)。ノートやプリントアウトが署名し、日付を記入しなければなりません。

- Note the difference between the system clock and UTC. For each timestamp provided, indicate whether UTC or local time is used.

- システムクロックとUTCの違いに注意してください。提供される各タイムスタンプについて、UTCまたはローカル時間が使用されているかどうかを示します。

- Be prepared to testify (perhaps years later) outlining all actions you took and at what times. Detailed notes will be vital.

- あなたが取って、何回ですべてのアクションを概説(おそらく数年後の)証言できるように準備してください。詳細なメモが不可欠となります。

- Minimise changes to the data as you are collecting it. This is not limited to content changes; you should avoid updating file or directory access times.

- あなたはそれを集めているように、データへの変更を最小限に抑えます。これは、コンテンツの変更に限定されるものではありません。あなたは、ファイルまたはディレクトリへのアクセス回数を更新することは避けてください。

- Remove external avenues for change.

- 変更のために外部の道を削除します。

- When confronted with a choice between collection and analysis you should do collection first and analysis later.

- 収集と分析の間の選択に直面したとき、あなたは後に最初に収集と分析を行う必要があります。

- Though it hardly needs stating, your procedures should be implementable. As with any aspect of an incident response policy, procedures should be tested to ensure feasibility, particularly in a crisis. If possible procedures should be automated for reasons of speed and accuracy. Be methodical.

- それはほとんど述べる必要はありませんが、あなたの手順が実装可能でなければなりません。インシデント対応方針の任意の態様と同様に、手順は、特に危機に、実現可能性を確実にするために試験されるべきです。可能な手順は、スピードと正確さの理由のために自動化する必要がある場合。系統的う。

- For each device, a methodical approach should be adopted which follows the guidelines laid down in your collection procedure. Speed will often be critical so where there are a number of devices requiring examination it may be appropriate to spread the work among your team to collect the evidence in parallel. However on a single given system collection should be done step by step.

- 各デバイスについて、方法論的なアプローチは、あなたのコレクションの手順に定めガイドラインに従っている採用されなければなりません。スピードがしばしば重要になりますので、検査を必要とするデバイスの数が存在する場合には、並行して証拠を収集するために、あなたのチームの中で仕事を広めるために適切かもしれません。しかし、単一の指定されたシステム収集には段階的に行われるべきです。

- Proceed from the volatile to the less volatile (see the Order of Volatility below).

- (下のボラティリティの順序を参照)低揮発性の揮発性から進みます。

- You should make a bit-level copy of the system's media. If you wish to do forensics analysis you should make a bit-level copy of your evidence copy for that purpose, as your analysis will almost certainly alter file access times. Avoid doing forensics on the evidence copy.

- あなたは、システムのメディアのビットレベルのコピーを作成する必要があります。あなたはフォレンジック分析を行いたい場合は、あなたの分析はほぼ確実に、ファイルアクセス時間を変えてしまうようあなたは、その目的のために、あなたの証拠のコピーのビットレベルのコピーを作成する必要があります。証拠のコピーでフォレンジックをやって避けてください。

2.1 Order of Volatility
ボラティリティの2.1注文

When collecting evidence you should proceed from the volatile to the less volatile. Here is an example order of volatility for a typical system.

証拠を収集するときは、揮発性の低いに揮発性から進めるべき。ここで典型的なシステムのための揮発性の一例の順序です。

- registers, cache

- レジスタ、キャッシュ

- routing table, arp cache, process table, kernel statistics, memory

- ルーティングテーブル、arpキャッシュ、プロセステーブル、カーネル統計、メモリ

- temporary file systems

- 一時的なファイルシステム

- disk

- ディスク

- remote logging and monitoring data that is relevant to the system in question

- 問題のシステムに関連する遠隔ロギングと監視データ

- physical configuration, network topology

- 物理構成、ネットワークトポロジ

- archival media

- アーカイブメディア

2.2 Things to avoid
回避するために、2.2物事

It's all too easy to destroy evidence, however inadvertently.

しかし、誤って、証拠を破壊するために、すべてあまりにも簡単です。

- Don't shutdown until you've completed evidence collection. Much evidence may be lost and the attacker may have altered the startup/shutdown scripts/services to destroy evidence.

- あなたは証拠収集を完了するまでないシャットダウンを実行してください。多くの証拠が失われ、攻撃者が証拠を破壊するために、起動/シャットダウンスクリプト/サービスを変更している場合があります。

- Don't trust the programs on the system. Run your evidence gathering programs from appropriately protected media (see below).

- システム上のプログラムを信用してはいけません。あなたの証拠が適切に保護されたメディアからプログラムを集めて実行します(下記参照)。

- Don't run programs that modify the access time of all files on the system (e.g., 'tar' or 'xcopy').

- システム(例えば、「タール」や「XCOPY」)上のすべてのファイルのアクセス時刻を変更するプログラムを実行しないでください。

- When removing external avenues for change note that simply disconnecting or filtering from the network may trigger "deadman switches" that detect when they're off the net and wipe evidence.

- 単純に切断したり、彼らがネットオフにしているとの証拠を拭くときに検出「デッドマンスイッチ」を引き起こす可能性がネットワークからフィルタリング変更ノートの外部の道を取り外すとき。

2.3 Privacy Considerations
2.3プライバシーの考慮事項
      -  Respect the privacy rules and guidelines of your company and
         your legal jurisdiction.  In particular, make sure no
         information collected along with the evidence you are searching
         for is available to anyone who would not normally have access
         to this information.  This includes access to log files (which
         may reveal patterns of user behaviour) as well as personal data
         files.
        

- Do not intrude on people's privacy without strong justification. In particular, do not collect information from areas you do not normally have reason to access (such as personal file stores) unless you have sufficient indication that there is a real incident.

- 強い正当化することなく、人々のプライバシーを侵害しないでください。特に、あなたは本当の事件があるという十分な兆候を持っていない限り、あなたは通常(パーソナルファイルストアなど)にアクセスする理由を持っていない領域から情報を収集することはありません。

- Make sure you have the backing of your company's established procedures in taking the steps you do to collect evidence of an incident.

- あなたは事件の証拠を収集するために行う措置を講じにおける会社の設立手続きのバッキングを持っていることを確認してください。

2.4 Legal Considerations
2.4法的留意事項

Computer evidence needs to be

コンピュータの証拠があることが必要

- Admissible: It must conform to certain legal rules before it can be put before a court.

- 許容:それは裁判所の前に置くことができる前に、それは特定の法的ルールに従わなければなりません。

- Authentic: It must be possible to positively tie evidentiary material to the incident.

- 本物:正に入射する証拠材料を結びつけることが可能でなければなりません。

- Complete: It must tell the whole story and not just a particular perspective.

- コンプリート:それは全体の話だけではなく、特定の視点を伝える必要があります。

- Reliable: There must be nothing about how the evidence was collected and subsequently handled that casts doubt about its authenticity and veracity.

- 信頼性:証拠を収集し、その後、その真正性と信憑性に疑問を投げかけるように扱われたかについては何があってはいけません。

- Believable: It must be readily believable and understandable by a court.

- 信じられない:それは、裁判所によって容易に信じられないと理解しなければなりません。

3 The Collection Procedure

3収集手順

Your collection procedures should be as detailed as possible. As is the case with your overall Incident Handling procedures, they should be unambiguous, and should minimise the amount of decision-making needed during the collection process.

あなたの収集手順は、可能な限り詳細にする必要があります。あなたの全体的なインシデントハンドリング手順と同様に、彼らは明確なべきである、と収集プロセスの間に必要な意思決定の量を最小限に抑える必要があります。

3.1 Transparency
3.1透明性

The methods used to collect evidence should be transparent and reproducible. You should be prepared to reproduce precisely the methods you used, and have those methods tested by independent experts.

証拠を収集するために使用される方法は、透明性と再現性でなければなりません。あなたは正確にあなたが使用した方法を再現するために準備、および独立した専門家によってテストされ、それらのメソッドを持っている必要があります。

3.2 Collection Steps
3.2コレクション手順
      -  Where is the evidence?  List what systems were involved in the
         incident and from which evidence will be collected.
        

- Establish what is likely to be relevant and admissible. When in doubt err on the side of collecting too much rather than not enough.

- 関連すると容認する可能性があるものを確立します。疑問にすぎなく、十分ではありませんを集めるのに越した場合。

- For each system, obtain the relevant order of volatility.

- 各システムについて、ボラティリティの関連する順序を得ます。

- Remove external avenues for change.

- 変更のために外部の道を削除します。

- Following the order of volatility, collect the evidence with tools as discussed in Section 5.

- 第5節で述べたように、揮発性の順に続いて、ツールとの証拠を収集します。

- Record the extent of the system's clock drift.

- システムのクロックドリフトの範囲を記録します。

- Question what else may be evidence as you work through the collection steps.

- あなたは、収集の手順を介して動作として証拠とすることができる他に何の質問。

- Document each step.

- 各ステップ文献。

- Don't forget the people involved. Make notes of who was there and what were they doing, what they observed and how they reacted.

- 関係者を忘れないでください。あったと、彼らは、彼らが観察何、何をやっていたし、それらがどのように反応した人の注意事項を確認します。

Where feasible you should consider generating checksums and cryptographically signing the collected evidence, as this may make it easier to preserve a strong chain of evidence. In doing so you must not alter the evidence.

可能であれば、あなたがチェックサムを生成し、これはそれが簡単に証拠の強いチェーンを維持するために行うことができるよう、暗号、収集した証拠に署名検討すべきです。そうすることで、あなたは、証拠を変更してはいけません。

4 The Archiving Procedure

4アーカイブ手順

Evidence must be strictly secured. In addition, the Chain of Custody needs to be clearly documented.

証拠は、厳密に確保する必要があります。また、CoCのは、明確に文書化する必要があります。

4.1 Chain of Custody
カストディの4.1チェーン

You should be able to clearly describe how the evidence was found, how it was handled and everything that happened to it.

あなたは明確な証拠は、それが処理されたか、発見された方法を説明し、それに起こったことすべてすることができるはずです。

The following need to be documented

文書化するには、次の必要性

- Where, when, and by whom was the evidence discovered and collected.

- どこで、いつ、誰によって、証拠が発見し、収集しました。

- Where, when and by whom was the evidence handled or examined.

- どこで、誰によって、証拠を取り扱うかを検討したとき。

- Who had custody of the evidence, during what period. How was it stored.

- 誰が何の期間中に、証拠の親権を持っていました。それはどのように保存しました。

- When the evidence changed custody, when and how did the transfer occur (include shipping numbers, etc.).

- 場合は証拠がいつ、どのように転送が発生しなかったが、親権を変更(出荷番号などが含まれます)。

4.2 Where and how to Archive
4.2とどのようにアーカイブするには

If possible commonly used media (rather than some obscure storage media) should be used for archiving.

一般的に使用される可能メディア(というよりも、いくつかのあいまいな記憶媒体)アーカイブに使用する必要がある場合。

Access to evidence should be extremely restricted, and should be clearly documented. It should be possible to detect unauthorised access.

証拠へのアクセスは非常に制限されなければならない、と明確に文書化されなければなりません。不正アクセスを検出することが可能でなければなりません。

5 Tools you'll need

あなたが必要とする5つのツール

You should have the programs you need to do evidence collection and forensics on read-only media (e.g., a CD). You should have prepared such a set of tools for each of the Operating Systems that you manage in advance of having to use it.

あなたが(例えば、CD)読み取り専用メディア上の証拠収集やフォレンジックを行うために必要なプログラムを持っている必要があります。あなたは、あなたがそれを使用することを事前に管理されているオペレーティングシステムのそれぞれのためのツールのようなセットを用意している必要があります。

Your set of tools should include the following:

ツールのあなたのセットには、以下を含める必要があります。

- a program for examining processes (e.g., 'ps').

- プロセスを検査するためのプログラム(例えば、「PS」)。

- programs for examining system state (e.g., 'showrev', 'ifconfig', 'netstat', 'arp').

- システムの状態(例えば、 'のshowrev'、 'ifconfigコマンド'、 'netstatの'、 'ARP')を検査するためのプログラム。

- a program for doing bit-to-bit copies (e.g., 'dd', 'SafeBack').

- ビット対ビットのコピーを行うためのプログラム(例えば、「SafeBack」「D」)。

- programs for generating checksums and signatures (e.g., 'sha1sum', a checksum-enabled 'dd', 'SafeBack', 'pgp').

- チェックサムと署名を生成するためのプログラム(例えば、 'SHA1SUM'、チェックサムが有効 'DD'、 'SafeBack'、 'PGP')。

- programs for generating core images and for examining them (e.g., 'gcore', 'gdb').

- コアの画像を生成するため、それらを検査するためのプログラム(例えば、「のgcore」、「GDB」)。

- scripts to automate evidence collection (e.g., The Coroner's Toolkit [FAR1999]).

- スクリプトは、証拠収集を自動化する(例えば検死官のツールキット[FAR1999])。

The programs in your set of tools should be statically linked, and should not require the use of any libraries other than those on the read-only media. Even then, since modern rootkits may be installed through loadable kernel modules, you should consider that your tools might not be giving you a full picture of the system.

ツールのあなたのセットの中のプログラムは、静的にリンクされている必要があり、かつ読み取り専用メディア上のもの以外の任意のライブラリを使用する必要はないはずです。現代のルートキットは、ローダブルカーネルモジュールを介してインストールすることができるので、この場合でも、あなたはあなたのツールがあなたのシステムの全体像を与えていない可能性がありますことを検討すべきです。

You should be prepared to testify to the authenticity and reliability of the tools that you use.

あなたが使用するツールの信憑性と信頼性を証明するために準備する必要があります。

6 References

6つの参考文献

[FAR1999] Farmer, D., and W Venema, "Computer Forensics Analysis Class Handouts", http://www.fish.com/forensics/

[FAR1999]ファーマー、D.、およびW Venema氏、 "コンピュータフォレンジック分析クラス配布資料"、http://www.fish.com/forensics/

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。

[RFC2196] Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997.

[RFC2196]フレイザー、B.、 "サイトセキュリティハンドブック"、FYI 8、RFC 2196、1997年9月。

[RFC2350] Brownlee, N. and E. Guttman, "Expectations for Computer Security Incident Response", FYI 8, RFC 2350, June 1998.

[RFC2350]ブラウンリー、N.とE.グットマン、FYI 8、RFC 2350、1998年6月 "コンピュータセキュリティインシデント対応への期待"。

[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC 2828, May 2000.

[RFC2828] Shirey、R.、 "インターネットセキュリティ用語集"、FYI 36、RFC 2828、2000年5月。

7 Acknowledgements

7つの謝辞

We gratefully acknowledge the constructive comments received from Harald Alvestrand, Byron Collie, Barbara Y. Fraser, Gordon Lennox, Andrew Rees, Steve Romig and Floyd Short.

我々は感謝しハラルドAlvestrand、バイロンコリー、バーバラY.フレイザー、ゴードン・レノックス、アンドリューリース、スティーブ・ローミッグとフロイドショートから受信した建設的なコメントを認めます。

8 Security Considerations

8セキュリティについての考慮事項

This entire document discuses security issues.

この全体のドキュメントは、セキュリティ上の問題をdiscuses。

9 Authors' Addresses

9本の著者のアドレス

Dominique Brezinski In-Q-Tel 1000 Wilson Blvd., Ste. 2900 Arlington, VA 22209 USA

ドミニクBrezinskiのIn-Q-電話1000年ウィルソン大通り、サント。 2900アーリントン、VA 22209 USA

EMail: dbrezinski@In-Q-Tel.org

メールアドレス:dbrezinski@In-Q-Tel.org

Tom Killalea Lisi/n na Bro/n Be/al A/tha na Muice Co. Mhaigh Eo IRELAND

トムKillaleaリージ/ Nブロ/ Nと/アルA /ある豚株式会社メイヨーアイルランド

Phone: +1 206 266-2196 EMail: tomk@neart.org

電話:+1 206 266-2196 Eメール:tomk@neart.org

10. Full Copyright Statement
10.完全な著作権声明

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

著作権(C)インターネット協会(2002)。全著作権所有。

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機能のための基金は現在、インターネット協会によって提供されます。