ニュースレターNo.28/2004年11月発行

第60回IETF

2004年8月1日（日）～8月6日（金）に米国カルフォルニア州・サンディエゴにて第60回IETF会議が開催されました。全体会議、IPv6、DNS、セキュリティ関連ワーキンググループ（以下WG）のレポートをお届けします。

1. 全体会議報告

◆概要

2004年8月1日（日）～8月6日（金）、米国カリフォルニア州・サンディエゴにあるSheraton San Diego Hotel ＆ Marinaにて、第60回IETFが開かれました。サンディエゴはアメリカ西海岸のメキシコに近くにある都市で、一年を通じて気候が温暖であることで知られているところです。しかし今回は8月でありながら、夜になると長袖が必要になるほど肌寒くなることがありました。

今回のIETF参加登録人数は1,511名でした。第59回（韓国・ソウル）の1,255名、第58回（米国・ミネアポリス）の1,233名、第57回（オーストリア・ウィーン）の1,304名に比べてやや増加していました。最も参加人数が多かったのはアメリカで、次いで日本、韓国、ドイツ、フランスと続いていました。合計で40ヶ国からの参加があったようです。

今回のIETFでは、120以上のセッションが開かれ、その中で11のBoFが開かれました。前回と同様に、Plenary（全体会議）はIETF Business MeetingとIETF Planning Meetingの二つに分かれて行われました。

◆IETF Business Meeting

IETF Business Meetingでは、今回のIETFでのネットワークに関する報告、RFC Editorからの報告、IANA^☆1による報告、IESG^☆2による報告、IESGのプロセスチーム（PROTO）の紹介、WSIS^☆3における議論の紹介、IAB^☆4からの報告が行われました。

RFC Editorからの報告では、RFC1が発行されてから2004年4月7日がちょうど35周年にあたることや、RFC2223の記述に代わる新たな著作権表示と知的所有権に関するアナウンスがありました。詳細は下記Webページをご覧ください。

RFC Copyrights: http://www.rfc-editor.org/copyright.html

IESGからはドキュメントプロセスの効率化に取り組むPROTOチームに関する報告がありました。PROTOチームとは、エリアディレクター（以下、AD）のドキュメントプロセスの一部を担うグループで、2004年1月に新設されたものです。PROTOチームに関する詳細は下記Webページをご覧ください。

IESG Process and Tools（PROTO）Team: http://www.mip4.org/proto/

◆IETF Planning Meeting

IETF Planning MeetingではIRTF^☆5のASRG^☆6 からSPAMの現状と対策に関するプレゼンテーションと、IABによるSecurity workshopに関する報告、IETFの新たなドキュメント体制チームのステータスレポート、IETFの管理組織に関するステータスレポートが行われました。

ASRGのプレゼンテーションでは、SPAMメールが、必要なメールよりも多く配送されている現状や対策、関連するプロトコルの標準化活動を行っているMARID WGの紹介が行われました。^☆7

IABのSecurity workshopに関する報告では、CERTに報告されるインシデント数の増加や詐欺行為の発生といった、量的・質的な変化、SSHやVPNといった技術の適用場面の特徴、Peer to PeerのセキュリティやDDoS、フィッシングといった問題の年代別の違いなどが紹介されました。

IETFの新たなドキュメント体制チームについては、General ADのHarald Alvestrand氏よりステータスレポートが行われました。第59回IETFの頃から始まった、ドキュメント化プロセスの効率化はICAR^☆8、NEWTRK^☆9、PROTO、EDUといったチーム（一部WG）によって進められており、それぞれの人数や活動内容のドキュメント化が進んでいるといった報告が行われました。

最後にIETFの運用組織（Administrative Group）に関して、ドキュメント化が進行中である旨の報告、コンサルタントのCarl Malamud氏の紹介、Administrative GroupがどのようにISOC^☆10と関連していくかについてのプレゼンテーションが行われました。

（JPNIC技術部　木村泰司）

2. IPv6関連WG報告

◆MULTI6（Site Multihoming in IPv6）WG

MULTI6 WGは8月2日（月）の午前中に開催されました。このWGは、IPv6インターネットに特化したマルチホーム手法の検討・標準化をその目的としています。

MULTI6 WGではIETFに先立ち、2004年6月に、同じカリフォルニア州のサンタモニカにて中間ミーティング（Interim Meeting）を実施しました。この中間ミーティングにて、前回ソウルで開催された第59回のIETFミーティングで提案された30あまりの提案を整理し、その整理に基づき今後MULTI6 WGで実施していく標準化の内容について議論をしました。その結果、マルチホーミング問題の根本的な解決を目指した、IPアドレスのホスト識別子としての機能とインターネット上の場所を示す場所指定機能を分離する手法（Wedgelayer 3.5／Fat IPと呼んでいます）にしぼって、今後WGにて検討を進めていくことになっています。

今回のミーティングでは、中間ミーティングの結果を受け、WGの文書としてRFC化を進めている文書の進捗報告（IPv4でのマルチホーミング手法の整理を実施した文書、マルチホーミングを実施する際に考慮すべき点を整理した文書、マルチホーミングの主にセキュリティの観点からの脅威をまとめた文書、IPv6におけるマルチホーミング手法を体系的に整理した文書の標準化が現在進行しています）、および、Wedgelayer 3.5／Fat IP手法の今後の進め方の議論が実施されました。次回のIETFまでに、現在提案されているいくつかの同系統提案をマージし、WGとしてのマルチホーミング手法提案を完成することを予定しています。

multi6 WG: http://www.ietf.org/html.charters/multi6-charter.html
60th IETF multi6 WG のアジェンダ: http://www.ietf.org/ietf/04aug/multi6.txt
Interim Meeting のアジェンダ: http://www.ietf.org/meetings/Interim-MTGs/Multi6-Interim.txt

◆IPv6（IP version 6）WG

IPv6のコア技術の標準化を進めているIPv6 WGのミーティングは、8月4日（水）午後の1コマ2時間でしたが、検討項目が非常に多く、活発な議論が実施されました。

今回話し合われた主なトピックスは、

IPv6近隣探索（RFC2461）、アドレス自動設定（RFC2462）等、IPv6ベーススペックRFCのドキュメント改訂
前回に引き続き、Optimistic DAD（簡易重複アドレス検出）に関する議論
IPv6のアドレス自動設定の際に利用されるパケット中の二つのフラグ（MフラグとOフラグ）の取り扱い

などです。

まず、議論のはじめに、DNSOP WGにてとりまとめを実施した、IPv6におけるDNS探索機構に関する文書について、現状報告とIPv6 WGとしての意見紹介がありました。この文書は前々から懸案事項になっている、IPv6ノードがDNSサーバを発見するための複数の提案について、三つの提案（DHCP利用、ルータ広告（RA）利用、well-knownアドレス利用）を整理、比較したもので、現在DNSOP WGにてラストコール中となっています。提案を一つか複数かにしぼるのかどうかなどといった今後の進め方について、DNSOP WGでもはっきりとした方向性は出ていませんが、IPv6 WGにおいてもWGに提案が挙がっているルータ広告を利用する手法について標準化を進めるべきかどうか結論は出ず、DNSOP WGの進捗待ち、という形になっています。

ドキュメントの改訂は、RFC2462改訂文書がWGラストコールを終了、IESG送付を実施、RFC2461、RFC2463改訂文書がIETF後WGラストコール実施予定となっています。

前回、多くの時間が割かれた Optimistic DAD（簡易重複アドレス検出）に関しては、機構としてはほぼ問題点も収束し、RFC化に向けて進めることにはなりましたが、後方互換性（既存機器に本当に影響を及ぼさないか）についての懸念が表明され、この部分に関しては継続して議論を続けていくことになっています。

アドレス自動設定において、ノードの動作を制御するルータ広告パケット中のMフラグ（Managed address configurationフラグ）、Oフラグ（Other stateful configurationフラグ）に関しては、このフラグの解釈について曖昧な点があったため、それを整理しました。ルータ広告がない場合にはどうするかなど検討もれがあり、再整理をすることになっています。

全体的に、標準における細かな部分（オプションの解釈など）の再整理、利用時の問題が中心になってきており、IPv6の標準化としては特に大きな問題はなく、順調に進んでいるという印象を受けました。

IPv6 WG: http://www.ietf.org/html.charters/ipv6-charter.html; http://playground.sun.com/pub/ipng/html/ipng-main.html
60th IETF IPv6 WG のアジェンダ: http://www.ietf.org/ietf/04aug/ipv6.txt

◆v6OPS（IPv6 Operations）WG

v6OPS WGは8月2日（月）午後と5日（木）午前に2コマ開催されました。今回、最初の予定では2コマ目が金曜日午前に割り当てられていたのですが、前回も含めここしばらく金曜日にはWGミーティングが開催されてないこともあり、既に予定を決めてしまったなど多くの変更要望があがったため、木曜日午前に2コマ目のスケジュールが変更になった、とどたばたした経緯がありました。

さて、v6OPSでは、ここ数回、IPv6への移行シナリオ、移行技術を中心に活動を進めてきました。移行シナリオのうち、特に企業向けシナリオに関しては、進捗が遅いということで早急な進行が要請されました。今回のIETF終了後、早急にRFC化に向けた作業が進められる予定です。移行シナリオ関連では、大学キャンパスネットワークのIPv6移行のケーススタディが報告されました。IPv4と比べ、アクセス制御に難点があること、PKI等、IPv6対応が必要なプラットフォームがあること、NFSやX11など、対応が未熟なソフトウェアがあることなどが挙げられており、会場からは、NFSはかなり前から対応済みであるはずだ等の意見が寄せられました。

移行技術に関しては、今回も多くの時間が割かれており、トンネル端点の自動設定、トンネルの使い方、IPsecとの併用などが議論されました。このあたりは移行に利用するISATAP／Teredooといったプロトコルの詳細を含め、延々と議論されてはいますが、利用シーンを含め、今後広範囲で使われていくとは考えにくいこと、また、日本などIPv6に早くから取り組んでいる地域ではIPv6ネイティブ接続が主流になりつつあり、利用が想定しにくいことなどの問題があります。次回のIETFでは、移行技術の取り扱いも含め今後v6OPS WGをどのような方向に進めていくかの議論が実施される予定です。

v6OPS WG: http://www.ietf.org/html.charters/v6ops-charter.html; http://www.6bone.net/v6ops/
60th IETF v6OPS WG のアジェンダ: http://www.ietf.org/ietf/04aug/v6ops.txt

（JPNIC IPアドレス検討委員会メンバー／NTT情報流通プラットフォーム研究所藤崎智宏）

3. DNS関連WG報告

◆DNSEXT（DNS Extensions）WG

前回の第59回IETFにおいてはBoFが開催されなかったDNSEXT WGですが、今回は2コマ開催されました。そのうち1コマは、DNSSEC^☆11に関する議論に費やされました。DNSSEC bisとして標準化が進められてきたDNSSECですが、基本となるドラフトがIESGのレビューに回されるなど、やっと標準化されそうです。しかし、実際の運用に際してはまだまだ普及しておらず、どうやって効率的に鍵の管理、交換、更新を行うか、不確定な部分が残されています。

今回のDNSSEC議論においても、DNSSECの普及に関して残された問題が中心となりました。まず、DNSSECを利用することのできる実装の確認と、鍵管理に利用できるツールの紹介が行われました。また、それぞれの実装がサポートしているプロトコルと、リゾルバの対応状況についても報告がありました。さらに、DNSSECの署名をアプリケーションから確認するためのAPI^☆12についても、その必要性を含めて議論されました。これらに関しては、特に明確な結論を出したわけではなく、現状の確認とさらなる調査ということで議論は終了しました。

さらに、DNSSECの鍵更新に関する手法や、NSEC^☆13をたどっていくことでゾーンに存在するレコードを全部たどることができてしまうという問題に関しても議論が行われました。これらはDNSSEC普及の大きな障害となっているという認識がWG全体にあり、解決のための手法が求められています。まだ明確な解決策は存在せず、そもそもDNSSECに求められるものはという点からも議論がなされました。

次に、DNSSEC以外で議論された事項に関して報告します。まず、draft-austein-dnsext-nsid-01に関して報告します。これはDNSOP WGにて議論された、draft-ietf-dnsop-serverid-02に関連するもので、Server IDを独立の応答として行うのではなく、EDNS0^☆14のオプションとして応答することによって、通常の名前解決応答に含ませてしまおう、というものです。また、draft-ietf-dnsext-mdns-33がようやくWGラストコールとなりました。さらに、BoFの最後には、これからDNSEXT WGが進む方向性について議論が行われました。チェアはDNSSECの鍵管理に関する事項を中心に、DNSOP WGと協力してこれからのWGを進めていきたいと考えていました。これに対して、DNSOP WGとのすみ分けはどうするのだ等の質問がなされ、DNSOP WGからの運用のフィードバックをうけて、プロトコルの標準化を行っていきたいとの意見が述べられていました。

DNSEXT WG: http://www.ietf.org/html.charters/dnsext-charter.html

◆DNSOP（Domain Name System Operations）WG

今回は、DNSOP WGとして2時間のBoFが開催されました。まず最初にWGドラフト全体の状態確認から始まり、そして個々のドラフトについて、状態が発表もしくは確認されました。今回のBoFでは、特に中心となる大きな議題はありませんでした。IPv6でのDNS運用に関連するドラフトがいくつかと、DNSの実装上の挙動や、プロトコルの制限からくる挙動に関するドラフトが主な議論となりました。また、DNSSECの運用に関連するドラフトや、すでに失効してしまったドラフトが更新されて復活したものもありました。そのうちのいくつかを報告します。

draft-ietf-dnssec-operational-practices-01
DNSSECにおける運用上の要点をまとめたドラフトです。編集的な変更のみで、そろそろWGラストコールがかかりそうでした。しかし、まだDNSSECを運用している人が少ないため、実経験に基づく運用上の注意点があれば、フィードバックしてほしいとのコメントがありました。
draft-ietf-dnsop-serverid-02
一度失効してしまったドラフトなのですが、今回復活しました。Server IDと呼ばれる、DNSサーバの識別子を取得するための機構をDNSのプロトコルに追加しようというドラフトです。これは、同一IPアドレスを複数台のDNSサーバに割り当てる、DNSのanycastサービスが普及した際に、どのDNSサーバから応答を得ているのかを識別するのに使うことができます。大きな反対意見もなく、このまま標準化が進みそうです。
draft-yasuhiro-dnsop-increasing-dns-server-01
このドラフトはまだWGドラフトではなく、さらに一度失効してしまったドラフトですが、今回復活しました。DNSゾーンに記述されるIPアドレス数が増えることによる、応答サイズの増大と、それを抑える方法について考察されたドラフトです。多くの人の関心を集めており、さらなる考察が求められていました。
draft-ietf-dnsop-ipv6-dns-configuration-01
IPv6クライアントのDNSサーバ自動設定に関して、三つの手法をまとめたドラフトです。前回のDNSOP WG BoFの大きな議題となっており、ドラフトとして発行されました。早めにラストコールをかけたいと議論されていました。

DNSOP WG: http://www.ietf.org/html.charters/dnsop-charter.html

（JPNIC DNS運用健全化タスクフォースメンバー／東京大学情報基盤センター　関谷勇司）

4. セキュリティ関連WG報告

◆PKIX（Public-Key Infrastructure （X.509））WG

PKIX WGは8月4日（水）の午前に行われました。参加者は100名ほどで、前回の約50名と少なかった状況から、通常の規模に戻りました。ただし各ドキュメントに特化した議論がほとんどであるためか、途中退席される方が見受けられました。

PKIX WGは第57回IETF以降終息に向け、既存のトピックのドキュメント化を中心に議論を進めています。最初にドキュメントステータスの発表が行われました。前回のIETF以降から今回のIETFまでに、下記のRFCが発行されました。

RFC 3739　"Qualified Certificates Profile"
RFC 3770　"Certificate Extensions and Attributes Supporting Authentication in PPP and Wireless LAN"
RFC 3779　"X.509 Extensions for IP Addresses and AS Identiers"
RFC 3820　"Internet X.500 Public Key Infrastructure Proxy Certificate Profile"

次に、提案されたWGのマイルストーンが提示されました。このスケジュールによると2005年の春までに、RFC3279とRFC3280の更新、テキスト文字列の処理、OCSPv2の拡張に関する活動を完了する予定になっています。

続いて、ドラフト・ドキュメントに関する議論が行われました。今回の議論ではLDAP^☆15関連、文字列比較ルール、RFC3280の更新、証明書検証プロトコルのSCVPといった話題がありました。

LDAPに関しては、DIT（Directory Index Tree）構造に沿った格納を行うLDAPスキーマとエントリの記述方法に関するプレゼンテーションがありました。LDAPスキーマはOpenLDAP^☆16バージョン2.2.1の設定ファイルに含まれていることが発表されていました。正式に組み込まれるのはOpenLDAP側のレビューの後であるとのことです。

文字列比較ルールについては、UTF8Stringといった文字データの種別の違いを超えた比較ルールの必要性やDCコンポーネントに対するルールなど、既存のルールとの使い分けなどについて議論が行われていました。

最後に恒例のリエゾンによるプレゼンテーションとして、韓国のKISA（Korea Information Security Agency）のTae Choi氏からPKIの為のユーザインターフェースの要件に関するプレゼンテーションと、IKEv2とOCSPを効率よく利用するためのメッセージに関してMike Myers氏によるプレゼンテーションが行われました。

PKIX WG: http://www.ietf.org/html.charters/pkix-charter.html

◆PKI4IPSEC（Profiling Use of PKI in IPSEC）WG

PKI4IPSEC WGは8月4日（水）の午後に行われました。参加者は200名程で、依然人気のあるセッションです。2004年5月に、IKEで使われる証明書プロファイルに関する提案draft-ietf-ipsec-pki-profile-04が、WGのI-Dとしてdraft-ietf-pki4ipsec-ikecert-profile-00に改訂され、さらに-01に更新されているため、多くの変更点がプレゼンテーションされました。

変更があった点は、IKEにおけるIPアドレスペイロードの書式と検証方針、一度検証された証明書の扱いや、CERTREQペイロードに含めていた識別名（DN）が鍵情報になるなど、多岐にわたっています。また-00から-01での更新では、証明書の鍵用途拡張のフィールドがある場合の解釈方法や、認証局が拡張の鍵用途拡張フィールドを加えないなど、PKIX WGの仕様を深く解釈したうえでの提案がなされていました。

この議論と平行して証明書管理の要求事項をまとめたdraft-bonatti-pki4ipsec-profile-reqts-01をWGで扱うことになり、今後、このドキュメントをもとにして議論が進められるようです。

PKI4IPSEC WG: http://www.ietf.org/html.charters/pki4ipsec-charter.html
プレゼンテーション資料・ドキュメント: http://www.icsalabs.com/html/communities/pki4ipsec/; ※コメント管理表のようなデータがありドキュメントでの対応状況が簡単に分かるようになっています。

◆MASS（Message Authentication Signature Standards）BoF

MASS BoFは、8月5日（木）の午前に開かれました。定員100名弱の部屋には入りきれないほどの人数が参加したため、大きな部屋に移動して行われるという一幕もありました。

MASS BoFで提案しているWGは、MARID WGで扱っている、認証の為のDNSレコードを利用して、メールメッセージを認証できるようにするという目標を持っています。SPAM等のメールで使われるような著名なドメイン名と似ていながら異なるドメイン名をかたった場合に、判別ができるという効果を狙っています。

このBoFでは、WGのゴールやチャーターが始めに提示され、次にDomainKeyと呼ばれる認証の為に使われる鍵の使い方や、DomainKeyを使ったメールメッセージ、MTA signatureと呼ばれる署名に関するプレゼンテーションがありました。

しかし、会場からはフィッシング（銀行などのWebサーバと似たような発信元（ドメイン名）のメールを使った詐欺行為）において根本的な解決にならない、S/MIMEとの違いは何か、といった厳しい意見が出されました。

◆その他

今回のIETFのSAAG（Open Security Area Directorate：セキュリティエリア全体会議）では、会場から認証技術とdeployment（利用・展開）に関して以下のような議論が起こっていました。

PKIの広範囲で工学的なdeploymentが必要。それには組織的な導入活動が必要。
認証の仕組みとネットワークアクセスのユーザーにとっての透過的な関連の必要性。

PKIX WGが、新たな実践面でのトピックを扱いにくくなっており、ネットワーク・プロトコルでの認証技術の利用といった実践的な話題を扱う場が、より多く必要になっている状況がうかがわれました。

セッションの最後には、エリアディレクターのSteven Bellovin氏より、次回のIETFで実践的なトピックを扱うBoFが開催されることが示唆されました。今後、認証技術のdeploymentに関する議論は、注目を集めることが予想されます。

（JPNIC 技術部木村泰司）

☆1　IANA：Internet Assigned Numbers Authority: ドメイン名、IPアドレス、プロトコル番号など、インターネット番号資源のグローバルな管理を行っていた組織
☆2　IESG：Internet Engineering Steering Group: IESGはIETFの活動と標準化プロセスの、技術的な側面についての責任を担っているグループ
☆3　WSIS：World Summit on the Information Society: 情報社会をテーマとした国連サミットで、第1回目は2003年12月にスイス・ジュネーブにて開催された
☆4　IAB：Internet Architecture Board: ISOCの下部組織で、インターネットのアーキテクチャ全般について責任を負い、IETFに対して大きな方向性を示す
☆5　IRTF：Internet Rsearch Task Forse: インターネットに関する将来の革新的な技術に関する検討を行うグループ
☆6　ASRG：Anti-Spam Research Group: http://asrg.sp.am/
☆7　MARID WG: MARID WGは、WGとしてのコンセンサスを得られなかった"Sender ID"に代わるプロトコル策定活動を、スケジュールを踏まえて実質的に実施が難しいという理由で、9月23日に終了した
☆8　ICAR：Improved Cross-Area Review: http://www.ietf.org/html.charters/icar-charter.html
☆9　NEWTRK：New IETF Standards Track Discussion: http://www.ietf.org/html.charters/newtrk-charter.html
☆10　ISOC：Internet Society: 非営利の国際組織で、インターネット技術およびシステムに関する標準化、教育、ポリシーに関する課題や問題を解決あるいは議論することを目的とする
☆11　DNSSEC：: DNSに関するセキュリティの強化を行うための拡張機能。DNSで提供する情報に電子署名を付加し、DNSを使って得られた情報と発信元にある情報との同一性を保証する
☆12　API：Application Program Interface: プログラムを作成するのに必要な関数の集まり
☆13　NSEC：Next SECure: DNSのResource Record（RR）の一つ。以前はNXTと呼ばれていたRRであり、ゾーンファイルにおける次のRRの存在を証明するためのRR
☆14　EDNSO：: Extension Mechanisms or DNS。RFC2671にて標準化されたDNSプロトコルの拡張
☆15　LDAP：Lightweight Directory Access Protocol: 高機能で複雑なX.500ディレクトリサービスプロトコルをインターネット向けに軽量化したもの。ディレクトリサービスとはネットワーク上に存在する資源を検索し、識別するためのサービスを指す
☆16　OpenLDAP：: http://www.openldap.org