ネットワーク WG
Request for Comments: 3013
BCP: 46
分類: ベストカレントプラクティス

T. Killalea
neart.org
2000年11月

English

推奨される ISP セキュリティサービスと手順
(Recommended Internet Service Provider Security Services and Procedures)

このメモの位置づけ

本書は、インターネットの「現時点における最善の実践(ベストカレントプラクティス)」をインターネットコミュニティのために規定し、改善のために議論や示唆を要求するものです。このメモの配布に制限はありません。

著作権表記

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

要旨

本書の目的は、「IETF によって代表されるエンジニアリングコミュニティがセキュリティに関連して ISP に何を期待しているか」を表明することにあります。

すべての ISP を対象に適切な要件集を規定することは、本書の意図ではな く、むしろ、コミュニティの期待について ISP の間で認識を喚起し、コミュニティに現在と将来のサービスプロバイダーについてのセキュリティ期待についての議論のためのフレームワークを提供することにあります。

目次

1 はじめに

1.1 本書中で用いられる用語

2 コミュニケーション

2.1 連絡先情報
2.2 情報共有
2.3 セキュアチャネル
2.4 脆弱性情報の通知およびインシデントの報告
2.5 インシデント 対応および CSIRT

3 適切な利用法に関するポリシー( AUP )

3.1 ポリシーの告知
3.2 制裁規定
3.3 データ保護

4 ネットワークインフラストラクチャ

4.1 レジストリデータのメンテナンス
4.2 ルーティングインフラストラクチャ
4.3 ソースアドレスについての入方向フィルタリング
4.4 ソースアドレスについての出方向フィルタリング
4.5 経路フィルタリング
4.6 指図されるブロードキャスト

5 システムインフラストラクチャ

5.1 システム管理
5.2 トランジットネットワーク上にシステムがないこと
5.3 オープンメール中継
5.4 メッセージ送信

6 参考文献

7 謝辞

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

9 著者のアドレス

10 著作権表記全文

 

1 はじめに English

本書の目的は、「IETF によって代表されるエンジニアリングコミュニティが、セキュリティに関連して ISP に何を期待しているか」を表明することにあります。本書は、ISP に宛てたものです。

ISP に、このコミュニティが何を望み、期待するかを知らせることによって、このコミュニティは、ISP をしてセキュリティを優先させるばかりでなく、そのサービスを販売するときにセキュリティを誇りをもって示すものとすることに積極的になるように応援することを望みます。

決して商慣習を指示することは、本書の意図ではありません。

本書において ISP を、インターネット接続性、もしくは他のインターネッ トサービスを提供する事業を行っている組織体を含むように定義し、Web ホスティングサービス、コンテンツプロバイダー、メールサービスが含まれますが、これに限定されるものではありません。この ISP の定義は、自身のための目的で、それらのサービスを提供している組織体は含みません。

本書は、ISP に対する、いかなるセキュリティと攻撃管理の準備がサポートされる必要があるかに関する一連の推奨事項として、そしてユーザに対する、 何を高品質サービスプロバイダーから期待すべきかに関するアドバイスとして提示されています。自身の権利においては、規範的な通念とはなっていません。やがて、時代遅れのものとなりがちであり、他の期待がふくらむかもしれません。しかし、これは、インターネットとそのテクノロジーの発展における一定時点における、この分野のプロフェッショナル一同の推奨事項のスナップショットをまさに表現しているのです。

1.1 本書中で用いられる用語 English

本書中のキーワード、"REQUIRED"、"MUST"、"MUST NOT"、"SHOULD"、 "SHOULD NOT"、"MAY"は、「RFC において要請の程度を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」 [RFC2119] に記述されているように解釈されるべきもの です。

 

2 コミュニケーション English

コミュニティの最も顕著な ISP に対するセキュリティ関連の期待は、セキュリティインシデントを取り扱うコミュニケーションチャネルの利用可能性に関するものです。

2.1 連絡先情報 English

ISP は、ネットワークセキュリティに関する論点用に SECURITY、不適切な公共での行為に関する論点用に ABUSE、それからネットワークインフラストラクチャに関する論点用に NOC のメールボックスを割り当てている [RFC2142] を遵守する必要があります(SHOULD)

これは、特定のサービスに関する問い合わせや報告を受け取るために割り当てられた追加的なメールボックスもリストしています。

ISP は、上記のより詳細なことについて、共通の URL を使用することを検討することができます。(例: http://www.ISP-name-here.net/security/ )

さらに ISP は、その連絡先情報が、Whois の中であれ、ルーティングレジス トリ [RFC1786] の中であれ、他のいかなるリポジトリの中であれ、完全で、正確で、そして連絡可能であることを確保にする義務があります。

2.2 情報共有 English

ISP は、対顧客、対他の ISP、対 IRT、対法執行機関、もしくは対プレスや一般公衆に、セキュリティインシデントについての情報の共有上の明確なポリシーと手順をもつことが必要です(SHOULD)

ISP は、自身と他の ISP の間の境界をまたぐセキュリティインシデントを取り扱うためのプロセスを実際にもつ必要があります。

2.3 セキュアチャネル English

ISP は、このようなコミュニケーションをセキュアチャネル越しに行うことができる必要があります(SHOULD)。しかし、司法管轄圏によっては、セキュアチャネルが許されていないこともあることを銘記しておいてください。

2.4 脆弱性情報の通知およびインシデントの報告 English

ISP は、その提供しているサービスにおけるセキュリティ脆弱性情報を顧客に通知することにおいて、積極的である必要があります(SHOULD)。さらに、新 しい脆弱性がシステムやソフトウェアに発見され次第、そのサービスがそれらのリスクによって脅かされているか否かを示す必要があります。

ある ISP のインフラストラクチャのコンポーネントに影響を与えるセキュリティインシデントがおきた場合、その ISP は、その顧客に(下記の事項を)報告する必要があります。

多くの ISP は、顧客に停電やサービス停止について通知する手続きを確立しています。ISP が、これらのチャネルをセキュリティ関連のインシデントを報告することのために利用することは、妥当といえます。このような場合、その顧客のセキュリティ連絡窓口は、通知される担当者ではないかもしれません。むしろ、通常の連絡窓口がその報告を受け取るでしょう。顧客は、このことを知っておく必要があり、そのような通知を適切に転送するようにしなければなりません。

2.5 インシデント対応および CSIRT English

CSIRT とは、定められた構成員のサイトを巻き込むセキュリティインシデントへの対応を、行ったり、コーディネートしたり、サポートするチームです。インターネット コミュニティの CSIRT についての期待は、 「コンピュータセキュリティインシデント対応への期待 (Expectations for Computer Security Incident Response)」 [RFC2350] に記述されています。

ISP が CSIRT をもっているか否かにかかわらず、ISP は、その顧客から報告されたインシデントを受け取り扱うための、よく宣伝されたやり方をもつ必要があります。さらに ISP は、報告されたインシデントに対応する能力主体を明確に文書化する必要があり、CSIRT がある場合には、どの( CSIRT の)構成員がその顧客を含むかと、誰にインシデントを報告することができるかを表示する必要 があります。

CSIRT をもっている ISP もあります。しかし、その ISP の接続性顧客、その ISP の顧客によって攻撃されているサイトのどちらも、自動的に、その ISP の CSIRT サービスを利用することができると想定すべきではありません。ISP の CSIRT は、しばしば、構成員をインシデント対応サービスに特別に登録した(そしておそらく支払った)者のみに限定しているチームによって、追加料金のサー ビスとして提供されます。

それゆえ ISP にとって、その顧客がインシデントが起きる「事前」に、そのインシデント対応の一連の段階を規定できるようにするために、どのインシデント対応/セキュリティ資源を顧客に入手可能にしているかを公表することは重要です。

顧客は、その ISP が CSIRT をもっているか否か、もっている場合には、そのチームの憲章、ポリシー、サービスが何であるかを見つける必要があります。この情報は、「コンピュータセキュリティインシデント対応への期待 (Expectations for Computer Security Incident Response)」 [RFC2350] の Appendix D 中に示されている CSIRT テンプレートを使用することによって最もよく表明されます。

3 適切な利用法に関するポリシー( AUP ) English

各 ISP は、適切な利用法に関するポリシー( AUP )をもつ必要があります(SHOULD)

ISP が顧客と、インターネットへの接続性を提供することの契約をする際には常に、その契約は AUP の配下におかれる必要があります。AUP は、契約が更新されるたびにレヴューされる必要があり、さらに、ISP は、積極的にポリシーが更新されるたびに顧客に通知する必要があります。

AUP は、システムもしくはネットワークの様々なコンポーネントにおいて、顧客がすべきことと、すべからざることを明確に識別する必要があり、そのネットワーク上で許容されるトラフィックの種類が含まれます。その AUP は、あいまいさ、もしくは誤解を避けるために、可能な限り明解である必要があります。例えば、IP スプ−フィングを禁止する AUP もあるでしょう。

3.1 ポリシーの告知 English

ISP は、自身の AUP をその顧客に対して伝えることに加えて、そのコミュニティが、その ISP が何を適切と考えているかを認識できるように、そして、不適切な行為が起きた場合において、どんなアクションを期待するかを知ることができるように、自身のポリシーを、その Web サイトのような公的な場で公表する必要があります。

3.2 制裁規定 English

AUP は、不適切な行為が行われた場合において、いかなる制裁が執行されることになるか、表明において明確である必要があります。

3.3 データ保護 English

多くの司法管轄単位はデータ保護の法規制をもっています。このような法規制が適用されるところでは、ISP は、保持する個人データを考慮する必要があり、必須とあらば、自身をデータコントローラーとして登録し、そのデータを法規制の文言に従ってのみ使用するように備える必要があります。インターネットのグローバルな性格によって、このような法規制が存在しないところに位置する ISP は、少なくとも典型的なデータ保護法(例: [DPR1998] )を読むことによってデータ保護の発想に慣れておく必要があります。

 

4 ネットワークインフラストラクチャ English

ISP は、このようなやり方で、インターネットのネットワークインフラストラクチャを管理することに責任を負います。

4.1 レジストリデータのメンテナンス English

ISP は通常、IRR( Internet Routing Registry )や APNIC、ARIN、RIPE データベースのようなグローバルなリポジトリに蓄積されたデータを保守することに責任を負います。このデータへの更新は、強い認証を使用することによってのみ可能である必要があります。

ISP は、その顧客に割り当てるアドレス空間を、その代表者欄により詳細な連絡先情報があるように、公的に登録する必要があります。

4.2 ルーティングインフラストラクチャ English

ISP のトラフィックを正しい宛先に経路制御する能力は、ルーティングレジス トリ [RFC1786] 中で設定されるルーティングポリシーに依存することがあり ます。その場合で、かつそのレジストリがサポートしているならば、ISP は、保守しているレジストリ情報が強い認証を使用しているときにのみ更新できるようにし、更新を行う権限者が適切に制限されるようにする必要があります。

善良なる管理者の注意義務はまた、宛先にとって経路の選択肢がある場合に、誰のルーティング告知により大きな信頼をおくかを決定する際にも払われる必要があります。過去においては、にせの告知によって、トラフィックが「ブラックホールに吸い込まれた」り、さらに悪いことにハイジャックされる結果をもたら したことがあります。

BGP 認証 [RFC2385] が、ルーティング ピアに使用される必要があります(SHOULD)

4.3 ソースアドレスについての入方向フィルタリング English

このようなフィルタリングの方向は、末端サイト(顧客)からインターネットへです。

攻撃者はしばしば、偽ったソースアドレスを使用することによって、痕跡を隠します。注意を自身のサイトからそらすために、攻撃者が選ぶソースアドレスは通常、無実の遠隔サイトから、もしくは実際に、プライベートなイントラネットのために割り当てられたアドレス [RFC1918] からのものです。さらに、偽ったソースアドレスは、しばしば、ホスト間の信頼関係を攻略するために、スプーフに基づく攻撃に使用されます。

偽ったソースアドレスに依拠する攻撃のインシデントを低減するために、ISP は、下記の事項を行う必要があります。ISP の各顧客との境界ルーターにおいて ISP は、顧客から来る、その顧客に割り当てたアドレス以外のソースアドレスを もつ、すべてのトラフィックを積極的にフィルタする必要があります。この話題のより詳細な検討については、[RFC2827] をご覧ください。

入方向フィルタリングが現状では不可能な(希な)状況があり、例えば、パケットフィルタ適用の追加的な負荷を負うことができない大きなアグリゲーション(集合)ルーターがあります。さらに、このようなフィルタリングは、モービルユー ザーにとって困難を引き起こす可能性があります。それゆえ、スプ−フィングを防ぐためにこのテクニックの使用は強く推奨されますが、常に使用可能というわけではありません。

顧客と ISP 間のインターフェイスにおける入方向フィルタリングが不可能である、これらの希な場合においては、その顧客には、彼らのネットワーク中に入方 向フィルタリングを実装することが強く薦められる必要があります。一般に、フィルタリングは、できる限り実際のホストの近くで行われる必要があります。

4.4 ソースアドレスについての出方向フィルタリング English

このようなフィルタリングの方向は、インターネットから末端サイト(顧客)へです。

今日、インターネット上で広く使用されていて、IP アドレスのみに基づいて他のホストに信頼を認める多くのアプリケーション(例: バークレー 'r' コマンド)があります。これらは、[CA-95.01.IP.spoofing] に記述されているように、IP スプーフィングを認めてしまうものです。さらに [CA-97.28. Teardrop_Land] に記述されている 'land' のように、仮定上、ローカルアドレスの濫用に依拠する脆弱性があります。

ISP の顧客が、偽のソースアドレスに依拠する攻撃にさらされることを低減するために、ISP は下記の事項を行う必要があります。各顧客との境界ルーターにおいて、ISP は、顧客宛ての、その顧客に割り当てたことのあるあらゆるアドレスに該当するソースアドレスをもつすべてのトラフィックを積極的にフィルタする必要があります。

入方向フィルタリングが不可能な 4.3 に記述した状況は、出方向フィルタリングにも同様に該当します。

4.5 経路フィルタリング English

過剰なルーティング更新は、攻撃者によって、DoS 攻撃(サービス妨害攻撃)を組み立てる前提となる負荷として、悪用される可能性があります。少なくとも、パフォーマンス低下をもたらします。

ISP は、例えば、プライベートなイントラネットのために割り当てられたアドレスへの経路を無視するため、偽の経路を避けるため、"BGP Route Flap Dampening" [RFC2439] とアグリゲーション(集合)ポリシーを実装するために、ISP が聞くルーティング告知をフィルタする必要があります。

ISP は、そのネットワークの他の部分におけるルーティングについて過剰な負荷にさらすことのリスクを低減させるテクニックを実装する必要があります。テク ニックとは、「固定」経路、攻撃的アグリゲーション(集約)、経路ダンピングを含むもので、これらすべては、あなたの内部ルーティングを他者に関係ないように変更する場合、他者へのインパクト (影響)を下げるものです。

4.6 指図されるブロードキャスト English

IP プロトコルは、ブロードキャストの指図、すなわち、特定のサブネット上でブロードキャストされるパケットをネットワーク越しに送信することを許容しています。この機能については実践的な使用法はほとんど 無いのですが、様々なセキュリティ攻撃 (主に DoS 攻撃(サービス妨害攻撃))が、これを使用しますが、ブロードキャストのパケット増幅効果を利用します。それゆえ、ブロードキャストメディアに接続されているルーターは、そのメディアへの指図されるブロードキャスト [RFC2644] を許容するように設定されてはなりません(MUST NOT)

 

5 システムインフラストラクチャ English

ISP が自身のシステムを管理するやり方は、そのネットワークのセキュリティと信頼性にとって決定的に重要です。そのシステムの侵害は、控えめにもパフォー マンス、もしくは機能の低下をもたらしますが、データの損失、もしくはトラフィックが盗聴されることのリスクをもたらす可能性があります。(それゆえ、ひいては 「中間者による攻撃(man-in-the-middle 攻撃)」をもたらすことになります。)

(メール、News、Web ホスティングのような)それぞれのサービスが個別のシステムに収められるようにすれば、セキュアなシステムを構築するのが容易であるとが広く認知されています。

5.1 システム管理 English

メール、News や Web ホスティングのような極めて重要な ISP 機能を行っているすべてのシステムは、それらへのアクセスが、それらのサービスの管理者にのみ可能であるように制約される必要があります。そのアクセスは、強い認証に従ってのみ許可される必要があり、暗号化されたリンク越しである必要があります。それらのサービスがリッスンしているポートだけが、ISP のシステムネッ トワークの外部から到達可能である必要があります。

ISP は、サービスを提供することにおいて、よりセキュアな手法が利用可能となり次第、その手法について最新であることを保つ必要があります。(例えば、シンプル チャレンジ/レスポンス対応の IMAP/POP AUTH 拡張 [RFC2195] )

5.2 トランジット ネットワーク上にシステムがないこと English

システムは、トランジットネットワークセグメントに設置されるべきではありません。

5.3 オープン メール中継 English

ISP は、そのメールインフラストラクチャが、送信者の身元を隠しながら UBE ( Unsolicited Bulk E-mail )を投入する「スパマー」によって利用されることを防ぐために、積極的な手順をふむ必要があります [RFC2505]。必ずしもすべての手順が各サイトにとって適切とは限りませんが、最も効果的な「サイトに適切な」手法が使用される必要があります。

ISP はまた、その顧客に、自身のシステム上で、この活動を防ぐのに必須の手順をふむことを強く薦める必要があります。

5.4 メッセージ送信 English

メッセージ送信は、"SMTP Service Extension for Authentication"[RFC2554] に記述されている AUTH SMTP サービス拡張を使用して、認証される必要があります。

SMTP AUTH は、IP アドレスに基づく送信制限よりも好ましく、これによって、 ISP の顧客に、たとえその ISP のネットワーク経由で接続されていないとき (例: 作業中)でもメールを送信することができる柔軟性を与え、よりスプ−フィングに耐性があり、より新しい認証機構が利用可能となり次第、アップグレードされることができます。

さらに、セキュリティポリシーの執行を促すために、メッセージが SMTP ポート (25) 経由ではなく、"Message Submission"[RFC2476] で検討されている MAIL SUBMIT ポート (587) を使用して送信されることが強く推奨されます。このようにすると SMTP ポート (25) が、ローカル配信のみに制限されるようにすることができます。

この理由は、入り方向ローカル配信と中継(つまり、顧客に ISP の SMTP サー ビス経由でメールをインターネット上の任意の受信者宛てに送信することができ ること)を区別できるようにすることにあります。認証されていない SMTP は、ローカル配信用にのみ許可される必要があります。

より多くのメールクライアントが(明示的であれ、もしくは SMTP ポートを設定することによってであれ)SMTP AUTH とメッセージ送信ポートの両方をサポートするようになってきたので、ISP は、入り方向のメールポート (25) のみを許可しつつ、送信ポートと SMTP AUTH の両方を使用した顧客の送信メッセージを要求することを有用と認識することでしょう。

これらの手段( SMTP AUTH と送信ポート)は、ISP が、第三者中継経由の UBE 投入点としての役割を果たすのを防ぐのみならず、顧客が UBE を送信する場合において、メッセージ送信の説明責任を追跡する際にも役立ちます。

 

6 参考文献

[CA-95.01.IP.spoofing] "IP Spoofing Attacks and Hijacked Terminal Connections",
ftp://info.cert.org/pub/cert_advisories/
 
[CA-97.28.Teardrop_Land] "IP Denial-of-Service Attacks",
ftp://info.cert.org/pub/cert_advisories/
 
[DPR1998] 英国 "Data Protection Act 1998 (c. 29)",
http://www.hmso.gov.uk/acts/acts1998/19980029.htm
 
[RFC1786] Bates, T., Gerich, E., Joncheray, L., Jouanigot, J., Karrenberg, D., Terpstra, M. and J. Yu,
"Representation of IP outing Policies in a Routing Registry (ripe-81++)",
RFC 1786, 1995年 3月.
 
[RFC1834] Gargano, J. and K. Weiss,
"Whois and Network Information Lookup Service",
RFC 1834, 1995年 8月.
 
[RFC1835] Deutsch, P., Schoultz, R., Faltstrom, P. and C. Weider,
"Architecture of the WHOIS++ service",
RFC 1835, 1995年 8月.
 
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G. J. and E. Lear,
"Address Allocation for Private Internets",
BCP 5, RFC 1918, 1996年 2月.
 
[RFC2119] Bradner, S.,
「RFC において要請の程度を示すために用いるキーワード (Key words for use in RFCs to Indicate Requirement Levels)」,
BCP 14, RFC 2119, 1997年 3月.
 
[RFC2142] Crocker, D.,
"Mailbox Names for Common Services, Roles and Functions",
RFC 2142, 1997年 5月.
 
[RFC2195] Klensin, J., Catoe, R. and P. Krumviede,
"IMAP/POP AUTHorize Extension for Simple Challenge/Response",
RFC 2195, 1997年 9月.
 
[RFC2196] Fraser, B.,
「サイトセキュリティハンドブック (Site Security Handbook)」,
FYI 8, RFC 2196, 1997年 9月.
 
[RFC2350] Brownlee, N. and E. Guttman,
「コンピュータセキュリティインシデント対応への期待 (Expectations for Computer Security Incident Response)」,
BCP 21, RFC 2350, 1998年 6月.
 
[RFC2385] Heffernan, A.,
"Protection of BGP Sessions via the TCP MD5 Signature Option",
RFC 2385, 1998年 8月.
 
[RFC2439] Chandra R., Govindan R. and C. Villamizar,
"BGP Route Flap Damping",
RFC 2439, 1998年11月.
 
[RFC2476] Gellens R. and J. Klensin,
"Message Submission",
RFC 2476, 1998年12月.
 
[RFC2505] Lindberg, G.,
「SMTP MTA についての spam 対策推奨事項 (Anti-Spam Recommendations for SMTP MTAs)」,
BCP 30, RFC 2505, 1999年 2月.
 
[RFC2554] Myers, J.,
"SMTP Service Extension for Authentication",
RFC 2554, 1999年 3月
.
[RFC2644] Senie, D.,
「ルーターにおいて指図されるブロードキャストについてのデフォルトを変更する (Changing the Default for Directed Broadcasts in Routers)」,
BCP 34, RFC 2644, 1999年 8月.
 
[RFC2827] Ferguson, P. and D. Senie,
「ネットワークイングレスフィルタリング: IP ソース アドレスを偽ったサービス妨害攻撃をくじく (Network Ingress Filtering: Defeating Denial of Service Attacks which employ IP Source Address Spoofing)」,
BCP 38, RFC 2827, 2000年 5月.

 

7 謝辞 English

私は、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氏および Bill Woodcock氏から受けた建設的なコメントに大いに感謝します。

 

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

本書全体が、セキュリティの諸論点を検討しています。

 

9 著者のアドレス

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

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

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

EMail: miyakawa@ipa.go.jp

 

10 著作権表記全文

Copyright (C) The Internet Society (2000). 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.

謝辞

RFC エディタのための財源は現在、Internet Society によって提供されています。