$Id: rfc3013-ja.txt,v 1.1 2000/12/25 15:24:03 true Exp true $ Network Working Group T. Killalea Request for Comments: 3013 neart.org BCP: 46 November 2000 Category: 現時点における最良の方法 インターネットサービスプロバイダにおけるセキュリティー業務および手順勧告 本文書の位置づけ 本文章はインターネットコミュニティに対するインターネットの現時点にお ける最良の方法を示し、改善のための議論や提案を求めている。本文章の配 布は制限されない。 著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 要約 本文書の目的はIETFに代表されるようなエンジニアリングコミュニティが セキュリティにおいてインターネットサービスプロバイダ(ISP)に何を求めて いるかを表明することである。 本文書にすべてのISPに対して妥当だと思われる必要条件群を定義する意図は ないが、むしろISPの間に注意を喚起することをコミュニティは期待しており、 現在および将来のサービスプロバイダに対して求められるセキュリティに関 する議論の枠組みをコミュニティに提供する。 Killalea Best Current Practice [Page 1] RFC 3013 Recommended ISP Security November 2000 目次 1 はじめに . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 1.1 本文章の中で使用される協定キーワード . . . . . . . . . . . . 3 2 連絡 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.1 連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2.2 情報共有 . . . . . . . . . . . . . . . . . . . . . . . . . . 4 2.3 安全な連絡手段 . . . . . . . . . . . . . . . . . . . . . . . 4 2.4 脆弱の通知および事故の報告 . . . . . . . . . . . . . . . . . 4 2.5 事件対応およびコンピューターセキュリティ対処チーム(CSIRTs) . 5 3 利用規約 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1 方針の発表 . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.2 罰則規定 . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3.3 データ保護 . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 ネットワークインフラストラクチャ . . . . . . . . . . . . . . . . 6 4.1 レジストリデータ管理 . . . . . . . . . . . . . . . . . . . . 6 4.2 ルーティングインフラストラクチャ . . . . . . . . . . . . . . 7 4.3 ソースアドレスの入方向フィルタリング . . . . . . . . . . . . 7 4.4 ソースアドレスの出方向フィルタリング . . . . . . . . . . . . 8 4.5 経路フィルタリング . . . . . . . . . . . . . . . . . . . . . 8 4.6 指向性ブロードキャスト . . . . . . . . . . . . . . . . . . . 8 5 システムインフラストラクチャ . . . . . . . . . . . . . . . . . . 9 5.1 システム管理 . . . . . . . . . . . . . . . . . . . . . . . . 9 5.2 トランジットネットワーク上のシステム設置禁止 . . . . . . . . 9 5.3 オープンメール中継 . . . . . . . . . . . . . . . . . . . . . 9 5.4 メッセージ送信 . . . . . . . . . . . . . . . . . . . . . . . 9 6 参考文献 . . . . . . . . . . . . . . . . . . . . . . . . . . . .10 7 謝辞 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .12 8 セキュリティに関する考察 . . . . . . . . . . . . . . . . . . . .12 9 著者連絡先 . . . . . . . . . . . . . . . . . . . . . . . . . . .12 10 完全な著作権表示 . . . . . . . . . . . . . . . . . . . . . . .13 1 はじめに 本文書の目的はIETFに代表されるようなエンジニアリングコミュニティがセ キュリティにおいてインターネットサービスプロバイダ(ISP)に何を求めてい るかを表明することである。本文書はISPへの提言である。 このコミュニティが何を望み、期待しているかをISPに伝えることにより、コ ミュニティはISPがセキュリティを優先するだけでなく、サービスを提供する にあたりセキュリティを誇りにできるような結果を期待する。 本文書には商慣習を押し付ける意図は一切ない。 Killalea Best Current Practice [Page 2] RFC 3013 Recommended ISP Security November 2000 本文書でISPに定義の含まれるものは、インターネット接続サービスあるいは その他のインターネットサービスを提供する商業組織であるが、Webホスティ ングサービス、コンテンツプロバイダ、E-mailサービスなどに限定しない。 ISPの定義は自組織のみにサービスを提供する組織を含まない。 本文書はどのようなセキュリティおよび攻撃管理分類についてサポートすべ きかに関し、一通り勧告するためにISPに提示している。また、利用者に対し ては高品質のISPに期待すべきことを助言できる。これは自身の権利として 規範的には認識されていないが、いずれは時流に乗るだろう。また他の期待 が寄せられるかもしれない。しかしそれは、インターネットとその技術の開 発中の分野において、プロフェッショナルを推薦することのほんの一場面で しかない。 1.1 本文章の中で使用される協定キーワード 本文章中の「要求される(REQUIRED)」、「しなければならない(MUST)」、 「してはならない(MUST NOT)」、「したほうがよい(SHOULD)」「しないほうが よい(SHOULD NOT)」および「してもよい(MAY)」は「RFC中で用いられる要求 レベルを示すキーワード」[RFC2119]に記述されているとおりに解釈すること。 2 連絡 コミュニティがセキュリティに関してISPに最も望むことは、セキュリティ上 の事件に対処する際の連絡手段の存在である。 2.1 連絡先 ISPはネットワークセキュリティ問題用に「SECURITY」、不適切な公的活動用 に「ABUSE」、ネットワークインフラに関連する問題に「NOC」の各メールボッ クスを設置し、特定のサービスに関連する質問や報告を受けるために追加の メールボックスの設置を定めている[RFC2142]の定義を固守したほうがよい (SHOULD)。 ISPは上記の詳細について、共通URLの利用を検討してもよい。 (例: http://www.ISP-name-here.ne.jp/security/) さらに、ISPは確実にWhois、ルーティングレジストリ[RFC1786]、その他ネッ トワーク情報貯蔵データベースにある連絡先情報を、完全かつ正確で、連絡 がつく状態にしておく義務がある。 Killalea Best Current Practice [Page 3] RFC 3013 Recommended ISP Security November 2000 2.2 情報共有 ISPは顧客や他のISP、コンピューターセキュリティ対処センター(Incident Response Teams)、当局、マスメディア、一般社会とセキュリティ事件に関す る情報共有についての、明確な方針とマニュアルを策定したほうがよい (SHOULD)。 ISPは他のISPとまたがったセキュリティ事件に対処するため、適切な対処を 行うべきである。 2.3 安全な連絡手段 ISPは安全な連絡手段を用いて連絡を行えるようにしたほうがよい(SHOULD)。 ただし、いくつかの国や地域においては安全な連絡方法の利用が許可されて いない可能性があるので、注意してほしい。 2.4 脆弱の通知および事故の報告 ISPは、提供するサービスにおけるセキュリティ上の脆弱性を率先して顧客に 通知したほうがよい(SHOULD)。さらに、システムとソフトウェアにおいて新 たな脆弱性が発見された際には、ISPは提供しているサービスが危険な影響を 受けるかを示すべきである。 ISPのインフラスストラクチャに影響するセキュリティ上の事件が発生した際 には、ISPは迅速に顧客に通知するべきである。 - 事件対応と調整を誰が行うのか - 脆弱性 - どのサービスが影響を受けるのか - 事件にどう対処したか - 顧客情報が危険にさらされたかどうか - どのようにして脆弱性に対処したか - 対応予想スケジュールは、計画どおりだったか 多くのISPには、顧客に停電およびサービス停止を通知する体制を確立した。 ISPがセキュリティ関連の事件の報告のために、これらの連絡方法を利用する のは妥当である。その場合、顧客のセキュリティ担当ではない人が通知を受 ける可能性がある。より正確に言えば、通常の担当者が報告を受けるだろう。 顧客が報告を適切に認識するような態勢を整えることが望ましい。 Killalea Best Current Practice [Page 4] RFC 3013 Recommended ISP Security November 2000 2.5 事件対応およびコンピューターセキュリティ対処チーム(CSIRT) コンピューターセキュリティ対処チーム(CSIRT: Computer Security Incident Response Team)は、定義された構成員のサイトを含むセキュリティ 上の事件に関して対応、調整、支援するチームです。インターネットコミュ ニティにおけるCSIRTへの期待は「コンピューターセキュリティ対処チーム (CSIRT)への期待」[RFC2350]に記述されています。 ISPにおけるCSIRTの有無に関係なく、周知徹底された顧客から報告を受けた 事件を受け、対処する態勢を整備すべきである。さらに、いかなるCSIRTも、 報告に対する対応方法を明確に文章化し、構成員に顧客を含められるか、誰 に対しては事件を報告してよいのかを明示すべきである。 一部のISPはCSIRTを有している。しかし顧客として接続している、もしくは 攻撃を行っているサイトを顧客としているISPのCSIRTサービスを自動的に利 用できると想定してはならない。ISPのCSIRTは、追加費用を要するサービス として頻繁に、チームは事件対処サービスを(おそらく有償で)契約した構成 員のみに限定して提供している。 従って、ISPが顧客に提供する事件対応とセキュリティリソースについて文書 化しておくことが重要である。その結果、顧客は事件が発生する「事前に」、 事故時対応の段階的拡大の連鎖状態を定義できる。。 顧客は契約ISPにCSIRTがあるかを確認し、CSIRTがある場合にはCSIRTの憲章、 ポリシー、サービスも確認するべきである。これに関しては「コンピューター セキュリティ対処チーム(CSIRT)への期待」[RFC2350]の付録Dに詳しい。 3. 利用規約 すべてのISPはネットワークの利用形態を規定する利用規約(AUP)を制定した ほうがよい(SHOULD)。 顧客とISPがインターネット接続の契約を結ぶ際には、AUPに従って契約を決 定すべきである。AUPは契約更新ごとに検討する方がよく、ISPが方針を更新 する際には、顧客に対して事前に通知することが望ましい。 Killalea Best Current Practice [Page 5] RFC 3013 Recommended ISP Security November 2000 AUPは、顧客に対しネットワーク上で許可されるトラフィックの種類も含め、 システムまたはネットワーク上で何が認められ、何が認められないというこ とを明確に確認するべきである。AUPの表現は誤解や曖昧さを排し、できるだ け明確に表現すべきである。たとえば、AUPはIPアドレスなりすまし攻撃を禁 止すべきである。 3.1 方針の発表 ISPは顧客にAUPを連絡するだけでなく、方針をWebサイトのような公開の場で 公表し、コミュニティ全体が不適切な行為の場合に対してどういった対応が 適切なのか確認できるようにすべきである。 3.2 罰則規定 AUPは不適切な利用行為が行われた場合の罰則を明示すべきである。 3.3 データ保護 多くの国や地域においてデータ保護に関する法整備が行われている。ISPが有 する個人情報の取り扱いを考慮するべきであるし、必要ならISP自身がデータ 保持者として法律に従った利用法のみでデータを利用する用意を行うべきで ある。そのような法律(例: [DPR1998])の存在しないグローバルな環境である インターネットに位置するISP、少なくとも、データの保護に対応する必要が ある。 4 ネットワークインフラストラクチャ ISPには以下のようなネットワークインフラの管理に責任がある。 - 既知のセキュリティ上の脆弱性に対する合理的な対策 - 乗っ取った攻撃者によって引き起こされる攻撃の阻止 4.1 レジストリデータ管理 ISPは一般に、インターネットルーティングレジストリ(IRR)やAPNIC、ARINや RIPEデータベースといった世界的なネットワーク情報貯蔵データベースに格 納されているデータの保守責任がある。このデータの更新には強力な認証機 構を利用すべきである。 ISPは、顧客に割り当てたアドレス空間の明確な連絡先を公的に登録すべきで ある。 Killalea Best Current Practice [Page 6] RFC 3013 Recommended ISP Security November 2000 4.2 ルーティングインフラストラクチャ ISPの正確な宛先へトラフィックを経路制御する性能はルーティングレジスト リ[RFC1786]に設定されたルーティングポリシーに依存する。その場合、レジ ストリが対応しているなら、レジストリ情報を保守する際に強力な認証機構 を必ず用いて更新し、更新権限が適切に管理されるようにすべきである。 ルーティング告知において、宛先までの有効な経路を選択する際により信頼 のおける決定に注意を払うべきである。過去に捏造された告知の結果、トラ フィックがブラックホールに吸収されてしまったり、最悪の場合乗っ取られ た事例がある。 ルーティングピアの際には、BGP認証[RFC2385]を利用したほうがよい(SHOULD)。 4.3 ソースアドレスの入方向フィルタリング フィルタリングの方向は末端サイト(顧客)からインターネットである。 攻撃者はしばしば偽のソースアドレスにより証拠を捏造します。攻撃者のサ イトから注意をそらすために、一般に無関係な遠隔サイトや、実際はプライ ベートインターネット用として割り振られたアドレス[RFC1918]をソースアド レスとして装う。さらに、捏造されたアドレスはホスト間の信頼関係を攻略 する目的で、しばしば成りすましに基づく攻撃に利用される。 顧客が捏造されたソースアドレスによる攻撃にさらされる状況を軽減するた め、ISPは以下の対策を講じるべきである。各顧客との境界ルータにおいて、 顧客に割り当てたアドレスのソースアドレス以外の何らかのソースアドレス を持つトラフィックを積極的にすべてフィルタすべきである。この話題に関 するより詳しい考察は[RFC2827]を参照されたい。 (まれに)現在のところ入方向フィルタリングをできない状況が存在する。例 えば大規模な集合ルーターの場合、パケットフィルタによって更なる負荷を かけることは不可能である。さらに、このようなフィルタリングはモバイル 利用者に困難を引き起こすことがある。従ってなりすましを防ぐこの方法の 使用が強く推奨されるものの、必ずしも全ての場合に実現できるとは限らな い。 こういった顧客とISPの間のインターフェイスで入方向フィルタリングが不可 能な稀なケースの場合においては、顧客はネットワーク内で入方向フィルタ リングを実施することが推奨される。一般に、フィルタリングは実際のホス トに可能な限り近いところで行うべきである。 Killalea Best Current Practice [Page 7] RFC 3013 Recommended ISP Security November 2000 4.4 ソースアドレスの出方向フィルタリング フィルタリングの方向はインターネットから末端サイト(顧客)である。 今日,インターネットで広く使われている多くのアプリケーションは外部ホス トの認証にIPアドレスだけを利用している(例: バークレーによる「R」コマ ンド群)。これらは[CA-95.01.IP.spoofing]で説明されているとおり、IP偽造 の影響を受けやすい。さらに、[CA-97.28.Teardrop_Land]で説明されている 「land」攻撃など、ローカルアドレスの悪用に影響を受ける潜在的な脆弱性 が存在する。 顧客が捏造されたソースアドレスによる攻撃にさらされる状況を軽減するた め、ISPは以下の対策を講じるべきである。各顧客との境界ルータにおいては ソースアドレスに顧客に割り当てられたアドレスを持つ顧客宛てのトラフィッ クを積極的にすべてフィルタすべきである。 4.3 章の入方向フィルタリングが不可能な場合において説明した環境は、出 方向フィルタリングにも同様に適用可能である。 4.5 経路フィルタリング 過剰なルーティング更新は攻撃者にサービス不能攻撃を引き起こす手段として 悪用されうる。過小評価したとしても、結果的には性能低下をもたらす。 たとえばプライベートアドレスへの経路を無視するようにしたり、捏造され た経路を無効にし"BGP経路フラップ減衰"[RFC2439]やアグリゲーションポリ シーを実装するために、ISPは受け取ったルーティング告知をフィルタすべ きである。 ISPはルーティングの過剰な負荷のリスクを軽減する方法を実装すべきであ る。これらは「釘付けされた」経路、攻撃的アグリゲーションと経路減衰、 などを含み、これら全て内部経路の変更は他への影響は低いが、ある意味 ではそれらに適切でない。 4.6 指向性ブロードキャスト IPプロトコルは、ネットワークを介してパケットを特定のサブネット上のブ ロードキャストに送る指向性ブロードキャストを許容している。この機能は 役立つ場面は少ないものの、様々なセキュリティ攻撃に悪用される。(元来 サービス不能(DoS)攻撃はブロードキャストのパケット増殖効果を悪用する) 従って、ブロードキャスト媒体に接続しているルータでは、指向性ブロード キャストを受け付ける設定をしてはならない(MUST NOT) [RFC2644]。 Killalea Best Current Practice [Page 8] RFC 3013 Recommended ISP Security November 2000 5 システムインフラストラクチャ ISPがそのシステムを管理する方法によって、ネットワークのセキュリティお よび信頼性が決まる。システムの欠陥はパフォーマンスや機能の低下をもた らすことは少ないかもしれないが、データ損失もしくは通信傍受の危険に繋 がる。(このようにして「man-in-the-middle」攻撃に結びつく) 異なるサービス（電子メール、ネットニュース、Webホスティングなど）が、 個別のシステム上で運用される場合、より簡単に安全なシステムを構築でき ることが広く知られている。 5.1 システム管理 電子メール、ネットニュース、Webホスティングといった重要なISP機能は各 サービスの管理者にのみアクセスが許されるように限定すべきである。また、 そのアクセスは強力な認証後に認めるべきであり、通信を暗号化することが 望ましい。ISPのシステムネットワーク外からは、サービスを行うポートにの み接続できるようにすべきである。 ISPはより安全な方法が利用可能になり次第、最新のサービスを提供すべきで す。（例:「シンプルチャレンジ＆レスポンスを利用したIMAP/POP拡張認証」、 [RFC2195] ） 5.2 トランジットネットワーク上のシステム設置禁止 (訳注:バックボーン回線が接続されている)トランジットネットワークセグメ ント上には、システムを設置すべきでない。 5.3 オープンメール中継 ISPは、メールシステムが発信者の情報を隠しつつ、頼みもしないのに勝手に 送りつけられる大量の電子メール(UBE)を送付する「スパマー」による悪用さ れることを防止するため、積極的な手段を取るべきである[RFC2505]。これら の予防策が必ずしも全てのサイトにとって有効であるわけではないが、各サ イトにとって最も効果的な方法を用いるべきである。 ISPは併せて、顧客に対してもシステム上でこのような行為が行われないよう、 必要な策を講じるように強く呼びかけるべきである。 5.4 メッセージ送信 メッセージの送信の際には「認証用のSMTPサービス拡張」[RFC2554] におい て説明されているAUTH SMTPサービスを利用して認証すべきである。 Killalea Best Current Practice [Page 9] RFC 3013 Recommended ISP Security November 2000 SMTP AUTHは、ISPの利用者がそのISPのネットワーク以外を利用中（例えば、 仕事をしている間など）であってもメールを送信できるなどの柔軟性を備え、 なりすましに強く、新しい認証方式にいち早く対応できるなど、IPアドレス ベースでのメール送信制限よりも好ましい方法である。 さらに、セキュリティポリシーの施行促進ために、メッセージ送信の際には SMTP(25番)ポートを用いるのでなく、「メッセージ送信」[RFC2476] におい て検討されたMAIL SUBMIT(587番)ポートの利用を強く推奨する。この場合、 SMTP(25番)ポートはローカル向け配送にのみ利用する。 このように推奨するのは、ローカル向け配送と外部への中継（すなわち利用 者がインターネット上の任意のホストに対して、ISPのSMTPサービスを用いて メールを送信すること）を区別できるためである。SMTP AUTHで認証されてい ない接続に対しては、ローカルへの配送のみを許可すべきだ。 最近ではより多くのメールソフトがSMTP AUTHやメッセージ送信用ポート(明示 的、もしくはSMTPポートの設定ができるかのいずれか)の両者に対応しており、 ISPは顧客が送信用ポートおよびSMTP AUTHの両方を利用し、メッセージを送信 できる状態が必要とされることを認識すべきである。つまり、25番ポートでは メール受け取りのみを許可することである。 これらの手法（SMTP AUTH や送信・ポート）は、第三者中継においてISPが UBEの送信元になる事態を防止するだけでなく、逆に利用者がUBEを送るよう な状況となった場合でも、その責任を追及しやすくできる。 6 参考文献 [CA-95.01.IP.spoofing] 「IPなりすまし攻撃とターミナル接続乗っ取り」 "IP Spoofing Attacks and Hijacked Terminal Connections", ftp://info.cert.org/pub/cert_advisories/ [CA-97.28.Teardrop_Land]「IPサービス否認攻撃」 "IP Denial-of-Service Attacks", ftp://info.cert.org/pub/cert_advisories/ [DPR1998] 英国「1998年データ保護法(29章)」 The UK "Data Protection Act 1998 (c. 29)", http://www.hmso.gov.uk/acts/acts1998/ 19980029.htm [RFC1786] 「ルーティング・レジストリ(ripe-81++)における IPルーティング・ポリシの表現」 Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., Karrenberg, D., Terpstra, M. and J. Yu, "Representation of IP Routing Policies in a Routing Registry (ripe-81++)", RFC 1786, March 1995. Killalea Best Current Practice [Page 10] RFC 3013 Recommended ISP Security November 2000 [RFC1834] 「Whoisおよびネットワーク情報の検索サービス」 Gargano, J. and K. Weiss, "Whois and Network Information Lookup Service", RFC 1834, August 1995. [RFC1835] 「WHOIS++サービスのアーキテクチャ」 Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider, "Architecture of the WHOIS++ service", RFC 1835, August 1995. [RFC1918] 「プライベートネットワークのためのアドレス割り当て」 Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J. and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] 「RFC中で用いられる要求レベルを示すキーワード」 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2142] 「共通サービス、役割、機能のためのメールボックス名」 Crocker, D., "Mailbox Names for Common Services, Roles and Functions", RFC 2142, May 1997. [RFC2195] 「シンプルチャレンジ＆レスポンスを利用した IMAP/POP拡張認証」 Klensin, J., Catoe, R. and P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", RFC 2195, September 1997. [RFC2196] 「サイトセキュリティ・ハンドブック」 Fraser, B., "Site Security Handbook", FYI 8, RFC 2196, September 1997. [RFC2350] 「CSIR(コンピューターセキュリティ対処センター) への期待」 Brownlee, N. and E. Guttman, "Expectations for Computer Security Incident Response", BCP 21, RFC 2350, June 1998. [RFC2385] 「TCP MD5署名オプションによるBGPセッション保護」 Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2439] 「BGPルートフラップ減衰」 Chandra R., Govindan R. and C. Villamizar, "BGP Route Flap Damping", RFC 2439, November 1998. [RFC2476] 「メッセージ送信」 Gellens R. and J. Klensin, "Message Submission", RFC 2476, December 1998. [RFC2505] 「SMTP MTA向けスパム防止推奨事項」 Lindberg, G., "Anti-Spam Recommendations for SMTP MTAs", BCP 30, RFC 2505, February 1999. Killalea Best Current Practice [Page 11] RFC 3013 Recommended ISP Security November 2000 [RFC2554] 「認証用のSMTPサービス拡張」 Myers, J., "SMTP Service Extension for Authentication", RFC 2554, March 1999. [RFC2644] 「ルータにおける指向性ブロードキャスト用の デフォルトの変更」 Senie, D., "Changing the Default for Directed Broadcasts in Routers", BCP 34, RFC 2644, August 1999. [RFC2827] 「ネットワーク入方向フィルタリング：ソースIP アドレスなりすましによるサービス攻撃拒否」 Ferguson, P. and D. Senie, "Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing", BCP 38, RFC 2827, May 2000. 7 謝辞 以下の各氏より寄せられた建設的なコメントに感謝する。 Nevil Brownlee, Randy Bush, Bill Cheswick, Barbara Y. Fraser, Randall Gellens, Erik Guttman, Larry J. Hughes Jr., Klaus-Peter Kossakowski, Michael A. Patton, Don Stikvoort and Bill Woodcock. 8 セキュリティに関する考察 本文章全体に渡り、セキュリティに関する問題が検討されている。 9 著者連絡先 Tom Killalea Lisi/n na Bro/n Be/al A/tha na Muice Co. Mhaigh Eo IRELAND Phone: +1 206 266-2196 EMail: tomk@neart.org 翻訳者連絡先(*訳注) 神奈川県藤沢市遠藤5322 慶應義塾大学 村井研究室 学部1年有志(RG-00) 白畑真、工藤 紀篤、三島 和宏、柴田 巧 Phone: +81 466 47 5111 ext 3330 EMail: true@sfc.wide.ad.jp, kudo@sfc.wide.ad.jp, three@sfc.wide.ad.jp, takumi@sfc.wide.ad.jp * この翻訳の誤りや、より分かりやすい翻訳などがありましたら、 どんなことでも rg-00@sfc.wide.ad.jp までご連絡ください。 Killalea Best Current Practice [Page 12] RFC 3013 Recommended ISP Security November 2000 10 完全な著作権表示 Copyright (C) The Internet Society (2000). All Rights Reserved. 本文章とその翻訳は、複製および他への提供ができる。また本文書にコメン トや説明を加えたりその実装を補助する派生的な著作物は、上記の著作権表 示と本節をそれぞれの複製や派生著作物に対して付加しているならば、全体 であれ一部であれ、一切の制約を受けることなしに作成、複製、発表、配布 できる。ただし、本文書自体には著作権表示やインターネットソサエティも しくは他のインターネット関連団体への参照を取り除くなどの変更を加えて はならない。インターネット標準化過程で定義されている著作権のための手 続きに従って、インターネットの標準を開発するために必要な場合や、RFCを 英語以外の言語に翻訳する必要がある場合はこの限りではない。 以上の制限は永久的なものであり、インターネットソサエティもしくはその 継承者によって取り消されることはない。 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. 本文書およびここに含まれる情報は「無保証」で提供され、インターネット ソサエティおよびIETFは、本情報の利用がいかなる権利をも侵害していない という保証や、商用利用および特定目的における適合性への保証、またこれ に限らないすべての保証を、明示的にも暗黙的にも行わない。 謝辞 現在、RFCエディタの役割に関する財政支援は、インターネットソサエティ によって提供されている。 Killalea Best Current Practice [Page 13]