JPドメイン名のサービス案内、ドメイン名・DNSに関連する情報提供サイト

ドメイン名関連会議報告

2013年

第87回IETF Meeting報告（後編）

～DNSの運用とセキュリティにつながる話題、レジストリ関連WGにおける話題～

2013/09/10

今回のFROM JPRS増刊号では前回に引き続き、第87回IETF Meeting （以下、IETF 87）における議論の中から、DNSの運用とセキュリティにつながる話題、及びレジストリ関連WGにおける話題についてお伝えします。

会場近くに現在も残る「ベルリンの壁」の一部

会場近くに現在も残る「ベルリンの壁」の一部

6man WGとsaagにおける話題：IPフラグメンテーションがDNSに及ぼす影響

今回のIETF 87では、IPフラグメンテーション（*1）がDNSに及ぼす影響についての話題が、二つのWG／グループで取り上げられました。

(*1)
IPネットワークにおいて一回の伝送で送れる最大の単位（Maximum Transmission Unit：MTU）よりも大きなデータを送る必要がある場合、IPの内部処理において、MTUよりも小さなデータに断片化された上で送られます。断片化されたそれぞれのデータをフラグメント（fragment）と呼び、断片化する処理のことをIPフラグメンテーション（IP fragmentation）と呼びます。

以降では、それらのWG／ミーティングにおける議論内容についてご紹介します。

6man WG：IPv6におけるIPフラグメンテーションの廃止提案

IPv6の保守と発展（advancement）について取り扱う6man WGにおいて、IPv6のフラグメントヘッダーの廃止（Deprecated）が提案されました（draft-bonica-6man-frag-deprecate）。これは、IPv6においてIPフラグメンテーションの機能そのものを廃止することを意味しています。

このような提案が出された背景として、IPフラグメンテーションそのものがパフォーマンス上・セキュリティ上の観点において有害（harmful）であると、以前から繰り返し指摘されていた点が挙げられます（関連URIを参照）。

IPv6におけるTCPとUDPの動作の違い

そうした背景から実際のインターネットでは、TCPなどIPの上位層において、 フラグメントの発生をできるだけ回避するように運用されてきました。

現在のTCPの標準的な実装では、通信開始時に送信元がMTUを調べ（*2）、IPフ ラグメンテーションができるだけ発生しないように（MTUに収まるように）、 データをセグメントと呼ばれる単位で分割した上で送信用のパケットを作成し、 下位層（IP）に送信を依頼します。

(*2)
IPv6ではIPv4と異なり、経路途中におけるIPフラグメンテーションが禁止されています。そのためIPv6ではPath MTU Discovery（PMTUD）という手法により経路におけるMTUを事前調査し、得られた値を分割処理に使用することが一般的です。なお、PMTUDの手法はIPv6のみに限ったものではなく、IPv4においても同一の手法が使用される場合があります。

しかし、UDPではプロトコル仕様においてセグメント単位でデータを分割する機能が存在しないため、より上位の階層で特別な配慮をしない限りデータはそのままの形で送信用パケットとされ、下位層（IP）に送信依頼されます。そのため、対象となるデータがMTUに収まらない大きさであった場合、IPフラグメンテーションが発生することになります。

DNSSECへの影響

ここまでで説明した通り、TCPではIPフラグメンテーションの発生はできる限り回避されており、特にIPv6ではそれが発生することは基本的にありません。また、IPv6ではMTUの最低保証値を1280バイトと定めており、IPやTCP/UDPヘッダーを含む送信データの大きさが1280バイトを超えない場合、IPフラグメンテーションは発生しません。

そのため、IPv6においてIPフラグメンテーションを廃止した場合に影響を及ぼすのは、

  • 1. 通信プロトコルにUDPやICMPなど、TCP以外のものを使用している
  • 2. かつ、ヘッダーを含むデータがIPv6で最低保証されているMTU（1280バイト）よりも大きくなる通信を実行する可能性がある
の双方に該当するプロトコルということになります。

会議では、これら二つの条件を満たすプロトコルとして、DNSSECとSIIT（RFC 6145）があるのではないかという指摘がされました。

議論された回避策

DNSでは、512バイトを超えるUDPのデータを取り扱うためのEDNS0という仕組みが標準化されており、現状において上記1と2の双方に該当する大きなUDPのデータが、DNS応答に含まれています。そのため、IPv6におけるIPフラグメンテーションが廃止された場合、DNSSECなどEDNS0への対応を必須としているサービスの運用に影響を及ぼす可能性があります。

しかし、会議ではDNSSECの仕様は本来、データ通信のプロトコルをUDPに限定しておらず、IPフラグメンテーションが発生しうる場合はUDPに替えてTCPを用いるようにすることでこの問題を回避できる、というコメントが出されました。この場合、EDNS0のバッファサイズをDNSSECの仕様（RFC 4035）において要求されている最小値である1220バイト（*3）に設定し、それよりも大きなデータについてはUDPに替えてTCPを使用することになります。

(*3)
IPv6で最低保証されているMTU（1280）からIPv6のUDPヘッダーの大きさ（48）の値を引いた値（1232）を超えない、切りのいい値。

もし、特に大規模かつDNSSECに対応した権威DNSサーバーがこのような運用形態となった場合、TCP問い合わせの増加によるサーバーの負荷の上昇やそれに対応するための設備の増強などが必要になることが考えられ、DNSSECの普及を図る上での今後の要考察事項となります。

そして、会議では、文書中の表記は「Deprecate（廃止）」よりも「SHOULD NOT use（使用すべきではない）」とするのがよい、などといった意見が出され、今後、WGにおいて肯定的な形で議論を継続していくこととなりました。

saag：第一フラグメント便乗攻撃（1st-fragment piggybacking attacks）

セキュリティエリア全般にまたがる話題を横断的に取り扱うグループsaag（Security Area Advisory Group）のオープンミーティングにおいて、新たなDNSキャッシュポイズニング攻撃手法である「第一フラグメント便乗攻撃（1st-fragment piggybacking attacks）」が発表されました。

この発表は、2012年5月に発表された論文「Fragmentation Considered Poisonous」の内容に基づいており（*4）、今回の発表は、論文の著者がsaagを主催するエリアディレクターの招待を受けてのものとなっていました。

(*4)
Fragmentation Considered Poisonous
http://arxiv.org/abs/1205.4011

フラグメントされた二つ目以降のパケットを偽物に差し替え

送信元においてIPフラグメンテーションが実行された場合、受信先においてパケットの再組み立ての処理が必要になります。この処理をリアセンブリー（reassembly）といい、送信側でIPヘッダーに設定される識別（Identification）フィールドの数値によってそれぞれのフラグメントをひも付け、パケットを断片化前の状態に組み立てます。

しかし、このIdentificationの大きさはIPv4では16ビットしかなく（*5）、総当たり攻撃に対して脆弱であることが、今回の論文で指摘されました。これにより、フラグメントされた二つ目以降のパケットを偽物に差し替える形の攻撃が成立し得ます（*6）。

(*5)
IPv6ではIdentificationは32ビットであり、IPv4と比較して総当たり攻撃に対する耐性を備えています。
(*6)
実際の攻撃時には、UDP checksumにも配慮する必要があります。

この手法を悪用し、IPフラグメンテーションが発生する大きなDNS応答の二つ目以降のパケットを偽物に差し替えることでキャッシュポイズニングを成功させようという試みが、今回発表された攻撃手法の骨子です。

本件に関する今後の情報発信について

発表では、この問題を解決するためのいくつかの技術的手法も併せて示されました。しかし、この攻撃手法は現在のIPの仕様上の弱点を突いたものであり、根本的な解決は容易ではありません。なお、発表では本件に関する根本的な対策として、DNSSECの使用を挙げています。

なお、JPRSでは本件について、今後も随時情報発信を実施していく予定です。

weirds WG

weirds WGでは、現在のWHOISを置き換える登録データのアクセスに使用するプロトコルの開発、各実装の相互接続性の確認などを推進しています。

主要なTLD WHOISの現状調査・まとめ

今回のweirds WGでは、主要なTLD（今回対象となったのは124）における現在のWHOISの出力結果を集約・分析した結果をまとめた目録（draft-ietf-weirds-object-inventory）の、WGにおける今後の取り扱いをどうするかが議論されました。

会議では、この目録は他のドキュメントを作成するための下調べのみで終わらせるには惜しく、その成果をInformational RFCとして公開することが提案され、多くの同意を得ていました。

問い合わせ名からRDAPサーバーへの到達方法

現在、調査対象となる未知のドメイン名やIPアドレス・AS番号のWHOIS情報にアクセスする場合、まずIANA WHOISを検索し、その検索結果から各TLDや地域レジストリなどのWHOIS情報を、必要に応じて検索することになります。

WHOISを置き換えるRDAP（*7）においても同様の問題が発生します。すなわち、対象となる名前やIPアドレス・AS番号から、どのようにしてRDAPサーバーを発見するか（到達するか）が、重要なポイントとなります。

(*7)
）RDAPの詳細についてはFROM JPRSバックナンバー「第86回IETF Meeting報告（後編）～レジストリ関連／全体会議／Networking History BOFにおける話題から～」をご参照ください。

会議では、対象となる名前やIPアドレス・AS番号からどのような方法でRDAPサーバーに到達するかについて示した二つの提案（draft-blanchet-weirds-bootstrap及びdraft-blanchet-weirds-bootstrap-ianaregistries）が発表されました。

発表では以下の二つの方法が説明され、それぞれの方法について検討が行われました。

1. DNSベースでの検索（draft-blanchet-weirds-bootstrap）
rdap.arpaという専用のドメイン名を定義し、そのドメイン名空間にRDAPサーバーのIPアドレスを記述する方法です。例えば、以下のようになります。

  • ドメイン名：example.com → example.com.domain.rdap.arpa
  • IPv4アドレス：192.9.200.0 → 200.9.192.ip4.rdap.arpa
  • IPv6アドレス：2001:db8::/32 → 8.b.d.0.1.0.0.2.ip6.rdap.arpa
  • AS番号：65411 → 65411.autnum.rdap.arpa
2. IANAレジストリ方式（draft-blanchet-weirds-bootstrap-ianaregistries）
従来のIANAレジストリ方式と同様、TLDやIPアドレス・AS番号ごとに、RDAPの応答においてRDAPサーバーを指定する方式です。

会議では方法の検討にとどまり、方法の統一などの合意には至らず、また本提案はRDAPの問い合わせをより適切な別のサーバーにリダイレクトするための仕様（draft-ietf-weirds-redirects）とも密接に関連するため、そちらと合わせて検討を進めていくことになりました。

次回のIETF Meeting

次回の第88回IETF Meeting（IETF 88）は2013年11月3日から8日にかけ、カナダのバンクーバーで開催される予定です。

関連URI

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