ロガーではないが、とりあえずログを取ったので、晒しておく。
無修正で、いろいろと至らないところがあるし、敬称略なので、その上で。
また、一部不足している点などもありますので、そこは記憶を元に保管してください。
---------- 最近のルーティング動向 経路奉行Update 中野 達也氏 (Telecom-ISAC Japan 経路情報共有ワーキンググループ(BGPWG) / KDDI) ---------- agenda 1. 経路奉行って何? 2. 最近の経路奉行 3. ルーティング事象に関連した事例の紹介 4. その日が来たときの為に IWと同じようなことをしゃべっているがご了承ください。 IRSで経路奉行が出たのは2009年頃。 * 経路奉行の仕事 経路情報(BGP fullroute)を蓄積 経路情報をJPIRRの登録情報(OriginAS)と比較 差分があれば警告。 X-keiroに経路ハイジャックの疑いということで通知。 * BGP peers 18社 2497 2510 2514 4716 2518 2527 .....etc * 何で作った? 2005年頃BGP-WGメンバー向けのLGから始まった。 せっかくの経路情報があるので活用して、経路の監視をしてみよう 名前を決めよう → 経路奉行 * 何かと比較するか? 最初はRADBだったが、アラート大量発生、消し忘れ、誤登録などで使い物にならなかった。 JPIRRを参照して試験。 良い感じで、なかなか良い感じ。 BGP-WGメンバーの経路=だいたいJPIRRにある JPNICの努力により制度も高め。 2008/5〜 JPNICと協力して通知実験を行い、現在に至る。 * 最近の経路奉行 注意 検知数=経路ハイジャックの発生数ではない * 考えられる検知原因 作業の経過で発生(notオペミス) - ASをまたぐprefixの行こう(PIの引っ越し等) - IRR 更新前に移行するとそうなる パンチングホール オペミスによる誤広報 リアルな経路ハイジャック行為 * 最近の通知状況 1月 - 8/11 2月 - 32/25 3月 - 29/33 4月 - 21/13 5月 - 2142/2153 6月 - 7 / 10 * 最近の通知状況(メンバー向けmail総負数-作業分除く) 1月 - 8/11 2月 - 32/25 3月 - 29/33 4月 - 21/13 5月 - 20/13 6月 - 7/10 * 最近の通知状況(X-Keiro宛送付数-作業分除く) INV_ORGN(v4)/X-keiro通知数/通知NG 1月 8/8/0 2月 26/29/1 3月 29/44/8 4月 20/20 5月 16/37/4 6月 7/7/0 ※ NGは登録がなかった物 * IPv6分布数(検知AS数) 1月 - 9 2月 - 0 3月 - 1 4月 - 1 5月 - 1 * 回復要因別グラフ BGP-update等 1788/12 それ以外 443/0 * BGPを要素とした物がほとんど 検知・通知状況についてのまとめ 作業等で大量にAlertが発生してしまうのはある程度は仕方がない。 誤広報が検知できないよりは良い 正しい検知のためには正しいIRRが不可欠。 X-Keiroの情報もあるとJPIRRに登録した方にも通知ができる。 * 最近の経路奉行 今の経路奉行における問題。 1台のサーバで受けている。 壊れると奉行は止まる。 一時期止まっていたときがあった。 bgpdがシングルスレッド そろそろfullrouteが受け取れない。メモリの上限に達しそう・・・。 改善策を検討中(機能分散化等) 次回、IRSでお話することがあれば、お話させていただきます。 * 経路舞踊を取り巻く事情 それぞれの思惑 - BGP-WGは分散化や実験的なことを行いたい。 → 当然不安定になる可能性 -JPNIC(JPIRR)利用者は確実な通知を望んでいる → 求められるのは安定したシステム 双方がしあわせになれる方法を検討中。 * 経路奉行のまとめ 経路奉行は今日も安定して動いている 経路情報とJPIRRに登録のupdateがあれば、きっと今後も動き続けます。 さまざまな問題を抱えているのは事実なので改善 BGPsecが当たり前な世の中になるまでは活躍し続けます。 * ルーティング事象に関連した事例の紹介 typo で経路がハイジャックした例 ある休日の昼下がり。(IWの前日?) 13:19 事件発生、Alertメール受領、調査開始。 13:30 使用中のアドレスであることを確認、細かい経路広報の準備開始 13;45 誤広報もとのASに停止をメールにて依頼 14:05 細かい経路を広報し、取り返す 15:14 誤広報が停止。 16:09 誤広報もとのASより対処した旨を連絡 16:25 先方に了承したとメール 原因は...prefixの第1オクテットをベンダーがtypoした。 * 本件で感じたこと typoが原因とはいえ、実際に被害は受けてしまう。そして他人事ではない。 加害者にならないように気をつけないと。。 先方は非常に真摯に対応してくれた。 ここはお国柄がよく現れる衣装 対応手順の確立が早期解決につながると感じた。 * ねらわれそうなアドレス(/24) がやられた例 飲み会を夜に控えた夕方のこと。 16:38 事件発生、Alertメールが来ない(経路奉行。。。) BGPMONからメールが来てた。担当者のみ受信していた 18時頃 担当者がBGPMONのメールに気づきあわてる 幸か不幸か、アドレスはまだ使われていなかった。 19:15 誤広報元ASにメールで問い合わせ 複数宛先に送ったが、大半がunknownで帰ってきた。 19:44 誤広報元の上位ASにメールで問い合わせ 22時頃 停止 * 事例を踏まえ、実際にやったこと 手順書の策定及び文章化 - 文章化というより、Wiki - メールテンプレートの作成 支援ツールの作成 - 簡単なスクリプト、以下を一度に実行 - JPIRR/RADBへのwhois - 複数のホスト(含むLG)でtraceroute / sh ip bgp route * 備えておきましょう - 検知できる、してもらえる体制作り 何かあったときにわかるように IRR(JPIRR/RADB)の登録 - K-keiroを麺テナー/Routeオブジェクトに - 経路奉行以外のシステムへの登録も - BGPMON - ISAlarm やったときには気づかない、加害者にならないように対策。 注意してもらえる体制作り - やってしまったときに教えてもらえるように - whois情報のアップデート - peering db の登録・更新 - 調べるためのノウハウ作りも - LG/traceroute.org - 自社網からshow ip bgp でも正しい答えは出ないかも - 第三者的支点として、LGも使ってみる 簡単でも良いので対応手順をまとめる - やられたときのことを考える - やってしまったときのことを考える 重要なのは、これらのことを継続して行うこと。 * 質疑 メモリが足りないというのは、食えないと言うよりは、そのうちたりなくなる。 OSの制限事項に引っかかってしまう。Linuxの環境上、シングルプロセスあたり3G。 64bitにすれば、回避出来る? /lib/〜が32bitを使っているので、そこを治さないといけない(ishiguro) Quagga。 ログにスロースレッドが出ている。 ---------- IPv4アドレス移転で経路数は増えたのか? 白畑 真氏 (クララオンライン/USONYX) ---------- PIの変更のおすすめの手順 検知されない手順 JPIRRに引っ越し前に新しい情報を登録、二つ登録された状態。 新しい方で広報しても、問題ない。 やっちゃった人向けへの通知も出来るのではないか? 経路奉行の分散 JPIRRの負荷分散。 検出する元のDBの負荷については? (yoshitomo) 経路ハイジャック、検出するところでは検出出来る。 日本では検出していない、ヨーロッパなどで検出している、気づかない物もたくさんあるとおもうので、 WorldWideで登録しておきましょう。 multiple originのprefixは? (shiharata) 経路奉行としては、問題ない。という基本設計書だったと思う。 検証: IPv4アドレスの移転 アドレス移転の件数 2012Q4 2 2011Q1 1 2011Q2 10 2011Q3 42 2011Q4 40 2012Q1 47 2012Q2 38 2012Q3 46(8/1現在) アドレスブロックの分割移転(カウント) 192.168.0.0/16 -> 192.168.1.0/24 192.168.2.0/24 対象外 元々の分割広報・ぱちん具ホールされていたアドレスブロックの移転 こちらについてはアドレス移転による経路増大にはカウントしていない 計測方法 2010/11/1 - 2012/8/3 にAPNICまたはJPNICでIPアドレス移転が行われたアドレスブロックを調査 アドレス移転が行われた日から一定期間前、期間後の当該ブロックの経路広報状況(or-longers) .... 要因1 IPアドレス移転と経路広報状況の推移 要因2: アドレスブロックの分割移転 スーパーネットとパンチングホールの状況 * まとめ IPアドレス移転で移転されるアドレスブロック数、移転IPアドレス数は今後も増加すると考えられる IPアドレス移転に伴い、一定の経路数増加が見られる 現時点ではフルルートの経路数の推移から見て、インターネットの経路数増大が主要な原因となる。 広告されていない物がすべて移転対象とするのであれば、どの程度の経路数が増えるのか、というのが予測出来るのではないかというコメント。 ---------- SDNのセキュリティ 石黒 邦宏氏 (株式会社ストラトスフィア), 永尾 禎啓氏 (株式会社ストラトスフィア), 大久保 修一氏 (さくらインターネット)---------- v4、NATを使うようになり、トラフィックなどが増えてきている。 1個のグローバルIPアドレスにしめるトラフィックが非常に増えてきているというのが現状。 経路分割していなかったところが、トラフィックエンジニアリング的に、経路を細かくしている。 現状の分割要因から比べると大きく増えるわけではないと思うが。 * 最近のDCネットワークの要因 1. コンピューティングリソースのプール化 2. プラットフォーム化 3. ディズアスタリカバリ ... * Why SDN? 従来のVLANを ベースとした物理ネットワークの限界 - VLAN, VLAN ID, FDB(MAC ADDR数) 数万台規模のノードをシームレスに扱え、柔軟で即時に構成変更可能なネットワークが望ましい * 今後の方向性は? L2 拡張 - trill, spb, pbb, evpn SDN - オーバレイ方式 - hop-by=hop openflow - その他 * オーバレイ方式は? トンネルを使うことにより、物理NWの負担を減らす。 ただし、SDN導入ですべて解決か? 答えはNO 実装上、運用上新たな課題が生じる可能性がある。 * SDNセキュリティー課題マップ 負荷、フロー数、バグ、VMからの攻撃。 負荷、外部からの攻撃 物理ネットワークからは見えなくなる ゲートウェイの冗長など。。。。 * 今日のお題 フローテーブルの爆発問題 フロー単位での制御は現実的? OpenvSwitch利用環境での弊社テナントの事例。 DDoSが発生したときなどフローテーブルがあふれるなど。。 hbstudyで。。。 * セキュリティーインシデント対応 物理ネットワークでは、カプセルされて中身が見えない。 仮想トポロジでは、刻一刻変化する 追跡が不可能になる こんなケースには? 仮想ネットワーク内での疎通障害 お客様申告→事業者側での調査は可能? 外部からのアタック受けた。 などなど。 * フローテーブルの爆発 OpenFlowスイッチのありそうな動作モデル 1. 仮想スイッチが道のパケットを受信 2. OpenFlowコントローラに問い合わせ 3. 転送先ポートをコントローラが計算 4. 仮想スイッチにフローを投入 - フロー= K2~L4ヘッダ情報 - 今後同じパケットを素早く処理するため フローテーブルの爆発 - DDoSやspoofing等で大量のパケットを投げ込まれた場合 - 投入するフローマッチング部が詳細(下位〜上位例やのヘッダフィールドまどでを広く)過ぎると - どれもこれも初見のパケット スイッチのフローテーブルに大量のエントリ投入 ↓ スイッチの性能低下 stratosphereの動作モデル 1. 仮想スイッチにあらかじめstaticなフローを登録 物理スイッチ相当の動作をルール化 2. 仮想スイッチがMACアドレス学習として、自立的にフロー追加(timeout付き) 3. OpenFlowコントローラへの転送はARP ブロードキャストなど少量のケースのみ 基本的にMACアドレス学習によるフロー追加のみ 投入するフローのマッチング部はL2ヘッダレベルまで ↓ VMにMACアドレス詐称を許さないフィルタをいれる運用ならそもそも爆発しない - 予備試験で100万フロー登録した状態でもスループットに目に見える影響は現れず - コントローラの負荷試験 コントローラが暇であれば、その分冗長構成での切替時の間余裕が出てくる ポイント 出来るだけフローを増やさない - staticなフローの活用 - 動的に塚する場合でも、あまり多くのヘッダフィールドをマッチ対象にしない - フィールドが多ければ、それだけフローのバリエーションが増える - アドレス詐称防止の導入を検討 - 流れるパケットに制限を加えることでバリエーションが抑制される。 static = mac routing * 某CDNで実験 NECのSWをつかっていた。 フローテーブルがあふれた。 80番でアクセスしてくるので、IPプロトコル17番だけを見よう (コメント: あれ?TCPは6じゃないのかな...聞き間違い?) など。爆発させないように。。。 * SDNでの障害検知の課題 仮想化に伴う障害検知の課題 - 物理レイヤーと仮想レイヤーのマッピング - ネットワークを記述するためのオブジェクトモデル 既存IP網とSD網両方を統一的に管理する必要がでてくる可能性がある - IP Prefix - MPLS - VLAN - Flow VXLAN等のトンネル - コネクションレストンネル - 自動学習すると時系列での設定が変化 物理ネットワークと論理ネットワーク - 障害児に物理と論理のマッピンの必要がある - VXLANの場合のコネクションレス - 3層APIモデル (Tenant AP Extension) テナントユーザ向け テナントネットワークの構築 Amazon EC2ライク 拡張API - Mapping API - (Provider API) 2時プロバイダ向け マルチテナント対応プロバイダネットワークの構築 QoS/TEを考慮 ゾーニング - Mapping API - (Infrastrucure API) クラウド/IDC事業者向け DCネットワークの構築 物理ホスト/ネットワーク設定 * 時系列での変化 VXLAN/NVGRE コネクションレストンネル 自動学習するケースもある 時系列でパケットフローが変化する 何時何分頃にどうなっていたか? 時系列でのネットワーク設定の再現 NetObjectsでのネットワークトポロジーの録画 * OpenFlow Controller スペック上は生TCPかTLS たいていPort6633番で待機 油断して生TCPでControllerを立ち上げていると... OenFlowを仕様したFabric Switch/Router bGP/OSPF/TRILL等の婦登呂凝るパケットをサーバへエスカレーション 生成されたFIB等をOpenFlowでCommodity Switchへインストール OpenFlow接続をハイジャックされると。。。 TLSで保護しましょう! ---------- パーシャルトランジットにより引き起こされる経路広告不良 篠宮 俊輔氏、大久保 修一氏 (さくらインターネット(株) 研究所) ---------- 篠宮 フリーの自称エンジニア 以前はCRL(現NICT)、東工大のNOCにいた 本発表では、どちらかというとエッジ側の支点 * パーシャルトランジット インターネット全体に到達性があるフルトランジットに対して、一部への到達性だけがあるトランジットサービス ISP自身が安価に調達性を調達できるネットワークの詰め合わせ販売のような感じ。比較的やすい ≒ドメスティック 本発表では、サービス利用者 * 経路広告のイメージ パーシャルトランジットに広告した経路は一部に届く 一部以外にはフルトランジットに広告した経路が届く * 経路広告の空白の出来る例 利用者ASはパーシャルトランジットにもフルにも同じprefixを広告。 いろいろとあるが、トランジットAS Tからその2への広告に注目。 * ASローカルなメカニズムでの原因 トランジットするASが経路広告しない(adj-RIBs-Outに載せない)のにベストパスとして選んだ → 広告する範囲の背mかうなる可能性の経路は、優先度を落とせば解決? * 利用者ASで出来る対応は? パーシャルにもフルにも同じprefixを流すから、流した経路情報がフルに流した経路情報をたたき落としてしまう。 パーシャルとフルに同じprefixを流さなければよい。 - フルには、/16 - パーシャルには /15*2 など 大久保さんのターン 入社したときには、パーシャルトランジットを当時の社長が売ってた。 フルトランジット お客様向けに全経路を広報 お客様の経路をすべてのピアに広報 パーシャルトランジット お客様向けにトランジット以外の経路のみ お客様の経路をトランジット以外のピア向けに広報 単価ちょっと休め。 DCのトラフィック傾向 フルトランジット local prefを優先 * まとめ 同一のお客様がフルとパーシャル両方を契約している場合の制御は難しい - %%結局フリーピアトラフィックもフルトランジットと課金も出来て、うちとはうはうは%% - お客様側でprefixを分割 → ただ乗り? - AS2516さんがうまく制御されていたけど、どうやっていたんだろう?? → NWを分割した - NO-EXPORTでの経路広告は副作用が強い - パーシャルトランジットは複雑。やめましょう? * お聞きしたいこと - パーシャルトランジット提供の事業者の肩、パーシャルトランジットがこういう問題をおこす可能性が あることをお客様に伝達されていますか? - または、このような問題を起こさないパーシャルトランジットだけを提供されていますか? ASを分けて、prefixを分割するしか、現実解がないのではないか?(kondou) ---------- JPIRR関連のお知らせと相談 角倉 教義氏 (JPNIC) ---------- JPIRRのこれまでの内容 2006/8/1から正式サービス開始、6年となった。 メンテナーオブジェクト数では第4位(世界) 2007/6 メンテナーオブジェクト登録数が100突破 2008/5/21 2012/7時点のオブジェクト登録数 mainter 220 route 5319 autnum 350 as-set 119 * JPIRRのこれから JPIRRをっつねに仕様されているユーザの皆様に対して、アンケートを実施させていただいた。 2011/12/12-22 212組織。 回答数57 JPIRRシステムについて: より安全性の高い登録・参照システムへの改善が必要か? 現状と同程度:66% 各組織でのJPIRRの参照度合いと関連性がある様子 現状以上の安定性を希望する回答 30% 現状以上の安定性を希望する背景としてJPIRRの障害の影響を受けたケースがあった その他、原則停止しないシステムを希望する意見が複数件見られた。 質問1:?? 質問2;登録情報のカバー率と削除漏れ対策 プロモーション活動の今日かや未更新のオブジェクト対策の改善が必要か? 現状と同程度 44%よりさらなる対策が必要、49% ガーベージコレクタの機能改善をを希望する意見 オブジェクトは削除しないでほしいという意見 カバー率向上に関して、いっそうの啓発活動を期待 質問3:経路ハイジャック通知実験について 経路ハイジャック情報通知実験について、通知内容の追加等、実験の改善が必要か? 現状維持で継続すべき 65% 氏式サービスか、英kぞくてきな取り組み絵の期待もあり 機能改善が必要という意見 26% ハイジャック元のoriginASの通知 ハイジャックから回復した際の通知 通知が届いた際の対応や実験のレポートが見たい JPNIC WEBやIWの資料として公開しているが.... * JPIRRサービス改善計画 アンケートで頂いた意見を踏まえ、JPIRRサービス改善計画を策定 目的:根付き始めたJPIRR活用手法の維持とさらなる普及、JPIRRの活用に高まった。 .... 書ききれず * 改善計画: システム面 単一障害点の解消 複数拠点化 冗長化 JPIRRシステムのハードウェア更新 * 改善計画:付加機能 オブジェクトの自動削除機能の改善 オブジェクト削除前通知内容、通知頻度の見直し オブジェクト削除前通知手段の追加 経路ハイジャック情報通知実験の維持・継続 * 改善計画:登録カバー率維持向上 実施項目 JPIRR登録に向けたプロモーション IRRに関する広報・周知活動 JPIRR登録状況 etc... その他将来に向けて JPIRRデータベースとWHOIS IPレジストリデータベースの統合など