RPKIはじめました(少し)
インフラストラクチャ本部の黒河内です。
グリーでゲームのプラットフォームのネットワークの設計・構築・運用を主 に担当しております。
※この記事はGREE Advent Calender 11日目の記事になります。
今回はRPKIについてお話をしたいと思います。
RPKIとは”Resource Public-Key Infrastructure”の略で、いまインターネットの経路交換の
信頼性を向上させる観点で注目されている技術の一つです。
※詳細は以下のJPNIC様のページに詳しく記載されております。
https://www.nic.ad.jp/ja/rpki/
そもそもインターネットとは
インターネットでは自身が管理しているネットワークをインターネット上で認 識させるために
各々個別にグループ化させるAS(autonomous system)番号というのを持っております。
ちなみにグリーは55394という番号です。
この番号に自社で管理しているネットワークのPrefix(IPアドレス群)を紐付けて
AS番号をもつもの同士で互いに”経路交換”をすることでインターネットは構成されております。
何が問題なのか?
ただ、その中で大きな問題がございます。
現時点で“AS番号”と”自社で管理しているPrefix”の紐付けを証明できる機関は存在しません。
そのため例えばグリーの持っているPrefixを、グリーではない別の事業者のAS番号と
紐づけてインターネット上に経路を発信した場合、 そちらの業者にグリーのTrafficが
吸い込まれてしまう恐れがあります。
これを"経路ハイジャック"や"Mis-Origination"といいます。
https://www.nic.ad.jp/ja/rpki/mis-origin.html
既に多くの被害事例がございます。
経路ハイジャックやmis-originationを防ぐために、AS番号とPrefixを紐付ける証明書を作成、
信頼できる証明書サーバを通じて公開します。そして、 ネットワーク管理者がルーター上に
存在する経路を公開されている証明書をつかって評価する為の一連の技術がRPKIと呼ばれます。
ちょっとやってみた
いまどきはソフトウェアルータの評価版などで、(手軽に)BGPルーターを構成できるので、
以下の環境を作ってちょっと試してみました。
- 環境:グリー内検証環境
- VMware ESXi5.1サーバ(評価版)
- CISCO CSR1000v(評価版)
- Juniper Firefly
今回はJPNIC様のROA(Route Origin Authorization)キャッシュサーバ(以下ROAサーバ)に接続し、
以下の2つのダミー経路を流して、経路を評価できるかテストしました。
- インターネットに経路があり、ROAキャッシュサーバに登録されているPrefix 2.0.0.0/16
- インターネット上ではフランステレコムさんのPrefixになります
- プライベートIPアドレスで、ROAキャッシュサーバには登録されていないPrefix 10.0.0.0/8
ROAサーバの情報は以下の通りです。2.0.0.0/16は登録があり、10.0.0.0/8は登録なしですね。
1 2 3 4 5 |
csr1000v# show ip bgp rpki table | include 2.0.0.0/16 Network Maxlen Origin-AS Source Neighbor 2.0.0.0/16 16 3215 0 192.41.192.218/323 csr1000v# show ip bgp rpki table | include 10.0.0.0/8 csr1000v# |
そして、OriginValidation前のCSR1000vでの経路情報は以下の通りです。まぁ普通ですね。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
csr1000v#show ip bgp Load for five secs: 0%/0%; one minute: 0%; five minutes: 0% Time source is NTP, 15:16:13.133 JST Fri Nov 28 2014 BGP table version is 17, local router ID is 192.168.1.48 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path *> 2.0.0.0/16 192.168.1.49 0 65001 i *> 10.0.0.0 192.168.1.49 0 65001 i |
これにOriginValidationの処理を以下の通り加えました
- Invalid = ROAサーバのAS情報とRoutingテーブルのAS情報が一致しなかったときは、LocalPreferenceを90にする
- Not found = ROAサーバに情報がなかった場合は、LocalPreferenceを100にする
- Valid = ROAサーバのAS情報とRoutingテーブルのAS情報が一致したとき、LocalPreferenceを110にする
1 2 3 4 5 6 7 8 9 10 11 |
route-map origin-validation permit 10 match rpki invalid set local-preference 90 ! route-map origin-validation permit 20 match rpki not-found set local-preference 100 ! route-map origin-validation permit 30 match rpki valid set local-preference 110 |
上記適用(OriginValidation後)のCSR1000vでの経路情報の結果です
1 2 3 4 5 6 7 8 9 10 11 12 13 14 |
csr1000v#show ip bgp Load for five secs: 1%/0%; one minute: 2%; five minutes: 2% Time source is NTP, 15:08:17.860 JST Fri Nov 28 2014 BGP table version is 11, local router ID is 192.168.1.48 Status codes: s suppressed, d damped, h history, * valid, > best, i - internal, r RIB-failure, S Stale, m multipath, b backup-path, f RT-Filter, x best-external, a additional-path, c RIB-compressed, Origin codes: i - IGP, e - EGP, ? - incomplete RPKI validation codes: V valid, I invalid, N Not found Network Next Hop Metric LocPrf Weight Path I*> 2.0.0.0/16 192.168.1.49 90 0 65001 i N*> 10.0.0.0 192.168.1.49 100 0 65001 i |
- 2.0.0.0/16は Origin-ASが違うのでInvalid(I)でLocalPreference 90
- 10.0.0.0/8は ROAサーバに登録がないので、Not found(N)の表記でLocalPreference 100
と期待通りの動作になりました!Validはできませんでしたが、、、きっと同じです。
考察と今後
というわけでモックアップはうまくいきました!
しかし、本番ネットワークに適用するには、越えるべき障壁が多いとも感じました。
その辺りは来月静岡で開催されるJANOG35にて、続きをお話したいと思います。
http://www.janog.gr.jp/meeting/janog35/
あと、今回利用したCSR1000VとFireflyのConfigも以下に添付します。
CSR1000v-config Firefly-config
皆様もお試しあれ!
明日は橋本さんによる記事です。お楽しみに!