BGPによるドメイン間経路制御の現状と将来：障害事例と対策

2017.11.09インターネット技術第163委員会研究会 (ITRC meet42)

NTTコミュニケーションズ ⻄塚要

⾃⼰紹介：

l ⻄塚要(にしづか かなめ)

l 2006年 NTTコミュニケーションズ⼊社l OCNアクセス系ネットワークの設計に従事した後、⼤規模

ISPの運⽤サービスを担当。現在は研究開発組織にて、トラフィック分析などISPの課題に関する研究開発に従事。

l メインフィールドl トラフィック分析l DDoS対策l IPv4枯渇対策関連技術

l 社外活動l IETF標準化 DOTS WGl JPNIC「IPv6教育専⾨家チーム」

この発表では：

l インターネットを流れるトラフィックの全体的な傾向がわかる(2016-2017)

l ISPの視点で、BGPによってトラフィックがどのような⽬的で制御されているかがわかる

l CDNによる、BGPを無視した配信のISP視点でのインパクトがわかる

l 8/25に発⽣したRoute Leak事象の背景がわかる

トラフィック傾向

・複数ISP のフロー情報により算出したトラフィック⻑期傾向を分析・送信元 IPアドレスをAS番号に変換→ダウンロードトラフィックがどのオリジンASから流れてくるかを集計対象期間：2016年9⽉〜2017年8⽉

ダウンロードトラフィックの寡占化

l 上位 100 ASで全トラフィックの 約96%を占めるl 100AS程度みれば、トラフィックのおおよその⾒積も

りには⼗分

TopAS 全体比率

25 81.16%

100 96.37%

500 99.45%

トラ

フィ

ック

量(C

DF)

AS(対数)

l シェア = 対象ASからのトラフィック / 全体トラフィックl 成⻑幅 = シェア上昇幅(1年での成⻑の傾き)

増加傾向のコンテンツ

知⾒(2016年~2017年)

l 上位コンテンツによる寡占化が進むl  Google トラフィックのさらなる伸⻑

l シェア・成⻑幅ともに最⼤l  GCP, AWS, Azureなどのクラウドサービスのシェアの伸

⻑l  SNS系も順調にシェア増

l コンテンツのリッチ化l 動画配信サイトも堅調にシェアを伸⻑

l ゲーム配信系が新興l 新興CDN事業者が⾒え始めてきたl 国内ISPからのトラフィックのシェアが減少

トランジット：引きの強さと⼒学

引きの強さ

l 引きの強さ: あるISPが複数事業者でマルチホームしているときに、下りトラフィックがどちらのトランジットから流れてくるかという強さのこと

TransitA

TransitB

ISPコンテンツプロバイダ

ユーザ (Eyeballs)

コミット

l トラフィックを何Gbpsまで流してよいのか、というトランジット事業者との契約上の合意

l 10Gの回線をひいたとて、従量制の料⾦体系(メガ単価: $/Mbps/monthの価格)が基本

l しかし、企業の会計上は従量制の料⾦体系は処理しにくいので、何Gbpsまでなら固定でいくら、という契約を⾏う

l 例えば、3Gbpsまで100万円/⽉というのを5Gbpsまで100万円/⽉にすると、収⼊は変わらないが実質の値下げになる

l 顧客ISPは、コミットが増えた分、その回線に流したいが、はたしてどのように流すのか？というのがキーポイント

AS-PATH による制御(BGP)

l 楽観的なトラフィック制御では、AS-PATHの⻑さで制御されるので、流したくないトランジットピアにAS Prependをつけることで流したい回線に下りトラフィックが流れる

l 実際はAS-PATH⻑では制御されていないので、ほとんどよらない(後述)

TransitA

TransitB

ISPコンテンツプロバイダ

ユーザ (Eyeballs)

ASプリペンドで AS-PATHを長くすることで ネットワーク的に遠く見せる

ロンゲストマッチ による制御

l longer 経路を流せば、ほぼ必ず寄ることは期待できるl ただし、prefixの分割は禁断の⼿法l 運⽤の複雑化、レイテンシの増加、トラブルの元、フ

ルルートの増加

TransitA

TransitB

ISPコンテンツプロバイダ

ユーザ (Eyeballs)

細切れ経路をAにだけ流せば、 ロンゲストマッチにより、 Aにトラフィックが寄る

コンテンツへのホップ数

l 国内主要トランジット事業者(6社)について、主要ASに何ホップで到達できるかをBGP経路から算出

l トラフィックの多いASほどホップ数は近い(世の中のピアリング戦略が有効に働いている)

AS(トラフィック順)

凝縮するインターネット

l ホップ数とトラフィックシェア

l 国内でトランジットを購⼊すると、6〜8割のトラフィックは、2ホップで到達

ホップ数

トラフィック シェア

Transit A 2.22

Transit B 2.46

Transit C 2.23

Transit D 2.20

Transit E 2.23

Transit F 2.20

トラフィックシェアで 重みづけした 平均ホップ数

ISPのトラフィックエンジニアリングは、効かない

l 主要コンテンツはほとんど2ホップ先

l コンテンツ側に、特定のトランジットに流すインセンティブがあると、ISP側のトラフィックエンジニアリングは効かないl コンテンツ事業者にとっての⾦銭的インセンティブl アプリケーションアウェアルーティング(cf. Google Espresso)

l 上記のシチュエーションでは、ASプリペンドによる操作は効かないl  Transit B にとって、ISPは顧客なので、AS-PATH⻑よりもLocal

Preference値 (通常 customer > peer) が優先される

TransitA

TransitB

ISPコンテンツプロバイダユーザ

(Eyeballs)

こっちから 流してほしいが…

Google のトラフィックエンジニアリング(TE)およびEspresso

•  トラフィックエンジニアリングの入力–  1)BGP経路–  2)ユーザの利用帯域と品質–  3)ピアのリンク使用率–  と、コストなどのハイレベルなポリシ(論文では強調していないが)

•  Googleにとっての効用：–  グローバルトラフィック最適化:ピアのリンク使用率の向上–  ApplicaDon-awareTE:End-to-EndのQoEの向上–  コストダウン

Espressoにおける⾮ベストパス(Overflow)

overflowしたトラフィックの割合

ISP

・50%以上のISPで、10%以上のトラフィックが、他に回ったほうがいいとなった ・ごく少数のISPでは、ほとんどのトラフィックがOverflowした

ISP視点では、迷惑な話

8/25 経路漏れ(Route Leak)事象

•  RouteLeakfromGoogle–  Googleからベライゾン経由の経路漏れ–  Googleがピアから受け取った経路を誤って広報してしまった–  ベライゾンはそれを受け取ってしまった–  経路は、ISPがインターネットに通常広報している経路よりも

細切れだった

•  RecommendedArDcles–  8月25日に発生した大規模通信障害をまとめてみた–  OCNはとばっちり、米グーグルによる大規模ネット障害の真相–  パブリックデータから経路リークを探る–  08/25の通信障害概説(pdf)–  LargeBGPLeakbyGoogleDisruptsInternetinJapan–  BGPleakcausingInternetoutagesinJapanandbeyond

事象の概要：何が起きたのか？

•  RouteLeakfromLevel3(11/6)– 北米のインターネットが約90分間不安定に– 内部のComcast細切れ経路(18AS/3000prefix)の漏洩

先⽇も…

•  ほとんどがVerizon->Google経由に–  影響1: 海外経由による遅延の増加–  影響2:トラフィックの輻輳–  影響3:Googleが経路を約10分後に消去した時のルーティングループ

Google15169

Verizon701

被害ISP

ユーザ(Eyeballs)

Internet

通常経路

経路リーク時

被害ISPの細切れ経路

一部影響のなかった トラフィックもあり

被害ISPの細切れ経路海外経由による遅延の

増加

想定外のトラフィックによる輻輳

細切れ経路に含まれなかったアドレス帯もある

Google以外のダウンロードトラフィック (全体の70%程度)

Google経路消去時のルーティングループ

Peer Leak: ユーザへの影響について

リーク影響型 経路影響・自社型 経路影響・透過型

経路のリークによって、ユーザがつながりにくい事象1.  海外経由による遅延の

増加2.  トラフィックの輻輳3.  経路消去時のルーティン

グループ(※)

トランジットから流入した経路増大により、自社設備に影響がでて、自社や顧客のサービスに影響

トランジットから流入した経路増大により、自社設備には影響がなくても、顧客のNW機器(あるいはDCなど)が経路増大で影響

自社設備

自社設備

顧客 顧客

約10万経路 約10万経路

リークされた 経路のユーザ

※経路消去(withdraw)時のループに関しては、IRS26の資料参照

リークの影響に加えて経路数の影響があった

1.  GoogleがISPから受け取った経路を内部的に分割していた(？)2.  ISPがGoogleに細切れ経路を何らかの理由で渡していた(？)3.  第3者が詐称して注入した(❌)

•  Googleが自身のミスを後日認めたためこの可能性はない(BGP経路は、誰が注入したのかはわからないので、事象発生時点では、Googleのミスかどうかは同定できなかった)

Google15169

Verizon701

被害ISP

Internet

被害ISPの細切れ経路

悪意のある第3者

被害ISPの細切れ経路

可能性①

可能性③被害ISPの細切れ経路

観測できているもの

経路はどこから来たのか？

細切れ経路

可能性②

隣接ASとのトラフィックエンジニアリング(BGP)

ISP 隣接ASユーザ (Eyeballs)

l MEDによる重み付け

l MEDによって、どのピアからトラフィックを出してほしいか、要望することができる

l MEDは受信AS側で上書きすることができるl インターネットでは、⼊ってくるトラフィックは、根本的

には制御できないl 双⽅に合意がなければ

MED:10

MED:100

l CommunityおよびLocal Preferenceによる重み付け

l 隣接AS側が、Communityに応じたLocal Preference値の実装を公開している場合がある

l Communityによってどのピアからトラフィックを出してほしいか、要望することができる

l 双⽅に合意があるとみなせる

隣接ASとのトラフィックエンジニアリング(BGP)

ISP 隣接ASユーザ (Eyeballs)

act-community

sby-community

ntt.netの例

l 地理的広がりがあると、レイテンシが効いてくる

l ISPには地理的隔たりに合わせて、プレフィックスを分割して、隣接ASに経路を広告するモチベーションがあるl 特に、隣接ASがコンテンツプロバイダで、l 低レイテンシが鍵となるアプリケーションである場合

l 隣接ピア向けとそれ以外で経路の細かさが異なる場合がある

地理的広がりとプレフィックス分割

ISP 隣接AS

ユーザA

ユーザAの ベスト経路

ユーザB

数msec の 地理的隔たり

ユーザA向けトラフィック

ユーザBの ベスト経路

ユーザB向けトラフィック

Peer leaks

l 最近では、GoogleおよびLevel 3の事例

l 隣接ピアが、誤って経路を全インターネットあるいは部分に対して広告してしまうリスク

l 特定のピア”だけ”に細かい経路を流していると、リスクが⾼まる

経路漏れに関して、BGP元来の脆弱性を補う提案がいくつかある•  BGPPrefixOriginValidaDon–  RouteOriginAuthorizaDons(ROAs)を配布し検証する–  しかし、OriginASが正しい今回のようなハイジャックには効果

がなかったと思われる•  maxlen(maximumprefixlength)は有効かもしれない

•  BGPPathValidaDon–  AS-PATHに対して、署名検証する–  しかし、MITMは防げるが、今回のようなRouteLeakは防げな

かったと思われるしかし、そもそも、世界中のASが対応しないと効果がない

Secure BGP

•  [RFC8212]DefaultExternalBGP(EBGP)RoutePropagaDonBehaviorwithoutPolicies– 何も考えずにeBGPのピアを張ったときに、全経路を

送出しようとする動作をやめる

•  [I-D.]RouteLeakPrevenDonusingRolesinUpdateandOpenmessages– ピアを張るときに、そのピアの用途を規定する– “ピア経由の経路”というtransiDveahributeをつける

実装上・プロトコル上の対策提案

Espressoのインパクト

l Espresso以前l Googleに対して、プレフィックス単位での制御(トラ

フィックエンジニアリング)を期待して、細かい経路を渡す

l Espresso以降l ISP側がどのような単位で経路広告をしようが、

Google側が、内部処理的に品質単位でプレフィックス分割をして、トラフィックエンジニアリングを実施する

l 今後はISPは細切れ経路を出さなくて済むのか？l Googleに対してはそうかもしれないが、全てのコンテ

ンツプロバイダがGoogleと同様の仕組みを持つとは思えない

細切れされていく経路

•  IPv4総経路のうち約50%は、(本来不要な)細切れ経路

http://www.iepg.org/2017-07-16-ietf99/2017-07-16-bgp-more-specifics-gih.pdf

細切れ経路(more specific)

•  経年で割合が増えているわけではないが、用途が変わってきている

http://www.iepg.org/2017-07-16-ietf99/2017-07-16-bgp-more-specifics-gih.pdf

細切れ経路(more specific)

細切れ経路を出す理由

•  トランジットとのトラフィックエンジニアリング– パンチングホール– マルチホーム時のトラフィック操作

•  ピアとのトラフィックエンジニアリング– ピアへのみ広報

•  グローバルインターネットでは観測されない•  これが漏れてしまうとシビアな経路漏れ事象になる

•  経路漏れ/経路ハイジャック対策•  DDoS対策

経路漏れ対策としての細切れ経路

•  経路漏れされてしまったら– 経路漏れ経路よりも細かい経路を流す

•  同一の長さの経路でも、AS-PATH長で勝てるかもしれない

•  経路漏れされないようにするには– 基本無理。いかに気づくかが大事– 全てのASに送付する経路を一致させる

•  ピアのオペミスの影響を最小化

– 常時最小単位に細切れする(前述のOverlayTypeの広報)

•  昨今のRouteLeak事象の背景には、コンテンツプロバイダでのSDNによる粒度の細かい制御のために、経路を分割したいという要求がある

•  BGP上にSDN制御をアドオンするという形式が引き続き続くとすると、インターネット上で観測される経路は、トラフィックエンジニアリング(DDoS対策含む)のためにさらに分割されていくと予想される

まとめ