ニュースレターNo.25/2003年11月発行
第57回IETF
2003年7月13日から18日にかけて、オーストリア・ウィーンにて第57回IETF会議が開催されました。DNS・レジストリ関連WG、IPv6関連WG、セキュリティエリアWGのレポートをお届けします。
コンピュータがずらりと並ぶIETF会場のターミナルルーム |
1. DNS・レジストリ関連WG報告
◆IEPG(Internet Engineering and Planning Group)Meeting
IEPGではRIR(地域インターネットレジストリ)やTLDの活動報告などが行われます。最近ではDNSの運用状況と不正な経路情報の抑制に関する報告が多く行われるようになっています。DNSも経路制御もインターネットの重要な基盤技術ですが、その安定運用のためにはまだまだ成熟が必要であり、数多くの事例研究と情報交換が必要です。IEPGはそのための場として活用されています。
ところでみなさんBogonという言葉はご存知でしょうか。私はあまり経路制御について詳しくないので今回はじめて知ったのですが、経路制御の世界では広告可能アドレスとして登録されていないアドレスブロックやAS番号が広告されている状態をBogonと言うそうです。インターネットでは結構な数のBogonが観測されているとのことで、自分の使用しているアドレスがBogonであると気づいたらすぐに直して欲しいという呼びかけが行われました。
また、IANAおよびRIRにおけるIPv4アドレスの最新の割り振り状況とBGPのアドレステーブルに現れるアドレスブロックの状況から、IPv4アドレス枯渇は2028年1月と予測されたが、その予測方法の正当性について検証して欲しいという発表がありました。IANA予測は2019年で約10年の差がありますが、IANAでの割り振りが終了してもRIRには残存プールがあり、さらにRIRでの割り振り後も実際に使われるまでの時間差を考慮した結果そうなったとのことです。さて、24年後は遠い未来でしょうか、それとも近い将来でしょうか。
IEPGで発表された資料
http://www.potaroo.net/iepg/july-2003/
◆DNS関連WG
DNS関連WGは、前回同様DNSEXT(DNS Extensions)とDNSOP(DNS Operations)のWG Meetingが開催されました。
DNSEXT WGではまずWGチャーターの更新案についてチェアから説明が行われました。更新案の骨子はDNSSECにより焦点を絞っていくこと、既存のProposed/Draft Standard RFCのステータスを進めること、新しい作業項目の設定を注意深く行うこと、などです。
その後、マルチキャストDNSやDNSSECなどのInternet Draft(以下、I-D)の更新状況が作者から解説されました。また、RFC2845(TSIG)をProposed StandardからDraft Standardにするためヨーロッパを中心に行われた相互接続性試験についての報告が行われました。
DNSOP WGでは、後述の「2. IPv6関連WG報告」にある議論に続いて、Root DNSサーバに.localという存在していないTLDの問い合わせが3000回/秒以上来て問題になっているので、あえてどこかに.local TLD DNSサーバを設置し、Root DNSサーバの負荷を軽減したいという提案が行われました。この提案はDNSOP WGの作業項目として合意され、今後検討が進められていくことになりました。
DNSEXT WG
http://www.ietf.org/html.charters/dnsext-charter.html
DNSOP WG
http://www.ietf.org/html.charters/dnsop-charter.html
◆レジストリ関連WG
レジストリ関連WGとしては、現在主要なWG I-DがRFC発行待ちのPROVREG(Provisioning Registry Protocol)WGは開催されず、CRISP(Cross Registry Information Sharing Protocol)WGは開催されました。
CRISP WGではCRISPの要求条件を満たすプロトコルとして、LDAP(Lightweight Directory Access Protocol)をベースとしたFIRSという提案と、XMLをベースとしたIRISという提案のどちらをWGの選択とするか、議論が行われました。会場では実装が存在しているIRISへの支持が上回っていましたが、その場では結論は出さず、最新のI-Dが出てからMLで結論を出すことになりました。
※CRISPについての詳細は「インターネット10分講座:CRISP & EPP」をご覧ください。
CRISP WG
http://www.ietf.org/html.charters/crisp-charter.html
◆ENUM WG
ENUM WGでは、まず最初にENUM登録情報をWhoisやCRISPで参照できるようにするべきかが議論されました。イギリスではno whoisで検討が進められているとのことでしたが、会場では参照できるべきともそうでないともどちらも多数の支持はなく、合意は得られませんでした。
また、ENUMにおけるセキュリティとプライバシーに関する考察について解説が行われました。今後は、セキュリティはプロトコル・実装的な観点から、プライバシーはデータの取り扱いという観点から、それぞれ分けて議論しようという提案が行われました。
今回のENUM WGでは韓国、イギリス、スウェーデン、オーストリアでのトライアル状況の報告が行われました。どの国でも電話会社よりはインターネット関連組織が積極的に進めているという状況とのことです。韓国およびオーストリアは会場で実際にENUMアプリケーションのデモを行い、参加者から大きな拍手を受けていました。
ENUM WG
http://www.ietf.org/html.charters/enum-charter.html
◆IDN(Internationalized Domain Name)関連最新情報
IDN WGは、RFC3490-3492の3本のStandard Track(Proposed Standard)RFCを発行して終了しましたが、IDN WGでは解決しなかった言語や地域性に依存する問題は、IDN登録時のガイドラインで解決する方式が継続して議論されています。これはWGの活動ではありませんので、I-Dとしては個人(Individual)となってしまいますが、CJK(ここでは漢字)圏のガイドラインとしてdraft-jseng-idn-admin-04が、汎用のガイドラインとしてdraft-klensin-reg-guidelines-00とdraft-hoffman-idn-reg-00が発行されています。
IDNではCJK圏が先行してきましたが、現在ヨーロッパ圏でも精力的に検討が進められており、登録ガイドラインの存在はますます重要になっていくでしょう。
((株)日本レジストリサービス 米谷嘉朗)
2. IPv6関連WG報告
昨今では、IPv6に関連するトピックスが非常に多くのWGで議論されるようになりました。その中からIPv6 WG、v6OPS WG、DNSOP WG、MULTI6 WGについて紹介します。
◆IPv6 WG(IP version 6 WG)
従来、IPNGと呼ばれていたWGです。今回は、
- IPv6のサービス実施の際に重要になる、プロバイダからユーザーにIPv6アドレスプリフィクスを自動的に払い出す際に利用される「プリフィクス委譲」プロトコルに対する要求条件
- IPv6ノードに対し、そのノードの名前等を問い合わせるプロトコル
の文書についてWG内部での合意が得られ、RFC化に向けて前進しています。また、ここ数回のIETFで継続的に議論されている、サイトローカルアドレスの廃止関連で2コマ目の大部分の時間を使いました。サイトローカルアドレスが廃止(利用停止)となることは決定していますが、今回は、
- サイトローカルアドレスの代替となるアドレスに関し、要求条件の整理
- 要求条件を満たすアドレスとしての、「一意ローカルIPv6ユニキャストアドレス(Unique Local IPv6 Unicast Address)」の提案
- サイトローカルアドレスを利用停止とすることに関する文書に関する提案
の各々が議論されました。ローカルで自由に使えるアドレスは重要であり、IPv6普及の阻害要因とならないように、早急な標準化が望まれます。
IPv6 WG
http://www.ietf.org/html.charters/ipv6-charter.html
http://playground.sun.com/pub/ipng/html/ipng-main.html
◆v6OPS WG(IPv6 Operations WG)
v6OPS WGでは、IPv6導入シナリオ、IPv4 NAT利用時にIPv6トンネルを張るための方法、ノードでIPv6機能をデフォルト有効にすることに関する是非等について議論がありました。
IPv6の導入シナリオに関しては、v6OPS WGのメインの議題としてWG開設当初より引き続き議論されています。シナリオの対象として、第三世代携帯電話関連(3GPP)、ISP、企業、SOHO等unmanaged(管理者不在)ネットワークの四つを挙げ、それぞれのネットワークにおけるIPv6導入のための問題点、利用できる移行技術等を明示することでIPv6の導入を促進することを目的としています。個々のシナリオについてはまだ議論が必要で、実際にIPv6ネットワークを構築しているISP、企業からの協力が求められています。
v6OPS WG
http://www.ietf.org/html.charters/v6ops-charter.html
http://www.6bone.net/v6ops/index.htm
◆DNSOP WG(Domain Name System Operations WG)
今回DNSOP WGにて、IPv6ノードがDNSサーバのアドレスを知る方法(DNS探索)について議論がありました。IPv6ノードがDNSサーバのアドレスを知るための手法に関しては、簡易DHCPv6を使う方法が標準化されようとしています。しかしながら、より簡素なDNS探索手法が利用できる方法が好ましいという意見があり、ルータによるプリフィクス通知と同様の手段を用いてDNSサーバのアドレスを通知してはどうか、といった提案が行われました。この手法を用いることで、個々のノードにDHCP機能を実装しなくてもよいという利点があります。一方で、DNSサーバアドレス情報の取得をするために、複数の手段が乱立した場合、トラブルシューティングが困難になる、といった反対意見も出ています。DNS探索手法に関しては、今回のIETFでは明確な方向性の合意は得られず、継続して議論することになっています。
DNSOP WG
http://www.ietf.org/html.charters/dnsop-charter.html
◆MULTI6 WG(Site Multihoming in IPv6 WG)
IPv6インターネットにおけるマルチホームの実現手法を検討するmulti6 WGですが、ここしばらくは活動が低調でした。今回、久しぶりにIETFでのWGミーティングが開催され、IPv6でマルチホーミングを実現するためのさまざまな手法が提案されました。
モバイルIPやSCTPを利用する方法、ホストで経路情報を扱う方法、また、IPv4と同様にASとPIアドレスを利用する手法などが提案されましたが、どの手法も実現性において問題をはらんでいます。経路集成によるグローバルルーティングテーブルサイズの抑制を目的の一つとしているIPv6においては、IPv4のようなPIアドレス(プロバイダに依存しないアドレス)を使用したマルチホーミング手法をそのまま実施することは困難であり、スケーラビリティを考慮したマルチホーミング手法の確立が求められています。
(JPNIC IPアドレス検討委員会メンバー/NTT情報流通プラットフォーム研究所 藤崎智宏)
MULTI6 WG
http://www.ietf.org/html.charters/multi6-charter.html
3. セキュリティエリア(認証技術関連)WG報告
IKE(Internet Key Exchange)をはじめとする多くのプロトコルで、PKI(Public-Key Infrastructure)の利用方法が策定されつつある中、PKIX(Public-Key Infrastructure (X.509))WGやSMIME WGでは、PKIの相互運用性実験の話題や新しい暗号アルゴリズムの対応についての話題が挙げられていました。
◆PKIX WG
PKIX WGのセッションでは、WGドキュメントの話題として、SCVP(Simple Certificate Validation Protocol)、3279/3280 progression、LDAP(Lightweight Directory Access Protocol)specification、Qualified Certificate、Certificate Path Buildingといったことが議論されました。
SCVPは、PKIX WGで現在力を入れて議論されているオンラインの証明書検証用のプロトコルで、検証に失敗したときの状態の違いといった詳細事項が決まりつつあります。
LDAPについては、LDAPスキーマを使って証明書を格納したときの、表記・特定方法について議論されています。一部(";binary"表記を許容するかどうか)を除いてほとんどが決まっている状況です。
Certificate Path Buildingとは、証明書検証プロセスの中のパス構築(CAを含めて証明書を揃える手続き)のことで、改めてドキュメント作業を行うことが提案されています。パス構築には、証明書チェインのどちらの端から構築していくのが効率的かといった論点があります。これらをドキュメント化していくことで、パス構築の不明瞭な部分に対するガイドラインを作っていくのが目標であるようです。
新たなI-Dの話題としては、PKIで暗号アルゴリズムGOSTを利用するための方法やマルチドメインPKIにおける相互運用性に関するメモが紹介されました。マルチドメインPKIとは、日本のGPKIのように複数のPKIドメインをまたがる環境のことです。このメモでは相互認証証明書の扱いの不明瞭な部分やPKIドメインを接続する形態、問題点について整理されています。なお、このドキュメントは日本で行われた相互運用性実験、ChallengePKI 2002※1の成果の一つということができます。
PKIX WG
http://www.ietf.org/html.charters/pkix-charter.html
◆SMIME WG
SMIME WGのセッションでは、ドキュメント状況の確認と既存のRFC(3369、3370)の変更点の確認が主に行われました。これらについての論点は多くなく、アルゴリズムの追加や表記方法の変更がほとんどです。
その他に、PKIX WGでも紹介されたGOSTのCMS(Certificate Management Messages)での扱いやNIST(National Institute of Standards and Technology)でのS/MIMEのテストシステム※2が紹介されました。
SMIME WG
http://www.ietf.org/html.charters/smime-charter.html
◆RIRにおけるPKIの動向 ~IESG Meeting RIR報告より~
セキュリティエリアというわけではありませんが、IESG Meetingの中で関連のあるトピックがありましたのでご紹介します。
RIRの活動報告の中で、RIPE NCCからはX.509形式の証明書の応用が議論されているという報告がありました。つまりクライアントの認証にPKIを用いることが検討されつつあるということになります。
APNICではすでにクライアント認証にPKIを利用したページを整備しつつあり、RIRの中でPKIの利用が広がりつつあることが伺えます。報告にはありませんでしたがARINでもPKIを使ったクライアントの認証について議論が行われているようです。
(JPNIC 技術部 木村泰司)
※1 ChallengePKI 2002 報告書(情報処理振興事業協会):http://www.ipa.go.jp/security/fy14/development/pki/interop.html
※2 NIST S/MIME Interoperability Testing:http://csrc.nist.gov/pki/smime/smtest.htm