IP VPN 構築の理論と実践 ~ ネットワークベース VPN 最新動向 ~ コサインコミュニケーションズ ( 株 ) シニアシステムズエンジニア進藤資訓 1 VPN はいまだに % mkdir mkdir vpn-do

Transcription

1 IP VPN 構築の理論と実践 ~ ネットワークベース VPN 最新動向 ~ コサインコミュニケーションズ ( 株 ) シニアシステムズエンジニア進藤資訓 mshindo@cosinecom.com 1 VPN はいまだに % mkdir mkdir vpn-doc vpn-doc % cd cd vpn-doc vpn-doc % wget wget q q ftp://ftp.ietf.org/internet-drafts/ *vpn * % ls ls wc wc % cd cd.... % du du s s vpn-doc vpn-doc vpn-doc vpn-doc % As of 11/11/

2 VPN 関連技術 ルーティング技術 トンネリング技術 暗号化技術 その他関連技術 マルチキャスト技術 認証技術 運用管理技術 3 VPN の変遷 (1) ~(!V)PN 時代 ~ Site X Site W L2 Provider Site Z Site Y 4 2

3 VPN の変遷 (2) ~ CPE-based VPN ~ Site X Site W ISPs Site Z Site Y 5 VPN の変遷 (3) ~ Managed Router Solution ~ Site X Site W ISPs Site Z Site Y 6 3

4 VPN の変遷 (4a) ~ Network-based VPN ~ Site X Site W MPLS Site Z Site Y 7 VPN の変遷 (4b) ~ Network-based VPN ~ Site W Site X ISPs Site Z 8 Site Y 4

5 IETF / ITU の活動 Network-based VPN (NBVPN) August 3, th Pittsburgh - NBOF (Routing Area) Provider Provisioned VPN (PPVPN) December 14, th San Diego - PPOF (Routing Area) March 23, th Minneapolis PPOF/WG (Sub-IP Area) August 8, st London PPVPN WG 9 トポロジーと用語 (L2 and L3) Virtual Forwarding / Switching Instance VPN Tunnel VFI or VSI CE Customer Edge PE Provider Edge P Provider

6 VPN の分類 Base CPE-based Network-based Model Overlay model Peer model Types / Applications Virtual Leased Lines (VLL) Virtual Private Routed Networks (VPRN) Virtual Private Dial Networks (VPDN) Virtual Private LAN Segments (VPLS) 11 CPE-based vs Network-based CPE-based プロバイダは VPN の存在を意識しない プロバイダとの切り口 Layer ATM / FR Layer 3 Tunnel by GRE, IP-in-IP, IPsec, L2TP or MPLS, etc. カスタマーからプロバイダのネットワークがどう見えるか? Point-to-Point Broadcast LAN Network-based プロバイダは サービス として VPN を提供 PE 間のトンネルで実現 GRE, IP-in-IP, IPsec, MPLS, etc. Layer 2 or Layer 3 6

7 Overlay モデル Site W Site X Site Z Provider 13 Site Y Peer モデル Site W Site X Site Z Provider 14 Site Y 7

8 Network-based Layer 2 VPN ユーザからみると ( 巨大な ) スイッチに見える 顧客の Layer 3 ( 特にルーティング ) に関与しない Overlay model 利点 管理の分解点が明確 既存の Layer 2 ネットワークからの移行がスムーズ 自然なルーティングの分離 Layer 3 独立 ( マルチプロトコルのサポート ) マルチキャスト PE のスケーリング 設定の容易さ 欠点 N^2 問題 単一の Layer 2 に縛られる 15 Network-based Layer 3 VPN ユーザからみるとルーターに見える ユーザ側アドレスは通常 PE のみ expose される Overlay model or Peer model 利点 N^2 問題の回避 ルーティングを サービス として提供できる 欠点 カスタマーネットワーク ( 特にルーティング ) に関わる必要がある プロトコルの限定 ( 典型的には IP only)

9 NB-VPN に要求される各種機能 ( ステージ ) Discovery stage Membership discovery 共通のVPNを持っているかを各 PEがチェックする Topology Full-mesh / Hub & Spoke / Others Capability discovery PE 間でトンネルやルーティングの方法に関して合意する Tunnel establishment stage E.g. IPsecならIKEがこれにあたる VPN routing stage Static, IGPs (OSPF/ISIS/RIP) and/or EGPs (BGP4) Per-VPN or 全 VPN 共通 これらの stage が個別に実現されている必要はない E.g. Layer-2 VPN の場合は VPN routing stage は必要ない 17 VPN discovery 実現方法 NMS (Network Management System) 独自手法標準的手法 (e.g. SNMP) Directory (Database) server 例 )LDAP 組み込みの認証 Persistent search capability (proposed) Replication (proposed) ルーティングプロトコルにピギーバック 例 )BGP4 VPN discovery とルーティングの統合 幅広い実績とスケーラビリティー きめの細かい制御が可能

10 Tunnel Establishment 通常 トンネリングメカニズムは VPN discoveryやvpn routing を実現するメカニズムとは独立している 目的 アドレスの重複 VPN トラフィックの差別化 (e.g. QoS) IPsec MPLS GRE IP-in-IP L2TP etc. 要素 Encapsulation トンネルの多重化 トンネル作成 スケーラビリティーと階層化トンネル トンネル維持管理 19 Tunneling encapsulation Per-tunnel state の管理が必要か? IPsec, IP-in-IP, GRE : 不要 MPLS : 必要 削減するには 階層的多重化 Multi-Point to Point Encapsulation( ヘッダ ) オーバーヘッド IPsec >> MPLS Fragmentation

11 トンネルの多重化 ひとつのトンネルで複数の VPN をカバーするには 何かしらの多重メカニズムが必要 IPsec : SPI field MPLS : Label GRE : Key IP-in-IP : outer IP address? 21 トンネル作成 多重化識別子をどう配布するか? 明示的なシグナリング 利点 : セキュリティーや QoS などの特性を per-tunnel で指定できる 欠点 : スケーラビリティー問題 暗黙的方法 VPN membership や VPN routes の配布時に piggyback する シグナリングを持たないトンネリングプロトコルの場合

12 スケーリング CoreでState を管理しなければいけないトンネリングを使う場合 単に VPN 毎にすべてトンネルを張るのはスケールしない!! スケールさせるには階層的トンネルが必要 例 ) RFC2547 PE 間のLSPはLDPで作る Per-VPNのラベルはBGPにPiggyback 23 Tunnel Maintenance トンネルの生死の確認 VR (per-vpn Routing) 方式 VPNルーティングで検出可能 Aggregated routing 方式 Per-VPNのRouting Instanceがないので 別の方式を用意する必要がある

13 トンネリングプロトコル比較 多重化 マルチプロトコル可可 QoS / SLA MPLS GRE IPsec IP-in-IP L2TP PPPoE なし 可 (Key Field 可 なし 可 可 使用可 ) 本質的にはなし Delivering Protocol に依存 IP only (*1) 本質的にはなし IP only (*1) 本質的にはなし 可 Delivering Protocol に依存 トンネル確立 & 維持 LDP / RSVP なし IKE なし L2TP PPPoE MTU 制限なし 制限なし 制限なし 制限なし 64K 1500 トンネルオーバーヘッド 小 比較的小 (Bit Vector) 大 小 中 (Bit Vector & HC) 比較的小 In-Order Delivery 保証 可能 (Sequenc e Field) なし (*2) なし 保証はないが可能 可 なし なし 25 VPN Routing Layer2 Network-based VPN シンプル! 顧客のルーティングにはサービスプロバイダは関与しない Layer3 Network-based VPN VFI Scaling Issue Per-VPN routing vs Aggregated routing

14 Per-VPN Routing VPN ごとにルーティングプロトコルのインスタンスを生成 & 実行 VPN ごとに自由にルーティングプロトコルを選択できる VPN membership と reachability は独立している PE 間でトンネルする必要がある 通常 データをトンネルするのに使われるトンネルを共用 Data Plane = Control Plane VR モデルとの親和性が高い 27 Aggregated Routing サービスプロバイダ内のネットワークで単一のルーティングプロトコルを使用 理論的にはどのようなルーティングプロトコル (IGP/EGP ( ) でも使用可能だが Link State Protocol (like OSPF / ISIS) は不向き BGP がベストチョイス 柔軟なポリシー設定 高いスケーラビリティー RR マルチプロトコルサポート 高い浸透率 Data Plane!= Control Plane Peer モデルとの親和性が高い

15 Case Study BGP / MPLS VPN IPsec / BGP VPN IPsec VPN VR VPN L2 MPLS VPN 29 MPLS/BGP VPN RFC 2547 (Informational) draft-ietf-ppvpn-rfc2547bis-00.txt Layer 3 Network-based VPN Peer モデル MPLS (LSP) トンネル Aggregated Routing

16 基本的な発想 ルーティング情報の配布制御に BGP を使おう スケールするし Community で Filter するのがいいかも でも 空間が足らないので Extended Community で encode しよう! ルーティング情報を運ぶのにも BGP を使おう! でも アドレスは一意じゃないな ~ VPN IP address = Route Distinguisher + IP address そのままじゃ運べないよな ~ マルチプトロコルな BGP を使おう! アドレスの重複は VRF で解決 そのままじゃパケットを運べないので MPLS を使おう ラベルをスタックさせてスケールさせよう 31 RFC2547 の動き (1) NLRI Prefix=RD NextHop= RT=100:0 Label=200 PE( ) /8 CE /8 I-BGP P Static,IGP(RIP/OSPF),E-BGP I-BGP P P PE( ) CE PE( ) Static,IGP(RIP/OSPF),E-BGP I-BGP VRF(Virtual Routing & Forwarding)

17 RFC2547 の動き (2) /8 CE PE( ) CE L3 200 L /8 L L3 L2 200 I-BGP 15 P L2 Label=15 Penultimate Hop Poping P I-BGP Label=10 P PE( ) PE( ) I-BGP CE 33 VRF(Virtual Routing & Forwarding) Label Binding Packet Fowarding PE CE routing in RFC2547 PE (VRF) ~ CE 間のルーティングプロトコルは自由に使うことができる BGP-4 / RIP / OSPF / ISIS / Static, etc. ただし ループができやすい RIP などは事故のもと OSPF / ISIS のような Link State Protocol で 他サイトのルートは AS External なルートになってしまう 結局 現実的なのは Static か BGP-4!!

18 OSPF backdoor 問題 in RFC /8 OSPF Backdoor Link PE( ) CE / /8 I-BGP P OSPF I-BGP P P PE( ) PE( ) I-BGP CE OSPF VRF(Virtual Routing & Forwarding) 35 IPsec BGP VPN draft-declercq-bgp-ipsec-vpn-01.txt Layer 3 Network-based VPN Peer モデル Aggregated Routing 基本的な考え方は RFC2547(bis) を踏襲 ただし MPLS LSP トンネルの代わりに IPsec トンネルを使用 セキュリティーの向上 MPLS core を仮定しなくてもよい ( ただし 否定もしない ) スケーラビリティーを考慮

19 発想 トンネル手法と VPN 実現の仕組みは独立しているべきである!! MPLS LSP トンネルの代わりに IPsec トンネルを使おう ただ IPsec には MPLSのLabel Stacking のような仕組みはないので 単純に考えると各 VFI 間で full meshにipsec トンネルを張ることになる それではスケールしない!! では トンネルは PE 間だけにして トンネル中に複数の VPN トラフィックを多重できるようにしよう! SPI (Security Parameter Index) を使うしかないね 37 SA トポロジー (VFI メッシュ )

20 SA トポロジー (PE メッシュ ) PE 間で 1 つの SA を確立 39 IPsec SA ( おさらい ) 3 つのパラメータで規定される SPI (Security Parameter Index) 送信先 IP アドレス セキュリティープロトコル (AH or ESP) SPI のフォーマットは規定されていない Pseudo Random な 32bit Value でありさえすればよい

21 手法 複数の SPI (SPI pool) を一つの SA にマップする手法 BGP/IPsec VPN と通常時のコンテキストを区別する 41 VPN-SPI V-flag = V prefix prefix null null V-flag = V pseudo-random value value

22 SPI in IPsec Processing prefix prefix label label label はSA を特定するためには使われない 20bit はMPLS ラベルを使うことを想定 43 BGP / IPsec VPN IP IP ESP ESP data data V V SPI SPI pref pref Label Label SAD

23 その他の部分 RFC2547bis と同様 (BGP ( を使う ) VPN-IPv4 AF と Route Distinguisher (RD) Route Target (RT) と Extended Community Route Reflector (RR) はほぼ必須 ( 大きなネットワークの場合 ) スケーリングに関する ( 理論上の ) 特性も同じ 45 P router への要求 VPN に関する 知識 はなくてよい MPLS を要求しない ( 否定もしない ) 単なるIPルーター 各 PEに対するhost routeさえあればよい

24 セキュリティー MPLS-based Link Layer でのセキュリティー IPsec-based PE PE のエンドツーエンドセキュリティーを実現 SP またがりのサービス時に有用 47 IPsec VPN draft-ietf-ppvpn-ipsec txt Layer 3 Network-based VPN Peer モデル Aggregated Routing IPsec / BGP VPN の改良?

25 発想 IPsec / BGP VPN の有用性には同意 ただし SPI に新たなセマンティックスを導入するのは IPsec および IKE への変更につながる ならば outer なラベルに IPsec を使い inner なラベルに MPLS を使えばいいんじゃない? MPLS-in-IP で encap すればいいじゃん!! 49 IPsec の動き (1) NLRI Prefix=RD NextHop= RT=100:0 Label=200 PE( ) /8 CE /8 I-BGP Static,IGP(RIP/OSPF),E-BGP I-BGP P PE( ) CE PE( ) Static,IGP(RIP/OSPF),E-BGP I-BGP VRF(Virtual Routing & Forwarding)

26 IPsec の動き (2) /8 CE PE( ) CE L3 200 AH / ESP L /8 L3 L3 200 AH / ESP L2 200 AH / ESP L2 I-BGP R R I-BGP R PE( ) PE( ) I-BGP CE VRF(Virtual Routing & Forwarding) Packet Fowarding 51 VR-based VPN draft-ietf-ppvpn-vpn-vr-00.txt Virtual Router ( 仮想ルーター ) Layer 3 Network-based VPN Overlay モデル Per-VPN Routing

27 Layer-2 backbone-based VR-based VPN Layer-2 Network 53 Aggregated Backbone-based VR-based VPN IP / MPLS Tunnel IP / MPLS backbone Customer VR IP / MPLS Tunnel Backbone VR

28 Layer-2 vs Aggregated Backbone Layer-2 Backbone Per VPNでQoSをコントロールできる 完全なルーティングの分離 Aggregated Backbone Backbone に Layer-2 で多重できるメディアを仮定しなくてもよい GbE, POS, etc. スケーラビリティー トンネル MPLS and/or IPsec Per VPN vs VPN で多重 55 MPLS L2 VPN draft-kompella-ppvpn-l2vpn-00.txt Layer 2 Network-based VPN Overlay モデル ユーザのルーティングには関与しない

29 L2 のモチベーション DSL Optical Ethernet Metropolitan Network 57 基本的な発想 Layer 2 VPN を提供したい L2 VPN の利点を参照 できるだけ Layer 2 のセマンティックスを保ちたい マルチプトロコル性 In-Order Delivery Non address 情報 トランスポートには MPLS を使おう! ラベルスタック & CE-PE-P-PE-CE モデル でも N^2 問題は避けたい Over Provisioning でProvisioning の負荷を軽減してやろう!( 半自動 Provisioning) Layer 2 ID (DLCI, VPI/VCI) および Label は cheap である!( という前提 )

30 Topology Site X { } Frame Relay Any Media {DLCI Pool} CE5 Site W { } { } CE0 CE1 PE0 P MPLS Network PE2 { } PE1 CE4 {107,209,265, 301,414,555, 654,777,888} Site Y 59 CE2 CE3 { } Site Z 設定 VPN ID CE ID Range Label Base

31 PE Advertisement Site X { } CE0 { } CE1 VPN=1, CE ID=0, R0=10, L0=1000 PE0 P PE Data Data CE5 Site W { } VPN=1, CE ID=4, R4=9, D4[]={107,.. 888}, L4=4000 PE1 107 Data 107 Data FEC Label PE { } CE2 Site Y 61 CE3 { } Site Z CE4 {107,209,265, 301,414,555, 654,777,888} ポイント CE a CE b なパケットを送る際に PE k がinner label として割り当てた label は PE l がCE a CE b なパケットを受け取る際の incomingなlabel として割り当てたものと必ず等しくなる Layer2 ID (DLCI, VPI/VCI, etc.) とMPLS LabelのOver provisioning により CE の追加が発生しても 変更は局所的で済む (full ( mesh 時でも )

32 フレーム & ラベルフォーマット MPLS Outer Outer Inner Inner Sequence Modified Layer Layer 2 Encap Label Label Label Label Number Frame Label Label (20 (20 bits) bits) N C L S (unused) 63 N : Notification C : Control L : Loss シグナリング BGP Multiprotocol BGP L2-VPN のための AFI および SAFI を新たに導入 L2-VPN のための NLRI を規定 Extended Community LDP 以前は提案されていたが 現状はとりあえず BGP にしぼる

33 BGP NLRI for L2-VPN Length (2 octets) Route Distinguisher (8 octets) CE ID (2 octets) Label-block Offset (2 octets) Label-base (3 octets) Variable TLVs (0 to N octets) MPLS VPN : To be Layer 3 or not to be ~Layer 3 MPLS VPN (rfc2547) vs Layer 2 MPLS VPN~ Peer モデルってそんなにいいの? Aggregated Routing になるよね CE-PE 間ルーティング問題 (OSPF Backdoor Link 問題 ) draft-rosen-vpns-ospf-bgp-mpls-02.txt なんてのもあるけどさ 顧客にルーティングを サービス する 言葉を変えて言うと 顧客からルーティングの自由を奪う スケールするの? Provisioning 的にはすると思う でも PE がユーザの経路持たなくちゃいけないよね! ユーザーの経路がフラップするかもしれないし とは言っても 2547 は良くできたモデルだと思うし Layer2 の実装はこれから 要は適材適所!

34 各 VPN 手法の比較 BGP / MPLS VPN IPsec /BGP IPsec VPN VR VPN L2 MPLS VPN CPE / Network bas Network-based Network-based Network-based Network-based Layer Layer 3 Layer 3 Layer 3 Layer 2 Overlay / Peer mod Peer Peer Overlay Overlay Tunnel MPLS IPsec Layer 2 or Any IP/MPLSbased MPLS Tunnel Discovery BGP BGP Any BGP / LDP Tunnel Establishme LDP IKE Any LDP / RSVP VPN Routing BGP BGP (Aggregated) (Aggregated) Any(Per-VPN) N/A 67 まとめ IP-VPN!= RFC2547 IPsec / BGP VR L2 MPLS ユーザ側でルーティングに関して細かい要求がなければRFC2547 は良いモデル モデル!= 実装 L2 PPVPN は今後に期待 ルーティングの自由度とマルチプロトコルが魅力 VPNの P を実現するには IPsec ユーザーが選択できるのが望ましい 優れた Provisioning Tool が必要

35 参考資料 RFC 2547 (BGP/MPLS VPN) RFC 2685 (VPN-ID) RFC 2764 (IP VPN Framework) RFC 2917 (CORE-MPLS-VPN) draft-ietf-ppvpn-framework-00.txt draft-ietf-ppvpn-rfc2547bis-00.txt draft-rosen-vpns-ospf-bgp-mpls- 01.txt draft-declercq-bgp-ipsec-vpn- 01.txt draft-ietf-ppvpn-vpn-vr-00.txt draft-ouldbrahim-bgpvpn-auto- 01.txt draft-kompella-ppvpn-l2vpn- 00.txt draft-shah-mpls-l2vpn-ext-00.txt draft-kb-ppvpn-l2vpn-motiv-00.txt draft-tsenevir-l2-req-00.txt draft-worster-mpls-in-ip-05.txt