BoF開催報告書

■ 本議事録について

質疑応答ではJPNIC関係者および発表者の発言のみ、 発言者を明記しています。 発言者の記名が無いものは参加者からの発言となります。

[はじめに]

• これまでのBoFでいろいろと意見をいただいてきていて、JPIRRにもその意見をフィードバックして、新しい機能として取り入れてきている。
• JPNICでも、JPIRR試験サービスの正式化にむけた準備を進めている。
• 今回についても、新しい取り組みをいろいろとやってきているので、その取 り組みについてご紹介して、みなさんと議論をしていきたいと考えている。

■JPIRR Update(川端宏生(社団法人日本ネットワークインフォメーションセンター))

[補足]

• 11/15にMail-Fromの認証を廃止したが、Mail-From認証のみのメンテナーオブジェクトについては、すぐに利用できるように準備を行っている。該当する組織の方は、問い合わせ窓口までコンタクトして欲しい。

■IPv6 IRR(外山勝保 (JPNIC IRR企画策定専門家チーム/日本電信電話株式会社))

[質疑応答]

• レジストリが登録するベータベースだと、 /48とか/64のinet6numオブジェクトはあってはならないものではないか。(近藤)
  • IPv6については、レジストリに登録された内容とIRRのオブジェクトの内容がほぼ同じになってくると想像している。登録してはいけないものかどうかについては調べる必要があると思う。(外山)
• /48のオブジェクトがあるということは、 レジストリからの/48の割り振りがあるということではないのか。 /48はともかくとして、IPv6のポリシー上、 /40とか/42の割り振りは聞いたことはない。 もしもこれが正しいものとすると、 レジストリの登録が間違っているのではないか。(近藤)
  • /48はCritical Infrastructureとして割り振りをされていることがあるか確かに、/40とか/42の割り振りは聞いたことはないので、この登録が正しいかは調べてみる。(外山)

■ゴミオブジェクト問題への取り組みついて(衛藤将史(JPNIC IRR企画策定専門家チーム/独立行政法人情報通信研究機構))

[質疑応答]

• BGPで利用されているフルルートとJPIRRに登録されているオブジェクトとの比較を行ったとのことだが、 フルルート内で見つからなかったRouteオブジェクトについては、 Routeオブジェクトが登録されているが、 経路広告されていない経路のことになると思うが、 そのRouteオブジェクトを管理するメンテナに、 オブジェクトを削除するように通知のメールを流すのか？(近藤)
  • 意図的に経路広告していないケースもあるので、このRouteオブジェクトが必ずしも問題になるとはいえないと考えている。(衛藤)
  • 情報がかけ離れていなければ、正しいのではないかとも思う。逆にユーザの立場からすれば、経路は流れているけど、Routeオブジェクトが登録されていないケースの方が、メールで通知する/されるモチベーションは上がると思う。ただ、その場合には、どこに通知するか、という問題点はある。(近藤)
  • as-setオブジェクトに登録されている、AS番号をoriginとするrouteを検索する等、逆の検索をしないといけない。自分が登録したことを忘れている場合に通知してくれると嬉しいと思う。(吉田)
  • 上記のようなケースを機械的に見つけ出す方法が思い浮かばなかったので、その方法は書いていなかったが、確かに必要な機能だと思う。(衛藤)
• 一時的に、または万が一の時のために、 フルルート内にないRouteオブジェクトを登録している場合も想定されるので、 オブジェクト内に一定の文字列が記述されていれば、 メールで通知しないような仕組みにしてはどうか(近藤)
  • 例えば、descriptionにそのような文字列を記入すれば、メールによる通知を行わないようなしくみがあると思う。(衛藤)
• その人に直接通知をする必要はなくて、 1週間とか3日に1回ぐらいの間隔で、 経路情報とデータベースに登録されたRouteオブジェクトの情報を、 あるメーリングリストに投げるようなしくみにするというのもある。 その情報を見たい人だけがMLに登録することになるので、 必要な人だけに情報が届くしくみになる。 あるいはWebページなどで公開する形もあると思う。(近藤)
  • 他の人の目にさらされる方が、効果が上がるかもしれない。(近藤)
• 本当に経路広告元が正しいのかについて調べて、 通知を行うことも考えている。(衛藤)
  • その場合には、通知が送られることになるので、良いと思う。(近藤)
• 視点として考えた時に、元々、JPNICでは、 (1)割り振りの情報と(2)IRRの情報との整合性について考えてきていたので、 RIR/NIRがIRRをやる、と考えてきていたと思う。 このプレゼンでは、 (2)IRRと(3)実際に経路広告されている情報が一致するかについてみていると思う。 この3者のどこをチェックするか、 ということをもっと明確にしたほうが良いと思う。 先ほどの質問もこの点を明確にしないと答えが出にくいと思う。
  • IRRの登録情報を神であり、IRRの情報が絶対だと思っている。 割り振りを受けた人がそのアドレスレンジで経路広告を行うわけなので、 割り振られたアドレスが正しくIRRに登録されている。 逆に、割り振りを受けたアドレスレンジ以外が登録できないようにしてしまうのが良いと思っている。 その関係は正しく保つべきものである。(近藤)
  • IRRの情報は、 経路情報のReferenceとして参照されるべきものと考えている。 IRRに登録されようとする情報を、 インターネットレジストリの持つ情報と比較されていて、 間違った情報を登録できないようになっている。 登録されたものを、さらに細かな単位で登録する時に、 誰に登録を許可させるかをはっきりとして、 管理者を明確にしていく。 それが、インターネットに流れる経路のReferenceである、 と考えている。 ここまでは以前と何ら変わっていない。(近藤)
  • 一番大きな情報は割り振り情報になるのではないかと考えている。 例えば、/16の割り振りを受けた時に、 /16が一番大きな単位になる。 そのアドレスを誰が管理するか、 インターネットの経路のReferenceとして、 誰が管理するかと言えば、メンテナである。
    メンテナは、/16のブロックを管理することができて、 その管理者は、/16に含まれる/18を管理できる人を決めて、 その人に/18の管理を委譲する。 その人は/18のオブジェクトを登録することが可能になる。 結果として、インターネット上に/18の経路が、 この人の管理の元で広告されます、 という参照データベースにIRRはなっていく。(近藤)
  • 経路情報とつき合わせていて、 IRRに登録されていないのに広告されている経路は、 不正利用の可能性があるかもしれない。 IRRが神であれば、登録がないのに経路広告がある場合には、 (あまり強くはいえないが)不正利用であると言えると思う。
    IRRに登録されているのにもかかわらず、 経路広告が行われていない場合は、その/16を管理している人が、 なにかあった時に/17*2や/18のオブジェクトを使うという意思を(何らかの形で)表していると理解している。(近藤)
• IRRは神であり、IRRに登録されている情報が正しいとすると、 実際の経路情報に対して正しいかどうかを判断する。 もう一つの話は、RIRのデータ登録の時に、IRR(神)はどうする、 という話があると思う。
  • 具体的な例でみると、 IPv6では経路広告をしないアドレスの割り振りが認められている。 レジストリデータベース上では割り当て情報が存在するが、 経路広告は行われていない。 その場合に、IRRはどうするのか？ 「私は経路広告を行いません」と言うことを宣言するのか。
  • 仕組み上は、レジストリが割り振りをする。 メンテナーを作成する際に、 どのブロックを登録可能かというDBにアドレスの範囲を登録する。 Route オブジェクトの登録の際にその情報を参照するようなしくみを想定している。(近藤)
• 近藤さんの説明だと、やはりレジストリデータベースが神になると思う。 誰が神で何と比較をしてどのようなアラートをあげるかについて、 明確にしないとユーザが混乱とすると思う。
  • どちらかが悪いので、登録情報を確かめてください、 という感じではなく、 Aが正しくてBが間違っているのでBを直してください、 ということを第1義的にやらないといけないということで理解した。(衛藤)

■ISPにおけるIRRの利用について(河野誠(ソフトバンクBB株式会社))

[質疑応答]

• スライド中にフォーマットの統一とあるが、 どの部分のフォーマットのことを指しているのか？(近藤)
  • 電子メールでオブジェクト登録を行う際のフォームのことか？ 現在、IRRdでもRIPEのソフトウェアでも、 現在使われているフォーマットは定義されており、 中に記入するものは統一されているので違いはない。(近藤)
• スライド中に、 オブジェクトのsource記述が柔軟に対応ができないかという内容があるが、 これの意味を教えて欲しい。(近藤)
  • 例えば、RADBとJPIRRの2箇所登録したい場合、 JPIRRにメールを送るとRADBにも登録される、 という内容をイメージしている。(河野)
  • しくみ的な問題よりも、登録をして良いのか悪いのか、 という問題になると思う。 RADBの更新権限をJPIRRに誰に持たせるか、という問題になるので、 まだまだ議論の余地はあると思う。 構造的には、EPPを利用すれば実現できるのかもしれない(近藤)
• 以前に、 把握できるすべてのIRRにコンタクトを取ってミラーをしようとしたことがある。 IRRの中には、 自組織とのpeerとIRRを共有してフィルタを作成するためだけの目的で、 RADBとミラーを行っているところもあることがわかった。 Peerするのであればミラーを受け入れるという組織が多かった。
  一部でプライベートな用途にIRRがあることは事実で、 グローバルなオブジェクトとプライベートなオブジェクトが世の中にあるのかもしれない。 プライベートなオブジェクトをIRRに登録することで、 内部のネットワークの管理が楽になることもまた事実である。 IRRにはそのような力も持っているので、 そのような用途のIRRをいっしょにして考えるのではなくて、 ある程度分離して考えるようになると、 違う世界があるのかもしれないと考えている。 そうすれば、IRRの使い道も広がるかもしれない。(近藤)
• IRRの目的には2つあるようなので、確認をしたい。 経路情報データベースとしてIRRを利用しているケースと、 自分が割り振りを受けた情報を全て登録して、 自分が割り振りを受けたアドレスブロックはこれだけあることを、 他の人に参照させるような使い方をしている場合もあると思う。 この2つの用途が混在していて、 どちらの使い方を優先させるのかは難しい状況にあると思う。 本来であれば、 経路広告を行わないアドレスブロック登録しないべき(したくない)であると考えている人も多いと思う。
  現状では、 割り振りを受けていることを主張できるのはIRRしかないと考えている人もいるため、 インターネットレジストリが持っているアドレス割り振り/割り当て情報を確認して、 通知を上げる機能があれば、 IRRに経路広告を行わないアドレスブロックを登録をしなくても良いという風にも思える。 天使が天使として活動するのであれば、 神の情報を参照する(できる)ようにしたほうが良いと思う。 APNICでは、天使と神がほぼ一緒になっているが、 JPNICでは天使と神が独立して活動を行っている。(松本)
• IRRが利用されているのに、 IRRのデータが正しく整備されていないことが現在の問題だと思う。
• 登録情報を正確に保つための具体的な良いアイデアがあれば教えて欲しい。
  • ISPとしてもレジストリとしても大変な労力を割く必要があるとは思うが具体的には何かアイデアがあるというわけではない。

■CRISP for IRR
　　(吉田友哉 (JPNIC IRR企画策定専門家チーム/NTTコミュニケーションズ株式会社))
　　(近藤邦昭 (JPNIC IRR企画策定専門家チーム/株式会社インテック・ネットコア))

[補足]

• CRISPというのは、もともと、 レジストリ間のデータを相互参照するプロトコルとして考えられているので、 ミラーリングとは違う構造になっている。 このプロトコルの良い点は、各レジストリにデータが残らない点、 情報を持たないレジストリに問い合わせがあった場合に、 上位のレジストリに参照を行う仕組みになっているところである。(近藤)
  • 一時期、RWHOIS というのがあったと思うが、 それをイメージしていただければよいと思う。(近藤)
  • 登録関係は全くない、あくまでも参照系の話になる。 登録と言うことになると、現在、 検討対象外となっているEPPを使うことになる。(近藤)
  • 下のレイヤーにはIRISというのがあって、その上のレイヤーには、 EPPとCRISPが乗っている、という関係である。 基本的には、同じカテゴリーのものであると考えてもらえればよい。 EPPとCRISPはそれぞれ別々に検討されているのが現状である。(近藤)
• IRRでCRISPを利用する際にデメリットと思われる点は、 CRISPではrootという概念が必要になっていて、 最上位を定義しないと検索が始まらないというプロトコルであるところだと考えている。 rootが特定できないところが現在の大きな問題点である。 したがって、どういう検索Pathを作るかについては、 まだ検討されている。 DNSで逆引きの検索ができるぐらいなので、 CRISPについてもできるのではないかと考えている。(近藤)

[質疑応答]

• フィルタリングの情報はどこか特定のIRRの情報を見るか、 ローカルの情報を見るかといわれれば、 特定のIRRを使って欲しいところだが、 実際にフィルタを書こうとすると、 IRRを見ているだけで時間がかかるので、ローカルの情報を見たい、 と考えている。(近藤)
  • そういう意味で、ローカルに何らかのChashみたいなに、 すばらしく早く検索できるようなものがあって欲しいと考えている。 ミラーリングだと、自分の手元に全てデータが残るので、 検索を行うととても早い点がとてもよい。 CRISPを使うとそのメリットが失われる。 運用に落ちてきた時に、 そこをどういう風にクリアしていくのかが、 いま気になるところである。(近藤)
• どこまで情報が正確である必要があるのか、 フィルタリングの情報を作る時に、 1時間おきにきちんと正確な情報を出して欲しい等について、 ぜひISPのオペレータの方に意見を聞きたい。(吉田)
  • 1日1回位更新されるものであるということが理解できれば、 その更新頻度でも問題ないと思うが、別の視点で、 フィルタを緊急で開けたい場合の対応などが考えられていれば良いと思う。
    また、IRRから情報が引けるから良いというものでもなくて、 名前空間は一意でないので、 正しいものが引けているかどうかの検証が大変である。 as-setオブジェクトに他のas-setオブジェトの情報が書かれている時に、 どこのIRRを見に行けばよいのか、 同じsourceと仮定してよいのか、 まだ、表記の自由度が大きいところが逆に悩みどころである。 現在は、 このオブジェクトはどのIRRに登録されたものなのかを聞いて、 そのIRRの内容を参照するようにしている。
  • 1日1回位更新されるものでも問題ないと思う。 緊急の場合には、 手動でルータの設定を直接いじれば良いかもしれない。
  • 自組織の経路が届かない場合に何とかして欲しい、 というのがあると思うが、 自分が設定しても何とかならない場合もあると思う。 お互いの緊急度の考え方が重要になると思う。(近藤)
  • フィルタリングはExact Matchで行っているので、 IRRに/22のRouteオブジェクトが登録されている場合、 /23の経路を受け入れないような運用をしている。(吉田)

■IRR Security(木村泰司(社団法人日本ネットワークインフォメーションセンター))

[補足]

• 1月に開催されるJANOG17でも、IRRのセキュリティに関する議論を行う予定である。そこでも詳しい話をしてもらう予定にしている。

[質疑応答]

• なし

■最後に(吉田)

• メンテナーオブジェクトもRouteオブジェクト数も以前に比べてだいぶ登録数が増えてきているので、 IRRがどのように利用されているかについても把握していきたいと考えている。
• 来年度以降、 JPIRRサービスも正式サービス化を予定しているので、 IPアドレスのレジストリのデータベースとの相互参照より、 信頼度の高い情報を登録できるなどの機能を考えている。
• ミラーリング先の追加についても議論を行う機会を設けたいと考えている。
• 複数のIRRにオブジェクトを登録することについては、 なるべくやりたくない人が多いと思うが。 情報の冗長化を図っている人も多いのではないかと考えられる。
• 1月に開催されるJANOG17でも、 今回のトピックのようなことを議論できれば良いと考えている。