8/27/2016

BGPsecの概要

インターネットを支えるルーティングプロトコルBGPはまったく安全ではない。BGPのセキュリティ機能は登場した当初から検討されているが、ようやく標準化がまとまってきた。既に、リソースPKI (RPKI)を使ったIPアドレスの割当てやそのオリジンAS番号を検証する機能が実用段階に入っている。ただ、BGPのセキュリティはRPKIだけでは実現できない。現在、標準化が進められているBGPsecによるASパスの検証機能と伴う必要がある。BGPsecの普及はRPKIと比較するとかなり難しい仕事になるだろう。BGPsecの実装としてはBIRDQuaggaがあるので、時間がある時にでも試してみたい。

BGPsecの概要に関するIETF Draftが更新されていたので、超訳してみた。

BGPsecの概要

はじめに

BGPsec (Border Gateway Protocol Security)はBGPの拡張機能で、BGPルーティング[RFC4271]の改善されたセキュリティ機能を提供する。この文書はBGPsecの概要と想定される利用法からなる。

BGPsecのより詳しい考察については、次の一連の文書で規定されている。

[RFC7132]:
BGPsecの運用が必要となったセキュリティの背景を説明する脅威モデル
[RFC7353]:
BGPsecが満たそうとしているBGPパスセキュリティの一連の要件
[I-D.sidr-bgpsec-protocol]:
BGPsecはBGPの拡張であることを明記した標準化過程文書
[I-D.sidr-as-migration]:
BGPsecの下でAS番号を移行する方法を説明する標準化過程文書
[I-D.sidr-bgpsec-ops]:
運用上の考察を説明する情報文書
[I-D.sidr-bgpsec-pki-profiles]:
BGPsecで使われる鍵とAS番号、関連する証明書破棄リスト(CRL)、証明書要求を結びつけるX.509証明書プロファイルを明記する標準化過程文書
[I-D.sidr-bgpsec-algs]:
BGPsecで使われる署名とダイジェストアルゴリズムのスイートを明記する標準化過程文書

この文書セットに加え、一部の読者は[I-D.sriram-bgpsec-design-choices]に興味を持つかも知れない。これはdraft-ietf-sidr-bgpsec-protocolの-00版の公開に先立ちデザインチームによって作成された設計上の選択を説明する情報文書である。-00の公開した後の設計上の選択の考察は、SIDRワーキンググループのメーリングリストのアーカイブから入手できる。

背景

BGPsecの開発の動機は、BGPにはBGP経路広告([RFC4271]で例を参照)の正当性や信ぴょう性の検証を、ASが行うメカニズムを含んでいない点にある。

[RFC6480]で説明されるリソース公開鍵基盤(RPKI)は、BGPのルーティングデータの検証に取り組むための第一歩を提供する。RPKIのリソース証明書はAS番号とIPアドレスの所持者に発行され、デジタル署名を検証するために使われるリソースと暗号鍵間の結び付きを提供する。加え、RPKIアーキテクチャはデジタル的に署名されたオブジェクト、Route Origination Authorization (ROA)を明記し、これらのリソースにBGPの経路の起点となるASを認可するのをIPアドレスの所持者に許可する。有効なROAから取り出されたデータは、受信経路がその経路の起点と認可されているかを断定する起点ASかどうかを判断するために、BGPスピーカによって使われる([RFC6483]と[RFC7115]参照)。

RPKIデータを使って、検証された起点ASを持つ経路を優先するというローカルポリシーを策定することで、ASはネットワークオペレータによる設定エラーや明白なミスオリジネーション攻撃から自身を保護できる。しかし、RPKIデータだけの利用では、洗練された攻撃者に対しては保護されない、あるいはされてもわずかである。そのような攻撃者は、例えば別の不正なASパスにオーソライズされた起点ASを付加することによって経路ハイジャック攻撃を行う。(BGPsecの脅威モデルの詳細な考察は[RFC7132]を見てほしい。)

BGPsecは、BGPsecルータ証明書として参照したり、AS番号を公開署名検証鍵と結び付けたり、証明書に追加タイプを加えることでRPKIを拡張している。付随する秘密鍵はこのAS内の1台以上のBGPスピーカによって保持される。その証明書の公開鍵に付随する秘密鍵は、BGPスピーカがそのASの代表として署名できるようにするため、BGPsecの中で使われる。証明書はこのようにして任意のASに属するBGPスピーカによって生成されるBGPsecの署名を検証することを依拠当事者(relying party)に許可している。BGPsecの目的は、BGPアップデートメッセージの中のASパスデータを保護するために署名を利用することである。そして、各BGPスピーカは受信したアップデートメッセージの中のこのデータの正当性を評価できる。

3. BGPsecの運用

BGPsecの核はBGPsec_Pathと呼ばれる新しいオプション(非通過型)属性である。この属性はASパスデータと一連のデジタル署名を含んでいる。(この新しい属性の利用は、[I-D.sidr-bgpsec-protocol]で公式に規定される。) 新しい署名はアップデートメッセージがASを離れるたびに加えられる。BGPsecアップデートメッセージ中のASパスデータあるいはネットワークレイヤ到達性情報(NLRI)の改ざんがメッセージの受け手によって検知できるよう、署名が構成される。

3.1. BGPsecのネゴシエーション

BGPsecの利用はBGPケーパビリティ広告[RFC5492]を使ってネゴシエーションされる。BGPsecをサポートする(そして利用を欲する)BGPスピーカは、ピアとのBGPセッションのオープン時に交わされるOPENメッセージの中で新しく定義されたケーパビリティを含める[I-D.sidr-bgpsec-protocol]。

BGPsecの利用は各アドレスファミリーで別々にネゴシエーションされる。これはBGPスピーカが例えばIPv6でBGPsecの利用を選択し、IPv4の経路では使わない(あるいはその逆)ということをになる。更に、BGPsecの利用は送信と受信方向も別々にネゴシエーションされる。これはBGPスピーカが例えば、BGPsecアップデートメッセージ送信をサポートを示すが、メッセージは従来の(非BGPsec)アップデートメッセージを受信することを求めることになる。(なぜ、そのような機能が有益なのかは、4.2節を参照。)

もし、BGPsecの利用がBGPセッションの中でネゴシエーションされたら(ある方向で、あるアドレスファミリーで)、双方のBGPアップデートメッセージ(BGPsec_Path_Signature属性を含んでいる)や従来のBGPアップデートメッセージ(この属性を含まない)はセッションの中で送られる。

もし、BGPsec可能なBGPスピーカが、ピア先はBGPsecアップデートメッセージを受信できないことに気付いたら、BGPスピーカはこのピア先に送信するアップデートメッセージからBGPsec_Path属性を削除しなければならない。

3.2. 署名と検証の更新

BGPスピーカがBGPsecアップデートメッセージを起点として送る時、一つの署名を含んだBGPsec_Path属性を作成する。署名はネットワークレイヤ到達性情報(NLRI)、起点ASのAS番号、ピアASのAS番号を保護し、その上でアップデートメッセージが送信される。BGPsecアップデートメッセージの中のNLRIは一つのプレフィックスのみ含むよう制限されていることに注意する。

BGPスピーカがBGPsecアップデートメッセージを受け取り、アップデートの中に含まれる経路広告を外部ピア先に伝搬したい場合、BGPsec_Path属性に新しい署名を加える。この署名は前の署名によって保護されたすべてに加えて、アップデートメッセージが送信される新しいピア先のAS番号を保護する。

各BGPスピーカはサブジェクト鍵識別子(SKI)と呼ばれるリファレンスを含んでいる。SKIはBGPsec_Path属性を署名したBGPスピーカのBGPsecルータ証明書を識別する。SKIは署名を検証するのに必要となる公開鍵(と関連するルータの証明書データ)を選択するために受信側が利用する。

例えば、AS 1が起点となる192.0.2/24の広告を、AS 2に経路を送信、AS 3に送信、AS 4に送信する次のようなケースを考えてみる。AS 4はこの経路のBGPsecアップデートメッセージを受信すると、次のデータを含んでいる:

 ___          ___       ___       ___
/   \        /   \     /   \     /   \ 
|AS1|--------|AS2|-----|AS3|-----|AS4|
\___/        \___/     \___/     \___/
192.0.2/24
  • NRLI: 192.0.2/24
  • ASパスデータ: 3 2 1
  • BGPsec_Pathは3つの署名を含んでいる:
    • 192.0.2/24, AS 1とAS 2を保護するAS 1の署名
    • AS 1の署名が保護する全てとAS 3を保護するAS 2の署名
    • AS 2の署名が保護する全てとAS 4を保護するAS 3の署名

BGPsecアップデートメッセージがBGPsecスピーカによって受信されると、そのBGPsecスピーカは次のようにメッセージを検証できる。まず、BGPスピーカは各署名でSKIが一致する有効なRPKI経路証明書があり、適切なAS番号を含んでいるかどうかを判定する。(これは大抵は有効なRPKIオブジェクトから抽出されるデータのキャッシュの中でSKIを検索することによって実行される。キャッシュは非同期プロセス経由で処理される証明書検証を可能にし、それは別デバイス上で実行されるかも知れない。)

そして、BGPsecスピーカはBGPsec経路証明書の公開鍵を使って、署名を検証する。もし、各署名がこのやり方で検証できれば、BGPsecスピーカは受信したアップデートメッセージがアップデートメッセージの中で指定されたASパス経由で伝搬されたことが保証される。

上記例では、BGPsecアップデートメッセージを受信する上で、AS 4のBGPスピーカは次のように動作する。まず、最初の署名のSKIを探し、AS 1の有効なBGPsec経路証明書と一致するかどうかを確認する。次に、この有効の証明書の中にある鍵を使って最初の署名を検証する。最終的に、2番目、3番目の署名に対して、この処理を繰り返し、AS 2とAS 3のBGPsec経路証明書が有効であるかをそれぞれ1つずつ確認してチェックする。更に、AS 4のBGPスピーカはRFC 6483[RFC6483]の通り、オリジン検証を実行する。ただし、当該のオリジン検証はBGPsecとは独立したものである。

BGPsecのデプロイモデルは、BGPsecでパスが保護される全てのASがBGPsecスピーカであることを求めている。BGPsecをサポートしないASを通過して広告するアップデートのBGPsec保護を認めていない。特に、ダウンストリームのネイバーから受信した保護されていないアップデートにBGPsec ASがBGPsec_Path属性を付加するような"部分的パス署名”と呼ばれるものを認めない。

部分的パス署名は部分的に保護された経路を優先するという、一部のパスついてより良い経路決定に使われる補助情報としてみなされるかも知れない。しかし、部分的経路署名は全体のASパスが厳密に保護されていなことを示している。厳密なASパスの保護はBGPsec[RFC7353]の重要要件である。部分的パス署名は次の脆弱性への攻撃を導いてしまう: もし、BGPsecスピーカが保護されていないアップデートにBGPsec_Path属性を付加できるなら、そしてもしBGPsecがアップデートが保護されないアップデートを有効になるよう保護したとすると、保護されないアップデートを操作でき、BGPsecスピーカはBGPsec_Path属性を付加できることになり、その結果操作されたアップデートが優先されるという可能性が増大する。部分的パス署名は権限昇格攻撃ベクタになり得る。そして、いつでもどんなBGPsec ASによって利用される。

その脆弱性の発生を避ける必要性は厳しいデプロイモデルを推し進めた。

4. デザインとデプロイの考察

この節では、一般的にBGPsecの議論の中で起こる幾つかの付加的なトピックの概要を提供する。

4.1. トポロジー情報の開示

BGPsecのデザインの重要要件はBGPピアリングトポロジーについての新しい情報を開示しないことだった。多くのISPはピアリングトポロジーデータがプロプライアタリであると感じており、さらなる開示はBGPsecの採用の妨げになりそうだった。

特に、BGPsecのアップデートメッセージから推測されるトポロジー情報は、同等の(非BGPsec)BGPアップデートメッセージから推測できるものとまさに同じものである。

4.2. BGPsecルータの前提

セキュリティの目的を達成するため、BGPsecはルータに付加的な機能を負わせている。特に、BGPsecはBGPアップデートメッセージにデジタル署名を付加することを要求し、メッセージサイズは著しく増大する。従って、BGPsecアップデートメッセージを受信したいASは、そのルータにこれらの大きなアップデートメッセージで運ばれるデータを(ADJ RIBの中に)保持するためのメモリを追加する必要がある。加え、BGPsecのデザインは、BGPsecアップデートメッセージを受け取ることを選択するASは、エッジルータで暗号署名の検証を実行することを前提とする。この検証は、これらのエッジルータが付加的機能を要求するかもしれない。

BGPsecの初期バージョンには、BGPsecアップデートのサイズを小さくする、あるいはエッジルータで要求される処理の最適化は検討されていない。そのような最適化は将来検討されるかもしれない。

BGPsecのデザインはBGPsecアップデートメッセージを受け取らなくても、BGPsecアップデートメッセージを送ることをASに許可していることにも注意する(起点となる経路を保護するため)。BGPsecアップデートメッセージを送信するが、受信しないASは、BGPsecのデプロイのためエッジルータにそれほど能力を要求しないだろう。特に、BGPsecアップデートメッセージを送信するだけのルータは大きなアップデートを保持するための追加メモリを必要としないし、最小限の暗号機能を要求するだけである(出方向のアップデート毎に一つの署名を生成するため、個々の入方向のアップデートメッセージにある複数の署名を検証するよりは、コンピュータ能力は低く済む。) トランジットを提供しないエッジASに関連する更なる考察は[I-D.sidr-bgpsec-ops]を参照。

4.3. BGPsecと対外的な可視データの一貫性

最終的なデザインでは、BGPsecはASパスの中に矛盾あるいは誤りのある情報を含んだ経路広告を伝搬するのを(調べることなく)防止する。特に、これはBGPsecを使わなければ、BGPスピーカが矛盾あるいは誤ったASパス属性を構成するようなシナリオを破るであろうことを意味する。

例えば、BGPsecが使われない場合、一つの自律システムにとって1つ目のピアリングセッションではAS 111として自身を識別し、2つ目のピアリングセッションではAS 222として自身を識別することが可能である。そのような場合、1つ目のピアリングセッション(AS 111として)からの経路広告を受け取り、AS 222をASパスに追加し(しかし、AS 111ではない)、2つ目のピアリングセッションの中に伝搬する。

前記の挙動が極めて潔白で、AS 111とAS 222の正規な保持者の同意が取られているとする。しかし、悪意のあるAS 222によって実行される次の中間者攻撃とは見分けがつかない。まず、悪意のあるAS 222は1つ目のピアリングセッションでAS 111に成りすます(基本的AS 111向きの毛色広告を盗む)。悪意のあるAS 222はASパスの中に自分自身を挿入し、ピア先にアップデートを伝搬する。

従って、BGPsecが使われれば、自律システムは全ての外部のピアリングセッションで矛盾のないAS番号を主張する必要がある。あるいは1つ目のピアリングセッションから受け取り、2つ目のピアリングセッションの中に伝搬する経路広告のASパスにAS 111とAS 222を加える必要がある(適切な署名と共に)。BGPsecを使ってAS番号の統合を合理的に行う方法の詳細な考察については[I-D.sidr-as-migration]を参照。

5. セキュリティの考察

この文書はBGPsecの概要を提供する。BGPへのBGPsec拡張を定義していない。BGPsec拡張は[I-D.sdir-bgpsec-protocol]で定義されている。BGPsecの脅威モデルは[RFC7132]で説明されている。