PGA: Using Graphs to Express and Automatically Reconcile Network Policies を読む

2015-12-18 by Daisuke Kotani

この記事はシステム系論文紹介 Advent Calendar 2015 18日目の記事です。

Chaithan Prakash, Jeongkeun Lee, Yoshio Turner, Joon-Myung Kang, Aditya Akella, Sujata Banerjee, Charles Clark, Yadi Ma, Puneet Sharma, and Ying Zhang. 2015. PGA: Using Graphs to Express and Automatically Reconcile Network Policies. SIGCOMM '15. ACM, New York, NY, USA, 29-42, 2015.

をざっと読みます。図は断りのない限り本論文からの引用です。

何をしたいのか

一つのネットワークにはいろんな思い(ポリシー)が詰まっている。例えば、

Independently specified policies in Figure 1 (a)

では、

  • P1: Marketing 部門 (Mktg.) からのポート 7000 宛ての通信のみ Load Balancer (LB) を経由して CRM サーバ (CRM) に通す
  • P2: Employees からのポート 80, 334, 7000 宛ての通信は Firewall (FW) を経由してサーバ (Servers) に通す

ということを示している。実際のネットワークでは、

Composed policy in a graph

のように、複数のポリシーを組み合わせて1つの大きなポリシーを作る必要がある。 これをどうやって作るかという話。

どうするか

論文に挙げられている

Sample input graphs and label mapping

を例に使う。

構成要素

全てのポリシーは通信元と通信先 (Endpoints, EP) を指定する必要がある。 Endpoint をグループ (Endpoint Group, EPG) にして、ラベルをつける。 IT (IT部門), Engg (工学部), Departments (部局の集合), DC (データセンターにあるサーバ), Web (ウェブサーバ) など。 ポリシーは EPG 単位で記述される。

EPG は階層化することができる。IT と Engg を合わせて Departments といった感じ。同じ親ノードを持つノードは互いに素である必要がある。 また、階層構造は複数存在してもよい (場所に関するもの、組織構造に関するもの、など)。 異なる階層構造にあるラベル間の制約を書くこともできる (IT部門はキャンパスに存在する、サーバはDCにある、など)。

Sample input label namespace hierarchy

2つの EPG 間のポリシーを表現するための枝 (edge) には2種類ある。

  • whitelist edge: 2つの EPG 間の通信を許可するもの (例の (a) - (c) )。
  • conditional edge: もし whitelist edge が存在している場合に経由すべき middlebox などを指定するもの (例の (d) は、もし他のポリシーでキャンパスからDCへの通信が許可されていれば、その通信は必ずFirewallとByte Counterを通すということを表現している)。

どちらも、枝には属性としてclassifier(その枝で通信を許可するパケットのヘッダ)がつく。 枝のないEPG間は通信が許可されない。

また、枝には、Network Function Box (ロードバランサとかファイアウォールとかDPIとか)を挟むことができる。 Network Function Box の動きは Pyretic で書く。 "match(dstip = Web.virtIP) » modify(dstip = Web.RIPs)" (VIP に来たパケットをバックエンドのサーバのIPに書き換える) みたいな感じ。

2つの EPG 間の制約、例えばAとBの間はポート 88 だけは確実に discard する、その他はポリシーがあれば通してもよい、みたいなことも書けるらしい。

ポリシーの結合

1. EPG を正規化する。

それぞれの階層木の葉の部分をさらに他の階層木の葉の部分と AND を取ったりして、全ての EPG が互いに素になるように、EPG を細かくしていく。DC and Web, IT and Campus みたいな感じ。 もともと定義されていた EPG 間の制約は新しいものにコピーされる。もし矛盾なくマージできたらマージし、矛盾を解決できなかったら通知される。

2. 正規化されたEPGで表現された個々のポリシーをまとめていく。

同じ EPG 間で、枝についている classifier が overlap しなくて、EPG 間との制約を満たすものは特に気にせずマージできる。例えばある枝がポート 80 への通信を許可していて、違う枝がポート 81 への通信を許可している場合など。 一部だけ overlap していても、overlap していない部分はその部分だけを classifier にした新しい枝を追加してまーじすればよい。

overlap している部分は、Network Function Box の順番をよく考えてマージする必要があって、それぞれの Box がどういうことをしているのかとかトポロジとかを考慮してよろしくやってくれるらしい (読みきれなかった)。

Composed graph for the running example

評価

大規模なネットワークの ACL (20K以上) を参考に作ったポリシーのデータセットで10〜15分で作れたらしい。

感想・その他

計算されたものからそれぞれの機器に送り込むにはもう一苦労しそう。

ポリシーの表現能力が十分かどうかって評価はどうすればよいのだろう。例えば端末間の直接通信は禁止する、というのを書こうとした時に、書けなくはないけどEPGの数が爆発しそうだし動的に変化しそうだし現実的じゃなさそう。

ポリシーの結合の部分、具体例が少なくて分かりにくかった。



このエントリーをはてなブックマークに追加