JP2011509539A - プロキシを通じて接続されたホスト間の安全なネイバディスカバリ - Google Patents

プロキシを通じて接続されたホスト間の安全なネイバディスカバリ Download PDF

Info

Publication number
JP2011509539A
JP2011509539A JP2010532680A JP2010532680A JP2011509539A JP 2011509539 A JP2011509539 A JP 2011509539A JP 2010532680 A JP2010532680 A JP 2010532680A JP 2010532680 A JP2010532680 A JP 2010532680A JP 2011509539 A JP2011509539 A JP 2011509539A
Authority
JP
Japan
Prior art keywords
host
proxy
address
layer
message
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2010532680A
Other languages
English (en)
Other versions
JP5255065B2 (ja
JP2011509539A5 (ja
Inventor
クリシュナン、スレッシュ
Original Assignee
テレフオンアクチーボラゲット エル エム エリクソン(パブル)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by テレフオンアクチーボラゲット エル エム エリクソン(パブル) filed Critical テレフオンアクチーボラゲット エル エム エリクソン(パブル)
Publication of JP2011509539A publication Critical patent/JP2011509539A/ja
Publication of JP2011509539A5 publication Critical patent/JP2011509539A5/ja
Application granted granted Critical
Publication of JP5255065B2 publication Critical patent/JP5255065B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/02Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0281Proxies
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/12Applying verification of the received information
    • H04L63/126Applying verification of the received information the source of the received data
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W12/00Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/10Integrity
    • H04W12/106Packet or message integrity
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/08Network architectures or network communication protocols for network security for authentication of entities
    • H04L63/0823Network architectures or network communication protocols for network security for authentication of entities using certificates
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/14Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441Countermeasures against malicious traffic
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04LTRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00Network architectures or network communication protocols for network security
    • H04L63/16Implementing security features at a particular protocol layer
    • H04L63/162Implementing security features at a particular protocol layer at the data link layer
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W8/00Network data management
    • H04W8/26Network addressing or numbering for mobility support
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W80/00Wireless network protocols or protocol adaptations to wireless operation
    • H04W80/04Network layer protocols, e.g. mobile IP [Internet Protocol]
    • HELECTRICITY
    • H04ELECTRIC COMMUNICATION TECHNIQUE
    • H04WWIRELESS COMMUNICATION NETWORKS
    • H04W88/00Devices specially adapted for wireless communication networks, e.g. terminals, base stations or access point devices
    • H04W88/18Service support devices; Network management devices
    • H04W88/182Network node acting on behalf of an other network entity, e.g. proxy

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)

Abstract

ホストがプロキシを通じて接続される場合にホスト間のネイバディスカバリ(ND)信号送信の安全を確保する方法、プロキシ、ホストが提供される。第1ホストが、第1ホストのアドレスに基づく第1署名を含む元のNDメッセージを送信する。プロキシは、第1ホストのアドレスを削除し、修正したNDメッセージにおいて第1ホスト自体のアドレスを代用する。プロキシは、第1ホストのアドレスのコピーを新たなフィールドに配置し、プロキシ自体のアドレスと新たなフィールドとに基づくプロキシ署名を構成する。新たなフィールドおよびプロキシ署名は、修正したNDメッセージに追加される。第2ホストが、修正したNDメッセージをプロキシから受信し、プロキシ署名を検証する。第2ホストは下のNDメッセージコンテンツを再構成し、第1署名を検証する。

【選択図】図4c

Description

本発明は、ディスカバリメッセージについて安全にプロキシを行う方法、プロキシ、およびホストに関する。
パケット交換コンピュータネットワークにおいて、ホストやルータなどのノードは、ネイバディスカバリ(ND:neighbor discovery)信号送信を使用して、付されたリンクに存在することがわかっているネイバのリンクレイヤアドレスを決定する。単一のリンクを越えてネットワークを存在させるには、ブリッジを使用して、共通リンクを共有しないサブネットワークを接続するのが一般的である。NDプロキシが、複数のリンクを単一のネットワークにブリッジする方法を提供する。NDプロキシを通過するND信号送信を修正することで、NDプロキシはブリッジを行う。IETF(Internet Engineering Task Force:インターネットエンジニアリングタスクフォース)は、「Neighbor Discovery Proxies (ND Proxy)(ネイバディスカバリプロキシ(NDプロキシ))」という題名のRFC4389というRFC(Request For Comments:リクエストフォーコメンツ)を公開しており、ここには、複数のリンクレイヤセグメントがプロキシを通じて単一のセグメントにブリッジされる方法が記載されている。RFC4389はICMP(Internet Control Message Protocol:インターネット制御メッセージプロトコル)を規定している。ICMPを使用すると、ブリッジの片側のホストが、アドレシング情報を交換して、IP(Internet Protocol:インターネットプロトコル)アドレスとMAC(Media Access Control:媒体アクセス制御)アドレスとの間のブリッジングを作成することができる。MACアドレスは、リンクレイヤアドレスやレイヤ2アドレスとしても知られている。図1(先行技術)は、NDプロキシ180として動作するブリッジを通じて接続された2つのサブネットワーク110および150を含んだ単純なネットワーク100を示している。サブネットワーク110は第1リンクレイヤ接続130を備えており、第1ホスト120などの複数のホストが第1リンクレイヤ接続130に接続されている。同様に、サブネットワーク150は第2リンクレイヤ接続170を備えており、第2ホスト160などの複数のホスト第2リンクレイヤ説即170に接続されている。NDプロキシ180は、第1リンクレイヤ130と第2リンクレイヤ170とにそれぞれ接続されたポートを備えている。リンクレイヤの1つに対する各接続はMACアドレスを備えている。ゆえに、第1ホスト120は、第1リンクレイヤにMACアドレスを有しており、第2ホスト160は第2リンクレイヤ170にMACアドレスを有しており、NDプロキシ180は、各リンクレイヤにそれぞれ1つずつ、2つのMACアドレスを有している。第1ホスト120が最初は第2ホスト160のMACアドレスを知らずに、第2ホスト160に接続するためには、第1ホスト120は、第1ホスト120のIPアドレスおよびMACアドレスと第2ホスト160のIPアドレスとを含んだネイバソリシテーションメッセージをブロードキャストする。NDプロキシ180はこのネイバソリシテーションメッセージを受信し、内部キャッシュに第1ホスト120のMACアドレスを記憶することもできる。NDプロキシ180は、メッセージ内の第1ホスト120のMACアドレスを第2リンクレイヤ170のNDプロキシ180のMACアドレスで置き換えた後、ネイバソリシテーションメッセージを第2リンクレイヤ170に転送する。第2ホスト160は、第1ホスト120のIPアドレスを、第2リンクレイヤ170のNDプロキシ180のMACアドレスと関連させてネイバキャッシュに記憶する。そして、第2ホスト160は、第2リンクレイヤ170におけるネイバアドバタイズメントメッセージで応答する。ネイバアドバタイズメントメッセージは、第2ホスト160のIPアドレスおよびMACアドレスと、任意で第1ホスト120のIPアドレスおよび第2リンクレイヤ170のNDプロキシ180のMACアドレスとを含む。NDプロキシ180は、第2のホスト160のネイバアドバタイズメントメッセージを検出し、第2ホスト160のMACアドレスを、第1リンクレイヤ130のNDプロキシ180自体のMACアドレスで置き換え、含まれている場合は第2リンクレイヤ170のNDプロキシ180自体のMACアドレスを第1ホスト120のMACアドレスで置き換え、第1リンクレイヤ130のネイバアドバタイズメントメッセージを転送する。第1ホスト120は、第2ホスト160のIPアドレスを、第1リンクレイヤ110のNDプロキシ180のMACアドレスと関連させてネイバキャッシュに記憶する。後に第1ホスト120が第2ホスト160のIPアドレスを使用して第2ホスト160との通信を行う必要があれば、そのネイバキャッシュが、第1リンクレイヤ130のNDプロキシ180のMACアドレスへメッセージまたはパケットを送信する必要があると示すことになる。同様に、第2ホスト160が第1ホスト120のIPアドレスを使用して第1ホスト120との通信を行う必要があれば、第2ホスト160のネイバキャッシュが、第2リンクレイヤ170のNDプロキシ180のMACアドレスへメッセージまたはパケットを送信する必要があると示すことになる。
「SEcure Neighbor Discovery (SEND)(安全なネイバディスカバリ(SEND))」という題名のRFC3971は、ネイバソリシテーションメッセージやネイバアドバタイズメントメッセージにおけるアドレスに対する悪意のある修正(なりすまし)などの特定の脅威に対してネイバディスカバリ信号送信の安全を確保する方法を規定する。SENDプロトコルは、NDパケットが改ざんされていた場合に受信ノードが検出可能な、ND信号送信の安全確保法を提供する。デジタル署名を使用して、ネイバディスカバリに関するメッセージを保護する。署名はメッセージの完全性を保護し、メッセージ送信簿との完全性を証明する証明を使用して、その送信元の完全性を認証する。実際、各メッセージは、送信元の秘密鍵と送信元のアドレスとに基づく署名を含んでいる。受信側で、送信元の秘密鍵を使用して、署名を検証することができる。送信元の秘密鍵は、受信側も送信元も認知および信頼しているトラストアンカに対するクエリを使用して、受信側に証明を与える。署名の検証は、送信元のアドレスを確認する。
図2(先行技術)は、RSA署名のフォーマットを示している。RSA署名200は、周知のRSA(Rivest-Shamir-Adleman:リベスト‐シャミール‐エイドルマン)アルゴリズムに基づいており、SENDにおいて規定されている。RSA署名200は、ND信号送信メッセージに追加される。ビットマーカ270が、RSA署名200のフォーマットに関する情報を提供する。RSA署名200に含まれるフィールドは、以下のものを含んでいる。
・タイプ210:IETFによって割り当てられ、12に等しく設定された値
・長さ220:8オクテットのユニットにおけるRSA署名200の長さ(図2の全パラメータを含む)
・予約230:将来使用するために予約されている16ビットフィールド
・キーハッシュ240:RSA署名200の構成に使用する公開鍵のSHA−1(Secure Hash Standard-1:安全ハッシュ規格−1)ハッシュの最重要(一番左)128ビットを含む128ビットフィールド
・デジタル署名250:送信元の公開鍵を以下のオクテットシーケンスに使用して構成される、PKCS(Public Key Cryptography Standards:公開鍵暗号規格)を含む長さ可変のフィールド
1.SENDプロトコル専用に定まれる128ビットCGAメッセージタイプタグ値
2.SENDプロトコルによって保護されているND信号送信メッセージのIPヘッダの128ビットソースアドレスフィールド
3.IPヘッダの128ビット宛先アドレスフィールド
4.保護されたメッセージのICMP(インターネット制御メッセージプロトコル)ヘッダの8ビットタイプ、8ビットコード、16ビットチェックサムフィールド
5.ICMPチェックサムフィールド後の第1オクテットから始まり、NDプロキシ特定パラメータまで続くがNDプロキシ特定パラメータは含まないNDプロキシメッセージヘッダ
6.RSA署名200に先行する全NDプロキシ特定パラメータ。具体的には、これらのパラメータはNDメッセージを送信するノードのリンクレイヤアドレスを含んでおり、NDメッセージが別のNDメッセージに対する応答である場合には、これらのパラメータは、メッセージの宛先であるノードのリンクレイヤアドレスも含んでいる。
・パディング260:パディングを含む長さ可変のフィールド
RSA署名200に先行する全メッセージパラメータは、デジタル署名250の計算に含まれている。結果として、これらのメッセージパラメータのいくつかを変更しようとする「man in the middle(間にいるもの)」の攻撃は、受信ノードが署名を検証すれば、すぐに検出されるであろう。
SENDおよびNDプロキシは、相反する要求に基づいているため、基本的には互換性がない。一方で、今日規定されるように、SENDについては、IPアドレスのアドバタイズメントを行うノードがIPアドレスの所有者であり、アドバタイズメントが行われたIPアドレスに基づいてデジタル署名を生成するのに使用する秘密鍵を所有していると想定する。他方で、NDプロキシでは、最初にそのIPアドレスのアドバタイズメントを行い、そのIPアドレスとMACアドレスに基づいてデジタル署名を作成したノードのMACアドレスは、NDメッセージ内で、プロキシのMACアドレスで置き換えられる。アドバタイズメントを行う元のノードのデジタル署名は、MACアドレスが上書きされているため、そのMACアドレスに対して受信側では検証することができない。NDプロキシがあれば、実際には元のND署名を修正したのは真正プロキシであるのに、悪意のあるノードが元のND信号送信を改ざんしたかもしれないと、受信側のSENDプロトコルが推察するであろう。RFC4389は、「NDプロキシ」を規定するもので、SEND RFC3971の後、2006年4月に公開されたものであるが、プロキシネイバディスカバリ処理の保護に使用可能な機構はないと明確に記述している。プロキシオペレーションはRSA署名を無効にするものであり、NDメッセージを受信するSEND可能ノードに、そのNDメッセージを破棄させたり、あるいはそのNDメッセージを安全ではないものとして処理させたりしてしまう。
方法、プロキシ、ホストを有することで、ブリッジ、プロキシ、またはルータを通じて、ネイバディスカバリメッセージのプロキシを安全に行うことが可能になるという明らかな効果があろう。
したがって、本発明の広い目的は、ホストがプロキシを通じて接続されている場合に、ホスト間のネイバディスカバリ(ND)信号送信の安全を確保する方法、プロキシ、ホストを提供することである。本発明は、NDプロキシがNDメッセージにおけるリンクレイヤアドレスをNDプロキシ自体のもので置き換えることができる方法を提供する。このように修正されたアドバタイズメントを受信するノードは、NDプロキシが変更を行うことを許可されているかどうか検証する。この検証について、ノードは、NDプロキシに発行された証明に依存して、このような変更を許可する。NDプロキシングは、プロキシを通過するNDメッセージの元のコンテンツを修正し、それによって送信元ホスト署名を壊し、本発明のプロキシは、元のコンテンツを、修正前にそれらを新たなメッセージフィールドに移すことで保存する。プロキシは、プロキシを通過するNDメッセージにプロキシ署名を追加する。それにより、修正したNDメッセージの正当性を受信ホストが検証することができる。受信ホストは、新たなメッセージフィールドを使用して、NDメッセージの元のコンテンツを再構成し、それによって送信元ホスト署名を修復することができる。
本発明の第1の観点は、プロキシを通じて接続されたホスト間のネイバディスカバリの安全を確保する方法に対するものである。当該方法は、プロキシが、第2ホストを宛先としたネイバディスカバリ(ND)メッセージを第1ホストから受信すると開始する。NDメッセージは、第1ホストのインターネットプロトコル(IP)アドレスおよびレイヤ2アドレスと、第1ホストのレイヤ2アドレスに少なくとも部分的に基づいて第1ホストによって構成された第1署名とを含む。プロキシは、まずは第1ホストのレイヤ2アドレスをプロキシのレイヤ2アドレスで上書きして、NDメッセージを修正する。プロキシは、さらに、プロキシの第2署名を挿入することによってNDメッセージを修正する。プロキシ署名は、プロキシのレイヤ2アドレスに少なくとも部分的に基づく。そして、プロキシは、修正したNDメッセージを第2ホストへ送信する。
本発明の第2の観点は、プロキシを通じて接続されたホスト間のネイバディスカバリの安全を確保する方法の変更例に対するものである。当該方法はいくつかの追加ステップを含む。プロキシは、修正したNDメッセージの追加フィールドに第1ホストのレイヤ2アドレスをコピーし、その追加フィールドを使用して、プロキシの第2署名を計算する。第2ホストは、修正したNDメッセージを受信すると、プロキシの第2署名を検証する。第2ホストは、さらに、プロキシのレイヤ2アドレスを第1ホストのレイヤ2アドレスで上書きすることによって、NDメッセージをその元の形態に戻す。ゆえに、第2ホストは、第1ホストの第1署名を検証することができる。第2ホストは、第1ホストのIPアドレスを、プロキシのレイヤ2アドレスと関連させて記憶する。
本発明の第3の観点は、ホストにおいてネイバディスカバリ(ND)メッセージを安全に受信する方法に対するものである。当該方法は、プロキシのレイヤ2アドレスと、ピアホストのレイヤ2アドレスと、ピアホストの署名と、プロキシの署名とを含むNDメッセージをホストが受信すると開始する。ホストはプロキシの公開鍵を使用して、プロキシの署名を検証する。そしてホストは、プロキシのレイヤ2アドレスをピアホストのレイヤ2アドレスで置き換えることによって、NDメッセージを修正する。これにより、ホストは、ピアホストの公開鍵を使用して、ピアホストの署名を検証することが可能となる。2つの署名の検証に続いて、ホストは、ピアホストと通信するためのレイヤ2アドレスとしてプロキシのレイヤ2アドレスを記憶する。
本発明の第4の観点は、プロキシに対するものである。当該プロキシは、第1ホストからネイバディスカバリ(ND)メッセージを受信するのに使用する第1レイヤ2接続を有する。また、当該プロキシは処理部も有する。処理部は、第1レイヤ2接続からNDメッセージを受信し、少なくとも1つの元のアドレスを含む第1フィールドと、第1ホストの第1署名を含む第2フィールドとをNDメッセージから読み出す。そして、処理部は、受信したNDメッセージから少なくとも1つの元のアドレスを第3フィールドへコピーすることで、NDメッセージを修正する。次に処理部は、第1フィールドにおいて少なくとも1つの元のアドレスのうちの1つをプロキシのアドレスで上書きする。処理部は、プロキシのアドレスと、少なくとも1つの元のアドレスとに基づくプロキシの第2署名を挿入する。そして処理部は、第2レイヤ2接続に命令し、修正したNDメッセージを第2ホストへ送信させる。
本発明の第5の観点は、ホストに対するものである。当該ホストは、ピアホストの公開鍵と、プロキシの公開鍵と、ピアホストと通信するためのレイヤ2アドレスとを記憶する記憶部を備える。当該ホストは、プロキシからネイバディスカバリ(ND)メッセージをリンクで受信するレイヤ2接続を有する。NDメッセージは、プロキシのレイヤ2アドレスと、ピアホストのレイヤ2アドレスと、ピアホストの署名と、プロキシの署名とを含む。当該ホストにおいて、処理部が、プロキシの公開鍵を使用してプロキシ署名を検証する。そして処理部は、プロキシのレイヤ2アドレスをピアホストのレイヤ2アドレスで置き換えることによってNDメッセージを修正する。処理部は、さらに、ピアホストの公開鍵を使用してピアホストの署名を検証する。それらの検証に続いて、処理部は、ピアホストと通信するためのレイヤ2アドレスとして、プロキシのレイヤ2アドレスを記憶する。
本発明、その目的および効果についてより詳細に理解するために、添付図面と併せて、以下の説明を参照可能である。
図1は、ネイバディスカバリプロキシとして動作するネイバディスカバリプロキシを通じて接続された2つのサブネットワークを含んだ単純なネットワークの先行技術を表す。 図2は、リベスト‐シャミール‐エイドルマン署名のフォーマットの先行技術を表す。 図3は、安全ネイバディスカバリプロキシを通じて接続された2つのサブネットワークを含んだネットワーク例を示す。 図4a、4b、4cは、本発明の方法のステップ例を表したシーケンス図を示す。 図5は、本発明のいくつかの観点によってプロキシ署名を計算する方法例を示す。 図6は、本発明のいくつかの観点によって単純化したネイバディスカバリメッセージコンテンツを示す。 図7は、本発明の一観点によって構成されたプロキシ例を示す。 図8は、本発明の一観点によって構成されたホスト例を示す。
好ましい実施形態の様々な使用例や観点を特に参照しながら、本発明の革新的開示を記載する。しかしながら、この実施形態は、本発明の革新的開示の多くの効果的用途のうちのいくつかの例だけを提供するものであるということを理解すべきである。一般に、本願明細書における記載は、必ずしも、本発明で請求する様々な観点のうちのいずれかを限定するものではない。また、ある進歩的特徴に適用可能だが、他の特徴には適用不可能である記載もある。図面の記載において、同様の番号は、本発明の同様の構成を表している。
本発明によれば、アドレス所有およびアドレスアドバタイズメントの役割は、明らかに別々のものである。標準ネイバディスカバリ(ND)プロキシの通常オペレーションは、IETF(インターネットエンジニアリングタスクフォース)のRFC(リクエストフォーコメンツ)第4389号において定義されている。本発明では、元のNDメッセージを修正する許可SENDプロキシと、同じことをする悪意のあるノードとを受信ノードが区別できることを確証する特徴をさらに備えたSEND(安全なネイバディスカバリ)プロキシが提供される。これについては、許可SENDプロキシの鍵で署名してNDメッセージを修正することによって達成される。許可SENDプロキシは、署名および修正が行われたNDメッセージに、それが置き換えたNDメッセージの元のコンテンツも含むことが好ましい。これは、受信ノードがさらなる検証に使用することができる。SENDプロキシの署名は、プロキシ署名情報(PSI:proxy signature information)という新たな情報フィールドに含めるものとすることができる。署名は、元のNDメッセージのRSA(リバスト‐シャミール‐エイドルマン)署名フィールドを含んだ、メッセージに存在するNDプロキシ情報フィールドに行われる。PSIは、好ましくは最後の情報フィールドとして、メッセージに追加される。プロキシ署名は、以下の点を除いて、図2に示したRSA署名と同様のフォーマットを有する。第1に、プロキシ署名は、図2のタイプ210の値とは異なる別個のタイプ値を有する。第2に、デジタル署名はPSIに先行する全NDプロキシ特定パラメータに基づくのが好ましいため、PSI内のデジタル署名は、RSA署名自体の一部に基づくのが好ましい。
また、Dプロキシを使用して、安全にNDメッセージのプロキシを行うことを可能にする方法と、PSI可能なホストとが提供される。
本発明において、NDプロキシは、ブリッジと、ルータと、スイッチと、その他いかなるパケット転送装置を含むものとしてもよい。SENDプロキシは、同様の物理および/またはリンクレイヤプロパティを有するサブネットワークに接続しても、同様ではない物理および/またはリンクレイヤプロパティを有するサブネットワークに接続してもよい。ある例では、SENDプロキシは、2つの別個のイーサネット(登録商標)サブネットワークを接続するものとすることができる。別の例では、SENDプロキシはWLAN(wireless location area network:無線ロケーションエリアネットワーク)とセルラ無線ネットワークとの間をブリッジするものとすることができる。ホストは、いかなる端末、エンドユーザ装置、ルータ、アプリケーションサーバなどを含むものとしてもよい。ホストは、1または2以上の物理接続と、関連リンクレイヤアドレスおよびリンクレイヤプロパティとを含んだものとすることができる。例えば、パーソナルコンピュータを、イーサネット(登録商標)接続とWLAN接続とを備えたものとして、そのどちらかを本発明に関して使用するものとすることが可能である。また、ホストは、BluetoothTMもセルラ接続も使用する移動端末を含んだものとしてもよい。
本発明の記載において、「レイヤ2(layer 2)」、「リンクレイヤ」、「MAC(媒体アクセス制御)」という用語を使用した場合、互いに置き換えることができる。
ここで図面を参照する。図3は、SENDプロキシ380を通じて接続された2つのサブネットワーク310および350を含んだネットワーク例300を示している。ネットワーク300は、本発明のある開示として構成されたノードを備える。2つのネットワーク310および350の各々はホストをサポートするものであり、第1ホスト320、第2ホスト360をそれぞれサポートする。いうまでもなく、サブネットワーク310および350はもっと多くのホストをサポートすることも可能であり、SENDプロキシ380は複数のサブネットに相互接続を提供することも可能である。図3は、本発明の説明を簡単にするために単純化してある。第1ホスト320は、MAC(媒体アクセス制御)アドレスMAC_H1を有するポートを介して、サブネットワーク310に接続されている。同様に、第2ホスト320は、MACアドレスMAC_H2を介して、サブネットワーク350に接続されている。SENDプロキシ380は、両サブネットワークに対する接続を有するため、サブネットワーク310および350にそれぞれ接続する2つのMACアドレスMAC_P1およびMAC_P2を有している。第1ホスト310、第2ホスト360、SENDプロキシ380の間のやり取りは、以下の図に関連して説明する。
図4a、4b、4cは、本発明の方法のステップ例を表したシーケンス図を示している。図3に関連して導入した第1ホスト320と、第2ホスト360と、SENDプロキシ380と、トラストアンカ400とが図4a、4b、4cのシーケンスに関与する。トラストアンカ400を図3のネットワークに追加することにより、信頼のあるインフラストラクチャの中にホスト320および360とSENDプロキシとを含めることができる。
この方法はステップ403から任意に開始するものとすることが可能であり、ここで、第1ホスト320は、SENDプロキシ380を通じて他のホストと通信する必要があることを知っており、トラストアンカ400から、SENDプロキシ380のセキュリティ証明を要求することができる。そうした場合には、トラストアンカ400は、ステップ406において、SENDプロキシ380の公開鍵を含んだSENDプロキシ380の証明で応答する。同様に、第2ホスト360も、ステップ409において、トラストアンカ400からSENDプロキシ380の証明を任意で要求することができる。そうした場合、ステップ412においてトラストアンカはSENDプロキシ380のセキュリティ証明で応答する。言うまでもなく、第1ホストおよび第2ホストは、時間を延長して、トラストアンカ400のセキュリティ証明のそれぞれの写しを記憶しておくことが可能である。したがって、ステップ403〜412については、図4a、4b、4cのシーケンスを実行する度に繰り返す必要はない。
ステップ415において、第1ホスト320は、第2ホスト360との通信を始めることを所望する。第1ホストと第2ホストとが以前に通信していた場合であっても、例えば第2ホスト360がそのレイヤ2接続を修正していることもあるため、以下で説明するND手続を再度行うのが好ましいという状況もあろう。第2ホスト360がそのレイヤ2接続を修正する例の1つとしては、イーサネット(登録商標)接続が使用されておらず、WLAN接続が第2ホスト360のトラフィックを支配しているという場合があろう。第1ホストおよび第2ホストが別個のサブネットワークに位置しているため、単純なND手続が使用不可能で、2つのサブネットワークを接続するブリッジをディスカバリ信号送信が通過する必要があり、SENDプロキシ380がブリッジ機能を提供する。ステップ418において、第1ホスト320はRSA署名を構成する。RSA署名は従来のものとして、例えば図2のRSA署名フォーマット200にしたがって構成することができる。RSA署名は、少なくとも第1ホスト320のMACアドレスMAC_H1であるSLLA(source link layer address:ソースリンクレイヤアドレス)を含む様々なパラメータにしたがって構成することができる。ステップ421において、第1ホスト320が、アドレスMAC_H1を有するポートを使用して、サブネットワーク310のリンクのネイバソリシテーションメッセージを送信する。サブネットワーク310の同一リンクに接続されたSENDプロキシ380が、SENDプロキシ380自体のMACアドレスMAC_P1を介してネイバソリシテーションメッセージを検出する。ステップ424において、SENDプロキシ380は、修正したネイバソリシテーションを第2ホスト360へ転送するのに使用するプロキシ署名を構成する。プロキシ署名は、上述のPSIフォーマットにしたがって、修正したネイバソリシテーションに追加される。
図4aのステップ424におけるプロキシ署名の構成法の詳細を図5に示す。図5は、本発明のいくつかの観点によってプロキシ署名を計算する方法例を示している。図5の方法は、さらに図6に関連して説明する。図6は、本発明のいくつかの観点による単純化したネイバディスカバリメッセージコンテンツを示す。図6を参照すると、NDメッセージ600が、元のアドレスフィールド610と、NDメッセージを発したホスト(ソースホスト)のRSA署名620を含んでいる。元のアドレスフィールド610は、ソースホストのMACアドレス612と、ソースIP614ともいうソースホストのIPアドレスと、宛先IP616ともいうNDメッセージの宛先であるホストの宛先アドレスとをさらに含む。図6に示す他のフィールドは、以下で参照する補足アドレスフィールド630とプロキシ署名640とを含む。図5の方法はステップ500から開始し、例えば図4aのステップ421のネイバソリシテーションメッセージなどのNDメッセージをSENDプロキシ380が受信する。ステップ510において、SENDプロキシ380はNDメッセージからソースMACアドレス612を読み出す。ソースMACアドレス612は、補足アドレスフィールド630に任意でコピーされ、ステップ520においてNDメッセージ600が修正される。するとステップ530において、SENDプロキシ380が、SENDプロキシ380自体のMACアドレスを元のアドレスフィールド610に書き込むことで、NDメッセージをさらに修正し、ソースMAC612を上書きする。SENDプロキシ380自体のMACアドレスは、例えば、図3に示すように、第2ホスト360と同一のサブネットワークのSENDプロキシ380のレイヤ2アドレスであるMAC_P2とすることが可能である。ステップ540において、SENDプロキシ380はプロキシ署名640を計算し、修正したNDメッセージに追加する。この署名は、SENDプロキシ380のRSA署名であることが好ましく、PSIフォーマットにしたがって構成されたものであることが好ましい。プロキシ署名640は、ステップ530で修正された元のアドレスフィールド610を含んだNDメッセージの全部の情報フィールドと、ソースホストのRSA署名620とに基づいていることが好ましい。署名は、補足アドレスフィールド630にも基づいていることが好ましい。言うまでもなく、プロキシ署名640は、他のパラメータにも基づいたものとすることも可能である。
図4a、4b、4cのシーケンスに戻ると、ステップ424においてSENDプロキシ380がプロキシ署名640を構成した後、SENDプロキシ380は、ステップ427において、第2サブネットワーク350のリンクレイヤに、アドレスMAC_P2を有するそのポートを使用してメッセージを置くことによって、修正したネイバソリシテーションメッセージを第2ホスト360へ転送する。サブネットワーク350の同一リンクに接続された第2ホストは、MACアドレスMAC_H2を有する第2ホスト自体のポートを介して、修正したネイバソリシテーションメッセージを受信する。この時点で、第2ホスト360は、任意のステップ409および412において、SENDプロキシ380の証明を事前に取得しておくことも可能である。修正したネイバソリシテーションの受信に従事する第2ホスト360に証明が存在していない場合、第2ホスト360は、ステップ430および433において証明を取得する。そしてステップ436において、第2ホスト360は、SENDプロキシ380の証明に含まれたSENDプロキシ380の公開鍵を使用して、SENDプロキシ380のRSA署名を検証する。この検証により、修正したネイバソリシテーションが真正ノードによって送信されたものであると、第2ホスト360が確かめることができる。SENDプロキシ380が、第2ホスト360が認知する信頼のあるインフラストラクチャの一部である場合、ステップ436のSENDプロキシRSA署名の検証は、修正したネイバソリシテーションのコンテンツ全体が有効であると第2ホスト360が考慮するのに十分である。そして処理は直接ステップ445へ続くものとすることができる。しかしながら、第2ホスト360が全体的にSENDプロキシ380を信頼しない場合は、ネイバソリシテーションはまた真正ノードによってもともと開始されたと検証することができる。このため、第2ホスト360がステップ439および442を実行することができる。ステップ439において、第2ホスト360は、今は元のアドレスフィールド610に存在するSENDプロキシ380のMACアドレスを、補足アドレスフィールド630にある値で上書きすることによって、元のネイバソリシテーションメッセージを再構成する。例えば、値MAC_H1を補足フィールド630から読み出し、元のアドレスフィールドへソースMAC612として戻すことができる。ステップ442において、第1ホスト320のRSA署名620が検証される。ネイバソリシテーションの元のソースMACアドレス612がメッセージにおけるその元の場所に戻されているため、この検証が可能となる。
ステップ445において、SENDプロキシRSA署名によって、または第1ホスト320のRSA署名を検証することによって、修正したネイバソリシテーションで第2ホスト360が満足すると想定すると、第2ホスト360は、例えばMAC_P2などのプロキシのMACアドレスを、第1ホスト320のIPアドレスと関連させてネイバキャッシュに記憶する。第2ホスト360は、後にこのアドレスペアを使用して、第1ホスト320と通信するであろう。第2ホスト360が以前に第1ホスト320のキャッシュエントリを有している場合は、ステップ445が、キャッシュエントリに対する更新からなる。そして第2ホスト360はステップ448においてRSA署名を構成する。ステップ418の場合のように、このRSA署名は従来のものとし、図2のRSA署名フォーマット200にしたがって構成されるものとすることができる。RSA署名は、第2ホスト360のMACアドレスMAC_H2である第2ホスト360のTLLA(target link layer address:ターゲットリンクレイヤアドレス)に少なくとも部分的に基づいて構成されるものとすることができる。ステップ451において、第2ホスト360は、アドレスMAC_H2を有するポートを使用して、サブネットワーク320のリンクのネイバアドバタイズメントメッセージ送信を行う。サブネットワーク320の同一リンクに接続されたSENDプロキシ380は、SENDプロキシ380自体のMACアドレスMAC_P2を介して、ネイバアドバタイズメントメッセージを検出する。ステップ454において、SENDプロキシ380は、修正したネイバアドバタイズメントを第1ホスト320を転送するのに使用する別のプロキシ署名640を構成する。図5に記載の方法を再度使用して、プロキシ署名640を構成する。ステップ454から、例えばTLLA MAC_H2など、ソースMAC612として元のネイバアドバタイズメントに含まれた第2ホスト360の元のMACアドレスは、修正したネイバアドバタイズメントにおける補足フィールド630へ移動され、SENDプロキシ380自体のMACアドレスがネイバアドバタイズメントのソースMAC612を上書きする。SENDプロキシ380自体のMACアドレスは、例えば、図3に示すように、第1ホスト320と同一のサブネットワークのSENDプロキシ380のレイヤ2アドレスであるMAC_P1とすることができる。また、プロキシ署名640も、2つのアドレスフィールド610および630の現在のコンテンツに基づいて追加される。修正したネイバソリシテーションの場合のように、修正したネイバアドバタイズメントは、好ましくはPSIフォーマットにしたがったプロキシ署名640を含む。
ステップ454においてSENDプロキシ380がプロキシ署名640を構成した後、SENDプロキシ380は、ステップ457において、アドレスMAC_P1を有するそのポートを使用して第1サブネットワーク310のリンクレイヤにメッセージを置くことによって、修正したネイバアドバタイズメントメッセージを第1ホスト320へ転送する。サブネットワーク310の同一リンクに接続された第1ホスト320は、第1ホスト320自体のMACアドレスMAC_H1を介して、修正したネイバアドバタイズメントメッセージを検出する。この時点で、第1ホスト320は、任意のステップ403および406において、SENDプロキシ380の証明を事前に取得しておくことも可能である。修正したネイバアドバタイズメントの受信に従事する第1ホスト320に証明が存在していない場合、第1ホスト320は、ステップ460および463において証明を取得する。そしてステップ466において、第1ホスト320は、証明に含まれたSENDプロキシ380の公開鍵を使用して、SENDプロキシ380のRSA署名を検証する。この検証により、修正したネイバソリシテーションが真正ノードによって送信されたものであると、第1ホスト320が確かめることができる。任意で、第1ホスト320は、ネイバアドバタイズメントもまた真正ノードによってもともと開始されたと検証することができる。このため、第1ホスト320がステップ469および472を実行することができる。ステップ469において、第1ホスト320は、ソースMAC612を、例えば値MAC_H2などの補足アドレスフィールド630にある値で上書きすることによって、元のネイバアドバタイズメントメッセージを再構成する。ステップ472において、第2ホスト360のRSA署名620が検証される。ネイバアドバタイズメントの元のソースMACアドレス612がメッセージにおけるその元の場所に戻されているため、この検証が可能となる。ステップ475において、第1ホスト320は、例えばMAC_P1などのプロキシのMACアドレスを、第2ホスト360のIPアドレスに関連させてネイバキャッシュに記憶または更新する。
ここで、本発明の一観点によって構成されたプロキシ例を示した図7を参照しながら、プロキシの構成例を説明する。プロキシ700は、処理部710と、少なくとも2つの接続720および730とを備える。プロキシ700は、記憶部(図示せず)を備えたものとしてもよいが、本発明の目的としては、プロキシ700のオペレーションは記憶部がなくてもよい。本発明のプロキシ700は、ネットワーキング装置の分野において周知の通常のプロキシ、ブリッジ、スイッチに見られる多くの構成をさらに備えたものとすることも可能である。これらの追加構成は、図示を簡潔なものとするため、ここでは図示していない。
処理部710は、例えば、いかなる市販のプログラム可能プロセッサを備えたものとすることも可能である。レイヤ2接続720および730の各々は、信号、メッセージ、データの受信(入力)および送信(出力)を行う1つの単一装置として実施することもできるし、個別の装置として実施することもできる。プロキシ700は、複数のホストへ接続される。プロキシ700をホストへ接続する手段は様々なものがある。例えば、あるホストへの通信を提供するあるレイヤ2接続がイーサネット(登録商標)リンクにあれば、他のリンク2接続の別のホストへの接続はATM(asynchronous transfer mode:非同期転送モード)リンクにあるものとすることができる。したがって、プロキシ700は、様々な種類の複数のリンクを接続する複数の装置を備えたものとすることが可能である。本発明を簡潔に表現するため、2つのレイヤ2接続しか図示していない。
オペレーション中、プロキシ700は、例えばMACアドレスMAC_P1のレイヤ2接続720などの第1レイヤ2接続において、NDメッセージを第1ホストから受信する。NDメッセージは、NDソリシテーションであることもあれば、NDアドバタイズメントであることもある。レイヤ2接続720が処理部710に通知する。処理部710は、第1ホストの元のMACアドレスを含んだ第1フィールドと、第1ホストの第1署名を含んだ第2フィールドとをNDメッセージからまずは読み出すことによってNDメッセージを修正する。処理部710は、修正したNDメッセージに追加される第3フィールドへ第1ホストのMACアドレスをコピーする。そして、処理部710は、MAC_P2である他のレイヤ2接続730のMACアドレスで第1ホストのMACアドレスを第1フィールドに上書きする。処理部710は、最終的に、第3フィールドの第1署名において、その現在値における第1フィールドに基づいて、修正したNDメッセージにプロキシ700の第2署名を挿入する。そして処理部710は、修正したNDメッセージを第2ホストへ第2リンクで送信するよう、第2レイヤ2接続730に要求する。
図8は、本発明の一観点によって構成されたホスト例を示している。ホスト800は、レイヤ2接続820と、処理部810と、記憶部840とを備える。ホスト800は、様々な個別の装置を表したものとすることができるため、ディスプレイ、キーボード、マウス、複数の追加プロセッサ、その他多くの構成要素(図示せず)をさらに備えたものとすることができる。処理部810は、ND信号送信専用とすることもできるし、ホスト800のその他のタスクもサポートするものとすることもできる。記憶部840は、電気的な消去およびプログラムが可能な、例えばフラッシュメモリやデータ格納モジュールとして実施することができる不揮発性メモリまたは持続性メモリである。レイヤ2接続820は、信号、メッセージ、データの受信(入力)および送信(出力)を行う1つの単一装置として実施することも、複数の個別の装置として実施することも可能である。ホスト800は、1つよりも多くのレイヤ2接続を備えたものとすることも可能である。したがって、図8は図示を簡潔にするために単純化してある。
記憶部840は、ホスト800自体に関する情報845を永久的または準永久的に記憶する。これには、例えば、レイヤ2接続820のレイヤ2アドレスMAC_Hn、ホスト800に割り当てられたIPアドレス、RSA署名の計算に使用するホスト800の秘密鍵および公開鍵などが含まれる。当技術分野においては周知のように、ホスト800に割り当てられたIPアドレスは永久的なものとすることもできれば、ホスト800が現在接続されているネットワークによって割り当てられるものとすることもできる。記憶部400は、プロキシやルータやその他のホストなど、他のノードのIPアドレス、リンクレイヤアドレス、公開鍵もテーブル847に記憶することができる。記憶部400は、当技術分野において周知の他のデータをさらに記憶することも可能である。
動作中、ホスト800は、別のホストとの通信を開始する必要がある場合、そのホストとの通信で使用するリンクレイヤアドレスを取得する必要がある。ホスト800は、ルートルックアップなどの周知手段によって、そのホストのIPアドレスを最初に取得しておくこともできる。他のホストへ導く当該リンクレイヤアドレス取得するためには、ホスト800は、そのレイヤ2接続820でNDソリシテーションを送信する必要がある。NDソリシテーションはMAC_Hnアドレスを含んでおり、MAC_Hnアドレスは、今度はこの取引においてSLLA(ソースリンクレイヤアドレス)になる。処理部810が、SSLAと、このホスト800のIPアドレスと、他のホストのIPアドレスと、ホスト800の秘密鍵とを記憶部840から読み出す。処理部は、これらのパラメータおよび他のパラメータに基づいてRSA署名を構成し、レイヤ2接続820に対して、NDソリシテーションを、それが付されるレイヤ2リンクに置くよう命令する。
レイヤ2接続820はNDソリシテーションメッセージを受信することができる。レイヤ2接続820は、このNDソリシテーションとそのコンテンツとを処理部810へ転送する。NDソリシテーションがPSIを含んでいる場合は、送信元ホストが発したNDソリシテーションはプロキシによって修正されており、NDソリシテーションに含まれたリンクレイヤアドレスはプロキシのMACアドレスであり、送信元ホストの元のアドレスではないという表示として、処理部810がPSIを検出する。処理部810はテーブル847からプロキシの公開鍵を読み出す。見つかった場合は、プロキシの公開鍵を使用して、PSIに含まれたプロキシ署名を検証する。この検証が失敗した場合、NDソリシテーションは単純に破棄される。そうでない場合は、処理部810が、NSソリシテーションを発したホストのSLLAをPSIから読み出すことが好ましいことがある。NDソリシテーション内でプロキシのMACアドレスを送信元ホストのSLLAで上書きすることによって、処理部810は、送信元ホストのRSA署名を検証することができる。RSA署名の検証には、処理部810が送信元ホストの公開鍵をテーブル847から読み出すことが必要である。RSA署名が有効であると仮定すると、処理部810は、プロキシのMACアドレスと、送信元ホストのIPアドレスとをテーブル847に記憶して、テーブル847内に送信元ホストのキャッシュエントリを作成する。そして処理部は、ホスト800自体のレイヤ2アドレスMAC_Hnを記憶部840から読み出し、TLLA(ターゲットリンクレイヤアドレス)フィールド内において、NDアドバタイズメントメッセージに配置する。プロキシのMACアドレス、ホスト800のIPアドレス、その他のパラメータも、NDアドバタイズメントに配置される。処理部810はRSA署名を計算し、NDアドバタイズメントに挿入する。そして処理部810は、レイヤ2リンクにNDアドバタイズメントを配置するようレイヤ2接続820に要求する。
レイヤ2接続820はNDアドバタイズメントを受信することができる。レイヤ2接続820は、このNDアドバタイズメントとそのコンテンツとを処理部810へ転送する。NDアドバタイズメントがPSIを含んでいる場合は、応答ホストが発したNDアドバタイズメントはプロキシによって修正されており、NDアドバタイズメントに含まれたMACアドレスまたはリンクレイヤアドレスはプロキシのアドレスであり、応答ホストの元のTLLAではないという表示として、処理部810がPSIを検出する。処理部810はテーブル847からプロキシの公開鍵を読み出す。見つかった場合は、プロキシの公開鍵を使用して、PSIに含まれたプロキシ署名を検証する。この検証が失敗した場合、NDアドバタイズメントは単純に破棄される。そうでない場合は、処理部810が、NSアドバタイズメントを発したホストのTLLAをPSIから読み出すことが好ましいことがある。プロキシのMACアドレスを応答ホストのTLLAで上書きすることによって、処理部810は、応答ホストのRSA署名を検証することができる。RSA署名の検証には、処理部810が応答ホストの公開鍵を記憶部840から読み出すことが必要である。RSA署名が有効であると仮定すると、処理部810は、プロキシのMACアドレスと、応答ホストのIPアドレスとを記憶部840に記憶する。
本発明の方法およびプロキシの好ましい実施形態のいくつかを添付図面に示し、上述の発明を実施するための形態において説明したが、本発明は、開示した実施形態に限定されるものではなく、添付の特許請求の範囲において掲載および限定がなされた本発明の本異質から逸脱せずに、多くの再構成、修正、代替が可能である、ということが理解されよう。

Claims (13)

  1. プロキシを通じて接続されたホスト間の安全なネイバディスカバリの方法であって、
    第1ホストから、前記プロキシにおいて、第2ホストを宛先としたネイバディスカバリ(ND)メッセージを受信するステップであって、前記NDメッセージは、前記第1ホストのインターネットプロトコル(IP)アドレスと、前記第1ホストのレイヤ2アドレスと、前記第1ホストのレイヤ2アドレスに少なくとも部分的に基づく前記第1ホストの第1署名とを含むステップと、
    前記プロキシにおいて、前記NDメッセージを、
    前記第1ホストのレイヤ2アドレスを前記プロキシのレイヤ2アドレスで上書きし、
    前記プロキシのレイヤ2アドレスに少なくとも部分的に基づく前記プロキシの第2署名を挿入すること
    によって、修正するステップと、
    修正した前記NDメッセージを前記第2ホストへ送信するステップと
    を含む方法。
  2. 前記第2ホストにおいて、修正した前記NDメッセージを受信するステップと、
    前記第2ホストにおいて、前記第2署名を検証するステップと、
    前記第2ホストにおいて、前記プロキシのレイヤ2アドレスを、前記第1ホストのIPアドレスと関連させて記憶するステップと
    をさらに含む、請求項1に記載の方法。
  3. 前記第2ホストにおいて前記第2署名を検証するステップの前に、前記プロキシの公開鍵をトラストアンカから取得するステップ
    をさらに含む、請求項2に記載の方法。
  4. 前記プロキシにおいて、前記第2ホストから、前記第1ホストのIPアドレスと、前記プロキシのレイヤ2アドレスとを含むデータパケット受信するステップ
    をさらに含む、請求項2に記載の方法。
  5. 前記プロキシにおいて前記NDメッセージを修正するステップは、前記NDメッセージから前記第1ホストのレイヤ2アドレスを追加メッセージフィールドへコピーするステップをさらに含む、請求項1に記載の方法。
  6. 前記第2ホストにおいて、修正した前記NDメッセージを受信するステップと、
    前記第2ホストにおいて、前記第2署名を検証するステップと、
    前記第2ホストにおいて、前記プロキシのレイヤ2アドレスを前記第1ホストのレイヤ2アドレスで上書きすることによって、前記NDメッセージを再構成するステップと、
    前記第1ホストの前記第1署名を検証するステップと、
    前記第2ホストにおいて、前記プロキシのレイヤ2アドレスを、前記第1ホストのIPアドレスと関連させて記憶するステップと
    さらに含む、請求項5に記載の方法。
  7. 前記プロキシの前記第2署名は、前記第1ホストのIPアドレスと、前記第2ホストのIPアドレスと、前記第1ホストのレイヤ2アドレスと、前記第1ホストの前記第1署名とにさらに基づく、請求項1に記載の方法。
  8. 前記プロキシの前記第2署名は、前記NDメッセージの全部の情報フィールドに基づく、請求項7に記載の方法。
  9. ホストにおいてネイバディスカバリ(ND)メッセージを安全に受信する方法であって、
    前記ホストにおいて、プロキシのレイヤ2アドレスと、ピアホストのレイヤ2アドレスと、前記ピアホストの署名と、前記プロキシの署名とを含む前記NDメッセージを受信するステップと、
    前記プロキシの公開鍵を使用して、前記プロキシの署名を検証するステップと、
    前記プロキシのレイヤ2アドレスを前記ピアホストのレイヤ2アドレスで置き換えることによって、前記NDメッセージを修正するステップと、
    前記ピアホストの公開鍵を使用して、前記ピアホストの署名を検証するステップと、
    前記ピアホストと通信するためのレイヤ2アドレスとして、前記プロキシのレイヤ2アドレスを記憶するステップと
    を含む方法。
  10. 第1ホストからネイバディスカバリ(ND)メッセージを受信する第1レイヤ2接続と、
    前記第1レイヤ2接続から前記NDメッセージを受信し、
    少なくとも1つの元のアドレスを含む第1フィールドと、前記第1ホストの第1署名を含む第2フィールドとを前記NDメッセージから読み出し、
    受信した前記NDメッセージから少なくとも1つの元のアドレスを第3フィールドへコピーし、
    前記第1フィールドにおいて前記少なくとも1つの元のアドレスのうちの1つを前記プロキシのアドレスで上書きし、
    前記プロキシのアドレスと、前記少なくとも1つの元のアドレスとに基づく前記プロキシの第2署名を挿入すること
    によって、前記NDメッセージを修正する処理部と、
    修正した前記NDメッセージを第2ホストへ送信する第2レイヤ2接続と
    を備えるプロキシ。
  11. 前記プロキシによって上書きされる前記少なくとも1つの元のアドレスは、前記第1ホストのレイヤ2アドレスであり、
    前記プロキシのアドレスはレイヤ2アドレスである、
    請求項10に記載のプロキシ。
  12. ピアホストの公開鍵と、プロキシの公開鍵と、前記ピアホストと通信するためのレイヤ2アドレスとを記憶する記憶部と、
    前記プロキシのレイヤ2アドレスと、前記ピアホストのレイヤ2アドレスと、前記ピアホストの署名と、前記プロキシの署名とを含むネイバディスカバリ(ND)メッセージをリンクで受信するレイヤ2接続と、
    前記プロキシの公開鍵を使用して前記プロキシ署名を検証し、
    前記プロキシのレイヤ2アドレスを前記ピアホストのレイヤ2アドレスで置き換えることによって前記NDメッセージを修正し、
    前記ピアホストの公開鍵を使用して前記ピアホストの署名を検証し、
    前記ピアホストと通信するためのレイヤ2アドレスとして、前記プロキシのレイヤ2アドレスを記憶する処理部と
    を備えるホスト。
  13. 前記レイヤ2接続は、さらに、ND応答を前記リンクで送信し、
    前記記憶部は、さらに、前記ホストのレイヤ2アドレスと、秘密鍵とを記憶し、
    前記処理部は、さらに、前記ホストの秘密鍵とレイヤ2アドレスとを前記記憶部から読み出し、前記秘密鍵を使用して、前記ホストのレイヤ2アドレスに基づく前記ホストの署名を作成し、前記ホストのレイヤ2アドレスと署名とを含む前記ND応答を作成し、前記ND応答を送信するよう前記レイヤ2接続に要求する、
    請求項12に記載のホスト。
JP2010532680A 2007-11-01 2008-10-08 プロキシを通じて接続されたホスト間の安全なネイバディスカバリ Expired - Fee Related JP5255065B2 (ja)

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
US98452707P 2007-11-01 2007-11-01
US60/984,527 2007-11-01
US12/036,757 2008-02-25
US12/036,757 US7779136B2 (en) 2007-11-01 2008-02-25 Secure neighbor discovery between hosts connected through a proxy
PCT/IB2008/054132 WO2009057004A1 (en) 2007-11-01 2008-10-08 Secure neighbor discovery between hosts connected through a proxy

Publications (3)

Publication Number Publication Date
JP2011509539A true JP2011509539A (ja) 2011-03-24
JP2011509539A5 JP2011509539A5 (ja) 2011-12-01
JP5255065B2 JP5255065B2 (ja) 2013-08-07

Family

ID=40589303

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010532680A Expired - Fee Related JP5255065B2 (ja) 2007-11-01 2008-10-08 プロキシを通じて接続されたホスト間の安全なネイバディスカバリ

Country Status (5)

Country Link
US (1) US7779136B2 (ja)
EP (1) EP2220843B1 (ja)
JP (1) JP5255065B2 (ja)
CN (1) CN101843075B (ja)
WO (1) WO2009057004A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR20150115221A (ko) * 2014-04-03 2015-10-14 에스케이텔레콤 주식회사 피투피 통신 시스템, 그의 피투피 통신 제어를 위한 피어 리스트 관리 방법 및 장치
US9427435B2 (en) 2009-02-26 2016-08-30 Teikoku Pharma Usa, Inc. Narcotic emulsion formulations for treatment of cancer pain
WO2019163810A1 (ja) * 2018-02-21 2019-08-29 株式会社Nttドコモ 無線通信システム、セキュリティプロキシ装置及び中継装置

Families Citing this family (35)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
KR101508794B1 (ko) 2008-07-09 2015-04-06 삼성전자주식회사 Ndef 메시지에서 선택적으로 레코드들을 보안하기 위한 방법
CN101404579B (zh) * 2008-10-31 2011-02-09 成都市华为赛门铁克科技有限公司 一种防止网络攻击的方法及装置
ES2483117T3 (es) * 2009-07-13 2014-08-05 Siemens Aktiengesellschaft Mensaje de actualización de asociaciones y procedimiento para la actualización de asociaciones en una red enmallada
JP5382789B2 (ja) * 2009-07-13 2014-01-08 Necアクセステクニカ株式会社 パケット転送方法およびパケット転送システム
US9066195B2 (en) * 2011-09-28 2015-06-23 Alcatel Lucent Method and apparatus for neighbor discovery
US9107193B2 (en) * 2012-01-13 2015-08-11 Siemens Aktiengesellschaft Association update message and method for updating associations in a mesh network
KR101660751B1 (ko) * 2012-11-01 2016-09-28 엘지전자 주식회사 확장된 디스커버리 범위를 갖는 프락시머티-기반 서비스 디스커버리를 위한 무결성 보호를 제공하는 방법 및 장치
US20140181984A1 (en) 2012-12-21 2014-06-26 International Business Machines Corporation Method and apparatus for authentication of solution topology
KR101538762B1 (ko) 2013-06-12 2015-07-24 서정환 캡슐화 프로토콜을 이용하여 클라이언트의 ip 주소를 서버로 전송하는 중계 시스템 및 방법
US9544376B1 (en) * 2013-07-11 2017-01-10 Marvell International Ltd Method and apparatus for securely discovering services in a wireless network
EP2830274A1 (en) * 2013-07-23 2015-01-28 Knightsbridge Portable Communications SP Method for electronic transmission of a message and proxy device therefore
US9438555B2 (en) * 2013-10-31 2016-09-06 Aruba Networks, Inc. Communicating with a distribution system via an uplink access point
US9237129B2 (en) 2014-05-13 2016-01-12 Dell Software Inc. Method to enable deep packet inspection (DPI) in openflow-based software defined network (SDN)
US9716716B2 (en) 2014-09-17 2017-07-25 Microsoft Technology Licensing, Llc Establishing trust between two devices
US9641400B2 (en) 2014-11-21 2017-05-02 Afero, Inc. Internet of things device for registering user selections
US20160180100A1 (en) 2014-12-18 2016-06-23 Joe Britt System and method for securely connecting network devices using optical labels
US9832173B2 (en) * 2014-12-18 2017-11-28 Afero, Inc. System and method for securely connecting network devices
US10291595B2 (en) 2014-12-18 2019-05-14 Afero, Inc. System and method for securely connecting network devices
US9537872B2 (en) 2014-12-31 2017-01-03 Dell Software Inc. Secure neighbor discovery (SEND) using pre-shared key
US9998425B2 (en) 2015-01-27 2018-06-12 Sonicwall Inc. Dynamic bypass of TLS connections matching exclusion list in DPI-SSL in a NAT deployment
US9704318B2 (en) 2015-03-30 2017-07-11 Afero, Inc. System and method for accurately sensing user location in an IoT system
US10045150B2 (en) 2015-03-30 2018-08-07 Afero, Inc. System and method for accurately sensing user location in an IoT system
US9717012B2 (en) 2015-06-01 2017-07-25 Afero, Inc. Internet of things (IOT) automotive device, system, and method
US9699814B2 (en) 2015-07-03 2017-07-04 Afero, Inc. Apparatus and method for establishing secure communication channels in an internet of things (IoT) system
US9729528B2 (en) 2015-07-03 2017-08-08 Afero, Inc. Apparatus and method for establishing secure communication channels in an internet of things (IOT) system
US10015766B2 (en) 2015-07-14 2018-07-03 Afero, Inc. Apparatus and method for securely tracking event attendees using IOT devices
US11526877B2 (en) * 2015-10-22 2022-12-13 Coinbase, Inc. Electronic devices having embedded circuitry for accessing remote digital services
US9793937B2 (en) 2015-10-30 2017-10-17 Afero, Inc. Apparatus and method for filtering wireless signals
US10178530B2 (en) 2015-12-14 2019-01-08 Afero, Inc. System and method for performing asset and crowd tracking in an IoT system
US10027576B2 (en) 2016-05-23 2018-07-17 Juniper Networks, Inc. Method, system, and apparatus for proxying intra-subnet traffic across multiple interfaces within networks
US10313108B2 (en) 2016-06-29 2019-06-04 Intel Corporation Energy-efficient bitcoin mining hardware accelerators
US10142098B2 (en) * 2016-06-29 2018-11-27 Intel Corporation Optimized SHA-256 datapath for energy-efficient high-performance Bitcoin mining
CA3032282A1 (en) * 2016-07-29 2018-02-01 Magic Leap, Inc. Secure exchange of cryptographically signed records
US11283754B2 (en) * 2018-09-19 2022-03-22 Cisco Technology, Inc. Unique identities of endpoints across layer 3 networks
US11722577B2 (en) * 2021-09-07 2023-08-08 Webshare Software Company Proxying TCP fingerprints

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004040762A (ja) * 2002-02-19 2004-02-05 Docomo Communications Laboratories Usa Inc アドレスに基づく鍵を使用することによる近隣発見の保護
WO2006119358A2 (en) * 2005-05-02 2006-11-09 Ntt Docomo Inc. Secure address proxying using multi-key cryptographically generated addresses
WO2007027241A2 (en) * 2005-05-03 2007-03-08 Ntt Docomo Inc. Multi-key cryptographically generated address

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6930988B2 (en) * 2002-10-28 2005-08-16 Nokia Corporation Method and system for fast IP connectivity in a mobile network
US7463605B2 (en) * 2002-12-06 2008-12-09 Alcatel Lucent Apparatus, and associated method, for facilitating local mobility management in a heterogeneous radio communication network
EP1628458A1 (de) * 2004-08-19 2006-02-22 Siemens Aktiengesellschaft Verfahren zur Vermittlung von IP-Paketen zwischen Kundennetzen und IP-Provider-Netzen über ein Zugangsnetz
EP1739893A1 (en) * 2005-06-30 2007-01-03 Matsushita Electric Industrial Co., Ltd. Optimized reverse tunnelling for packet switched mobile communication systems
US20070113075A1 (en) * 2005-11-10 2007-05-17 Ntt Docomo, Inc. Secure route optimization for mobile network using multi-key crytographically generated addresses
JP5008680B2 (ja) * 2006-07-04 2012-08-22 パナソニック株式会社 通信システム及びモバイル・ホームエージェント
CN101022418B (zh) * 2007-03-14 2010-05-26 华为技术有限公司 Hmip认证方法、设备及系统
US8219800B2 (en) * 2007-06-06 2012-07-10 Cisco Technology, Inc. Secure neighbor discovery router for defending host nodes from rogue routers

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004040762A (ja) * 2002-02-19 2004-02-05 Docomo Communications Laboratories Usa Inc アドレスに基づく鍵を使用することによる近隣発見の保護
WO2006119358A2 (en) * 2005-05-02 2006-11-09 Ntt Docomo Inc. Secure address proxying using multi-key cryptographically generated addresses
WO2007027241A2 (en) * 2005-05-03 2007-03-08 Ntt Docomo Inc. Multi-key cryptographically generated address

Non-Patent Citations (3)

* Cited by examiner, † Cited by third party
Title
JPN6013012814; Daley, G.: 'Securing Proxy Neighbour Discovery Problem Statement' Internet-Draft , 20050218, IETF *
JPN6013012816; Arkko, J. et al.: 'SEcure Neighbor Discovery (SEND)' RFC 3971 , 200503, IETF *
JPN6013012817; Thaler, D. et al.: 'Neighbor Discovery Proxies (ND Proxy)' RFC 4389 , 200604, IETF *

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9427435B2 (en) 2009-02-26 2016-08-30 Teikoku Pharma Usa, Inc. Narcotic emulsion formulations for treatment of cancer pain
KR20150115221A (ko) * 2014-04-03 2015-10-14 에스케이텔레콤 주식회사 피투피 통신 시스템, 그의 피투피 통신 제어를 위한 피어 리스트 관리 방법 및 장치
KR102083467B1 (ko) * 2014-04-03 2020-03-02 에스케이텔레콤 주식회사 피투피 통신 시스템, 그의 피투피 통신 제어를 위한 피어 리스트 관리 방법 및 장치
WO2019163810A1 (ja) * 2018-02-21 2019-08-29 株式会社Nttドコモ 無線通信システム、セキュリティプロキシ装置及び中継装置

Also Published As

Publication number Publication date
EP2220843B1 (en) 2018-02-28
US20090119407A1 (en) 2009-05-07
WO2009057004A1 (en) 2009-05-07
CN101843075B (zh) 2014-11-26
US7779136B2 (en) 2010-08-17
JP5255065B2 (ja) 2013-08-07
EP2220843A1 (en) 2010-08-25
CN101843075A (zh) 2010-09-22

Similar Documents

Publication Publication Date Title
JP5255065B2 (ja) プロキシを通じて接続されたホスト間の安全なネイバディスカバリ
JP4756048B2 (ja) プレフィックススコープバインディング更新をセキュアにするためのシステム及び関連方法並びに装置
JP4625125B2 (ja) マルチ鍵暗号化生成アドレスを用いたセキュアなアドレスプロキシ
EP2127249B1 (en) Route optimization between a mobile router and a correspondent node using reverse routability network prefix option
US8126148B2 (en) Securing home agent to mobile node communication with HA-MN key
US8266427B2 (en) Secure mobile IPv6 registration
US8098823B2 (en) Multi-key cryptographically generated address
US20070113075A1 (en) Secure route optimization for mobile network using multi-key crytographically generated addresses
JP4917596B2 (ja) 対応ノードとセッション中にある移動ノードへの匿名性の提供
JP4054007B2 (ja) 通信システム、ルータ装置、通信方法、ルーティング方法、通信プログラムおよびルーティングプログラム
JP2010531106A (ja) アクセスネットワークのマルチホーミングのためのシステムおよび方法
JP2003324419A (ja) アドレス・ベースド・キ−を使用して対応情報更新を保護する方法
JP5144685B2 (ja) 移動ネットワークにおけるシグナリング委任
EP2033400A1 (en) Method and arrangement for assuring prefix consistency among multiple mobile routers.
WO2006133740A1 (en) Host identity protocol method and apparatus
Bless et al. The underlay abstraction in the spontaneous virtual networks (SpoVNet) architecture
WO2004045133A1 (en) Key distribution across networks
Jokela et al. Host identity protocol
Ylitalo et al. A new name space for end-points: Implementing secure mobility and multi-homing across the two versions of IP
Combes et al. Securing neighbor discovery proxy: Problem statement
Combes et al. RFC 5909: Securing Neighbor Discovery Proxy: Problem Statement
WG et al. Internet-Draft Sun Microsystems Expires: March 31, 2006 September 27, 2005

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111011

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20111011

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20130319

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20130418

R150 Certificate of patent or registration of utility model

Ref document number: 5255065

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20160426

Year of fee payment: 3

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

LAPS Cancellation because of no payment of annual fees