第97回IETF Meeting（ソウル）報告

2016年11月13日から18日にかけて、第97回IETF Meeting（以下、IETF 97）が韓国のソウルで開催されました。

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

• dnsop WGにおける話題
  - IETF 96以降のRFC発行状況
  - 議論された主な提案の内容と標準化作業の進行状況
  
• regext WGにおける話題
  - 議論された主な提案の内容と標準化作業の進行状況
  
• dnsbundled BOFの開催
  
• IETF全般における話題
  - インターネットのアーキテクチャーに対する攻撃
  
• IEPG会合における話題
  - IP AnycastとDDoS
  - NSEC/NSEC3の積極的な活用
  
• 次回のIETF Meetingについて
  

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

IETF 96以降のRFC発行状況

前回のIETF 96以降に発行されたRFCは、以下の2本です。

• 名前不在の取り扱いに関する仕様の明確化と更新
  （draft-ietf-dnsop-nxdomain-cut、RFC 8020：Standards Track）
  名前不在の取り扱いについてRFC 1034を明確化、RFC 2308を更新し、リゾルバーが名前不在エラー（NXDOMAIN）を受け取った場合にそれをネガティブキャッシュすることと、受け取った名前（例：a.example.jp）がNXDOMAINであるとき、c.b.a.example.jpなどのように子孫の名前すべてをNXDOMAINとして扱うよう変更します。
  
  本RFCの発行により、(random).www.example.jpに対する大量のクエリを送りつけるDDoS攻撃に対し、www.example.jpの情報を一時的に削除する形で緊急対応した場合、www.example.jpが存在しないことがリゾルバーにキャッシュされた時点で、(random).www.example.jpは存在しないことになります。
  
  これにより、(random).www.example.jpに対するクエリを受信した場合、リゾルバーから権威DNSサーバーへのクエリの送信を抑制でき、DDoS攻撃の効果抑制につながります。


• ネットワークインフラにおけるDNSSEC非準拠の検知法と影響の緩和策
  （draft-ietf-dnsop-dnssec-roadblock-avoidance、RFC 8027：Best Current Practice）
  EDNS0を制限するミドルボックス（*1）や、UDPフラグメントを正しく取り扱えない機器が用いられているネットワークにおいて、何が原因になっているかの検知と、影響軽減のための手法を記述したものです。
  
  本RFCの発行により、DNSSECに対応できないネットワークインフラをオペレーターが効率的に検知することが可能になり、DNSSECの普及に役立てることが期待されています。

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

FROM JPRS編集局が注目した提案の内容と標準化作業の進行状況について紹介します。

▽ipv4only.arpaの導入（draft-cheshire-sudn-ipv4only-dot-arpa）

DNS64（*2）の存在と、IPv6・IPv4のプロトコル変換に利用されているIPv6アドレスの検出方法を定義するRFC 7050において利用される「ipv4only.arpa」を、特殊用途ドメイン名（*3）に登録するための提案です。

本提案では、同様にRFC 7050において利用される特別なIPアドレスである「192.0.0.170」、「192.0.0.171」の逆引きに利用される「170.0.0.192.in-addr.arpa」、「171.0.0.192.in-addr.arpa」の二つも、特殊用途ドメイン名に登録します。

今回のWGでは、arpaドメイン名の委任の方法と議論を行うべき場について議論され、ipv4only.arpaはIABが管理するarpaドメイン名における委任でありIETFの担当ではないこと、ドメイン名の予約自体はIABと交渉すればよいが、TTLなどの設定パラメータについてはdnsop WGと相談したほうがよいことなどがコメントされました。

▽DNSのパケットキャプチャーフォーマット（draft-dickinson-dnsop-dns-capture-format）

ネットワークを流れるパケットをキャプチャーする際に、DNSデータをより効率的な形で交換可能な、記録フォーマットを定義するための提案です。

現在、キャプチャーされたDNSデータを扱うツールとしてDSC、packetq、dnscap、dnstapなどが使われていますが、記録したデータを交換するための標準フォーマットは定義されていません。

本提案では、大規模なデータのキャプチャーにおける問題点に注目し、データ容量を削減し、かつデータ交換が可能な標準フォーマットとしてCBOR（*4）形式を使うというものです。

発表では、クエリと対応する応答を組み合わせて格納する、複数のクエリ／応答をまとめてブロック化するなど、DNSの特性を考慮したデータの配置にして保存するデータ量を最小限とした上で圧縮することにより、PCAPデータを圧縮しただけの場合と比べ30％程度のサイズになることが示され、多くの感心が集まりました。

本提案はWG draftとして採択され（draft-ietf-dnsop-dns-capture-format）、WGで検討されることになりました。

▽リゾルバーアルゴリズムの更新（draft-fujiwara-dnsop-resolver-update）

JPRSの藤原和典が著者として作成している提案で、リゾルバーの名前解決アルゴリズムの一部を変更するものです。

DNSの仕様を定義したRFC 1034では、新しい委任／ゾーンは親側に設定されるNSレコードによって作られると定義しており、子ゾーンの権威DNSサーバーにアクセスするためのすべての情報は、親側に存在するとしています。

しかし、親側に設定されるNSレコードは権威を持つデータではなく、権威を持つデータは子側に存在しています。リゾルバーが権威DNSサーバーから受信した応答の取り扱いについてRFC 1034/1035の仕様を明確化したRFC 2181では、権威を持たないデータは権威を持つデータで上書きすべきであるとしており、結果として名前解決の際に親から応答されたNSレコードは、子から応答されたNSレコードで上書きされます。

提案では、このことがフルリゾルバーの実装の複雑さや幽霊ドメイン名脆弱性（*5）の要因となっていることを指摘し、DNSの名前構造をたどる場合には親側で設定されるNSレコードとグルーレコードが重要であり、それらのみが利用されるべきであるとしています。

今回のWGでは、本件はリゾルバーにおける大きなアルゴリズムの変更であり、親子それぞれのNS・TTLの取り扱いについては慎重に議論すべきであるといった意見や、NSレコードについてはそもそも子側のデータを使うべきであるといった主張が強く、継続して議論を進めていくことになりました。

また、本提案に記述されたフルリゾルバーのキャッシュを二つに分離する実装方式については、特許が存在する旨の指摘が寄せられています（*6）。

regext WGは、RDAPの標準化と機能拡張を検討したweirds WGとEPP（*7）の機能拡張のために組織されたeppext WGの活動を一つにまとめ、RDAPなどレジストリ関連のプロトコルも扱うよう再編成されたWGです。

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

FROM JPRS編集局が注目した提案の内容と標準化作業の進行状況について紹介します。

▽EPPを用いたDNSSEC鍵の中継（draft-ietf-eppext-keyrelay）

EPPを拡張し、DNSオペレーター間におけるDNSSECの鍵情報中継の機能を定義し、鍵交換を実現可能にするための提案です。

DNSSECを維持した状態でDNSオペレーターを変更する場合、変更元と変更先のDNSオペレーター間でDNSSEC鍵情報を交換する必要があります。しかし、変更元と変更先のDNSオペレーターの関係が非協力的（Non-Cooperating）である場合、円滑なDNSSEC鍵情報の交換ができないことがあります（*8）。

本提案では、あるレジストラが持つDNSSEC鍵情報をレジストリ経由で別のレジストラに中継できるようにEPPを拡張し、DNSSEC環境におけるDNSオペレーターの変更を円滑に実行可能にするための機能を提供します。

本提案については旧eppext WGで標準化作業が進められましたが、2014年7月にVerisignから同社の知的財産権を侵害している旨のクレームが寄せられたため、標準化作業が一時中断していました（*9）。

今回のWGでは本提案についての取り扱いが議論され、同社から知的財産権に対する追加の情報が得られなかったため影響はないものと判断し、RFC化を推進していくこととなりました。その後、12月6日にIESGが本提案をStandards Track RFCとして発行することを承認し、RFC発行待ち（RFC Ed Queue）の状態となっています。

▽データエスクローの標準化（draft-arias-noguchi-registry-data-escrow、draft-arias-noguchi-dnrd-objects-mapping）

JPRSの野口昇二が共著者として作成している提案で、ドメイン名レジストリのデータエスクローのための、データ形式と内容を規定するものです。

レジストリやレジストラが何らかの理由により業務を継続できなくなった場合に備え、ドメイン名の登録情報を第三者組織に預託することをデータエスクローと言います。

データエスクローの標準化については上記のドキュメントが発行されていますが、現在は期限切れ（expire）の状態となっています。

今回のWGで、データエスクローの標準化提案をregext WGの作業項目とすることについて共著者が提案しました。regext WGチェアからは、WGのリチャーターが必要とのコメントがあり、メーリングリストで確認する他、エリアディレクターにも相談の上、作業を進めることとなりました。

国際化ドメイン名における「中国」と「中國」など、異なるラベルを同一の名前として取り扱うための仕組みを検討するWGの設立を目指して、dnsbundled BOFが開催されました。前回のIETF 96では非公式なSide BOFとして開催されましたが、IETF 97では正式なBOFとして開催されています。

今回のBOFでは、CNNICのJiankang Yao氏らから提案された問題提起文書（problem statement）の説明、いくつかのレジストリ・レジストラにおけるユースケースの紹介の後、今後の進め方についての議論が進められました。

会場からは、

• この問題は、IDNの標準化が進められた2002年にも議論されている
  
• 現在の問題提起文書は不十分であり、問題点を明確に定義していない
  
• 問題の解決にはDNSの名前解決のみでは不十分であり、インターネット識別子の根本的な作り直しが必要になる
  
• 本件においては、DNSのゾーン管理と利用者のアクセスの双方について考慮する必要があるが、この場では対象をゾーン管理に絞るべきである
  

などといった意見が寄せられました。

結果として、今回のBOFではWG設立の合意には至らず、当面はメーリングリストで問題提起文書における問題点を明確化する作業を進めることとなりました。

インターネットのアーキテクチャーに対する攻撃

今回のIETF Operations, Administration, and Technical Plenaryでは、「インターネットのアーキテクチャーに対する攻撃（Attacks Against the Architecture）」というテーマで、講演と議論が行われました。

まず、CloudFlareのNick Sullivan氏から「How to stay online」というタイトルで、現在のDDoS攻撃の傾向と代表的な影響緩和策が講演され、IABチェア／DynのAndrew Sullivan氏から「The Internet's Architecture is Under Attack (Ironically)」というタイトルで、2016年10月に発生した米国のDNSプロバイダー大手企業のDynに対するDDoS攻撃を題材とした講演が行われました。既報の通り、今回のDynに対する攻撃ではセキュリティ上の考慮が不十分な大量のIoT機器が悪用され、極めて大規模な攻撃が行われました。

Andrew Sullivan氏の講演では、IoT機器が悪用されたことは本件の一面の事実に過ぎず、根本原因にはインターネットのアーキテクチャーそのものの脆弱さがあるとし、問題解決のためにはより強固なインターネットアーキテクチャーの構築が必要であり、そのためにはどのようなことが可能であるか、どのような取り組みが必要であるかについて、会場の参加者を交えた議論が行われました。

会場からは、

• 問題解決のためにはプロトコル設計者・製品開発者・運用者・行政執行者など、それぞれの立場の人が何をすべきかを知らなければならない。そして、IABはそれを知らせることができる立場にいる
  
• プロトコル設計の段階から、オペレーターの観点を加味したセキュリティ上の対策を考慮すべきである
  
• IoT機器の製造者や政府など、さまざまな関係者を交えた総合的な取り組みが必要である
  

などのコメントが寄せられ、活発な議論が行われました。

IP AnycastとDDoS

2015年11月30日に発生したルートサーバーに対して大量のクエリが送られた出来事（*10）について、IP Anycast（*11）がどのように機能したかを評価したレポートが発表されました。

この出来事では、A～Mまで13系列存在するルートサーバーの各系列ごとに1秒間に500万クエリが観測され、13系列のうち10系列が影響を受けました。

発表では、現在のIP Anycastを利用した防御手法は合理的と考えているものの、大陸をまたぐ規模の地理的な多様性と、長期的な視点での研究継続が必要であることが報告されました。

NSEC/NSEC3の積極的な活用

APNICのGeoff Huston氏から"DDOS and the DNS"というタイトルで発表が行われ、その中でJPRSの藤原和典らが提案している、DNSSECの不在証明の仕組みをより積極的に活用することで負荷軽減を図るdraft-ietf-dnsop-nsec-aggressiveuse（*12）が、有用な対策の一つとなることが紹介されました。

この発表の後、Google Public DNSにおける本提案の活用事例が、共著者の一人であるGoogleのWallen Kumari氏から急遽紹介されました。

2016年5月に発生したk.root-servers.net（K-Root）に対するGoogle Public DNSからの大量クエリが導入のきっかけになったこと、導入によりGoogle Public DNSからルートサーバーへのクエリ数が減少し、効果を発揮したことが報告されました。

次回の第98回IETF Meeting（IETF 98）は2017年3月26日から31日にかけ、米国のシカゴで開催されます。

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