第107回IETF Meeting報告

2020年3月23日から27日にかけて、第107回IETF Meeting（以下、IETF 107）が、完全オンライン会合として開催されました。

IETF 107は、当初カナダのバンクーバーで開催される予定でしたが、新型コロナウイルス感染症の拡大が国際的な緊急事態となったことを受け、2020年3月10日に対面での会合の中止と、完全オンライン会合への変更が発表されました[*1]。

IETFの本会合が完全オンラインの形式となるのは、IETF史上初のことでした。また、後述するように従来から活動しているDNS関連WGは会期中には開催されないこととなるなど、通常とは異なるアジェンダでの開催となりました。

今回のFROM JPRS増刊号では、完全オンラインとなった会合の開催に関する話題と、DNS関連として創設後初の会合となったadd WGにおける話題についてお伝えします。

• 完全オンライン会合の開催に関する話題
  - 代替アジェンダへの変更とWG Meetingの開催状況
  - 参加者サポートと利用されたツール
  - 本会合におけるハイライトの公開
• add WGにおける話題
  - 議論された提案の内容と標準化作業の進行状況
• 次回のIETF Meetingについて

▼代替アジェンダへの変更とWG Meetingの開催状況

対面での会合の中止が発表されてから2日後の2020年3月12日、完全オンライン会合への変更に伴う代替アジェンダが公開されました[*2]。

今回の代替アジェンダは、以下の方針で作成されました。

• より多くのタイムゾーンに対応するため、コンパクトなスケジュールとする
• BoFと、創立後に初めて会合を開催するWGのセッションを優先する
• 議論するWGが決まっていない提案の取り扱い先WGや、取り扱い方を決めるミーティングの開催を優先する

その結果、当初開催予定であったdnsop、dprive、dnssdといった従来から活動しているDNS関連WGは、IETF 107の会期中には開催されないこととなりました。既存のWGの会合はIETF 107の終了後、4月末までに完全オンラインの中間会合として、順次開催されています[*3][*4]。

▼参加者サポートと利用されたツール

完全オンラインとなったことを受け、IETF 107では通常のIETF会合のリモート参加とは異なるツールや、これまでとは異なる使われ方をしたツールがありました。そのため、会議を円滑に進めるためのガイドが作成され[*5]、本会合の開催前に、テストのためのセッションが設けられました[*6]。

今回の会合では、発表と質疑応答には通常のMeetecho[*7]に代えてWebex[*8]が使われました。参加者間のチャットには通常と同じJabber[*9]が、参加者の記録と議事録の作成にはEtherpad[*10]が使われました。Etherpadはこれまでも議事録の作成に使われていましたが、今回、誰が会議に参加していたかの記録（対面での会合で回覧される「ブルーシート」）の役割も付加されました。

Webexを使った質疑応答は、以下の手順で進められました。

• 質問の列に並びたい参加者が、Webexのチャット画面に「+q」と記入する
• 列に並んだ後に質問をやめたくなった参加者は、Webexのチャット画面に「-q」と記入する
• チェアが列を管理し、質問者を指名する
• 指名された質問者が、質問する

発表と質疑応答は録画され、IETF公式サイトで公開されています[*11]。

Webexの参加者リストとEtherpadのブルーシートの記録によると、IETF 107全体の参加者の推測値は701人で、少なくとも39カ国からの参加が観測されたとのことでした。

▼本会合におけるハイライトの公開

開催後の2020年4月3日、IETFチェアからIETF 107の開催状況をまとめたハイライトが公開されました[*12]。ハイライトでは今回の完全オンライン会合について、

• 準備・計画時間が短かったにも関わらず、全体として円滑に進行した
• Webexによるオンライン会議は安定しており、有益なディスカッションをスケジュール通りに進めることができた

という見解を示しており、会合は成功であったと結論付けています。

前回のIETF 106で開催されたabcd BoFの議論[*13]と、その後のaddメーリングリストでの議論を踏まえ、2020年2月21日に新たなWGとしてadd WGが創設されました。

addはAdaptive DNS Discoveryに由来しており、パブリックネットワーク・プライベートネットワーク・VPNを含むさまざまなネットワーク環境において、DNSクライアントがリゾルバーを発見／選択するための技術的な仕組みを標準化することを目的としています。

その背景として、さまざまな付加サービスを提供するパブリックDNSサービスが出現・普及したことで、利用するネットワークやアプリケーションごとに異なったリゾルバーが使われる状況に対応するための仕組みが求められるようになったことが挙げられます。

addでは、DNS over TLS（DoT）やDNS over HTTPS（DoH）のようなトランスポートの暗号化に対応したリゾルバーと、暗号化に対応しないリゾルバーの双方が対象となっています。また、作業の対象を技術的な仕組みの開発に絞り込んでおり、クライアントやサーバーのユースケース、ポリシーに関する推奨事項については対象外としています。

▼議論された提案の内容と標準化作業の進行状況

▽複数のリゾルバーのセットからのリゾルバーの選択
（draft-arkko-abcd-distributed-resolver-selection）

名前解決に使うリゾルバーを、複数のリゾルバーをまとめたセットからその都度選んで使うようにすることで特定のリゾルバーによる情報収集を低減し、名前解決のプライバシーを向上させるための提案です。

この提案では、複数のリゾルバーのセットを選んで使うことでプライバシーを向上できるかという点にのみ注目しており、DoTやDoHといったトランスポートの暗号化、アプリケーションに固有の名前解決の仕組みの取り扱いについては対象外としています。

参加者からは「クライアントは複数のネットワークインターフェースやVPNインターフェースからどのようにインターフェースを選択するのか」「複数のリゾルバーを使うことによるパフォーマンスへの影響は考察しているのか」などといったコメントが寄せられ、今後も継続して議論を進めることとなりました。

▽リゾルバーを動的に発見するための枠組み
（draft-pauly-dprive-adaptive-dns-privacy）

暗号化されたDNSサービスを提供するリゾルバーをクライアントが動的に発見し、ローカルに提供されるリゾルバーと共存する形で適切に使うための枠組みを定義するための提案です。

参加者からは「その枠組みには利用者の意向は反映できるのか」「DoHやDoTによって、サービスプロバイダーが現在よりも多くの情報を集めるようになるのではないか」「大手のISPは対応可能かもしれないが、中小のISPでは対応が難しいのではないか」といったコメントが寄せられ、今後も継続して議論を進めることとなりました。

▽DNS Resolver Discovery Protocol（DRDP）（draft-mglt-add-rdp）

クライアントが利用できるローカル／グローバルな名前解決サービスを発見するための、DNS Resolver Discovery Protocol（DRDP）の仕様を定義するための提案です。

DRDPが取り扱う情報には、以下のものが含まれます。

• 名前解決サービスの識別子（identity）
• トランスポートに関する情報（IPアドレス、トランスポートプロトコル、TLSのパラメーター、HTTPのバージョン）
• 名前解決サービスの特性（フィルタリングの有無、権威を持つドメイン名）

参加者からは「DRDPに応答するものとして何を想定しているのか」「名前解決サービスのリポジトリを作るとしてそれを誰が運営・管理するのか」「認証局のようなビジネスモデルを作ろうとしているのか」などといったコメントが寄せられ、今後も継続して議論を進めることとなりました。

▽オープンマイクの状況

提案中のインターネットドラフトに関する議論の後、参加者からのコメントを募るオープンマイクの時間が設けられました。

参加者からは「このWGはプライバシーを強化したリゾルバーを発見するためのプロトコルの話を進めようとしているのか」「議論を進めるに当たり最初に原理原則と要求条件をまとめるべきだ」といったコメントが寄せられました。

2020年4月6日に、次回の第108回IETF Meeting（IETF 108）の開催に関する検討状況が発表されました[*14]。

IETF 108は2020年7月25日から31日にかけ、スペインのマドリードで開催される予定となっています。しかし、現在のスペイン及び世界各地の状況を受け、IETF 108についても、完全オンライン開催への変更が計画されています。結論については、5月15日に発表される予定です。

本会議報告は、JPRSのメールマガジン「FROM JPRS」の増刊号として発行した情報に写真などを交えてWebページ化したものです。
「FROM JPRS」にご登録いただいた皆さまには、いち早く情報をお届けしております。ぜひご登録ください。