━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1744【臨時号】2020.1.17 ◆
  _/ＮＩＣ
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
---------- PR --------------------------------------------------------
■■ IPv6 Summit in TSU 2020 & IPv6ハンズオンセミナー ＠三重県津市■■
□┏━━━━━━━━━━━━━━━━━━━━┓ 2月6日(木)/7日(金) □□
■┃1日目:座学セミナー & IPv6 Summit in TSU ┃ 主催:IAjapan/JPNIC ■■
□┃2日目:ハンズオンセミナー                ┗━━━━━━━━━┓□□
■┃→→ https://www.nic.ad.jp/ja/topics/2019/20191223-01.html  ┃■■
----------------------------------------------------------------------
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1744 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

vol.1738より、2019年11月下旬にシンガポールで開催された第106回IETFミー
ティングのレポートを、連載にてお届けしています。第3弾となる本号では、
DDoS対策のための技術を検討している、DOTS WGの動向をご紹介します。

次回の第4弾では、メールに関連した技術の動向を取り上げる予定です。ま
た、これまでに発行した全体会議およびトランスポートエリア関連のレポー
トについては、下記のURLからバックナンバーをご覧ください。

  □第106回IETF報告
    ○[第1弾] 全体会議報告 (vol.1738)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2020/vol1738.html
    ○[第2弾] トランスポートエリア関連報告
              ～Web Packing BoFとWebTransport BoF～ (vol.1739)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2020/vol1739.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第106回IETF報告 [第3弾]  DDoS対策(DOTS WG)関連報告
                                NTTコミュニケーションズ株式会社 西塚要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2019年11月16日(土)～22日(金)にシンガポールにて、第106回IETFミーティン
グ(以下、IETF 106)が開催されました。

本稿では、DDoS対策に関する標準プロトコル策定をめざす、DOTS WGの進捗を
報告します。


■ はじめに

筆者は、DDoS対策の組織間連携の自動化を実現するDOTS (DDoS Open Threat
Signaling)プロトコルの策定に、WG設立当初(2015年6月)より関わっていま
す。2019年7月に発行したJPNICニュースレター72号の「インターネット10分
講座」にて、「DOTS (DDoS Open Threat Signaling)とは」というタイトル
で、解説記事を書きました(*1)。今回は、基本仕様における最後の課題であ
るHeartbeatに関する話題と、DOTS Step2と呼ばれているテレメトリ情報のや
り取りについての話題をお届けします。

(*1) https://www.nic.ad.jp/ja/newsletter/No72/0800.html


■ DOTS基本仕様 RFC化への長い道のり

2019年の5月に、DOTSプロトコルに対する要求事項をまとめたドラフトが、
RFC8612として発行されました(*2)。

(*2) DDoS Open Threat Signaling (DOTS) Requirements
     https://tools.ietf.org/html/rfc8612

DOTS WGとして発行した、初めてのRFCになります。

これに続いて、基本仕様を定めた、

・draft-ietf-dots-signal-channel (DOTSシグナルチャンネル)
・draft-ietf-dots-data-channel (DOTSデータチャンネル)

の二つのドラフトが、RFC化間近となっています。

二つとも、2019年5月にIESG Evaluationのプロセスに進みました。しかし、
シグナルチャンネルについて、トランスポートエリアのエリアディレクター
から待ったがかかり、提出された議論点の解決に5月～11月の、半年もかかっ
た、という事情があります。

議論点は多岐にわたったのですが、もっとも解決に時間がかかったのが、シ
グナルチャンネルの死活をチェックする、Heartbeatの仕様でした。


■ Heartbeatに関する話題

エリアディレクターからの指摘は、CoAP (Constrained Application
Protocol)を使ったシグナルチャンネルの死活監視は、レイヤバイオレーショ
ンではないか、という内容でした。

確かにそれまでのDOTSの仕様では、DOTS over UDPでは"CoAP Ping"、DOTS
over TCPでも相当する"Ping and Pong"メカニズムを利用していました。既に
あるメカニズムを再利用したのは、車輪の再開発を避けるためです。

対して、DOTSプロトコルの想定しているDDoS攻撃が発生している状況では、
防御依頼と防御サービスの間の回線が攻撃で埋まっている可能性があります。
そのため、死活監視を元にその状況を判断して、DOTSサーバ側が防御を発動
するという動作も定められているのですが、その動作にCoAPの機能を無理や
り当てはめていた、という見方も確かにできるでしょう。

既存の仕様でも、我々が開発しているOSSのgo-dots(*3)と、NCC Groupによる
実装の両者で相互接続試験を重ね、十分に動作することがわかっているので、
最初は仕様変更には大変抵抗がありました。

(*3) https://github.com/nttdots/go-dots

しかし、この問題が解決しないことにはRFC化ができないということで、ドラ
フト著者と実装者の間で、Heartbeatの仕様をDOTS側に入れる(CoAPの
Heartbeatは使わない)、という結論に達しました。

以上の経緯を踏まえて、RFC化直前に大きな仕様変更を入れたというのが、
IETF 106までの進捗で一番大きなニュースです。

個人的にはこのような直前での仕様変更は、バグの温床になるので止めても
らいたいところですが、2019年12月中に新しい仕様に基づいての相互接続試
験を行い、無事動作することが確認されました。


■ DOTS Step2とは？

そもそもDOTS WGは、IPFIX WGの流れを一部くんでいます。DOTSが定めるDDoS
対策依頼は、「IPネットワークに関する情報の、information modelの定義
と、それを運ぶプロトコルを定義する」という、IPFIXの目的のDDoS対策特化
版と言うこともできなくはありません。

しかし、DDoS対策依頼をIPFIXプロトコルに載せなかったのは、DDoS攻撃を受
けている最中でもサバイブできるトランスポートを、別途仕様化する必要が
あったからです。あるいは、そのようにあえて判断した、という見方もある
かもしれません。

攻撃対策の依頼時に伝達する情報として、以下の2点が考えられます。

 1. 攻撃を受けているリソースに関する情報(IPアドレス、ポートなど)
 2. その他の付加情報(攻撃に関する情報など)

ここで、1について定義するのがDOTS Step1です。WGとして早く立ち上げる必
要があったため、スコープを絞った形となります。

2については、非常に時間がかかることが予想された領域です。攻撃に関する
information modelは、別のWG (I2NSF WG)と重複領域ですし、今後出てくる
であろう新しい攻撃手法について一つ一つモデルを定義していくのは、ベン
ダ間での共通化が非常に困難で、終わりのない作業になります。

なお、IETFにおけるセキュリティオートメーション技術(DOTS、I2NSF、MILE、
SACM WG)の概要については、こちらの会合の資料をご覧になることをおすす
めします(*4)。

(*4) https://www.isoc.jp/wiki.cgi?page=PreIETF94

しかし、現実のDDoS対策ベンダの装置は、2の領域も含めてシグナリングを
行っています。そのため、標準化プロトコルのDOTSとして、その他の付加情
報を運搬する領域に入ってきました。これがDOTS Step2です。

DOTS Step2の旗印となるのがこちらのWGドラフトです。

Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
(draft-ietf-dots-telemetry)

テレメトリ(telemetry)という名前ですが、いわゆるルータのtelemetryとは
異なる点をご注意ください。一般用語の遠隔測定という意味で、telemetryと
呼んでいます。

上記のdraftは、2016年に提出された以下の個人ドラフトを元にしています。
Step1へ集中するために一度意図的にExpireされました。

Distributed Denial-of-Service Open Threat Signaling (DOTS) Telemetry
Specifications(draft-doron-dots-telemetry)

主著者の所属からわかるように、元のドラフトはRadware社の、DDoS対策製品
の機能を色濃く反映したものになっています。他のDDoS対策サービス提供者
からすると、必ずしも使いやすい情報伝達内容ではないと感じており、一般
的に標準化可能なメトリクスがあるのかどうか、今後集中的に議論されると
思います。

なお、メトリクスを一般的にし過ぎる(帯域(bps)情報など)と、それらはIPFIX
で伝達すれば十分ということになり、DDoS対策だからこそ必要な情報、とい
うものの定義は難しいです。


■ 今後の展望

DOTS基本仕様のゴールが見えてきたため、WGのrecharter (WGの目的を述べた
チャーター文書を書きなおすこと)をすべきか、という議論もありました。主
に、上記のStep2の内容が、チャーター文書に入ってくると思います。

OSSとして開発している我々のgo-dotsは、リファレンス実装としての立場を
確立することができました。今後はRFC化を受けて、市場の製品の対応が増え
てくることを期待しています。

個人的には標準化のプロセスに深く関わることができて満足していますが、
市場での認知を高めて利用されることが本当のゴールであり、長い道のりの
まだ途中、といった心境です。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
      わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
                  ◇              ◇              ◇
            メールマガジン以外でも、情報を発信しています！
             JPNICブログ  https://blog.nic.ad.jp/
                 Twitter  https://twitter.com/JPNIC_info
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃ https://feedback.nic.ad.jp/1744/3978164a7112d2d2d7238d3ff898f869 ┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃ https://feedback.nic.ad.jp/1744/ee8eecdda959ae7c01b7efa6cec0cc2a ┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  JPNICの活動はJPNIC会員によって支えられています  ■■■■■
  :::::  会員リスト  ::::: https://www.nic.ad.jp/ja/member/list/
  :::: 会員専用サイト :::: https://www.nic.ad.jp/member/ (PASSWORD有)
□┓ ━━━  N e w s & V i e w s への会員広告無料掲載実施中 ━━━┏□
┗┛          お問い合わせは  jpnic-news@nic.ad.jp  まで          ┗┛
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
 JPNIC News & Views vol.1744 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先 jpnic-news@nic.ad.jp
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
   ◇ JPNIC Webにも掲載していますので、情報共有にご活用ください ◇
登録・削除・変更   https://www.nic.ad.jp/ja/mailmagazine/
バックナンバー     https://www.nic.ad.jp/ja/mailmagazine/backnumber/
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■     News & ViewsはRSS経由でも配信しています！    ■■■■■
::::: https://www.nic.ad.jp/ja/mailmagazine/backnumber/index.xml :::::
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣

■■◆                          ＠ Japan Network Information Center
■■◆                                     ＠  https://www.nic.ad.jp/
■■

Copyright(C), 2020 Japan Network Information Center