NSDI2015読み会 (http://connpass.com/event/16685/) Correctness セッションの資料です。理解に誤りがあったらごめんなさい

1. NSDI’15 Correctness セッション

2. UCLAとUSCとMSRしかいない
 A General Approach to Network Configuration Analysis
 Ari Fogel and Stanley Fung, University of California, Los Angeles
Luis Pedrosa, University of Southern California
Meg Walraed-Sullivan, Microsoft Research
Ramesh Govindan, University of Southern California
Ratul Mahajan, Microsoft Research
Todd Millstein, University of California, Los Angeles
 Analyzing Protocol Implementations for Interoperability
 Luis Pedrosa, University of Southern California
Ari Fogel, University of California, Los Angeles
Nupur Kothari, Microsoft
Ramesh Govindan, University of Southern California
Ratul Mahajan, Microsoft
Todd Millstein, University of California, Los Angeles
 Checking Beliefs in Dynamic Networks
 Nuno P. Lopes, Nikolaj Bjørner, and Patrice Godefroid, Microsoft Research
Karthick Jayaraman, Microsoft Azure
George Varghese, Microsoft Research
2

3. 論文の概要
 A General Approach to Network Configuration Analysis
 機器の設定 - プロトコルの振る舞い - Data Plane の転送 の一貫性の
確認
 ECMPであるパスは通るけど別のパスは通らない、みたいなことがない
 障害があってもパケットが届く(ACLとか経路フィルタに引っかからない)
 宛先は一つ
 Analyzing Protocol Implementations for Interoperability
 同じプロトコルの異なる実装の相互接続性のシンボリック実行による
検証
 メッセージが問題なく処理されるか、エラーになるか
 メッセージの意味の解釈までは踏み込まない
 Checking Beliefs in Dynamic Networks
 ネットワークのパスやアクセス制御のポリシーの検証
3

4. A GENERAL APPROACH TO
NETWORK CONFIGURATION
ANALYSIS
Ari Fogel, Stanley Fung (UCLA), Luis Pedrosa (USC),
Meg Walraed-Sullivan (MSR), Ramesh Govindan (USC),
Ratul Mahajan (MSR), Todd Millstein (UCLA)
4

5. Background and Motivation
 到達性やフィルタなどのポリシーを反映した Data Plane
になる Config かどうか検証したい
5
 Challenge:
 どのように Data Plane の状態を導出するか
 どのように Data Plane のエラーの原因の Config を特定するか
Data Plane
Config
導出
Device
Data Plane
Config
導出
Device
Data Plane
Config
導出
Device
ポリシー
手動もしくは自動で設定
検証

6. Batfish
 LogiQL を使って導出ルールを (ひたすら) 記述する
 LogiQL: Datalog をベースにした演繹データベースへのクエリ言語
6
BestOspfRoute(node, network, nextHop, nhIp, cost)
← OspfRoute(node, network, nextHop, nhIp, cost),
MinOspfRouteCost[node, network] = cost
Rule
Body
Body が成り立てば Rule も成り立つ
例1: node の network への最小コストが cost でその OSPF 経路があれば、
その経路は OSPF の node の network へのベスト経路である
例2: OspfRoute の node の network への経路のうち、コスト最小のものが
OSPF の node の network への最小コストである
MinOspfRouteCost[node, network] = minCost
← minCost = agg<<cost =
min(cost)>>:
OspfRoute(node, network, _, _,
cost).

7. Batfishの4つのステージ
 Stage 1: Config + Topology → Control Plane Model
 がんばって Config を Parse して LogiQL の fact を作る
 Stage 2: CP Model + Environment → Data Plane Model
 Environment: ポートの up/down, 対象のネットワーク外からの入力
 Data Plane Model: RIB (経路表) + ACL
 Stage 3: Data Plane Model + Safety Property → 反例
 Safety Property: 確認したいポリシー (の not)
 反例: Safety Property を満たさないパケットの例
 Stage 4: Data Plane Model + User Interaction + 反例 →
問題のある Config
 反例 -> Data Plane Model -> Control Plane Model -> Config
 原因となった fact を順に追跡していく
7

8. 例
 Config: それぞれの機器の設定
 OspfCost(n1, int1_2, 1)
 OspfNeighbors(n1, int1_2, n2, int2_1)
 Control Plane Model: それぞれのプロトコルの経路計算
 OspfRoute(node, network, nextHop, nextHopIp, cost) ←
OspfNeighbors(node, nodeIntCost, nextHop, nhInt),
InterfaceIp(nextHop, nhInt, nextHopIp),
OspfNeighbors(nextHop, _, hop2, _),
BestOspfRoute(nextHop, network, hop2, _, subCost),
node != secondHop, cost = subCost + nodeIntCost
 Data Plane Model: FIB
 InstalledRoute(node, network, nextHop, nextHopIp, admin, cost,
protocol)
← MinCostRoute(node, network, nextHop, nextHopIp, admin, cost,
protocol)
8

9. Property Checking
 Network Optimized Datalog を使用
 Checking Beliefs in Dynamic Network で出てくる
 条件 P を確かめるために not P をシステムに入力する
 not P を満たすパケットや状態の例とともに出力される
 Multipath Consistency
 どのパスを通ってもパケットは同じように扱われる
→ パケットが破棄される、をシステムに入力
 Failure Consistency
 想定した障害が起こってもパケットが届く
→ ある Environment でパケットが届かない、をシステムに入力
 Destination Consistency
 Destination は一つで、他にパケットが吸い込まれない
→ Destination がいない Environment ではパケットが届かない、を
システムに入力
9

10. 評価
 2つの大学のキャンパスネットワークの設定で検証
 計算時間
 Data Plane の導出 (Stage 2): 238 / 37 min (Net1 / Net2)
 Multipath Consistency の確認 (Stage 3): < 90 sec
 Failure Consistency (Stage 3):
1 case 当たりの時間は Multipath と同じぐらい
10
論文より引用
設定ミス
Net1: 21 Routers, 52 AS
Net2: 17 Routers, 1 AS

11. ANALYZING PROTOCOL
IMPLEMENTATIONS FOR
INTEROPERABILITY
Luis Pedrosa (USC), Ari Fogel (UCLA),
Nupur Kothari (Microsoft), Ramesh Govindan (USC),
Ratul Mahajan (Microsoft), Todd Millstein (UCLA)
11

12. Protocol の実装の相互接続性
 メッセージが受け入れられるかどうか
 Sender がメッセージを生成・送信 → Receiver がエラー
 メッセージの解釈が同じかどうか
12
本論文はこっち
https://www.usenix.org/sites/default/files/conference/protected-files/nsdi15_slides_pedrosa.pdf より引用

13. Joint Symbolic Execution
 Symbolic Execution: ある実行経路を通る制約を求める
 制約の種類が爆発する intersection を求めるのが面倒
 Sender で Symbolic Execution を実行,
メッセージの値の制約を求める
 Receiver でその結果を利用し Symbolic Execution を実行
Reject される制約を求める
 探索の工夫:
 Reject されるパスを DFS で求めるのは
効率が悪い
 Receiver で Error になる点をゴールとし
A* で求める
 SMT Solverで制約を満たす値を
求める
13
https://www.usenix.org/sites/default/files/conference/protected-files/nsdi15_slides_pedrosa.pdf より引用

14. Validation & Clustering
 Validation
 Joint Symbolic Execution の結果には False Positive がある
 実際にコードに入力してみて確かめる
 Clustering
 同じ箇所に起因していると思われるバグをまとめる
 距離関数: API, API への入力, メッセージの正規表現,
state machine など
14

15. 評価
 SPDY と SIP の実装で相互接続性のバグを発見
 SPDY: spdylay v0.3.7 / v1.3.1 と nginx v1.5.5 / v1.7.4
 SIP: eXoSIP, PJSIP
 ASCII 文字列ではないものを受け入れない
 空の文字列を受け入れない
 バージョン番号の表記
 TRACE method の受け入れの可否
 検証速度
 Joint Symbolic Execution が同じ時間で100,000 倍以上のパスを発見
 A* を使った探索が同じ時間で一番多くのパスを発見
 130 Core ぐらいまでは linear に発見されるパスの数が増える
15

16. CHECKING BELIEFS IN
DYNAMIC NETWORKS
Nuno P. Lopes, Nikolaj Bjørner, Patrice Godefroid (MSR),
Karthick Jayaraman (Microsoft Azure), George Varghese (MSR)
16

17. Goal
 “Belief” が満たされていない潜在的なバグを発見する
 Belief: Operator が ”こうであるはず” と思っていること
 例: 顧客の VM は Cloud Controller にアクセスできない
 例: 顧客の VM 同士は相互に通信できるアクセスできる
 例: ECMPやバックアップ経路を通ってもフィルタは同じ
 例: あるセグメントは特定の Middlebox (NAT) を通って通信する
 例: 同じクラスタ内のマシン同士の通信はクラスタの外に出ない
 どんどん変わるネットワークで
 ホストやリンクは落ちる → バックアップに切り替わる
 パケットフォーマットや転送制御の方法は変わる
 OpenFlow, P4, VXLAN, etc
17

18. Datalog で Packet の転送を表現
18
図は論文より引用
 R1(dst,src)
 R1 に (dst, src) のパケットがある
 A(dst, src) :- R1(dst, src)
 R1 にあるパケットは A にもある
 Set0 := src’ = src & dst’ = dst[2] 0 dst[0]
 dst[1] を 0 にセット
 G32 := !G3D & dst = 1**
 R3 → R2 に送られるパケット
 R3(dst, src) :- G32 & Set0 & R2(dst’, src’)
 R3 にあるパケットは、
R3->R2の線を通って、
dst[1] が 0 に書き換えられていて
R2 にあるパケット
 ? A(dst, src)
 Aにあるパケットはどこから？

19. Network Optimized Datalog
19
図は論文より引用
 Original の Datalog の課題:
 Large Header Space: 値の数の爆発
 Large Header Space のための新しいデータ構造
 Boolean の表現のために BDD を使う
 Ternary Bit Vectors (0 / 1 / don’t care) も使用
 Select-Project Operator: Input から生まれる Output のみに絞る (?)
 パケットフォーマットや
転送制御の変更 →
query に新しいフォーマットや
制御に関するものを追加すればよい

20. 評価
 データ
 Stanford のルータの経路表の snapshot, ルータ 16台ぐらい
 一般的なクラウドプロバイダー (fat tree)
 Microsoft のクラウド用データセンター (HKG, SG) ルータ100台ぐらい
 Belief のチェック (Protection, Reachability)
 MS の DC で Belief を満たさないものを見つけた
 それぞれ十数分ぐらい
20