(57)【要約】【課題】ＩＰ（インターネット・プロトコル）アドレスを偽装したサービス妨害（ＤｏＳ）攻撃から防御する方法および装置を提供すること。【解決手段】本発明の例示的実施形態によれば、通信事業者は、それが指定されたＩＰ送信元アドレスの正確さを、実際に、検証することができているかどうかに基づいてＩＰデータ・パケットをマークすることを含む「プレミアム」サービスを提供する。このマーキング・フラグは、ＩＰヘッダ中のゼロ／非ゼロのサービスの種類（ＴＯＳ）フィールド値を用いて実施することができ、送信元アドレスの検証は、逆方向パス転送（ＲＰＦ）テストまたは他の類似のそのようなテストを用いて実施することができる。本明細書では、この「プレミアム」サービスを「ＩＰ  ＣａｌｌｅｒＩＤ」と呼ぶ。【選択図】図１
2005229614.tif 000002
【特許請求の範囲】
【請求項１】
ＩＰネットワークを介して送信されるＩＰデータ・パケットに含まれる指示ＩＰ送信元アドレスを認証する方法であって、
ＩＰネットワークの着信エッジで、指示ＩＰ送信元アドレスを含むＩＰデータ・パケットを受信する工程と、
前記ＩＰネットワークの前記着信エッジで受信した前記ＩＰデータ・パケットが、前記指示ＩＰ送信元アドレスで発信されたものと一致するかどうか判定する工程と、
前記ＩＰデータ・パケットの所定のデータ・フィールドが、前記ＩＰネットワークの前記着信エッジで受信した前記ＩＰデータ・パケットが前記指示ＩＰ送信元アドレスで発信されたものと一致するかどうかを表す値を含むことを保証する工程と
を含む方法。
【請求項２】
前記ＩＰネットワークの前記着信エッジで受信した前記ＩＰデータ・パケットが前記指示ＩＰ送信元アドレスで発信されたものと一致するかどうか判定する工程が、前記ＩＰデータ・パケットに対して逆方向パス転送テストを実施する工程を含む請求項１に記載の方法。
【請求項３】
前記ＩＰデータ・パケットの前記所定のデータ・フィールドがサービスの種類データ・フィールドを含み、前記ＩＰデータ・パケットの前記所定のフィールドが、前記ＩＰネットワークの前記着信エッジで受信した前記ＩＰデータ・パケットが前記指示ＩＰ送信元アドレスで発信されたものと一致するかどうかを表す値を含むことを保証する前記工程が、
前記ＩＰネットワークの前記着信エッジで受信した前記ＩＰデータ・パケットが前記指示ＩＰ送信元アドレスで発信されたものと一致しない場合、前記サービスの種類データ・フィールドがゼロ値を含むことを保証する工程と、
前記ＩＰネットワークの前記着信エッジで受信した前記ＩＰデータ・パケットが前記指示ＩＰ送信元アドレスで発信されたものと一致した場合、前記サービスの種類データ・フィールドが非ゼロ値を含むことを保証する工程と
を含む請求項１に記載の方法。
【請求項４】
前記ＩＰネットワークの前記着信エッジで受信した前記ＩＰデータ・パケットが前記指示ＩＰ送信元アドレスで発信されたものと一致するかどうか判定する工程が、
前記ＩＰネットワークの前記着信エッジで受信した前記ＩＰデータ・パケットが、前記ＩＰネットワークの前記着信エッジで受信した前記ＩＰデータ・パケットが前記指示ＩＰ送信元アドレスで発信されたものと一致するかどうかすでに判定しているピア通信事業者から受信したものであるかどうか判定する工程と、
前記ＩＰデータ・パケットの前記所定のデータ・フィールドが、前記ＩＰネットワークの前記着信エッジで受信した前記ＩＰデータ・パケットが、前記ピア通信事業者により、前記指示ＩＰ送信元アドレスで発信されたものと一致すると判定されたかどうかを表す値を含むことを保証する工程と
を含む請求項１に記載の方法。
【請求項５】
指示ＩＰ送信元アドレスを含み、その１つまたは複数が、そこに含まれる前記指示ＩＰ送信元アドレスがＩＰネットワークによって認証されているかどうかを表す印でマークされている、前記ＩＰネットワークから受信したＩＰデータ・パケットを処理する方法であって、
前記ＩＰデータ・パケットの前記１つまたは複数のそれぞれに含まれる前記指示ＩＰ送信元アドレスが、前記ＩＰネットワークによって認証されているかどうか判定する工程と、
そこに含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されているかどうかに基づいて前記ＩＰデータ・パケットの前記１つまたは複数のそれぞれを処理する工程と
を含む方法。
【請求項６】
前記ＩＰデータ・パケットの前記１つまたは複数に含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されているかどうかを表す前記印が、前記ＩＰデータ・パケットのそれぞれの所定のデータ・フィールドに含まれる値を含む請求項５に記載の方法。
【請求項７】
前記ＩＰデータ・パケットのそれぞれの前記所定のデータ・フィールドが、サービスの種類データ・フィールドを含み、前記１つまたは複数のＩＰデータ・パケットのそれぞれに含まれる前記サービスの種類データ・フィールドが、そこに含まれる前記指示ＩＰ送信元アドレスがＩＰネットワークによって認証されていない前記１つまたは複数のＩＰデータ・パケットのそれぞれにはゼロ値を含み、そこに含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されている前記１つまたは複数のＩＰデータ・パケットのそれぞれには非ゼロ値を含む請求項６に記載の方法。
【請求項８】
そこに含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されているかどうかに基づいて前記ＩＰデータ・パケットの前記１つまたは複数のそれぞれを処理する工程が、そこに含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されていない前記１つまたは複数のＩＰデータ・パケットのそれぞれを廃棄する工程を含む請求項５に記載の方法。
【請求項９】
前記ＩＰネットワークによって認証されている１つまたは複数の対応するＩＰデータ・パケットに含まれる１つまたは複数の指示ＩＰ送信元アドレスの検索を実施する工程をさらに含み、そこに含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されているかどうかに基づいて前記ＩＰデータ・パケットの前記１つまたは複数のそれぞれを処理する工程が、前記ＩＰネットワークによって認証されている１つまたは複数の対応するＩＰデータ・パケットに含まれる前記１つまたは複数の指示ＩＰ送信元アドレスの前記検索に基づき、そこに含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されている前記ＩＰデータ・パケットの１つまたは複数を廃棄する工程をさらに含む請求項８に記載の方法。
【請求項１０】
そこに含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されているかどうかに基づいて前記ＩＰデータ・パケットの前記１つまたは複数のそれぞれを処理する工程が、そこに含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されているかどうかに基づいて前記ＩＰデータ・パケットの前記１つまたは複数に優先順位をつける工程であって、そこに含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されている前記ＩＰデータ・パケットが、そこに含まれる前記指示ＩＰ送信元アドレスが前記ＩＰネットワークによって認証されていない前記ＩＰデータ・パケットより高い優先順位を持つ工程を含む請求項５に記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、一般に、インターネット・セキュリティの分野に関し、より詳細には、ＩＰ（インターネット・プロトコル）アドレスを偽装したサービス妨害（ＤｏＳ）攻撃からの防御の問題に関する。
【背景技術】
【０００２】
今日のインターネットでは、通信事業者から顧客にパケットが配信されるとき、それがどこから来たかについての正確な情報はない。パケット・ヘッダ中の送信元ＩＰアドレスは偽造され得る（サービス妨害攻撃ではしばしば偽造される）。過去に、この問題を解決しようとするいくつかの試みがある。
【０００３】
１つの従来技術の解決法は、顧客が（おそらく、管理されたサービスとして）、当分野の技術者にはよく知られているＩＰｓｅｃ（ＩＰセキュリティ）ＶＰＮ（仮想私設ネットワーク）ハードウェアを導入し、暗号化によって、事実上、インターネットを横切るポイントツーポイント・パスを創出することである。これは安全であるが、悪意のあるパケットを発見し、廃棄するために、なお、労力が費やされねばならない。
【０００４】
第２の従来技術の解決法は、ＢＧＰ（境界ゲートウェイ・プロトコル）ＶＰＮを使用するものであり、その場合、顧客別仮想ルータを使用してトラフィックが分離される。これも機能し得るが、一般に、複雑さはセキュリティの敵であるとみなされ、関与するＢＧＰへの大幅な拡張は、決して単純とはいえない。
【０００５】
第３の従来技術の解決法は、通信事業者が、よく知られており、例えば、ＩＥＴＦ（インターネット技術標準化タスクフォース）ＲＦＣ（コメント要求）２２６７に記載されている、完全なイングレス・フィルタリングを提供することである。実際には、これが意味するのは、通信事業者が、一定の範囲に及ぶその顧客のための１組のアドレスを持つはずであるということである。各顧客接続では、その顧客に属する送信元アドレスを有するパケットだけが入ることを許される。インターネットの残りの部分へのピアリング接続では、その通信事業者の範囲内の送信元アドレスを持つ任意の着信パケットは、廃棄される。このようにして、顧客は、そのアドレスが正しい範囲内にある限り、受信するパケットの送信元アドレスを信頼していればよい。
【非特許文献１】ＩＥＴＦ  ＲＦＣ２２６７
【発明の開示】
【発明が解決しようとする課題】
【０００６】
しかしながら、偽造パケットが正当に使用されることもあり、そのため、イングレス・フィルタリングの教条主義的実施は問題を生じるであろうが、それは、おそらく、すでにネットワーク・アドレス変換により生じている問題よりは少ないであろう。さらに困難な問題は、世界中の通信事業者により一般に広く配備されるのが、（論理的には）可能であるにしても、はるか遠い先になることである。イングレス・フィルタリングが普及しない理由の一部には、（ｉ）それが通信事業者への収益の流れを提供しないこと、（ｉｉ）通信事業者が非対称経路指定を危惧していること、および（ｉｉｉ）それが、非常に広範に配備されない限り、効果が薄いことが含まれる。
【課題を解決するための手段】
【０００７】
本発明は、前述の問題に対する新規の解決法であって、有利に好ましくは、漸進的に配備され得る解決法を提供する。本発明の若干の例示的実施形態によれば、通信事業者は、それが実際にその送信元アドレスを検証できているパケットをマークすることを含む「プレミアム」サービスを提供する。そのような一実施形態によれば、このマーキング・フラグは、パケットの送信元アドレスが検証されている場合に限り、ＩＰヘッダ中のサービスの種類（ＴＯＳ）フィールドを非ゼロに設定することにより実施される。本明細書で使用する場合、「フラグ」またはデータ「フィールド」の「マーキング」および「設定」という用語は、単に、所与のフラグまたはデータ・フィールドが、実際に、所望の値（例えば、ゼロまたは非ゼロ）を含むことを「保証する」行為を意味するものにすぎず、所望の値がそのフラグまたはデータ・フィールドにアクティブに書き込まれるかどうか、あるいは、まず、そのフラグまたはデータ・フィールドの現在の値がチェックされ、次いで、現在の値が所望の値ではない場合に限り上書きされるかどうかは問わないことに留意されたい。また、本明細書では、そのような（プレミアム）サービスを「ＩＰ  ＣａｌｌｅｒＩＤ」と呼ぶことにも留意されたい。というのは、それが、電話の送信元アドレス（すなわち電話番号）を識別する従来の電話技術のＣａｌｌｅｒＩＤと同様の意味で、ＩＰパケットの送信元アドレスを正確に識別する（すなわち検証する）からである。
【０００８】
例えば、本発明の一例示的実施形態によれば、逆方向パス転送（ＲＰＦ）その他のテストに合格できなかった顧客アクセス・リンクから通信事業者のネットワークに入ってくるどんなパケットも、好ましくは、そのＴＯＳフィールドがゼロ値に設定されているはずであり、そのようなテストに合格したパケットは、好ましくは、そのＴＯＳフィールドが非ゼロ値に設定されているはずである。（当分野の技術者にはよく知られているように、逆方向パス転送テストは、ネットワークの入口ポートにおいて、所与の識別された送信元アドレスを持つ着信パケットが、仮に、それがその識別された送信元アドレスと同じ宛先アドレスを持つ発信パケットであった場合に経路指定されたはずの同じポート上で、実際に、受け取られていることのチェックを含む。）また、本発明の一例示的実施形態によれば、非ゼロ値（例えば、値１）は、ＴＯＳフィールドが（例えば、サービス品質などのために）まだ何らかの非ゼロ値に設定されていない場合に限り、それがＲＰＦ（または他の）テストに合格した場合にＴＯＳフィールドに書き込まれる。この方式では、ＴＯＳフィールドがサービスの種類要求の指定に使用されていて、送信元アドレスが、実際に、検証できなかった場合、その点において無効になってしまう。
【０００９】
さらに、本発明の一例示的実施形態によれば、やはり、本発明の実施形態を実施しているピア通信事業者から着信するパケットは、好ましくは、それ以上のチェックなしで受け入れられるはずである。しかしながら、非参加ピア通信事業者からのパケットは、好ましくは、ＴＯＳフィールドがゼロに設定されているはずである。というのは、そのような場合には起点となる送信元アドレスが検証できないからである。
【００１０】
前述の本発明の例示的実施形態によれば、本技術の使用により生じる１つのあまり大きくない副作用は、偽造された、またはその可能性のある一方で高いサービス品質を保持することを求めるパケットに不利に働くことである。しかし、好ましくは、例えば、前述の（ＩＥＴＦ２２６７に記載されている）より厳格なイングレス・フィルタリングの従来技術の手法とは異なり、パケットがネットワークによって廃棄されることは絶対になく、したがって、どんな既存のアプリケーションも破壊されることはない。
【００１１】
前述の本発明の例示的実施形態を実施する際に最も高くつく部分は、アクセス回線上の着信パケットのＲＰＦ（または他の）テストであり、これを効率よく実施するルータはすでに存在していることに留意されたい。また、本発明の実施形態の実施は、例えば、ＩＰｓｅｃの使用など、前述の従来技術の手法のいくつかと両立しないものではなく、実際、本発明の使用は、ＩＰｓｅｃトンネルをサービス妨害攻撃からより防御しやすくし得ることにも留意されたい。
【発明を実施するための最良の形態】
【００１２】
図１に、本発明の例示的実施形態によるＩＰ  ＣａｌｌｅｒＩＤサービスを使用して経路指定され得る典型的なＩＰ（インターネット・プロトコル）データ・パケットの例示的構造を示す。この例示的ＩＰデータ・パケットは、そのパケットがＩＰｖ４（バージョン４）プロトコル・データ・パケットであることを示すデータ・フィールド１１の表示から始まる。データ・フィールド１２は、本発明の一部の例示的実施形態では、送信者がサービス品質情報（すなわち、送信者により提供される所望の、または必要とされるサービス品質レベル）を示すために使用し得るサービスの種類（ＴＯＳ）値を含む。本発明の（例えば、サービス品質情報が提供されない）他の例示的実施形態では、ＴＯＳフィールドは、送信者により単に空白のままとされ得る。
【００１３】
最後に、例示的ＩＰデータ・パケットのデータ・フィールド１３には、送信元アドレスが指定される。このアドレスは、パケットの発信元ＩＰアドレスを識別することになっている。しかしながら、ＩＰアドレスを偽装したサービス妨害攻撃からパケットが悪意を持って生成されたときなど、一定の状況では、データ・フィールド１３に示された送信元アドレスが、実際には、誤っている（「偽装されている」）ことがある。
【００１４】
図２に、本発明の例示的実施形態によるＩＰ  ＣａｌｌｅｒＩＤサービスを提供する２つの通信事業者を含む例示的ネットワーク環境を示す。図に示す例示的環境は、例えば、偽の（「スマーフ」）送信元アドレスを持つＩＰパケットを通信事業者Ａのネットワーク２３に送信することによりサービス妨害攻撃を行おうとする（悪意の）「スマーファ」２１を含む。具体的には、これらのパケットは、ネットワーク２３のエッジ（周辺）ルータ２３Ａにより受け取られる。ネットワーク・エッジ・ルータ２３Ａ（ならびに図に示す他のネットワーク・エッジ・ルータすべて）は、当分野の技術者によく知られている境界ゲートウェイ・プロトコル（ＢＧＰ）ルータとすることができる。
【００１５】
一方で、（正当な）システム２２は、本物の（すなわち正しい）送信元アドレスを持つ正当なＩＰパケットを通信事業者Ｂのネットワーク２４に送信する。具体的には、これらのパケットは、ネットワーク２４のエッジ（周辺）ルータ２４Ａにより受け取られる。また、ＩＰパケットが、一般に、（信頼されない）インターネット２５から到着し、例えば、ネットワーク２４のエッジ（周辺）ルータ２４Ｃにより受け取られる可能性もある。（図には、エッジ・ルータ２３Ｂおよび２４Ｂも示されている。これらは、必要に応じてネットワーク２３とネットワーク２４の間のＩＰパケット交換に使用され得る。）
【００１６】
本発明の例示的実施形態によれば、通信事業者Ａおよび通信事業者Ｂは、（プレミアム）顧客２６に「プレミアム」ＩＰ  ＣａｌｌｅｒＩＤサービスを提供する。特に、顧客２６に転送されるＩＰパケット２６は、パケット中で識別されるその送信元アドレスが「検証」されている場合に限り、そのＴＯＳデータ・フィールドが非ゼロに設定されている。図示のように、例えば、（悪意の）スマーファ２１により送信された「スマーフ」ＩＰパケットは、その対応するＴＯＳフィールドがゼロ値に設定されて顧客２６に転送され、例えば、（正当な）システム２２により送信された正当なパケットは、その対応するＴＯＳフィールドが非ゼロ値に設定されて顧客２６に転送されることになる。
【００１７】
本発明の他の例示的実施形態では、ＴＯＳフィールド以外のデータ・フィールドを用いて送信元アドレスが検証されているか否かの表示を提供し得ることに留意されたい。例えば、ＩＰデータ・パケット中の任意の他に使用されない（１ビットまたは複数ビットの）フィールドが、送信元アドレスが検証されているか否かに基づいてゼロまたは非ゼロ（例えば１）に設定される「フラグ」として使用され得る。
【００１８】
図３に、本発明の例示的実施形態によるＩＰ  ＣａｌｌｅｒＩＤサービスを提供するように着信パケットを処理する例示的方法の流れ図を示す。図３の例示的方法は、好ましくは、ネットワークによる着信ＩＰパケットの受信に応答して、ネットワーク・エッジ（周辺）ルータにより用いられ得る。
【００１９】
具体的には、（図のブロック３１に示すように）ＩＰパケットがエッジ・ルータにより受け取られた後で、（図のブロック３２に示すように）所与のＩＰパケットが、実際に、識別された送信元アドレスから来ているかどうか検証するために、ＲＰＦ（逆方向パス転送）テストまたは他の類似のそのようなテストが実施される。（逆方向パス転送テストは一般に行われており、当分野の技術者にはよく知られている。）判断３３で、ＲＰＦ（または他の）テストが成功したかどうか判定し、そうでない場合、ブロック３６で、ＴＯＳフィールドをゼロ値に設定する。送信元アドレスが、実際に、ＲＰＦ（または他の）テストに合格した場合、判断３４で、そのＴＯＳフィールドがゼロ値を持つかどうか判定し、そうである場合、ブロック３５で、ＴＯＳフィールドの値を１に設定する。最後に、送信元アドレスが検証されているか否かに基づき、ＴＯＳフィールドを非ゼロ値またはゼロ値に設定して、パケットが転送される（図のブロック３７）。
【００２０】
ＴＯＳフィールドがサービス品質のために使用されている場合には、本発明のこの例示的実施形態によれば、送信者により提供されたどんな非ゼロＴＯＳ値も、送信元アドレスが検証され得る限り妨害されないことに留意されたい。言い換えると、検証されないＩＰパケットだけが、その必要とされるまたは要求されるサービス処理品質の指示を失うことになる。また、前述したように、本発明の他の例示的実施形態によれば、ＴＯＳフィールド以外のＩＰデータ・パケットのデータ・フィールドを使用して、送信元アドレスが検証されているか否かを表示することもできることにも留意されたい。
【００２１】
図４に、本発明の例示的実施形態による、図３に示す例示的方法のものなど、本発明の例示的実施形態によるＩＰ  ＣａｌｌｅｒＩＤサービスを提供する通信事業者により有利に処理されている、宛先で受信したパケットを処理する例示的方法の流れ図を示す。このパケットをブロック４１で受信し、判断４２で、受信したパケット中のＴＯＳフィールドの値をチェックする。ＴＯＳフィールド値がゼロである場合、そのＩＰ送信元アドレスは検証されていないため、パケットは拒絶され、廃棄される（ブロック４６）。
【００２２】
他方、ＴＯＳフィールドがゼロでない場合、好ましくは、受け入れ可能な、かつ／または受け入れ不能な既知のアドレスを含む表から、（検証された）送信元アドレスが検索される（ブロック４３）。次いで、判断４４で、ブロック４３で実施された検索に基づき、その送信元アドレスが受け入れ可能か、それとも受け入れ不能か判定する。それが受け入れ可能である場合、パケットが受け入れられ、転送される（ブロック４５）。そうでない場合、それは拒絶され、廃棄される（ブロック４６）。
【００２３】
本発明の若干の例示的実施形態によれば、図４に示す例示的方法の表検索は実施されないことに留意されたい。そうではなく、パケットは、単に、ＴＯＳフィールド値がゼロかそれともゼロでないかだけに基づいて受け入れられ（転送され）、または拒絶され（廃棄され）る。また、本発明の若干の他の実施形態では、ＴＯＳフィールドの値に関わらず、すべての受信パケットが受け入れられる。しかしながら、これらの実施形態によれば、データ・パケットは、好ましくは、送信元アドレスが検証されているか否か（例えば、ＴＯＳフィールド値がゼロかそれともゼロでないか）に基づいて優先順位をつけられる。この方式では、どんなパケットであれ失われることはないが、サービス妨害攻撃の一部として送信されたものなどの「スマーフ」パケットには、より低い優先順位が与えられ、したがって、（サービス妨害攻撃の目標である）正当なデータ・パケットの処理を妨害する効果が極めて低くなる。
【００２４】
詳細な説明への追補
前述の説明はすべて、単に、本発明の一般的原理を示すためのものにすぎないことに留意すべきである。本明細書に明示的に説明、図示されてはいないが、当分野の技術者は、本発明の原理を実施し、その精神および範囲内に含まれる他の様々な構成を考案し得ることが理解されるであろう。また、本明細書で示したすべての例および条件的文言は、主として、読者が、本発明の原理および当分野の発展のために発明者により示された概念を理解するのを支援する教育のためのものにすぎないことが明確に意図されており、そのように具体的に示す例および条件に限定するものではないと解釈すべきである。さらに、本明細書で本発明の原理、態様、および実施形態、ならびにその具体例を示すすべての記述は、その構造的均等物と機能的均等物の両方を包含することが意図されている。また、そのような均等物は、現在知られている均等物と、将来開発される均等物の両方、すなわち、構造に関わらず、同じ機能を実施する任意の開発された要素を含むことも意図されている。
【図面の簡単な説明】
【００２５】
【図１】本発明の例示的実施形態によるＩＰ  ＣａｌｌｅｒＩＤサービスを使用して経路指定され得る典型的なＩＰ（インターネット・プロトコル）データ・パケットの例示的構造を示す図である。
【図２】本発明の例示的実施形態によるＩＰ  ＣａｌｌｅｒＩＤサービスを提供する２つの通信事業者を含む例示的ネットワーク環境を示す図である。
【図３】本発明の例示的実施形態によるＩＰ  ＣａｌｌｅｒＩＤサービスを提供するように着信パケットを処理する例示的方法を示す流れ図である。
【図４】本発明の例示的実施形態による、図３に示す例示的方法のものなど、本発明の例示的実施形態によるＩＰ  ＣａｌｌｅｒＩＤサービスを提供する通信事業者により有利に処理されている、宛先で受信したパケットを処理する例示的方法を示す流れ図である。
【図１】
2005229614.tif 000003
【図２】
2005229614.tif 000004
【図３】
2005229614.tif 000005
【図４】
2005229614.tif 000006