IETF99報告会
Hackathon & DOTS WG
2017.09.01
Kaname Nishizuka@NTT Communications@__kaname__⾃⼰紹介
n 2006年 NTTコミュニケーションズ⼊社
n OCNアクセス系ネットワークの設計に従事した後、⼤規模ISP向けのトータル保守運⽤サービスを担当
n メインフィールド• トラフィック分析• DDoS対策ソリューション
• IPv4枯渇対策関連技術
n IETF提案活動• DOTS WG
n JPNIC「IPv6教育専⾨家チーム」

2

IETFハッカソンとは

3

3

IETFハッカソン – イベントの定着
n 2015年 IETF 92 から開始
• 今回で8回⽬
n IETFミーティングの直前の2⽇間(⼟⽇)
n IETFで策定されているプロトコルについて実装を作ることが⽬的• "rough consensus and running code”
n 参加者やプロジェクト数は増加傾向• 参加者: 199名(初参加:89名)• プロジェクト数: 25

4

IETFハッカソン – 参加のメリット
n 参加者同⼠の議論の場• 興味のある⼈同⼠でグループが作られる
n 相互接続テストの場
n IETF参加者への露出• プロトコルやプロジェクトの知名度向上
n WGでの実装報告
n Bits-n-Bites(懇親会) でのデモ権の獲得
n Tシャツn 3⾷+間⾷ 完備• スポンサーは Cisco

5

IETFハッカソン – ⾵景

Running Code is King at IETF 99 in Prague
6

IETFハッカソン – 参加までの流れ
n MLをサブスクライブ• https://www.ietf.org/mailman/listinfo/
hackathonn 次回ハッカソンのページが出来上がる• https://ietf.org/hackathon/100-hackathon.html
n 参加登録• 参加者と興味のある分野のリストが閲覧可能
n Wikiに情報が集まり始める• https://www.ietf.org/registration/MeetingWiki/
wiki/100hackathon

7

IETFハッカソン – プロジェクトの主催参加の仕⽅は2つ
n 既存のプロジェクトに参加する• DNS, HTTP 2.0, NETVC, OpenDaylight, ONOS,VPP/FD.io, RiOT, SFC, TLS 1.3, WebRTC, YANG/
NETCONF/RESTCONF
n ⾃らプロジェクトを主催する=Champion になる• Wikiを編集して、プロジェクトを追加• MLにプロジェクトの簡単な紹介を流す

8

IETFハッカソン – 初⽇の動き
n 8:00 – 9:00 早めにきて、ポスターを準備する
n 9:00 なし崩し的になんとなく始まった雰囲気になる
n 9:30頃 キックオフ• 2⽇間のおおよその流れが説明される
n 〜21:00 ひたすら開発• ポスターを⾒て、興味を持って話しにきてくれる⼈の対応がちょくちょく⼊る

9

IETFハッカソン – 2⽇⽬の動き
n 9:00 開始
n 13:30 作業終了のアナウンス• プレゼンの準備をするように⾔われる• 資料は github にて収集
n 14:00 プレゼンテーション• プロジェクトあたり3分程度• ジャッジから質問される

ü 何⼈がプロジェクトに参加していたか
ü 実際にこの2⽇間で達成したことは何か
ü WGはどこで、標準化のステータスはどのくらいか

n 15:30 結果発表・表彰

10

発表の様⼦11

IETFハッカソン – IETF99 受賞プロジェクト
n Best New Work - HTTP error code 451
n Best University Work - Interface to Network
Security Functions (I2NSF) Frameworkn “NEAT”est Work - NEAT/TAPSn Best Interop Work – QUIC Interopn Best Continuing Work - SCHC implementation andtest SCTP
n Best Name - Waiting for go-dots
n Best Overall - SDN Apps for management ofmicrowave radio link via IETF YANG Data Model

12

IETFハッカソン – プロジェクト⼀部紹介
n Best New Work - HTTP error code 451• クローラ(js)とコレクタを作る• 451を返すWordpressプラグインを作る• 451を解釈するブラウザプラグインを作る

13

IETFハッカソン – プロジェクト⼀部紹介
n Best Interop Work – QUIC Interop• First Implementation の相互接続試験

14

IETFハッカソン – ⽇本からの現地参加
n MILE• Managed Incident Lightweight Exchange (MILE)の実装を⾏うü NICT:⾼橋健志⽒,鈴⽊未央⽒

n Best Name - Waiting for go-dots• DDoS Open Threat Signaling(DOTS) の実装を⾏うü 私と株式会社レピダム:岡⽥耕司⽒• ハッカソンに合わせて、PoC開発したソフトをOSSとして公開し、現地で改良• だ洒落で、ベストネーム賞をいただく…

IETFハッカソン – デモn ⽊曜⽇に開催される懇親会にてデモブースを持つ機会が得られる• スペースは限られているため、早いもの勝ち

IETF99@プラハ
DOTS 関連報告1717

dots WGn DDoS Open Threat Signaling (dots)n 設⽴：2015-06
n Chairs: Roman Danyliw(CERT)
Tobias Gondrom (OWASP, Huawei)n 新しいWG(BoF:IETF92 / Meeting:IETF93〜)
n DDoS対策を効率的に実現するために、DDoSに関連した情報のリアルタイムでのシグナリングを規格化する• ⾃動化• より⼤規模な防御システム• ベンダ独⾃なソリューションからの開放
18

DOTS プロトコルスタック
Signal Channel

Data Channel

アプリケーション
セキュリティ
トランスポート
目的

CoAP
TLS/DTLS
TCP/UDP(攻撃を受けているときに)防御を依頼するチャンネル

クライアント→サーバ

・防御依頼(開始/停止)
・攻撃を受けているIPアドレス・プレフィックス
・防御状況の確認

RESTCONFTLS
TCP(攻撃を受けていないときに)防御をセットアップするチャンネル
・ネットワーク情報の登録
・テレメトリ情報

サーバ→クライアント

・防御状況の報告

スタック

19

・テレメトリ情報

Interim Meeting – 6/8
n DOTS WGでは、IETFミーティングの約1ヶ⽉前に毎回 Interim
Meetingを実施• 次のIETFまでに何をすればいいのかが明確化される• ドキュメントの精査がこの間に進む
n Virtual Interim Meeting 6/8• Usecase Discussion• Requirements Discussion

ü Homenet Usecase の扱いの議論• Architecture Discussion
ü マルチホーム環境の議論• Service Discovery

ü CPEでどのようにDOTS Serverを⾒つけるか20

Design Team Meeting – 7/18
n DOTS WGでは、IETF期間中にデザインチームミーティングを少⼈数で開催
n デザインチームミーティング 7/18
n ユースケース関連• A社の著者が、ドラフトを⼀つ前の⽂⾯に revert したため紛糾• 読みやすさと、網羅性の両⽴が困難• 読者をナビゲートするような⽂⾯にすべきとなったが、果たして…
n プロトコル関連• ハッカソンで⾒つけた議論すべき点をフィードバック(後述)• 事前にこの場で説明することで、他のメンバに議論点の重要性を認識させることができたのが⾮常に有⽤だった
21

DOTS WG ミーティング – 7/20

22

ユースケースドラフト
n 前⽇のデザインチームミーティングを受け、直前で内容をマージして -07 として提出• 直前すぎて読んでいる⼈が少ないため、議論が深まらず• (戦術なのか、天然なのか)• github にも反映されておらずドキュメントの編集状況が不透明
n エリアディレクター(AD)からのマージ要請• ADとして、Informational な RFC を複数出したくないü 似た内容が含まれていたりして、読む⽅も編集する⽅も⼤変• リクワイヤメント/アーキテクチャドラフトとマージしては？
• これに対しては、2⼈のチェアが明確にNO！
ü それぞれのドラフトが独⾃の有益なコンテンツを含んでいるü これまでの経緯を重視
23

リクワイヤメントドラフトn 新しい参加者からの質問が増加• そもそもの前提のクラリフィケーションなど

ü クライアントからの情報と、サーバ側の判断どちらを優先するか
ü DOTSの仕様は後者• 参加者層や注⽬度が上がっている

n 今後• 引き続きイシューを受付中• 近⽇中に次のバーションに24アーキテクチャドラフト関連
n アーキテクチャドラフト(WGドラフト)• 内容も充実しており順調
n マルチホームアーキテクチャドラフト(New)• draft-boucadair-dots-multihoming• インタリムミーティングで議論が出て、マルチホーム環境について考慮(仕様への重要な改変)が必要かどうかを判断したい• 著者は、ありうるマルチホーム環境を列挙
ü しかし、微に⼊りすぎていている感あり• 結論としてマルチホーム環境にどのような問題があるかが不明瞭のため引き続き議論
ü 結果がでたら、WGドラフトに吸収されるべき(by Chair)25ハッカソンレポート
n ハッカソンでの実装結果と、気づきをフィードバック• 次ページからは発表資料26

Go implementa@on of DOTS
DOTS WG
2017.07.20
Kaname Nishizuka(NTTCommunica@ons)

We opened the code !!
• hPps://github.com/nPdots

What was developed in hackathon• made the code easy to be deployed in variousenvironments– made docker-compose ﬁles for each services– reﬁned conﬁgura@on part• clariﬁed the documents– for newcomers to this ﬁeld

Demos and Interests• made a demonstra@on of one user scenario– on a portable docker environment– triggering “blackhole rou@ng” from vic@m side

• aPracted 4 people and showed them demoWe do demo on Bits-n-Bites• Today: 19:15-21:15• Prosím, visit us on the site.

Demo: Go implementa@on of DOTS
Demo scenario:
Enabling DDoS Protec@on in an upstream network by DOTS protocol
DOTS is:• DDoS Open Threat Signaling• Automa@on and Standardiza@on of signaling for DDoS
protec@on• “ask for help!” from a vic@m to an upstream provider- inter-organiza@on / including authN and authX in
spec
What you can see in this demo:• A DOTS client sends a mi@ga@on request to a DOTS serverover DOTS signal channel.
• The DOTS server receives and validates the request, thenstarts mi@ga@on by kicking a blocker• In this demo, the blocker is a gobgp server which triggers“blackhole rou@ng” in a service operator's network
targetIP/portDOTS
ClienthPps://github.com/nPdots/go-dots

Signal Channel

Data Channel

Mi@ga@on Request Model

Service Provider’s Network

Signal Channel
Data Channel

1. send mi@ga@on request

DOTSServer
2. validate request

gobgp

4. Stop DDoS APack

3.enable blackhole rou@ng

Lessons Learned(1/3)
1. Need more descrip@on on speciﬁca@on ofmutual authen@ca@on– (D)TLS based-on client cer@ﬁcate• tend to use self-signed cer@ﬁca@on (in lab)
• how can we bind the (D)TLS channel and customer(mi@ga@on scope)• CN(or SNI) should be used? (it's not clearly
documented)– what else for mutual authen@ca@onLessons Learned(2/3)
2. S@ll searching for good RESTCONF library– As an alterna@ve, CoAP/DTLS can be used for datachannel– but we want to implement it on RESTCONF, if wecan.

Lessons Learned(3/3)
3. Zero heartbeat mode should be allowed– As a star@ng point of implementa@on in lab– Also there are several usecases (as discussed inthe last IETF mee@ng)– “MUST” in REQ.SIG-003 should be relaxed?

IANA considera@ons• need assignment for default port number– 4646/udp for signal channel (from dralmortensen-dots-over-udp)– 4647 for data channel?

implementa@on speciﬁc problems• Traﬃc data collec@on– traﬃc informa@on should be returned from DOTSservers• incoming traﬃc / blocked traﬃc / passed traﬃc– need addi@onal solware component to collect thosedata from network equipment or mi@ga@on boxes• very implementa@on speciﬁc but required• Par@ally valid request– When a mi@ga@on request includes valid scope andinvalid scope at the same @me, what is theappropriate behavior?
• reject all? / pass valid request only?

Next Step
• As an OSS,
– adopt to the various deployment scenario– keep going on the implementa@on of WG drals
and make feedback to the spec

• your feedback is welcomeJ

DOTS is geong popular!
• We’d like to do interoperability tes@ng at thenext hackathon in IETF100– signal channel interop will be the 1st step

次回IETF100に向けて
n 発表は⼤変好評
n zero heartbeat の件も、リクワイヤメントに反映
n チェアが会場に、次回以降 Interop あるとしたらやりたい⼈を聞く• 5⼈が挙⼿ü Arbor, Cisco, Huawei, Verisign, Checkpoint40その他のプロトコル関連ドラフト
n シグナル/データチャンネルドラフト(WGドラフト)• 順調
n サービスディスカバリ(New)• boucadair-dots-server-discovery• DHCPを提案

ü CPEのユースケースで使うのか？
ü サービスディスカバリ機能をMUSTとすべきではない、とフィードバック

n ipv6 signal option(New)• draft-francois-dots-ipv6-signal-option• WGドラフトが順調に進む中で、IPv6限定のチャンネルを提案(前は Hop-by-hop オプションの利⽤を提案)• 申し訳ないが筋が悪い
41

マイルストーン
n 2017年以内に現状のWGアイテムのラストコールを⽬指す• 下記のMilestoneは更新されていないが、11⽉がターゲットに設定されている

各WGアイテムは github にて管理: https://github.com/dotswg
42

まとめn ハッカソン出場の意義• WGでの発表や懇親会でのデモなど、数多くのアクティビティの機会をゲットできる• WGでの発⾔⼒を強化できる
n DOTSの進展• OSS実装の露出• 参加⼈数/層が増え、注⽬を集めつつある• 今後の Interop に向けて、複数の実装が出てくる⾒込み43