自律分散協調論 課題レビュー 第11回 村井純 課題 • 課題内容 – インターネットの理想と現実 ・DNS root server operation ・BGP operation(BGP routing) ・End to end model(Broadband Application) のうち2つを選び, 以下についてまとめなさい。 1) 要求の変化 2) 現状の問題点 - 自律分散協調, インターネットアーキテクチャの観点から 3)その問題に対する解決策 量は自由です。 – 57人中 2人が提出 加藤文彦さんのレポート • RootDNS – アメリカにほぼ全体重がのった現在のシステムは国際 政治的に問題になっている – アメリカに10、他に3あるがアメリカの10個が機能しな いと他の3つではインターネットを維持できない – ルートサーバを増やすことで対応 • 数が増えることでアルゴリズムも変化 • End-toEnd – 帯域格差の大きいネットワークが存在する – エンドノードはネットワークの状態がわからない – End-to-Endの一つ手前にアプリケーション の最適化を 行う機構を導入するのはどうか？ 丸山武さんのレポート • RootDNS – アメリカに完全に依存したシステム • テロなどがおこって遮断されたら、、、、、 rootDNSのオペレーション – 国家に所属しない衛星に組み込んだら？ • BGP Operation – ポリシなどはISP 間で交渉、人の手で作業 – 非営利団体にすべてをゆだねては？ 1 ルートネームサーバ • 理論上、最初に問い合わせがくるDNSサーバ – ルートネームサーバ＝RootDNS • インターネット上の名前空間 の頂点 – 13台のルートネームサーバで運用 • 規模性への配慮 – キャッシュによるパフォーマンスの向上 日本のルートネームサーバ • m.root-servers.net – Spec • PentiumIII 1GHz×2 • 256MB – そろそろきついので、現在新しく構築中 • Athlon XP 1800+ • 512MB – 実は全然すごいマシンではない ルートネームサーバ：ハードウェア • オペレーション方法 – リモートからではなくコンソールから • 環境 – 鉄格子による防衛と無停電電源装置 による熱 暴走防止 • 接続性 – レイヤー１から３までは異なった経路でイン ターネットへ接続 RootDNSのオペレーション(続き) • BINDのバージョン – 全てのRootDNS はBINDの最新版で動作している • オペレータの連絡先情報 – それぞれのRootDNS のオペレータは(ハードコピーで) 他のオペレータの連絡先情報をもっている – 安全なコミュニケーション を利用が前提 • 複数のレベルで人員を配置 – 複数のレベルでシステムを運用する仕組み RootDNSのオペレーション • バックアップ – それぞれのRootDNS はゾーンファイルのコピーを持つ • ハードウェア に冗長性を持たせる – 全てのRootDNS はハードウェアに冗長性を持たせる • Hot Spare（手動） – 機器を動作させたまま交換できる必要がある • Live Spare (自動) – 機器を自動的に切り替えられなければならない ゾーンファイル • RootDNSの持つゾーンファイルに対する追加、 変更、削除申請 – 必要事項をテンプレートに沿って記入 http://www.icann.org/icp/icp1.htm – [email protected]に記入したものを送る – IANAなどによる申請者の技術、政治的な状況の確 認 – DoC(米商務省)に承認されPGP暗号化された文章が IANAからVeriSignへと送られる – RootDNS への変更通知 – ゾーンファイル及びwhoisの変更準備 2 ゾーンファイル の配布 • 定義 – マスター ：配布元 • 一つのファイルによる情報供給 • 一つのデータベースから生成されるファイル – スレーブ ：マスターサーバの複製 • 変更箇所の検出 – プロトコルによる取得 (zone transfer と呼ぶ) • SOAレコード – シリアルナンバー – 定期的 な更新 – 通知 • TSIG(Transaction SIGnature)による保護 – ファイルによる取得 • PGPサインされたメールがあるアドレス群に届くことで通知 ゾーンファイルの分配 – マスター (cont) • FTPサーバを通した分配 – ftp://rs.internic.net/domains – • ftp://ftp.crsnic.net/domains (com/net/org のアカウントを持つ人向け) マスターとa.root-servers.netへの分配 – 信頼できるインターフェースへの分配 – データロード前 のセキュリティチェック • 信頼性 • 合法性 • ゾーン変更を行う間の複数台のマシン利用 • 継続的な通知リストへのメッセージ送信 – a.root-servers.netあるいはj.root-servers.netならば最小の停止時間 で行う オペレータ • 異なった性格、異なった組織、異なった種類 の組織、異なった ... • 強い社会ネットワーク • 暗号化されたコミュニケーションチャンネルの 確立 ゾーンファイル の定義：マスター • マスターファイル – 供給データベースによる生成 – 災害に備えた複製 • データベース • 分配プログラム • 別所へのバックアップファイル の保存 – 人の目による差分調査 – 鍵の調査 • SOAレコードのシリアルナン バー – 安全である要素 • ゾーンファイルを崩す • 一つ一つのファイルに対 するGnuPG (PGP) 署名 • Md5sumサイン – ステージングマシン へのイ ンストール • ログ確認 • DNSクエリー • データ供給中に変 更が生 じた 場合の代表者への連 絡 ゾーンファイル の分配 – スレーブ • 変更箇所の検出 • DNSプロトコルの使用 – メッセージの通知 – 継続的なチェックによる更新 • その他の方法 – PGPサインされたメール – Cronjob • 各ルートオペレータは正当性の確認に対する 責任がある テクニカルガイドライン • The Internet Engineering Task Force (IETF)の技 術開発に関する手続き – Domain Name System Operations working group. – Domain Name System Extensions working group. • ルートオペレータはRFC 2870をガイドラインとし て使用する – "Root Name Server Operational Requirements" – 新しいアイディアは次のバージョンのドキュメントの中 に盛り込まれる 3 現在の運用状況 • オペレーションを目的としたリモートから のアクセスを制限している • 運営場所は物理的に十分な防衛がなさ れている • 万一の場合に備えた防災計画 ICANNの規則 • 完全な変遷計画 – 新しいIANA規則に乗っ取ったセキュリティと 安定性 • MoUプロセス – Btwnルートサーバオペレータ • IANAファンクションのバックアップ • 信頼できるエンジニアとオペレータ ルートキャッシュを使った名前解決 ユーザ 1. root zone (root server) ・ 2. jp zone (ns.nic.ad.jp) jp .jp • 様々なUNIXを利用 – 7種類の異なるハードウェア – 8種類の異なるUNIX – 5種類の異なるベンダー • 地理的に分散 • 地元の時間で運用（GMT含む） www.sfc.keio.ac.jp ac.jp 3. ac.jp zone (ns.nic.ad.jp) 4. keio.ac.jp zone (ns0. keio.ad.jp) 5. sfc. keio.ac.jp zone (ns1.sfc.keio.ac.jp) ルートネームサーバ: 分散システム www.sfc. keio.ac.jp ac keio sfc k e io ローカル ネーム サーバ 133.27.4.212 p .ac.j web ブラウザ 133.27.4.212 sfc .k eio 13 .ac 3.2 .jp 7.4 .21 2 • ルートキャッシュ • 負荷分散 • akamai アクセスされる ネームサーバ 運用の工夫 ルート キャッシュ TCP IP すべてのCNAME を解決し てからA を聞く akamai • 負荷分散の仕組み • DNSキャッシュのコピーを複数台つくる • すべてのDNSクエリーをakamaiに送信する – akamaizer – 場所に応じて近いakamaiサーバに変更 • http://www.akamai.com/ 4 運用問題 • ルートサーバの数 – 米国以外の3台では機能しない • 攻撃のターゲットとなる • ルールに準拠しない/設定ミスのあるサーバ – repeated queries – microsoft – こわれたクエリー • IPv6 ルートサーバの数 • 米国10、その他3 • 米国の10個がつながらない場合、名前解 決は機能しない – アメリカに完全依存している • 丸山 武さんの答え – 国に属さない衛星にルートサーバを設置 DoSアタック • 普段は一秒5000-10000回のクエリーがくる • DoSアタック時は38000回を記録することが ある • RootDNSが機能しなくなる事はインター ネット全体が機能しなくなる事と同じ • 数が少なくあきらかなターゲットとなる ルール違反や設定ミス • Src.Portが0であるクエリー • RootのZoneを書き換えようとするクエリ – win2kは標準状態でDHCP でアドレス取得後 にルートサーバにDNSのアップデートを行おう とする – 日に120000件ほど来る事もある ルール違反や設定ミス • 壊れたクエリー – DNSサーバが理解できないクエリー • 全クエリーの14%にもおよぶ – IP アドレスからIP アドレスを聞こうとする • win2k、MacOSXは行うことがある • 設定ミス – プライベートアドレスのクエリー ルール違犯や設定ミス • Repeated queries – 通常キャッシュされて短期間に何回もクエリー が来る 事はない – しかし実際に何度も同じホストがしきりにクエリーを 送っている 4-minute trace 1M queries 8-minute 2M 1 hour 10-18M 2 hours 29M 62% repeats 69% 74% 85% • この様なルール違犯や設定ミスはサーバの負荷 になっている、なくならない 5 ルートネームサーバ とIPv6 • 将来的にインターネットはIPv6になる • DNSのIPv6対応とは、以下の異なる２つ 通信のIPv6対応 • ３種類の通信に関して対応が必要 権威サーバ – レコードのIPv6対応 ２．ネームサーバ間 の 問 い合 わせ ・ • AAAAレコード • ip6.int逆引きツリー ローカル ネーム サーバ jp – 通信のIPv6対応 ac ac クライアント １．クライアントからの 問 い合 わせ ３．ゾーン転送 IPv4/IPv6 • 移行・過渡期の問題 – すべてのホストがIPv6で通信できるわけではない – 移行末期では、すべてのホストがIPv4で通信できるわけではなく なると予想される – ネームサーバは、世界中のあらゆるホストと通信ができなければ いけない ルートへのAAAAの登録 • ルートネームサーバは１３個 – サーバ１つにつきNSとAが１個づつ • パケットサイズの制限 – 上限：512バイト 現在：444バイト 残り：68バイト • レコードごとのサイズ – NS:15バイト A:16byte AAAA:28バイト → ネームサーバは両方のサービスが必要 – – – – IPv4/IPv6両方の到達性 ソフトウェアのIPv4/IPv6両対応(OS/サーバ実装） AAAAとAの両方を登録 いつv4をなくして良いかは難しい問題 • 選択肢としては….. – IPv4ルートネームサーバは現在のまま • 現存ルートネームサーバのうち２つを両対応に • 両対応のネームサーバを１つ追加 – IPv4ルートネームサーバを減らす – 512byte 以上使えるように拡張する（EDNS*) BGPとは BGP Operation • Border Gateway Protocol • AS間の経路交換に用いられる – IBGP AS内でBGP の経路を伝播 – EBGP AS間 • 通常BGP4を利用 – 基本的に手動 6 ポリシールーティング • BGP によって実現 • AS ごとのポリシーにしたがったルーティン グ – どの AS に経路を広告するか – 他の AS の経路も広告するか – 他 AS からの通信をTransit するか ポリシとコンフィグのブラックホール • 通常経路集約でプリフィックス数を減らす • ポリシにより長いプリフィックスの経路をア ナウンスしたい必要もある • 場合によっては最適な経路が利用されなく なる、ブラックホールが発生する BGP Operationで起こる問題 • • • • ポリシとコンフィグのブラックホール フラップとダンプイング ネクストホップアドレスの解決 経路情報の変更 フラップとダンピング • 転送されてくる 経路情報のなかには安定しない ものもある – 属性が変化する – 消える、など • 経路情報を交換するパケットが大量に発生 • ルータのCPUリソースを消費 • インターネット全体に影響をおこぼしかねない ネクストホップアドレスの解決 経路情報の変更 • 管理者はIGPにおけるネクストホップとEGP におけるそれとの 違いを意識しなければな らない • 経路情報の属性値などを変更した場合に 経路情報を読み込みなおす必要がある • ピアをはった先と一度TCPのコネクションを 切る必要がある – IGP ではとなりの ホスト – BGP では • EBGP----ピア接続された隣接ルータ • IBGP---- 外部ASから学習したEBGP のネクストホッ プ – 対策としてルータ内のメモリーにキャッシュす る方法がとられるようになった – さらに最近ではTCP セッションを維持したまま 経路情報を読み直す機能もついた 7 パケット交換方式 – データを小包（パケット）に小 分けにして転 送 – データグラム End-to-End End-To-Endモデル • エンドシステムが頑張る – エンドシステムは雲の中(ネットワーク)がどうなってる かを知らなくてもよい ベストエフォート • 中継システムは、データを“なるべく”努力 して転送しようとする – インターネットでは、データが必ず相手に届く 保証はない 自律分散協調 • 中継システムの役目(IP) – ベストエフォート(best effort) – データを「 なるべく努力」し て転送 • エンドシステムの役目(TCP/IP) – 自分で責任をもってデータを転送 相手に確認を取る もう一度送り直す ペースダウンする データを小さく分ける End-toEndですべて解決か？ • 過去、相手までデータが送れる事が重要 だった • 現在ではQoSへの要求が高まってきてい る 8 QoS への要求 • 90 年代に入ってインターネットが爆発的に普及 – 最初はパケットが宛先まで届けばよかった • リアルタイムアプリケーション の要求 – 音声、動画通信 • ビジネス向けの高品質サービスの要求 – インターネットを使ったビジネス • 電話網に匹敵するQ o S の要求 – 電話網とIP 網の逆転現象 何故必要とされたか？くだいて • 110番パケットは落ちて欲しくない • 119番パケットは落ちて欲しくない • 金払っている奴のパケットはそれなりの 待 遇して欲しい、かも知れない • えらい人のパケットはそれなりの 待遇して 欲しい、かも知れない • データ通信量が音声通信量を追い抜く現実 – 従来：電話網上にIP ネットワークを構築 – 今後：IP ネットワーク上に電話網を構築 インターネットQoS とは？ • 定量的に表現できる通信品質 – 帯域、遅延、ジッタ、パケット損失率 • 必要なだけの保証された帯域 (bandwidth) • 少ない遅延 (delay) – 現状での限界は光の速さぐらい • 小さいジッタ(jitter) – ジッタ：遅延のばらつき、ゆらぎ • パケットロス率 ようは。。。。 • インターネットは様々なトラフィックが流れ ているのが特徴 • それぞれが譲り合いながら通信をしている • それなので、インターネットとQoSというの は、実は相反するアーキテクチャな面もあ る – QoS系は、特定のトラフィックを優先する – 特定のトラフィックの優先は、他のトラフィック の犠牲により成り立つ インターネットでのパケット転送 • Shared Network – みんなで共有 – 色々なトラフィックが流れている • Shared Bandwidth – 限られた帯域をみんなで使う – 90％以上がTCP • 譲り合いの精神（ TCP） では、QoSを実現するには？ • 回線を太くする – RFC1633(Intserv)での反論(1994年) • 帯域をじゃぶじゃぶ使うというのが最も安価な解法 になるとは 考えにくい • どこもかしこもじゃぶじゃぶになるとは考えにくい • 優先制御をする – Intserv、Diffserv、その他の考え方 • この後に紹介 9 QoSは優先制御によって実現さ れる • 複数のコンポーネントの組み合わせ Intserv（Integrated Services） • • • • RFC1633（1994年） 帯域予約を行って,QoSを実現しよう Flow毎に予約を行う 各ルータはそれぞれのFlowの状態（ state） を見続ける • 予約されているフローには、優先制御を行 う – アドミション制御 • 動的な資源配分(帯域など)の判断 – クラシファイア (classifier) • 到着パケットを対応するグループに分ける機構 – シェーピング(shaping)／ポリシング(policing) • バーストを一定のレートにならす • 規定以上の入力がないか監視 – パケット・スケジューラ(packet scheduler) • 各グループに応じたパケットの送出 – バッファ管理 RSVP （Resource reSerVation Protocol） • Intserv 的な予約をルータに対して予約して回る プロトコル • Intserv パラメータをルータに配るプロトコル • Intservと同時ぐらいに提案されて出てきた RSVP SRC • ある送信アドレスからある受信アドレスまでの経 路に沿って予約をして行く • フロー • 受信者が予約要求 を出す DST RSVP RSVP SRC RSVP対応ルータ：R SRC FLOW RSVP PATH M S G RSVP_HOP:R1 RSVP_HOP:SRC DST:DST DST R1 DST R2 10 RSVP RSVP RSVP対応ルータ：R SRC RSVP対応ルータ：R SRC RSVP PATH M S G RSVP_HOP:R1 DST:DST RSVP PATH M S G R1 R1 DST RSVP_HOP:R2 RSVP_HOP:R1 DST:DST R2 RSVP DST R2 RSVP RSVP対応ルータ：R SRC RSVP対応ルータ：R SRC RSVP PATH M S G R1 RSVP RSV M S G R1 DST RSVP_HOP:R2 DST:DST DST:R2 R2 R2 予約 RSVP RSVP RSVP対応ルータ：R SRC RSVP対応ルータ：R SRC RSVP RSV M S G DST:R１ DST:R2 RSVP RSV M S G R1 予約 R2 R1 R2 11 RSVP は,何故,受信者ベース か？ マルチキャストの時の RSVP PATHメッセージ • RSVPは、マルチキャストを前提としている • マルチキャストフローの送信者がPATHメッ セージを出す • 受信者が必要に応じてRESVメッセージを 出す SRC RSVP対応ルータ：R R1 R2 Diffserv (Differentiated Services) Intserv問題点 • 各フローの状態（state）を持たなくてはならな い – ルータで管理する情報が膨大になる – トラフィックが大量にあると破綻する – ポリシ制御が明確でなかった • • • • 誰が予約して良いか どれぐらいまで予約してよいか 最近になって、やっとCOPSというのが標準になった でも、まだ実用的ではない面もある • Intservの問題点を解決した手法 – ルータで持たなくてはならない状態（state）を大 幅に集約（aggregate） • IPパケットヘッダのTOSフィールドを使う – TOS → DS field に改名 – DSCP(DS Code Point) – PHB（Per Hop Behavior） DSCP – ポリシ記述方法など 0 IntservとDiffservの差（簡易版） Intserv Diffserv 様々なフィールド を見てフローを識別 フロー毎にSTATEを持つ バックボーンルータではつらそう DSCPだけを見てフローを識別 PHB毎にSTATEを持つ バックボーンルータではIntserv より楽 7 DSCP のマーク方法 DSドメイン Classifier Marker DSCP見るだけ EDGE CORE Classifier Marker CORE EDGE CORE 12 現在、決まっているPHB • あるレートのトラフィックを実現しましょう • EF（Expedited Forwarding） – Virtual Leased Line – 101110ｂ を使うことがRECOMMENDED • AF（ Assured Forwarding） – PHB Group – 青、黄色、赤 – 4 class がある（詳しい説明は後ほど） EF, それだけだとわかりにくいので,,, • バーチャルな専用線を提供する感じ – 専用線内のトラフィックが少なければスカスカ 通る – 専用線にトラフィックを流しすぎるとパケットが 落ちる EF 普通 普通 普通 普通 EF（Expedited Forwarding） 優先Queueに入り、 先に出る AF実際 • パケットロス率 – 赤＞黄色＞青 • どうやってやるか？ – RFCでは、REDを使うとできると書いてある – RED(Random Early Detection) – 他のトラフィックが大量にあっても大丈夫 にし ましょう • でも、サービスの与えすぎには注意しま しょう • EF PHB のDSCPは、101110b を使いま しょう AF(Assured Forwarding) • AF1、AF2、AF3 、AF4の AF class が用意されている – 各クラス内のフローは、赤、黄色、青に分けられる • 赤、黄色、青 – 青パケットは落ちにくい – 黄色パケットは青より落ちやすい – 赤パケットはもっと落ちやすい – 本当は、赤、黄色、青と分かれているわけではなくて、AF class 1 の1番、2番、3番という風に書かれている RED（Random Early Detection） • ルータでの queue length の平均値を計算しつ づける • Random にパケットを落とす • 平均 queue length が長くなるほどパケットを捨て る確率が増加する • RED – QUEUEにパケットが溜まってきたらパケットを捨て る – パケットを捨てると,TCP が出す量を減らしてくれる Avg Queue length Max thresh Min thresh 0% 100% パケット捨てる率 13 今週の課題 • SFCが慶應義塾大学から独立した場合、どのよ うなことが起こるか説明してください。また独立す ることによる利点、欠点について述べてください。 • 字数 800字程度 • SoIのシステムを使って提出 • 締め切り – 7/7(日)23:59 14
© Copyright 2024 Paperzz
