JPNIC News & Views vol.1429【臨時号】第96回IETF報告 [第4弾] セキュリティ関連報告(1) ～DDoS対策技術についてDOTS WGを中心に～

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
    __
    /Ｐ▲        ◆ JPNIC News & Views vol.1429【臨時号】2016.8.26 ◆
  _/ＮＩＣ
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ News & Views vol.1429 です
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2016年7月17日(日)から22日(金)にかけて、ドイツ・ベルリンにて開催された、
第96回IETFミーティングの様子を、連載にてお届けしています。第4弾の本号
では、セキュリティ関連報告(1)として、DDoS対策を取り上げます。

連載の最終回となる次号では、引き続きセキュリティ関連報告(2)として、
OAuthやTLSについて取り上げる予定です。今までに発行した号は下記のURLか
らバックナンバーをご覧ください。

  □第96回IETF報告

    ○[第1弾] 全体会議報告 (vol.1426)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1426.html

    ○[第2弾] IPv6関連WG報告 (vol.1427)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1427.html

    ○[第3弾] DNS関連WG報告 (vol.1428)
    https://www.nic.ad.jp/ja/mailmagazine/backnumber/2016/vol1428.html

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
◆ 第96回IETF報告 [第4弾] セキュリティ関連報告(1)
   ～DDoS対策技術についてDOTS WGを中心に～
                                NTTコミュニケーションズ株式会社 西塚要
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

2016年7月17日(日)～22日(金)にドイツのベルリンにて、第96回IETFが開催さ
れました。本稿では、DDoS対策に関するプロトコル策定をめざすDOTSワーキ
ンググループ(WG)を中心として、セキュリティオートメーションとしてのDDoS
対策の概要を報告いたします。

■ はじめに

近年、DDoS攻撃が規模の面でも頻度の面でも増加しています。例えば、
Cloudflare社のレポート(*1)によると、2013年には300Gbpsを超えるDNSリフ
レクター攻撃が観測されました。これは、攻撃対象のシステムのキャパシティ
を超えるような攻撃パケットを送りつけて、サービス不能にすることを意図
しています。このような大規模化の傾向が続けば、攻撃を受けている組織単
体で防御することが、ほとんど不可能になります。また、Akamai社のレポー
ト(2016 Q1)(*2)によると、DDoS攻撃数は過去最多を記録し、前年と比較して
2倍以上も増加しました。

(*1) https://blog.cloudflare.com/the-ddos-that-knocked-spamhaus-offline-and-ho/
(*2) https://content.akamai.com/PG6298-SOTI-Security.html

DDoS対策を施すことが、すべての組織について喫緊の課題となっている一方、
いつ自組織に来るかわからない攻撃に対して大規模な防御システムを構築す
ることが、コスト的にどんどん見合わなくなってしまっています。

このような状況に対して、DDoS防御システムを複数組織でシェアすることが、
一つの解決策になるかもしれません。複数組織がそれぞれに持つDDoS防御シ
ステムをシェアすることで、対策可能なトータルの容量を増やすことができ
ます。

またその際には、「攻撃検知」「防御依頼」「防御実行」といった、一連の
流れを自動化することが重要です。従来のDDoS防御依頼は、電話やメールな
どでやりとりされているケースが多く、非常に時間がかかってしまい、スケー
ルしないという問題があります。DDoS防御依頼の方法を自動化することで、
組織を超えた連携であっても、防御実行までの所要時間を短くすることが可
能となります。

DDoS防御システムの複数組織での連携については、実現するまでにたくさん
の困難があると思いますが、IETF DOTS WG (DDoS Open Threat Signaling WG)
におけるプロトコル策定が、解決のための一つのパーツになるかもしれませ
ん。そこで、筆者が活動をしているDOTS WGについて、最近のIETFにおける動
向を紹介いたします。


■ DOTS WG (DDoS Open Threat Signaling WG, セキュリティエリア)概要

DOTS WGは、2015年6月に設立された、IETFの中でも比較的新しいWGです。DDoS
対策を効率的に実現するために、DDoS対策に関連した情報をリアルタイムに
シグナリングする、プロトコルの策定を目的としています。

現在は、

 - ユースケースドラフト
   https://datatracker.ietf.org/doc/draft-ietf-DOTS-use-cases/
 - リクワイヤメントドラフト
   https://datatracker.ietf.org/doc/draft-ietf-DOTS-requirements/
 - アーキテクチャドラフト
   https://datatracker.ietf.org/doc/draft-ietf-DOTS-architecture/

の三つが、WGドラフトとなっています。

以降では、現在のドラフトを元に、プロトコルの中身について説明します。

○DOTSプロトコルのスコープ

DOTS WGが策定を進めている、DOTSプロトコルがターゲットとしているのは、
「このエンティティ(宛先IPアドレス)に対する攻撃を(何らかの方法で)防御
して欲しい」という依頼を、攻撃を受けている側から、防御をする側に通知
する仕組みです。また、防御をする側から攻撃を受けている側に、防御状況
を連絡する仕組みも合わせて必要です。

DDoS攻撃をどのように検知するか(ユーザー申告、flow技術、シグネチャベー
スなど)といった、検知手法は議論の対象外です。また、防御手法(緩和装置、
Blackholing、Access Listなど)の標準化も対象外です。

検知手法や防御手法の標準化となると、非常に時間を要することは明白です
ので、防御依頼(=request for help)にだけ特化することでスコープを狭くし
て、より早くプロトコルを策定したいというのが、参加者のラフコンセンサ
スとなっています。


■ DOTSプロトコル概説

○DOTSクライアント/サーバ

DOTSプロトコルは、DOTSクライアントとDOTSサーバの、二つのコンポーネン
ト間のプロトコルです。下図に基本的なDOTSのアーキテクチャを示します。

      +-----------+            +-------------+
      | Mitigator | ~~~~~~~~~~ | DOTS Server |
      +-----------+            +-------------+
                                      |
                                      |
                                      |
      +---------------+        +-------------+
      | Attack Target | ~~~~~~ | DOTS Client |
      +---------------+        +-------------+
       図: 基本的なDOTS アーキテクチャ


1. DDoS攻撃を受けたAttack Target(攻撃対象)は、何らかの方法でDOTSクラ
   イアントに検知情報を伝達します。繰り返しになりますが、検知に関する
   やりとりはプロトコル策定の対象外です。

2. DOTSクライアントはDOTSサーバに、攻撃対象のIPアドレスを基本情報とし
   た防御依頼を、DOTSプロトコルを利用して伝達します。

3. DOTSサーバは、Mitigator(緩和装置)に実際の防御を指示します。ただし、
   防御手法についてはプロトコル策定の対象外です。

より詳しい各コンポーネントの役割については、アーキテクチャドラフトに
まとめられています。

○シグナリングチャンネル / データチャンネル

DOTSクライアントとDOTSサーバの間には、シグナリングチャンネルとデータ
チャンネルの、二つのチャンネルが想定されています。

・シグナリングチャンネルは、実際に攻撃が発生しているときに利用される
  チャンネルです。攻撃を受けているときには、DOTSサーバからDOTSクライ
  アント方向のリンクが攻撃で輻輳していることが想定されるため、レジリ
  エンシー(回復力)やロバスト性(堅牢性)が要求されます。

・データチャンネルは、平時に利用されるチャンネルです。防御内容に関す
  る付加情報が、やりとりされることが想定されています。

これらのチャンネルに対する要求条件は、リクワイヤメントドラフトにまと
められています。

○DOTSユースケース

・intra-domain / inter-domain

  DOTSクライアントとDOTSサーバが、同一ドメイン(同一組織)にある場合を
  intra-domain、別ドメイン(別組織)にある場合をinter-domainと分類して
  います。

・customer-to-provider / provider-to-provider

  inter-domainの場合を、さらに二つに分類しています。

  1. customer-to-provider(c2p)は、顧客からDDoS対策を提供する事業者へ
     シグナリングするケースです。
  2. provider-to-provider(p2p)は、DDoS対策を提供する事業者が、さらに
     他の事業者へシグナリングするケースです。

c2pとp2pのどちらのケースであっても、DOTSクライアントとDOTSサーバの関
係は本質的には同一と考えられており、プロトコルとしてはどちらのユース
ケースもカバーする、統一的なものが策定される予定です。

これらのユースケースは、次の版のユースケースドラフトにて、整理した上
で記述される予定です。


■ IETF 96における議論

DOTS WGが立ち上がった当初は、DOTSプロトコルのスコープや目的について参
加者の間で見解がバラバラでしたが、メーリングリスト上でもIETFミーティ
ングでも議論が活発だったおかげで、約1年かけてようやくまとまってきまし
た。

○中間ミーティング(Interim Meeting)

今回のIETF 96ベルリンの開催に先駆けて、2016年6月21日(火)にオンライン
の中間ミーティングが開催されました。約20名が参加し、WGアイテムの進捗
が確認されました。WGアイテムとしてのユースケースドラフトの他に、私個
人によるユースケースのドラフトがあったため、両者をマージする形でのユー
スケースの整理を行いました。

○IETF 96ミーティング

・デザインチームミーティング

  IETF 96期間中の7月18日(月)に、三つのWGドラフトの著者が集められ、デ
  ザインチームミーティングが実施されました。三つのドラフトにはオーバー
  ラップ部分が多く存在しているため、次の版に向けて、お互いを矛盾なく
  参照するための整理が行われました。

・DOTS WGミーティング

  7月19日(火)にDOTS WGミーティングが開催されました。100名近くが出席
  し、非常に活発でした。WGドラフトについては、前日のデザインチームミー
  ティングの成果があったため、スムーズに進行しました。DOTSプロトコル
  の仕様、特にトランスポートとデータモデルについて多く議論されました。

・実装者ミーティング

  翌7月20日(水)に、前日のWGミーティングを受けて、実装予定があるメン
  バーでプロトコル仕様の議論を継続して行いました。チェアは、実装同士
  での相互接続試験を早期に行いたい旨を発言しましたが、実装者同士とし
  ては、プロトコル仕様が複数提案されており、まだ一つに固まりきってい
  ないため、実装の前にまずは相互で整理して統一的な仕様を文章化すべき、
  ということで意見の一致を見ました。

○今後のスケジュールについて

2016年9月末に、再びオンラインの中間ミーティングが開催予定となってお
り、今はそれに向けて参加者同士で相談しながら、プロトコル仕様に関する
ドラフトを書いている最中です。2016年11月に、現在の三つのWGドラフト、
2017年3月にプロトコル仕様(トランスポートとデータモデル)のドラフトのWG
ラストコールを行うというのが、現在のマイルストーンとなっています。


■ 最後に

今回は、DOTS WGについて初めての紹介ということで、DOTSプロトコルの概要
について駆け足で記述いたしました。興味があれば、DOTS WGでの取り組みが
将来のDDoS対策にどのように活かせるかについて、ご意見をいただければ幸
いです。


     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～
       わからない用語については、【JPNIC用語集】をご参照ください。
             https://www.nic.ad.jp/ja/tech/glossary.html
     ～～～～～～～～～～～～～～～～～～～～～～～～～～～～～～

┏━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
┃     ◆◇◆◇◆   本号のご感想をお聞かせください   ◆◇◆◇◆     ┃
┃良かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1429/a8eff37402bf3b978b2ec548350d5405┃
┃                                                                  ┃
┃悪かった                                                          ┃
┃→ http://feedback.nic.ad.jp/1429/e1e600b5d3bb129844d0b976656e76da┃
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
■■■■■  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.1429 【臨時号】

 ＠ 発行  一般社団法人 日本ネットワークインフォメーションセンター
          101-0047 東京都千代田区内神田3-6-2 アーバンネット神田ビル4F
 ＠ 問い合わせ先  jpnic-news@nic.ad.jp
＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿
            本メールを転載・複製・再配布・引用される際には
        https://www.nic.ad.jp/ja/copyright.html をご確認ください
￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
登録・削除・変更   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), 2016 Japan Network Information Center
このページを評価してください
