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

メールマガジン「FROM JPRS」

バックナンバー：vol.136

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━2013-09-10━
　　　　　　　　　　◆ FROM JPRS 増刊号 vol.136 ◆
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

 ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┓
　　　　　　　　　　　第87回IETF Meeting報告（後編）
～DNSの運用とセキュリティにつながる話題、レジストリ関連WGにおける話題～
┗━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

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

　　　　　◇　　　　　　　　　　 ◇　　　　　　　　　　 ◇

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

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

（*1）IPフラグメンテーション
      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

　- IETF 87 - Berlin, Germany
　　http://www.ietf.org/meeting/87/
　　（IETF 87ホームページ）

　- IETF 87 Preliminary & Interim Materials
　　https://datatracker.ietf.org/meeting/87/materials.html
　　（IETF 87発表資料一覧）

  - IPv6 Maintenance (6man)
    http://datatracker.ietf.org/wg/6man/charter/
    （6man WG公式ページ）

  - Fragmentation Considered Harmful
    http://www.hpl.hp.com/techreports/Compaq-DEC/WRL-87-3.pdf
    （1987年に発表された「フラグメンテーションは有害」論文）

  - RFC 4963 - IPv4 Reassembly Errors at High Data Rates
    http://tools.ietf.org/html/rfc4963
    （2007年に発行された、IPv4におけるIPフラグメンテーションの危険性に
      ついて言及したRFC）

  - Sec Area Wiki
    http://trac.tools.ietf.org/area/sec/trac/
    （IETF Security Area公式Wikiページ、saagの公式記述あり）

  - Fragmentation Considered Poisonous
    http://u.cs.biu.ac.il/~herzbea/security/13-03-frag.pdf
    （CNS 2013において採択された論文）

  - dns-operations Info Page
    https://lists.dns-oarc.net/mailman/listinfo/dns-operations
    （DNS-OARCが主催するdns-operationsメーリングリスト）

  - Web Extensible Internet Registration Data Service (weirds)
    http://datatracker.ietf.org/wg/weirds/charter/
    （weirds WG公式ページ）

━━━━━━━━━━━━━━━━━━━━━━━━━━━【FROM JPRS】━
■会議報告：http://jprs.jp/related-info/event/
■配信先メールアドレスなどの変更：http://jprs.jp/mail/henkou.html
■バックナンバー：http://jprs.jp/mail/backnumber/
■ご意見・ご要望：from@jprs.jp

当メールマガジンの全文または一部の文章をホームページ、メーリングリスト、
ニュースグループ、他のメディアなどへ許可なく転載することを禁止します。
また、当メールマガジンには第三者のサイトへのリンクが含まれていますが、
リンク先のサイトの内容などについては、JPRSの責任の範囲外であることに
ご注意ください。
その他、ご利用にあたっての注意事項は読者登録規約にてご確認ください。
http://jprs.jp/mail/kiyaku.html
━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
編集・発行：株式会社日本レジストリサービス（JPRS）
http://jprs.jp/
Copyright(C), 2013 Japan Registry Services Co., Ltd.