第95回IETF会合（ブエノスアイレス）報告（前編）

2016年4月2日から8日にかけて、第95回IETF会合（以下、IETF 95）がアルゼンチンのブエノスアイレスで開催されました。FROM JPRSではIETF 95と、その周辺で開催された会議の内容について、前編と後編に分けて報告します。

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

• dnsop WGにおける話題
  - IETF 94以降のRFC発行状況
  - 主な提案の内容と標準化作業の進捗状況
  
• arcing BOFにおける話題
  - 開催の背景
  - 今回の議論の内容と今後の方向性
  
• dprive WGにおける話題
  - IETF 94以降のRFC発行状況
  - 主な提案の内容と標準化作業の進捗状況
  
• saagにおける話題
  - 楕円曲線暗号を用いたNSEC5の評価
  

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

IETF 94以降のRFC発行状況

前回のIETF 94から2016年5月10日現在までの間に5本のRFCが発行され、4本のインターネットドラフト（以下、I-D）がRFC発行待ち（RFC Ed Queue）となっています。

▽RFC発行

• ルートサーバーへのアクセス時間の短縮（RFC 7706）
• DNS用語の明確化（RFC 7719）
• DNSのTCPサポートにおける実装上の要求事項（RFC 7766）
• 問い合わせ名の最小化（RFC 7816）
• EDNS0によるedns-tcp-keepaliveオプション（RFC 7828）

▽RFC発行待ち（RFC Ed Queue）

• 共有アドレス空間（100.64.0.0/10）の逆引きローカルゾーンへの追加（draft-ietf-dnsop-rfc6598-rfc6303）
• EDNS0によるChain Query機能（draft-ietf-dnsop-edns-chain-query）
• EDNS0によるDNSクライアントのネットワーク情報の伝達（draft-ietf-dnsop-edns-client-subnet）
• DNSクッキー（draft-ietf-dnsop-cookies）

主な提案の内容と標準化作業の進捗状況

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

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

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

今回のWGでは知っているすべてのRRを返すという従来の動作に加え、応答サイズの減少のため有効な一部のRRSetのみを返すことができるようにするという動作の具体例として、CloudFlare（*1）のDNSサービスで実装されたHINFO RR（ホストの情報）を返す案と、NSD（*2）で実装されたMX+A+AAAA RRを返す案の二つが検討されました。その結果、双方の案を記述することとし、議論の結果を見た上でワーキンググループラストコール（以下、WGLC）を実施することとなりました。

▽DNSの委任における要求事項（draft-wallstrom-dnsop-dns-delegation-requirements）

DNSの委任において親子それぞれのゾーンが正しく設定・運用されていない場合、Lame Delegationを始めとするさまざまな問題の原因となります。本提案では、提案者が開発メンバーの一人となっているDNSの設定チェックツールZonemaster（*3）を開発・運用する中で得られた知見を活かし、DNSの委任における要求事項について、DNSプロトコルやパケットの取り扱いなどに求められる項目がまとめられています。

本提案では要求事項として、ドメイン名の有効性や権威DNSサーバーのIPアドレスの到達性といった基本的なものから、TCP/UDP双方でのサービスの提供、SOAやNSの設定内容、UDPにおけるパケットの切り詰め、DNSSEC関連の設定に至るまでの、DNSの委任に関する要求事項が網羅的にまとめられています。

今回のWGでは本件について活発な議論が行われましたが、WGとして取り上げるかについては明確な結論が出されず、今後メーリングリストで議論を続けていくこととなりました。

▽DNSSECのための暗号アルゴリズムの実装要求事項と利用指針（draft-wouters-sury-dnsop-algorithm-update）

DNSSECではさまざまな暗号アルゴリズムが用いられます。しかし、それらのアルゴリズムは計算機環境の変化やアルゴリズムの危殆（きたい）化などにより使用が推奨されなくなる場合があります。

本提案では、フルリゾルバーと権威DNSサーバー間における相互運用性の確保のため、その時点においてすべての実装でサポートが必須、あるいは推奨される暗号アルゴリズムの実装ガイドラインを作成することを目的としています。

今回のWGでは各暗号アルゴリズムを署名と検証に分けて分類・定義することや、MUST+／SHOULD-／MAYなどといったレベルの付け方について議論されましたが明確な結論は出されず、今後メーリングリストで議論を続けていくこととなりました。

▽HTTPを使ったDNS通信（draft-song-dns-wireformat-http）

DNSサービスの可用性を高めるため、DNSの通信をHTTPで伝達する方法を定義するための提案です。本提案では通常のDNS通信ができないネットワークやミドルボックス（*4）などの配下において、HTTPを用いたDNS通信を実現することを想定しています。

WGではJSON（*5）でDNSパケットを記述すべきといった意見や、既存の名前解決APIが対応していない問題などについて議論されましたが明確な結論は出されず、今後も議論を続けていくこととなりました。

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

JPRSの藤原和典と慶應義塾大学大学院の加藤朗氏との共著で提案されている、DNSSECの不在証明の仕組みを積極的に活用することでDNS水責め攻撃（*6）の影響緩和を図る、プロトコル変更のための提案です。

WGでは、不在証明を用いてルートゾーンへの問い合わせを減らすことに特化した別の提案（draft-wkumari-dnsop-cheese-shop（*7））と併せた形で議論されました。

WGでの議論の結果、藤原らが提案しているNSEC/NSEC3の積極的な活用がより支持され、draft-wkumari-dnsop-cheese-shopに記述された要素・考え方を藤原らの提案に取り入れるよう、WGチェアから指示がありました。

WG終了後の4月10日に、WGチェアが本提案をWG Draftとして採択することを検討する旨（Call for Adoption by WG Issued）を宣言しています。

開催の背景

インターネットの名前解決システムには、DNS以外にもMulticast DNS（mDNS）やTor（*8）で用いられているOnion routingなど、複数のシステムが混在・併存しています。

こうしたDNS以外の名前解決システムも含め、複数のシステムが混在・併存している環境における名前解決全般における問題を議論・検討する場として、arcing（Alternative Resolution Contexts for Internet Naming）BOFが開催されました。

今回の議論の内容と今後の方向性

今回のBOFでは問題点と検討対象の明確化のため、DNSの歴史やDNS以外の名前解決システムの紹介とそれらに関する課題の認識が解説され、その後、利用者ごとに異なる名前解決方法をどのように識別し、どのような手順で適用すべきかを中心に議論が進められました。

今後のWG設立については、今回の議論の対象となったI-D（draft-lewis-domain-names、draft-hardie-resolution-contexts、draft-trammell-inip-pins）を更新し、WGの設立を前提としたBOFを次回のIETF 96で開催した上で決める方がよいという意見が多く、メーリングリストでコメントを募集した上で進めていくことがBOFチェアから示されました。

なお、今回のBOFはIABが主催しており、dnsop WGで検討が進められている特殊用途ドメイン名（RFC 6761）に関する議論が、ここで取り扱う課題の一つになることが見込まれます（*9）。

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

IETF 94以降のRFC発行状況

前回のIETF 94から2016年5月10日現在までの間に、2本のI-DがRFC発行待ち（RFC Ed Queue）となっています。

▽RFC発行待ち（RFC Ed Queue）

• DNS over TLS（draft-ietf-dprive-dns-over-tls）
• パディングオプション（draft-ietf-dprive-edns0-padding）

主な提案の内容と標準化作業の進捗状況

▽DNS over DTLS（draft-ietf-dprive-dnsodtls）

DNS over DTLSは、TLSをUDPに対応させたDTLS（*10）をDNSに適用する提案です。

DTLSではフラグメントの仕様が定義されておらず、DTLSを利用する場合、上位層においてフラグメントを回避する必要があります。そのため、今回のWGではフラグメントが発生しうる大きな応答についてはDNS応答のTCビットをセットした上で切り詰めた応答を返すことによりDNS over TLSでの再問い合わせを促し、フラグメントが発生した場合の取り扱いについてはI-Dから削除されることとなりました。

本提案については今後、内容のレビューを進めた上でWGLCを実施する予定となっています。

▽DNS over TLS/DTLSにおける認証とプロファイル（draft-ietf-dprive-dtls-and-tls-profiles）

本提案は、DNS over TLS/DTLSにおいてDNSクライアントがDNSサーバーを認証する方法に加え、DNS over TLS/DTLSを実装するために必要なプロファイル（*11）の内容について定義します。

今回のWGでは認証部分のプロファイル定義として、以下の3種類が提案されました。

• Strict（厳密に認証・暗号化し、中間者攻撃や盗聴を防ぐ）
• Opportunistic（暗号化を試みるが相手の正当性は検証しない）
• No Privacy（そもそもTLSを用いない）

提案を元にサーバーの認証方法について議論され、Strictでなければプライバシーは確保できないのではないかという意見や認証にDANE（*12）を用いる解決法の提案、複雑な方式では普及しないのではないかといった意見などさまざまな議論が交わされ、今後も継続して議論を進めていくこととなりました。

セキュリティエリア全般にまたがる話題を横断的に取り扱うグループsaag（Security Area Advisory Group）のオープンミーティングにおいて、NSEC3を改良した不在証明方式であるNSEC5（*13）を楕円曲線暗号（Elliptic Curve Cryptography）を用いて評価した結果の報告が行われました。

楕円曲線暗号を用いたNSEC5の評価（draft-vcelak-nsec5）

現在のDNSSECの不在証明方式であるNSEC3はゾーン情報の列挙を困難にするため、名前情報をハッシュした結果を利用します。しかし、NSEC3ではハッシュの総当たりにより、ゾーン情報の列挙ができ得るという問題が指摘されています（*14）。

NSEC5はこの問題を解決するための不在証明方式として、2014年に論文の形で発表されました（*15）。その後、論文の仕様に基づいたI-Dが2015年に発表されています。NSEC5では公開鍵暗号方式により不在証明の結果を暗号化する機能を加えることで、総当たりによるゾーン情報の列挙を防止しています。

今回のsaagではNSEC5の暗号方式として楕円曲線暗号を用いた場合の応答サイズを従来のNSEC・NSEC3の応答サイズと比較した結果、NSEC3よりわずかに大きくなる程度に応答サイズを収めることが可能であり、応答サイズの観点からは実運用可能であると考えられることが報告されました。

後編となる次回のFROM JPRS増刊号では、レジストリ関連の状況と、IETFに併設される形で開催された各種会合における話題を中心にお伝えします。

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