English

IPng についてのセキュリティの関心事
(Security Concerns for IPng)

このメモの位置づけ

このメモは、インターネットコミュニティに情報提供するものです。これは、いかなるインターネット標準をも定めるものではありません。このメモの配布に制限はありません。

要旨

本書は、RFC 1550 への対応として、IETF の IPng エリアに提出されました。本書の公表は、この中で表明されているいかなるアイディアの IPng エリアによる受容を意味するものではありません。コメントは、big-internet@munnari.oz.au のメーリングリストに提出する必要があります。

概説と理論 English

IPng についての数多くの候補は、セキュリティの観点から何かを心配している何らかの機能を持っています。IPng が IPv4 より改善されたものであることは必要不可欠ではありませんが、IPng が物事を悪化させないことは、必須です。以下に、私は、いくつかの関心分野を概説します。場合によっては、何も手を打たない場合、セキュリティにネガティブな影響を与える機能があります。とにかくその機能を採用することが渇望されるという可能性がありますが、その場合、修正を行う活動が必須です。

ファイアウォール English

良きにつけ悪きにつけ、ファイアウォールは、今日のインターネットの機能といえるものです。ファイアウォールは、それ自体、主にネットワークプロトコルのセキュリティ問題に対応するものではありません。むしろ、ファイアウォールは、ソフトウェアエンジニアリングやシステム管理における失敗を埋め合わせるための手段です。それゆえ、ファイアウォールは、すぐには無くなりそうにありません。IPng は、ホストプログラムをバク含みにすることは少しもしません。ファイアウォールの採用を難しくするあらゆる事項は、市場において IPng を受容されにくくします。

ファイアウォールは、数多くの要件を提起します。まず、階層的なアドレス空間がなければなりません。多くのアドレスに基づいたフィルタは、アクセスコントロール判断のために IPv4 アドレスの構造を使用します。幸い、これはスケーラブルなルーティングのための要件でもあります。

ルーターは、パケットのデスティネーションアドレスにのみアクセスできればよいですが、ネットワークレベルファイアウォールは、しばしば、ソースアドレスとデスティネーションアドレスの両方をチェックする必要があります。ソースアドレスを発見することを困難にする構造は、明らかにネガティブなことです。

トランスポート層（すなわち TCP もしくは UDP）ヘッダーへのアクセスも必要があります。これは、ポート番号フィールドへのアクセス、もしくは、様々なフラグビット（特に TCP ヘッダーにある ACK ビット）へのアクセスである可能性があります。この後者のフィールドは、入り方向と出方向のコールを区別するために使用されます。

別の傾向として、少なくとも可能性ある移行計画のひとつは、ネットワーク層パケットトランスレーター [1] を利用します。ファイアウォールを利用する組織体は、その内部ネットワークを変換するために、独自にトランスレーターを配備する必要があります。これらの組織体は、インターネットコミュニティ全体の面倒を見ることが意図された中央に配置されたトランスレーターに依存することができません。それゆえ、トランスレーターは、簡素で、多くの卑近なプラットフォームに移植可能で、かつ廉価であることが極めて重要です。（我々は、IPng への変換のために 、あまりに高い金銭的障壁を課することは望みません。）

同様に、このようなトランスレーションボックスが、ネットワーク層コネクションのロンダリングのために利用可能でないことが渇望されます。今日、攻撃を逆探知することは、相当に困難です。； 我々は、これをより困難にすべきではありません。（ターミナルサーバーには、ロンダリングのために利用可能なブランドがあります。このようなボックスをもった大部分のサイトは、そのような活動ができないように、それらを設定することを学んでいます。） 広範囲で行うロギングは、ありうる代替戦略です。

IPAE [1] は、アドレスが（これまでのところ）予約されているので、そのトランスレーション戦略について問題を持っていません。サーキットレベルトランスレーターのような、いかなるありうる代替戦略を避けることが必要不可欠です。

暗号化と認証 English

多くの人々が、IP 層における暗号化や暗号技術による認証について実験し始めています。この傾向は、続くでしょう。（また、継続する必要があります。）IPng は、本質的にであれ、重大な性能についての障壁をもたらすことによるものであれ、これをより困難にすべきではありません。

暗号化は、様々な異なる単位において行うことができます。： 「ホスト to ホスト」、「ホスト to ゲートウェイ」および「ゲートウェイ to ゲートウェイ」。これらすべてには、ユーザがいます。；IPng は、それらのどれも排除してはなりません。カプセル化とトンネリングの戦略は、問題を引き起こしやすいといえるものです。それは、パケットが暗号化を行うゲートウェイに到着したとき、パケットは、もはや、当初のソースアドレスをもっていないからです。（これは、ネットワークトポロジーにおける制約と見なされる可能性があります。そうであれ、我々は、その情報を人々に警告する必要があります。）

TUBA の移行計画 [2] におけるもののようなデュアルスタックアプローチは、各ホストについて複数アドレスをもつことを意味します。（IPAE もこの機能を持ちます。）暗号化とアクセスコントロールのインフラストラクチャは、当該ホストについて、どのスタックに属するものであれ、すべてのアドレスについて知っていることが必要です。同一のホストについて異なるアドレスを尋ねることによって認証もしくは暗号化を迂回することが可能であるようにすべきではありません。

ソースルーティングとアドレスに基づく認証 English

今日のインターネットにおけるホスト認証の支配的な形態は、アドレスに基づいたものです。すなわち、ホストは、しばしば、他のホストをそれらの IP アドレスに基づいて信頼する判断をします。（実際には、それよりも悪い状態にあります。； 多くの認証は名前に基づいており、これは、新しい攻撃の可能性を開きます。しかし、攻撃者が IP アドレスを偽ることができる場合、名前サービスを攻撃する必要がありません。）アドレスに基づく認証が機能する限りにおいて、示されたリターンルートの正確さに依存します。すなわち、パケットに偽ったソースアドレスを入れることは容易ですが、リプライは、通常のルーティングパターンに従い、普通、そのアドレスをもった実在のホストに送られます。これは、すべてではありませんが、大部分のなりすましの試みを失敗させます。

ソースルーティングが利用されている場合、問題が起きる可能性があります。ソースルートは、リプライパケットのために返されねばならないものであり、通常のルーティングメカニズムを無視し、それゆえ、アドレスに基づく認証のセキュリティを破壊します。この理由により、多くの組織体は、少なくともその境界ルーターにおいて、ソースルーティングを使えなくしています。

IPng 候補のひとつである SIPP は、重要なコンポーネントとしてソースルーティングを含んでいます。これが利用される程度に応じて、これは、アドレスに基づく認証を壊すものです。これは、悪いことではない可能性があります。実際、おそらく良いことです。しかし、SIPP が採用された場合、ソースルーティングが廃止される前に、よりセキュアな暗号技術的 な認証プロトコルが規定され、採用されることが極めて重要です。

アカウンティング English

世界の相当部分は、利用度に敏感なアカウンティングを行うことを望んでいます。これは、請求書を送るためである可能性があり、または、単にサービス品質要求について面倒を見るためである可能性があります。いずれにせよ、関連するアドレスフィールドの最終的な知識が必要とされます。これに適応するために、IPng は、「強制ではない（non-intrusive）」パケット認証メカニズムをもつ必要があります。「強制ではない（non-intrusive）」という用語によって、私は、IPng が次の必要があることを意味しています。 (a) 認証を行う必要がない中間のホップに負荷を、ほとんどもたらさない、あるいは、全くもたらさないこと。 (b) （望まれた場合）境界ゲートウェイによって削除可能であること。 (c) 関連しないエンドシステムもしくは請求システムによって無視可能であること。

参考文献

[1]	Gilligan, R., and E. Nordmark, "IPAE: The SIPP Interoperability and Transition Mechanism", 作業中, 1994年 3月16日.
[2]	Piscitello, D., "Transition Plan for TUBA/CLNP", 作業中, 1994年 3月 4日.

セキュリティについての考慮事項 English

このメモ全体が、セキュリティについての考慮事項についてのものです。

著者のアドレス

Steven M. Bellovin
Software Engineering Research Department
AT&T Bell Laboratories
600 Mountain Avenue
Murray Hill, NJ 07974, USA

電話： +1 908-582-5886
Fax： +1 908-582-3063
EMail： smb＠research.att.com

翻訳者のアドレス

宮川 寧夫
情報処理振興事業協会
セキュリティセンター

Email： miyakawa＠ipa.go.jp

Copyright (c) The Internet Society(1994).All Rights Reserved.