7年ぶりの日本開催2009年11月、広島市のANAクラウンプラザホテルで第76回IETFミーティングが開催された。日本で開催されるのは2回目で、前回の2002年7月横浜開催以来、7年ぶりとなる。参加登録者数はプレナリーでの発表時点(11月10日)で1,106名、そのうちの日本からの参加者の割合は34%で、米国の27%を抜いて1位であった。Awardの初の授賞式が行われたことや、インターネットへの接続が広帯域でかつ大変安定しており好評であったこと、そして参加者メーリングリストでの決め細やかな対応など、日本における開催という意味で、印象深いIETFミーティングであった。本節では、第76回IETFミーティングのセキュリティエリアのWGの動向をまとめる。WGは、インターネットにおけるX.509ベースのPKIについて策定を行うことを目的として、1995年に設置されたWGである。Management)の仕組みの確立といった課題がある。Santesson氏を含め、ベテランの参加者がI-Dの作成に取り組んでいるという状況がある。WGミーティング(2009年11月)までの間に、以下のドキュメントがRFCとなった。[1]電子証明書に入るSubjectの公開鍵アルゴリズムとして、楕円曲線暗号を使えるようにするRFC。Menezes-Qu-Vanstone)の3種類について定義されている。Partyが識別できるようにするため、関連する電子証明書を結びつける識別子を格納できる拡張フィールドを定義したRFC。MLで収集されたS/MIMEのメールを検証するなどの作業が行われた。今後、RFC5280の大きな変更は行わず、Errataに基づく修正のみでDS化の提案が行われる。Requirementを踏まえ、インタードメイン・ルーティングにおけるセキュリティアーキテクチャの検討を行うWGである。Callがかけられたドキュメントが現れてきた。[5]セキュア・ルーティングを実現するためのアドレス資源の割り振り構造に従ったPKIの定義を行っているドキュメントである。PKI)という用語が出てくる。[6]RPKIのCP(証明書ポリシー)を定義したドキュメントである。後半にWGドキュメントになっていない、2つの話題について議論された。Kent氏の提案である。Anchorとなる電子証明書を用意し、プライベートアドレス等も扱えるようにするものである。WGと同様にベテランの少数のメンバーが提案と議論を行っている状況であり、今後、より実現性の高めるために、ルーティングの技術者も議論に参加することが望まれている。テクニカルプレナリーテクニカルプレナリーはIRTFの報告や、IETFミーティング参加者全体での技術的なトピックについて議論が行われる全体会議である。今回は、国際化ドメイン名に関する議論が行われた。台湾ではドメイン名の35.2%が、韓国ではドメイン名の13.7%がIDNとして登録されているようで、今後コード体系が多いことによる問題、例えばWebのセキュリティやあいまいさを避けるために、複数のコードを混在させるのではなく、UTF-8に限定するなどの対策が必要であるというプレゼンテーションがあった。この他に、.ARPAゾーンにおけるDNSSEC導入のスケジュールがIABのチェアから発表された。この発表によると2009年第4四半期に設定を開始し、2010年第2四半期に本番投入できるように計画を進めているとのことであった。Group)ミーティングに触れておきたい。IEPGミーティングは、IETFミーティングの初日、IETFの受付が開始する前に行われるミーティングである。IEPGミーティングは、開催日程からしてIETFミーティング参加者を対象としたものであるが、ミーティングの趣旨はプロトコルの策定とは離れている。Registry)の活動状況など、国際的なインターネットの運用に関する話題が多い。今回のIEPGミーティングのアジェンダの中でインターネットの運用上のセキュリティに関連するものを以下にまとめる。2009年のインターネット運用上のセキュリティの話題を少しずつ取り出して集めたようなアジェンダであった。ICANNルートゾーンを提供するルートDNSサーバにおいて、DNSSECを導入する計画の発表である。out”(署名レコードの影響を考慮した段階的な提供)が行われる。2010年7月に完了する予定である。Labsと呼ばれる研究グループの紹介である。Labsは、IPアドレスに関する登録情報とトラフィックデータを元にした、様々な分析ツールをWebで開発・公開していく活動グループである。2008年にあったYouTubeの経路ハイジャック事件以降、インターネット上のトラフィック状況などを世界地図にマッピングし、閲覧できるようにするプログラムの開発が進んできている。その活動のひとつとして捉えることができる。APNICDNSサーバにおけるTCPの通信負荷を下げられるかどうか、という観点でステートレスのTCPに関する考案である。結局、考案したステートレスTCPは大きな効果が得られないことがわかったが、DNSSECのようにTCPが使われることが想定されるDNSサーバにおいてTCPに工夫を凝らす着眼点として面白い。Base)を集約(アグリゲート)し、メモリ消費量を減らすことについての考察である。一定の効果は見られるが、アグリゲートの処理をどのタイミングで行うか、といった課題がある。UK様々なネームサーバ・ソフトウェアと組み合わせ、ネームサーバにおいてDNSSECを提供できるようにするオープン・ソフトウェアの紹介である。NLNetLabsDNSのルートゾーンにおけるDNSSECの導入に関する調査活動の中間報告である。国際化ドメイン名の導入やDNSSECの導入により、転送するデータが格段に増加するルートゾーンを提供するDNSサーバの要件等を調べることを目的としている。5010005007126)。