(57)【要約】  方法は、複数のノードを有しているＩＰネットワーク内の現ノードによって受信された最初のセッションパケットを有しているセッションを処理する。複数のノードには、次ノードが含まれており、また現ノードは、レイヤ３プロトコルを使用して次ノードと通信する。本方法は、現ノードにおいて、ディジタル署名、ペイロードデータおよびメタデータを有している最初のセッションパケットを受信する。本方法は、確認情報を生成するためにペイロードデータおよびメタデータを使用し、また比較ディジタル署名を生成するために、ディジタル署名を使用する。次に、本方法は、確認情報を比較ディジタル署名と比較する。確認情報が、比較ディジタル署名と合致しない場合には、本方法は、最初のセッションパケットを廃棄する。合致する場合には、本方法は、最初のセッションパケットに対してディジタル署名を行い、最初のセッションパケットを、ＩＰネットワークを介して次ノードにルーティングする。
2018521534.tif 000002
【特許請求の範囲】
【請求項１】
複数のノードを有しているＩＰネットワークのセッションを処理するネットワークルーティングデバイスにおいて、
前記複数のノードには、次認証鍵を有している次ノードが含まれており、前記ネットワークルーティングデバイスは、現認証鍵を有しており、前記ネットワークルーティングデバイスは、
ディジタル署名、ペイロードデータおよびメタデータを有している最初のセッションパケットを受信するように構成されている、入力インタフェースと、
適切に作用するように前記入力インタフェースに接続されている署名モジュールと、
適切に作用するように前記署名モジュールに接続されている出力インタフェースと、
を含んでおり、
前記署名モジュールは、前記現認証鍵を使用して前記ディジタル署名を処理して、処理されたディジタル署名を生成するように構成されており、
前記署名モジュールはまた、前記ペイロードデータおよび前記メタデータを処理して、確認情報を生成するように構成されており、
前記署名モジュールはさらに、前記処理されたディジタル署名を前記確認情報と比較して、前記処理されたディジタル署名が前記確認情報と合致するかを判定し、さらに（１）合致しない場合には、前記最初のセッションパケットを廃棄するか、または（２）合致する場合には、前記次認証鍵を使用して、前記最初のセッションパケットに対してディジタル署名を行う、ように構成されており、
前記出力インタフェースは、ディジタル署名が行われた後に、前記最初のセッションパケットを、レイヤ３プロトコルを使用して、前記ＩＰネットワークを介して前記次ノードにルーティングするように構成されている、
ネットワークルーティングデバイス。
【請求項２】
前記署名モジュールは、前記ペイロードデータおよび前記メタデータにハッシュ関数を適用して、前記確認情報を生成するように構成されている、
請求項１記載のネットワークルーティングデバイス。
【請求項３】
前記セッションは、前記最初のセッションパケットと、複数の中間セッションパケットと、最後のセッションパケットと、を含んでおり、
前記署名モジュールは、前記最初のセッションパケットに対してのみディジタル署名を行うように構成されており、前記中間セッションパケットは、受信後にディジタル署名が行われずに転送される、
請求項１記載のネットワークルーティングデバイス。
【請求項４】
前記メタデータは、（１）前記セッション、（２）前記ペイロードデータ、または（３）前記セッションおよび前記ペイロードデータの両方に関連するデータ、を含んでいる、
請求項１記載のネットワークルーティングデバイス。
【請求項５】
前記ネットワークルーティングデバイスは、さらに、適切に作用するように前記署名モジュールに接続されている鍵マネージャを含んでおり、
前記鍵マネージャは、ネットワークを介して、前記複数のノードのセットに関する認証鍵のコピーを有している鍵ネットワークデバイスから、前記次認証鍵を検索するように構成されている、
請求項１記載のネットワークルーティングデバイス。
【請求項６】
複数のノードを有しているＩＰネットワーク内の現ノードによって受信された最初のセッションパケットを有しているセッションを処理する方法であって、
前記複数のノードには、次ノードが含まれており、前記現ノードは、レイヤ３プロトコルを使用して前記次ノードと通信するように構成されている、
方法において、
ディジタル署名、ペイロードデータおよびメタデータを有している前記最初のセッションパケットを、前記現ノードにおいて受信するステップと、
前記ペイロードデータおよび前記メタデータを処理して、確認情報を生成するステップと、
所定の認証鍵を使用して前記ディジタル署名を処理して、処理されたディジタル署名を生成するステップと、
前記確認情報を、前記処理されたディジタル署名と比較するステップと、
前記確認情報が、前記処理されたディジタル署名と合致しない場合には、前記最初のセッションパケットを廃棄するステップと、
前記確認情報が、前記処理されたディジタル署名と合致する場合には、前記最初のセッションパケットに対してディジタル署名を行うステップと、
ディジタル署名の後に、前記ＩＰネットワークを介して、前記最初のセッションパケットを前記次ノードにルーティングするステップと、
を含んでいる、方法。
【請求項７】
前記現ノードは、前記所定の認証鍵を有している、
請求項６記載の方法。
【請求項８】
前記次ノードは、次認証鍵を有しており、
前記最初のセッションパケットに対してディジタル署名を行うステップは、前記次認証鍵、前記ペイロードデータおよび前記メタデータを使用して、前記最初のセッションパケットに対してディジタル署名を行うステップを含んでいる、
請求項７記載の方法。
【請求項９】
前記現ノードは、ルータデバイスを含んでいる、
請求項６記載の方法。
【請求項１０】
前記セッションは、前記最初のセッションパケットと、複数の中間セッションパケットと、最後のセッションパケットと、を含んでおり、
前記方法は、前記最初のセッションパケットに対してのみディジタル署名を行って転送する、
請求項６記載の方法。
【請求項１１】
前記確認情報が、前記処理されたディジタル署名と実質的に正確に同じである場合には、前記確認情報は、前記処理されたディジタル署名と合致している、
請求項６記載の方法。
【請求項１２】
前記所定の認証鍵は、公開鍵・秘密鍵のペアを含んでいるか、または対称鍵を含んでいる、
請求項６記載の方法。
【請求項１３】
ネットワークには、送信元ノードおよび宛先ノードを有しているパブリックネットワークが含まれており、
前記最初のセッションパケットは、前記送信元ノードから、一連のノードを介して受信され、
前記最初のセッションパケットは、該最初のセッションパケットの最終的な宛先として、宛先ノードアドレスを有している、
請求項６記載の方法。
【請求項１４】
前記ペイロードデータおよび前記メタデータを処理するステップは、一方向ハッシュ関数を使用して前記ペイロードデータおよび前記メタデータを処理するステップを含んでいる、
請求項６記載の方法。
【請求項１５】
さらに、
第２のディジタル署名、第２のペイロードデータおよび第２のメタデータを有している第２のセッションパケットを、前記現ノードにおいて受信するステップと、
前記第２のペイロードデータおよび前記第２のメタデータを処理して、第２の確認情報を生成するステップと、
前記所定の認証鍵を使用して前記第２のディジタル署名を処理して、第２の処理されたディジタル署名を生成するステップと、
前記第２の確認情報を、前記第２の処理されたディジタル署名と比較するステップと、
前記第２の確認情報が、前記第２の処理されたディジタル署名と合致しない場合には、前記第２のセッションパケットを廃棄するステップと、
前記第２の確認情報が、前記第２の処理されたディジタル署名と合致する場合には、前記第２のセッションパケットに対してディジタル署名を行うステップと、
ディジタル署名の後に、前記ＩＰネットワークを介して、第２の最初のセッションパケットを前記次ノードにルーティングするステップと、
を含んでいる、
請求項６記載の方法。
【請求項１６】
前記メタデータは、（１）前記セッション、（２）前記ペイロードデータ、または（３）前記セッションおよび前記ペイロードデータの両方に関連するデータ、を含んでいる、
請求項６記載の方法。
【請求項１７】
前記最初のセッションパケットは、ＴＣＰプロトコルのＳＹＮパケットを含んでいる、
請求項６記載の方法。
【請求項１８】
さらに、
前記現ノードを始動させるステップと、
ネットワークを介して、前記複数のノードのセットに関する前記認証鍵のコピーを有している鍵ネットワークデバイスから、前記次ノードに関する次認証鍵を検索するステップと、
を含んでいる、
請求項６記載の方法。
【請求項１９】
前記所定の認証鍵は、前記現ノードに関する前記認証鍵であり、
さらに、前記次ノードは、次認証鍵を有しており、
前記方法は、認証データが前記ペイロードデータにも前記メタデータにも合致する場合には、前記次認証鍵を使用して、前記最初のパケットに対してディジタル署名を行う、
請求項６記載の方法。
【請求項２０】
複数のノードを有しているＩＰネットワーク内の現ノードによって受信された最初のパケットを有しているセッションを処理するための、コンピュータシステムにおいて使用されるコンピュータプログラム製品において、
前記複数のノードには、次ノードが含まれており、前記現ノードは、レイヤ３プロトコルを使用して前記次ノードと通信するように構成されており、
前記コンピュータプログラム製品は、有形の非一時的なコンピュータ使用可能媒体と、該媒体におけるコンピュータ可読プログラムコードと、を有しており、
前記コンピュータ可読プログラムコードは、
ディジタル署名、ペイロードデータおよびメタデータを有している前記最初のセッションパケットを、前記現ノードにおいて受信するためのプログラムコードと、
前記ペイロードデータおよび前記メタデータを処理して、確認情報を生成するためのプログラムコードと、
所定の認証鍵を使用して前記ディジタル署名を処理して、処理されたディジタル署名を生成するためのプログラムコードと、
前記確認情報を、前記処理されたディジタル署名と比較するためのプログラムコードと、
前記確認情報が、前記処理されたディジタル署名と合致しない場合には、前記最初のセッションパケットを廃棄するためのプログラムコードと、
前記確認情報が、前記処理されたディジタル署名と合致する場合には、前記最初のセッションパケットに対してディジタル署名を行うためのプログラムコードと、
ディジタル署名の後に、前記ＩＰネットワークを介して、前記最初のセッションパケットを前記次ノードにルーティングするためのプログラムコードと、
を含んでいる、コンピュータプログラム製品。
【請求項２１】
前記セッションは、前記最初のセッションパケットと、複数の中間セッションパケットと、最後のセッションパケットと、を含んでおり、
前記プログラムコードは、前記最初のセッションパケットに対してのみディジタル署名を行って転送するように構成されている、
請求項２０記載のコンピュータプログラム製品。
【請求項２２】
前記現ノードは、前記所定の認証鍵を有している、
請求項２０記載のコンピュータプログラム製品。
【請求項２３】
前記次ノードは、次認証鍵を有しており、
前記最初のセッションパケットに対してディジタル署名を行うためのプログラムコードは、前記次認証鍵、前記ペイロードデータおよび前記メタデータを使用して、前記最初のセッションパケットに対してディジタル署名を行うためのプログラムコードを含んでいる、
請求項２２記載のコンピュータプログラム製品。
【請求項２４】
前記確認情報が、前記処理されたディジタル署名と実質的に正確に同じである場合には、前記確認情報は、前記処理されたディジタル署名と合致している、
請求項２０記載のコンピュータプログラム製品。
【請求項２５】
現認証鍵は、公開鍵・秘密鍵のペアを含んでいるか、または対称鍵を含んでいる、
請求項２０記載のコンピュータプログラム製品。
【請求項２６】
前記メタデータは、（１）前記セッション、（２）前記ペイロードデータ、または（３）前記セッションおよび前記ペイロードデータの両方に関連するデータ、を含んでいる、
請求項２０記載のコンピュータプログラム製品。
【請求項２７】
複数のノードを有しているＩＰネットワーク内の現ノードによって受信された最初のセッションパケットを有しているセッションを処理する方法であって、
前記複数のノードには、次ノードが含まれており、前記現ノードは、レイヤ３プロトコルを使用して前記次ノードと通信するように構成されている、
方法において、
ディジタル署名、ペイロードデータおよびメタデータを有している前記最初のセッションパケットを、前記現ノードにおいて受信するステップと、
前記ペイロードデータおよび前記メタデータを使用して、確認情報を生成するステップと、
前記ディジタル署名を使用して、比較ディジタル署名を生成するステップと、
前記確認情報を、前記比較ディジタル署名と比較するステップと、
前記確認情報が、前記比較ディジタル署名と合致しない場合には、前記最初のセッションパケットを廃棄するステップと、
前記確認情報が、前記比較ディジタル署名と合致する場合には、前記最初のセッションパケットに対してディジタル署名を行うステップと、
ディジタル署名の後に、前記ＩＰネットワークを介して、前記最初のセッションパケットを前記次ノードにルーティングするステップと、
を含んでいる、方法。
【請求項２８】
前記ペイロードデータおよび前記メタデータを使用するステップは、ハッシュ関数を使用して前記確認情報を生成するステップを含んでいる、
請求項２７記載の方法。
【請求項２９】
前記現ノードは、所定の鍵を有しており、
前記方法は、前記所定の鍵を使用して、前記比較ディジタル署名を生成する、
請求項２７記載の方法。
【請求項３０】
前記確認情報は、生のペイロードデータおよびメタデータを含んでいる、
請求項２７記載の方法。
【請求項３１】
前記次ノードは、関連付けられた次認証鍵を有しており、
ディジタル署名を行うステップは、前記次認証鍵を使用して、前記最初のセッションパケットに対してディジタル署名を行うステップを含んでいる、
請求項２７記載の方法。
【発明の詳細な説明】
【技術分野】
【０００１】
関連出願
本願は、２０１４年９月２６日に出願された米国特許出願第１４／４９７，９５４号、発明の名称「ネットワークパケットフローコントローラ（ＮＥＴＷＯＲＫ  ＰＡＣＫＥＴ  ＦＬＯＷ  ＣＯＮＴＲＯＬＬＥＲ）」、代理人整理番号４０９４／１００１、発明者ＭｅＬａｍｐｙ、Ｂａｊ、Ｋａｐｌａｎ、Ｋｕｍａｒ、ＰｅｎｆｉｅｌｄおよびＴｉｍｍｏｎｓ、に関連するものであり、その開示内容全体は参照により本願に組み込まれる。
【０００２】
また本願は、２０１４年１２月８日に出願された米国特許出願第１４／５６２，９１７号、発明の名称「ステートレスなネットワークにおけるステートフルなロードバランシング（ＳＴＡＴＥＦＵＬ  ＬＯＡＤ  ＢＡＬＡＮＣＩＮＧ  ＩＮ  Ａ  ＳＴＡＴＥＬＥＳＳ  ＮＥＴＷＯＲＫ）」、代理人整理番号４０９４／１００２、発明者Ｔｉｍｍｏｎｓ、Ｂａｊ、Ｋａｐｌａｎ、ＭｅＬａｍｐｙ、ＫｕｍａｒおよびＰｅｎｆｉｅｌｄ、に関連するものであり、その開示内容全体は参照により本願に組み込まれる。
【０００３】
本ＰＣＴ出願は、２０１５年５月１８日に出願された米国特許出願第１４／７１５，０３６号の優先権を主張するものであり、その開示内容全体は参照により本願に組み込まれる。
【０００４】
発明の分野
本発明は、一般的には、ネットワークデバイスに関し、より詳細には、ネットワークルーティングデバイスについてのセキュリティに関する。
【背景技術】
【０００５】
インターネットプロトコル（「ＩＰ」）は、データメッセージ（「データグラム」）を、インターネットに接続されているネットワークデバイス間で転送するためのデファクトスタンダードとして使用されている。そのために、ＩＰは、一連のインターネットデバイスを介して、例えばルータおよびスイッチを介して、データグラムを１つまたは複数のデータパケットの形態で供給する。各パケットは、２つの主要部分、すなわち、（１）伝送される情報（例えばテキストデータ、グラフィックデータ、オーディオデータまたはビデオデータ）を有しているペイロード、ならびに（２）（１つまたは複数の）パケットを受信するネットワークデバイス（「宛先デバイス」）のアドレス、パケットを送信するネットワークデバイス（「起源デバイス」）の識別子およびパケットをルーティングするためのその他のデータを有している、「ＩＰヘッダ」として公知であるヘッダ。したがって、多くの人々は、パケットを一般郵便／ファーストクラスメール（ｆｉｒｓｔ  ｃｌａｓｓ  ｍａｉｌ）を使用する従来の手紙を例にして説明している。つまり、手紙は、ペイロードとして機能し、また差出人住所および宛先住所が示されている封書は、ＩＰヘッダとして機能する。
【０００６】
パブリックネットワークまたはプライベートネットワークを介してパケットをルーティングする場合には、ネットワーク内の人間またはデバイスがそれらのパケットに対してアクセスおよび／または変更を試みる可能性があるという危険がしばしば存在する。この問題は、「中間者攻撃（ｍａｎ−ｉｎ−ｔｈｅ−ｍｉｄｄｌｅ）」問題として多方面で既に論じられている。
【発明の概要】
【課題を解決するための手段】
【０００７】
本発明の図示の実施の形態によれば、本方法は、複数のノードを有しているＩＰネットワーク内の現ノードによって受信された最初のセッションパケットを有しているセッションを処理する。また、複数のノードには、次ノードが含まれており、現ノードは、レイヤ３プロトコルを使用して、その次ノードと通信するように構成されている。本方法は、現ノードにおいて最初のセッションパケットを受信する。最初のセッションパケットは、ディジタル署名、ペイロードデータおよびメタデータを有している。本方法は、確認情報を生成するためにペイロードデータおよびメタデータを処理し、また所定の認証鍵を使用してディジタル署名を処理して、処理されたディジタル署名を生成する。次に、本方法は、確認情報を処理されたディジタル署名と比較し、この比較に基づいて適切なアクションを行う。特に、本方法は、確認情報と処理されたディジタル署名とが合致しない場合には、最初のセッションパケットを廃棄するが、しなしながら確認情報と処理されたディジタル署名とが合致する場合には、最初のセッションパケットに対してディジタル署名を行う。さらに、本方法は、ディジタル署名の後に、またはディジタル署名が行われる場合には、ＩＰネットワークを介して、最初のセッションパケットを次ノードにルーティングする。
【０００８】
現ノードは、所定の認証鍵を有することができる、かつ／または次ノードは、次認証鍵を有することができる。したがって、本方法は、次認証鍵、ペイロードおよびメタデータを使用して、最初のセッションパケットに対してディジタル署名を行うことができる。種々の実施の形態は、複数のタイプのセッションに適用され、例えば最初のセッションパケット、複数の中間セッションパケットおよび最後のセッションパケットを有しているセッションに適用される。この場合、本方法は、最初のセッションパケットに対してのみディジタル署名を行って転送することができるか、または最初セッションパケットと、中間セッションパケットのうちの１つまたは複数と、最後のセッションパケットと、に対してディジタル署名を行って転送することができる（すなわち、署名の前に関連するパケットを検証するために上述のアクションを実行する）。
【０００９】
この他、確認情報と処理されたディジタル署名とが実質的に正確に同じである場合には、確認情報を、処理されたディジタル署名と合致しているとみなすことができる。
【００１０】
ネットワークは、複数のトポロジを取ることもできる。例えば、ネットワークには、送信元ノードおよび宛先ノードを有しているパブリックネットワークが含まれると考えられる。この場合、最初のセッションパケットは、一連のノードを介して、送信元ノードから受信することができ、またその最終的な宛先として、宛先ノードアドレスを有することができる。実際には、現ノードは、ルーティングデバイスを含むことができる。
【００１１】
この他、ペイロードおよびメタデータを、一方向ハッシュ関数を使用して処理することができる。さらに、メタデータは、（１）セッション、（２）ペイロードデータ、または（３）セッションおよびペイロードデータの両方、に関連するデータを含むことができ、また最初のセッションパケットは、ＴＣＰプロトコルのＳＹＮパケットを含むことができる。
【００１２】
必要な鍵を検索するために、幾つかの実施の形態は、現ノードを始動させ、続いて、次ノードに関する次認証鍵を、ネットワークを介して鍵ネットワークデバイスから検索する。鍵ネットワークデバイスは、複数のノードのセットに関する認証鍵のコピーを有している。さらに、所定の認証鍵は、現ノードに関する認証鍵であってよい。この場合、本方法は、もちろん認証データがペイロードデータにもメタデータにも合致する場合には、次認証鍵を使用して、最初のパケットに対してディジタル署名を行うことができる。
【００１３】
本発明の別の実施の形態によれば、ネットワークルーティングデバイスは、複数のノードを有しているＩＰネットワークのセッションを処理する。複数のノードには、次認証鍵を有している次ノードが含まれており、その一方で、ネットワークルーティングデバイスは、現認証鍵を有している。デバイスは、とりわけ、適切に作用するように入力インタフェースに接続されている署名モジュールを有しており、この入力インタフェースは、ディジタル署名、ペイロードデータ、およびメタデータを有している最初のセッションパケットを受信するように構成されている。署名モジュールは、複数の機能のために構成されている。特に、署名モジュールは、（１）現認証鍵を使用してディジタル署名を処理し、処理されたディジタル署名を生成する、（２）ペイロードデータおよびメタデータを処理し、確認情報を生成する、（３）処理されたディジタル署名を確認情報と比較し、処理されたディジタル署名が確認情報と合致するかを判定する、かつ（４）合致しない場合には、最初のセッションパケットを廃棄するか、または合致する場合には、次認証鍵を使用して、最初のセッションパケットに対してディジタル署名を行う、ように構成されている。デバイスは、適切に作用するように署名モジュールと接続されている、出力インタフェースも有しており、ディジタル署名が行われた後に、最初のセッションパケットを、レイヤ３プロトコルを使用して、ＩＰネットワークを介して次ノードにルーティングする。
【００１４】
別の実施の形態によれば、本方法は、複数のノードを有しているＩＰネットワーク内の現ノードによって受信された最初のセッションパケットを有しているセッションを処理する。複数のノードには、次ノードが含まれており、現ノードは、レイヤ３プロトコルを使用してその次ノードと通信するように構成されている。本方法は、現ノードにおいて最初のセッションパケットを受信する。この受信された最初のセッションパケットは、ディジタル署名、ペイロードデータおよびメタデータを有している。本方法はまた、確認情報を生成するためにペイロードデータおよびメタデータを使用し、また比較ディジタル署名を生成するために、ディジタル署名を使用する。次に、本方法は、確認情報を比較ディジタル署名と比較する。確認情報が、比較ディジタル署名と合致しない場合には、本方法は、最初のセッションパケットを廃棄する。しかしながら、合致する場合には、本方法は、最初のセッションパケットに対してディジタル署名を行い、ディジタル署名が行われた後に、最初のセッションパケットを、ＩＰネットワークを介して次ノードにルーティングする。
【００１５】
本発明の図示の実施の形態は、コンピュータ使用可能媒体と、その媒体におけるコンピュータ可読プログラムコードと、を有しているコンピュータプログラム製品として実現される。コンピュータ可読コードを、従来のプロセスに従ってコンピュータシステムによって読み出して利用することができる。
【００１６】
当業者であれば、以下に簡単に説明している図面と関連させて説明を行う、「図示の実施の形態の説明」の項から、本発明の種々の実施の形態の利点がより十分に明らかになる。
【図面の簡単な説明】
【００１７】
【図１】本発明の図示の実施の形態を使用することができる、仮想の従来技術のネットワークを概略的に示す。
【図２】本発明の図示の実施の形態によって使用することができる、従来技術のメッセージのフラグメンテーションを概略的に示す。
【図３】本発明の図示の実施の形態を実現することができる、一般的な従来技術のインターネットを概略的に示す。
【図４】本発明の図示の実施の形態を実現することができる、ネットワークを概略的に示す。
【図５】本発明の図示の実施の形態を実現するように構成されている、ネットワークデバイスを概略的に示す。
【図６】本発明の図示の実施の形態に従って構成することができる、パケットの詳細を概略的に示す。
【図７】本発明の図示の実施の形態による、パケットを安全にルーティングするための方法を示す。
【発明を実施するための形態】
【００１８】
図示の実施の形態において、レイヤ３ルーティングデバイス／ノードは、より安全に、セッションのパケットを、送信元（Ｓｏｕｒｃｅ）と宛先（Ｄｅｓｔｉｎａｔｉｏｎ）との間でルーティングする。そのために、セッションにおけるパケットの認証後に、ノードはそのパケットに対してディジタル署名を行い、またレイヤ３プロトコルを使用してそのパケットをルーティングする。とりわけ、このパケットは、ペイロード、ならびにセッションおよび／またはペイロードに関連するメタデータの両方を含むことができる。この場合、ノードは、好適には、ペイロードおよびメタデータを使用して、ディジタル署名を生成する。したがって、送信元と宛先との間でこのパケットが伝送される間に、いわゆる「中間者攻撃」による、パケットに対する改竄が介入する可能性が低くなる。種々の実施の形態を下記において詳述する。
【００１９】
ネットワーク
図示の実施の形態は、好適には、従来のコンピュータネットワークにおいて実現されている。特に、ネットワークは、少なくとも２つのノードと、ノード間の少なくとも１つのリンクと、を含んでいる。ノードは、（ホストまたはデバイスと称する場合もある）コンピューティングデバイスおよびルータを含むことができる。コンピュータには、パーソナルコンピュータ、スマートフォン、テレビジョン・セットトップボックス、現金自動預け払い機（ＡＴＭ）、ならびにプロセッサおよびネットワークインタフェースを含んでいるその他の多くのタイプの装置が含まれると考えられる。リンクは、ノードペア間の有線式および無線式のコネクションを含んでいる。さらに、ノードおよび／またはリンクを、完全にソフトウェアとして実現することができ、例えば仮想マシン、ソフトウェア定義ネットワーク（ＳＤＮ：Ｓｏｆｔｗａｒｅ  Ｄｅｆｉｎｅｄ  Ｎｅｔｗｏｒｋ）において、また、ネットワーク機能の仮想化（ＮＦＶ：Ｎｅｔｗｏｒｋ  Ｆｕｎｃｔｉｏｎ  Ｖｉｒｔｕａｌｉｚａｔｉｏｎ）を使用して実現することができる。多くのネットワークは、スイッチを含んでおり、それらのスイッチの大部分は、この議論に関してトランスペアレント（透過性）である。しかしながら、幾つかのスイッチは、ルーティング機能も実施する。ここでの議論に関して、そのようなルーティングスイッチはルータとみなされる。ルータについては下記において説明する。
【００２０】
ノードを、１つまたは複数のその他のノードと、それぞれ個別のリンクを介して直接的に接続することができる。例えば、図１には、ノードＡがリンク１を介してノードＢに直接的に接続されていることが概略的に示されている。所定のネットワークにおいて（例えば、ローカルエリアネットワーク内では）、各ノードは、データの送信および受信を容易にするためのユニークなネットワークアドレスを有している。ネットワークは、ネットワークのアドレッシングスキームに従ってネットワーク内でアドレッシング可能なすべてのノードと、ネットワークのアドレッシングスキームに従って通信を行うためにノードを相互接続するすべてのリンクと、を含んでいる。例えば、図１においては、ノードＡ、ノードＢ、ノードＣ〜ノードＦおよびすべてのリンク１〜８が一緒になって１つのネットワーク１００を形成している。簡略化のために、ネットワークを、１つのクラウドとして、または１つのクラウド内に含まれるものとして示すことができる。しかしながら、クラウドは存在しないということが、複数のノードおよび複数のリンクの集合体はネットワークではないということを意味しているわけではない。例えば、複数の比較的小さいネットワークから１つのネットワークを形成することができる。
【００２１】
各ノードは、ネットワークを介してその他のノードとの通信を開始することができ、また各ノードは、ネットワークを介してその他のノードによって開始された通信を受信することができる。例えば、ノードは、直接的に接続されているノード（隣接ノード）に、その隣接ノードと相互接続されているリンクを介してデータ（メッセージ）を送信することによって、そのデータ（メッセージ）を伝送／転送／送信することができる。メッセージは、送信ノードのネットワークアドレス（「送信元アドレス」）と、意図されている受信ノードのネットワークアドレス（「宛先アドレス」）と、を含んでいる。送信ノードは、メッセージを非隣接ノードに、１つまたは複数のその他の介在ノードを介して送信することができる。例えば、ノードＤは、ノードＦにノードＢを介してメッセージを送信することができる。周知のネットワーキングプロトコルを使用して、送信元ノードと宛先ノードとの間に存在する（１つまたは複数の）ノードは、メッセージがその宛先ノードに到達するまで、メッセージを転送する。したがって、適切に動作するために、ネットワークプロトコルは、各ノードによる、そのネットワーク内の非隣接ノードのネットワークアドレスの学習または発見を実現する。
【００２２】
ノードは、プロトコルに従って、例えば公知のインターネットプロトコル（ＩＰ：Ｉｎｔｅｒｎｅｔ  Ｐｒｏｔｏｃｏｌ）および伝送制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｓｓｉｏｎ  Ｃｏｎｔｒｏｌ  Ｐｒｏｔｏｃｏｌ）に従って、ネットワークを介して通信を行う。プロトコルは、典型的には、例えば周知の７層オープンシステム接続（ＯＳＩ：Ｏｐｅｎ  Ｓｙｓｔｅｍ  Ｉｎｔｅｒｃｏｎｎｅｃｔ）モデルに従って、階層化されたソフトウェアコンポーネントおよび／またはハードウェアコンポーネントによって実施されている。一例として、ＩＰは、ＯＳＩのレイヤ３（ネットワーク層）で機能し、その一方、ＴＣＰは、大部分がＯＳＩのレイヤ４（トランスポート層）で機能する。各層は、論理的な機能を実施し、また自身より下位の層を抽象化し、したがって下位層の詳細を隠す。
【００２３】
例えば、レイヤ３は、レイヤ２（データリンク層）が１つの大きいメッセージを１回の伝送で処理できない場合には、そのメッセージの、複数のより小さいパケットへのフラグメント化を実施することができる。図２には、複数の部分２０２、２０４、２０６、２０８、２１０および２１２に分割された大きいメッセージ２００が概略的に示されている。この場合、各部分２０２〜２１２を、パケット２１４によって例示されている個別のパケットとして送信することができる。各パケットは、ペイロード２１６によって例示されているペイロード（本体）部分と、参照番号２１８によって例示されているヘッダ部分と、を含んでいる。ヘッダ部分２１８は、（１）パケットのその宛先へのルーティング、（２）メッセージのパケットの再組み立て、および（３）プロトコルに従って提供されるその他の機能、のために必要とされるまたは望まれる情報、例えばパケットの送信元アドレス、宛先アドレスおよびパケットシーケンス番号を含んでいる。幾つかのケースにおいては、例えばペイロードまたはパケット全体のチェックサムを送信するために、ペイロードにトレーラ部分も付加されている。メッセージのすべてのパケットが同一の経路に沿って送信される必要はない。つまり、それらのパケットの共通の宛先への経路において同一のノードを通過する必要はない。ＩＰパケットは、正式にはＩＰデータグラムと称されるが、それらは一般的には単純にパケットと称されていることを言及しておく。
【００２４】
その他の幾つかのプロトコルも、データの複数のパケットへのフラグメント化を実施する。例えば、ＴＣＰは、データの複数のセグメントへのフラグメント化を実施する。セグメントは、正式には、ＴＣＰプロトコルデータユニット（ＰＤＵ：Ｐｒｏｔｏｃｏｌ  Ｄａｔａ  Ｕｎｉｔ）と称される。それにもかかわらず、一般的には、ＰＤＵおよびデータグラムを表す際に、またイーサネットフレームを表す際にパケットという用語が用いられている。
【００２５】
プロトコルの多くは、上位の階層のプロトコルのパケットのカプセル化を実施する。例えば、ＩＰは、ＩＰパケットを生成するために、ＴＣＰパケットにＩＰヘッダを付加することによって、ＴＣＰパケットのカプセル化を実施する。したがって、下位の階層において送信されたパケットは、パケット内のパケットから成るものであると考えられる。通常の場合、あるプロトコルに従って動作するコンポーネントは、同一のプロトコルに従って動作する別のコンポーネント、典型的には別のノード内の別のコンポーネントによって生成されたヘッダおよび／またはトレーラ内の情報しか検査または変更しない。つまり、一般的には、あるプロトコルに従って動作するコンポーネントは、その他のプロトコルによって生成されたパケットの部分を検査または変更しない。
【００２６】
階層プロトコルによって提供される抽象化の別の例では、幾つかの層がアドレスを変換する。幾つかの層は、層固有のアドレッシングスキームを含んでいる。例えば、リンクの各端部は、実際の（例えば電子的な）インタフェースまたは仮想のインタフェース、例えばイーサネットインタフェースを介してノードに接続されている。レイヤ２（データリンク層）では、各インタフェースがアドレスを、例えばメディアアクセスコントロール（ＭＡＣ：Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレスを有している。その一方で、ＩＰを使用するレイヤ３では、各インタフェースが、または少なくとも各ノードがＩＰアドレスを有している。レイヤ３は、ＩＰアドレスをＭＡＣアドレスに変換する。
【００２７】
典型的に、ルータは、２つまたはそれ以上の個別のネットワーク、もしくは単一のネットワークの２つまたはそれ以上のサブネットワーク（サブネット）を相互接続するノードとして機能する。これによって、「複数のネットワークから成る１つのネットワーク」（すなわち、１つのインターネット）が形成される。したがって、ルータは、少なくとも２つのインタフェースを有しており、各インタフェースは、図３に例示されているように、ルータを異なるネットワークに接続する。ルータは、一方のインタフェースを介して一方のネットワークからパケットを受信すると、自身のルーティングテーブルに記憶されている情報を使用して、そのパケットを他方のインタフェースを介して他方のネットワークに向ける。ルーティングテーブルは、ネットワークとネクストホップとの関連性を含んでいる。それらの関連性は、最終的な宛先への経路上のネクストホップを表している特定のルータにパケットを送信することによって、特定の宛先に最適に到達できることをルータに知らせる。例えば、第１のルータ３００が自身の第１のインタフェース３０４を介して、第１のネットワーク３０２からパケットを受信し、かつそのパケットの宛先が第３のネットワーク３０６内のあるノードに指定されている場合には、第１のルータ３００は、自身のルーティングテーブルを参照して、自身の第２のインタフェース３０８を介して第２のネットワーク３１０にパケットを転送する。続けて、第２のネットワーク３１０は、パケットを第３のネットワーク３０６に転送する。ネクストホップの関連性を、最終的な宛先への出力（出口）インタフェースとしてルーティングテーブルに示すこともできる。
【００２８】
大規模な組織、例えば大企業、商用データセンタおよび電気通信事業者は、内部トラフィックの送信のために、階層構造のルータのセットを使用することが多い。例えば、１つまたは複数のゲートウェイルータによって、各組織のネットワークと、１つまたは複数のインターネットサービスプロバイダ（ＩＳＰ：Ｉｎｔｅｒｎｅｔ  Ｓｅｒｖｉｃｅ  Ｐｒｏｖｉｄｅｒ）と、を相互接続することができる。またＩＳＰは、自身の顧客のゲートウェイ間のトラフィックの送信のために階層構造のルータを使用して、その他のＩＳＰとの相互接続およびインターネットバックボーンにおけるコアルータとの相互接続を実現する。
【００２９】
慣例のルータは、その主たる転送の判断に関して、レイヤ３ＩＰパケットにおける情報、特に宛先ＩＰアドレスを基礎としているので、レイヤ３デバイスとみなされる。従来のルータは、パケットが運ぶ実際のデータコンテンツ（すなわち、カプセル化されたペイロード）を参照しない。その代わりにルータは、単に、転送の判断を行うためのレイヤ３アドレスと、オプションとして、サービス品質（ＱｏＳ：Ｑｕａｌｉｔｙ  ｏｆ  Ｓｅｒｖｉｃｅ）要求のようなヒントに関するヘッダにおけるその他の情報と、だけを見る。パケットが転送されると、従来のルータは、パケットに関する履歴情報を保持しない。しかしながら、ルータがそのように構成されている場合であっても、統計的なデータを生成するために転送活動を収集することはできる。
【００３０】
したがって、ＩＰネットワークは、特にこの履歴情報を保持しないことから、「ステートレスな」ネットワークとみなされる。例えば、ＩＰネットワークは一般的に、各リクエストを、以前のいずれのリクエストにも関係しない独立したトランザクションとして処理する。したがって、ルータは、先行のパケットをどのように処理したかを顧みずに、パケットをルーティングすることができる。例えば、ＩＰネットワークは、典型的に、新規に加わった通信パートナの状態またはセッション情報を記憶しない。例えば、ネットワークの一部が、使用できない中間トランザクションになった場合には、リソースを再割り当てする必要はないか、またはさもなければ、ネットワークの状態を固定する必要はない。その代わりに、パケットをネットワーク内のその他のノードに沿ってルーティングすることができる。しかしながら、図示の実施の形態は、上記において参照により組み込まれた特許明細書に記載されているような、安全に通信を行うルータを含むことができる。
【００３１】
上記において述べたように、ルータは、一方のインタフェースを介して一方のネットワークからパケットを受信すると、自身のルーティングテーブルを使用して、そのパケットを他方のネットワークに向ける。表１には、基本的なＩＰルーティングテーブルから一般的に見て取れる情報が列挙されている。
【表１】
2018521534.tif 000003
【００３２】
ルーティングテーブルを、例えばシステム管理者によって手動で埋めることができるか、またはルータによって動的に埋めることができる。ルータは、その他のルータと情報を交換するためにルーティングプロトコルを使用し、またそれによって、周囲のネットワークまたはインターネットのトポロジを動的に学習する。例えば、ルータは、自身の存在を（１つまたは複数の）ネットワークに通知する。より詳細には、ルータは、自身がパケットを転送できるＩＰアドレスの範囲をネットワークに通知する。隣接するルータは、その情報を用いて自身のルーティングテーブルを更新し、また第１のルータの（１つまたは複数の）ネットワークへとパケットを転送する自身の能力をブロードキャストする。この情報は、必要に応じて、ネットワーク内のより遠隔のルータに拡散される。動的なルーティングによって、ルータは、ネットワークまたはインターネット内の変化に、例えば増大したネットワークの輻輳、新たなルータのインターネットへの追加、およびルータまたはリンクのエラーに反応することができる。
【００３３】
したがって、ルーティングテーブルは、パケットを各宛先へとルーティングするための一連の規則を提供する。パケットが到着すると、ルータは、パケットの内容を検査し、例えばそのパケットの宛先アドレスを検査し、ルーティングテーブルにおける最適な規則を発見する。その規則は、事実上、パケットを転送するためにどのインタフェースが使用されるかをルータに知らせ、またそのパケットの最終的な宛先ＩＰアドレスへの経路上においてそのパケットが転送されるノードのＩＰアドレスも知らせる。
【００３４】
ホップ・バイ・ホップ方式のルーティングでは、各ルーティングテーブルには、到達可能なすべての宛先に関して、その宛先への経路に沿った次ノード、すなわちネクストホップのアドレスが記載されている。ルーティングテーブルに矛盾がない場合を想定すれば、ネットワーク内のいずれかの場所にパケットを送信するには、パケットをその宛先の各ネクストホップへとリレーする各ルータの単純なアルゴリズムで十分である。ホップ・バイ・ホップ方式は、ＩＰインターネットワーク層およびＯＳＩネットワーク層の基本的な特性を表している。
【００３５】
したがって、各ルータのルーティングテーブルは、通常の場合、パケットを、そのパケットの宛先の「比較的近くに位置する」別のルータに転送するのに十分な情報しか含んでいないので、パケットが常にその宛先へと送信されることは保証していない。ある意味において、少なくとも大部分のパケットが最終的にその宛先へと到達することを目的として、パケットは、一連のルータを辿って、各ルータにおいてその時点での最新の規則を使用して、次にどのルータを辿るかを決定することによって、自身の宛先までの自身の経路を発見している。
【００３６】
例えば、ルータが輻輳した場合、またはリンクに障害が発生した場合、規則は１つのパケットの連続する２つのホップ間で、または１つのメッセージの連続する２つのパケット間で変化する可能性があることを言及しておく。したがって、１つのメッセージの２つのパケットが異なる経路を辿る可能性があり、それどころか順番通りに到着しない可能性がある。換言すれば、パケットが送信元ノードまたは起源ノードから送信される場合には、ネットワークがステートレスであることから、送信元ノードとパケットの宛先ノードとの間でパケットが取ることになる、事前に規定された経路は一般的に存在しない。その代わりに、典型的には、パケットが種々のルータを通過するときに、経路が動的に求められる。これは「自然なルーティング」と称することができる。つまり、パケットがインターネットを通過するときに、経路が動的に求められる。
【００３７】
自然なルーティングが長年にわたり上手く機能しているにもかかわらず、この自然なルーティングは欠点を有している。例えば、１つのセッションの各パケットが異なる経路に沿って伝播する可能性があり、また異なるルータのセットを通過する可能性があるので、セッションに関するメトリックを収集することは困難である。セッションのパケットに適用することができるセキュリティ機能を広範囲にわたり分散させなければならず、また、そのようなセキュリティ機能がすべてのパケットに適用されないリスクも考えられる。さらに、セッションへの攻撃が多くの場所から開始される可能性がある。
【００３８】
通常の場合、宛先ノードから再び送信元ノードへと送信されるパケットは、送信元ノードから宛先ノードへと送信されたパケットとは異なる経路を辿る可能性があることを言及しておく。
【００３９】
多くの状況において、クライアントコンピュータノード（「クライアント」）は、サーバコンピュータノード（「サーバ」）とセッションを確立し、またクライアントとサーバは、そのセッション内でパケットを交換する。例えば、ブラウザを実行しているクライアントは、従来のプロセスを使用して、ウェブサーバとのセッションを確立することができる。クライアントは、ウェブページをリクエストするために１つまたは複数のパケットを送信することができ、またウェブサーバは、ウェブページのコンテンツを含んでいる１つまたは複数のパケットでもって応答することができる。幾つかのタイプのセッションでは、パケットの往復的な交換を複数回のサイクルにわたり継続することができる。幾つかのタイプのセッションでは、パケットを２つのノード間で非同期的に送信することができる。下記において説明するように、周知のプロトコル、例えばセキュア・ソケット・レイヤ・プロトコル（「ＳＳＬ」：Ｓｅｃｕｒｅ  Ｓｏｃｋｅｔｓ  Ｌａｙｅｒ  Ｐｒｏｔｏｃｏｌ）またはトランスポート・レイヤ・セキュリティ・プロトコル（「ＴＬＳ」：Ｔｒａｎｓｐｏｒｔ  Ｌａｙｅｒ  Ｓｅｃｕｒｉｔｙ  Ｐｒｏｔｏｃｏｌ）を使用して、インターネットを介するセキュアなセッションを提供するために、このハンドシェイクを実施することができる。
【００４０】
セッションは、その通常の意味を有している。つまり、セッションとは、プロトコルに従って一方のノードから他方のノードへと送信される、各パケットが関連付けられている複数のパケットである。セッションは、そのセッションを開始する先行パケット（または最初のパケット）と、そのセッションの１つまたは複数の後続パケットと、を含むものと考えられる。セッションには、明確な開始および明確な終了が存在する。例えば、ＴＣＰセッションは、ＳＹＮパケットによって開始される。幾つかのケースにおいては、１つの所定のパケットまたは一連のパケットによって、終了を規定することができる。例えば、ＴＣＰセッションを、ＦＩＮ交換によってまたはＲＳＴによって終了させることができる。その他のケースにおいては、少なくとも事前に規定された長さの時間（タイムアウト時間）にわたり、ノード間で通信が行われないことによって終了を規定することができる。例えば、ＴＣＰセッションを、所定のタイムアウト期間後に終了させることができる。幾つかのセッションは、一方のノードから他方のノードへと送信されるパケットしか含んでいない。その他のセッションは、ウェブクライアントとサーバとのインタラクションの例のように、応答パケットを含んでいる。１つのセッションは、プロトコルに従った、何サイクルもの往復的な通信または非同期的な通信を含むことができるが、しかしながら、１つのセッションのすべてのパケットは、ノードの同一のクライアントとサーバのペア間で交換される。ここでは、セッションを一連のパケット（パケットシリーズ）とも称する。
【００４１】
単一ＩＰアドレスを有しているコンピュータは、種々のサービス、例えばＷｅｂサービス、Ｅメールサービスおよびファイル転送（ＦＴＰ：Ｆｉｌｅ  Ｔｒａｎｓｆｅｒ  Ｐｒｏｔｏｃｏｌ）サービスを提供することができる。一般的に、各サービスには、コンピュータ上でユニークである、０〜６５，５３５の範囲のポート番号が割り当てられている。したがって、サービスは、ノードのＩＰアドレスとサービスのポート番号との組合せによって規定されている。この組合せは、コンピュータが接続されているネットワーク内でユニークであり、またインターネット内でもユニークであることが多いことを言及しておく。同様に、単一のノードにおいて多数のクライアントを実行することができる。したがって、サービスをリクエストするクライアントには、そのクライアントのノードにおけるユニークなポート番号が割り当てられているので、サービスからの戻りパケットを、リクエストを行ったクライアント宛てに一意に送ることができる。
【００４２】
ソケットという用語は、ＩＰアドレスとポート番号との組合せを意味している。したがって、各サービスは、ネットワーク固有の、またインターネット固有であることも多いサービスソケットを有しており、サービスをリクエストするクライアントには、ネットワーク固有の、またインターネット固有である場合もあるクライアントソケットが割り当てられている。ところによっては、送信元クライアントおよび宛先サービスという用語は、サービスをリクエストするためにパケットを送信するクライアントおよびリクエストされているサービスをそれぞれ表す際に使用される。
【００４３】
ネットワークのセキュリティおよび制御
上記において述べたように、パブリックＩＰネットワークまたはパブリックインターネットを介して（例えばＩｎｔｅｒｎｅｔを介して）セッションのパケットをルーティングする際に問題が生じる可能性がある。例えば、図１のネットワークを使用して、ノードＤは、リンク４、ノードＢおよびリンク２を介して、パケットをノードＣに伝送することができる。しかしながら、このルート沿いの人間またはデバイスが、慣例の技術を使用してパケットを改竄する可能性がある。例えば、ノードＢは、ＴＣＰセッションの最初のパケットを開いて変更する悪意のある従業員が居るデータセンタの一部である可能性がある。機密性の潜在的な漏洩に加えて、そのような変更は、ウィルスの拡散、セッションパラメータの変更のような他の有害な結果をもたらす可能性があるか、またはセッション自体に有害な影響を及ぼす可能性がある。
【００４４】
この問題を緩和するために、図示の実施の形態では、特別に構成されたルーティングデバイス／ノード（例えばルータ）がネットワーク内に設置されている。図４には、それらの特別に構成されたノードを有しているパブリックネットワークの他の表現が概略的に示されている。この図において、特別に構成されている各ノードは、全体として、参照番号「４００」によって識別される。図示されているように、ネットワークは、送信元（例えば、消費者のホームパーソナルコンピュータのような「クライアントデバイス」）を有しており、この送信元は宛先（例えば、ビデオを配信するウェブサーバのような「サーバデバイス」）と、複数の小規模ネットワーク４０２およびノード４００を介して通信する。幾つかのノード４００は、小規模ネットワーク４０２と接続されているか、または他のノード４００と接続されている。図示されてはいないが、実際には、幾つかのノード４００が図４の小規模ネットワーク４０２内に存在していると考えられる。当業者であれば、他の複数のネットワークトポロジのいずれかを使用できることを言及しておく。つまり、図１のネットワークと同様に、図４のネットワークは、説明を目的として使用される単純化された例であり、したがって、本発明の種々の実施の形態を制限するものではない。
【００４５】
図４の特別に構成された各ノード４００は、対応する特別に構成された複数の機能コンポーネントから機能を得る。そのために、図５には、本発明の図示の実施の形態に従って構成されている単一のノードが概略的に示されている。この実現形態においては、ノード４００は、好適には、ネットワークルーティングデバイスであり、図４のＩＰネットワークのようなネットワークを介してルーティングされたレイヤ３セッションパケットを処理する。
【００４６】
この実施の形態のネットワークルーティングデバイスは、ネットワークと通信するためのＩ／Ｏインタフェース５００と、ネットワークを介してパケットをルーティングするルーティングモジュール５０２と、暗号化、復号および関連するプロセスを管理するための暗号化エンジン５０４と、を含んでいる。
【００４７】
Ｉ／Ｏインタフェース５００は、単一の物理的なインタフェースおよびそれに付随するソフトウェア（例えばドライバソフトウェア）を含むことができるか、または複数のインタフェースおよびそれらに付随するソフトウェアを含むことができる。例えば、図３のルータ３００と同様に、Ｉ／Ｏインタフェース５００は、ネットワークデバイスの第１のセットと通信するための第１のインタフェースと、ネットワークデバイスの第２のセットと通信するための第２のインタフェースと、ネットワークデバイスの第３のセットと通信するための第３のインタフェースと、を含むことができる。所定のセッションに関して、それらのインタフェースのうちの１つを入力インタフェースとみなすことができ、それに対し、別の１つのインタフェースを出力インタフェースとみなすことができる。もちろん、当業者であれば、特定のネットワークデバイスおよびそれが接続されているネットワークのトポロジに対する要求に応じて、Ｉ／Ｏインタフェース５００を構成することができる。
【００４８】
さらに、ネットワークデバイスは、ディジタル署名機能（例えば、ディジタル署名の生成および検証）を管理する署名モジュール５０６と、ノード４００によって使用される暗号化鍵および認証鍵を管理する鍵マネージャ５０８と、ネットワーキングデータおよびプライベート認証鍵のような他のデータを記憶するためのデータストレージデバイス５１０と、を含んでいる。図６についての下記の記述においてより詳細に説明するように、署名モジュール５０６は、処理された署名データを、パケット内の特定のデータと比較し、また特定の状況下では、例えばパケットの認証が成功した場合には、パケットに対してディジタル署名を行う。
【００４９】
それらの各コンポーネントは、慣例の相互接続メカニズムによって、適切に作用するように接続されている。一例として、図５には、各コンポーネントが通信するバス５１２が簡潔に示されている。しかしながら、当業者であれば、この一般化された表現を修正して、他の慣例の直接的または間接的なコネクションを含ませられることが分かる。したがって、バス５１２の議論は、種々の実施の形態を制限することは意図していない。
【００５０】
確かに、図５には、それらの各コンポーネントが単に概略的に示されている。当業者であれば、例えば１つまたは複数の他の機能コンポーネントを介して、ハードウェア、ソフトウェア、またはハードウェアおよびソフトウェアの組合せを使用して、それらの各コンポーネントを慣例の種々のやり方で実現できることが分かる。例えば、署名モジュール５０６を、ファームウェアを実行する複数のマイクロプロセッサを使用して実現することができる。別の例として、署名モジュール５０６を、１つまたは複数の特定用途向け集積回路（すなわち「ＡＳＩＣ」）および関連するソフトウェアを使用して、またはＡＳＩＣ、離散的な電子コンポーネント（例えばトランジスタ）およびマイクロプロセッサの組合せを使用して実現することができる。したがって、図５における、署名モジュール５０６および他のコンポーネントの単一のボックスでの表現は、単に簡略化を目的としている。実際には、幾つかの実施の形態では、図５のネットワークルーティングデバイスが複数の異なるマシンにわたり分散されており、その機能が、単一のケーシングまたはシャシ内にある必要はない。
【００５１】
ここで繰り返し述べるが、図５の表現は、実際のネットワークルーティングデバイス／ノード４００の極めて単純化された表現である。当業者であれば、そのようなデバイスは、他の多くの物理的なコンポーネントおよび機能コンポーネント、例えば中央処理ユニット、他のパケット処理モジュール、および種々のタイプのメモリ（例えば、短期記憶用メモリ、付加的な長期記憶用メモリ等）を有していることが分かる。したがって、ここでの議論は、図５がネットワークルーティングデバイスのすべての構成要素を表すことを示唆することを意図していない。
【００５２】
上記において述べたように、他のネットワークポイントとの間で、図５のノード４００は、図４に示した送信元と宛先との間のセッションにおけるパケットを受信、処理および伝送する。それらのパケットは、双方向性のものであってよい。すなわち、パケットを送信元から宛先へと送ることができるか（例えば、ビデオストリームのようなデータの要求）、または宛先から送信元へと送ることができる（例えば、上述のビデオストリームの要求に対する応答としてのビデオストリーム）。そのために、図６には、本発明の図示の実施の形態に従って構成されているパケット６００の４つの主要な部分が概略的に示されている。
【００５３】
この図示したパケット６００は、好適には、少なくとも４つの主要な部分を有している。特に、パケット６００は、上記において述べた２つの部分を有している。すなわち、パケット６００は、「ＩＰヘッダ６０２」として公知であり、かつパケット６００を受信するネットワークデバイス（例えば、宛先）のアドレス、パケット６００を送信するネットワークデバイス（例えば、送信元）の識別子、およびパケット６００をルーティングするための他のデータを含んでいるヘッダ６０２を有している。またパケット６００は、伝達される情報（例えば、テキストデータ、グラフィックデータ、オーディオデータ、またはビデオデータ）を含んでいるペイロード６０４も有している。
【００５４】
図示の実施の形態によれば、パケット６００がさらにメタデータ６０６を含んでおり、このメタデータ６０６は、（１）セッション自体および（２）ペイロードデータ６０４の一方または両方に関連する情報を含んでいる。このメタデータ６０６は、一般的に、セッションの１つの最初のパケットにおいてのみ、または複数の最初のパケットのうちの１つにおいてのみ送信する必要がある１つの時間データを含むことになると期待される。例えば、メタデータ６０６は、ユーザ／送信元に割り当てられた帯域幅、ユーザプロフィール、戻りアドレス、ポリシー情報、アクセスコントロール、およびセッションのための暗号化アルゴリズムに関する情報を含むことができる。さらに、またはより詳細には、メタデータ６０６は、とりわけ以下の情報を含むこともできる：
・本来の送信元ＩＰアドレスおよびポート、
・セッションに関して提案されたセキュリティパラメータ（権限レベル、アクセスが許可されたネットワークセグメント、アクセスが許可されたサービス等を含む）、
・トラフィックエンジニアリングパラメータ（最小帯域幅および最大帯域幅、サービス品質（ＱｏＳ）パラメータ、最小許容パケットレートおよび最大許容パケットレート等を含む）、
・優先レベル、
・後続のパケットが認証されるか否かに関する情報、および
・後続のパケットが暗号化されるか否かに関する情報。
【００５５】
一例として、送信元には、そのパーソナルコンピュータの消費者が含まれると考えられ、他方、宛先には、ビデオオンデマンドのコンテンツをその消費者に伝送するためのビデオサーバが含まれると考えられる。とりわけ、メタデータ６０６は、消費者が対価を払ったサービスのレベルに関連する情報を含むことができ、またビデオサービスを配給する会社のメンバシップステータスに基づいた、その特定の消費者が利用できる映画の選択も含むことができる。確かに、このタイプの情報は、１つの最初のパケットまたは複数の最初のパケットのうちの１つにおいて伝送されることが期待され、したがって宛先によって受信された後に伝送されることは要求されない。
【００５６】
最後に、パケット６００は、そのデータを認証するための、有利にはペイロードおよび／またはメタデータを認証するための、ディジタル署名６０８も含んでいる。下記において図７に関連させてより詳細に説明するように、ディジタル署名６０８は、好適には、少なくとも、暗号化されたまたは暗号化されていないペイロード６０４およびメタデータ６０６に適用されるプライベート認証鍵を使用して形成される。パケット６００が最終的な宛先によって受信される前に、（暗号化されたまたは暗号化されていない）ペイロード６０４またはメタデータ６０６がセッションにおける任意のポイントで変更された場合には、署名６０８は無効になる。したがって、署名６０８は、セッションに関するデータの有効性の保証において重要な役割を担う。
【００５７】
図７は、本発明の図示の実施の形態による、１つまたは複数のセッションパケットを処理するための図５のノード４００によって使用されるプロセスを示す。このノード４００を、択一的に「現ノード４００」と称することもできる。このプロセスは、パケット６００を処理するために通常使用されるであろう、より長いプロセスに比べて大幅に簡略化されていることを言及しておく。したがって、このプロセスは、当業者が使用するであろうことが見込まれる他の多くのステップを有することができる。さらに、幾つかのステップを、図示されている順序とは異なる順序で実施することができるか、または同時に実施することができる。したがって、当業者であれば、このプロセスを適宜変更することができる。
【００５８】
しかしながら、プロセスの開始前に、現ノード４００は、ネットワーク内の他の関連ノード４００の秘密認証鍵のコピーを取得する。図示の実施の形態においては、ノード４００は、ネットワーク内のノード４００のうちの大部分またはすべてのノード、主としてネクストホップのノード４００の秘密認証鍵のコピーを取得する。そのために、始動時／ブートアップ時、また好適には始動後に周期的に、ノード４００の鍵マネージャ５０８は、上述の認証鍵を、ネットワークを介して鍵ネットワークデバイス４０４から要求する。ノード４００の識別子の検査後に、鍵ネットワークデバイス４０４は、要求された鍵をノード４００に転送する。したがって、鍵マネージャ５０８は、Ｉ／Ｏインタフェース５００において鍵を受信し、それらの鍵を、ノード４００のためのストレージデバイス５１０に記憶する。代替的な実施の形態においては、ノード４００は、図７のプロセスの実行中に、関連する秘密鍵を取得する。
【００５９】
種々異なる秘密認証鍵のいずれかを使用することができる。例えば、幾つかの実施の形態は、単純に、対称秘密認証鍵を使用することができる。他の実施の形態は、公開認証鍵・秘密認証鍵のペアを使用することができる。したがって、特定のタイプの認証鍵の議論は、本発明のすべての実施の形態を限定することを意図したものではない。
【００６０】
現ノード４００が関連する鍵を取得した後に、ステップ７００においてプロセスが開始され、このステップ７００では、現ノード４００のＩ／Ｏインタフェース５００を介して、セッションにおける最初のパケット６００が受信される。上記において述べたように、セッションにおける最初のパケット６００は、好適には、図６に示したようなフォーマットを有している。ＴＣＰプロトコルが実行される場合、例えば、最初のパケット６００は、単純に、送信元から送信された公知のＳＹＮパケットであってよい。この場合、ペイロード６０４は、少なくとも、慣例のＳＹＮパケットに一般的に含まれているペイロードデータを含んでいる。このプロセスを、ＴＣＰプロトコルを使用する場合には、宛先から再び送信元へと返送される、公知のＳＹＮ−ＡＣＫパケットに適用できることを言及しておく。したがって、このプロセスは二重認証技術に適用される。
【００６１】
ＴＣＰプロトコルを使用しない実施の形態では、最初のパケット６００として他のタイプのパケットを取得することができる。例えば、ユーザデータグラムプロトコル（ａ／ｋ／ａ「ＵＤＰプロトコル」）が実施される場合、最初のパケット６００は、ＴＣＰプロトコルの後続のパケットにおいて一般的に送信されるペイロード情報を有することができる。先の例の説明を続けると、そのようなペイロード６０４は、ビデオデータを含むことができる。
【００６２】
議論を目的として、受信した最初のパケット６００のペイロード６０４およびメタデータ６０６を、受信ルータ４００には公知の何らかの暗号化鍵を使用して、暗号化することができる。もちろん、そのような暗号化されたパケット６００の議論は、関連するデータを暗号化しないその他の種々の実施の形態を制限するものではない。幾つかの実施の形態は、暗号化されたデータを含んでいるパケット６００に適用することはできない。
【００６３】
パケット６００を受信した後に、署名モジュール５０６は、検証プロセスを開始する。そのために、署名モジュール５０６は、ディジタル署名６０８を処理して、処理されたディジタル署名を生成する（ステップ７０２）。この処理されたディジタル署名は、他の関連するパケットデータと比較するために、後に使用されることになる。特に、署名モジュール５０６は、秘密認証鍵を使用して、ディジタル署名６０８を処理し、処理されたディジタル署名を生成する。パケット６００がこのプロセスより前に改竄されていなかった場合には、この処理されたディジタル署名は、パケット６００におけるペイロード６０４およびメタデータ６０６と直接的な関係性を有している（ステップ７０８に関連させて下記において議論する）。
【００６４】
この例においては、署名モジュール５０６は、自身の固有の秘密認証鍵を、ストレージデバイス５１０から検索する。しかしながら、代替的な実施の形態は、より高速な検索のために、例えばローカルキャッシュのような、ローカルの高速メモリから秘密認証鍵を検索する。
【００６５】
幾つかの実施の形態では、ディジタル署名６０８を処理するためにノード４００の秘密認証鍵を使用するのではなく、むしろ別の秘密認証鍵、例えば署名６０８を生成した先行ノード４００の認証鍵を使用する。さらに、別の実施の形態においては、ディジタル署名６０８を形成する前に、先行ノード４００が、その本来のフォーマットに由来するデータを処理した可能性がある。例えば、先行ノード４００は、一方向ハッシュ関数を、ディジタル署名６０８に暗号化されているデータに対して実行した可能性がある。そのような場合であれば、署名モジュール５０６は、（１）さらに本来のデータを取得するために（すなわち、ペイロード６０４およびメタデータ６０６）を取得するために結果として生じたデータをさらに処理することができるか、または（２）単純に署名６０８の処理を停止することができ、その結果、処理されたディジタル署名は、ペイロード６０４およびメタデータ６０６のハッシュを含むことになる。図示の実施の形態は、後者のアプローチを採用する（すなわちオプション（２））。
【００６６】
図示の実施の形態においては、そのような先行ノード４００が、１つ前のホップネットワークデバイスである必要はない。その代わりに、先行ノード４００を、いずれの場合にも、ネットワークデバイスまたは他のネットワークによって、受信ノード４００から隔てることができる。図４を例とすると、「第１のノード」として識別されるノード４００が、図７のプロセスを実行するノード４００であってよい。したがって、処理されているパケット６００は、第１のノードによって暗号化された可能性があり、また数百、数千またはそれどころか数百万のネットワークデバイスを有している可能性がある、介在する小規模ネットワーク４０２を介して、第２のノードに転送された可能性がある。
【００６７】
第２の例として、第４のノードが、図７のプロセスを実行するノード４００であってよい。この場合、処理されているパケット６００は、１つ前のホップネットワークノード４００である第３のノードによって暗号化された可能性がある。第２の例を使用するさらに別の実施の形態においては、図７のプロセスを実行するように構成されている複数の介在ノード４００が、それらの処理をスキップした可能性がある。この例においては、第１のノードまたは第２のノードの一方のみが、第４のノードによる処理が意図されているパケット６００を暗号化した可能性がある。
【００６８】
幾つかの実施の形態では、運ばれるデータの機密性を保証するために、暗号化鍵（例えば、現ノード４００または先行ノード４００のいずれかの暗号化鍵）を使用してペイロード６０４およびメタデータ６０６が暗号化される。他の実施の形態では、ペイロード６０４およびメタデータ６０６が暗号化されない。しかしながら、図示の実施の形態では暗号化を行うことができ、したがってこのプロセスは、それらのデータが暗号化されることを想定して継続される。
【００６９】
プロセスはステップ７０４に続き、このステップ７０４は、ペイロード６０４およびメタデータ６０６を処理して、ディジタル署名６０８を検証するために使用することができる形態にする。そのために、暗号化エンジン５０４は、パケット６００のペイロード６０４およびメタデータ６０６を復号するために、適切な暗号化鍵を使用する。幾つかの実施の形態では、ディジタル署名６０８に使用される認証鍵と同様に、ノードの固有のディジタル暗号化鍵を使用することができるか、または別のノード４００の暗号化鍵、例えばデータを暗号化した先行ノード４００の暗号化鍵を使用することができる。
【００７０】
次に、署名モジュール５０６は、確認情報を生成するために、公知の一方向ハッシュ関数を使用して、ペイロード６０４およびメタデータ６０６をさらに処理する。代替的な実施の形態においては、署名モジュール５０６は、このハッシュプロセスをスキップすることができる。
【００７１】
ここで署名モジュール５０６（または他の機能コンポーネント、例えばノード４００におけるマイクロプロセッサ）は、ステップ７０６において、２つのデータセットを比較し、すなわち処理されたディジタル署名と確認情報とを比較し、それらのデータセットが合致するかを判定する（ステップ７０８）。図示の実施の形態においては、２つのデータセットは、それらが正確に同一である場合にのみ合致しているとみなされる。例えば、ペイロード６０４およびメタデータ６０６をハッシュする実施の形態においては、処理されたディジタル署名は、上記において説明したような一方向ハッシュ関数を使用する、ペイロード６０４およびメタデータ６０６のハッシュと同一のハッシュ値である。
【００７２】
合致しない場合には、署名モジュール５０６は、パケット６００を廃棄し（ステップ７１０）、先行ノード４００にエラー状態を通知する（ステップ７１２）。特に、合致しない場合には、先行ノード４００とこの現ノード４００との間の誰かまたはデバイスが、ペイロード６０４および／またはメタデータ６０６を改竄した可能性がある。換言すれば、「中間者攻撃」によってパケット６００が改竄された可能性がある。エラー状態通知の受信によって、好適には、起源デバイス、例えば送信元に返送されるべきメッセージが形成される。送信元は、多数あるやり方のうちのいずれかによって応答することができ、例えばセッションの再確立を試みないことによって、またはセッションを再確立するための他の試みを行うことによって応答することができる。
【００７３】
反対に、ステップ７０８において、比較されたデータが合致していると判定された場合には、署名モジュール５０６は、パケット６００に対してディジタル署名を行う（ステップ７１４）。そのために、署名モジュール５０６は、次ノード４００の秘密ディジタル認証鍵を検索し、ハッシュ値を生成するために（例えば、上述の一方向ハッシュ関数を使用して）ペイロード６０４およびメタデータ６０６をハッシュし、続いてパケット６００に対してディジタル署名を行うために、ハッシュ値を処理することができる。上記において述べたように、幾つかの実施の形態では、署名６０８を形成する前に、ペイロード６０４および／またはメタデータ６０６をさらに処理することはできない。また、機密性のために、暗号化エンジン５０４は、暗号化鍵を使用してペイロード６０４および／またはメタデータ６０６を暗号化することができる。
【００７４】
幾つかの実施の形態では、ＩＰヘッダ６０２と、ペイロード６０４およびメタデータ６０６の暗号化されたハッシュと、を使用して、パケット６００に対して署名を行うために認証鍵を使用することができる。以下の擬似コードは、そのようなステップを実施することができる：
ＳｉｇｎＵｓｉｎｇＡｕｔｈｅｎｔｉｃａｔｉｏｎＫｅｙ  （ＩＰＨｅａｄｅｒ＋ｅｎｃｒｙｐｔｅｄ（Ｈａｓｈ（ｐａｙｌｏａｄ  ｐｌｕｓ  ｍｅｔａｄａｔａ）））
【００７５】
幾つかの実施の形態は、次ノード４００の秘密ディジタル認証鍵を使用するのではなく、むしろ別のノード４００の、例えばパケット６００を処理するノード４００の秘密ディジタル認証鍵を使用することができる。当業者であれば、それらの特定の用途の仕様に基づいて、適切な鍵を選択することができる。
【００７６】
したがって、種々の実施の形態では、ディジタル署名６０８を検証するために、ハッシュ、生のペイロード６０４およびメタデータ６０６、および／または他の技術を使用する。実際には、幾つかの実施の形態は、確認情報と比較するための何らかの比較データを生成するために、ディジタル署名６０８を処理することができるが、これは必ずしも必要ではない。当業者であれば、それらの特定の用途に関して、適切な技術を選択することができる。したがって、種々の実施の形態は、ディジタル署名６０８、ペイロードデータ６０４、およびメタデータ６０６を処理する特定のやり方に制限される必要はない。
【００７７】
最後に、パケット６００の署名を行った後に、ルーティングモジュール５０２は、署名されたパケット６００を、Ｉ／Ｏインタフェース５００を介して次ノード４００に転送する（ステップ７１６）。このパケット６００は、図７のプロセスを実行するように特別に構成されている別のノード４００によって受信されるまで、ネットワークに沿って伝播し続ける。
【００７８】
当業者には公知であるように、セッションは、典型的には、最初のセッションパケットと、複数の中間セッションパケットと、最後のセッションパケットと、を含んでいる。本発明の図示の実施の形態は、最初のパケット６００に対してのみ図７のこのプロセスを実行する。これは、類似のやり方で中間パケットを処理するノード４００と比較した場合、オーバヘッドコストを低減する。それにもかかわらず、幾つかの実施の形態は、セッションの第２のパケット、セッションの第３のパケット、またはセッションにおける事前に規定された任意の数の付加的なパケット（それどころか最後のパケット）に対して図７のプロセスを繰り返すことができる。したがって、最初のパケット６００のみを用いる使用の議論は、説明を目的としたものに過ぎず、すべての実施の形態を制限することは意図していない。さらに別の実施の形態は、最初のパケット６００に対するプロセスをスキップすることができる。その代わりに、この場合には、それらの実施の形態は、後続のパケット、例えば第２のパケットまたは第３のパケットにおいてプロセスを実行することができる。
【００７９】
この処理されたパケット６００は、次ノード４００を通過し続け、最終的には、宛先に到達する。幾つかの実施の形態においては、ノード４００のうちの１つ、例えば論理的に宛先の直前に位置しているノード４００が、パケットを宛先に転送する前に、ディジタル署名６０８を除去する。しかしながら、別の実施の形態は、宛先においてディジタル署名６０８を除去することができる。さらに別の実施の形態では、宛先は、ディジタル署名６０８を有するパケット６００を変更せずに受信することができる。
【００８０】
ここでもまた、種々の実施の形態が、宛先と送信元との間で伝播する他のセッションパケット６００に対して、このプロセスを繰り返すことを言及しておく。さらに、図示の実施の形態は、このプロセスを、上記において参照により組み込まれた特許明細書のステートフルなプロセスを実行する中間地点またはノード４００において実施する。
【００８１】
したがって、発明者には公知の従来技術によるルーティングデバイスとは異なり、図示の実施の形態は、２つのネットワークデバイス間でのレイヤ３（ネットワーク層）での伝送においてより高い安全性を保証するために、ペイロード６０４およびメタデータ６０６の情報を使用して、少なくとも１つのセッションパケットに対してディジタル署名を行う。そのようなプロセスは、不所望にもネットワークデバイスを攻撃に晒す可能性があるレイヤ７（アプリケーション層）認証プロセス（例えばファイヤウォール内で実施される認証プロセス）の使用の必要性を排除する。
【００８２】
本発明の種々の実施の形態を、少なくとも部分的に、任意の慣例のコンピュータプログラミング言語で実現することができる。例えば、幾つかの実施の形態を、手続き型プログラミング言語（例えば「Ｃ」）、またはオブジェクト指向プログラミング言語（例えば「Ｃ＋＋」）で実現することができる。本発明のその他の実施の形態を、事前構成されたスタンドアローン型のハードウェア要素および／または事前プログラミングされたハードウェア要素（例えば特定用途向け集積回路、ＦＰＧＡおよびディジタル・シグナル・プロセッサ）として、またはその他の関連するコンポーネントとして実現することができる。
【００８３】
１つの代替的な実施の形態においては、開示した装置および方法（例えば上述の種々のフローチャートを参照されたい）を、コンピュータシステムを用いて使用するためのコンピュータプログラム製品として実現することができる。そのような実現形態は、実体のある非一時的な媒体、例えばコンピュータ可読媒体（例えば、ディスケット（登録商標）、ＣＤ−ＲＯＭ、ＲＯＭまたは固定ディスク）に記憶されている一連のコンピュータ命令を含むことができる。一連のコンピュータ命令は、本明細書においてシステムに関して上述した機能のすべてまたは一部を実施することができる。
【００８４】
当業者であれば、そのようなコンピュータ命令を、多くのコンピュータアーキテクチャまたはオペレーティングシステムを用いて使用するために、多数のプログラミング言語で書けることが分かる。さらに、そのような命令を、任意のメモリデバイスに、例えば半導体デバイス、磁気デバイス、光学デバイスまたはその他のメモリデバイスに記憶することができ、また、任意の通信技術を使用して、例えば光学伝送技術、赤外線伝送技術、マイクロ波伝送技術またはその他の伝送技術を使用して伝送することができる。
【００８５】
この他、そのようなコンピュータプログラム製品を、リムーバブル媒体として、印刷された文書または電子文書と共に配布することができ（例えば市販ソフトウェア）、コンピュータシステムに（例えばシステムＲＯＭまたは固定ディスクに）プリロードすることができるか、もしくはネットワーク（例えばインターネットまたはワールド・ワイド・ウェブ）を介してサーバまたは電子掲示板から配布することができる。実際には、幾つかの実施の形態を、ＳａａＳ（Ｓｏｆｔｗａｒｅ  ａｓ  ａ  Ｓｅｒｖｉｃｅ）モデルまたはクラウドコンピューティングモデルとして実現することができる。もちろん、本発明の幾つかの実施の形態を、ソフトウェア（例えばコンピュータプログラム製品）とハードウェアの組合せとして実現することができる。本発明のさらに別の実施の形態は、完全にハードウェアとして、または完全にソフトウェアとして実現される。
【００８６】
上記においては、本発明の種々の実施例を説明したが、当業者であれば、本発明の真の精神から逸脱することなく、本発明の幾つかの利点を達成する種々の変更を行えることが分かる。
【図１】
2018521534.tif 000004
【図２】
2018521534.tif 000005
【図３】
2018521534.tif 000006
【図４】
2018521534.tif 000007
【図５】
2018521534.tif 000008
【図６】
2018521534.tif 000009
【図７】
2018521534.tif 000010
【国際調査報告】
2018521534.tif 000011
2018521534.tif 000012