ニュースレターNo.29/2005年3月発行

第61回IETF

2004年11月7日（日）～11月12日（金）に米国ワシントンD.C.にて第61回IETF会議が開催されました。全体会議、IPv6、DNS、セキュリティ関連ワーキンググループ（以下WG）のレポートをお届けします。

1. 全体会議報告

概要

2004年11月7日（日）～11月12日（金）、米国のワシントンD.C.にあるHilton Washingtonホテルで、第61回IETFが開催されました。IETFはインターネットにおけるプロトコルの標準化を行うミーティングです。普段はMLで議論を行っていますが、1年に3回オフラインのミーティングで提案ドキュメントについての議論を行ったり、コンセンサスの確認を取ったりしています。

今回の参加者数は、26ヶ国から1314名と前回よりも参加国数、登録者数、共に少ない状況でした。国別の参加者数は、米国、日本、韓国、ドイツ、フランスの順となっており、日本からの参加者は全体の1割以上を占めていました。国際的な技術標準化の活動の場でこれほど多くの日本人が参加していることは大変素晴らしいことだと思います。

Plenary（全体会議）

今回のIETFでは、通常2回に分けて行われるPlenary（全体会議）が1回にまとめて行われました。RFCの発行前の編集を行っているRFC Editorからは、2001年には月に20程度の文書の編集依頼が来ていたが、2003年以降は平均28に増加していることやXMLを使った原稿が増えていること、新しいWord用のテンプレート^※1に対するコメントを募集していることなどが発表されていました。IANAからは、コード番号やパラメータといったIANAの判断が関連するInternet-Draft（以下、I-D）の状況を見られるWebページの紹介がありました。http://www.iana.org/reporting-and-stats/で見られます。

IESG^※2からはエリアディレクターによるI-Dの処理状況で、第60回までの増加傾向から一転し、第61回IETFまでの間はドキュメントの処理（レビュー）依頼件数が減少したことなどが発表されました。IAB^※3からは第60回IETFで説明があったIETFの運営構造の再編成^※4についての現状報告がありました。ISOCの活動としてIABやIESGをサポートし、またIETF運営の費用管理を行なう、IASA（IETF Administrative Support Activity）モデルについてのRFC（BCP^※5）が作られるようです。

次回の第62回IETFは米国のミネアポリスで2005年3月6日～3月11日に開かれる予定です。また第63回IETFはフランスのパリで、2005年7月31日～8月5日に開かれる予定です。

（JPNIC 技術部　木村泰司）

2. IPv6関連WG報告

本セクションでは、IPv6関連トピックスとしてIPv6、v6ops、Multi6のワーキンググループ（以下、WG）の動きについて報告します。

IPv6（IP version 6）WG

IPv6の基本スペックなど、コア部分の標準化を進めているIPv6 WGのミーティングは、11月11日（木）午前に1コマ開催されました。前回に比べ、アジェンダ自体はそれほど多くはありませんでしたが、大きめの部屋に溢れそうな参加者を集め、活発な議論が実施されました。

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

既存RFCのドキュメント更改
- プライバシーアドレス（RFC3041）： PS -> DS に向けた議論
- アドレス自動設定（RFC2462）： DS文書の改訂
ルータ選択機構についての議論
Multi6 WGの状況報告
始点アドレス選択ポリシーの配布機構に関する提案

などです。

ミーティングのはじめに、チェアよりIPv6 WGで扱っている各文書について、ステータスの報告がありました。IPv6 WGのWGドキュメントについては、

http://www.innovationslab.net/~brian/IETF61/IPv6/IPv6DocumentStatus.html

に非常に良くまとまっていますので、是非ご参照下さい。

既存RFCのドキュメント更改に関しては2件、ミーティングで話し合われました。いわゆるテンポラリアドレス（プライバシーを保護するために、IPv6アドレスの下位64ビットをランダムに構成する方法）を定義したRFC3041は、現在、PS（Proposed Standard）状態ですが、これをDS（Draft Standard）にするための検討が進んでおり、プライバシーアドレスをデフォルトで利用するようにするかどうか、現在別途検討が進んでいるユニークローカルアドレスの場合にもプライバシーアドレスをつけるか、などが議論されました。IPv6のベーススペックの一つである、RFC2462の改訂に関しては、エリアディレクターからのコメントを検討し、別途改訂が進行中であるRFC2461との関連を整理すること、前回のミーティングでも話題になりましたアドレス自動設定を制御するM/Oフラグの仕様明確化などを現在のドラフトに盛り込み、RFC化を進めることとなっています。

その他、WGとして取り組んでいるルータ選択ドラフトに関する議論（複数のルータが存在する場合に、ルータの優先度の指定、経路情報の伝達をする機構）ですが、経路情報の有効期限や経路の振れに関する問題等が議論され、ルータの有効時間を経路情報にも利用する等を文書に反映し、RFC化を進めることになりました。また、IPv6では一つのインタフェースに複数のIPv6アドレスが付加されることがありますが、通信の際に適切なアドレスを選択する手法についての提案がありました。こちらは、ルータ選択機構との関連を整理し、議論を継続することになっています。

IPv6 WG: http://www.ietf.org/html.charters/ipv6-charter.html; http://playground.sun.com/pub/ipng/html/ipng-main.html
第61回 IETF IPv6 WG ミーティングのアジェンダ: http://www.ietf.org/ietf/04nov/ipv6.txt

v6ops（IPv6 Operations）WG

IPv4とIPv6の共存技術／移行技術、及びIPv6デプロイメントを進めるv6ops WGミーティングは、11月10日（水）午前中に1コマ開催されました。前回のミーティングでも予告があったとおり、v6ops WGの今後の進め方が大きな議論となりました。

従来より、v6ops WGでは、IPv6移行技術（主に、IPv4ネットワークを利用してIPv6接続を実施する技術）と、IPv6ネットワークへの移行技術を並行して扱って来ましたが、そもそもIETFにおけるオペレーションエリアのWGであるv6ops ではプロトコルの標準化が主目的ではないこと、また、IPv6ネットワークの普及がある程度進んできたことにより、セキュリティなど取り扱うべき項目が増えてきたことから、移行技術を扱うWGを別途設けることになりました。新たなWGはトンネルベースの移行技術を扱うWGとして定義されており、設立に向けた準備を急ぎ実施することで合意が得られています。

この議論に多くの時間を使ったため、議題にあがっていた幾つかの項目は駆け足で概要紹介、簡単な議論となりました。その主な内容は以下の通りです。

移行技術として標準化されたRFC2766（NAT-PT）は、Experimental（実験的プロトコル）として利用しない方向にすることとなりました。
今日のブロードバンドインターネットにおいてIPv6/IPv4を共存させるための検討ドラフトですが、更にレビューをした上で、WGとして扱うことにするか否かの判断をすることになりました。

概要のみでしたが興味深いところとして、WIDEプロジェクトよりIPv6 FIXプロジェクトに関する報告がありました。これは、IPv6が普及し始めたことにより、幾つかの不具合が実際に報告されており、普及を阻害しないようにするためにも早急な対処をしていこう、というものです。このプロジェクトについては、以下のURLに概要が掲載されており、Internet Week 2004のBoF「IPv6 Fix BoF～デュアルスタックサクサクブラウジング～」でもその概要が紹介されました。

IPv6 Fixプロジェクト: http://v6fix.net
v6ops WG: http://www.ietf.org/html.charters/v6ops-charter.html; http://www.6bone.net/v6ops/
第61回 IETF v6ops WG のアジェンダ: http://www.ietf.org/ietf/04nov/v6ops.txt

Multi6（Site Multihoming in IPv6）WG

IPv6インターネットで利用可能なマルチホーム手法の検討・標準化を目的としているMULTI6 WGは、11月8日（月）の午前中及び11月10日（水）の午後の2コマ開催されました。

ミーティングでは、まずはじめにWGの四つのドラフト文書

マルチホーミングの主にセキュリティの観点からの脅威をまとめた文書
IPv4でのマルチホーミング手法の整理を実施した文書
マルチホーミングを実施する際に考慮すべき点を整理した文書
IPv6におけるマルチホーミング手法を体系的に整理した文書

について、ほぼ完成に近づいたことの報告があり、WGからのコメントを募集後、RFC化を進めることになりました。

その後、WGでデザインチームを組織して検討していたマルチホームの解法についての紹介、議論がありました。Multi6 WGとして、IPアドレスのホスト識別子としての機能と、インターネット上の場所を示す場所指定機能を分離することでマルチホーミングを実現すること、そのために、IP層とトランスポート層の間に、上位層で利用するホスト識別子と、IPアドレスをマッピングする層を設けることを基本設計とすることに決定しました。

マルチホーミング手法の基本設計が終わったことで、Multi6 WG自体は終了し、プロトコル詳細を設計／標準化するWGを別途設立することになっています。

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

Multi6 WG: http://www.ietf.org/html.charters/multi6-charter.html
第61回 IETF Multi6 WG のアジェンダ: http://www.ietf.org/ietf/04nov/multi6.txt

3. DNS関連WG報告

DNS関連のWGの中から、DNSOPとDNSEXTのWGでの議論の動向について報告します。

DNSOP （Domain Name System Operations）WG

DNSOP WGでは2時間のBoFが開催されました。今回のBoFでは、新たな話題というものは少なく、I-Dの状況報告に大半の時間が費やされました。

まず最初に、DNSSEC^※6の運用に関する情報をまとめたI-Dである、draft-ietf-dnsop-dnssec-operational-practicesに関する報告が行われました。DNSSECの最新仕様に準拠するよう改訂され、Working GroupのLast Callにむけて動いているようです。また、DNSSECにて使用されるzone署名鍵の更新に関するI-Dである、draft-ietf-dnsop-key-rollover-requirementsの状況報告もなされました。Working Group Last Callをしてもいいのではないかという意見もありましたが、まだ鍵更新に関する事象を網羅できているわけではないので、もう少し更新が必要だろうという意見に落ち着きました。なお、今回のIETFと併設してDNSSEC WorkShopも開催されていたようで、DNSSECの運用における問題点の共有がなされていたようです。

次に、IPv6におけるDNS設定の問題点を述べたdraft-ietf-dnsop-ipv6-dns-issuesの状況報告がなされていました。DNSのzoneにAAAA recordを追加する場合の注意点や、DNSサーバのIPv6トランスポートを有効にする際の注意点等、DNSをIPv6対応にして運用する際に注意すべき点について書かれたI-Dです。

今回唯一の新たな話題であったのが、draft-fujiwara-dnsop-bad-dns-authに関する報告でした。この発表では、IPv6やDNSSECの普及によって、DNSの名前解決のためにやりとりされるパケットが増大するため、TCPやEDNS0^※7による名前解決が必要になるという指摘がされました。この際、TCPは管理者の設定ミスによってフィルタされている場合があるという問題点を指摘しており、またEDNS0では、取り扱えるバッファサイズの上限を越えると結局UDPフラグメントが発生してしまう、という問題点も指摘されました。会場にて、このI-DをWG I-Dとして議論を続けていくことが合意されました。

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

DNSEXT（DNS Extensions）WG

DNSEXT WGでも、2時間のBoFが開催されました。やはり話題の中心は、DNSSECに関するI-Dでした。その中で、一番時間を割いて行われた議論は、NSEC^※8）RR（以下、RR）に関する議論でした。これは、DNSSECにてzone中にあるRRの存在を保証することによって、あるRRがzone中に存在しないことを確認するために利用されるRRで、偽のDNS応答に対する防御を行うための仕組みの一つです。しかし、現在の仕様のままでは、NSEC RRをたどっていくことによって、zone中に存在するすべてのRRがばれてしまう仕様となっています。これをセキュリティ的に問題視する人が多いため、現在の仕様のままではDNSSEC導入の障害となる、という指摘が以前からなされていました。そのため、NSECの仕様を改善しようという議論が行われました。いくつかの候補が出ており、それぞれの候補に対して、利点、欠点等が示され、解決しなければならない課題が示されました。どの案もまだ議論の途中であるため、結論は出ていません。引き続き議論が行われることとなりました。

他にも、draft-kolkman-dnsext-dnssec-in-band-rolloverやdraft-laurie-dnssec-key-distribution、個人名で出されているDNSSECに関するI-Dについて、報告がなされました。DNSSEC以外の話題としては、SenderPolicy Framework（SPF）という機構についての発表がありました。これはDNS に新しいRRを登録して、この新しいRRがzoneに登録されているホストからのメールしか受け付けないようにすることによって、SPAMを防ごうとする仕組みです。これはまだ原案段階といった感じであり、I-Dも発行されていません。全体として、やはりDNSSECの議論に終始した、という感じでした。

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

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

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

2004年12月現在、セキュリティ・エリアのWGは23あります。IETFで議論されているプロトコルの主旨や性質は多種多様なので、このように多数のWGがある状況です。WGは年単位で見ると流動的で、時間が経つと様相が変わってきます。

ここでは、セキュリティ・エリアの概況をお伝えすると共に、第61回IETFで注目したセキュリティ関連のWGやBoFの活動を報告します。

セキュリティ・エリアの概況

セキュリティ・エリアのWGは、TLS^※9やIPsec^※10といった基本となる暗号通信プロトコルの標準化の他に、暗号鍵や認証情報の扱い方としてのプロトコルの標準化を行うWGや、開発や利用の指針となる仕様としてのプロトコルを標準化するWGなどがあります。

セキュリティ・エリアのWGを大きく分けると、IPsec、PKI^※11、Kerberos^※12、それからインシデント情報に関連したWGがそれぞれ複数あり、あとは個別の仕組みのプロトコルに取り組んでいるWGがいくつかある、という状況です。IPsecに関連したWGはIPSEC、IPSECKEY、IPSP、MOBIKE、PKI4IPSEが挙げられます。PKIに関連したWGには、PKIXの他に、PKIを利用してそれぞれのサービスを実現するためのプロトコルを扱うLTANSやSMIMEがあります。最近作られたWGの中でも活発なPKI4IPSEは、IPsecの利用しやすくするため、VPNといった利用条件を決め、PKIの併用方法（プロファイル）の標準化を検討するのを主な目標としたWGです。

近年のセキュリティ・エリアでは、セキュリティの為の基本的なプロトコルの標準化よりも、それらを活用して、いかにサービスとして動かしていくか、という主旨をターゲットにしたWGが活発に活動しています。今回のIETFで開かれたEasycert BoFは、より実践的な知見を集めて、PKIを簡単に使えるようにしようという主旨のBoFであり、最近の動向を象徴した活動だと言えます。一覧は以下URLでご覧いただけます。

Active IETF Working Groups - Security Area: http://www.ietf.org/html.charters/wg-dir.html

セキュリティに関連したWGとBoF

今回はPKIX、Easycert BoFについて報告致します。

▼PKIX（Public-Key Infrastructure）WG

PKIX WGは11月10日（水）の午後1時から行われました。参加者は60名程でした。

はじめにドキュメントステータスの確認が行われました。今回のIETFまでに、RFC3874"A 224-bit One-way Hash Function: SHA-224"が発行されました。以下の三つのI-DはIESGによって承認され、RFC Editorの編集待ちの状態にあります。

- "Additional Algorithms and Identifiers for RSA Cryptography"
- "Internet X.509 Public Key Infrastructure -- Certificate Management Protocol（CMP）"
- "Internet X.509 Public Key Infrastructure Permanent Identifier"

"Internet X.509 Public Key Infrastructure : Certification Path Building"を始めとする6つのI-Dがエリアディレクターによるフォローかコメントを待っている状態です。"Simple Certificate Validation Protocol"（SCVP）の第16版はWG Last Callがかけられました。

今回のセッションではSCVPの16版（draft-ietf-pkix-scvp-16.txt）、RFC3280の改良、CRL（Certificate Revocation List）の発行者を特定するための拡張フィールド（AIA: Authority Information Access）、CRLの検証ルール、証明書とCRLを格納するLDAPのスキーマ、簡易版のOCSP、ECCアルゴリズム識別子など、多くのプレゼンテーションが行われました。大きな動きのあった、SCVPとCRLの拡張フィールドについて紹介します。

SCVPの16版は、CA証明書のフルサポートを始め、様々な機能追加や文書の変更がありました。基本的な記述作業は一段落したようです。

CRL発行者を特定する仕組みの必要性は、MLで必要性が指摘されたものです。今回の提案は認証局と鍵を特定できるよう、AIAに識別の為の値をいれることです。

リエゾンによるプレゼンテーションは、韓国KISAのBaehyo Park氏によって"User Interface Requirements for PKIX"と題して行われました。証明書を扱うGUIの要件について紹介するため、SSL/TLSに加えてオンライン取引に使用するといったデモが行われました。

WGチェアのTim氏によると、LDAPスキーマ関連のドキュメントやRFC3279/3280の改良は2005年の春までに完了させる予定だそうです。PKIX WGのクローズに向け、ラストスパートをかけている様子です。

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

▼Easycert（Easy-to-Use Certificates）BoF

Easycert BoFは、前回のIETFのセキュリティ・エリア会議（SAAG）で挙がった“PKIの利用が広まらない状況を踏まえて実践的な議論を進めるべき”という指摘を受け、エリアディレクターのSteve Bellovin氏、Russ Housley氏がチェアとなって開かれました。180名近い参加者がいて、会場の部屋は超満員の様子です。

このBoFの主旨は、PKIの成功した導入事例から使いやすさの要素を洗い出し、その上でIETFとしてできる活動を明らかにする、というものです。BoFでは、マサチューセッツ工科大学（MIT）とJohnson＆Johnの事例が紹介されました。いずれの事例紹介でも話題になったのは、失効方法（CRLを使っているか）と証明書管理モデルの妥当性です。どの事例でも、証明書は基本的に認証用に用いており、CRLに頼らず、サービスシステム側で認証用のデータベースを持っていました。米国防総省（DoD: Department of Defence）で発行されたCRLは40メガバイトにもなったという話も挙がっていました。

これらの事例紹介に対し、会場から出る意見は多く、活発に議論が行われました。PKIを簡単にする観点については、ISPが証明書を発行してはどうか、PKIはフォーマットが複雑なのが問題、といった意見が出ました。

IETFとしてできる活動については、色々な場面で使えるような認証のブートストラッピング（初期立ち上げ）のプロトコルを標準化してはどうか、といった意見が出てました。この他に認証時にどのクライアント証明書を使うべきなのか戸惑う、といった意見があり、TLS WGへのフィードバックになるといったコメントが返されていました。しかしIETFでできる活動の方向性を見出すまでの議論には発展しませんでした。

今後はより多くの事例を集め、PKIのガイドブックとなるInformational RFCを作ることを目指す、ということになりました。この作業はIABのEric氏が担当することになりました。

Easycertは、MLでの議論も平行して行われています。Easycert MLについては"Easycert -- Easy-to-Use Certificates"をご覧下さい。

Easycert - Easy-to-Use Certificates: https://www.machshav.com/mailman/listinfo.cgi/easycert

その他

今回のIETFのセキュリティエリア会議（SAAG）で、Steven Bellovin氏がエリアディレクターを引退することが発表されました。後任には、MITのSamHartman氏が着任することになりました。

IETFはプロトコルの標準化を目的とする活動ですが、議論の中で運用面／利用面の意見が重要なフィードバックとなります。特にPKIの議論に関して、利用経験のある日本の方が標準化活動に参加することで、RFCに知見を盛り込み、利用性向上を図る活動の牽引力になるのではと思いました。

（JPNIC 技術部　木村泰司）

※1　RFC Templates and Info. （Joe Touch氏のページの一部）: http://www.isi.edu/touch/tools/
※2　IESG: Internet Engineering Steering Group: IESGはIETFの活動と標準化プロセスの、技術的な側面についての責任を担っているグループ。IESGのメンバーは、IETFの複数のWorking Groupで文書のレビューを行ったり、WGの方向性について助言を行っているArea Directorで構成されている。
※3　IAB: Internet Architecture Board: IABは、インターネットの技術コミュニティ全体の方向性やインターネット全体のアーキテクチャについての議論を行う技術者の集団。ISOCの技術理事会（Technical Advisory Group）としても機能し、インターネットを支える多くの重要な活動を監督する。
※4　IETF AdminRest Homepage: http://www.alvestrand.no/ietf/adminrest/
※5　BCP: Best Current Practice: インターネットの運用方法について、論点やコンセンサス事項を示したり、IETFの運用プロセスを示したりする種類のRFCのこと。RFCには他にInformational（情報）、Experimental（実験的）、Historical（歴史的）という種類がある。; http://www.nic.ad.jp/ja/newsletter/No24/090.html
※6　DNSSEC：: DNSに関するセキュリティの強化を行うための拡張機能。DNSで提供する情報に電子署名を付加し、DNSを使って得られた情報と発信元にある情報との同一性を保証する。
※7　EDNS0：: Extension Mechanisms or DNS。RFC2671にて標準化されたDNSプロトコルの拡張。
※8　NSEC：Next SECure: DNSのResource Record（RR）の一つ。以前はNXTと呼ばれていたRRであり、ゾーンファイルにおける次のRRの存在を証明するためのRR。
※9　TLS: Transport Layer Security: TCPなどのトランスポート層プロトコルの上位プロトコルで、暗号化や双方向の認証を実現する。TLSやSSLを併用したHTTPは、httpsと表記される。
※10　IPsec: Security Architecture for Internet Protocol: IPsecは、暗号技術を使ってIPパケットの完全性や機密性を実現する仕組み。IPv4ではオプションとなっているが、IPv6では実装が必須とされている。
※11　PKI: Public Key Infrastructure: PKIとは、公開鍵暗号技術と電子署名を使って、インターネット上で安全な通信が行えるようにするための環境のことである。なりすましやデータの盗聴・改竄を防ぐためのインフラとして近年注目が高まっている。
※12　Kerberos:: マサチューセッツ工科大学（MIT）のAthenaプロジェクトで開発された認証システム。telnetやftpを始め、複数のプロトコルに対して共通の認証と暗号化の機能を提供する。