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 WG
l 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⽉

トラフィック量(CDF)

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

Top AS

全体比率
2581.16%
10096.37%
50099.45%
AS(対数)

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

増加傾向のコンテンツ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
ユーザ(Eyeballs)

ISP
Transit
B

コンテンツ
プロバイダ

コミット
l トラフィックを何Gbpsまで流してよいのか、というトランジット事業者との契約上の合意
l 10Gの回線をひいたとて、従量制の料⾦体系(メガ単価: $/Mbps/monthの価格)が基本
l しかし、企業の会計上は従量制の料⾦体系は処理しにくいので、何Gbpsまでなら固定でいくら、という契約を⾏う
l 例えば、3Gbpsまで100万円/⽉というのを5Gbpsまで100万円/⽉にすると、収⼊は変わらないが実質の値下げになる
l 顧客ISPは、コミットが増えた分、その回線に流したいが、はたしてどのように流すのか？というのがキーポイント

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

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

コンテンツ
プロバイダ

TransitBl 実際はAS-PATH⻑では制御されていないので、ほとんどよらない(後述)ロンゲストマッチ による制御
l longer 経路を流せば、ほぼ必ず寄ることは期待できる
l ただし、preﬁxの分割は禁断の⼿法
l 運⽤の複雑化、レイテンシの増加、トラブルの元、フルルートの増加
細切れ経路をAにだけ流せば、ロンゲストマッチにより、Aにトラフィックが寄る

ユーザ(Eyeballs)

TransitA

ISP
Transit
B

コンテンツ
プロバイダ

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

AS(トラフィック順)

l トラフィックの多いASほどホップ数は近い(世の中のピアリング戦略が有効に働いている)凝縮するインターネット
l ホップ数とトラフィックシェア
トラフィックシェア

トラフィックシェアで重みづけした平均ホップ数Transit A
Transit B
Transit C
Transit D
Transit E
Transit F

ホップ数

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

2.22
2.46
2.23
2.20
2.23
2.20

ISPのトラフィックエンジニアリングは、効かないl 主要コンテンツはほとんど2ホップ先
こっちから流してほしいが…

ユーザ(Eyeballs)

Transit
A
コンテンツ
プロバイダ

ISP
TransitBl コンテンツ側に、特定のトランジットに流すインセンティブがあると、ISP側のトラフィックエンジニアリングは効かない
l コンテンツ事業者にとっての⾦銭的インセンティブ
l アプリケーションアウェアルーティング(cf. Google Espresso)l 上記のシチュエーションでは、ASプリペンドによる操作は効かない
l Transit B にとって、ISPは顧客なので、AS-PATH⻑よりもLocal
Preference値 (通常 customer > peer) が優先される

Google のトラフィックエンジニアリング(TE)およびEspresso• トラフィックエンジニアリングの入力– 1) BGP経路– 2) ユーザの利用帯域と品質– 3) ピアのリンク使用率– と、コストなどのハイレベルなポリシ(論文では強調していないが)• Googleにとっての効用：– グローバルトラフィック最適化:ピアのリンク使用率の向上– ApplicaDon-aware TE: End-to-End のQoEの向上– コストダウンEspressoにおける⾮ベストパス(Overﬂow)
overflowしたトラフィックの割合
ISP・50%以上のISPで、10%以上のトラフィックが、他に回ったほうがいいとなった・ごく少数のISPでは、ほとんどのトラフィックがOverflowした
ISP視点では、迷惑な話8/25 経路漏れ(Route Leak)事象

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

• Route Leak from Google– Googleからベライゾン経由の経路漏れ– Googleがピアから受け取った経路を誤って広報してしまった– ベライゾンはそれを受け取ってしまった– 経路は、ISPがインターネットに通常広報している経路よりも細切れだった• Recommended ArDcles– 8月25日に発生した大規模通信障害をまとめてみた– OCNはとばっちり、米グーグルによる大規模ネット障害の真相– パブリックデータから経路リークを探る– 08/25の通信障害概説(pdf)– Large BGP Leak by Google Disrupts Internet in Japan– BGP leak causing Internet outages in Japan and beyond

先⽇も…

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

Peer Leak: ユーザへの影響について
Google以外のダウンロードトラフィック(全体の70%程度)

経路リーク時Google経路消去時のルーティングループ
一部影響のなかったトラフィックもあり

被害ISPの細切れ経路

Internet

海外経由による遅延の増加
Verizon701

通常経路

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

被害ISPの細切れ経路

被害ISP

ユーザ(Eyeballs)

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

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

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

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

経路のリークによって、ユーザがつながりにくい事象
1. 海外経由による遅延の増加
2. トラフィックの輻輳
3. 経路消去時のルーティン
グループ(※)

経路影響・自社型

経路影響・透過型

約10万経路約10万経路

自社設備

自社設備

顧客

顧客

トランジットから流入した経路増大により、自社設備に影響がでて、自社や顧客のサービスに影響トランジットから流入した経路増大により、自社設備には影響がなくても、顧客のNW機器(あるいはDCなど)が経路増大で影響※経路消去(withdraw)時のループに関しては、IRS26の資料参照

経路はどこから来たのか？
悪意のある
第3者

観測できているもの

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

被害ISPの細切れ経路
Verizon
701

Internet

被害ISPの細切れ経路

可能性②
細切れ経路
被害ISP

1.
2.
3.

可能性①

Google15169

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

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

隣接ASとのトラフィックエンジニアリング(BGP)l MEDによる重み付け
MED:10ユーザ(Eyeballs)

ISP

隣接AS

MED:100

l MEDによって、どのピアからトラフィックを出してほしいか、要望することができる
l MEDは受信AS側で上書きすることができる
l インターネットでは、⼊ってくるトラフィックは、根本的には制御できない
l 双⽅に合意がなければ

隣接ASとのトラフィックエンジニアリング(BGP)l CommunityおよびLocal Preferenceによる重み付け
ntt.netの例

act-community

ユーザ(Eyeballs)

ISP

隣接AS

sby-communityl 隣接AS側が、Communityに応じたLocal Preference値の実装を公開している場合がある
l Communityによってどのピアからトラフィックを出してほしいか、要望することができる
l 双⽅に合意があるとみなせる

地理的広がりとプレフィックス分割
l 地理的広がりがあると、レイテンシが効いてくる
ユーザAの
ベスト経路
ユーザA
数msec の地理的隔たり

ISP

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

隣接AS

ユーザBのベスト経路

ユーザB
ユーザB向けトラフィックl ISPには地理的隔たりに合わせて、プレフィックスを分割して、隣接ASに経路を広告するモチベーションがある
l 特に、隣接ASがコンテンツプロバイダで、l 低レイテンシが鍵となるアプリケーションである場合
l 隣接ピア向けとそれ以外で経路の細かさが異なる場合がある

Peer leaksl 最近では、GoogleおよびLevel 3の事例
l 隣接ピアが、誤って経路を全インターネットあるいは部分に対して広告してしまうリスク
l 特定のピア”だけ”に細かい経路を流していると、リスクが⾼まるSecure BGP

経路漏れに関して、BGP元来の脆弱性を補う提案がいくつかある• BGP Preﬁx Origin ValidaDon– Route Origin AuthorizaDons(ROAs)を配布し検証する– しかし、Origin ASが正しい今回のようなハイジャックには効果がなかったと思われる• maxlen(maximum preﬁx length)は有効かもしれない• BGP Path ValidaDon– AS-PATHに対して、署名検証する– しかし、MITMは防げるが、今回のようなRouteLeakは防げなかったと思われる

しかし、そもそも、世界中のASが対応しないと効果がない実装上・プロトコル上の対策提案• [RFC8212]Default External BGP (EBGP) RoutePropagaDon Behavior without Policies– 何も考えずにeBGPのピアを張ったときに、全経路を送出しようとする動作をやめる• [I-D.]Route Leak PrevenDon using Roles in Update
and Open messages– ピアを張るときに、そのピアの用途を規定する– “ピア経由の経路”という transiDve ahributeをつける

Espressoのインパクト
l Espresso以前
l Googleに対して、プレフィックス単位での制御(トラフィックエンジニアリング)を期待して、細かい経路を渡す
l Espresso以降
l ISP側がどのような単位で経路広告をしようが、Google側が、内部処理的に品質単位でプレフィックス分割をして、トラフィックエンジニアリングを実施する
l 今後はISPは細切れ経路を出さなくて済むのか？
l Googleに対してはそうかもしれないが、全てのコンテンツプロバイダがGoogleと同様の仕組みを持つとは思えない細切れされていく経路

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

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

細切れ経路(more speciﬁc)• 経年で割合が増えているわけではないが、用途が変わってきている

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

細切れ経路を出す理由• トランジットとのトラフィックエンジニアリング– パンチングホール– マルチホーム時のトラフィック操作• ピアとのトラフィックエンジニアリング– ピアへのみ広報• グローバルインターネットでは観測されない• これが漏れてしまうとシビアな経路漏れ事象になる• 経路漏れ/経路ハイジャック対策• DDoS対策

経路漏れ対策としての細切れ経路• 経路漏れされてしまったら– 経路漏れ経路よりも細かい経路を流す• 同一の長さの経路でも、AS-PATH長で勝てるかもしれない• 経路漏れされないようにするには– 基本無理。いかに気づくかが大事– 全てのASに送付する経路を一致させる• ピアのオペミスの影響を最小化– 常時最小単位に細切れする(前述のOverlay Typeの広報)

まとめ• 昨今のRoute Leak事象の背景には、コンテンツプロバイダでのSDNによる粒度の細かい制御のために、経路を分割したいという要求がある• BGP上にSDN制御をアドオンするという形式が引き続き続くとすると、インターネット上で観測される経路は、トラフィックエンジニアリング(DDoS対策含む)のためにさらに分割されていくと予想される