第94回IETF Meeting報告

2015年11月1日から6日にかけて、第94回IETF Meeting（以下、IETF 94）が横浜で開催されました。今回のFROM JPRSでは、IETF 94の内容について報告します。

今回のFROM JPRSでは、以下の項目に沿って会合の模様をお伝えします。

• dnsop WGにおける話題
  - RFC 6761の問題点に関する議論
  - 標準化作業の進行状況
  
• dprive WGにおける話題
  - RFC 7626がInformational RFCとして発行
  - DNS over TLSとDNS over DTLS
  - 今後のWGの方向性について
  
• eppext WGにおける話題
  - チャーターの改定と今後の作業方針
• lager WGにおける話題
  - 背景
  - lager WGの新設
  - 今回の議論の内容
  
• その他の主なDNS・レジストリ関連WGの状況
  
• IETF全般における話題
  - チュートリアル
  - JPRSがBits-N-Bitesに出展
  
• 次回のIETF Meeting
  

dnsopはDNS Operationsに由来しており、DNSサーバーや登録情報の管理など、DNSの運用全般に関するガイドラインの作成を目的として組織されています。現在では運用上の課題に着目したDNSプロトコルの拡張・メンテナンスも、WGの活動項目に追加されています。

RFC 6761の問題点に関する議論

今回のdnsop WGでは、特殊用途ドメイン名（Special-Use Domain Name）を定義する、RFC 6761の問題点に関する議論が行われました（*1）。

いくつかの特殊用途ドメイン名ではTLDラベルの内容により、参照するシステムや名前空間（name space）が変更されます。例えば、.localではDNSに替えてmDNS（*2）が参照され、今回予約された.onionではTor（*3）内部で定義される専用の名前空間が参照されます。

このように、TLDラベルによって参照するシステムや名前空間を変更する場合、そのラベルが特殊なものであり、DNS以外のシステムやインターネット以外の名前空間を参照する必要があることが広く認識され、かつ適切に対応されている必要があります。そのためにはそのラベルを特殊用途ドメイン名として単に予約するだけでは不十分であり、正しく機能しないこととなります。

今回、この問題に対応するためのデザインチームがdnsop WG内に組織され、作業の結果がインターネットドラフト（draft-adpkja-dnsop-special-names-problem）としてまとめられました。

今回のWGではデザインチームから、現時点において考えている問題解決の方向性として、以下の五つが示されました。

• RFC 6761による予約をやめる
• プロトコル変更用として.alt TLDを新設する
• ICANNと協働で、新しい予約プロセスを策定する
• URIスキームを用いた別の識別子を作る（*4）
• その他の方法を考える

その後、参加者による活発な議論が行われましたが結論には至らず、今後も議論を継続していくこととなりました。今回の議論にはIETFチェアも参加しており、チェアからはこの問題はIESGが決めるものではなく、コミュニティで議論すべきものであるという発言がありました。

なお、会場からは、これはプロトコルの話ではなく名前空間の利用の話であり、IETFで議論すべき内容ではないのではないか、という意見もありました（*5）。

また、今後の特殊用途ドメイン名の予約はこの問題の解決後とすることが、WGチェアから示されました。

標準化作業の進行状況

dnsop WGでは最近、プロトコル変更・拡張に関する活発な提案と標準化作業が進められています。ここでは、最近の主な提案の内容と標準化作業の進行状況について、簡単に紹介します。

▽クエリタイプANYのレスポンスサイズの小型化（draft-jabley-dnsop-refuse-any）

DNSリフレクター攻撃の防止のため、ANYリソースレコード（RR）に対する応答の仕様を変更してサイズを小さくする、プロトコル変更の提案です。

今回のWGではANY RRに対する応答として、知っているRRをできるだけ返すという現在の仕様に替え、サイズの小さい別のRR（*6）を返すようにするという仕様が提案され、今後WGとして標準化作業を進めていくこととなりました（*7）。

▽DNSメッセージへのハッシュの付加（draft-muks-dnsop-dns-message-checksums）

第一フラグメント便乗攻撃（*8）への対策、及びキャッシュポイズニング攻撃への耐性強化（DNSメッセージのエントロピーの増加）のため、DNSメッセージにnonce（*9）を付加した上でEDNS0により全体のハッシュを付加する、プロトコル拡張のための提案です。

今回のWGでは提案内容や効果について興味を持つ人がいる反面、IPv6であれば必要ない、プロトコルが複雑になり過ぎるといった意見もあり、今後議論を継続することとなりました。

▽EDNS0のオプションフォーマットへの鍵タグ追加（draft-wessels-edns-key-tag）

EDNS0に新しいオプションを追加し、鍵タグ（*10）の情報をクライアント側からサーバー側に伝えられるようにする、プロトコル拡張のための提案です。

これを利用することで、トラストアンカーの自動更新（*11）における新しいトラストアンカーの利用状況を把握できます。今回のWGでは主に動作についての確認が行われ、今後WGとして標準化作業を進めていくこととなりました。

▽NSEC/NSEC3の積極的な活用（draft-fujiwara-dnsop-nsec-aggressiveuse）

JPRSの藤原和典が提案している、DNSSECの不在証明の仕組みを積極的に活用することでDNS水責め攻撃（*12）の影響緩和を図る、プロトコル変更のための提案です。

本提案では、応答されたNSEC/NSEC3レコードのキャッシュを積極的に活用することで権威DNSサーバーへの問い合わせ数を減らすと共にリゾルバーの処理コストを軽減させ、DNS水責め攻撃の影響緩和を図っています。

今回のWGではこの提案に関する議論は行われませんでしたが、WG Draftとして採択される候補（candidate for WG adoption）となりました。

dpriveはDNS PRIVate Exchangeに由来しており、DNSトランザクションにおける機密性（confidentiality）の提供を目的としています。

RFC 7626がInformational RFCとして発行

DNSにおけるプライバシーに関する考慮事項をまとめたRFC 7626（DNS Privacy Considerations）が、Informational RFCとして発行されました。

RFC 7626ではDNSにおけるプライバシーのリスクについて、問い合わせ名の最小化（qname minimisation）（*13）とDNSの通信の暗号化の必要性、その考慮事項について記述しています。

DNS over TLSとDNS over DTLS

dprive WGではDNSの通信を暗号化するための提案として、DNS over TLS（*14）とDNS over DTLSの二つの方式の標準化が進められています。

DNS over TLSはHTTPSで用いられているTLS（*15）をDNSに適用する提案であり、TCPでの通信が前提となっています。一方、DNS over DTLSはTLSをUDPに対応させたDTLS（*16）をDNSに適用する提案です。

今回のWGでは前回から継続して、それぞれの問題点の確認と標準化に関する議論が進められました。

▽DNS over TLS

DNS over TLS（draft-ietf-dprive-dns-over-tls）では、DNSメッセージをやり取りする前に暗号を用いるかどうかの確認を実施する機構（STARTTLS）はプロトコルが複雑になることから削除され、DNS over TLS専用のポート番号として、853/tcpがIANAから割り当てられることとなりました（*17）。

DNS over TLSには既にいくつかの実装があり（*18）、また、今回のIETF Hackathon（*19）でも実装作業が進められました。

WGでは、現在のインターネットドラフトはサーバーの認証部分のプロファイル（Profile）（*20）の定義のみとし、プロファイルの内容は別ドキュメントとする方向で、継続して検討を進めることとなりました。

▽DNS over DTLS

DNS over DTLS（draft-ietf-dprive-dnsodtls）では、DNSメッセージのフラグメントの問題が指摘されました。DTLSはフラグメントを扱う仕組みを持たないため、UDPのDNSメッセージをDTLS化する場合、DTLS上にフラグメントを扱うための仕組みが別途必要になり、プロトコルが複雑になることが指摘・共有されました。

また、フラグメントされたDNSメッセージには前述した第一フラグメント便乗攻撃を始めとするセキュリティ上の問題が見つかっていることが問題提起され、それを解決するためにメッセージの分割をDNSレベルで実現するための提案（draft-muks-dns-message-fragments）や、DNS over TLSへのフォールバックを用いたフラグメントの回避について議論が行われました。

DNS over DTLSの標準化にはこの課題の解決が必要であり、また、dprive WGでの議論においてDNS over TLSの標準化を先に進める流れがあることから、DNS over DTLSの標準化には時間を要することが見込まれます。

今後のWGの方向性について

前述の通り、クライアントとフルリゾルバーの間の暗号化はDNS over TLSで進めようという流れがありますが、DNS over TLS／DNS over DTLSのどちらか、あるいは両方を標準化するかどうかについては、今後も継続して議論を進めていくこととなりました。

また、今回のWGでは標準化作業完了後のWGの方向性について議論が行われ、フルリゾルバーと権威DNSサーバーの間の暗号化に進む、運用・実装についての文書化を進める、いったん終了するなどの案がWGチェアから提示されましたが、結論は出されず、継続して議論を進めることとなりました。

eppextはEPP Extensionsに由来しており、レジストリ・レジストラ間の登録情報のやりとりに用いられるEPP（Extensible Provisioning Protocol）の機能拡張を目的として組織されています。

チャーターの改定と今後の作業方針

eppext WGでは今後の方向性として対象をEPPの拡張に限定せず、登録情報の検索サービスとしてWhoisを置き換えるために開発されたRDAP（*21）の拡張も対象とすることとし、WGのチャーターの改定（リチャーター）を議論しています。

これを受け、これまでRDAPの標準化と機能拡張を検討してきたweirds WGとeppext WGの活動を一つにまとめたregext WG（仮称）を設立する方向で検討が進められています。

また、今後のWGの作業方針について、IETFとしてはレジストリが取り扱うプロトコルの標準化作業に集中すべきであるという意見が寄せられ、2016年1月に予定されているリチャーターに向け検討を進めることとなりました。

背景

新gTLDの登場により、ルートゾーンでも非ASCII文字を含むさまざまな言語が利用されるようになりました。しかし、今回の新gTLDプログラムでは、使用文字列（ラベル）の人手による審査に多くの時間と労力を要しました。

そのため、次回以降の新gTLDプログラムに向け、TLDラベルとして使用可能な文字と異体字を機械的に生成できるようにするためのルートゾーンラベルの生成ルール（Root Zone Label Generation Rules、以下、Root Zone LGR）の作成が進められています。

Root Zone LGRの作成に向け、各言語コミュニティにおいてそれぞれの言語のルール案の作成が進められています。日本では専門家有志により、日本語ラベルに関するルールを検討するパネルとして日本語生成パネル（Japanese Generation Panel：JGP）が設立され、活動を続けています（*22）。

lager WGの新設

こうした動きを受け、ラベル生成ルール（LGR）を記述するための共通の形式を作成することを目的とした、lager WGが新設されました。WGでは記述ファイルの形式として、XMLを採用しています。

今回の議論の内容

今回のWGではRoot Zone LGRにおける経験から、セカンドレベルドメイン（2LD）などTLD以外のラベルにおいても起こり得るユースケース（*23）についても検討課題とすべきではないかという問題提起がありました。本件については課題であることが共有されつつも、まずは当初の目的であるLGRのプロトコルの策定を進める方向で検討が進められることとなりました。

また、LGRの内容を記述するXMLスキーマの定義そのものについては大きな議論はなく、実装からのフィードバックを反映しながら、WG Last Callに向けた作業を進めていくこととなりました。

LGR用のXMLスキーマが標準化された後、現在IANAに登録されているIDNテーブル（*24）のLGR化が進められていくこととなります。

dbound WGは、ドメイン名の境界、すなわち管理レベルの判定に使われているPublic Suffix List（*25）を置き換える仕組みの標準化を進めるために設立されたWGです。

今回のdbound WGでは活発な議論が行われましたが、WGとして何が問題であり、何を解決したいのかが明確に定義されておらず、結論は出ませんでした。

また、homenet・mif・dnssdの各WGにおいてもDNS関連の話題が上がったものの関連する標準化作業は減速気味であり、作業完了には時間を要すると見込まれます。

チュートリアル

IETF Meetingでは会議初日の日曜日に、参加者を対象としたチュートリアルが開催されます。チュートリアルでは新規参加者向けのオリエンテーションやインターネットドラフトを書く際に有用なツールの紹介、特定の技術分野の概要を紹介するものなどが開催されています。

今回のチュートリアルでは特定の技術分野の概要を紹介するものとして国際化（PRECIS（*26）and i18n）が取り上げられ、JPRSの米谷嘉朗が講師を担当しました。

JPRSがBits-N-Bitesに出展

Bits-N-Bitesは、IETFで標準化されている技術を採用した製品や新技術のデモンストレーション・活動紹介などが行われる、IETF参加者が数百人規模で集う場です。会場では食事や飲み物が無料で提供され、参加しやすい雰囲気が作られています。

今回は横浜での開催であることもあり、日本からJPRSを含む6組織がブースを出展しました。JPRSでは、JPドメイン名とJPRSにおける標準化技術の採用・実装状況を紹介し、参加者との情報交換を行いました。

次回の第95回IETF Meeting（IETF 95）は2016年4月3日から8日にかけ、アルゼンチンのブエノスアイレスで開催されます。

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