2004年 3月31日
IRR企画策定専門家チーム
JPNICにおけるIRRサービスに関する検討報告書
----------------------------------------------------------------------
■目次
1. 検討の目的
2. IRR企画策定専門家チーム
3. 検討内容
4. 検討結果要約
5. IRRを取り巻く環境に関する調査
5.1 IRRの歴史
5.2 国際的なIRR利用状況
5.3 アジア太平洋地域におけるIRR
5.4 IPアドレスレジストリとIRRの関連性
5.5 IRRの技術に関する環境
6. IRR環境の改善のための検討
6.1 プライベートデータとパブリックデータの分離
6.2 理想的なIRRミラーリングモデル
6.3 IRRの即時性
6.4 経路情報の台帳としてのIRR
6.5 常に最新のデータとするための構造
6.6 IRRデータミラーリングにおける問題点(個人情報保護)
6.7 IRRデータミラーリングにおける問題点(一括ミラーParent/Child)
6.8 IRRのセキュリティ
6.8.1 ルーティングとIRRの安全性
6.8.2 登録情報の安全性
6.8.3 IRRのセキュリティ向上のための今後の対応
7. IRRの運用実績とその結果
7.1 JPNICにおけるIRR試験サービス
7.2 JPIRRサーバのシステム構成
7.2.1 JPIRRサーバのソフトウェア構成
7.2.2 JPIRRサーバのハードウェア構成
7.3 他IRRとのミラーリング
7.4 運用者向けマニュアルの整備
7.5 利用者向けマニュアルの整備
7.6 利用実績(統計情報)
77.7 サービスの運用における問題点および改善点
7.7.1 JPNIC IRRサービスの信頼性
7.7.2 他IRRデータ参照サービスの信頼性
7.7.3 他のIRRで参照されるJPIRRデータベースの信頼性
7.8 IRRシステムの問題点と改善案
7.8.1 認証・個人情報を有するオブジェクトの扱いについて
7.8.2 IRRdソフトウェアの問題点について
8. IRRに関連する技術研究・調査
8.1 IRRとルータを利用した経路確認システム
8.2 ポリシチェックシステム
8.3 IRRオブジェクトガーベージコレクタシステム
8.4 IPv6 IRRシステム
8.4.1 IPv6におけるIRRの必要性
8.4.2 IPv6用IRRデータベースの状況
8.4.3 IPv6 IRRに関する提案
9. JPNIC IRR企画策定専門家チームの活動実績
9.1 日本ににおける活動
9.2 APNIC管轄地域における活動
9.3 国際的活動
10. JPNICにおけるIRRサービス
10.1 国際的なIRRとJPNICの関連性
10.2 インターネットレジストリにおけるIRRサービスの必要性
10.3 周辺活動の重要性
10.4 本サービスに向けての問題点と改善策
10.4.1 セキュリティ
10.4.2 NICハンドルの問題
10.4.3 Whoisデータベースとの連携
10.4.4 システムの安定に向けた施策
10.4.4.1 他IRRデータ参照サービスの信頼性
10.4.4.2 他IRRで参照されるJPIRRデータベースの信頼性
10.4.5 IPv6サービス
10.4.6 IRRのデータの信憑性維持のための施策
10.4.7 階層構造を構成するためのシステム作り
10.5 JPNICにおけるIRRサービスの必要性
Appendix.1 - 謝辞
Appendix.2 - IRR企画策定専門家チームメンバ一覧
Appendix.3 - 参考文献等
----------------------------------------------------------------------
1. 検討の目的
IRR(Internet Routing Registry)は、インターネットの経路情報の台帳と
して機能すべく研究され、運用されてきました。当初は研究目的ということ
もあり無料でそのサービスは提供されていましたが、2000年に世界最大のデ
ータ量を誇るMerit社(Merit Network Inc. 以下、Merit)のRADB(Routing
Assets Database)サービスが有料化されるに伴い、これまでRADBに蓄積され
てきたデータが、各ISPで保持するなどして分散化の傾向を示すようになり
ました。
このようなIRRを取り巻く環境の劇的な変化に伴い、インターネットの経
路情報の台帳としてのIRRの環境を考え直し、インターネットコミュニティ、
特に日本のインターネットコミュニティに対して価値のあるIRRサービスの
あり方を検討するためにIRR企画策定専門家チーム(以下、当チーム)を構成
しました。
当チームでは、現状のIRR環境の整理をはじめ、より具体的、かつ現実的
に活動を進めるために、APNIC(Asia Pacific Network Information Centre)
やRIPE NCC(RIPE Network Coordination Centre), NANOG(The North American
Network Operators' Group)などと協調して次世代のIRR環境を検討してき
ました。そして、その検討結果をこれらの団体に対してフィードバックを行
い、検討した結果の普及・啓蒙などを実施することも目的の一つとしていま
す。
2. IRR企画策定専門家チーム
上記のような目的を持った当チームは、JPNIC(Japan Network Information
Center)がコーディネートを行い、2000年に発足した「IRR研究会」を前身
とします。研究会はより多くの意見を求め、情報を交換する場としてのオー
プンな研究会として1度実施され、その後は、メンバを数名に絞って検討の
結果をまとめる作業に従事しました。この結果は、JPNICに対して提出した
「IRRに関する検討報告」という形で公開されています。
「IRRに関する検討報告」
http://www.nic.ad.jp/ja/materials/irr/report-200012.html
その後、この研究会の結果を踏まえ、より具体的な検討が必要という認識
のもと、「IRR企画策定専門家チーム」として6名のメンバによって再構成さ
れ、3年間に渡る検討などの活動を実施してきています。
本報告書は、この「IRRに関する検討報告」を受けて、当チームでさらに
検討を重ねてきた結果です。
3. 検討内容
当チームでは様々な観点から検討を実施し、活動を行ってきました。これ
らの活動について以下の内容で、この報告書をまとめています。
まず、4章において、当チームでの検討の結果に基づいて重要な事項をま
とめ、今後のJPNICの活動として実施すべきと考える事柄について提案しま
す。5章以降においてこの結果に至った検討内容について詳細な報告を行い
ます。
5章では、活動を行うにあたって背景となっているIRRの現状についてまと
めます。6章では、現状を踏まえた上でのIRR周辺環境の改善の検討とその改
善方法の提案について記述します。7章では改善案に基づく実装を行った報
告を行います。
8章は、次世代のIRRを検討して行く上で必要となるIRR周辺ツールの解説
とその実装について記載します。
9章は、これらの検討、改善提案、実装を行う上で必要となった他団体と
の連携活動などについて報告します。
最後の10章では、これらの活動を通じて、今後、JPNICとしてどのような
活動を実施すべきかなどについて提案を行います。
4. 検討結果要約
当チームでは、3章にあげた検討内容に沿って検討を進めてきました。こ
れらの検討内容については、5章以降で詳しく述べたのち、10章でJPNICにお
けるIRRサービスの必要性とサービス開始に向けての検討事項などを述べま
す。細かい議論に先立ち、本章にてこれら検討の結果の要約を述べておきま
す。
検討においては、先にも述べた通り、IRRの周辺環境の調査にはじまり、
現状の把握、改善のための検討・提案、それらの実績を作るための試験サー
ビスの実施、そこから得られるユーザの声の聴取と様々な活動を実施しまし
た。
これらの活動の結果、RIPE NCCやAPNICのようなインターネットレジスト
リによるIRRサービスが実施される方向にあることが把握できました。また、
IRRに蓄積されるデータの信憑性を維持することができるようになるほか、
JPNICとしても、インターネットに流れる経路の実体を把握するための良い
参考になるという結論になりました。
また、当チームメンバが参加したいくつかのミーティングにおいては、日
本のIRRユーザからも、日本国内における公共的なIRRの存在を望む声が聞こ
えてきています。このような日本における公共的なIRRの存在は、海外のIRR
に登録する際に発生する、(1)外貨建てでの支払いの必要性、(2)登録時に登
録先の言語でのやり取りの必要性、などの登録の煩雑さを軽減するほか、
日本にある経路の台帳となることで、ISPなどによって個別に運用されるIRR
に対して、情報を補完できるというメリットをIRRのユーザに与えます。こ
のような考えから、JPNICのような公共的な団体によるIRRサービスの実施は
不可欠だと考えます。
もちろん、実際にJPNICで正式なIRRサービスを実施するためには、今回洗
い出されたいくつかの問題点や改善点を検討し、適宜実装するなどの対策を
施す必要があります。しかし、これらの対策は、運用を行いながら改善すれ
ば良いと判断されるものです。
2003年度までの活動の結果、日本おいて公共的なIRRサービスを望む声が
強いことが把握できました。また、IRRデータの信憑性を維持するための方
法についても検討し、ある程度効果的な方法があることが判明しました。
しかし、IRRの試験サービスについてはオブジェクト数の数が期待数ほど
集まらなかったこともあり、十分なデータを収集することができず、当チー
ムとしてIRRのサービスを開始することを強く推奨するほどの結論を導き出
すことができませんでした。
しかし、少なからずIRRに関する十分なデータを集めるためにも、何らか
の形でJPNICがIRRのサービスを継続する必要があると考えます。
5. IRRを取り巻く環境に関する調査
本章では、IRRの歴史を振り返り、現在のIRRの世界的状況およびアジア太
平洋地域での状況について調査した結果を報告します。これに加え、近年多
く行われているインターネットレジストリによるIRRサービスの背景、そし
てIRRの情報を利用するツール群とその利便性に関して報告します。
5.1 IRRの歴史
IRRを研究していた有名なプロジェクトの一つに米国のMerit, University
of Southern California Information Sciences Institute(ISI),
Cisco Systems, University of Michiganとその関係者によって提供された
Routing Arbiter Project(以下、RAプロジェクト)があります。
RAプロジェクトは、Route Server, Network Management System, Routing
Arbiter Database(RADB), Routing Engineering Teamの4つのプロジェクト
で構成されていました。このRAプロジェクトは、 NAP(*1)での経路交換にお
いて、NAP上でフルメッシュのBGP Peerをするのではなく、Route Serverを
使って、単一のPeerをRoute Serverに接続することで、BGPの経路情報の交
換をスムーズに行うことを目的としていました。このRoute Serverには、デ
ータベースに蓄積された経路情報とポリシ情報を利用して、BGP Peer間の経
路制御を実装する機能があり、ここで利用するデータベースがRADBであり、
IRRでした。
RADBに蓄積されるポリシ情報は、RIPE-181という形式で記述されていまし
た。RIPE-181形式は、ヨーロッパにあるRIPE NCCによって開発されたもので、
その原型は、1980年後半にNSFNETのバックボーンルータを設定するために利
用されていたPRDB(Policy Routing Database)です。PRDBは、このRADBと
RIPE-181の出現によって、1995年までに置き換えられています。
その後、IRRの記述言語であるRIPE-181はいくつかの拡張をされながら利
用されてきましたが、1999年6月にRFC2622としてRPSL(Routing Policy
Specification Language)が定義されると、Meritを初めとするいくつかの
IRRサーバ提供者は、すぐさまこれに対応し、現在では、RPSLを利用するこ
とが標準となっています。
一方で、IRRサービスの状況も変化してきています。RAプロジェクトの発
足に合わせる形で、NAPやISPなどでもIRRサービスを提供する動きがありま
した。1999年までは、IRRサーバソフトウェアも十分なものがなく、実際に
サービスを提供していたのは、RADB, RIPE, Cable & Wireless, ANS, CAnet
の5か所のみでした。この中でもRADBはデータ量などから見ても世界最大の
データベースとなっていました。しかし、Meritは1999年後半に、RADBを有
料化すると宣言しました。また同時に、IRRdというIRRサーバソフトウェア
の提供を無償で開始すると発表しました。
IRRdは、IRRの情報を簡単に扱うことができ、かつ他のIRRとのミラーリン
グもサポートし、小規模向けには非常に強力なソフトウェアでした。このた
め、IRRを必要とするISPなどは、IRRdを用いてIRRサービスを独自に行い、
そのデータをRADBとミラーするという手法を取り始めました。これにより、
先にあげた5か所のIRRに多く集まっていたデータは分散化していきました。
IRRのミラーリングの仕組みでは、ミラーリング先から他のミラーリング先
へとデータを転送することは行わないので、今までのようにRADBをミラーし、
そのデータベースからルータへポリシを実装することが難しくなりました。
この段階において、日本でもIRRの周辺事情に関する議論が盛り上がり、
JPNICが2000年に開催したIRR研究会へとつながります。
(*1)NAP(Network Access Point)：現在のIX(インターネットエクスチェン
ジ)に類似したもの
5.2 国際的なIRR利用状況
国際的には、IRRのコミュニティは現在もMeritが運営するRADBを中心と考
えて問題ありません。Meritの有料化以降、Meritが配布するIRRdを用いて独
自にIRRサーバを運営するISPが数多くできましたが、その多くは、RADBとミ
ラーリングを実施しており、その数は、47(2004年3月末現在)となっていま
す。このため、RADBから直接検索を実施するのであれば、現在もなお、多く
のIRRの情報を取得することが可能です。
一方で、インターネットレジストリでIRRの機能をサポートする動きもあ
ります。この動きは、米国のネットワーク運用グループであるNANOGが開催
するミーティングであるNANOG22(2001年5月開催)において、当チームとして
IRRとインターネットレジストリが持つWhoisデータベースの連携によって
IRRのデータがより信頼性の高いものになるという提案に賛同を受け始まっ
たものです。
この流れを受け、アジア太平洋地域を中心に活動するAPNICは、2002年よ
りRIPE NCCのWhoisシステムを採用し、同時にIRRのサービスも始めています。
ヨーロッパを中心に活動を行うRIPE NCCは、独自のデータベースを開発し
利用している経緯もあり、古くから、IRRとインターネットレジストリが持
つWhoisデータベースが統合されたシステムで運用が行われてきました。
北米を中心に活動するARIN(American Registry for Internet Numbers)で
は、Meritが大きなIRRであるRADBを運営していることから、実験的にIRRを
運営するにとどまり、積極的な運用は行っていません。
このように、IRRの共通のデータは、RIR(Regional Internet Registory:
地域インターネットレジストリ)を中心にデータの統合化が進んできていま
す(*2)。しかし、各ISP、特にトランジットサービスを行うような比較的大
規模なISPにおいては、現在もなお、独自にIRRサービスを実施しているとこ
ろも少なくありません。
この2つの運用のされ方には、データの内容に大きな違いがあることがわ
かってきています。
先に説明した、RIRが運用するIRRデータについては、より一般的な情報、
つまり、AS番号とPrefix、そしてそれらがグループ化された情報と運用者情
報などが入り、経路の優先性情報やPeering情報などの細かい情報はほとん
ど含まれていません。その一方で、各ISPが運用するようなIRRでは、顧客の
Peering情報が扱われているケースもあるようです。
このようにISPが独自にIRRを運用する背景には、BGPルータのPrefixフィ
ルタを自動生成するなど運用負荷の軽減や自ASが管理すべき経路情報の安全
な蓄積などという目的があります。
RIRが運用するようなIRRでも、ごく一般的な情報はあるためPrefixフィル
タ程度であれば自動生成が可能です。しかし、ISPが独自に運用するIRRなど
では、これに加え、マルチホームPeeringの優先性情報などの細かい情報も
扱うことで、より高度な運用負荷軽減を狙っているのが現実と言えます。
(*2)北米では、RADBが中心となっています
5.3 アジア太平洋地域におけるIRR
アジア太平洋地域におけるIRRの活動はAPNICを中心に行われています。
先の第22回NANOGミーティングの動きや第10回APNICオープンポリシーミー
ティングでの当チームからのインターネットレジストリによるIRR実施の提
案などを受けて、APNICでは2001年よりIRRサービスを開始しました。
この動きを経て、APNIC管轄地域では、APNICのIRRデータベースが利用さ
れるケースが増えてきました。
ISP独自でのIRRサービスの運用については、国際的な流れと変わることは
ありませんが、全体の数としてAPNIC管轄地域では、大規模なISPも少ないこ
とからその数は多くありません。
APNIC管轄地域において比較的大きな動きがある地域は日本と韓国と言え
るでしょう。韓国は、先のAPNICの流れを受け、KRNIC(Korea Network
Information Center)が中心にIRRサービスの検討プロジェクトが立ち上がっ
ており、サービス開始に向けた検討が進んでいます。日本では、公共のIRR
サービスとして現在当チームが実施しているJPIRR試験サービスがあります
が、民間・研究団体としてはNTTやSINETなどもIRRを運用しています。
これらAPNIC管轄地域のIRRについては、IRRの普及度などの面から、公共
のIRRとして運用されているものはAPNICの持つIRRのみであり、JPNICおよび
KRNICはいまだ実験段階、その他はISP独自となっている状況です。
5.4 IPアドレスレジストリとIRRの関連性
IPアドレスレジストリ(IPアドレスを管理するインターネットレジストリ)
は本来、IPアドレスを利用者に割り振り・割り当てを効率よくかつ重複のな
いように実施することが目的のため、IRRのような運用情報を取り扱うとい
うことに関係はありません。しかし、インターネットの経路情報は、これら
IPアドレスレジストリが割り振るアドレスブロックのサイズなどに大きく影
響されます。このため、IPアドレスレジストリにおいても、この影響度につ
いては認識されており、割り振りポリシ決定の際には、多くの場面で経路表
の増大などについて検討されています。
このように、IRRが扱うインターネットの運用情報のうち、特にPrefixサ
イズについて、IPアドレスレジストリが扱わないような情報と、運用に本来
関係のないアドレス管理という2つの面が、実は密接に関係してくることが
わかります。
さらに、割り振られたアドレスの管理者情報については、セキュリティの
面で密接な関係があると言えます。
IRRに登録されるオブジェクトはすべて、管理者情報を登録してあるオブ
ジェクト(Maintainerオブジェクト)によって管理されます。このMaintainer
オブジェクトには、オブジェクト変更のための認証情報なども含まれていま
す。また、このMaintainerオブジェクトさえ登録してしまえば、どんなIRR
オブジェクトも自由に登録できてしまいます。
このように、IRRの運用において、このMaintainerオブジェクトは大変重
要なオブジェクトとなっています。しかし、このオブジェクトの登録にあた
っては、登録者が実在するかどうかについて、十分なチェックが行われてい
ないのが実情です。このような現状は、IPアドレスレジストリから正しく割
り振りを受けている経路情報を、悪意を持った誰かが登録を改竄できてしま
う危険性を含んでいます。
IPアドレスレジストリが割り振ったアドレスブロックが、そのままの形で
インターネットの経路情報に反映されることがほとんどであることは、先に
述べました。逆に言えば、インターネットに反映されている経路情報は、IP
アドレスレジストリが利用者情報などを含め確認を取ったところに、そのア
ドレスを貸与しているわけですから、IRRに反映されるRouteオブジェクト
などの管理者情報と一致するはずです。
このように、IPアドレスレジストリとIRRは本来、異なる目的で運用され
ているにも関わらず、IRRの情報を健全に保つことを考えた場合には、IPア
ドレスレジストリと密接な関係を持たせる必要があることがわかります。
実際には、RIPE NCCのRIPE-db version 3というデータベースシステムは、
IPアドレスレジストリの情報であるinetnumオブジェクトから、IRRの情報
であるRouteオブジェクトに対して認証情報が引き継がれており、inetnum
で指定される範囲内でなければ、その管理者はRouteオブジェクトを登録で
きないような仕組みを実装しています。このデータベースは、現在APNICの
Whoisシステムとしても利用され、IPアドレスレジストリのシステムとし
て多く利用されているものになっています。
5.5 IRRの技術に関する環境
IRRの技術に関する環境は、様々な変化を遂げてきました。2000年以前、
IRRデータベースサーバを運営することのできるソフトウェアは、一般に公
開されているものではなく、ユーザ側はあくまでIRRのサービスを提供され
る側でした。
しかし、MeritがRADBに課金を開始したのと同時に、そのソフトウェアを
一般に公開し、それ以来、ISPなどでIRRサーバを独自に立ち上げるようにな
りました。(5.1節「IRRの歴史」を参照)
現在、最も広く利用されているIRRサーバソフトウェアは、IRRdです。こ
のIRRdは、Meritにより開発され、昔からRADBで利用されてきました。今で
は、多くのISPなどで広く利用されているものです。
RIPE-181やRPSLの記述言語をサポートし、WHOISやユーザからのqueryを処
理することはもちろんですが、他のIRRデータベースサーバとのミラーリン
グもサポートしています。つまり、自分でこのIRRdを用いてIRRサーバを立
ち上げ、そこにIRRの情報を登録し、他のIRRサーバとのミラーリングを実施
することにより、互いにそれぞれのIRRの情報を交換するようになりました。
また、このIRRd以外に、RIPE-dbというものがあります。RIPE-dbは、イン
ターネットレジストリが管理する情報に加えて、IRRの情報も同時に管理す
ることのできるデータベースソフトです。元々RIPE NCCで開発されてきたも
ので、現在では、RIPE NCCの他に、APNICでも利用されています。
IRRの情報には，BGPの経路情報やその優先性に関する情報、あるいは、特
定の経路に対するコンタクト情報など、様々な情報が含まれています。これ
らの情報から、ユーザが必要な情報を取得したり、あるいはそこからBGPの
コンフィグレーションを作成したりといった、IRRの情報から必要な情報を
取得、収集、生成を可能とするようなツールの開発も、IRRの開発の一環と
して行われてきました。
RAToolset(Routing Arbiter ToolSet)は、1997年から2001年にかけてISI
を中心として開発されたソフトウェアです。RPSLで記述されたIRRオブジェ
クトを利用して、ポリシを生成したり分析するツール群の総称のことです。
プラットフォームも狭く限定されることなく、通常のUNIX環境であれば問題
なく動作するものとなっています。
その代表的なものの1つとして、RtConfigというものがあります。これは
RPSLで記述されたポリシに従い、BGPのコンフィグレーションを生成するこ
とや、顧客やピアに対する経路フィルタなど容易に作成することが出きます。
複数のベンダのルータ設定言語にも対応しているため、広く利用されていま
す。また、pevalというものがあります。これはIRRのRouteオブジェクトか
ら特定のOrigin ASを割り出して、該当するASのPrefixの一覧などを抽出す
ることも可能です。
これらの他にもいくつかのツールがありますが、現在では、IRRToolsetと
いう名前で、その開発元もRIPE NCCへと引き継がれ、開発も継続的に行われ
ています。
6. IRR環境の改善のための検討
本章では、IRRの周辺環境の変化に伴って生じた問題点について、詳細に
分析し、それぞれについて発生している問題点の改善策について検討した結
果を報告します。
6.1 プライベートデータとパブリックデータの分離
IRRの利用形態はその利用者によって様々です。あるIRRでは、特定のイン
ターネットエクスチェンジポイント(IX)の経路交換ポリシを表現するケース
や、特定のISPの顧客の経路情報を管理するケースなどに使われています。
一方で、IRRのデータはインターネット全体の経路情報を表します。どのISP
がどのようなPrefixやASの塊で、経路をインターネット上に広告しているの
かという、非常に一般的な情報の参照元としても利用されています。
これら2つの利用方法は、IRRに登録されるデータの粒度や参照元などが大
きく異なるため、同じポリシでデータを取り扱うことは、Peering情報など
の守秘義務もあり、得策ではありません。当チームが主催した会合などでも
同様な意見が寄せられているほか、APNICやRIPE NCCの担当者などからも同
じような意見が寄せられています。
当チームでは、JPNICが実施するIRRを前提に、検討を加える上でこの2つ
の性質の異なるIRRデータをプライベートデータとパブリックデータに分類
し、JPNICのような公共的なIRRはパブリックデータのみを扱うべきであると
の結論に達しています。
以下では、プライベートデータとパブリックデータの定義について明示し
ます。
○プライベートデータ
主に、特定のIXへの参加者や特定のISPの顧客向けに提供され、そ
のコミュニティに閉じて利用されるIRRに蓄積されるデータを指しま
す。これらのプライベートデータには、特定のコミュニティ内で閉じ
ることが必要とされている情報が含まれていることが考えられ、他の
IRRとの情報の交換には、守秘義務協定など一定の制限を設けて実施
するか、または一切の情報交換を実施しないなどの措置が必要です。
具体的には、特定のBGP Peerに対するLocal Preferenceの値、
AS-PATHやPrefixの情報と、それらをどのBGP Peerにどういう優先度
で広告するかという情報、およびどういう優先度で受信するかという
情報が含まれます。これらの情報を使うことで、特定のコミュニティ
においてきめの細かい経路フィルタなどを自動的に実装することが可
能となっています。
○パブリックデータ
不特定多数からの参照を前提とし、インターネットの経路情報全体
を参照できることを目的に運用されるIRRに蓄積されるデータを指し
ます。蓄積される情報は、インターネットレジストリから割り振られ、
実際にインターネットに広告されている経路が登録されるもので、
BGP運用者がインターネットに対して広告する可能性のある経路とそ
のOrigin ASの情報などが登録されるほか、トラブル発生時のコンタ
クト先に関する情報の蓄積などに利用されます。
パブリックデータは、インターネットに広告されている全ての経路
情報が参照可能であるため、広告されている経路が正しいものである
かどうかを確認することができる点と、プライベートデータのような
細かい優先性情報などは、付加的に登録可能、つまりオプションとし
ての情報であるという点が、重要なポイントとなっています。
もちろん、全ての経路情報に関連するデータが蓄積されるべきもの
であるため、フルルートに対する適切なPrefixフィルタが実施できる
レベルの情報である必要があります。
これら2つの情報は、完全に分離して管理されるべきです。プライベート
データは、そのコミュニティによって管理され、パブリックデータはインター
ネットレジストリのような公共的な機関によって管理されるべきです。しか
し、これら2つのデータは時に相互に補完して形成されるべきです。例えば、
特定のコミュニティにおいて蓄積されるプライベートデータは、そのコミュ
ニティ内部で利用される情報のみが蓄積されます。それ以外の情報はパブリ
ックデータとして蓄積されているデータによって補完されることで、必要な
部分は細かく、それ以外の部分については粗く、全ての情報が参照できるよ
うになります。
逆に、プライベートデータから細かい優先性情報などの守秘義務に抵触す
るような情報をそぎ落とし、パブリックデータに加工することで、パブリッ
クデータを蓄積するIRRに流用することが可能になります。
2003年時点でのIRRの仕組みには、このようなプライベートデータとパブ
リックデータの分類は存在していません。しかし、将来的にIRRの相互連携
モデルが確立した時には、IRRの各オブジェクト、さらにはRPSLの各フィー
ルド単位で、パブリック・プライベートなどの属性をもつことで、より信憑
性の高いIRR環境の構築が可能となります。
6.2 理想的なIRRミラーリングモデル
公共的なIRRが持つデータは、前節でも述べたようにインターネット全体
の経路情報を網羅しておく必要があります。IRRのデータはある一定のコミ
ュニティの中で集められている場合が多いほか、IRRデータのメンテナンス
などの利便性を考えた場合でも、ある一定の地域でいったんIRRのデータを
集約した方が、効率的かつ利便性が高いと言えるでしょう。
このような考え方から、IRRのデータはコミュニティを形成するような適
切な地域に分割され、それぞれの地域で集約したものを、それぞれのIRR間
で相互に交換しながら運用することが最善の方法と言えます。
このとき、これらのデータの管理を行う適切な機関はどこか、という問題
となります。既に5.4節で述べたように、IRRのデータとインターネットレジ
ストリは密接に関係があるため、インターネットレジストリがIRRデータの
管理も集約して行うことが最善の方法と言えます。さらに、IRRデータを集
約する地域的な広がりも、インターネットレジストリが管理を行う地域的な
広がりに一致させることで、管理範囲を明確にできるといったメリットも生
まれてきます。
次に、集約されたIRRデータの相互交換の方法です。インターネットレジ
ストリは、RIRを中心とした階層構造を持っており、IPアドレスの管理もこ
の構造に従って行われています。(図6-1)
+--------+
| ICANN |
+--------+
|
+-----------+-----------+-----------+.............+
| | | : :
+--------+ +--------+ +--------+ +--------+ +...........+
| ARIN | |RIPE NCC| | APNIC | | LACNIC | :Potential :
+--------+ +--------+ +--------+ +--------+ :future RIRs:
| +...........+
+-----------+--+--------+
| | |
+------+ +-------+ |
| NIR | | JPNIC | | National Internet
+------+ +-------+ | Registries
| | |
| | |
| | |
+------+ +------+ +------+ Local Internet
| LIR | | LIR | | LIR | Registries
+------+ +------+ +------+
図6-1 インターネットレジストリの階層構造
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
RIRの下には、JPNICをはじめとする国別インターネットレジストリ(NIR)
が存在します。その下には、ISPなどのローカルインターネットレジストリ
(LIR)が存在する階層構造になっています。
IRRのデータをRIR間で交換すれば、全世界的に共通のIRRデータを持つこ
とが可能になります。一方で、IRRの運用を考えた場合、各国単位やISP単位
などのコミュニティを絞った形で集約できた方が効率的です。このため、
IRRのAuthoritativeなデータベース(*3)は、各NIRまたはLIRが集約します。
上位のインターネットレジストリが運用するIRRとミラーリングし、最終的
にその地域の上位RIRにデータが集約することで、RIRが管轄する地域の全て
のIRR情報が集まる構造となります。この集約されたデータを他のRIRと交換
することで、全てのRIRで共通の情報を持つことができるようになります。
データを集約することだけではなく、データを分配することを考える必要
があります。NIRやLIRはAuthoritativeなデータを扱いますが、これらの情
報は、そのIRRのユーザに検索されるなどして利用されます。この際、それ
ぞれのAuthoritativeなデータだけを検索できれば良いわけでなく、ユーザ
は、RIRが共有している全てのデータを検索対象とすることが想定されます。
そのため、RIRに集約されたデータは、NIRを経てLIRへと、逆方向にデータ
を配分する必要があります。
この一連の説明で、「情報交換」としている部分の具体的な手法としては、
NRTM(Near Real Time Mirroring)という仕組みが使われています。NRTMが出
現する前までは、各IRRが出力するテキスト形式のデータベースファイルを
交換することで、情報交換を実施していました。しかし、NRTMを利用するこ
とで、30分程度の一定間隔の差分更新が実施され、ミラーリングを実施して
いるIRR間では、NRTM利用前と比較して、非常に短時間にデータの更新が反
映されるようになりました。今回のミラーリングモデルの検討では、この
NRTMが利用されることを前提にして、検討を重ねたことを付け加えておきま
す。
このNRTMによるミラーリングを実施せず、無作為にミラーリングを実施し
た場合、階層構造は利用しないわけですから、各RIR, NIR, LIRは全てのIRR
とミラーリングを実施する必要があります。さらに、NIRやLIRがIRRデータ
の集約を実施しないため、さらに細かいネットワークのIRRが加わり、各IRR
が必要とするミラーリングの対象は膨大な数になることが考えられます。
一方、階層構造を利用したミラーリングを実施した場合、上位のIRRから、
集約されたIRRの情報をミラーリングすることが可能となり、ミラーリング
の管理が非常に楽になるほか、各インターネットレジストリが持つ割り振り
情報などと照合することが可能になれば、より信頼性の高いIRR情報の提供
が十分期待できます。
このように、IRRの運用はインターネットレジストリが実施し、IPアドレ
スの階層構造に従ってミラーリングを行うことで、IRRを支える環境として
適切であると考えられます。
(*3)Authoritativeなデータベースとは、JPIRRであれば、JPIRRが管理・
認証を行っているデータベースを指します
6.3 IRRの即時性
NRTMの導入により、信頼性のあるミラーリングが実施されるようになりま
したが、NRTMには以下に挙げられるような問題点があります。
1. 各オブジェクトに対するアクセス権限が設定できない
2. 最新のデータを引き出すことができない
1.に関しては、ミラーリングしたデータは、機能的に全てのデータが公開
されるために、ユーザはWHOISクライアントを通じて、データを参照するこ
とが可能です。しかし、これらのデータには、公開すべきではないデータが
含まれていることも想定されます。 現在のIRRサーバソフトウェアには、こ
うした特定のデータに対するアクセスを制限することは不可能です。
2.に関しては、データの差分更新途中にデータベースへの問い合わせがあ
った場合などに、誤った古いデータを返す場合も考えられます。例えば、
AuthoritativeなIRRデータベースとそれをミラーリングしているデータベー
スがあった場合、Authoritativeなデータベースが更新された場合には、NRTM
では、両者のデータベースに更新間隔のずれがあるため、両者への問い合わ
せ結果が異なる場合も考えられます。これでは、即時性のあるレジストリシ
ステムであるとは言えません。
これらの問題が発生する理由としては、RFC954において標準化されている
Whoisプロトコルの仕様に問題が挙げられます。この問題解決に取り組んだ
RWhois(Referral Whois)がRFC2167で標準化されましたが、(1)IRRサーバご
とにデータフォーマットが異なるため、RWhoisでは適切な処理ができない、
(2)セキュリティ上の問題点がある、との理由で全面的な普及には至ってい
ないのが現状であり、こうした問題を解決するため、IETF(Internet
Engineering Task Force)では現在、CRISP(Cross Registry Internet Service
Protocol)が標準化されようとしています。
CRISPは、ルーティングレジストリに限らず、ドメインレジストリ、IPア
ドレスレジストリといった、インターネットレジストリにおいて汎用的に問
い合わせ・返答するためのプロトコルを定義しています。
CRISP設立の経緯は、2001年8月に開催された第51回IETFミーティングにお
いて、Whois Enhancement BoFが開催されたことに始まります。当初は、
whoisプロトコルの修正が目的でしたが、Whois Enhancement BoFを経て、
CRISP ワーキンググループが設立されました。
このワーキンググループは、Whoisプロトコルに代わるプロトコルの策定・
標準化を目指して設立されました。現在では、標準化を加速するためドメイ
ンレジストリの機能に絞って、ワーキンググループ内で議論されています。
CRISPの要求を満たすプロトコル実装方式として、IRIS(Internet Registry
Information Service)があります。IRISは、XML(eXtensible Markup Language)
をベースとしたディレクトリサービスです。図6-2のように、ドメイン、ア
ドレス、ルーティングといったレジストリに依存する部分とBEEP(Blocks
Extensible Exchange Protocol)といったトランスポートプロトコルとの間
に挟まれる共有レジストリ層としての役割を持っています。
-----------------------------
Registry-Specific |domain | address | routing|
-----------------------------
Common-Registry | IRIS |
-----------------------------
Transport | beep | iris-lwz | etc... |
-----------------------------
図6-2 IRISの関係
~~~~~~~~~~~~~~~~
先述の通り、CRISPはドメインレジストリを中心に標準化が進んでいます
が、今後の展開としては、アドレス、ルーティングにおいてもその利用が検
討されています。CRISPは、今までのWhoisプロトコルで実現できなかったIRR
の即時性を実現するという点において、今後の標準化が期待されています。
6.4 経路情報の台帳としてのIRR
IRRで取り扱うデータは大きく分類して、「パブリックデータ」と「プラ
イベートデータ」の2種類があることを、6.1節で説明しました。
プライベートデータには、経路の優先性情報などインターネットの運用上、
重要な情報が含まれます。このような情報は、企業内や特定のコミュニティ
の中だけで利用され、外部に流出させないように運用されます。その一方、
パブリックデータは、プライベートデータをより一般的にし、特定のコミュ
ニティ以外で参照可能な情報となります。
インターネットの運用上、優先性情報といった、より細かい情報を得るこ
とで運用の煩雑さが改善されることが期待できると考えられています。JPNIC
のような公共的な団体で実施するIRRでは、特定のコミュニティに依存する
プライベートデータではなく、広くデータを参照できるパブリックデータが
求められています。このため、JPNICでIRRのサービスを実施する際の判断基
準として、パブリックデータをインターネットの運用にどのように生かせる
かという点が、一つのポイントとなると考えられます。
これまでのIRRの歴史の中で、この「パブリック」なIRRに近いものがRADB
と言えます。IRRが分散化する前の段階におけるRADBの利用方法を考察する
ことで、パブリックデータの価値が見えてくることが考えられます。
IRRが分散化する前の段階では、RADBはCAnetやMCIをはじめとする他のIRR
と比べて、非常に多くのデータを蓄積していました。この段階で、RADBのユー
ザは主に以下のような利用を行っていました。
1) 経路情報のPrefixやAS-PATHを利用した、フィルタリングの基礎情報の
生成
2) 特定のPrefixに対するコンタクト情報の検索
3) 不審経路の確認
当時は、RADBとMCIのIRRを参照することでインターネットのほとんどの経
路が参照できたことから、日本のISPもRADBに自ASの経路情報を登録しなけ
れば、インターネット上で経路がフィルタされてしまう懸念がありました。
また、ISPの顧客がBGPによって接続する場合には、ISPがRADBへの登録を
代行してきたため、実質的にRADBを参照すればインターネットの経路情報は
ほとんど解決可能だと思われていました(*4)。
もちろん、この段階ではあくまで、PrefixやASのフィルタを避けるために
登録されていたため、経路の優先性情報などの細かい情報はほとんど含まれ
ていませんでした。
このような環境が功を奏して、インターネットに接続されているネットワー
クのPrefixやASに関する情報、コンタクト情報が容易に取得可能になってい
たのです。
また、このようなインターネットの経路情報が十分集まっているデータベ
ースは、実際にルータで受けている経路の確認のためにも使われていました。
インターネットのルータの運用は、一部自動化されている部分もありますが、
多くの場合、人手によって行われます。これは同時にミスを引き起こす原因
でもあり、ミスオペレーションなどによって、時として他のASのPrefixや自
分が割り当てられていないAS番号の経路などをインターネットに流してしま
うということがあります。もちろん、このほかにも、悪意をもって他のISP
の経路を流し、インターネットを混乱させるということもあります。
このような場合、RADBはその膨大なデータ量から、その経路は意図されて
インターネットに広告されているのかを確認をするための台帳としての役割
も果たしていました。
現時点でのIRRのデータ、特にRADBなどのパブリックデータは、IRRの分散
化や長期間に渡ってデータが未更新となることなどによって、以前ほどの効
果は得られません。しかし、パブリックデータとして、インターネットの経
路情報の台帳となるほどのデータが参照できるようになれば、運用上、非常
に有用なデータベースとなることには間違いないでしょう。
(*4)実際は他のIRRも合わせて参照しなければ解決は不可能でした
6.5 常に最新のデータとするための構造
6.4節で触れていますが、IRRのデータにはもう一つ大きな問題があります。
IRRは、RAプロジェクトの発足以来、RADBを中心としてデータが蓄積されて
きました。IRRに登録されたデータは基本的には、期限という概念がありま
せん。このため、一度登録されたデータは、そのデータの管理者が意識的に
更新しなければ、永遠に残ってしまいます。この状況は、以下のような問題
を引き起こします。
1) IRRに登録されているデータと実際の経路とのミスマッチが起こってし
まう
2) アドレスの管理者が変更となった場合でも、古いデータが有効のまま
残ってしまう
3) 実際に流れていない経路に相当するデータが残ってしまう
このような状況は、RADBのような古くから運用しているIRRにはよく見ら
れる状況で、これらのデータの残留によって、IRRがインターネットの台帳
としての役割が果たせなくなってしまいます。
つまり、IRRを台帳として機能させるためには、(1)インターネットのフル
ルートに相当する情報を参照可能にし、(2)古いデータが残留しないような
仕組みを実装しておくこと、が必要になります。
古いデータが残留しないようにする仕組みとしては、IRRの制度的なアプ
ローチと運用的なアプローチがあります。
制度的なアプローチとしては、MeritがRADBの年間利用料という形で、課
金を始めたことが代表的な例と言えるでしょう。利用に関して課金を始める
ということは、利用料を支払わなければ登録しているオブジェクトは削除さ
れるということに他なりません。このため、課金をすることで、ユーザに
「サービスを利用している」という意識を植え付け更新を促す効果と、利用
しない場合(料金を支払わない場合)は、オブジェクトを速やかに削除し、
古いデータを残さない、という効果が得られます。
しかし、料金さえ払っていれば古いデータは蓄積されることに他なりませ
んので、一定の期間間隔で登録オブジェクトが正しいものかどうかを確認す
る必要があります。IRRのサービスを考えた場合、非更新に対する罰則をつ
けることは困難です。このため、IRRの運用上の仕組みとして、登録者に自
動的に更新を促す仕組みと、更新されない情報について自動的に削除される
ような仕組みが必要となります。
当チームでは、このデータ更新を促す仕組みとして「IRRオブジェクトガー
ベージコレクタシステム」を利用することを検討しました。このシステムの
詳細と結果については、8.3節「IRRオブジェクトガーベージコレクタシステ
ム」で説明します。
6.6 IRRデータミラーリングにおける問題点(個人情報保護)
IRRは基本的にスタンドアロンなシステムとして運用されてきました。し
かし、他のIRRが持つデータを交換することで、お互いのデータの補完やバ
ックアップを目的とした、任意のIRRとのミラーリングの仕組みが構築され
てきました。
現在のミラーリングでは、IRRのデータベースをFTPでそのままダウンロー
ドして、そのデータを基準にしてNRTMを利用してデータをミラーリングして
います。この手法では、ミラー先に対してデータを振り分けており、個々の
情報に対するフィルタなどを通して受け渡す手段は現段階ではありません。
IRRでは、コンタクト情報や管理者情報、技術者情報など様々な個人情報
に関連する情報を扱います。現在では、Roleオブジェクトの登場などによっ
て、その情報を会社や組織とすることが可能ですが、個人情報が含まれてい
ることには変わりありません。
近年、個人情報は特に慎重に扱われるべき情報となってきています。これ
は、日本ばかりではなく欧米などでも同じです。APNICやRIPE NCCなどでも、
個人情報に関するデータの受渡しについては、AUP(Acceptable Use Policy)
などの書類にサインしなければならないなど、慎重に扱われる傾向にありま
す。
このような情報保護の観点は、当然IRRのデータに対しても同じです。し
かし、現状では、先にも述べたように、IRRのデータはFTPなどで容易に受渡
しが可能となっています。
情報の保護と運用の利便性は常に衝突する要素を持っています。例えば、
データから個人情報などを抜き取った場合、運用の利便性が失われてしまう
可能性も考えられます。
IRRは本来、IRRにデータを登録させて、インターネットの運用上で必要な
最低限の情報をデータ中に記録させることに意味があります。最低限の情報
とは、コンタクト情報(管理者、運用者などにコンタクトするために必要な
情報)と経路情報(Prefix, AS番号など)を指します。逆に考えれば、これら
の情報が十分保持できれば良いことになります。しかし、これらの情報とし
て公開して良いものかどうかというのは、各登録者が判断すべき問題である
ので、IRRの運用者側としては、各自の判断に任せる旨を啓蒙することが最
善の努力となるでしょう。
問題は、これだけではありません。ミラーリングをするということは、そ
の情報が他のIRRにコピーされると言うことです。コピーされた情報は、さ
らにコピーされ、その先のIRRにミラーリングされる可能性があります。
IRRのデータの信憑性を高める観点からも、無限にコピーされることは望
ましくありません。コピーを繰り返される過程で、データの改ざんや、変形
なども考えられます。また、自分が出した情報が今どこで利用されているか、
という管理もできなくなります。IRRの運用者としては、最低限、自IRRの
データがどこで利用されているかということは知っておくべきです。このた
めには、ある一定のミラーリングの制限が必要になります。
これらの個人情報保護の観点、そしてデータの無限コピーの問題などを解
決するために、いくつかのIRRではミラーリングを厳しく制限しています。
例えば、RIPE NCCの運営するIRRでは、ミラーリングを実施するに当たって、
RIPE NCCが作成したAUPにサインをした上で、RIPE NCCのIRRから直接ミラー
リングを実施しなくてはなりません。
おそらく、JPNICでIRRを実施する場合でも、このようなミラーリングを制
限する施策は必要になるでしょう。このとき、そのポリシは日本の実情や法
規制などに合わせて作られるべきです。
しかし、そうすることによって、他のIRRとのミラーリングポリシと異なっ
てしまうことを配慮しなくてはなりません。
6.2節では、IRRのミラーリングモデルについて述べていますが、この構造
では、全てのIRRのデータは上流のIRRから受け取ることになります。例えば、
その上流から受け取るIRRの情報について、全ての情報のソースごとにAUPに
サインをしないといけなくなると大変な作業量になります。
理想的には、ある一定のパブリックIRR運用コミュニティにおいて、共通
のミラーリングポリシを持ち、そのなかで情報保護の共通の条文を実装し、
データのミラーリングを実施する場合は、その共通のミラーリングポリシを
実装したAUPにだけサインをする、という環境が望まれます。
6.7 IRRデータミラーリングにおける問題点(一括ミラーParent/Child)
先の6.2節「理想的なIRRミラーリングモデル」でも述べましたが、階層構
造を利用したミラーリングを実施した場合でも、現状のIRRのミラーリング
では、あくまで1対1の構造であることには変わりありません。例えば、我々
JPNICのIRRサーバ(以下、JPIRR)が、APNICを経由して他のインターネットレ
ジストリのIRR情報をミラーリングを通じて取得する際に、ミラーの張り先
が全て同じAPNICだとしても、あくまでミラーリングの設定は、互いのIRRの
ソース1つ1つに対して実施する必要があります。つまり、同一の相手先から
3つの異なるIRRソースの情報を取得する場合には、3つのミラーリング設定
が必要になります。
この方法では結局、当チームが理想的なミラーリングモデルとして提唱し
ている階層構造のモデルを構築できたとしても、あくまでミラーリングは
1対1のままであり、せっかくの階層ミラー構造のメリットが損なわれてしま
います。そのため、よりスケーラブルで柔軟、かつ今後の拡張性も考慮した
実装が求められるのは、言うまでもありません。そこで当チームで検討を重
ねた結果、この問題を解決する1つの方法として、BGPのルートリフレクタに
類似したような機能、つまり、IRRのミラーリングにおいて、親と子の関係
を実装し、より効率的なデータ交換を可能とするような方式が提案されまし
た。
ここでは、例として、階層構造を用いたミラーリングに基づき、JPIRR
(a.a.a.a)が、APNIC(b.b.b.b)を通じて、APNIC, RIPE NCC(c.c.c.c),
ARIN(d.d.d.d)のIRR情報を取得する場合を考えてみます。(括弧書きで記述
されている(a.a.a.a)などは、IRRサーバの実IPアドレスのことを表します)
現状では、それぞれ以下のように、まずJPIRRは、APNIC, ARIN, RIPEの3
つのIRRソースに対して、ミラーリングの設定をする必要があり、対する
APNIC, RIPE, ARINにおいても、同様に、APNICを通じたJPIRRへのミラーリ
ング設定が必要となります。
(現状)
以下は、JPIRR上での、APNIC, RIPE, ARINに対するミラーリング設定例
を示します。取得対象先アドレスは、全てAPNIC(b.b.b.b)に対して実施
されます。
jpirr% irr_database apnic mirror_host b.b.b.b 43
jpirr% irr_database ripe mirror_host b.b.b.b 43
jpirr% irr_database arin mirror_host b.b.b.b 43
また以下は、APNIC, RIPE, ARIN上での、JPIRRに対するミラーリング設
定例です。
APNICは、JPIRRの情報を直接ミラーリングすることで取得し、RIPE,
ARINは、APNICを通じてJPIRRの情報を取得します。
apnic% irr_database jpirr mirror_host a.a.a.a 43
ripe% irr_database jpirr mirror_host b.b.b.b 43
arin% irr_database jpirr mirror_host b.b.b.b 43
この方法では、JPIRRは、仮に全てAPNICを経由した情報取得であったと
しても、APNIC, RIPE, ARIN全てのIRRソース先に対して、ミラーの設定を
実施する必要があります。今後、RIRが追加されて、その際ミラーの設定
が必要となった場合や、APNIC管轄下にNIRが追加された場合などにも、そ
の都度、追加のミラー設定を互いに施す必要が出てきます。
そこで、このような状況を改善し、より発展的な効率の良い実装として、
IRRのミラーリングの概念に、「親」と「子」の関係を導入した実装を考
えてみます。ここでは例として、APNICを「親」、JPIRRを「子」とした場
合のミラーリングを考えてみます。
(検討案)
jpirr% irr_database apnic mirror_host b.b.b.b parent
apnic% irr_database jpirr mirror_host a.a.a.a child
JPIRRは、APNICを「親」としたミラーリングを実施します。逆に、
APNICは、JPIRRを「子」としたミラーリングを実施します。これにより、
JPIRRは「親」であるAPNICを通じて、APNICが「子」に対して提供可能な
全てのIRRソースの情報を提供することを可能とします。例えば、APNICが
他のIRRとミラーリングを実施し、その情報をJPIRRに提供可能となった場
合には、わざわざミラーの設定をする必要なしに、自動的にその情報が
「子」に対して伝達されることになります。この場合、あらかじめ、RIR
とNIR間で、互いにそのような取り決めを事前にしておくことが前提とな
っています。
また、他のRIPEやARINにおいては、お互い対等な立場でミラーリングを
実施することにより、特にミラー先を意識することなく、それぞれが保有
しているIRRの情報を一括して全て交換することを可能とします。
このように、parent/childモデルを実装することにより、IRRの階層ミ
ラーリング構造において、より現実的なミラーリングを実施することが可
能となります。
また、上記の実装とは別に、BGPの「no-export」や「no-advertise」の
ような実装も、場合によっては必要となるかもしれません。これまで述べ
てきた、parent/childモデルにおいては、互いが保有している、配送可能
な全てのIRRの情報を、信頼できる相手(親と子)と一括して交換するよう
な実装が実現されるものです。
しかし、場合によっては、あるIRRまでにその情報を限定したい場合や、
あるIRRから先には全く配送されないで欲しいといったケースも出てくる
かもしれません。そのような場合には、例えばミラーリングにより、相手
のIRRの情報を受け取る際に「no-export」のような機能を付与したり、あ
る特定のIRRとだけに情報のやり取りを限定するために、「no-advertise」
のような機能を付与する実装も必要となるかもしれません。
6.8 IRRのセキュリティ
IRRにおけるセキュリティを考慮するに当たっては、「IRRが果たす役割」
を考えます。そして、その役割を満たすために何を守らなくてはならないの
かを定義し、対策を打つことでIRRのセキュリティを高めます。
IRRの果たす役割は、実際にインターネット上に流れる経路に対する台帳
としての役割とそれら経路に関する情報の提供という役割があります。これ
らの役割を言い替えると、前者は「ルーティングのリスクに対するIRRの役
割」であり、後者は「安全な情報提供と情報登録を(ユーザに対して)実施さ
せる役割」と言うことができます。そこで今回は、この2点についてフォー
カスを絞り検討を実施しました。
これまでの検討においては、その多くが情報そのものの信憑性(意味的な
正当性)について実施されてきましたが、上記の2点にフォーカス絞るため
情報そのものよりも手続き的な信憑性(形式的な正当性)に注目しています。
この「形式的な正当性」とは、登録されている内容が正しいかどうかと言う
ことではなく、登録される際に、その登録者が正しいかどうかという認証の
問題と、登録される内容がいかに検証されるべきかを指しています。
この章では、これらの前提条件のもと、ルーティングとIRRの役割、さら
にその役割に対する登録情報の正当性について検討した内容について述べ、
最後に、登録情報の正当性をどのような仕組みで実現するかについて述べま
す。
6.8.1 ルーティングとIRRの安全性
IRRの安全性を検討するに当たっては、「IRRの目的は何か」を定義し、そ
の目的を阻害する要素を分析する必要があります。
IRRとは、ルータによる適切なルーティングを助けるための適切な参照情
報を提供することが目的です。このため、IRRの安全性を検討するには、こ
の目的が阻害される脅威に対する検討が必要となってきます。
以下は、この定義に準じた形で、検討項目を明らかにするための簡単なリ
スク分析を行います。分析は、(a)IRRの目的(要件の定義)、(b)目的を達成
するために守るべき資源の定義、(c)それら資源に対する脅威の分析の3段階
で脅威(いわゆる、リスク)を分析します。
(a)IRRの目標とする要件は何か
・該当経路のルーティングを行うための参考情報の提供
・適切な経路情報を入手するための参考情報の提供
・適切な範囲で経路情報の交換を行うための参考情報の提供
(b)IRRが守るべき資源は何か
・各ルータが持つ正しい経路情報
・経路情報の正しい伝達
・意図した通りのAS-PATHの伝達
(c)資源に対する脅威は何か
・変更された経路情報の伝達
・意図された変更
・意図されない変更
・根拠のない経路情報の伝達
・経路情報の意図通りでない伝達
経路情報に対する脅威(上記(c)であげた脅威)から守るためには、いかに
伝達されてくる経路情報が正しいかを検証する必要があります。しかし、伝
達されてくる経路情報は、BGPのPeerを張っているルータが正しいかどうか
というような単純な問題ではなく、Origin ASが発行した経路情報が、伝達
過程のASの中で、そのASの意図通りに加工され、複数の経由ASの意図が正し
く盛り込まれ、最終的なASに伝達されていることを検証する必要があります。
このような検証を実施できるようにするためにIRRを利用するには、IRRは、
経路情報の元来あるべき内容と、経路情報流入の根拠を調べられるような情
報源になっている必要があります。
そして、この場合のIRRの安全上のあり方は、ルータの挙動とIRRの登録情
報が密接に関わる場合に限られています。公共的なIRRの場合は、登録情報
がASに対して強い影響を及ぼさないことがあります。例えば、インターネッ
トレジストリの割り振り情報とIRRの登録情報が対応しているべき、といっ
た要件がどれほど強く適用されるべきなのかを検討する必要があります。
一方、IRRの利用者の観点では、登録情報の正当性に対する依存が発生し
ます。これは他者の登録した情報が、どの程度正当なのかがわからなければ
参照の意味が薄れてしまうからです。例えば弱い認証方式を利用して情報の
登録を行った利用者は、他者の情報の登録に対しても弱い保護しか期待しな
くなります。弱い認証方式が破られ、書き換えられている可能性を考慮しな
がら参照することは、ルータの管理者にとって上記の脅威を避ける手段とし
ては弱いものになります。その結果、メールなどの他の手段を取らざるを得
ず、IRRの効力が薄れてしまいます。
これらのことを考えると、IRRに求められる安全性を決める要素には下記
のものがあることがわかります。
・意図通りのルーティングのための安全性の観点
IRRの登録情報がASに及ぼす影響の強さを想定する必要がある
・IRRの利用者の観点
利用者のIRRに対する依存度を想定する必要がある
つまり、プライベートなIRRに比較して公共的なIRRは蓄積される情報の性
質から、IRRの登録情報がASに及ぼす影響の強さは低いと想定した場合、IRR
の安全性は、利用者のIRRに対する依存度によって決定されるということに
なります。また、依存度は、不慮の操作の禁止、悪意のある操作の不可能性、
適正な利用を促す仕組み(制約事項)などの対策を打つことで高めることが可
能ということになります。
6.8.2 登録情報の安全性
前節までは、IRRとルーティングシステム全体を考慮したうえでの安全性
について検討してきました。ここでは、さらにフォーカスを絞って、IRRへ
の情報登録とそこからの情報提供に関する安全性に検討を進めます。
一般に「安全性」と呼ばれる性質の中には、いくつかの要素があります。
ここで、IRRにおける安全性という観点で考えると、その登録情報が安全に
提供されことや、登録情報が正当性、可用性(availablity)を持ったもので
あるといった点が重視されると考えられます。その他に、機密性の要素も重
要な要素の1つではありますが、公共的なIRRでは、認証情報のような一部の
情報を除くと、あまり重視されない要素であると考えています。
本節では、登録情報の正当性を分類し、「形式的な正当性」について述べ
ます。次に、形式的な正当性が失われる場面と原因について述べ、対策を検
討します。
IRRにおける登録情報の正当性は、まずIRRへの登録内容が正しいこと、そ
して、登録や参照手続きの処理が確実であること、この2つが両立してはじ
めて成り立ちます。登録や閲覧手続きが確実であるとは、正しい登録者によ
る登録結果が、その通りに誰もが閲覧できるような状態のことを指します。
ここでは、内容の正しさを「意味的な正当性」と呼び、登録や閲覧手続きの
確実性に基づく正当性を、「形式的な正当性」と呼ぶことにします。
形式的な正当性が失われる状況を挙げると、以下のようになります。
・登録情報自体の正当性が失われる状況
‐意図しない変更・削除
・災害
・サーバ・クライアントのバグ
・クライアント・ユーザへのなりすまし行為
‐登録時の不正
・サーバへのなりすまし行為
・クライアント・ユーザへのなりすまし行為
・利用上の登録情報の正当性が失われる状況
‐参照時の不正
・サーバへのなりすまし行為
・伝送路での書き換え(参照時、ミラー時)
これまで、RPSLでは「登録時の不正」に着目し、CRYPT-PW, PGP-KEYと言っ
た認証機能を用意していました。しかし、形式的な正当性という見方をする
と、登録者の認証だけでは、「意図しない変更・削除」や「参照時の不正」
の対策をとることができません。これらの状況には、登録時以外での登録情
報の変化が含まれており、登録者の認証だけでは、検出や回避することはで
きないためです。
つまり、登録情報の形式的な正当性を確認する仕組みが必要になります。
例えば、登録情報にハッシュ値を付加し、閲覧時に確認するといった方法で
す。登録者との関連性を保障するため、ハッシュ値に電子署名を加える方法
が考えられます。しかし、RPSLではオブジェクトに電子署名を加える書式は
提供されていません。参照のために、Whoisプロトコルの代わりにhttpsを利
用したとしても、「参照時の不正」や「サーバへのなりすまし行為」を検知
することができるだけで、ミラーリングを行っているときの伝送路での書き
換えを防ぐことはできません。
今後、形式上の正当性を確保するためには、CRISPやEPP(Extensive
Provisioning Protocol)において電子署名を利用した登録情報の保護機能が
必要になると考えられます。しかし、そのためには認証情報(署名鍵)の管理
や登録の手続きなどを、今後検討する必要があります。
6.8.3 IRRのセキュリティ向上のための今後の対応
IRRのセキュリティを検討するために、いくつかの言葉の定義やIRRにおけ
る安全性について基本的検討から行いました。
これらの検討の中で、登録情報の形式上の正当性について検討を進めまし
たが、その一方で、意味的な正当性の向上についてはほとんど検討がされて
いません。また、IRRに必要な安全性を決める要素として、ルーティングの
安全性とIRRの利用者の観点を挙げましたが、これについても、運用者やIRR
情報のミラーリング時の検討が行われていません。さらに、形式的な正当性
を確保するためには、登録時の認証ではなく、登録された情報を保護する仕
組み(電子署名)を利用する仕組みについて述べましたが、現行のRPSLでは電
子署名を利用することはできません。
IRRに関するセキュリティの議論は、ルーティングシステムとの関連の中
で検討する必要があるため、検討のポイントはルーティングシステム自体へ
とずれてしまいがちです。今後は、IRRそのもののセキュリティの検討と、
ルーティングシステムと関連させたセキュリティの検討に分割すると共に、
今回の検討で残されている検討項目をさらに検討していく必要があります。
7. IRRの運用実績とその結果
本章では、当チームが2002年の夏より実施してきた、「JPNIC IRR試験サ
ービス(以下、JPIRR試験サービス)」の運用実績と結果について報告します。
また、サービス運用上やシステム上の問題点などについても、合わせて報告
します。
7.1 JPNICにおけるIRR試験サービス
JPIRR試験サービスは、世界的なIRRにまつわる状況の変化に伴い、日本国
内のユーザを対象に、JPNICが試験的に運用を開始した日本唯一の公共的な
IRRサービスです。このJPIRR試験サービスは、IRRサービスを日本国内のイ
ンターネット運用のために提供する効果を測定するために開始されたもので、
2002年夏から現在に至るまで、当チームを中心に運用されてきました。
日本では、NTTやSINETなどをはじめとして、独自にIRRサーバを立ち上げ
て運用してきたプライベートなIRRもいくつかありますが、一般に日本国内
でのIRRの運用経験は非常に乏しく、JPNICにおいて、その運用経験やノウハ
ウを取得することも、本サービスの目的の1つでもあります。また、大きな
目的の1つとして、当チームが提唱している、階層構造を利用したIRRのミラー
リングモデルの検証を通じて、日本におけるIRRの必要性を検討するという
ものがありました。
JPIRR試験サービスでは、具体的には、以下の4つのサービスを提供してい
ます。
・登録サービス
・検索サービス
・ミラーリングサービス
・ユーザサポート
登録サービスは、JPIRRユーザにIRRの各オブジェクトを登録・変更などを
してもらうものです。
検索サービスは、WHOISを利用した検索により、IRRに登録されている情報
を参照するものです。利用可能ユーザを特に限定せずに、一般に対して広く
提供を行っています。
ミラーリングサービスは、日本国内のLIRに対して、JPIRRに対する単方向
ミラーリングを許可するものです。
ユーザサポートでは、対象を特に限定せず、広く一般からも質問を受け付
けています。JPIRR試験サービス開始当初は、IRRとは何か、といった基本的
な質問にはじまり、IRRの各オブジェクトを重複して複数のIRRに登録するこ
とについての問い合わせなど、様々な質問が寄せられました。
またこのほかにも、実際にIRRのユーザの間で情報交換を可能とする、IRR
ユーザ情報交換メーリングリストを開設し、一般の方々同士での情報交換も
可能とするようなメーリングリストも運用してきました。
このように、IPアドレス管理指定事業者(以下、指定事業者)を中心とした
インターネットの運用に深く携わる方々向けにJPIRR試験サービスを提供し、
日本国内において広くIRRの利用を促進することとなりました。また実際に
サービスを提供し、運用経験を取得していく中で、いくつか問題点も生じま
したが、それらの詳細については、10章「JPNICにおけるIRRサービス」で報
告します。
7.2 JPIRRサーバのシステム構成
JPNICで設置しているIRRサーバ(以下、JPIRRサーバ)では、7.1節に記載し
たIRRとしてのサービスの他に、統計情報の収集(7.6節参照)や、IRRの利用
に伴う付加サービス(8.2, 8.3節参照)などを提供しています。また、試験サー
ビスではありますが、利用者の情報が登録されているため、登録情報のデー
タベースのバックアップを取るためのサーバを用意しています。この節では、
現在のJPIRRサーバのシステム構成を紹介します。
7.2.1 JPIRRサーバのソフトウェア構成
JPIRRサーバには、上記のようなサービスを提供するため、そしてサーバ自
体の管理のために、以下のような複数のソフトウェアを利用しています。
・IRRサービス提供に必要なソフトウェア
IRRd
MTA(postfix)
PGP
FTP
・IRRサービス利用に伴う付加サービスに必要なソフトウェア
Perl
Apache
RRD Tools
PostgreSQL
Tomcat
JDK
・サーバの管理・運用に利用されるソフトウェア
OpenSSH
Net-SNMP
これらのソフトウェアで起動しているプロセスは、JPNICのサーバ管理ポ
リシに従い、JPNICにて監視されています。
7.2.2 JPIRRサーバのハードウェア構成
現在のJPIRRサーバは、IRRサービスを継続的に提供するため、利用者に公
開しているメインJPIRRサーバと、バックアップJPIRRサーバの2台構成となっ
ています。このバックアップJPIRRサーバにも、前節で挙げたソフトウェア
がメインJPIRRサーバと同様にインストールされており、メインJPIRRサーバ
に障害が発生した際に、遠隔操作で復旧が可能な状態となっています。
また、JPIRRがAuthoritativeとなるデータベースを含め、JPIRRが保有す
るIRRデータベースは、バックアップJPIRRサーバがメインJPIRRサーバから
NRTMで情報を受け取っています。
このように、JPIRRではハードウェアのバックアップと共に、JPIRRサービ
スのデータベースについても、バックアップJPIRRサーバでバックアップを
実施しています。
7.3 他IRRとのミラーリング
JPIRR試験サービスにおけるミラーリングは、当チームが提唱してきた、
階層構造を用いた理想的なミラーリングモデルに基づき、公共的なIRRとし
てのミラーリングを実施してきました(図7-1)。
+- +----------------------------------+
| | |
(**1) +----------+ +----------+ +----------+
| | APNIC |-----| RIPE NCC |-----| ARIN |
+- +----------+ +----------+ +----------+
| |
(**2) +--+--------------+----------------+
| | | |
+- +----------+ +----------+ |
| JPNIC | | NIRs | |
+- +----------+ +----------+ |
| | |
(**3) +-+--------------+---------..... |
| | | |
+- +----------+ +----------+ +----------+
| LIRs | | LIRs |...... | LIRs |
+----------+ +----------+ +----------+
(**1) Inter-RIR Mirroring
(**2) Inter-IR Mirroring
(**3) Member Mirroring
図7-1 IRRシステム全体のミラー構成
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
(**1)で示されたInter-RIRミラーは、RIR間で相互に実施されるミラーリ
ングで、互いにフルメッシュでの情報交換が実施される部分になります。
(**2)のInter-IRミラーは、RIR/NIR間で実施されるミラーリングで、APNIC
やRIPE NCC, ARINなどのRIRが運用しているIRRとJPIRRとの間で実施される
ミラーリングが、まさにこのInter-IRミラーに位置付けられます。ARIN地域
においては事実上、RADBがその役割を担っていることから、当チームでは、
RADBとのミラーリングを実施してきました。
(**3)のMemberミラーでは、JPIRRの情報を受けるだけの単方向ミラーリング
のことですが、実際に試験サービス期間中には、このMemberミラーリングの
リクエストはありませんでした。
このように、APNIC配下に属するJPIRRサーバにおいては、まず、APNICと
の間で相互にミラーリングを実施し、他のRIRに属するRIPEとRADBの情報は、
APNICを経由する形でのミラーリングの実現を目指しました。
しかし、ここで問題としてあげられたのは、管理する情報の扱いなどの
IRRサーバの運用ポリシが異なるため、ミラーを開始するまでに多少の時間
を要する場合もあったことです。例えば、互いに情報を交換するにあたって、
そこで受け取った情報に変更を加えないことや、受け取ったデータをその先
のミラーリング先に対して出さない、などについて、ミラーリング前にAUP
を確認を交わす必要がありました。RIPE NCCにおいては、6.6節で取り上げ
た、個人情報保護の問題があり、他のIRRを経由した形でのミラーリングは
まだ実現できていません。
7.4 運用者向けマニュアルの整備
JPNIC事務局が、現在のJPIRR試験サービスを継承することを想定した場合、
当チームからJPNIC事務局へJPIRRサーバの運用・保守を移管することが想定さ
れます。そのため、これまでの運用経験をもとにIRRサーバの運用者向けマ
ニュアルを整備しました。本マニュアルは、IRRdをIRRサーバソフトウェア
として利用することを前提として作成されています。
この運用者向けマニュアルは、以下の章から構成されています。
1. IRRdについて
2. IRRの各オブジェクトの登録・管理方法
3. IRRdのオペレーション
4. サーバ運用
なお、本マニュアルはIRRd2.1.5をもとに作成していますが、IRRdはバー
ジョンによって多少の動作が異なるため、本マニュアルはバージョンの変更
に伴い更新される必要があります。
7.5 利用者向けマニュアルの整備
現在のところ、IRRへのオブジェクトの登録は、トランジットISPが代行で
登録するといったケースが多く、トランジットを購入しているISPでは、IRR
への登録方法などについて、意識をしていません。
このような状況を背景に、IRRサービスを初めて利用する人を対象に、利
用初心者向けのオブジェクト登録マニュアルを作成しました。JPNICホーム
ページの以下のURLで、このマニュアルを公開しています。
「JPIRR 初心者用登録マニュアル 」
http://jpirr.nic.ad.jp/jpirr_resistory.html
現在は、下記の内容について登録方法を記載しています。今後、登録が推
奨されるオブジェクトが増えた場合には、適宜マニュアルを変更していく必
要があります。
・Maintainerオブジェクト
・Routeオブジェクト
・AS-Setオブジェクト
・Aut-Numオブジェクト
・Roleオブジェクト
・Personオブジェクト
7.6 利用実績(統計情報)
JPIRR試験サービスでは、利用実績を把握するために以下の統計情報を取
得しています。以下では、主要なオブジェクトの登録状況を報告します。
JPNICホームページの以下のURLで、以下で報告する各オブジェクトの登録状
況の推移を公開しています。
「JPIRRオブジェクト登録統計」
http://jpirr.nic.ad.jp/stat/index.html
Maintainerオブジェクトは、試験サービス開始当初、10件も満たない数
でしたが、登録件数は順調に増え、現在(2004年3月)では、32件のMaintainer
オブジェクトが登録されています。
Routeオブジェクトについては、試験サービス開始当初には、ほとんど登
録がありませんでしたが、多数の経路を保有するISPの登録により、200件を
超えるようになりました。これ以降、微増減を繰り返し、現在(2004年3月)
では、268件のRouteオブジェクトが登録されています。
AS-Setオブジェクトは、試験サービス開始当初は、わずかな登録でした
が、2002年末にかけて10件程度の登録が行われるようになりました。その後、
微増して、現在(2004年3月)では、15件のAS-Setオブジェクトが登録されて
います。
Aut-Numオブジェクトは、試験開始当初から10件程度の登録がありました。
2004年2月に導入した、IRRオブジェクトガーベージコレクタシステムの影響
によりオブジェクト数の減少が見られますが、現在(2004年3月)では、16件
のAut-Numオブジェクトが登録されています。
今回の統計情報では、JPIRR試験サービスを利用するユーザが少ないこと
もあり、十分な情報が得られたとは言えませんが、オブジェクトの登録件数
に関して、わずかながらも増加傾向にあることがわかりました。今後こうし
た統計情報の収集を継続的に行うことは、IRRの利用状況の把握のために必
要であると言えます。
7.7 サービスの運用における問題点および改善点
現在のJPIRR試験サービスは試験運用ということから、品質および継続性
を保証していません。また、試験運用開始から提供しているサービスの種類
も増え、今まで検討する必要のなかった項目についても今後は検討する必要
性が出てきました。本節では、2003年度に行ったサービス運用面での改善と
共に、今後の課題となる問題点を列記します。ここでは問題点と完了した改
善点を記述するに留め、今後の改善案としては10.4.4節で記述します。
7.7.1 JPNIC IRRサービスの信頼性
JPIRRサービスを正式もしくは試験継続とする場合、IRRサービスの信頼性
を向上するため、サーバおよびネットワークの監視、データのバックアップ、
障害時の対応方法、ユーザからの問い合わせ対応を提供する必要があります。
JPIRRサービスの正式化を視野に入れ、今年度の改善点と正式サービス開
始の際に検討が必要となる項目について、以下にまとめました。
○サーバ・ネットワークの監視
JPIRRサーバはJPNICの監視サーバによる稼動監視、各プロセス監視を
実施しています。昨年度まではメインとバックアップのJPIRRサーバ同
士での監視を実施していましたが、現在はJPNICサーバ群の1台として、
JPNICの監視ポリシに従って監視されるように改善されました。
○データのバックアップ
現在は、バックアップJPIRRサーバにて、JPIRRのデータベースをNRTM
でバックアップしています。正式サービスとする際はこのような冗長構
成を取り、復旧方法を確立する必要があります。
○障害時の対応方法
JPIRRサーバに障害が発生した場合にバックアップJPIRRサーバへ切り
替えることで、遠隔でも迅速に復旧ができるように改善されました。し
かし、障害時の周知についてはまだ決定しておらず、今後検討する必要
があります。
○利用者からの申告対応
当チームが主に対応していた問い合わせへの対応が、2003年度より
JPNIC事務局へ移行しました。また、移行に合わせて窓口などをJPNIC事
務局側へ変更しました。
7.7.2 他IRRデータ参照サービスの信頼性
現在、RADB, APNIC, RIPEとミラーリングを実施することにより、JPIRRサー
バから他のIRRデータベースを参照することができるようになりました。現
在は、ミラーリング状態の監視を行っていませんが、正式サービスとなる際
には、この状況を監視し、ミラーリングが失敗した際に他IRRへ連絡する必
要があります。
ミラーリング先IRRの設定変更や中継ルータの構成変更などにより、ミラー
リングが失敗する可能性は十分にあります。また、ミラーが確立できていた
としても、そのミラーリングにより取得した情報が、最新ではない可能性も
あります。このため、ミラーしている他のIRRのデータベースが正しくJPIRR
上で参照できるかどうかを監視することが重要です。
7.7.3 他のIRRで参照されるJPIRRデータベースの信頼性
他のIRRで参照されるJPIRRデータベースの信頼性とは、JPIRR上に登録さ
れたオブジェクトが、他のJPIRRデータベースを受け取っているIRRでも正し
く参照されることです。例えば、RADBであるならば、JPIRRへ登録したオブ
ジェクトがNRTMによってRADBへ必ず反映されることが重要となります。
しかし、現在はこの監視は実施していません。この、他IRRで参照される
JPIRRの情報が最新の情報でなかったことは、ユーザからの申告で判明した
ケースもありました。
7.8 IRRシステムの問題点と改善案
7.7節では、JPIRRの正式サービス化に伴う問題点を指摘しましたが、IRRd
サーバソフトウェア自体についても、運用中にいくつかの問題点が見つかり
ました。本節では、それらの問題点を挙げていきます。
7.8.1 認証・個人情報を有するオブジェクトの扱いについて
IRRには、RoleオブジェクトやPersonオブジェクトに代表されるように、
プライバシーに関連する情報が含まれています。また、Maintainerオブジェ
クトには、オブジェクトの登録認証を行う際に使う情報が含まれており、無
制限に参照されることやデータベースがミラーされることなどが問題となっ
ています。この内容をどのように扱うかは、当チームだけでなくMerit(RADB)
やAPNIC, RIPE NCCでも取り組みが進んでいます。
MeritによるIRRdの改修の結果、Maintainerオブジェクトの認証部分は隠
蔽されるようになりました。これにより、CRYPT-PWの文字列を隠すことが可
能となります。この改修はベータ版で行われましたが、JPIRRでも動作確認
を行い、基本的な動作には問題がないことを確認しています。
APNICではRIPE-db version 3を利用してIRRサービスを提供していますが、
そのソフトウェアに改修を加え、IRRとして必要な情報のみをミラーして送
信する方法を検討しています。これはMaintainer, Role, Personなどのオブ
ジェクトを他IRRに転送しないような仕組みとなる予定です。
RIPE NCCでは、RIPE-db version 3.1.1でAC_AUTO_SAVE, AC_LOAD,
AC_SAVE_INTERVALといったオブジェクトの参照頻度を管理する項目を加えた
り、X.509認証の機能追加を計画したりしています。また、Authフィールドが
NONEであるMaintainerオブジェクトの削除を進めるなど、ソフトウェア的な
改修とオペレーション的な改修の両方から、認証や個人情報の強化を意欲的
に進めています。
これらの流れの中、JPIRRでは当初からCRYPT-PWによる認証を推奨し、
Maintainerオブジェクト新規登録の際に、ユーザへ注意を促してきました。
その結果、Maintainerオブジェクト中のAuthフィールドにNONEやMAIL-FROM
を利用しているユーザは少数に止めることができました。また、PGPにも対
応したことで、今後はユーザにPGPでの認証へ移行を促すような案内を行う
ことも検討する必要があります。
7.8.2 IRRdソフトウェアの問題点について
JPIRRではIRRdを利用していることから、IRRdが保有するバグや仕様に大
きく影響されます。現在まで運用してきた中で、以下に挙げるような問題が
出てきたため、注意して運用を進める必要があります。必要に応じて、Merit
へ改修要望を行う必要があります。
○ Roleオブジェクト中のnic-hdlフィールドが参照されない
Roleオブジェクトにはadmin-c、tech-c、nic-hdlのフィールドを持ち、
登録されている個人と関連付けて登録する仕組みができています。しか
し、Roleオブジェクトのnic-hdlフィールドの情報は他のオブジェクト
にリンクされません。現在は、Roleオブジェクトの登録数が少ないため
に、特に問題は発生していませんが、注意をする必要はあるでしょう。
○ 管理者情報の多段参照がされない
Maintainerオブジェクトはadmin-c, tech-cのフィールドを持ち、そ
のフィールドがRole、Personオブジェクトのような管理者情報と一致
する場合はMaintainerオブジェクトと共に参照されます。このRole オ
ブジェクトにもadmin-c, tech-cフィールドがありますが、そこから、
Personオブジェクトがさらに参照されることはありません。この情報
については、さらにRoleオブジェクトのみで参照する必要があります。
8. IRRに関連する技術研究・調査
本章では、6章で挙げた環境改善のための検討の結果からその対策として
考えられるシステムの検討と、JPIRRにおける適応実績の報告および次世代
のIRRとして検討を進めるべきIPv6への対応に関する調査結果について報告
します。
8.1 IRRとルータを利用した経路確認システム
IRRには経路情報の台帳としての機能があります。そして、この機能を活
用した研究として、IRRとルータを利用した経路確認システムについて述べ
ます。以下に、現状のBGPの問題点と、その問題に対するアプローチについ
て述べます。
○ 問題点
インターネットのバックボーンはBGPによって経路制御されていますが、
BGPは、多くの問題点を抱えています。その問題の中に、「ブラックホー
ル経路問題」があります。
「ブラックホール経路問題」とは、あるASが本来、生成すべきでない経
路を生成して、その経路が伝播してしまう問題を指します。
これを、図8-1を用いて説明します。AS100のボーダルータであるR1は、
経路192.168/16をAS200, AS400, AS500に広告しています。これよって、
宛先192.168/16のパケットは、全てAS100に向かいます。しかし、ルータ
のミスコンフィグレーションなどによりR3が、本来、AS100が広告すべき
はずの経路192.168/16を広告してしまいます。そして、この経路がAS200,
AS400, AS500に伝播し、宛先192.168/16のパケットは、全てAS300に吸い
込まれてしまいます。もちろん、AS300には、192.168/16のアドレスを持っ
ているノードはいないので、結果的に到達性が失われてしまいます。
AS100 AS200 AS400 AS500
+--+ +--+ +--+ +--+
|R1|==192.168/16===>|R2|-----|R4|----|R5|
+--+ +--+ +--+ +--+
|
xxx 192.168/16 xxx
+--+
|R3|
+--+
AS300
図8-1 ブラックホール経路
~~~~~~~~~~~~~~~~~~~~~~~~
○ アプローチ
この問題を解決するためには、
(1) BGPルータにおいて、正しい経路とそのOrigin ASをチェックする
仕組み
(2) 正しい経路とそのOrigin ASの組を保持しているデータベース
が必要となります。
(1)のBGPルータにおいて正しい経路とそのOrigin ASをチェックする仕
組みに関しては、BGPルータと(2)で述べたデータベースとの間の通信プロ
トコルが必要になります。
(2)のデータベースとしては、(a)DNS, (b)IRRがその候補としてあげる
ことができます。(a)のDNSに関しては、以下のように経路とOrigin ASの
認証をすることが可能です。
1. bgp.in-addr.arpa.ゾーンのルートは、205/8をarin.net.にゾーン
委譲します(1)
2. arin.net.は、ASリソースレコードより、65535のAS番号と205/8の
経路を保有しています
3. arin.net.は、同時にdigex.net.に、205.0/16ゾーンを委譲してい
ます(2)
4. arin.net.から、0.205.bgp.in-addr.arpa.ゾーンを委譲された
digex.netは、ASリソースレコードにより、AS番号は2548で、
205.0/16を保有しています
;(1)
$ORIGIN bgp.in-addr.arpa.
@ SOA (...)
0 AS 0 0
205 NS ns0.arin.net.
; arin.net (2)
$ORIGIN 205.bgp.in-addr.arpa.
@ SOA (...)
AS 65535 8
0 NS ns0.digex.net.
; digex.net (3)
$ORIGIN 0.205.bgp.in-addr.arpa.
@ SOA (...)
AS 2548 16
図8-2 経路、Origin AS認証のためのDNS
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
しかしながら、DNSを利用して経路、Origin AS認証をするためには、AS
リソースレコードを定義してなくてはいけません。これは現在のDNSの実
装を変更するため、普及に多大な時間と労力を要します。この点において、
DNSをデータベースとして利用することは、現実的であるとは言えません。
そこで、IRRを上記のデータベースとして利用することを検討しますが、
IRRに関する問題として、 全てのインターネットの経路が全て登録されて
いるとは限らないという点が指摘されています。例え、IRRを利用しても、
精度の高い情報がデータベースに格納されていなければ、誤った情報をBGP
ルータに返すことになってしまいます。
こうした事態を避けるために、以下の手法を用いて、IRRデータベース
をもとにしたUnify DBを作成します。
1. 公開されているBGPルーティングテーブル(OREGON routeview,
RIPE RIS)から経路およびそのOrigin ASを抽出します。
2. routeview, RISを比較して同じ経路(PrefixおよびPrefix長が同じ)お
よび同じOrigin ASである組を抽出します。
3. IRRデータベース(現在のソースはRADB, RIPE, APNIC)も同様に、Route
オブジェクトからroute属性、origin属性を抽出し、同じOrigin ASで
ある組を抽出します。
4. 3,4を統合し、経路およびOrigin ASを記載したUnify DBを生成します。
先に述べたように、IRRデータベースとBGPルータとはネットワークを介
して通信を行うため、その間の通信プロトコルが必要になります。
通信プロトコルに要求される機能としては、以下があります。
a. BGPルータからIRRデータベースへの問い合わせメッセージ(QUERY)
b. IRRデータベースからBGPルータへの返信メッセージ(REPLY)
c. BGPルータ/IRR-DB間の生存確認(KEEPALIVE)
QUERYメッセージは、BGPルータからIRRデータベースへの問い合わせの
メッセージで、経路をキーとします。このメッセージの送出タイミングは、
BGPセッションを張っているピアからのUPDATEパケットを受信し、それが
自身の経路表に注入されるときにこのメッセージは送出されます。しかし、
route flappingのように、数秒間に数千ものUPDATEパケットが来た場合、
QUERY/REPLYは処理できません。こうしたflappingを避けるために、キャ
ッシュを導入します。
キャッシュは、一度IRRデータベースに問い合わせた経路、および返答
があったOrigin ASを一定期間保存する機能です。BGPルータは、最初にキ
ャッシュを確認して、該当するエントリがあれば、それを採用し、ない場
合には、IRRデータベースに問い合わせるような方式であれば、flapping
のような特定の経路を問い合わせる方法に関しては有効です。
REPLYメッセージは、QUERYメッセージでIRRデータベースに問い合わせ
た経路をキーにして探索して、該当するOrigin ASがあれば、その
Origin ASを返し、該当しない場合には、NULLを返します。
KEEPALIVEメッセージは、BGPルータとIRRデータベース間で生存確認を
するために利用します。30秒に一度、BGPルータがIRRデータベースに
KEEPALIVEメッセージを送信し、IRRデータベースはそれを受信すると、
BGPルータに返答します。もし、KEEPALIVEに失敗した場合は、BGPルータ
とIRRデータベース間でのコネクションが切断しているとみなします。
8.2 ポリシチェックシステム
6.4節でも触れたように、IRRには経路情報の台帳としての機能と、ASのルー
ティングポリシを記述することにより隣接AS間での経路情報交換のルールを相
互参照させる機能があります。このルーティングポリシを記述する機能をう
まく利用することで、ASの対外ルータの設定を自動的に行うことができます。
例えば、AS(甲)とAS(乙)が隣接関係を結ぶ際には双方のAS管理者がIRRに
以下のように記述することができます。
-----------------------------------------------------------------
[AS(甲)のポリシ]
import: from AS (乙) accept (route of 乙)
export: to AS (乙) announce (route of 甲)
[AS(乙)のポリシ]
import: from AS (甲) accept (route of 甲)
export: to AS (甲) announce (route of 乙)
-----------------------------------------------------------------
このような情報をIRRに登録しておき、IRRToolsetというツールなどを利
用することで、それぞれのASのルータに必要な設定を生成することができま
す。
ところが、現状のIRRでこのような利用がなされている例はそれほど多く
ありません。その理由として挙げられるのが、自ASのポリシだけ登録しても
隣接ASが同様に情報を登録していないと、そのポリシが実質的に意味をなさ
ないということです。また仮に双方が登録していたとしても、そこでやりと
りされている経路情報が食い違っていた場合にも同様にこの機能は実質的に
意味をなしません。隣接関係の一方が経路情報を広告するように設定しても、
他方がそれと対をなす設定をしないと、実際には経路情報が交換されないこ
とになります。
このようなポリシ間の不整合が存在するために、実際にIRRにポリシを登
録して利用する例が少ないのだと言えます。
当チームでは、現状で登録されているポリシにどの程度の不整合があるの
かを明らかにし、この不整合を減少させるための取り組みを行っています。
○ 現状のIRRにおける不整合の割合
現在運用されているIRRに経路情報交換のポリシを登録しているASも多
数存在します。これらのポリシが上で述べたような不整合をどの程度含ん
でいるかを検証しました。検証にあたっては、隣接ASの情報が他のIRRに
登録されている場合を考慮して、インターネットでパブリックデータを公
開しているIRRデータベースを収集し、この情報を基にして、統一的なIRR
データベースを構築しました。これにより世界中のASのポリシの整合性を
検証することが可能となりました。
検証の結果、IRRにポリシを登録しているAut-Numオブジェクトのうち、
実に55.8%は不整合を含んでいることが判明しました。不整合の内訳は以
下に示すようになります。
+--+----------------------------------------------------+--------+
| | 不整合の分類 | 割合 |
+--+----------------------------------------------------+--------+
| 1| 隣接As-SetがIRRデータベースに存在しない | 0.2% |
+--+----------------------------------------------------+--------+
| 2| 隣接ASがIRRデータベースに存在しない | 4.0% |
+--+----------------------------------------------------+--------+
| 3| 該当ASを指定したexport文が存在しない | 18.7% |
+--+----------------------------------------------------+--------+
| 4| 該当ASを指定したimport文が存在しない | 17.8% |
+--+----------------------------------------------------+--------+
| 5| importしている経路を隣接ASがexportしていない | 5.9% |
+--+----------------------------------------------------+--------+
| 6| exportしている経路を隣接ASがimportしていない | 9.2% |
+--+----------------------------------------------------+--------+
|計| 合計 | 55.8% |
+--+----------------------------------------------------+--------+
このことから、ポリシを基にしてルータの設定を自動生成することで、
正常な経路情報交換を実現するためには、ポリシを登録している大半のAS
について、そのポリシの記述内容が、隣接ASとの間で整合性がとれている
かを見直す必要があることがわかりました。
○ 不整合を減少させるための取り組み
このような不整合を減少させるため、当チームでは、ポリシを登録する
際に、AS管理者が隣接ASのポリシとの間の整合性を検査するための機構を
構築しました。ポリシチェッカーと呼ばれるこの機構は、Webブラウザを
利用したCGIとして動作します。ブラウザの画面よりポリシを含んだ
Aut-Numオブジェクトを入力すると、ポリシチェッカは該当ASと隣接する
ASのポリシとの間の整合性を検査し、不整合が検出された場合は、その旨
を表示します。AS管理者はこの結果を基に、必要に応じてポリシの修正や、
隣接ASとの間でポリシの再検討を行うことができます。
ポリシチェッカーは現在、JPIRRのサービスの一つとして2004年2月より
提供されています。JPIRRにデータを登録していることを問わず、誰でも
利用することができます。
○ 利用者へのアンケート
本システムの運用を開始した後に、JPIRRユーザで構成されるメーリン
グリスト、および、JPIRRに関心のある方々で構成されるirr-usersメーリ
ングリストを対象にアンケートを実施し、4つのAS管理者の方々からご意
見をいただきました。以下に主な質問とその回答を記述します。
・ポリシの記述について
ポリシの記述をしている(3件)
ポリシの記述をしていない(1件)
[主な理由] peerの数が多いと、全てのポリシを記述するのが困難
・検査の結果、不整合は検出されたか
検出された(3件)
検出されなかった(0件)
・不整合が検出された際に、ポリシの変更をしたか
変更した(0件)
変更していない(3件)
[主な理由] 隣接AS側のポリシについては自ASでは変更できない
・本システムの使用感について
使いやすかった(0件)
使いにくかった(2件)
[主な理由] aut-numオブジェクトをカットアンドペーストするのでは
なく、aut-num名だけで利用できると良い
使い方がよくわからなかった(1件)
以上のような結果となりました。今後、いただいた意見をもとにインター
フェイスに改善を加え、より多くの方々に利用していただけるようにする
予定です。
8.3 IRRオブジェクトガーベージコレクタシステム
IRRデータベースは、各ASの管理者が各種オブジェクトを登録することに
より、実ネットワークに則した情報の蓄積を可能としています。その一方で、
IRRデータベースの運用を続けるうちに、登録はされたものの長期間にわた
って更新されていないオブジェクトも蓄積されていきます。
このようなオブジェクトは、現実のネットワークの情報と乖離している場
合が多く、結果的にIRRデータベースの信頼性を下げることにつながります。
これはIRRデータベースの「ごみオブジェクト問題」として以前から問題視
されて来ましたが、実際にこの問題への対策は取られていませんでした。
「ごみオブジェクト問題」については、2003年7月24日に開催された第1回
JPIRR BoFでも取り上げられました。議論の詳細については以下のURLをご覧
ください。
「第1回 JPIRR BoF議事録(次第6-7)」
http://www.nic.ad.jp/ja/materials/irr/20030724/minutes-02.html
このような問題指摘を受け、当チームは「ごみオブジェクト問題」への対
応策として、IRRオブジェクトガーベージコレクタのサービスを開始しま
した。
本システムでは主に、以下の処理を行います。
○ オブジェクトの更新期間の確認と通知メールの発行
各オブジェクトの更新日より、JPIRRが設定した更新期間を経過したオ
ブジェクトについて、そのオブジェクトが属する管理者に対して更新に関
するメールを送信します。
○ 未更新オブジェクトの閲覧不可処理と通知メールの発行
更新期間を経過してもなお更新されていないオブジェクトはIRRデータ
ベースから一時的に除去し、その旨をメールにてAS管理者宛に通知します。
この処理により初めて、IRRにおけるオブジェクトの閲覧が不可能な状態
となります。除去されたオブジェクトは一定期間、一時ファイルにて保管
されます。
○ 保管オブジェクトの削除処理
閲覧不可処理により、IRRから一時ファイルに移動されたオブジェクト
は、一定期間を経過した後に削除されます。この処理により当該オブジ
ェクトに関する情報はJPNICの持つデータベースから完全に消失すること
になります。
○ 各オブジェクトの更新日の一覧表示
AS管理者に属するオブジェクトの更新期限の予定日の一覧をWebページ
にて表示します。このプログラムは以下のURLより参照することができます。
http://jpirr.nic.ad.jp/gc/
本サービスは、2004年2月度の初回実験運用を経て、現在正式稼動されて
います。初回実験運用では2月1日に最終更新日から12ヶ月以上経過したオブ
ジェクトについて、該当するオブジェクトを管理をする組織に対して、更新
期間満了の通知を発行しました。2月15日には、それらのオブジェクトの閲
覧不可処理の予告通知を行いました。そして、2月29日に閲覧不可処理を行
いました。
2月1日の更新期間満了通知の際には、24のメンテナに対し、合計180のオ
ブジェクトに関する通知が発行されました。また、2月29日の閲覧不可処理
の際には、3つのメンテナが管理する合計で9つのオブジェクトが処理の対象
となりました。このことから更新期間満了の通知から閲覧不可処理までに大
半のオブジェクトが適切に更新されたことが言えます。今後も本システムを
運用していくことで、一定の品質を保ったIRRデータベースを維持すること
ができると考えられます。
○ 利用者へのアンケート
本システムの初回実験運用を行った後に、JPIRR利用者の方々を対象に
アンケートを実施し、6つのAS管理者の方々からご意見をいただきました
。以下に主な質問とその回答を記述します。
・本システムによる各種通知が届いたか
通知が届いた(5件)
通知は届いていない(1件)
・通知に従い、オブジェクトの更新を行ったか
行った(5件)
行っていない(0件)
・本システムの一機能である、各登録オブジェクトの更新期限を表示する
CGIを利用したか
利用した(3件)
利用していない(3件)
・本システムの使用感に関する意見
・更新期限が直近である場合に赤文字で表示する機能は良い
・オブジェクトの数が多いと見づらいため、更新期限だけを一覧表
示してほしい
・本システムの必要性の有無について
必要である(5件)
必要ではない(1件)
[理由] 更新の必要なオブジェクトは登録していないため
・そのほか、本システムの運用に関する意見
・オブジェクトの内容に変更がないときは、より簡便な手続きにし
てほしい
・オブジェクトの登録、更新のためのマニュアルを整備して欲しい
・JPIRRの広報活動を充実させるべき(JPNIC管轄のASは全て登録して
ほしい)
・データの重複など、明らかに更新の必要があるときのみ通知して
ほしい
以上のような結果となりました。今後、使用感やドキュメントの改善を
行う必要がありますが、本システムの意義に関しては理解が得られたもの
と考えています。
今後はRouteオブジェクトと、実際の経路情報との比較を行うことでリア
ルタイムに情報の更新を促すことができるよう、システムを拡張する予定で
す。
これは、Routeオブジェクトと実際にインターネットに広告されている経
路情報を比較し、これらの情報に乖離があった場合にも、該当するRouteオ
ブジェクトを管理するメンテナに対して、情報の更新を促すメッセージを送
信するというものです。
なお、ガーベージコレクションシステムのより詳細な説明は、以下のURL
でて確認することができます。
http://jpirr.nic.ad.jp/gc/doc/
8.4 IPv6 IRRシステム
本節では、IPv6に対応したIRRシステムに対して、その必要性、IPv6対応
の現状、IPv6 IRRへの提案について記述します。
8.4.1 IPv6におけるIRRの必要性
IPv6ネットワークの経路制御の考え方は、IPv4の経路制御と大きな違いは
ありません。このことから、IPv4ネットワークにて生じている経路制御の課
題はIPv6ネットワークでも生じる可能性が高いと言えます。
IPv4では、過去に大規模な誤った経路情報の流布事件がありました。
(AS7007事件)
"7007 Explanation and Apology"
http://www.merit.edu/mail.archives/nanog/1997-04/msg00444.html
BGP誤設定によるバックボーンへの影響も観測されています。
"Understanding BGP Misconfiguration"
http://www.cs.washington.edu/homes/ratul/bgp/bgp-misconfigs.pdf
さらに意図的に誤った経路情報を流すことで通信を妨害することも不可能
なことではありません。
"Attack on the Routing Protocols"
http://www.esat.kuleuven.ac.be/cosic/seminars/slides/routing.pdf
IPv6でこのような事象が仮に発生しても、何らかの仕組みにてIPv6インター
ネット全体に影響が及ばないようにする必要があります。
その一つとして、IRRシステムを用いることが考えられます。
(a) 経路情報の正しさとIRRが果たせる役割
ここでは、経路情報の正しさを定義し、その正しさを確認するためにIRR
システムがどの程度の役割を果たせるかを検討します。
まず経路情報が正しいとは、以下の条件を満足していることと考えます。
・あるアドレス空間をインターネットレジストリから割当を受けた主体
(所有者)が、自らのAS、またはインターネットサービス事業者のASか
らそのアドレス空間に関する経路情報を広告するとき、経路情報
(Prefix, Prefix長, 広告するOrigin AS)がインターネットのどこで
も同一であること。
・所有者が意図していない経路情報がインターネット上に広告されてい
ないこと。
・経路情報の属性情報には、規則に沿った変更のみが行われていること。
(特にAS-PATH属性)
一方、IRRシステムでは、ある経路情報(Prefix)に対して、
(1)経路情報を広告する組織の連絡先
(2)その経路情報のOrigin AS番号、Prefix長
(3)経路情報を広告するにあたってのポリシ
の情報を管理し、提供しています。
経路情報の正しさを確認する点からは、IRRは必ずしも必要十分な情報
を保持しているわけではありません。以下では、適用範囲を明らかにする
べく、故意または過失による誤った経路情報の広告に関して、起こりうる
事象を大きく分類し、IRRが有効なケースを明らかにします。
(ケース1) 「より細かい経路情報(more specific Prefix)を流される」
※経路発生源(Origin)は、正式なAS番号でも異なるAS番号でも
結果は同じ。
・望ましくない結果
正しい経路情報よりも、細かい経路情報(more specific
Prefix)が優先して用いられる(longest match)。
・例
2001:FFFF::/32 の経路情報に対して、それより細かい
(specificな)経路情報 2001:FFFF:8000::/33を流され、それ
が本来あるべき、2001:FFFF::/32の発生源(origin)とは異なっ
たところから来ている場合、2001:FFFF:8000::/33にマッチす
るパケットは本来の行き先ではなく、誤ったところへ導かれ、
結果として通信ができなくなる(ブラックホール問題)。
・対処法
(1) 「IPv6アドレス割り振りおよび割り当てポリシ」
(APNIC-089)により、アドレス割り振り単位が/32でかつ集
約して経路情報を広告する必要があることから、経路情報
はPrefix長/32で広告されていると考え、Prefix長が/32よ
り長いもの(/33～/128)はフィルタを用いて排除する。
(2) 将来、/32より長いPrefix長の経路情報を流さない原則が
緩和される、またはなし崩しに消失する可能性があること
を念頭におき、広告する可能性のある経路情報をデータベー
スに登録しておき、何らかの形でこれを参照して、誤った
経路情報を排除する(IRRのアプローチ)。
(ケース2)「経路情報の発生源(Origin)が誤っている経路情報を流
される」※経路情報(Prefix)自体は同じ
・望ましくない結果
正式な発生源(Origin)からの情報がきていても、比較によっ
ては誤った経路情報を選んでしまう。
・例
2001:FFFF::/32がOrigin AS=50000、AS-PATH="50001 50002
50000" のとき、別の隣接ASから2001:FFFF::/32に関して、誤
った経路情報(Origin AS=55555、AS-PATH="54321 55555")を
受け取ると、防御策を施していないとAS-PATH長の短い
Origin AS=55555の経路情報を選択してしまい、結果として通
信できなくなる。
・対処法
(1) 経路情報とそれを広告する主体のAS番号を組み合わせて
データベースに登録しておき、何らかの形でこれを参照
して誤ったOriginを持つ経路情報を排除する(IRRのアプ
ローチ)。
(2) 経路情報に署名を付し、署名を検証して不正な経路情報
を排除する(S-BGP、soBGP(Authcert)のアプローチ)。
(ケース3)「経路情報に付されている属性を変えてしまう」
・望ましくない結果
経路をトランジットしているASにて、経路情報の属性、特に
AS-PATH属性を変えてしまう。例えば、AS-PATHにまだ通過して
いないASを追加することにより、そのASではループとみなし、
その経路情報を受け取らない。(すでに1回自分のところを通過
している経路とみなし、ループを防ぐために受け取らなくなる)
結果として、通信できなくなる。
・例
2001:FFFF::/32 AS-PATH="55555 55554 55553"のとき、途
中に50001 を挟み込むことにより AS50001では、2001:FFFF::/32
をすでに受け取り済みと認識し、経路情報を受け取らない。結
果として2001:FFFF::/32とは通信できない。
・対処法
(1) ingressのBGPメッセージを監視し、AS-PATHに自ASが含まれ
ている経路情報を再検証する。
(2) IRRに登録されたポリシからAS-PATHを構築し、比較する。
※非現実的
(3) AS-PATHを認証する。
※非現実的
上記の通り、
(ケース1) 広告する経路のPrefix長を確認
(ケース2) 広告する経路のOrigin ASを確認
については、IRRのアプローチは効果があると考えられます。
しかしながら、(ケース3)についてはIRR以外の何らかの手段を考える必
要があります。
(b) IPv6におけるIRRの必要性
IPv6は、日米欧においていくつか商用サービスが開始されています。し
かし、2004年3月現在ではまだ本格的に利用されている段階には到達して
いません。各社とも利用者が期待ほど増えておらず、IPv4との差異化、す
なわちIPv6ならではのアプリケーションやサービス開発に知恵を絞ってい
ます。
前述の通り、経路制御に関する脆弱性はIPv4と比較し本質的に変わりま
せん。経路表の膨張を抑えることを目的としてインターネット全体に広告
する経路は集約することとしており、今のところIPv6に接続しているネッ
トワークはこの制限を遵守しています。
しかし、商用サービス利用者が増加してくると、例えばマルチホーミン
グなど利用者からの要求によって、より細かい経路情報を広告するように
なる可能性もあります(これをパンチングホールと呼びます)。
このような状況が予想されるため、IPv4での経路情報の課題がIPv6で再
現しないよう、何らかの手立てが必要です。
その一つとして、経路情報の正しさを確認するのに役立つIRRの仕組み
を、まだIPv6の爆発的普及の前段階にある今の時点から早期に整備し、有
効活用していくべきと考えます。早い段階でIRRを含めて経路情報の安全
性を高める仕組みを構築できれば、経路情報の不安定要因の解消を一歩進
めることができるだけでなく、これまで重ねているアプリケーションでの
差異化によるIPv6普及・促進に加えて、セキュリティ面で「IPv6のほうが
基盤となる経路制御の信頼度が高い」という点からIPv6普及促進にも役立
つと考えます。
8.4.2 IPv6用IRRデータベースの状況
IPv6に対応したIRRを提供するためには、下記が必要になります。
(a) IRRにて記述すべきIPv6に関する情報の記述方法(RPSLng)
(b) IPv6の経路情報を蓄積できるIRRデータベースソフトウェア
以下にそれぞれの動向を記述します。
(a) RPSLngの標準化動向
ポリシ記述言語であるRPSLに関して、IPv6対応とマルチキャスト対応
拡張を行ったものがRPSLngです。
RPSLngは、現在IETFで議論が行われています。2004年3月現在、ドラフ
トの改訂が行われており、RFC化の時期については不明です。
RPSLngの拡張部分は、下記の通りです。
(a-1) ポリシの記述
RPSLにおけるimport:, export:, default: はIPv4 unicast を暗
黙のうちに対象にしています。これをマルチプロトコルで記述でき
るよう、mp-import:, mp-export:, mp-default: に拡張しています。
また拡張に伴い、どのプロトコル(IPv4/IPv6, Unicast/Multicast)
を記述しているのかを明確化するため、AFI(Address Family
Identifier)という記述子を設けています。これを用い、mp-import:,
mp-export:, mp-default: のなかで記述しているプロトコルをafi
に続けて次の語句を用いて示します。
ipv4.unicast, ipv4.multicast,
ipv6.unicast, ipv6.multicast,
any, any.unicast, any.multicast
(a-2) route6クラスの追加
IPv6の経路情報を記述するクラスとして、route6が追加されてい
ます。
(a-3) 既存クラスの拡張
RPSLで定義されているクラスのうち、IPv6アドレスなどを記述す
る必要のあるものは、定義を拡張しています。
as-set
route-set
filter-set
peering-set
inet-rtr
rtr-set
(b) IPv6をサポートするIRRデータベースソフトウェア
RPSLngに準拠してIPv6経路情報を蓄積できるデータベースソフトウェア
として次の2種類があります。前述の通り、RPSLngはまだRFC化されていな
いため、まだ正式対応ではありません。
・RIPE-db version 3 (RIPE NCC作成)
・IRRd2.2b29 (Merit作成)
双方ともRPSLngの拡張仕様を記述できるようになっています。なお、
RPSLngには定義されていませんが、6boneにて用いられた"ipv6-site"とい
うクラスがあり、IRRd2.2b29ではipv6-siteクラスをサポートしています。
ipv6-site クラスの定義
http://whois.6bone.net/~david/6bone/draft-ietf-ngtrans-6bone-registry-03.txt
◇ipv6-siteの定義
...........................................................................
ipv6-site: [mandatory] [single] ; ipv6-siteの識別名
origin: [mandatory] [single] ; Origin AS
descr: [mandatory] [single] ; このipv6-siteに関する記述
location: [optional] [multiple] ; 所在に関する情報
country: [mandatory] [multiple] ; ISO3166-country code
Prefix: [mandatory] [multiple] ; Prefix(Prefix length含む)
application: [optional] [multiple] ; 提供しているアプリ(ping, ftp..)
tunnel: [optional] [multiple] ; トンネルで接続しているサイト
native: [optional] [multiple] ; IPv6で接続しているサイト
contact: [mandatory] [multiple] ; 連絡先(NIC-handle)
remarks: [optional] [multiple] ; 備考(サイトの状況を記述)
url: [optional] [multiple] ; URL
notify: [optional] [multiple] ; 更新時の連絡先
mnt-by: [optional] [multiple] ; メンテナ
changed: [mandatory] [multiple] ; 変更責任者、変更日時
source: [mandatory] [single] ; 現在は6boneのみ
............................................................................
8.4.3 IPv6 IRRに関する提案
8.4.1節で記述したように、IPv6 IRRデータベースが存在すれば、経路情
報に関する連絡先台帳の役割だけでなく、経路情報の正しさを確認する情報
源として利用することができます。
また、IPv6がまだ普及黎明期であることから、現時点で迅速にIRRに関す
る体制や手続きを導入することで、IRRデータ自体の信憑性を維持する基盤
が作れると考えます。このような考え方に基づき、IPv6 IRR構築・運用に関
して以下のように提案します。
(1) 基本ポリシ
・インターネット全域に流すIPv6経路情報は、IRRデータベースに必ず
登録するものとします。逆に、IRRデータベースに登録されている経
路情報しかBGPで流せないとします。
すなわち、原則としてIRRデータベースに登録された情報に基づい
て経路フィルタが存在する可能性から、未登録の経路の経路制御性は
保証されません。
・限られた範囲でのみspecificなIPv6経路情報を流す場合に、局所的な
IRRを任意に立上げ、関係者のみでその経路情報やポリシを共有す
ることは制限されません。
(2) システムアーキテクチャ
・インターネット全域に流すIPv6経路情報を登録するIRRデータベース
は、RIR, NIRなどが提供する現在の階層構造を踏襲します。
・データベースへのアクセスに関して、最新の情報ができる限り素早く
入手が可能なよう、IRRデータベースの相互NRTM実現やCRISPのような
仕組みが導入されているものとします。
IPv6 IRRのアーキテクチャについては、既存アーキテクチャとの互換性だ
けでなく将来の拡張性も考慮に入れ、かつ既存の問題点を解決するような方
法を継続して検討する必要があります。
例えば検討すべき課題として、IRR全体をデータベースと捉えて
・IRRデータベースを「集中型」「分散型」どちらにするか
・IRRデータベースは誰が管理主体となってどこに配置すべきか
例：RIRだけに置く
RIRとNIRに置く
RIR, NIR, LIR全てに置く
どこか一極集中
・どのIRRデータベースに登録すべきか
例：APNIC管轄地域はAPNICに
どこでもOK
・分散配置された場合、IRRデータベースのデータを相互にミラーすべ
きか、それともアクセスする仕組みを工夫するか
・経路情報を登録してから、経路を確認する仕組みや経路フィルタへ情
報が反映するまでの時間差は、どの程度が適正か(長いと経路情報変
更が反映されるまで時間がかかる、短いとシステムへの負荷が重くな
る)
などを議論していく必要があります。
9. JPNIC IRR企画策定専門家チームの活動実績
当チームでは、JPNICにおけるIRRの存在意義の検討やIRRの周辺環境の改
善提案などを実施するために、多くの対外活動を実施してきました。
本章では、これらの活動をまとめ、そこで得られた意見などについて紹介
します。
9.1 日本ににおける活動
日本国内では、当チームの前身の「IRR研究会」からも、いくつかの会合
を実施してきました(2章参照)。特に、2003年度においては、実際のインター
ネットの運用者や国内でのIRRの運用者などからも広く意見を求め、IRRに関
する議論を深めてきました。
以下では、2003年度に実施した2回のBoFでの議論を紹介すると共に、得ら
れた意見についてまとめます。
1) 第1回 JPIRR BoF(札幌, JANOG12併催)
2003年度最初のBoFは、日本のインターネットの運用者が多く集まる
JANOG(JApan Network Operators' Group)の本会議日程に合わせて開催し
ました。予想を超える55名もの参加者に集まっていただき、活発な議論を
行いました。
BoFでは、現在のJPIRRの最新情報と統計情報の紹介後に、国内でIRRを
運用しているJPIX(JaPan Internet eXchange)の事例と、JPIXで使われて
いるツールなどの紹介が行われました。また、当チームで検討を進めてい
る経路情報の正当性、IRRデータの正当性を維持するための手法に関する
紹介も行いました。最後に、これらのプレゼンテーションを踏まえた上で、
「IRRの今後に関して」というテーマで幅広い議論を行いました。
議論の詳細については、JPNICホームページ上で公開しているので、そ
ちらを参照してください。
「第1回 JPIRR BoF 開催概要・議事録」
http://www.nic.ad.jp/ja/materials/irr/20030724/index.html
主な議論は、IRRに登録されるオブジェクトの登録タイミング、登録デー
タの信憑性、ミラーリングについてなどでした。以下では、それぞれの議
論について、代表的なコメントを紹介します。
○ オブジェクトの登録タイミング
オブジェクトの登録タイミングについては、現在は運用者の任意であ
って、登録しても登録しなくても良い状態となっています。これに対し、
当チームとしては、JPNICが指定事業者に対して、アドレスブロックを
割り振る段階で、Routeオブジェクトを自動的に登録する方法もあるこ
とについて言及したところ、会場の一部で賛同が得られました。
自動的にオブジェクトを登録することは、IRRが包含する経路情報の
完全性を維持するための強力な方法として、基本的に理解できるとしな
がらも、JPNICが運用面に介入することに対するネガティブなインパク
トを感じてしまうという側面があるようです。
このほか、自動的に登録された場合でも、その情報が実際の運用上の
経路情報とはそもそも一致しないだろうという予測も否定的な意見を強
める一因だったのかもしれません。
一方で、現状のようにJPIRRとJPNIC WHOISが別々に運用されているこ
とについて、疑問視する声もありました。一般利用者から見ても、これら
の2つのデータベースが、RIPE NCCのように共通のプラットフォームで
運用されることが、自然だと思われているようです。
○ 登録データの信憑性
これは、IRRに登録はされたものの長期間に渡って更新されていない
オブジェクト(いわゆる「ごみオブジェクト」)の問題です。
ここでは、RADBが実施した有料化によって、料金未払い時に自動的に
オブジェクトが削除されるという、暗黙的な登録期限が発生することに
よって、ごみオブジェクト問題が解消できるという効果について議論さ
れました。
古いオブジェクトの削除などが進んでいるRADBの実態を知っている参
加者も多く、登録期限があることは、データの信憑性を維持するために
一定の効果があることが認識されているようです。
当チームにおいても同様の考えから、IRRオブジェクトガーベージコ
レクタシステム(8.3節参照)を考案して紹介したところ、賛同が得られ
ました。この結果を受け、当チームでは、このIRRオブジェクトガーベー
ジコレクタシステムを実装し、試験運用を始めることを決定しました。
○ ミラーリング
ミラーリングを実施するにあたり、情報発信元の情報がそもそも正し
いのか、と言うところまで立ち返って議論が始まりました。つまり、
IRRにはPeeringの情報なども含まれている可能性もあり、それらのビジ
ネスに関わる情報を、ISPが安易に外部に公開しないであろう、という
ことです。これにより、外部に情報を出す場合には、ミラーリングポリ
シの明確化や情報の取り扱いポリシをきちんと明文化しておくことが必
要だというコメントをいただきました。
このコメントを受け、JPIRRにおけるミラーリングポリシを作成し、
そのポリシを基にして、本試験サービスでの運用を実施しています。
また、APNICをはじめとする、上流のIRRに対しても同様な措置が必要
ですが、こちらについては、まだ実施できていません。
全体を通して、IRRを使っているユーザにとって、RADBがいつまで続く
のかわからず、RADBがサービスを終了した場合にどこのIRRにオブジェク
トを登録すれば、フィルタを回避するなどの措置が取られるのか、と言う
ような不安を抱える声がありました。そのような不安を取り除くためにも、
早期に、広く周知された安定的なIRRが国内に作られることを望む声があ
ったことも補足しておきます。
2) 第2回 JPIRR BoF (横浜, Internet Week 2003会期中)
2回目のBoFは、前回同様、インターネットの関係者が多く集まる
Internet Week 2003の会場で開催されました。15名の参加者にもかかわら
ず、活発な議論が展開され、価値のある意見をいただきました。
今回のBoFでは前回と同様に、JPIRRの最新情報や統計情報を始めとして、
前回のBoFでいただいたコメントを基にして検討を重ねた、IRRオブジェク
トガーベージコレクタシステムの紹介や、さらに一歩踏み込んで、IRRに
おけるセキュリティに関する議論も実施しました。
議論の詳細については、JPNICホームページ上で公開しているので、そ
ちらを参照してください。
「第2回 JPIRR BoF 開催概要・議事録」
http://www.nic.ad.jp/ja/materials/irr/20031128/index.html
特に大きな時間を割いたのは、IRRオブジェクトガーベージコレクタシ
ステムの実装についてです。今回のBoFでは、より具体的な案について提
示したため、細かい議論が行われ、このシステムそのものの存在意義や更
新を促すメールに対応することで本当に信憑性があがるのか、などの本質
的な意見もいただきました。
最終的には、以下のような意見から、IRRオブジェクトガーベージコレ
クタシステムに存在価値があることについて、会場の意見が一致しました。
1) JPIRRのような新しいIRRではそもそも、ごみオブジェクトのような
ものは存在しないが、将来的に確実に対応しなくてはならないもので
あるということ
2) 更新を促すメールについては、登録者にオブジェクトの有無を確認
させることができるというレベルで、最新の情報に維持する効果を
期待できること
このほか、統計情報の分析において、IRRに登録されている情報とJPNIC
の割り振り情報で不整合が起きている(割り振り順序などによって発生し
たもので、実際には不整合ではない)と思われる箇所もあり、IRRの情報と
Whoisの情報を照らし合わせることで、経路情報の異常についても分析が
できる可能性も見出せるなど価値の高いミーティングでした。
このように国内においては、当チームの主催によってBoFを実施すること
で、国内でのIRRのニーズやユーザが考えるIRRへの不安や問題点を聞くこと
ができ、非常に有意義な機会となりました。
9.2 APNIC管轄地域における活動
APNIC管轄地域では、当チームが提案するミラーリングモデルを基に、様
々な活動を行ってきました。
2002年度までは、RIRを頂点とした階層化されたミラーリングモデルの提
案、各インターネットレジストリが持つWhoisシステムとIRRを連携させるこ
とによって、IRRに登録されているオブジェクトの信憑性の向上に関する提
案などを行いました。2003年度においては、今までの提案を前提に、ミラー
リングを実施する際に、受け渡される情報の無秩序な分散を防ぐことを目的
とした、IRR運用者における共通のIRRミラーリングポリシ策定の提案を実施
しました。
提案内容は、各インターネットレジストリが共通のミラーリングポリシを
もつことで、JPNICとは直接ミラーを実施しないようなRIPE NCCのIRRの情報
であっても、JPIRRは共通のポリシに従って運用し、むやみにその情報を配
布しないようにするためのものです。
これについては、APNICオープンポリシーミーティングで2度の提案を実施
しました。しかし、ヨーロッパ地域や米国でのIRRに対する考え方や、IRRの
情報そのものの信憑性を疑う姿勢などもあり、その効果が望めないことや労
力を使って得られるものが良くわからないなどの意見から、提案はコンセン
サスにまで至りませんでした。
当チームでは、現在もこのポリシは必要であると考えていますが、現時点
では、ポリシが必要なほどミラーリングが進んでいるという状況でもありま
せん。今後は、現在まで提案してきた内容を実装し、その中で今回提案した
ポリシが必要になったときに再度提案を実施する方向で検討を進めています。
しかし、これらのAPNIC地域での活動は、APNIC関係者、他のインターネッ
トレジストリやIRRの運用者からは一定の評価を得ており、現在、IRRの実装
を検討しているKRNICも当チームの活動を参考にしています。
9.3 国際的活動
国際的な活動の代表としては、NANOGでの活動が挙げられます。NANOGでは、
過去にAPNIC地域でも実施した、インターネットレジストリのWhoisデータベー
スとIRRを連携させることによって、IRRの情報の信憑性を高めようという提
案を実施しています。
この提案の中では、インターネットレジストリがIRRを実施することが前
提として組み込まれているため、NANOGで獲得したBoFの時間を利用して、
APNIC, RIPE NCC, ARINの担当者に参加を要請し、MeritにてIRRの研究を行
っていたCraig Lavovitz氏にミーティングチェアをお願いし、インターネッ
トレジストリはIRRを実施すべきだという提案を行いました。
これを受け、APNICではIRRサービスを実施することを決定し、当チームは、
このAPNICの活動をサポートしてきました。
また、Meritが公開しているIRRサーバソフトウェアのIRRdに対する改善提
案も積極的に行ってきました。改善提案の内容はおおむね賛同は得られてい
るものの、実装には至っていません。今後は当チームもしくはJPNICとして
積極的に実装をするなどの活動が必要となってきています。
10. JPNICにおけるIRRサービス
本章では、これまで当チームが調査、検討、提案し、また日本における
IRRのユーザからの意見などを総合的に検討した結果を基に、今後JPNICで
IRRサービスを実施すべきかどうか、また、IRRサービスを実施する場合には
どのような問題点があるのかを指摘し、現時点で考えられるそれらの改善点
などを提案します。
10.1 国際的なIRRとJPNICの関連性
IRRサービスは、5章で触れた通り、分散化の傾向があります。分散化され
たIRRは、必要な情報を求め、IRR間でミラーリングを実施し、それぞれで情
報の補完を実施しています。
本来、IRRは特定のコミュニティに閉じ、そのコミュニティの中で必要な
経路情報を扱いますが、データの完全性や信憑性などの面から特定のコミュ
ニティのIRR情報を補完すると言う観点で、公共的に存在するものが必要と
なります。
国際的な状況から、全世界的にはRADBがその中心と見て問題ない状態です
が、アジア太平洋地域においてはAPNIC、ヨーロッパ地域においてはRIPE NCC
がそれぞれその地域における公共的なIRRを運用しています。
当チームの提案では、アジア太平洋地域内においては言語などの問題もあ
り、APNICを頂点とした、階層化されたIRRの構造が必要であり、APNICの下
位層に日本地域を担当する公共的なIRRが必要であるとしています。
日本国内におけるインターネットにかかわる公共活動、特に経路情報およ
びアドレス情報にかかわる公共活動はJPNICが適切と考えられます。一方、
JPNICはIPアドレスの公平な分配という活動をしており、経路制御やインター
ネットの運用には言及しない立場を取るべきという考え方もあります。この
ため、JPNICにおいてIRRサービスを実施した場合でも、IRRを用いて経路制
御・インターネットの運用に深く立ち入らないような棲み分けを考慮する必
要があるでしょう。
10.2 インターネットレジストリにおけるIRRサービスの必要性
既に前節で、JPNICにおけるIRRサービスの必要性を公共的な面から言及し
ましたが、この際、JPNICのようなインターネットレジストリは経路制御や
インターネットの運用には深く立ち入らないべきであるとも言及しました。
一方で、IRRにおいて正しくかつ網羅的な情報を維持するためには、5.4節
で述べたように、インターネットレジストリが持つ割り振り・割り当て情報
との連携が必要となってきます。
APNICやRIPE NCCの状況をみても、これら2団体が既にインターネットレジ
ストリにおけるIRRサービスを実施しており、その方向性にあると言って良
いでしょう。
また、インターネットレジストリのサービスの観点から言えば、割り振り
や割り当てを行ったアドレスが、実際のインターネット上でどのような情報
として扱われているかを把握するための良い参考となります。
現時点では、JPNICのIRRサービスは実験フェーズにあるため、WHOISサー
ビスとは分離して行われていますが、正式サービスに向けては、これらを融
合したサービスを実施し、正しいIRR情報を維持するためには、Whoisの情報
を連携させる必要があるでしょう。
10.3 周辺活動の重要性
IRRを取り巻く環境は日々変化を続けています。現状では、IRRは多くのIRR
とミラーリングしなければ、多くの情報を集めることができません。APNIC
の活動を見る限り、このような多くの情報を集める作業は困難を極めます。
ミラーリングの方法についても、現在はNRTMを利用していますが、将来的
にはCRISPを利用する方向にあり、技術的にも変化が起こっている時期でも
あります。
ミラーリングの技術的変化、他団体のIRRに関する考え方の変化などの周
辺事情の変化には、常に耳を傾け状況を観察している必要があります。
10.4 本サービスに向けての問題点と改善策
本節では、今後JPNICがIRRサービスを正式サービスとする場合に必要な検
討事項について述べています。
正式サービスを開始する場合には、本節であげる問題点を解決することが
望まれますが、現時点では対応できないものも多く含まれています。これは、
必ずしも解決すべき問題ではなく、今後、時間をかけて改善すべき事項であ
ろうという観点で言及しています。
10.4.1 セキュリティ
IRRのセキュリティは、これまで登録者の認証に着目してきました。しか
し、IRRデータの同期や登録上の正当性に依存する場面を想定すると、登録
情報の保護と言う観点が必要になります。登録情報の保護とは、登録者の認
証だけでなく、データ認証・データ保護の観点を含んでいます。
今回の検討では、これらのいくつかの点について検討が実施されましたが、
RPSLでの電子署名の利用やIRRユーザのIRRへの依存度とIRR情報の正当性の
関係に関する検討などが不十分となっています。今後これらの検討を進めて
行く必要があります。
検討を進めるにあたっては、利用者が安心してIRRを利用するためには、
IRRとして利用者にどの程度の安全性を要求するのか、などの想定を行う必
要があります。
10.4.2 NICハンドルの問題
RPSL(RFC2622)で記述されるIRRのオブジェクトの中に、フィールドの1つ
として、nic-hdl(NICハンドル)を記述する部分があります。
例えば、あるMaintainerオブジェクトを参照した場合に、その技術コンタ
クト先(tech-c)などにnic-hdlが記述されている場合には、そのnic-hdlを含
む PersonオブジェクトなどがMaintainerオブジェクトを参照した際に、そ
れと同時に参照される仕組みになっています。
しかし、ここには実は大きな問題があります。nic-hdlは、インターネッ
トレジストリが提供するWhoisデータベース上で利用されているものであり、
このnic-hdlは、何らかのレジストリデータベース上にあるオブジェクトか
ら一定期間参照関係にないと、自動的にWhoisデータベース上から削除され
てしまうような仕組みになっています。
つまり、IRRのオブジェクトの中に、nic-hdlを記述したとしても、そのも
ととなるWhoisデータベース上に存在すべきnic-hdlのオブジェクト自体が削
除されてしまっているという可能性があります。
これはそもそも、IRRのデータベースと、レジストリが管理するWhoisデー
タベースとが密に連携していないところから発生している問題とも言えます
が、今後もこのように、nic-hdlをIRRのオブジェクトのフィールドの1つと
して利用していく上では、考慮が必要となります。
10.4.3 Whoisデータベースとの連携
現在インターネットレジストリにおけるIRRサービスの提供は、大きく2つ
に分類することができます。APNICやRIPE NCCのように、RIPE-db version 3
システムを用いてIRRのサービスが提供されており、inetnumオブジェクト
やdomainオブジェクトなど、インターネットレジストリが管理するwhoisデー
タベースの情報に加えて、IRRのオブジェクトも、それらのオブジェクトの1
つとして管理されるようなシステム構造になっているものです。
2つ目は、JPNICやARINのように、独自にWhoisデータベースシステムを構
築し、それとは全く別にIRRのシステムを構築しているような場合です。
前者の場合には、インターネットレジストリが管理するwhoisデータベー
ス情報とIRRの情報がある程度連携された形でのサービス提供がされていま
す。具体的には、inetnumオブジェクトの範囲内に限り、IRRのオブジェクト
を登録することが可能となっているように、IRRの情報登録がある一定の範
囲に限定されているようなサービス提供形態となっています。
後者の場合には、提供システム自体が全く別のデータベースであることか
ら、前者のようなサービス提供形態には至っていません。あくまでそれぞれ
のデータベースが独立したものとして運用されています。
今後JPNICでIRRサービスを正式に提供していく場合には、このWhoisデータ
ベースとの連携も視野に入れて検討していかなければなりません。現在は全
く別のシステムですから、仮に割り当てがされていないブロックに対してIRR
のオブジェクトを作成しようとしても、システム上、別のデータベースを構
築しているため、問題なく登録できてしまいます。本来は、未割り当ての空
間であったり、あるいは登録権限のないアドレス空間であるにも関わらず、
登録が可能となっています。またさらにこれを発展させた形としては、レジ
ストリ間の連携も考えていく必要があります。例えば、RIPE NCC管轄地域で
取得したAS番号をOrigin ASとして、APNICが管理しているRouteオブジェク
トを登録する場合など、現在ではまだ実現できていません。今後は、RIR,
NIR間での連携も視野に入れた形でのサービス提供を検討していく必要があ
るでしょう。
10.4.4 システムの安定に向けた施策
7.7節でも既に述べたように、現在の試験運用サービスから正式サービス
へ切り替えるには、「他IRRデータ参照サービスの信頼性」「他IRRで参照さ
れるJPIRRデータベースの信頼性」という観点が必要となります。ここでは、
これらの観点から、システムおよびサービスの安定化へ向けた施策を提案し
ていきます。
10.4.4.1 他IRRデータ参照サービスの信頼性
JPIRRは他のIRRとミラーしてデータベースを受け取っていますが、そのデ
ータベースが最新状態であることを保証していません。サービス提供側とし
ては、その状態を監視するか、もしくは最新状態であることを保証しないと
いう注釈をつける必要があります。
この最新状態かどうかを監視することは、階層型構造という特性上、実際
にミラーを実施する上流IRRだけではなく、他のIRRのデータベースも監視対
象となります。その場合、以下の方法が考えられます。
○ JPIRRサーバでのミラー状況監視
データベースの更新状況はミラーログファイルで確認ができます。また、
ミラー失敗時は、IRRdプロセスのログファイルにもメッセージが残ります。
これらのファイルを監視するスクリプトを作成し、ミラー失敗時には通知を
行う方法が考えられます。
この方法はもっとも簡単に実施できますが、この方法で確認できることは
ミラー状況のみであり、上流IRRのデータベース以外は、上流IRRがデータの
受け取りに失敗していた場合を検知することができません。
○ 他IRRサーバへの登録反映確認
他のIRRへMaintainerオブジェクトを登録し、定期的に更新することで、
その内容が、JPIRRサーバが持つデータベースファイルに反映されているか
を確認する方法があります。ただし、他IRRのミラー頻度は確認しておらず、
ミラー失敗が発生しても、その事象を検知するまでにある程度、時間的なず
れが発生してしまいます。
○ 他IRRサーバとJPIRRサーバのデータベースファイルを比較
各IRRサーバの持つFTPサイトにあるファイルを取得し、JPIRRサーバ内に
保存されるファイルと比較をすることで、ミラーリングが正常に行われてい
るかを確認することができます。この監視には、「参照IRRのCURRENTSERIAL
をFTPサイトから入手する」、「最新オブジェクトの登録情報を実際に参照
する」などの方法はありますが、これまで述べてきたように、更新は他IRR
サーバのミラーサイクルにも依存するため、JPIRRだけでの実施では、適切
に監視することが困難です。
10.4.4.2 他IRRで参照されるJPIRRデータベースの信頼性
10.4.4.1節とは反対に、他のIRRが持つJPIRRデータベースが最新のもので
あるかを監視する必要もあります。例えば、現在RADBに登録している日本の
ユーザがJPIRRへの切り替えを検討する際、重要な項目となります。
監視・確認の方法やそれに伴う問題点も10.4.4.1節とほぼ同様となります。
10.4.5 IPv6サービス
将来的にIPv6が普及していくことを考えると、今のうちから割り振りや
割り当ての行われたIPv6アドレス、さらにはIPv6の経路情報をデータベー
スに登録、更新する手続きを明確に定め、データベースが常に実状と整合
がとれている必要があります。
日本はIPv6アドレスの割り振り数が世界第2位です。また、商用のIPv6
サービスをいち早く開始しているなど、IPv6普及の面では世界の先頭を走
っています。この日本で、IPv6に関するIRRのあり方を議論し、RIRを説得
しつつ、その実現例を世界に見せることが重要です。
新たな仕組みを導入するにはIPv6普及黎明期である今が絶好の機会です。
これまで当チームで議論し試行してきたIRR階層構造、登録情報の更新を
促進する仕組みなどを取り入れて、IPv6 IRRを正確で使いやすいものとす
るよう、議論を継続していく必要があります。
10.4.6 IRRのデータの信憑性維持のための施策
IRRサービスを行う上で、IRRで管理する情報の信憑性維持は大きな問題で
す。JPNICでIRRサービスを実施するにあたり有効と思われる施策について、
当チームでの検討結果を以下に整理します。
施策は、古いデータの取り扱いと、登録されるデータの正しさの2つの方
向性に整理します。
1) 古いデータの取り扱い
IRRに残る古い情報は一般に、データベースそのものを陳腐化させます。
このために古い情報は、更新を促すなどをして常に最新の情報に維持する
必要があります。以下に、考えられる対応方法を列挙します。
○ IRRシステム利用料の徴収
RADBが採用した方法です。RADBは、有料化することによって、料金を
払わないユーザのデータを削除します。これは、RADBがある米国におい
ては、一定の効果が確認されています。
ただし、有料化することによって課金関連のシステムとの連携を実施
することや、課金管理などのオーバーヘッドも大きいものになります。
○ IRRオブジェクトガーベージコレクタシステムの採用
現時点でこのシステムを採用しているのは、当チームが実施している
試験サービスのみです。利用料の徴収の方法は、データベースを有料に
することで効果を出せますが、有料化するためには、上記であげたいく
つかの問題も伴います。
IRRオブジェクトガーベージコレクタシステムは、古い情報の持ち主
に一定間隔で更新を自動的に促すもので、利用料徴収の方法よりは、い
くぶん効果が低いかもしれませんが、無料にて運用する場合においては、
効果的なものとなります。
○ 登録の義務化
JPNICが指定事業者契約を締結する段階で、IRRへの登録を義務化し、
登録しない場合には罰則を与える方法です。
これまで述べてきた3つの方法の中では一番効果的な方法です。しか
し、IRRは本来、任意に登録されるべきものであること、インターネッ
トレジストリは経路制御などに深く関与しないことなどを考えると、
IRRの利用を義務化することは過剰と考えられます。
2) 登録されるデータの正しさ
登録されるデータそのものの正しさを維持することは非常に困難です。
ここでは、効果的と思われる2つの方法について取り上げます。
○ IRRオブジェクトガーベージコレクタシステムの採用
IRRオブジェクトガーベージコレクタシステムは、古い情報を削除す
るだけではなく、一定期間ごとに利用者に最新情報への更新を促すこと
から、効果が期待できます。
○ JPNIC Whoisシステムとの連携
IRRに登録されるべき情報の原点は、JPNICなどのインターネットレジ
ストリが割り振ったアドレスブロックが基礎になっています。
つまり、JPNIC Whoisが持つ情報と連携することにより、間違ったIRR
情報の発見や登録ミスを事前に防ぐことができるなどの効果が期待でき
ます。
このようにIRRデータの信憑性を維持するためにはいくつかの方法があり、
これらを複数組み合わせることでより高い効果を期待することができます。
最初にも述べましたが、IRRデータの信憑性を維持することは、IRR運用上
大きな問題です。少なからず何らかの手法で信憑性維持に努める必要があり
ます。
10.4.7 階層構造を構成するためのシステム作り
繰り返しになりますが、これまで述べてきた通り、当チームでは、RIRと
NIRを中心とした階層構造に基づいたIRRのモデルの実現に向けて、数年間、
幅広くインターネットコミュニティと議論を重ねながら、より良いIRRのシ
ステム作りを目指してきました。
2000年にIRR研究会を発足し、それ以来、APNICオープンポリシーミーティ
ングやNANOGなどの国際会議においても、様々な提案・啓蒙活動を実施して
きました。その1つの功績として、我々の働きかけを通じて、APNICでは2001
年より、APIRRプロジェクトとしてIRRの試験サービスが開始され、翌年には
正式に、APNICにおけるIRRサービスが開始されました。
元々IRRは、コミュニティに根ざしたものであり、それぞれの地域のイン
ターネットコミュニティで運用されてきたものです。そのため、当チームが
提唱しているような、RIR, NIRの階層モデルに基づいたシステムを構築して
いくものとは、相反するものかもしれません。また、RADBなどにおいては、
あくまでビジネスとして、IRRを運用、管理をしており、それらの人々と、
より密な議論が必要となることは間違いありません。
しかし、今まで述べてきたとおり、IRRの情報は、ますます分散化の一途
を辿る一方で、IRRから必要な情報を得ること自体が非常に困難になってき
ています。ここで、重要な点としては、アドレスブロックやAS番号の情報を
正しく管理し、正しい情報として一般ユーザへ提供できる組織は、インター
ネットレジストリしかありません。
つまり、公共的なIRRとして、それらの情報を正しく管理することのできる
インターネットレジストリ同士が協力し合い、より良いIRRのシステムづく
りをリードしていくことが、今後必要となっていくでしょう。そういった意
味でも、今後も様々なインターネットコミュニティーの間でより深い議論を
実施していくことが必要となります。
10.5 JPNICにおけるIRRサービスの必要性
これまで述べてきたように、IRRのサービスをインターネットレジストリ
が実施することは、一つの流れとなりつつあります。また、日本国内におい
てもRADBやAPNICのIRRに代わるような公共的なIRRのサービスを望む声もあ
ります。
JPNICでIRRのサービスを実施するには、この章で挙げたいくつかの検討が
必要な項目もありますが、これらの検討を進めながら、JPNICによる早い時
期のIRR正式サービスの提供を実施すべきと提案します。
正式サービスに当たっては、既に日本に存在する企業のプライベートなIRR
との連携を始め、APNICとの連携なども含めて検討する必要があることを再
度ここで述べておきます。
Appendix.1 - 謝辞
当チームでは、IRR研究会を契機に約3年という長い間活動を行ってきまし
た。この期間、IRRの周辺環境の調査に始まり、新しいモデルの提案などIRR
に関連することであればとりあえず全てのことについて検討してみるという、
とても膨大で気の遠くなる作業をしてきました。
検討に当たっては、当チームのBoFの開催などによって、いろいろな方々の
意見や提案を頂いたものを参考にさせていただいています。まずは、忙しい
さなかに参加いただき、貴重なご意見を頂いたJPIRR BoF、そしてIRR研究会
の参加者の皆さんに感謝の意を表したいと思います。
また、当チームの活動は日本にとどまらず、NANOGやAPNICミーティングな
どの場面でも活動を行ってきました。IRRの歴史や各国での考え方の違いなど、
日本にいては絶対に得られない情報を幾つも教えていただいたことに感謝い
たします。特に、APNICのGeorge Michaelson氏には幾度となく当チームの活
動に協力いただき感謝いたします。
最後に、このような膨大な報告書をまとめられたのは、ここまで挙げてき
た方々のみならず、JPNICのIP事業部の協力なくしては纏め上げられません
でしたので、ここで感謝の意を表したいと思います。
ご協力いただきました皆様、本当にありがとうございました。
Appendix.2 - IRR企画策定専門家チームメンバ一覧
当チームは、2年間に及およぶ活動を行い、その結果としてこのような報告書を
作成することができました。前任者にも敬意を表し、ここに各年度のメンバ
一覧を掲載させていただきます。
2003年度
Co-Chairs 近藤 邦昭 (株式会社インテック・ネットコア)
吉田 友哉 (NTTコミュニケーションズ株式会社)
メンバ 衛藤 将史 (奈良先端科学技術大学院大学)
外山 勝保 (日本電信電話株式会社)
長橋 賢吾 (東京大学大学院)
松本 順一 (日本テレコム株式会社)
2002年度
Chair 近藤 邦昭 (株式会社インテック・ネットコア)
メンバ 新井 直樹 (NTTコミュニケーションズ株式会社)
荒野 高志 (株式会社インテック・ネットコア)
江面 祥行 (株式会社インターネット総合研究所)
中川 郁夫 (株式会社インテック・ネットコア)
渡辺 直樹 (株式会社インターネットイニシアティブ)
吉田 友哉 (NTTコミュニケーションズ株式会社)
Appendix.3 - 参考文献等
1) Evolution of the Internet
http://www.unix.kg/eng/cisco/inter_arch/page004.html
2) Representation of IP Routing Policies in a Routing Registry
(RIPE-181++)
ftp://ftp.ripe.net/ripe/docs/ripe-181.txt
3) Routing Policy Specification Language (RPSL) - RFC2622
C. Alaettinoglu
http://www.ietf.org/rfc/rfc2622.txt?number=2622
4) Kengo NAGAHASHI, Hiroshi ESAKI, Jun MURAI,
"An Integrity Check for the Conflict Origin AS Prefixes in
the Inter-domain Routing", IEICE Transaction on Communications
Special Issue on Internet Technology III,
Vol.E86-B, No.2, pp.526-533, Feb.2003.
5) Tony Bates, Randy Bush, Tony Li, Yakov Rekhter,
"DNS-based NLRI origin AS verification in BGP",
draft-bates-bgp4-nlri-orig-verif work in progress,
July, 1998
6) Masasi Eto, Youki Kadobayashi, Suguru Yamaguchi,
"Improvement of Consistency among AS Policies on IRR Database",
TERENA Networking Conference 2003,
http://www.terena.nl/conferences/tnc2003/programme/papers/p3b1.pdf
----------------------------------------------------------------------
JPNICはインターネットの円滑な運営を支えるための組織です
- JPNIC
-
IPアドレス・AS番号
指定事業者向け各種申請手続/お知らせ
一般ユーザーの方
-
JPNIC会員
会員向け情報/各種変更手続
入会のご案内
