Transcript 拠点間接続における一提案 - 慶應義塾大学 徳田研究室

利用者主導型仮想プライベート・
サブネットワークに関する研究
慶應義塾大学政策・メディア研究科修士二年
サイバーインフォマティクス(CI) 青柳禎矩
主査 徳田英幸，副査 高汐一紀，戸辺義人
概要
‫ ﻪ‬利用者主導型VPN構築機構のShepherdの提案
‫ ﻩ‬ノード単位のアクセス制御が可能
‫ ﻩ‬既存ネットワーク構成，設定などを変更する必要がない
‫ ﻩ‬導入回数はプライベートネットワーク毎に一度のみ
：Shepherd
アウトライン
‫ﻪ‬
‫ﻪ‬
‫ﻪ‬
‫ﻪ‬
‫ﻪ‬
利用者主導型VPNの必要性
Shepherdの提案および関連研究との比較
Shepherdの設計・実装
評価
今後とまとめ
本研究の背景と目的
プライベートネットワーク
‫ ﻪ‬IP通信可能なノードの増加
‫ ﻩ‬ノード：個人利用する端末
‫ ﻪ‬組織でのプライベートネットワーク構築
：プライベート
ネットワーク
仮想プライベートネットワーク
(VPN: Virtual Private Network)
‫ ﻪ‬遠隔地に存在する同一組織のプライベートネット
ワークの結合
‫ ﻩ‬ノード間の透過的な通信の実現
‫ ﻩ‬ネットワーク管理者による構築
VPN
Public Network
接続形態によるVPNの分類
CE
CE
private network A
private network
CE
CE
private network B
(a) Virtual Leased Line
CE
CE
private network A
private network B private network C
(b) Virtual Private Routed Networks/
Virtual Private LAN Segment
node a
node c
mobile
node
node b
node d
public network
private network A
private network B
(c) Virtual Private Dial Networks
(d) Virtual Private SubNetworks
本研究の着目点
‫ ﻪ‬利用者主導型のVPNに着目
‫ ﻩ‬従来の多くのVPNは管理者主導型
‫ ﻯ‬利用者は無意識にVPNを利用していた
‫ ﻩ‬利用シナリオ
‫ ﻯ‬利用者が他のプライベートネットワークのノードと通信したい時
‫ ﻯ‬プライベートネットワークは同一組織とは限らない
‫ ﻩ‬機能要件
‫ ﻯ‬ノード単位のアクセス制御が可能であること
‫ ﻯ‬利用者のみで容易にVPN構築機構を導入・利用可能であること
映像が見たい
映像が見たい
本研究の目的
‫ ﻪ‬利用者主導型VPNの機能要件
‫ ﻩ‬ノード単位のアクセス制御が可能であること
‫ ﻯ‬VPNの接続形態の一種であるVPSNによって実現可能
‫ ﻩ‬利用者のみで容易にVPN構築機構を導入可能であること
‫ ﻯ‬既存のVPSN構築機構には存在しない
利用者のみで容易に導入可能なVPSN構築機構を提案し，
設計・実装すること
本研究による貢献
プライベートネットワーク専用の
アプリケーション使用(DLNAなど）
映像鑑賞
グループ専用の
アプリケーション実装
新しいユビキタス
アプリケーション
映像鑑賞
‫ ﻪ‬下記を実現可能
‫ ﻩ‬プライベートネットワーク専用アプリケーションの利用
‫ ﻩ‬グループ専用アプリケーションの通信基盤
Shepherdの提案
および関連研究との比較
Shepherdの提案
‫ ﻪ‬利用者のみで容易に導入可能なVPSN構築機構
‫ ﻩ‬既存ネットワーク構成，設定などを変更する必要がない
‫ ﻩ‬導入回数はプライベートネットワーク毎に一度のみ
：Shepherd
関連研究
‫ ﻪ‬ノードが送信したEthernetフレームの集約
手法の観点から分類
‫ ﻩ‬Bridge Model
‫ ﻩ‬Routing Model
‫ ﻩ‬Flat Model
関連研究 (1/3)
‫ ﻪ‬Bridge Model
ブリッジノード
が必要
ネットワーク構成の
変更が必要
：VPSN構築機構
既存の実装
・P2P-CUG (NEC) など
問題点
・ネットワーク構成変更が必要
・ネットワークの知識が必要
関連研究 (2/3)
‫ ﻪ‬Routing Model
ルーティングテーブル
の書き換え必要
：VPSN構築機構
既存の実装
・SoftEther (ソフトイーサ) など
問題点
・ルータの設定変更が必要
・ネットワークの知識が必要
関連研究 (3/3)
‫ ﻪ‬Flat Model
：VPSN構築機構
既存の実装
ノードのソフトウェア
改変が必要
・i3
・hamachi
・ELA など
問題点
・導入の手間が多い
・ノードによっては導入困難
全てのノードに
インストールの必要
Shepherd
‫ ﻪ‬Shepherdのトラフィック集約手法
‫ ﻩ‬Proxy ARP を利用する
‫ ﻩ‬シェパード（羊飼い）のようにトラフィックを特定
ノードに呼び寄せることができる
送信先
送信元
ns
ARP要求
ss
nd
ARP代理応答
sd
本来応答
すべきノード
比較
‫ ﻪ‬シェパードは導入が容易である
Bridge
Routing
Flat
Shepherd
ネットワークの
物理的変更
必要
不要
不要
不要
ネットワークの
論理的変更
不要
必要
不要
不要
機構導入回数
少ない
少ない
多い
少ない
導入後の設定
必要
必要
必要
必要
Shepherdの設計と実装
Shepherd の機能要件
‫ ﻪ‬ノード単位のアクセス制御
‫ ﻪ‬既存プライベートネットワークの物理的変
更の不要
‫ ﻪ‬既存プライベートネットワークの論理的変
更の不要
‫ ﻪ‬少ない機構導入回数
‫ ﻪ‬接続先の容易な発見
‫ ﻪ‬IP アドレス衝突の回避
機能要件の実現手法 (1/4)
‫ ﻪ‬ノード単位のアクセス制御
‫⇒ ﻩ‬フォールドの概念を導入
fold 1
fold 2
The Internet
sa
Private Network A
na
nb
sb
Private Network B
機能要件の実現手法 (2/4)
‫ ﻪ‬既存プライベートネットワークの物理的変更の不要
‫ ﻪ‬既存プライベートネットワークの論理的変更の不要
‫ ﻪ‬少ない機構導入回数
‫⇒ ﻩ‬Proxy ARP によって実現
送信先
送信元
ns
ARP要求
ss
nd
ARP代理応答
sd
本来応答
すべきノード
機能要件の実現手法 (3/4)
‫ ﻪ‬接続先の容易な発見
‫ ﻩ‬プライベートネットワークによってはIPアドレスが不定
‫ ﻯ‬利用者が接続毎に手動で教えてもらうのは利便性に欠ける
‫ ⇒ ﻩ‬XMPP (eXtensible Messaging and Presence
Protocol) の利用
‫ ﻯ‬インスタントメッセンジャのオープンプロトコル
‫ ﻯ‬XMPPサーバによるアカウントの発行，認証
‫ ﻳ‬アカウント毎の Jabber ID 割り当て
‫ ﻯ‬すでに多くの実装が存在
‫ ﻳ‬Google Talk など
機能要件の実現手法 (4/4)
‫ ﻪ‬IPアドレス衝突の回避
‫ ﻩ‬新しいアドレス空間の形成 (10.0.0.0/8 など)
‫ ﻯ‬既存アドレス空間と衝突する可能性がある
‫ ﻩ‬既存アドレス空間の拡張
‫ ﻯ‬IPアドレスを多く消費するが，衝突の可能性はない
実際のIPアドレス: 192.168.0.1
送信先IPアドレス: 192.168.0.3
192.168.0.2
192.168.0.4
192.168.0.1
192.168.0.3
192.168.0.2
192.168.0.4
全体構成と制約条件
‫ ﻪ‬プライベートネットワーク
‫ ﻩ‬インターネットとの接続を持つEthernet , IPv4のネットワーク
‫ ﻩ‬Shepherdを導入した1台のシェパードノード
‫ ﻩ‬DHCPサーバの存在
‫ ﻪ‬XMPPサーバ
‫ ﻩ‬シェパードノードのアカウントが存在すること
‫ ﻩ‬他のアカウントを追加していること（フレンドシェパードノード）
XMPP サーバ
Shepherd
シェパードノード
ns
ss
シェパードノード
nd
sd
(ssのフレンドシェパードノー
ド）
モジュール構成
Internal Message
User Interface Module
Shepherd ID, password
Managing Fold
Module
Account Module
Authenticate
Refresh
Shepherd
Nodes List
Refer
Nodes List
Refresh
Tending Module
Define Fold
Fold List
Refresh
Shepherd
Traffic
Edit Folds
Refer
Proxy Module
ARP, DHCP
Node’s traffic
Network
To Shepherd
Managing Server
To Nodes
To Nodes, Friend
Shepherd Nodes
To Friend
Shepherd Nodes
実装
‫ ﻪ‬Shepherd
‫ ﻩ‬実装対象OS
‫ ﻯ‬Windows XP
‫ ﻩ‬実装言語
‫ ﻯ‬C++ (Visual Studio .NET)
‫ ﻳ‬ヘッダを合わせて約6000行
‫ ﻩ‬使用ライブラリ
‫ ﻯ‬WinPcap: 低レイヤのネットワーク処理
‫ ﻯ‬Libjingle: XMPP通信
スクリーンショット
初期設定
フレンドシェパード
ノード一覧
フォールド一覧
メッセージ
Shepherdの利用手順 (1/5)
‫ ﻪ‬XMPPサーバへのログイン
‫ ﻩ‬フレンドシェパードノードの発見
XMPP サーバ
フレンドシェパードノードが
表示される
発見
ns
ss
nd
sd
Shepherdの利用手順 (2/5)
‫ ﻪ‬フォールドの作成
‫ ﻩ‬把握したノードの指定
‫ ﻩ‬フレンドシェパードノードの指定
‫ ﻩ‬フォールド名の指定
ns
ブロードキャストフレーム
（ARP要求等）
ss
フォールドが
表示される
ns
ss
nd
sd
Shepherdの利用手順 (3/5)
‫ ﻪ‬送信先IPアドレスの決定
‫ ﻩ‬リレーエージェントDHCP要求を出す
‫ ﻩ‬ndのIPアドレスが決定される
‫ ﻩ‬画面に表示されるIPアドレスに送信
ns
192.168.2.190
DHCP要求
ss
192.168.2.198
(192.168.2.197)
nd
10.0.0.1
DHCP応答受信
sd
10.0.0.2
Shepherdの利用手順 (4/5)
‫ ﻪ‬トラフィックの誘導
‫ ﻩ‬ns が 192.168.2.197 宛に送信するためARP要求する
‫ ﻩ‬シェパードノードssがARPに応答する (Proxy ARP)
→nsが192.168.2.197 宛IPパケットをssに送信するよう
になる
ARP要求
where 192.168.2.197
ns
192.168.2.190
(192.168.2.197)
ss
192.168.2.198
ARP応答
nd
10.0.0.1
sd
10.0.0.2
Shepherdの利用手順 (5/5)
‫ ﻪ‬実際のトラフィック転送
‫ ﻩ‬nsが192.168.2.197宛に送信→ssへ
‫ ﻩ‬ssはカプセリングしてsdに転送
‫ ﻩ‬sdは宛先を10.0.0.1に書き換え等してndへ転送
IP Packet
To:192.168.2.197
ns
192.168.2.190
ss
192.168.2.198
(192.168.2.197)
nd
10.0.0.1
sd
10.0.0.2
Shepherdの評価
評価手法
‫ ﻪ‬定性的評価
‫ ﻩ‬機能の観点による関連研究との比較
‫ ﻪ‬定量的評価
‫ ﻩ‬遅延・スループットの計測による
Shepherdの性能評価
定性的評価 - 評価項目 ‫ ﻪ‬利用者主導型VPNの機能要件
‫ﻩ‬
‫ﻩ‬
‫ﻩ‬
‫ﻩ‬
‫ﻩ‬
‫ﻩ‬
ノード単位のアクセス制御
既存プライベートネットワークの物理的変更の不要
既存プライベートネットワークの論理的変更の不要
少ない機構導入回数
接続先の容易な発見
IP アドレス衝突の回避
定性的評価 - 評価対象 ‫ ﻪ‬ノード単位のアクセス制御可能な機構に限定
定性的評価 - 評価結果 既存PNの物理的
変更不要
既存PNの論理的
変更不要
少ない
機構導入回数
接続先の
容易な発見
IPアドレス
衝突の回避
Shepherd
○
○
○
○
○
p2pcug
×
○
○
○
×
ELA
○
○
×
×
○
i3
○
○
×
×
○
hamachi
○
○
×
○
○
SoftEther
(Bridge Model)
×
○
○
×
×
SoftEther
(Router Model)
○
×
○
×
×
SoftEther
(Flat Model)
○
○
×
×
×
SSH
○
○
×
×
×
SOCKS
○
○
×
×
×
定量的評価
‫ ﻪ‬計測項目
: Shepherd
‫ ﻩ‬遅延
‫ ﻯ‬node 1 - node 4間のRTT
‫ ﻯ‬pingを用いて計測
router
‫ ﻩ‬スループット
‫ ﻯ‬node 1 -> node 4 に対する
UDPスループット
‫ ﻯ‬netperfを用いて計測
node 1
node 2
private network A
192.168.1.0/24
node 3
node 4
private network B
192.168.2.0/24
計測環境
定量的評価 (1/2) 遅延
‫ﻪ‬
‫ﻩ‬
‫ﻩ‬
16
14
‫ﻪ‬
‫ﻪ‬
12
RTT (msec)
RTT増加（中央値で約 2.84 msec の増加）
ばらつき（q1は2.72 msec, q3は4.05 msec）
結果⇒許容範囲内である
‫ﻩ‬
‫ﻩ‬
10
Shepherdによる処理増加
ホップ数の増加
インターネットでは定常的に発生しうる値
実装改良・ハードウェア性能向上により改善
8
6
4
1
2
0
Shepherd
No Shepherd
2
Shepherdの処理時間の分析 (1)
‫ ﻪ‬Pentium Counter を用いて計測
‫ ﻩ‬Shepherdに評価用実装を加えたため，若干性能が減少する
‫ ﻪ‬ノードからシェパードノードへのEthernetフレーム転送時
‫ ﻩ‬Ethernetフレームの修正に用いるデータのキャッシュなどによって
改善の余地あり
処理時間
割合
転送先フレンドシェ 0.026 msec
パードノードの検索
0.04
Ethernetフレームの
修正
0.454 msec
0.74
フレンドシェパード
ノードへの転送
0.303 msec
0.22
計
0.563 msec
1
router
1
node 1
node 2
node 3
node 4
Shepherdの処理時間の分析 (2)
‫ ﻪ‬シェパードノードからノードへのEthernetフレーム
転送時
‫ ﻩ‬検索処理は処理削減による改善の余地あり
‫ ﻩ‬ノードへの転送は，WinPcapに頼らない手法 (Raw
Socketなど) を検討する必要あり
処理時間
割合
送信元・送信先
ノードの検索
0.316 msec
0.32
Ethernetフレームの
修正
0.250 msec
0.25
ノードへの転送
0.435 msec
0.43
計
1.126 msec
1
router
2
node 1
node 2
node 3
node 4
定量的評価 (2/2) スループット
‫ ﻪ‬スループットは 35.53 Mbps
（中央値）
100
90
‫ ﻩ‬Shepherdによる処理の限界
Throughput (Mbps)
80
‫ ﻪ‬結果⇒許容範囲である
70
‫ ﻩ‬インターネットの方がボトル
ネックになる
60
50
40
30
20
10
0
Shepherd
No Shepherd
スループット減少の過程の検証
70000
60000
id of ip header
50000
40000
Shepherd
Ethereal
30000
20000
10000
0
0
2
4
6
8
10
12
time (sec)
‫ ﻪ‬IPヘッダのIDに着目
‫ ﻪ‬考察
‫ ﻩ‬最初：バッファ内の受信したEthernetフレーム全てを送信しようとする
‫ ﻩ‬途中から：Shepherdは処理が追いつかずバッファが溢れ，受信した
Ethernetフレームを間引いて送信する
今後とまとめ
今後の課題
‫ ﻪ‬セキュリティ
‫ ﻩ‬既存プロトコルなどを用いた下記項目の実装
‫ ﻯ‬通信の暗号化
‫ ﻯ‬改ざん検出
‫ ﻯ‬成りすまし検出
‫ ﻪ‬オーバヘッド軽減
‫ ﻩ‬実装改良による遅延の軽減，スループットの向上
‫ ﻪ‬利用制限
‫ ﻩ‬必要に応じて，管理者による制限
まとめ
‫ ﻪ‬動的ノードグルーピングの必要性
‫ ﻪ‬利用者主導型VPSN構築機構 Shepherd の提案
‫ ﻩ‬ノード単位のアクセス制御が可能なVPN
‫ ﻩ‬利用者のみで導入可能
‫ ﻩ‬導入はプライベートネットワーク毎に一回のみ
参照文献
‫ﻪ‬
‫ﻪ‬
‫ﻪ‬
‫ﻪ‬
"異種セグメント端末による分散型仮想LAN構築機構の設計と実装"
青柳 禎矩, 滝沢 允, 斉藤 匡人, 間 博人, 徳田 英幸
情報処理学会全国大会 Vol.66 (3) 2004年3月 March. 2004
"ELA: 分散型VPNの設計と実装"
青柳 禎矩, 滝沢 允, 斉藤 匡人, 間 博人, 徳田 英幸
日本ソフトウェア学会インターネットテクノロジーワークショップ(WIT2004)
"ELA: A Fully Distributed VPN System over Peer-to-Peer Network"
Sadanori Aoyagi, Makoto Takizawa, Masato Saito, Hiroto Aida, Hideyuki
Tokuda
IEEE International Symposium on Applications and the Internet (SAINT
2005) 2005年1月 January. 2005 pp.89-92
"Shepherd: 利用者主導型動的ノードグルーピング機構"
青柳禎矩, 高橋ひとみ, 斉藤匡人, 間博人, 徳田英幸
日本ソフトウェア学会 SPA X
Contribution
‫ ﻪ‬Lower load
‫ ﻩ‬監視すべきパケットが減る
‫ ﻪ‬Scalability
‫ ﻩ‬サーバの性能が足りなくなってきたらサーバを
追加するだけでよい
‫ ﻪ‬Redundancy
‫ ﻩ‬サーバを複数設置して冗長性を持たせること
が可能
Motivation
‫ ﻪ‬異なるネットワークに属するIPデバイス同士を容
易につなげたい
‫ ﻩ‬ユビキタスコンピューティングの発展によって，IPデバ
イスおよびこのような需要は増えるはず
Internet
‫ ﻪ‬４．２．２ ノードのグローバルな把握
‫ ﻩ‬各PCはBuddy List を保持
‫ ﻩ‬各IPデバイスごとにアクセス制限ができる
○○家のDVDレコーダからの接続
NAS：
○許可 ●禁止
プラズマ： ●許可 ○禁止
Related Works
‫ ﻪ‬アプローチの種類
‫ ﻩ‬Application Layer
‫ ﻩ‬Transport Layer
Related Work
‫ ﻪ‬拠点間接続VPN
‫ ﻩ‬端末は何もインストールしなくてもOK
‫ ﻩ‬端末とゲートウェイの間にIPsecサーバを設置
‫ ﻯ‬IPsecサーバは端末からの「全て」のトラフィックを監視
‫ ﻯ‬特定宛先のパケットだけトンネリング処理
‫ ﻩ‬SoftEther, P2P-CUG なども基本的に同一
ゲートウェイ
IPsecサーバ
‫ ﻪ‬問題点
‫ ﻩ‬性能的な問題
‫ ﻯ‬高負荷
‫ﻳ‬
‫ﻳ‬
全てのトラフィックを監視す
るので重い
トンネリング通信以外の通
信も影響をうける
‫ ﻯ‬ボトルネック
‫ﻳ‬
‫ﻳ‬
サーバが遅いと，全通信が
遅くなる
気軽にサーバを追加でき
ない
‫ ﻬ‬ネットワーク構成を
変更する必要がある
‫ ﻯ‬冗長性の欠如
‫ﻳ‬
壊れたら全く通信できない
‫ ﻩ‬使用上の問題
‫ ﻯ‬細かいアクセス制限が出
来ない
‫ ﻳ‬DVDレコーダには通信
してよいが，NASはダメ
とか
‫ ﻯ‬普通にDHCPでIPアドレス
が割り当てられると，その
デバイスにどのアドレス
がついたか分かりにくい
‫ ﻪ‬２．３ ノードグルーピングのアプローチ
‫ ﻩ‬Application Layer
‫ ﻯ‬pucc
‫ ﻩ‬Transport Layer
‫ ﻯ‬SOCKS
‫ ﻩ‬Network Layer
‫ ﻯ‬SoftEther,
‫ ﻩ‬Data Link Layer
‫ ﻯ‬SoftEther, P2P-CUG,
通信相手による通信の分類
‫ ﻪ‬パブリックなサーバに対する通信
‫ ﻪ‬プライベートなノード同士の通信
google
番組表取得
動画鑑賞
ファイル共有
Shepherdのモジュール図
User Interface
ノード
追加要請
ノード
追加？
ノード
追加
Nodes managing
module
MAC
アドレス
Node managing
module
宛先存在
確認
宛先
存在応答
宛先
要求
宛先
応答
内部メッセージ
Inducing module
DHCP
要求
ARP
要求
Capsulating module
ARP
応答
トラフィック
受信
トラフィック
送信
トラフィック
router
private network A
192.168.1.0/24
private network B
192.168.2.0/24