TRY AND ERROR

自宅NOCオペレータの運用備忘録。

AS59105でROVをはじめた話

　2020年12月末から、AS59105でRPKIによる不正経路の破棄（ROV）を開始しました。公式発表している情報は以下をご参照いただくとして、ここでは裏話的なことを少し雑に書いてみたいと思います。RPKIの仕組みについて基本的なことは理解していることが前提の記事。

f:id:kt-yamaguchi:20210131011113p:plain

1. ルータ

　AS59105ではJuniperとCiscoのルータを使っています。対外接続をしているルータ（エッジルータと呼称しています）では複雑なポリシー制御をすることがあるので、設定がしやすい（とメンバーが感じている）Junosを、エッジルータをNOC間をつないでいるルータ（コアルータ）は、複雑な制御をしないのでCisco（IOS-XE、IOS）を使っています。中古品をオークションで買ってきたり、どこかの会社で廃棄になったものを譲ってもらったりしているのでバージョンや機種もバラバラです。当初はROVのことなんか考えずにこの構成になったのですが、JunosはROVへの対応が比較的早く（2015年位のJunosから）やろうと思ったときには既に対応していたのは助かりました。（コアルータは対外接続は無いためROVはせず、エッジルータだけでするため。）

　検証段階ではJunos以外もROVの実装を試しましたが、OSにより設定できるパラメータや設定方法にも差がありますので、機種が混在している環境では十分に検証しておいた方が良いかもしれません。また、例えば以下のようにROVの結果に関しても疑問が疑問があるケースが散見されますので要注意です。

・集約経路（AS-SET）に関する動作がおかしい？

　経路の検証結果に影響を及ぼす問題として、AS-SET（JUNOSのCLIだと｛AS番号｝で表現される）を含む経路について、INVALIDとなるケース、VALIDとなるケース（ソフトウエアの不具合？各社のルータの仕様？）があります。

2001:4de0:1001::/48*[BGP/170] 1w0d 05:19:38, MED 100, localpref 100
                      AS path: 9370 2497 174 12989 {34343} I, validation-state: invalid

213.91.157.0/24    *[BGP/170] 1w0d 05:19:42, MED 100, localpref 100
                      AS path: 9370 2497 3223 {34224 205132} 199512 I, validation-state: invalid

RFC6483では、「If the AS_PATH contains a path segment of type AS_SET, indicating that the route is an aggregate, then the origin AS cannot be determined.」という一文があり、決定できない＝Unknown とするのがRFCに準拠しているように見受けられますが、明確に「Unknownとしなさい」と書いている訳では無いので、ルータを作っている各社の判断によって実装が分かれる部分なのかもしれません。

　現状、Unknownとして受け入れる実装をしているルータがあるので、AS59105のネットワークには経路は入ってきております。

・キャッシュサーバによって異なるROV結果を受け取った場合の動作

　キャッシュサーバがCAから情報を集めてキャッシュ情報を更新するタイミングだったり、不具合があった場合など、ルータがRPKI-RTRで接続している複数台のキャッシュサーバから取得した情報が異なる場合（例えば、ある経路についてキャッシュサーバ1は正常な経路、キャッシュサーバ2は不正経路という情報を持っている場合）どちらをRIBに反映するかという動作にも差があるようです。以下のようにキャッシュサーバによって保持しているレコード数が異なるタイミングはよくあることです。

Session                                  State   Flaps     Uptime #IPv4/IPv6 records
10.100.xxx.xxx                         Up          0 6w2d 11:21:34 178211/30109
10.100.xxx.xxx                         Up          0 6w2d 11:21:34 185454/30850

2. キャッシュサーバ

　東京に2つと大阪に1つのVMで運用しており、ソフトウエアはCloudflareのGoRTR+OctoRPKIを使っています。各ルータは2台のキャッシュサーバに接続するものとして東京地区のルータは東京の2台のキャッシュサーバを、大阪地区のルータは大阪と東京で1つのキャッシュサーバを参照しています。

　ROVをしているルータで全てのキャッシュサーバとの接続が全て切断されると、経路（RIB）の書き換えが走り、経路再計算により網全体にかなりの負荷を掛けることが分かったので、キャッシュサーバの冗長性は十分に考慮しました。本当は3冗長とかにした方が良いかもだけどルータのメモリを消費するとか別の問題も出てくるのでこの辺で妥協。

・OctoPRKIだけではなく冗長した方が良いのでは？

　ソフトウエアの不具合があったらとか懸念することは色々ありますが、そこまでしなくて良いと判断しています。以前はRIPEのRPKI Validatorも使っていたのですが2021年夏で開発終了になることや、動作が重い（安定動作には3GB-4GB程度のメモリが必要みたい）メモリリークする不具合もあったので止めました。分かりやすいWebUIがあるのは良かったですが…。最近はNLNOGのRoutinatorがなかなか良いという話を聞いたので今度試してみようかなというところ。

・パブリックキャッシュ使わないの？

　サーバの運用をしなくて済むという意味では便利なのですが使っていません。RPKI RTRがインターネット経由となってしまうので、インターネット上の経路変動や障害の影響を受けてしまうことが一番の理由（万一接続が切れると前述の通りRIBの書き換えが走りルータの負荷が上がる）。あとはキャッシュサーバのパラメータなどは非公開のものが多い、提供されるキャッシュ情報について信頼できるか分からない (一部の情報が書き換わってたり、古かったりするかもしれない)、RPKI RTRのプロトコル自体が暗号化されていないため、どこかで改竄されるリスクもゼロでは無いことでしょうか。多少運用の手間は掛かるかもしれませんが、重要な部分なので自分で用意するのが安心です。

3. どこでROVするの？状態の監視は？

　対外接続をしているルータの全て、全てのeBGP Neighborで実施しています。Route Reflector でROVしてお茶を濁すことも出来ましたが、iBGPでのROVをする実装はあるものの、非対応の機器もあり今後の機器選択の幅を狭める可能性もあります。そもそも、我々のネットワーク構成上、RRでのROVだと不正経路からASを完全に守れないため却下となりました。

　JUNOSの場合、全てのeBGP Neighborで以下のようなROV設定を入れています。Validationされた経路は、BGP Communityを付与（RFC8097）してiBGPで網内に流しています。

policy-options {
    policy-statement RPKI {
        term valid {
            from {
                family inet;
                protocol bgp;
                validation-database valid;
            }
            then {
                validation-state valid;
                community add RPKI-VALID;
            }
        }
        term not-found {
            from {
                family inet;
                protocol bgp;
                validation-database unknown;
            }
            then {
                validation-state unknown;
                community add RPKI-UNKNOWN;
            }
        }
        term invalid {
            from {
                family inet;
                protocol bgp;
                validation-database invalid;
            }
            then reject;
        }
    }
    policy-statement RPKI-6 {
        term valid {
            from {
                family inet6;
                protocol bgp;
                validation-database valid;
            }
            then {
                validation-state valid;
                community add RPKI-VALID;
            }
        }
        term not-found {
            from {
                family inet6;
                protocol bgp;
                validation-database unknown;
            }
            then {
                validation-state unknown;
                community add RPKI-UNKNOWN;
            }
        }
        term invalid {
            from {
                family inet6;
                protocol bgp;
                validation-database invalid;
            }
            then reject;
        }
    }
}

・モニタリング機能が弱い

　JUNOSもIOS-XEもROVに関する実装ではモニタリング関連の機能が弱く「不正経路が増減したらSYSLOGを上げる」「SNMPでROAキャッシュの状態（不正経路数とか）を取得する」なんてことが現状できません。

　ユーザから通信できないと問い合わせがあった際とか、単純に研究対象としてもデータの収集は細かくやりたいのですが。Linuxルータなどに経路を食わせて記録を取るような仕組みを作るとか方法はあるのですが、結局フルルートの監視みたいなことになってしまって大変なので、そこまで時間を掛けられず、やっていないのが実情。

4. 例外規定はナシでシンプルに

　不正経路を分析していると、「これはどう見ても悪意は無くて設定ミスだろう」という経路が多数あります。（というか、悪意ある経路は少なくて、設定ミスが殆どじゃないかな）不正経路について個別に許可する運用は一切やらない方針です。例えユーザから強く求められても。

　RFC8416で規定されたSLURM（不正経路であっても、自分のキャッシュサーバで強引にValid経路であるよってことにして、その経路を許可する）があるので技術的には十分可能なのですが、やりません。個別対応しているとキリが無くて運用が破綻するのと、不正経路か設定ミスかは推測に過ぎず、巧妙な経路ハイジャックを許してしまう可能性があるから。世界中の色々なASがROVをはじめても、みんなが個別許可をやってしまうとRPKIの効果や価値は下がってしまうでしょう。

　もし困ったら、まずはそのROAを登録しているアドレスホルダーに連絡を取ってください。個人から連絡しても反応無ければ、NOGのMLに晒してみるとか、連絡を頂ければ上流トランジットを経由して対応を求めたりもやります。

5. 不正経路の実際

　不正経路となっている経路が12月末現在で2300経路（ROVを始める前のAS59105への流入数）あり、その経路長などについてはトップにリンクのあるHOMENOC公式ブログを参照して頂ければと思いますが、その中身についてここで少し書いてみます。

・MaxLenより細かい経路

　これが最も多く全体の51%程。例えば/22-23というROAがあって、/24の経路が広報されているようなケースですね。トラフィック制御で細かい経路を出したとか、内部経路を漏らしているとかかな。

・OriginASが違う

　次に多いのはこちらで29%程。ROAに登録しているOriginASと実際に広報しているASが違うケース。パンチングホールとか、一部のDDoS対策サービスの利用とかが考えられるでしょう。

・上記2つ両方に該当

　3番目はこちらで20%程。ROAより細かい経路が広報されていてOriginASも違うケースです。

・ROAより経路長が短い

　最後はこちらで0.2%程。例えばROAは/23-24で登録されているんだけど、/22の経路が広報されているようなケース。このような結果になる運用が想像できないのですが、ごくわずかながら存在します。

　経路の動向を追いかけてましたが（ずっと経路の記録を取り続ける仕組みは持ってないので一定期間毎の観測です）、これは明らかに経路ハイジャックと分かるというものはありませんでした。まぁ経路ハイジャックの場合は、問題になって短期間で対応されて、続かないことが多しい、そもそも巧妙な手口で気付いていないだけかもしれませんが。

　設定ミスが疑われるケースが殆どなので、ROAを作成するなら、経路の広報を変更する前には必ずROAの登録を確認、という運用を徹底したいものです。日本のトランジット提供事業者は、IRR登録確認はしてくれて書いていないと教えてくれますが、ROAがおかしいことも知らせてくれると良いかもですね。

　さて、ではこれらの経路を破棄してしまった場合、影響がある（＝到達性が無くなってしまう）かどうかの話。これは何をもって影響があるのかというのが難しいですが、我々で確認できるのはルーティングテーブルだけなので、代替の経路があれば影響は無い（＝到達性がある）と考えます。

　この基準で経路を調べると影響のある経路は800経路～1000経路まで減ります。

6. ROVによる通信影響の考え方

　AS59105は商用サービスではなく品質や接続性は保証しないよってルールでやっています。ROVしたことによって到達性が無くなってユーザが困ることがあっても文句は言わせないというのが建前。でも実際自宅のネット回線として使ってたり、サーバを運営している人も多いので、止むを得ない障害ではなく、意図した障害になってしまうのは避けたいねというのが本音。

　そんな訳でやろうと思ったらもっと早くできたのですが、前項の「不正経路の実際」で書いた通り、色々と分析して、影響があってもかなり軽微なレベルだねという自信が持てるようになってからのスタートになりました。

　内部ではROVして不正判定された経路を破棄するのではなく、NextHopを書き換えてその経路宛の通信をサーバに飛ばして、パケットの中身を解析して分析（2500程ある不正経路の中でどこの通信が多いのかとか、どんな通信内容なのかとか）すると面白いのでは？という話がありましたが、電気通信事業者として届け出ているため、通信の秘密の問題とかが絡んでくるので面倒なので取りやめたなんてことも。

7. ユーザ（トランジットカスタマーに対して）

　現時点ではROAの作成を推奨としていますが、ROVは実施していません。近日中にROVを実施するように変更する予定です。ROAを作成していなくても、INVALIDとなっていなければ経路は許可されますので問題にはならないでしょう。

　ユーザ（トランジットカスタマー）がROAを作成することのメリットを何か作りたいと思ってますが、難しいですね…。現在はユーザが広報する経路についてはexact matchでフィルタ解放していますが、ROAの範囲では自動的にOrlongerで許可するようにできると良いかなと思ったりしています。（上流ASとの調整が必要ですね）