 |
 |
記事検索 |
イベントレポート |
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
第58回IETF報告会レポート |
||||||||||||||||||||
|
||||||||||||||||||||
|
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
||||||||||||||||||||
|
2003年11月に米ミネアポリスで行なわれた「58th IETF Meeting」での審議内容について報告を行なう「第58回IETF報告会」が、2月6日に早稲田大学理工学部で開催された。 IETFにおける審議内容は多岐に渡るが、今回の報告会ではその中でも特にIPsecやMobile IPv6、ENUM等といった技術の標準化動向についての最新動向が報告された。本稿ではその中から主だったものを紹介する。 IPsecはプロトコルの改訂作業が進む
現在一般的にIPsecと言うと、1998年に発行されたRFC2401をベースにしたもの（第2版）が広く使われているが、この第2版にはまだ仕様に曖昧な点が残っており、実装によって相互接続性に差がある状態は解消されなかった。また、第2版で標準の暗号プロトコルとして利用されているDES暗号が解読され、安全性が確保できなくなったことに加え、第2版の発行から既に5年以上が経過している。このことから、RFC2401をベースに改訂を行なった第3版を策定しようという動きが活発化し、この度内容がほぼ合意に達したという。 第3版の具体的な変更点としては、IPsecで使われるAH（Authentication Header）やESP（Encapsulating Security Payload）の両プロトコルにおいて、高速回線を利用した再送攻撃を防ぐためにカウンタのビット長を拡大する措置が取られた。そのほかにも、暗号プロトコルとして新たにAESを標準として導入し、当面は3DESの実装を必須とするものの、将来的にAESへの移行を促すことが決められた。またDESについては第3版で「実装すべきではない」と定められ、利用が推奨されないことが明確化されたとしている。 認証アルゴリズムにおいても、新たにAES-XCBC-MAC-96（RFC3566）が導入される一方、第2版で導入されたHMAC-MD5-96（RFC2403）が「実装してもよい」にステータスが落とされるなど、かなりの変更が加えられているという。それ以外にも、従来実装依存になっていた部分の仕様の明確化、より実環境を考慮した形での記述の変更・追加などが行なわれているという。 また、IPsecにおいて暗号鍵の交換プロトコルとして使われるIKE（Internet Key Exchange）についても、従来のプロトコル（IKEv1）では仕様が複雑なわりに肝心なところの記述が曖昧だったため、実装に混乱が起きていたという事情から、この度IKEv1とは互換性のない新たな鍵交換プロトコル（IKEv2）を作り直し、間もなくRFCとして発行される予定になっているとのこと。基本的に、IKEv2はIKEv1と比べて「VPNに重点を置いた設計」（坂根氏）になっているほか、ヘッダやメッセージ交換などの単純化が図られているという。 それ以外にIKEv2ではNAT越えなどの機能が追加されているほか、認証終了までの処理を全てステートレス化した点なども大きな違いとなっているが、一方でIKEv2に関しては一部Microsoftなどの保有する特許に抵触している部分があるとの情報もあり（ただし詳細は今のところ不明とのこと）、坂根氏は「特許問題については、どうなのか私も知りたいくらいだ」と語っていた。
Mobile IPv6は実装を考慮した技術の検討が本格化
Mobile IPv6自体に関しては、RFC化に向けてあとはIANAによるプロトコル番号の割り当て待ちという状態で、ほぼRFC化に必要な作業は終了した状態にある。そこで現在IETFのMobile IPv6（MIP6）WGでは、Mobile IPv6におけるホームリンクの冗長性確保や負荷分散などを狙い、異なる物理リンク上にある複数のHome Agent間でHome AgentのリストやMobile Nodeのbinding状況などの情報を交換するためのプロトコルを作るための議論や、Mobile IPv6で重要な経路最適化（binding cache）を行なうべきかどうかといった情報をHome Agent側からMobile Node側に伝えるためのオプションを定義しようという議論などが行なわれている。 また実際にインターネット上において、IPv6における6boneのような形でMobile IPv6を利用した実験を行なうことも計画されているほか、プログラマー向けにMobile IPv6用のSocket APIをIPv6のAdvanced Socket API（RFC3542）の拡張として定義しようという動きなどが行なわれているとのこと。このように、Mobile IPv6に関しては長かったプロトコル自体の策定作業がようやく終了し、いよいよ実利用に向けた作業に移りつつある様子が伺える。 一方、最近Mobile IPv6関連では、主に自動車などへの応用を想定した、複数のノードを持つLAN自体が移動する場合の移動透過性の確保を目指した「Network Mobility（NEMO）」の話題が盛んだ。これについて、IETFではMIP6 WGとは別にNEMO WGが作られ、既に基本プロトコルのドラフトがWGのLast Callにかかっているという状態まで議論が進んでいる。 ただし、このNEMO基本プロトコルのドラフトに対しては、その内容に対してCisco・Nokiaの2社が出願した特許（Ciscoの特許は既に成立、Nokiaはまだ未成立）が抵触することが既に判明しており、NEMO WGとして両社に対してロイヤリティフリーでの特許の利用を認めるよう要請してきたものの、両社とも完全なロイヤリティフリーの利用を認めることには難色を示しているという。中村氏によれば、これを受けてNEMO WG内で「このままプロトコル策定作業を続ける」「特許に抵触しないよう仕様を変更する」「プロトコル策定作業自体を中止する」という3択で採決を取ったところ、「このまま作業を続ける」という意見が多数を占めたため、当面はこのまま作業を続行することになっているというが、現在のドラフトがこのままRFCとなるかは依然流動的なようだ。
関連情報 ■URL 第58回IETF報告会 http://www.iajapan.org/ietf/20040206.html ・ 構造改革に向けて動き出したIETF～2003年を振り返って（2003/12/26）
（ 松林庵洋風 ）
- ページの先頭へ-
|
