_JANOG41.pptx

Size: px

Start display at page:

Download "_JANOG41.pptx"

ありさおとべ
5 years ago
Views:

1 本でのオープンループ 2018/1/24 JANOG41 NTT コミュニケーションズ塚要

2 紹介 : l 塚要 ( にしづかかなめ ) l 2006 年 NTT コミュニケーションズ社 l OCN アクセス系ネットワークの設計に従事した後規模 ISP の運サービスを担当現在は研究開発組織にてトラフィック分析など ISP の課題に関する研究開発に従事 l メインフィールド l DDoS 対策 l トラフィック分析 l IPv4 枯渇対策関連技術 l 社外活動 l IETF DOTS WG (2015 年 ) l JPNIC IPv6 教育専家チーム

3 標準化のアンチパターン : l 標準化過程と利者との断絶 IETF: 私作る運者 : 僕使う l 標準化されたプロトコルを誰も使わないアンチパターン 1. ニーズがないプロトコルを作ってしまった 2. 不要かつ複雑怪奇な仕様で使いたくない 3. 利しにくい他のプロトコルに依存している利しにくい = 良いライブラリが無いなど 4. 時期を逸してしまった ( すでにプロプライエタリな実装でエコシステムが出来上がった ) 今のテーマ : どちらかといえば運出の私が IETF でどのような活動をしているかを紹介

4 IETF とは

5 IETF(Internet Engineering Task Force) : l インターネット技術の標準仕様 ( プロトコル ) を議論策定する団体 1986 年に IAB により設置 ML による議論を中とし年 3 回のミーティングを開催 l 代表的なプロトコル IP (RFC791), TCP (RFC793), FTP (RFC 956) l RFC (Request for Comments) による仕様公開現在,RFC8313 まで公開 l 特徴 Open な参加標準化過程標準仕様 Rough Consensus, Running Code を重視

6 IETF ミーティングの中 : 1000 から 1500 の IETF 参加者が集まるミーティング ( 約 1 週間 ) が年に 3 回開催される l 公式イベント : Working Group セッション ( 約 130 WG) Birds of a Feather (BoF) セッションエリア全体セッション IETF 全体ミーティングチュートリアル & ランチセッション Social Event IETF ハッカソン公開のビジネス会議 ( 例 : IAB, IESG, IAOC, NOMCOM) l 公式イベント : Bar BoF PechaKucha

7 IETF 参加者数 : IETF 会合参加登録者数の推移 IETF69 Chicago IETF70 Vancouver IETF71 Philadelphia IETF72 Dublin IETF73 Minneapolis IETF74 San Francisco IETF75 Stockholm IETF76 Hiroshima IETF77 Anaheim IETF78 Maastricht IETF79 Beijing IETF80 Prague IETF81 Quebec IETF82 Taipei IETF83 Paris IETF84 Vancouver IETF85 Atlanta IETF86 Orlando IETF87 Berlin IETF88 Vancouver IETF89 London IETF90 Toronto IETF91 Honolulu IETF92 Dallas IETF93 Prague IETF94 Yokohama IETF95 Buenos Aires IETF96 Berlin IETF97 Seoul IETF98 Chicago IETF99 Prague IETF100 Singapore 不参加リモートオンサイト国数

8 IETF 参加者数 ( 本 ): 日本からの参加登録者数の推移不参加リモートオンサイト国別順位

9 DOTS WG に関わるまでの経緯

10 初めてのインターネットドラフト (2013): l 総務省平成 24 年度 IPv4 アドレスの枯渇に伴う情報セキュリティ等の課題への対応に関する実証実験の請負実証実験の成果をドラフトにまとめて投稿 CGN 導における考慮事項をまとめたドラフト内容は評価されたがタイミングが悪かったため主的に Expire l Lessons Learned ドラフト投稿はやればできる内容が技術的な知にきちんと基づいていれば議論の場に乗せてくれる特にオペレータからの意は貴重とみなされる受けとなる WG を持つことが重要以降分の考えは IETF にドラフト投稿して作る側に回ってしまえばよいというマインドに

11 DOTS WG ち上がり (2015): l DOTS: DDoS Open Threat Signaling DDoS 対策を効率的に実現するために DDoS に関連した情報のリアルタイムでのシグナリングを標準化する IETF92 BoF IETF93 WG 化 l 最初はスコープも定まらない状況どのような情報をどのようにやり取りするかをこれから決める状況 l DDoS 対策システムの開発の知を活かしスコープを定めるところから議論にる

12 DOTS プロトコルとは

13 DOTS のスコープ : n 防御依頼と相互信頼 X 宛のパケットを落として Customer Customer 攻撃元に近い AS 攻撃先 AS Customer Customer 果たして相手の防御依頼は信頼できるだろうか? n パケットフィルタアウトソーシングとセキュリティオートメーションを相互信頼のもとで実現する技術として DOTS プロトコルが注されている

14 DOTS プロトコルの動作とメリット : l DOTS プロトコルの動作利者側の DOTS クライアントから提供者側の DOTS サーバに対して攻撃を受けている IP アドレスなどの情報とともに防御を依頼依頼を受けた DOTS サーバ側は認証および防御依頼のバリデーションを実施した上で DDoS 対策を実施 l DOTS プロトコルのメリット間を介さない防御受付のインタフェースが規定されることで DDoS 対策の動化が可能になる複数の対策事業者に対して共通のプロトコルで防御依頼をすることができるようになる別の対策事業者に防御依頼をするような事業者間連携を実現できる

15 DOTS WG での活動

16 DOTS WG での活動 (1/3): ドラフトの投稿 l 2015 年 12 : ユースケースドラフトを投稿 draft-nishizuka-dots-inter-domain-usecases WG アイテムのユースケースが組織間での防御依頼のユースケースをカバーしていなかったためスコープを広げるために投稿後に WG アイテムにマージ l 2016 年 2 : 伝達する情報のモデルのドラフトを投稿 draft-nishizuka-dots-inter-domain-mechanism 他の参加者との議論の結果内容を整理しシンプル化したものを再提出し WG ドラフト化 l 2016 年 10 : テレメトリ情報に関するドラフトに連名 draft-doron-dots-telemetry ベンダ (Radware 社 ) がメインで執筆

17 DOTS WG での活動 (2/3): リファレンス実装 l 2016 年 10 仕様を決めたドラフトの WG アイテム化に合わせてリファレンス実装となることを的とした開発を開始 l 2017 年 7 : OSS として公開 Go implementation of DOTS (go-dots)

18 DOTS WG での活動 (3/3): ハッカソンへの出場 l 2017 年 7 : OSS 公開に合わせて IETF99 ハッカソンに出場 2 間のハッカソンで go-dots の改良ドラフト版の仕様を実際に実装しプロトコルとして有効に動くことを証明 Best Name 賞を受賞 ( Waiting for go-dots ) 懇親会でデモブースをゲットしデモを実施 WG に仕様上の改修すべき点をフィードバック l 2017 年 11 : 相互接続試験のために IETF100 ハッカソンに出場 NCC グループのプロプライエタリ実装との相互接続試験異なる実装間でも通信ができ動作することを証明 Best Open Source Project 賞を受賞 WG に仕様上の改修すべき点をフィードバック

19 ハッカソンでの発表の様 :

20 DOTS WG での活動の的

21 なぜ標準化に参加する必要があったのか : WG への参加の的 1. 分の望む仕様を実現するため使えないプロトコルを座して待つより使いたいプロトコルを作る 2. 標準化のプロセスを早めるため待っているだけでは 2 年以上はかかるしかし DDoS 対策の事業者連携は今すぐにでも実現したい ( ビジネスとしての戦略 ) そのためにオペレータの視点で欲しいものを明らかにするリファレンス実装を作って実際に動くことを実証する

22 なぜ実装を OSS 化したのか : 最初から OSS 化を的として開発を始めるリファレンス実装となることを的としているためオープンなランニングコードを持つということ端的にいえば議論で勝てる WG への継続的なフィードバックによって分たちが使いやすい仕様に変えていくことができる

23 IETF ハッカソンに出場する意義 : l ハッカソン体が頭でっかち ( 議論重視 ) になっていた IETF を Running Code( 実装重視 ) にするための取り組み標準化前のプロトコルについて実装をすすめることができる場所を IETF が提供するオープンな場所で相互接続試験を試すことができる l WG での発表や懇親会でのデモなど数多くのアクティビティの機会を獲得できる IETF には数多くの WG があり実は他の WG の活動を把握できる機会は少ない

24 これから IETF を活動の選択肢のつとするあなたへ : l IETF における標準化の的を常に考えること標準化体が的ではない使えるプロトコルを早く世に出しそれが広く使われることが的社にとってのビジネスでのメリットをいつでも正しくえるように l どのようにして標準化を早めるかそして使えるものをにいれるかオープンループをまわすのが今のベストプラクティス l どのようにオープンループを回すのか実装をもつ OSS で公開するハッカソンに参加する

25 JANOG とオープンループ : こんな JANOG(er) だったらいいと思います l 運上の知を IETF にフィードバックしていく NANOG は定常的できている ( ループが回せている ) (grow WG, idr WG など ) JANOG ももっとできるのでは? l 運で使っている OSS ツールにガンガンコミットしていく例えば JANOG ハッカソンを開催する運技術にフォーカスしてツールの開発改良など

_IETF95report_dots.pptx

_IETF95report_dots.pptx IETF95 報告会 dots WG 2016.05.10 Kaname Nishizuka@NTT Communications 紹介 n 2006 年 NTT コミュニケーションズ社 n OCN アクセス系ネットワークの設計に従事した後規模 ISP 向けのトータル保守運サービスを担当 n 現在 DDoS 対策ソリューション関連技術および CGN 関連技術の開発と IETF 提案活動に従事