WHOISの後継!使いやすくなったRDAP

こんにちは。あきみちです。今回は、WHOISの後継プロトコルとして誕生したRDAP(Registration Data Access Protocol)を紹介します。

WHOISとRDAP

IPアドレス、AS番号、ドメイン名などの、番号や名前の資源を管理するレジストリが保持する情報を公開するための「WHOIS」というプロトコルがあります。whoisというコマンドをご存知の方も多いと思いますが、実はwhoisコマンドはWHOISプロトコルを使っているのです。このプロトコルは非常に古く「NICNAME/WHOIS」というタイトルのRFC 812は1982年に発行されています。

WHOISプロトコルを最初に定義したRFC 812と、RFC 812を上書きしたRFC 954の両方を上書きするものとして、RFC 3912が2004年に発行されていますが、TCPによる単純なプロトコルであるという基本的な部分は過去のWHOISを踏襲しています。

WHOISプロトコルの例としてRFC 3912に、以下のような図が記載されています。WHOISは、TCP接続が確立してすぐに問い合わせ文字列を入力して改行コードを送りつけると、相手が応答を返すという非常に単純なものです。

telnetコマンドを使って簡単に行えてしまうという意味では便利なWHOISプロトコルですが、応答の内容が特に定義されておらず、レジストリによってフォーマットがバラバラであるという使いにくさがあります。そういった問題を解決するために、IRIS(IRIS: The Internet Registry Information Service)というプロトコルがRFC 3981として2005年に発行されましたが、複雑過ぎるといった理由によって普及しませんでした。

その後、ARINやRIPE NCCなどのRIR(Regional Internet Registry)がRESTfulなWebサービスとしてWHOISデータを提供する試みを開始し、そこでの知見を標準化するという流れでweirds(Web Extensible Internet Registration Data Service)というワーキンググループが2012年に開始されました。weirdsワーキンググループは、RDAPというプロトコルに関連する以下のRFCを発行して終了しています。

  • RFC 7480 : HTTP Usage in the Registration Data Access Protocol (RDAP)
  • RFC 7481 : Security Services for the Registration Data Access Protocol (RDAP)
  • RFC 7482 : Registration Data Access Protocol (RDAP) Query Format
  • RFC 7483 : JSON Responses for the Registration Data Access Protocol (RDAP)
  • RFC 7484 : Finding the Authoritative Registration Data (RDAP)
  • RFC 7485 : Inventory and Analysis of WHOIS Registration Objects

RDAPの大きな特徴として、HTTPプロトコルで問い合わせが行なわれ、それに対する応答がJSON形式で統一されているという点があげられます。応答を機械的に処理する場合には、フリーフォーマットで運用者ごとにバラバラなフォーマットで返していたWHOISとは違い、レジストリごとに異なる解析方法を作り込む必要がなくなります。

もうひとつの大きな特徴がbootstrapと呼ばれる機能です。WHOISでは、各レジストリは自分が管理している資源であるかどうかだけの判断を行っていたため、どのレジストリが情報を持っているのかをWHOISクライアント側が知ってなければ正しい結果を得られませんでした。RDAPのbootstrapでは、その情報を持つレジストリのRDAPサーバへとリダイレクトが行われます。

実際に使ってみよう!

では、実際にRDAPを使ってみましょう。RDAPを試しに使ってみるのは非常に簡単です。RDAP用のURLの最後に 「/ip/○○○」(○○○部分がIPアドレス)、「/domain/▲▲▲」(▲▲▲部分が名前)、「/autnum/□□□」(□□□部分がAS番号)とすれば結果が返ってきます。

試しに、203.211.186.48 (本稿執筆時点でGeekなぺーじが運用されているIPv4アドレス)に関するRDAPの問い合わせを行ってみましょう。本稿執筆時点で、世界5つのRIRがRDAPサービスを運用しているURLは以下の通りです。

  • AFRINIC : https://rdap.afrinic.net/rdap/
  • ARIN : https://rdap.arin.net/bootstrap/
  • APNIC : https://rdap.apnic.net/
  • LACNIC : https://rdap.lacnic.net/rdap/
  • RIPE : https://rdap.db.ripe.net/

203.211.186.48は、日本国内で運用されているWebサイトでIPv4アドレス情報を持っているレジストリがAPNICであることはあらかじめわかっていますが、ここはあえて北米およびカリブ海のRIRであるARINで試してみましょう。

次のURLをブラウザでクリックしていただくと、APNICのRDAPサーバにリダイレクトされるのが確認できるはずです。

WHOISと比べて非常に便利であるRDAPですが、本稿執筆時点では、まだIPアドレスとAS番号での運用がメインのように見えます。

ARINが誰でもRDAPのbootstrapサーバを建てられるようにgithubでソースコードを公開していますが、ドメイン名に関するRDAPサーバで記載されているのは.infoのレジストリ(Afilias Limited)だけです。

試しに http://rdg.afilias.info/rdap/domain/example.info を見てみましたが、JSONでの結果が返ってきているのを確認できました。その他にも、いくつか .info のドメイン名を試してみましたが、普通に結果が返っています。

WHOISと比べると非常に良い感じのRDAP、是非、みなさまもお試しください!

NetFPGAでOpenFlowを柔軟に活用するShowNetデモ [Interop Tokyo 2016]

SDN/NFVサービスチェイニングのデモの中で、OpenFlowを今よりもさらに柔軟に使うコンセプトデモも含まれていました。

数年前と比べると、OpenFlowの仕様や実装が進化しているので、OpenFlowでできることは増えています。しかし、現在のOpenFlowは主にマッチと書き換えを行うものなので、直接計算は行えません(コントローラに判断を仰ぐ方法はありますが、それだとリアルタイムな処理は困難です)。

そこで、今年のShowNetではNetFPGA-SUMEとOpenFlowを使ってハッシュ計算を伴うロードバランシングを実現しています。

7

デモの内容としては、以下のようなものです。

  • イーサネットフレームは、NetFPGAを通過してからLagopusへとパケットが転送される。
  • OpenFlowで負荷分散をするための例として、送信元IPアドレスと宛先IPアドレスでハッシュして、イーサネットフレームに含まれる送信元イーサネットアドレスを書き換える。
  • NetFPGAは、ハッシュ結果を送信元イーサネットアドレス下位8ビットにマーキングをしていって、OpenFlowは送信元イーサネットアドレスの48ビットをマッチして使って転送。
  • NetFPGAに入ってくるイーサネットフレームは、上位のルータからなので、そもそも入力は毎回同じ送信元イーサネットアドレスだけど、NetFPGAが下位8ビットを変更する。

この他に、OpenFlowのフローエントリ数を減らす工夫(微調整)も行われています。

今回サーバ上で動いているVMは8台なので、3bitで全てのVMを指定できます。NetFPGAはそのまま8bitに埋め込み、Lagopusのルールは送信元MACアドレスのうちマスクを使って下位3bitのみを見ています。

8bitでは全てのパターンを指定するのに256個のフローエントリが必要になりますが、下位3bitを見るだけであれば8エントリのみで全てのVMにトラフィックを転送することができます。これによって、OpenFlowでIPアドレスをマッチして転送するのと同じことを、8個のフローエントリで実現しています。

L3な機能(VirNOS含む)が使われるときは、ARP解決のために、OpenFlowで宛先イーサネットアドレスを宛先とするL3デバイスのMACアドレスに書き換えています。

NetFPGAを使ったデモは、NOCメンバーがShowNet 2016のために独自開発されたものです。なかなかマニアックですが、こういうの大好きです。


LagopusとNetFPGA(上に基盤むき出しで乗っているのがPCIカード用給電されたNetFPGA)

SDN/NFVサービスチェイニング@ShowNet 2016 [Interop Tokyo 2016]

ShowNetで行われるSDN/NFV関連デモは、年々進化しています。今年は、昨年よりも柔軟性と拡張性が大幅にアップしたSDN/NFVサービスチェイニングがShowNetで運用されていました。広帯域・高速処理が必要なバックボーンネットワークを構築しつつ、必要なトラフィックのみをSDN/NFV機器へと誘導することで、SDN/NFV機器を直接バックボーンネットワーク内に設置せずに運用しています。

今年のShowNetで行われたSDN/NFVサービスチェイニングの非常に大きなポイントは、BGP Flowspecを使ってバックボーンルータから特定のトラフィックをSDN/NFVエリアまで誘導できるようにしてあるところです。今年のShowNetでは、SDN/NFVエリアがdcwestエリアにまとめてありますが、任意のタイミングで任意のトラフィックをバックボーンからSDN/NFVエリアを経由させることができます。

1

2

SDN/NFVエリア内では、OpenFlowを使ったサービスチェイニングが行われています。ファイアウォールやDDoS mitigationを行う機器に対してユーザ単位でトラフィックを誘導できるようになっています。

3

4

5

今年のShowNetでのSDN/NFVデモは、SDN/NFV機器へとトラフィックを誘導することを目的として、通常トラフィックが通過する経路上にSDN/NFV機器を設置せずに実現できているという点が昨年と大きく異なります。

昨年のShowNet構成では、出展社などのユーザはvCPE(virtual CPE)に収容され、そのvCPEを通過するトラフィック”のみ”がOpenFlowで変更されるというネットワーク設計でした。そのために、OpenFlowで実現していたサービスチェイネイングの網自体もバックボーンから見ると下流にありました。必要に応じてサービスチェイニングを利用できるようにようするために、すべての出展社へのネットワーク提供の入り口に工夫をする必要があったのが去年の構成です。

去年の構成と比べると、今年の構成はシンプルでエレガントだと思いました。今年は、ShowNet各所でBGP Flowspecが活用されていますが、BGP Flowspec対応機器が増えたことで、サービスチェイニングを行う機器に流入するトラフィックを柔軟に制御しやすくなるので、処理能力に制約がある高機能機器も使いやすくなるのかも知れないと思える展示内容でした。

ShowNet 2016 セキュリティオーケストレーション [Interop Tokyo 2016]

今年のShowNetのセキュリティ関連デモは、次の図のような構成になっています。NFVはサービスチェーニング、BGP Flowspecを使ってDDoS mitigationを行う機器へのトラフィックの誘導、TAP/ミラーリングと解析、来場者や出展社への通信サービス提供箇所での監視とブロックなどです。

今年のShowNetでは、様々なセキュリティ製品のオーケストレーションをNICTのNIRVANA改が行っています。ここ数年は、毎年グラフィカルな攻撃可視化を行っているNIRVANA改ですが、今年は大幅にバージョンアップしてShowNetでのセキュリティオーケストレーションを行うようになったようです。

今年のセキュリティ連携は、以下のような構成になっています。

  1. タップ/ミラーしたトラフィックを検知装置に分配
  2. 検知結果をsyslogで通知して集約
  3. 各種機器にフィルタを設定

今年の構成では、ShowNetのトラフィックがタッピングもしくはミラーリングされ、検知機器に分配されます。検知機器は何らかの攻撃を検知するとsyslogで通知します。各種機器からのsyslogを収集したうえで、それらを統合的に扱うのがNIRVANA改です。

解析装置によって攻撃が発見されると、ShowNet運用者に攻撃内容と遮断する設定を行う機器の候補が通知されます。NIRVANA改は、ShowNetのトポロジを把握した上で防御用の設定を入力する機器の候補の計算も行うようになっています。ただし、今回は、自動的に攻撃を遮断するのではなく、その攻撃を遮断するのかどうかの判断をオペレータが行うという運用になっています。

ShowNet運用者が、攻撃を遮断すると判断すると、遮断を行う設定が各種機器に対して行なわれます。各種機器への設定入力の方法も機種依存します。今年のShowNetでは、NETCONF、BGP Flowspec、REST API、syslogの4種類の手法でNIRVANA改から機器へと設定が行われています。

シングルベンダーであればひとつの手法で一気にできることでも、マルチベンダーになるとこのようなオーケストレーションが必要になるというのが良くわかるデモと言えるかもしれません。

体験コーナーでMosaic、HotJava、Netscape、Mozillaを使いました [Interop Tokyo 2016]

NCSA Mosaicをいじったり、XMint端末でX11プログラミングをしていた18歳の夏を思い出すような、おっさんホイホイ展示が7ホールにありました。NCSA Mosaic、HotJava 1.0、Mozilla 1.0、Netscape Communicator 4.8、世界初のWebブラウザであるWorldWideWeb(ブラウザ名です)が動体展示されていたのです。いやぁ、良く動く状態を作ったなぁと感心してしまいました。

今朝行われたプレス向けブリーフィングで昔懐かしのブラウザ展示に関して紹介されたとき、少しだけプレスルームがざわつきました。隣にいた記者と私の会話が「おっさんホイホイですね(笑」でしたが、多分、多くの方々がそういう感想を持たれたと思います。


プレス向けブリーフィングの様子

Sun SPARC Station IPXで起動されたNCSA Mosaicと、NeXTで起動されたWorldWideWebはショーケースの中なので触れませんが、Mosaic、HotJava、Mozilla、Netscapeが実際に操作できるWindows端末もありました。SUN SPARC Station IPXは、私が研究室に入って初めてOSをインストールした機種です。懐かしすぎます。


体験コーナー

早速、懐かしのブラウザをいじって遊んでいたのですが、どこもかしこも表示できません。バーチャルホストだと駄目だったり、HTMLが新しすぎて駄目だったり、文字コードの問題で駄目だったり、といった感じです。ブラウザがいきなり死亡したりもしました。

どこか表示できるページはないかなぁとHotJavaなどをいじって遊んでいたら、たまたま通りがかった大学の先輩が「大学時代の自分のホームページを表示してみたら」と言いました。言われてみれば、自分が昔作ったままで放置しているWebページは、すごくレガシーな感じで残っています。「このページを最後に見たのは何年前だろうか。。。」とか思いつつ、化石を発掘した気分になった今日この頃でした。