インターネットをよりロバストに。RPKIはじめました
2021年03月31日 水曜日
CONTENTS
こんにちは、ネットワーク技術部の蓬田 裕一です。
今回は10月にIIJエンジニアブログに掲載しました インターネットをよりロバストに。RPKIはじめます の続編として導入後の状況や運用事例についてご紹介します。
RPKI ROA/ROVの技術詳細については前回のブログをご確認いただければ幸いです。
記事の内容についてはJANOG47で発表した資料をもとに作成しています。
当日の発表資料については以下のリンクをご確認ください。
JANOG47へのリンク IIJ/AS2497でRPKIはじめました
IIJでのRPKI実装状況
前回のブログ執筆段階ではまだIIJバックボーンネットワークへの導入は行っておりませんでしたが、2020年11月から12月にかけてIIJ保持アドレスのROA(Route Origin Authorization)の登録、AS境界ルータへのROV(Route Origin Validation)の実装を徐々に行いました。結果として、IIJではJPNIC割振分の保持アドレスで12月時点に登録可能なブロックの内 IPv4: 81.6% IPv6: 100% のROA登録の完了、およびIIJの対外接続ポイント(IIJのTransitユーザを除く)においてROVによる invalid経路のRejectを行いました。
ROV実装後のIIJバックボーンネットワーク
IIJバックボーン内部のBGPフルルートについてROVを行った結果、Validation結果が invalidとなる経路が約3,000経路ほど存在することがわかりました。これはフルルート全体(2021/01時点で90万経路)における 0.3%程度の割合です。ちなみにstatusがvalidの正当な経路としては 23.4%、合致するROAがなく判定ができない not foundについては 76.2%でした。まだまだ not found経路が多く、インターネット全体でもROA登録を推進する必要があると思われます。
ROV後の処理について、IIJはROVの結果 invalidとなった経路をルータで破棄するポリシーとしています。これはinvalid経路が本当に不正なのか、それとも意図しない設定ミスなのか、をIIJでは判断できないこと、また通信に本当に必要ならばinvalidからアドレス保持者で改善する必要があるのではないか、という認識のもと一律破棄で決定しました。また not found経路については現時点で相当数の割合を占めるため valid経路と同等な扱いとしています。
実際に経路をRejectする箇所は基本的にIIJのAS境界ルータです。IIJバックボーン内部のルータでRejectをするよりも各ASと相互接続する箇所で実施したほうが、ネットワーク内部にinvalid経路が流入せず、安全と考えます。また、本来であればIIJがTransitを提供している接続点でも実施することが望ましいのですが、初期導入時においてはIIJのUpstreamとPeer接続に限定しています。お客様接続点での導入は別途改めて検討していきますのでお待ちください。
IIJのUpstreamおよびPeer接続点となるルータはバックボーンネットワーク内に数十ノード存在します。2020年11月頃から徐々に設定を適用していき、2020/12/07で全ルータへの実装が完了しました。導入の手順としていきなりinvalid経路をRejectするのではなく、一時的にBGP local preference を 0 に設定し、IIJネットワーク内部で優先度を最低にしておき、最適な経路選択でなくなった時にどの程度影響が出るのかを把握した後に順次Reject作業を進めました。幸いにして、local preference 0 を設定したときやinvalid経路をRejectした時においてもお客様やIIJサービス担当者から問い合わせは無く、影響は最低限だったのでないかと推測しています。
下記はIIJバックボーン内で計測していたinvalid経路数のグラフです。Rejectを有効にした日以降はIIJとTransit接続しているお客様においてもIIJから受け取るBGPフルルートでinvalid経路が減少していると思います。
2020/12/04の段階で既に大きく減っていますが、これはIIJの一部のUpstream ASを残して設定したためです。いわゆるTier1 ISPにおいてもROVによるinvalid経路のRejectが進んでいるため、今回最後に残した Upstream ASからも既にinvalid経路が削られていることがわかりました。また、2020/12/07に設定後は限りなくinvalid経路は減ったのですが、残念ながら0とはならず、invalid経路が30-40ほど存在している状況です。ちなみにinvalid経路として残っているものは RFC6472で使わないよう推奨されている AS_SETがAS-Pathに含まれている経路でした。これはROVを実施しているルータのOSの都合で、一部のノードではAS_SETがうまくinvalid判定されておらず、not foundとして内部へ流入しているのが原因となります。こちらはOSの実装依存になるため適宜対応OSへの入れ替えにより将来的にはより0に近づくと予想されます。
* 45.88.168.0/22 3356 35913 35913 35913 35913 35913 35913 35913 35913 {58110} I
* 83.230.0.0/19 3356 13293 15744 15744 15744 15744 35434 {202220} I
* 83.230.32.0/20 3356 13293 15744 15744 15744 15744 35434 {199551} I
* 87.120.40.0/24 2914 3223 {8262 34224} 201200 I
* 103.150.208.0/23 7473 38193 136969 {140732} I
* 114.5.4.0/22 4761 {65055 65066} ?
* 114.5.5.0/24 4761 {65055 65066} ?
* 115.87.72.0/24 38082 7470 {17556} ?
* 115.87.73.0/24 38082 7470 {17556} ?
* 179.51.117.0/24 2914 52320 {262220 263210} I
* 181.225.80.0/20 2914 52320 {18747 52468 262220 263210} I
* 185.186.206.0/24 8529 28885 {206350} ?
* 195.82.176.0/21 3356 13293 15744 15744 15744 15744 35434 {62031} I
* 200.143.192.0/19 2914 1916 {263273} I
* 210.2.136.0/24 701 5511 8452 38193 58470 23966 {136974} I
* 212.106.160.0/21 3356 13293 15744 15744 15744 15744 35434 {199551} I
* 213.91.157.0/24 2914 3223 {34224 205132} 199512 I
* 2a01:cc00::/32 2914 5511 47377 {12493} I
* 2a03:c5c0::/32 6453 1680 198484 {198484} I
* 2a0e:9b40:1000::/48 3356 9002 208431 {208431} I
今回Rejectしたinvalid経路についてもう少し詳しく言及したいと思います。IIJ社内における導入検討においても、どういった経路がinvalidなのか、本当に影響がないのか、という声は上がっていました。そのためinvalid経路がどんな理由でinvalid判定されているかの調査を行いました。以下が当時調査した結果です。
- PREFIX_TOO_LONG
- Maximum Lengthより細かい
- ISMATCH_ORIGIN
- Origin ASがROAとmismatch
- MISMATCH_ORIGIN + PREFIX_TOO_LONG
- Maximum Lengthより細かい経路 & Origin ASがROAとmismatch
- PREFIX_TOO_SHORT
- 包含されるROAが存在することによる Maximum Length mismatch
- MISMATCH_ORIGIN + PREFIX_TOO_SHORT
- Origin ASがROAとmismatch & 包含されるROAが存在することによる Maximum Length mismatch
理由としては、Maximum Lengthの設定の差異による invalidが一番多く、続いて Origin ASの差異、その2つの複合と続きます。事象自体は設定ミスなのか、はたまた本当に不正利用なハイジャック経路なのかはわかりませんが継続していたことを考えると考慮漏れの可能性が高いのでは無いでしょうか。
そのinvalid経路の内、invalid以外の代替する経路があればRejectしても到達性は失われないため大きな問題とはなりにくいのですが、やはり完全に到達性が失われる経路は存在し、フルルートの0.152%はRejectにより経路が消失してしまうことがわかりました。ただし、経路のOrigin ASや通信先の経路情報を確認し、我々としては大きな影響がでないだろうと予測できたこと、IIJがRejectしなくともインターネット上では既にRejectしているASも存在するということを鑑みて実行に移しました。結果は先に書いたとおりですが、現在でも通信影響が出ているという申告はありません。
ただ、今後どうしてもIIJでinvalid経路を受け取る必要が出てくることがあるかもしれません。緊急避難として、SLRUM(RFC8416)を用いて、一時的にIIJ内部のみにvalidなROAを作成し経路を受け取る仕組みを用意はしています。ただRPKIのポリシーからは少し反することもありますし、結局のところインターネット全体で俯瞰すればどこかのASではRejectされてしまう経路であることは変わりないのでそこまで意味のある対応ではないかもしれません。
IIJバックボーンでのROV実装構成
ここまでIIJネットワークでROVを実施したあとの影響について述べました。次に、IIJネットワークにおけるROVの実装方法について簡単に取り上げます。
各ルータでROVを実施するためにIIJネットワーク内部には各CA(Certification Authority) よりROAを取得するキャッシュサーバが存在しています。ROAキャッシュサーバはRTRサーバも兼ねており、ルータへRPKI RTRプロトコルで検証済みのVRPsを渡す役割も兼ねています。IIJではRelying party softwareとして RoutinatorとRPKI-Validatorを採用しました。RoutinatorはNLnetLabs製open sourceで積極的な開発がされており、シンプルに動かすことができることとデプロイが容易であったことが評価されました。最新バージョンではWeb UIが導入され、ROA/ROVの状況を確認するツールとしての役割も果たしています。RPKI-Validatorについても同様な観点から採用しています。残念ながらRPKI-Validaorは開発が終了するとRIPEよりアナウンスがありました。現在だと2021/7月には開発が終了し、その後Javaベースの新たな実装に再開発されるようです。IIJとしてはどちらにしても新たなsoftwareが必要になるため、開発終了までに移設先を見つける必要が出てきました。
ROA/RTRサーバの要件として安定稼働が求められると思いますが、IIJはその要件をクリアするためにOSレベルでの冗長性を確保し、かつ異なるPOPへサーバ設置し可用性を高めています。ネットワーク内に全部で4台のサーバが稼働しており、ルータの系統により4台のうち2台とRTRセッションを確立する設計となっています。現状だと1台あたりRTRセッションを数10セッション担当することになるのですが、CPU負荷やメモリ使用率にも問題なく安定稼働を続けています。IIJでROVを実施するルータは日本国内のみならず、APAC/North America/Europeの各リージョンに存在していますが、RTRサーバとしては現在日本国内のみに設置しています。物理的な距離が遠いことによる遅延の影響はほとんど感じられず、RTRセッションを初期に確立する段階でVRPを注入するまでに多少ラグを感じる程度です。
ルータでROVを始めるにあたりOSの挙動を見ておくことは重要です。OS実装によりROVの設定手法が異なり、BGP neighborへ設定policyを個別で挿入する場合やルータ全体のBGP peerで機能を一括で有効にする場合などが存在します。前者の場合は各BGP peerへすべて設定する必要がありますが、どのBGP peerにおいてROVを実施するか明確に判断し設定することが可能です。そのため、ROVを実施したくないBGP peerを明示的に別けることもできます。後者の場合は設定時に注意が必要です。eBGP peerにおいては基本的にROVが有効になってしまうため、事前にROVを実施しないpeerについては設定で無効にしておく必要があります。特に注意が必要になるのは Private ASで eBGP接続をしている場合です。個別でPrivate AS用のROAを内部で作っていない限り、Private AS がOriginとなる経路はROVでinvalidとなってしまいます。ネットワークの設計において自AS内部でASを別けて接続している可能性は十分に考えられるのでROVを実装するルータの挙動は事前に把握することをお勧めします。IIJは両方のタイプのOSが稼働しているため各ノード毎に気を使いながら設定を行いました。
ROV設定の参考としてサンプルコンフィグをのせておきます。雰囲気を掴んでいただければ幸いです。流用される場合は自ASネットワークへの適用時に良くご確認ください。
【2021/07/07 追記】IIJの中の実装見直しによりコンフィグを一部修正しています
routing-options {
validation {
group RPKI {
session xxx.xxx.xxx.xxx {
refresh-time 600;
hold-time 1200;
port 8323;
local-address xxx.xxx.xxx.xxx;
}
session xxx.xxx.xxx.xxx; {
refresh-time 600;
hold-time 1200;
port 8323;
local-address xxx.xxx.xxx.xxx;;
}
}
}
}
policy-options {
policy-statement OriginValidation {
term Valid {
from {
family inet;
validation-database valid;
}
then {
validation-state valid;
next policy;
}
}
term Unknown {
from {
family inet;
validation-database unknown;
}
then {
validation-state unknown;
next policy;
}
}
term Invalid {
from {
family inet;
validation-database invalid;
}
then {
validation-state invalid;
reject;
}
}
then next policy;
}
}
protocols {
bgp {
group PEER {
import [ OriginValidation ];
}
}
}
!
router bgp 2497
rpki server xxx.xxx.xxx.xxx
transport tcp port 8323
purge-time 360
refresh-time 600
response-time 1300
!
rpki server xxx.xxx.xxx.xxx
transport tcp port 8323
purge-time 360
refresh-time 600
response-time 1300
!
bgp bestpath origin-as allow invalid
address-family ipv4 unicast
bgp origin-as validation enable
!
neighbor xxx.xxx.xxx.xxx
address-family ipv4 unicast
route-policy importPolicy in
!
!
route-policy importPolicy
apply OriginValidation
pass
end-policy
!
route-policy OriginValidation
if validation-state is invalid then
drop
endif
end-policy
!
ROA登録
IIJでは複数のRIR/NIRよりアドレス割り振りを受けていますが、現在はJPNIC割り振り分についてROA登録を実施している手前、今回はJPNICについて取りあげます。JPNIC以外のRIR/NIRは只今絶賛準備中となります。
IIJはROAを登録する手法として、JPNICが用意するROA登録システム(ROA Web)を利用し、ROAの作成を行いました。他のASでの導入事例を見てもRIR/NIRの用意するシステムを使うことが一般的かつ導入敷居が低いのでIIJでもそうしました。もう一つの手法として、自社ネットワーク内に独自CAを建てて、RIR/NIRと同等にROAを発行する BPKI(Business PKI) という手法もあるのですが、運用コストがかかり敷居が高いという理由で導入を行いませんでした。RIR/NIRが用意する仕組みを利用するのがお手軽ですが、どうしても他組織に依存するため独自のシステム開発(自動化など)や万が一の障害時リスクはありますので各組織のポリシーにより検討されるとよいと思います。
さて、このROAを登録するという工程ですが、登録作業自体はWeb UIをポチポチして必要な情報を入力するというシンプルなものです。しかしながら、登録内容を間違えてしまったり、実際のルーティング設計と異なる値で発行してしまうと一瞬で自社ネットワークのインターネットの到達性を失わせてしまう大変危険な作業となります。数年前であればROAベースのValidationはまだ導入していたASが少なかったため、仮にinvalidとなり経路が破棄されても即座に大きな影響にはならなかったかもしれません。しかし、現在ではTier1 ASはもちろんのところ、世界各国のASでRPKIベースのROVが始まっています。そのため、自身が現在広告しているルート情報と差異があるROAを発行した時点でなんらかの通信影響が発生することが大いに考えられます。
現時点ではROA WebのGUIよりROAを発行する手段しかないため、IIJでは2人体制でブラウザでの操作画面を録画しながら作業の記録を取るようにしています。ROA Webについては昨年10月末にリプレイスが行われており、もともと旧ROA Webで課題であったAPNICとの連携と情報の同期に少しリードタイムがあることが改善されました。新ROA WebになってからはリアルタイムにAPNICと連携されるようになり、インターネット上での反映のスピードが上がっています。また登録者が確認しやすいように、登録作業時に現在のBGP経路状況も合わせて表示してくれるため、万が一の設定ミスが起こらないような仕組みも備わっていて、助かります。JPNICによると将来的に要望が多ければAPI機能を追加することも検討するという話も聞いたので、対応ができた暁にはIIJでの別の作業手法を確立していければと思います。
なお、JANOG発表資料作成時(2021/01時点)のJPNICが保有するアドレスおけるROAの登録状況としては IPv4:44.4%, IPv6: 57.2% とのことでした。IIJもROAを作成、登録したことで多少貢献ができたと思っています。
JPNICではROAが作成できないアドレスたち
ROA Webのシステムの都合上、2021/01時点でROAが作成できないブロックを確認しています。改修内容はJPNICで認識しているようですので、我々としてはシステムの対応待ちとなります。現状把握しているものだと 133.x.x.x/16に代表される歴史的PI(Provider Independent)アドレスや203.180.0.0/16などAPNICとして特殊なブロックが該当するようです。IIJとしてはシステム対応され次第、登録を行う予定です。
ROA作成のポリシー
一言にROAを作成するとしても事前にいくつか考えておかなければならない事項があります。ROAの構成要素として Prefix /Origin AS/ Maximum Length を登録する必要があり、IIJの場合は以下のようなポリシーにより作成を行いました。
- IIJに割振済み、かつIIJでまだ経路未広告:
- Prefix: 割振アドレス、Origin AS: AS0、Maximum Length: 割振サイズ
- IIJ内で割当済み、AS2497 Originで経路広告済:
- Prefix: 割振アドレス、Origin AS: 2497、Max Length: 広告サイズ
- IIJ内で割当済み、かつ一部を顧客ASでOriginateして経路広告済:
- Prefix: 割振アドレス、Origin AS: 2497、Max Length: 広告サイズ
- Prefix: 割当アドレス、Origin AS: 顧客、Max Length: 顧客と相談
IIJでまだ利用が広告されておらず、利用開始準備中のアドレスについては、不正利用ができないように Origin AS0として登録を行います。AS0はIANAでも予約ASであり、インターネットでも利用されることがないこととRFCとしてもAS 0 で保有アドレスを証明することと書かれているため登録を行います。
Maximum Lengthの考え方はASにより見解が分かれるところだと思います。IIJで策定した方針として、IIJが現在外部へ経路広告しているサイズに合わせることを考えました。IIJの場合は極力経路を分割せずに割振サイズで経路広告しているため、最大経路長を宣言する Maximum Length を広告サイズに合わせています。原則広告経路とサイズを合わせることにより、仮にOringin ASを詐称された経路ハイジャックでより細かいPrefix長の経路が広告されたとしてもMaximum Lengthによりinvalidとなり、経路としては有効にならず、longest match で通信を吸い込まれるリスクも少なくなります。しかし、IIJでもCIDRアドレスの一部を顧客ASへ貸し出す対応を行っており、明示的にパンチングホール状態で接続している場合もあります。ROAを作成する際にはとても気を使う状況ですが、ここでも原則としてAS2497としてIIJが広告するPrefixでROAを作成し、パンチングホール部分については顧客ASのポリシーに基づいて登録を行うことにしました。順番もとても気を使うところです。先のMaximum Lengthのポリシーがあるため、IIJが広告するアドレス分のROAを先に作ってしまうと顧客ASから広告するアドレスの経路はinvalidとなってしまいます。そのため、先に顧客ASからROAを登録してもらい、validになったことを確認した後にIIJでもROAを作成する対応となります。
たまにあるROA登録済みによるトラブル
実際にIIJが経験したトラブルとしては把握していないROAによるトラブルがありました。お客様において過去にテストでROAを作っておいたが、現状の経路広告ポリシーと差異があるため、RPKI ROVの普及により想定外にinvalidとなった経路がRejectとされるという事象です。各ASが徐々にRejectをしているためにある日突然起こることとインターネット上のどこで起こるかがわからないため調査についてもなかなか難しいところです。ROA登録は明示的な作業が必要なため自動で作られることはありませんが、内容についても自動的な更新はされないため、継続して内容の見直しとメンテナンスが必要となります。もしみなさんがアドレスをお持ちの場合は、なにかしらのROAを作っているのか、いないのかの確認と作成済みのROAが存在する場合は現状の経路広告ポリシーに合致するかの見直しを行うことをオススメします。この機会にご対応ください。
RPKI ROA/ROVの監視
想定通り動いていることや万が一の異常に気付けるような監視の実装に向けて検討を進めています。
ROAについてはROAの作成漏れや経路ハイジャックによりinvalid状況となっていることをアラートとして検知したいと思っています。IIJのAS外での状態監視が必要になるため、外部のサービスを利用する方向で考えています。現在はBGPalerterやRIPE RISを使った状態監視をテスト中ですが、まだまだ誤報が多いため安定稼働に向けて作り込み中です。
ROVについてはRTRサーバのパフォーマンス監視と各ルータのRTRセッションについて状態を監視しています。基本的にRTRサーバやセッションは冗長構成となっているため、片系に障害が発生してもROVへ影響は軽微です。また各ルータで仮にRTRセッションがすべて切れてしまったとしても、VRPsのキャッシュがlifetimeで残り続ける限りはROV判定がされ、かつVRPsが消えてしまっても invalid経路をRejectすることはできなくなりますが、経路を不用意に破棄する等の振る舞いはありませんので通信影響は最低限と考えています。また万が一の経路障害を後々に辿れるように各ルータでのReject経路を定期的にdumpする仕組みを作成し、情報を取得しています。
これからの取り組み
RPKIの初期導入は完了しましたが、これからもRPKIの運用を継続していくことはもちろん、まだ対応できていないTransit顧客を収容するノードへの導入が次のステップとしてあります。引き続き検討は進めていきますので導入するフェーズになりましたらどうぞご協力をお願いいたします。
IIJはAS2497として引き続きインターネットの安定稼働に向けて貢献していきます。
