Improvement to agile network protocol for secure communication with assured system availability
Abstract
Problem to be solved.To establish a secure communication link between a first computer and a second computer on a computer network.
Solution.A secure communication mode of communication is enabled on a first computer without the user inputting encryption information for establishing a secure communication mode of communication, and then the enabled communication is performed. A secure communication link is established between the first computer and the second computer on the computer network based on the secure communication mode, and the secure communication link is a virtual dedicated network communication link on the computer network. At the link, insert one or more data values that change according to a pseudo-random sequence into each data packet. [Selection diagram] Fig. 2

Term
Projected expiry 26 October 2030.
- Priority
- Filed
- Published
- Today
- Projected expiry
116 claims: 24 independent, 92 dependent
- 1コンピュータ・ネットワーク上で、第1のコンピュータと第2のコンピュータとの間に安全通信リンクを確立する方法であって、 通信の安全通信モードを確立するためのいかなる暗号化情報もユーザが入力することなく、第1のコンピュータで通信の安全通信モードを使用可能にする段階、および 使用可能にされた通信の安全通信モードに基づくコンピュータ・ネットワーク上で、第1のコンピュータと第2のコンピュータとの間に安全通信リンクを確立する段階を含み、安全通信リンクが、コンピュータ・ネットワーク上の仮想専用ネットワーク通信リンクである方法。
- 2通信の安全通信モードを使用可能にする段階に応答して、第1のコンピュータ上に安全通信ソフトウェア・モジュールが記憶されているかどうかを判定する段階、 第1のコンピュータ上にソフトウェア・モジュールが記憶されていないときに、安全通信ソフトウェア・モジュールをロードするために、所定のコンピュータ・ネットワーク・アドレスにアクセスする段階、および 第1のコンピュータにソフトウェア・モジュールを記憶する段階をさらに含む、請求項1記載の方法。
- 3仮想専用ネットワークが、擬似乱数シーケンスに従って変化する1つまたは複数のデータ値を、各データ・パケットに挿入することに基づく、請求項1記載の方法。
- 4仮想専用ネットワークが、仮想専用ネットワークに関連する所定のサービス・レベルを表す少なくとも1つのデータ値を、少なくとも1つのデータ・パケットに挿入することに基づく、請求項1記載の方法。
- 5仮想専用ネットワークが、第1のコンピュータと第2のコンピュータとの間で送信されるパケット内のコンピュータ・ネットワーク・アドレスを、擬似乱数的に変更するのに用いられるコンピュータ・ネットワーク・アドレス・ホッピング方式に基づく、請求項1記載の方法。
- 6仮想専用ネットワークが、第1のコンピュータと第2のコンピュータとの間で送信される各データ・パケット内の値を、妥当な値の移動ウィンドウと比較することに基づく、請求項1記載の方法。
- 7仮想専用ネットワークが、各データ・パケットのヘッダ内のディスクリミネータ・フィールドを、第1のコンピュータ用に維持されている妥当なディスクリミネータ・フィールドのテーブルと比較することに基づく、請求項1記載の方法。
- 8コンピュータ・ネットワークがインターネットを含む、請求項1記載の方法。
- 9通信の安全通信モードを使用可能にする段階が、安全通信モードを指定するコマンドを第1のコンピュータに入力する段階を含む、請求項1記載の方法。
- 10コマンドが、通信の安全通信モードに関連するセットアップ・パラメータを定義するために入力され、かつ 安全通信リンクが、コンピュータ・ネットワーク上に通信リンクが確立されたときに自動的に確立される、請求項9記載の方法。
- 11安全通信リンク動作モードを使用可能にする段階が、第1のコンピュータの表示装置上に表示されたアイコンを選択する段階を含む、請求項1記載の方法。
- 12安全通信リンクが確立されていることの表示を、第1のコンピュータのディスプレイ上に表示する段階をさらに含む、請求項1記載の方法。
- 13表示がアイコンである、請求項12記載の方法。
- 14安全通信リンクが、安全通信リンク階層内の複数の安全通信リンクのうちの1つである、請求項1記載の方法。
- 15安全通信リンクが、コンピュータ・ネットワークに接続された安全ポータルを介し、かつ 第2のコンピュータが安全ドメイン名サービスを含む、請求項1記載の方法。
- 16コンピュータ可読記憶媒体であって、 記憶領域、および コンピュータ・ネットワーク上で、第1のコンピュータと第2のコンピュータとの間に安全通信リンクを確立する方法に関するコンピュータ可読命令を含み、該方法が、 通信の安全通信モードを確立するためのいかなる暗号化情報もユーザが入力することなく、第1のコンピュータで通信の安全通信モードを使用可能にする段階、および 使用可能にされた通信の安全通信モードに基づくコンピュータ・ネットワーク上で、第1のコンピュータと第2のコンピュータとの間に安全通信リンクを確立する段階を含み、安全通信リンクが、コンピュータ・ネットワーク上の仮想専用ネットワーク通信リンクである、コンピュータ可読記憶媒体。
- 17通信の安全通信モードを使用可能にする段階に応答して、第1のコンピュータ上に安全通信ソフトウェア・モジュールが記憶されているかどうかを判定する段階、 第1のコンピュータ上にソフトウェア・モジュールが記憶されていないときに、安全通信ソフトウェア・モジュールをロードするために、所定のコンピュータ・ネットワーク・アドレスにアクセスする段階、および 第1のコンピュータにソフトウェア・モジュールを記憶する段階をさらに含む、請求項15記載のコンピュータ可読記憶媒体。
- 18仮想専用ネットワークが、仮想専用ネットワークに関連する所定のサービス・レベルを表す少なくとも1つのデータ値を、少なくとも1つのデータ・パケットに挿入することに基づく、請求項16記載のコンピュータ可読記憶媒体。
- 19仮想専用ネットワークが、擬似乱数シーケンスに従って変化する1つまたは複数のデータ値を、各データ・パケットに挿入することに基づく、請求項16記載のコンピュータ可読記憶媒体。
- 20仮想専用ネットワークが、第1のコンピュータと第2のコンピュータとの間で送信されるパケット内のコンピュータ・ネットワーク・アドレスを、擬似乱数的に変更するのに用いられる、コンピュータ・ネットワーク・アドレス・ホッピング方式に基づく、請求項16記載のコンピュータ可読記憶媒体。
- 21仮想専用ネットワークが、第1のコンピュータと第2のコンピュータとの間で送信される各データ・パケット内の値を、妥当な値の移動ウィンドウと比較することに基づく、請求項16記載のコンピュータ可読記憶媒体。
- 22仮想専用ネットワークが、各データ・パケットのヘッダ内のディスクリミネータ・フィールドを、第1のコンピュータ用に維持されている妥当なディスクリミネータ・フィールドのテーブルと比較することに基づく、請求項16記載のコンピュータ可読記憶媒体。
- 23コンピュータ・ネットワークがインターネットを含む、請求項16記載のコンピュータ可読記憶媒体。
- 24通信の安全通信モードを使用可能にする段階が、安全通信モードを指定するコマンドを第1のコンピュータに入力する段階を含む、請求項16記載のコンピュータ可読記憶媒体。
- 25コマンドが、通信の安全通信モードに関連するセットアップ・パラメータを定義するために入力され、かつ 安全通信リンクが、コンピュータ・ネットワーク上に通信リンクが確立されたときに自動的に確立される、請求項24記載のコンピュータ可読記憶媒体。
- 26安全通信リンク動作モードを使用可能にする段階が、第1のコンピュータのディスプレイ装置上に表示されたアイコンを選択する段階を含む、請求項16記載のコンピュータ可読記憶媒体。
- 27安全通信リンクが確立されたことの表示を、第1のコンピュータのディスプレイ上に表示する段階をさらに含む、請求項16記載のコンピュータ可読記憶媒体。
- 28表示がアイコンである、請求項27記載のコンピュータ可読記憶媒体。
- 29安全通信リンクが、安全通信リンク階層内の複数の安全通信リンクのうちの1つである、請求項16記載のコンピュータ可読記憶媒体。
- 30安全通信リンクが、コンピュータ・ネットワークに接続された安全ポータルを介し、かつ 第2のコンピュータが安全ドメイン名サービスを含む、請求項16記載のコンピュータ可読記憶媒体。
- 31以下の段階を含む、安全コンピュータ・ネットワーク・アドレスにアクセスする方法:安全ドメイン名を受信する段階、 安全ドメイン名に対応する安全コンピュータ・ネットワーク・アドレスを要求する問合せメッセージを、安全ドメイン名サービスに送信する段階、 安全ドメイン名に対応する安全コンピュータ・ネットワーク・アドレスを含む、応答メッセージを受信する段階、および 安全コンピュータ・ネットワーク・アドレスに記憶されている情報を求める要求を含むアクセス要求メッセージを、仮想専用ネットワーク通信リンクを使用して安全コンピュータ・ネットワーク・アドレスに送信する段階。
- 32安全ドメイン名を受信する段階が、 所定の非安全ドメイン名に対応する安全コンピュータ・ネットワーク・アドレスとの仮想専用ネットワーク通信リンクを確立するための、コマンドを受信する段階、および 非安全ドメイン名に対応する安全ドメイン名を自動的に生成する段階を含む、請求項31記載の方法。
- 33仮想専用ネットワーク通信リンクを確立するためのコマンドを受信する段階が、コンピュータ・ディスプレイ上に表示された所定のアイコンを選択する段階を含む、請求項32記載の方法。
- 34応答メッセージが、仮想専用ネットワークに関する準備(provisioning)情報を含む、請求項31記載の方法。
- 35仮想専用ネットワークが、擬似乱数シーケンスに従って変化する1つまたは複数のデータ値を、安全コンピュータ・ネットワーク・アドレスに送信される各データ・パケットに挿入することに基づく、請求項34記載の方法。
- 36仮想専用ネットワークが、仮想専用ネットワークに関連する所定のサービス・レベルを表す少なくとも1つのデータ値を、少なくとも1つのデータ・パケットに挿入することに基づく、請求項34記載の方法。
- 37仮想専用ネットワークが、第1のコンピュータと第2のコンピュータとの間で送信されるパケット内のコンピュータ・ネットワーク・アドレスを、擬似乱数的に変更するのに用いられる、コンピュータ・ネットワーク・アドレス・ホッピング方式に基づく、請求項34記載の方法。
- 38仮想専用ネットワークが、安全コンピュータ・ネットワークに送信される各データ・パケット内の値を、妥当な値の移動ウィンドウと比較することに基づく、請求項34記載の方法。
- 39仮想専用ネットワークが、安全コンピュータ・ネットワーク・アドレスへの、各データ・パケットのヘッダ内のディスクリミネータ・フィールドを、妥当なディスクリミネータ・フィールドのテーブルと比較することに基づく、請求項34記載の方法。
- 40コンピュータ・ネットワークがインターネットを含む、請求項31記載の方法。
- 41安全ドメイン名が、.scom、.snet、.sorg、.sedu、.smil、または.sgovのうちの1つを含む、トップレベル・ドメイン名を有する、請求項31記載の方法。
- 42コンピュータ可読記憶媒体であって、 記憶領域、および 安全コンピュータ・ネットワーク・アドレスにアクセスする方法に関する、コンピュータ可読命令を含み、該方法が、 安全ドメイン名を受信する段階、 安全ドメイン名に対応する安全コンピュータ・ネットワーク・アドレスを要求する問合せメッセージを、安全ドメイン名サービスに送信する段階、 安全ドメイン名に対応する安全コンピュータ・ネットワーク・アドレスを含む、応答メッセージを受信する段階、および 安全コンピュータ・ネットワーク・アドレスに記憶されている情報を求める要求を含むアクセス要求メッセージを、仮想専用ネットワーク通信リンクを使用して安全コンピュータ・ネットワーク・アドレスに送信する段階を含む、コンピュータ可読記憶媒体。
- 43安全ドメイン名を受信する段階が、 所定の非安全ドメイン名に対応する、安全コンピュータ・ネットワーク・アドレスとの仮想専用ネットワーク通信リンクを確立するためのコマンドを受信する段階、および 非安全ドメイン名に対応する安全ドメイン名を自動的に生成する段階を含む、請求項42記載のコンピュータ可読記憶媒体。
- 44仮想専用ネットワーク通信リンクを確立するためのコマンドを受信する段階が、コンピュータ・ディスプレイ上に表示された所定のアイコンを選択する段階を含む、請求項43記載のコンピュータ可読記憶媒体。
- 45応答メッセージが仮想専用ネットワークに関する準備情報を含む、請求項42記載のコンピュータ可読記憶媒体。
- 46仮想専用ネットワークが、擬似乱数シーケンスに従って変化する1つまたは複数のデータ値を、安全コンピュータ・ネットワーク・アドレスに送信される各データ・パケットに挿入することに基づく、請求項45記載のコンピュータ可読記憶媒体。
- 47仮想専用ネットワークが、仮想専用ネットワークに関連する所定のサービス・レベルを表す少なくとも1つのデータ値を、少なくとも1つのデータ・パケットに挿入することに基づく、請求項45記載のコンピュータ可読記憶媒体。
- 48仮想専用ネットワークが、第1のコンピュータと第2のコンピュータとの間で送信されるパケット内のコンピュータ・ネットワーク・アドレスを、擬似乱数的に変更するのに用いられる、コンピュータ・ネットワーク・アドレス・ホッピング方式に基づく、請求項45記載のコンピュータ可読記憶媒体。
- 49仮想専用ネットワークが、安全コンピュータ・ネットワーク・アドレスに送信される各データ・パケット内の値を、妥当な値の移動ウィンドウと比較することに基づく、請求項45記載のコンピュータ可読記憶媒体。
- 50仮想専用ネットワークが、安全コンピュータ・ネットワーク・アドレスへの、各データ・パケットのヘッダ内のディスクリミネータ・フィールドを、妥当なディスクリミネータ・フィールドのテーブルと比較することに基づく、請求項45記載のコンピュータ可読記憶媒体。
- 51コンピュータ・ネットワークがインターネットを含む、請求項42記載のコンピュータ可読記憶媒体。
- 52安全ドメイン名が、.scom、.snet、.sorg、.sedu、.smil、または.sgovのうちの1つを含む、トップレベル・ドメイン名を有する、請求項42記載のコンピュータ可読記憶媒体。
- 53コンピュータ・ネットワーク上で、クライアント・コンピュータとサーバ・コンピュータとの間の専用通信リンクを使用して、通信する方法であって、 コンピュータ・ネットワーク上でクライアント・コンピュータからサーバ・コンピュータに情報パケットを送信する段階であって、該情報パケットが、クライアント・コンピュータとサーバ・コンピュータとの間に仮想専用接続を形成するのに用いられるデータを含み、仮想専用接続を形成するのに用いられるデータが、アプリケーション層プログラムによって、クライアント・コンピュータで情報パケットのペイロード部に挿入される段階、 サーバ・コンピュータ上のオペレーティング・システムのカーネル層で、情報パケットを受信する段階、および 情報パケットが、仮想専用接続を形成するのに用いられるデータを含んでいるかどうかを、サーバ・コンピュータ上のオペレーティング・システムのカーネル層で判定する段階を含む方法。
- 54情報パケットを、コンピュータ・ネットワーク上で送信する前にファイアウォールを通過させる段階をさらに含む、請求項53記載の方法。
- 55仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータによってクライアント・コンピュータに提供される、所定のレベルのサービスに対応する、請求項53記載の方法。
- 56コンピュータ・ネットワーク上でサーバ・コンピュータからクライアント・コンピュータに、第2の情報パケットを送信する段階をさらに含み、第2の情報パケットが、仮想専用接続を形成するのに用いられるデータを含み、仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータ上のオペレーティング・システムのカーネル層によって、第2の情報パケットのペイロード部に挿入される、請求項53記載の方法。
- 57情報パケットがUDPプロトコル情報パケットである、請求項53記載の方法。
- 58情報パケットが、TCP/IPプロトコル情報パケットおよびICMPプロトコル情報パケットのうちの1つである、請求項53記載の方法。
- 59仮想専用接続を形成するのに用いられるデータが、擬似乱数シーケンスに従って変化する1つまたは複数のデータ値を含む、請求項53記載の方法。
- 60仮想専用接続を形成するのに用いられるデータが、クライアント・コンピュータとサーバ・コンピュータとの間で送信されるパケット内のコンピュータ・ネットワーク・アドレスを、擬似乱数的に変更するのに用いられる、コンピュータ・ネットワーク・アドレス・ホッピング方式に基づく、請求項53記載の方法。
- 61仮想専用接続を形成するのに用いられるデータが、クライアント・コンピュータとサーバ・コンピュータとの間で送信される各データ・パケット内の値を、妥当な値の移動ウィンドウと比較することに基づく、請求項53記載の方法。
- 62仮想専用接続を形成するのに用いられるデータが、各データ・パケットのヘッダ内のディスクリミネータ・フィールドを、クライアント・コンピュータ用に維持されている妥当なディスクリミネータ・フィールドのテーブルと比較することに基づく、請求項53記載の方法。
- 63コンピュータ・ネットワークがインターネットを含む、請求項53記載の方法。
- 64コンピュータ可読記憶媒体であって、 記憶領域、および コンピュータ・ネットワーク上で、クライアント・コンピュータとサーバ・コンピュータとの間の専用通信リンクを使用して通信する方法に関する、コンピュータ可読命令を含み、該方法が、 コンピュータ・ネットワーク上でクライアント・コンピュータからサーバ・コンピュータに送信する段階であって、情報パケットが、クライアント・コンピュータとサーバ・コンピュータとの間に仮想専用接続を形成するのに用いられるデータを含み、仮想専用接続を形成するのに用いられるデータが、アプリケーション層プログラムによって、クライアント・コンピュータで情報パケットのペイロード部に挿入される段階、 サーバ・コンピュータ上のオペレーティング・システムのカーネル層で、情報パケットを受信する段階、および 情報パケットが、仮想専用接続を形成するのに用いられるデータを含んでいるかどうかを、サーバ・コンピュータ上のオペレーティング・システムのカーネル層で判定する段階を含む、コンピュータ可読記憶媒体。
- 65情報パケットを、コンピュータ・ネットワーク上で送信する前にファイアウォールを通過させる段階をさらに含む、請求項64記載のコンピュータ可読記憶媒体。
- 66仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータによってクライアント・コンピュータに提供される、所定のレベルのサービスに対応する、請求項64記載のコンピュータ可読記憶媒体。
- 67コンピュータ・ネットワーク上で、サーバ・コンピュータからクライアント・コンピュータに第2の情報パケットを送信する段階をさらに含み、第2の情報パケットが、仮想専用接続を形成するのに用いられるデータを含み、仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータ上のオペレーティング・システムのカーネル層によって、第2の情報パケットのペイロード部に挿入される、請求項64記載のコンピュータ可読記憶媒体。
- 68情報パケットがUDPプロトコル情報パケットである、請求項64記載のコンピュータ可読記憶媒体。
- 69情報パケットが、TCP/IPプロトコル情報パケットおよびICMPプロトコル情報パケットのうちの1つである、請求項64記載のコンピュータ可読記憶媒体。
- 70仮想専用接続を形成するのに用いられるデータが、擬似乱数シーケンスに従って変化する1つまたは複数のデータ値を含む、請求項64記載のコンピュータ可読記憶媒体。
- 71仮想専用接続を形成するのに用いられるデータが、クライアント・コンピュータとサーバ・コンピュータとの間で送信されるパケット内のコンピュータ・ネットワーク・アドレスを、擬似乱数的に変更するのに用いられる、コンピュータ・ネットワーク・アドレス・ホッピング方式に基づく、請求項64記載のコンピュータ可読記憶媒体。
- 72仮想専用接続を形成するのに用いられるデータが、クライアント・コンピュータとサーバ・コンピュータとの間で送信される各データ・パケット内の値を、妥当な値の移動ウィンドウと比較することに基づく、請求項64記載のコンピュータ可読記憶媒体。
- 73仮想専用接続を形成するのに用いられるデータが、各データ・パケットのヘッダ内のディスクリミネータ・フィールドを、クライアント・コンピュータ用に維持されている妥当なディスクリミネータ・フィールドのテーブルと比較することに基づく、請求項64記載のコンピュータ可読記憶媒体。
- 74コンピュータ・ネットワークがインターネットを含む、請求項64記載のコンピュータ可読記憶媒体。
- 75以下の段階を含む、コンピュータ・ネットワーク上でクライアント・コンピュータとサーバ・コンピュータとの間の専用通信リンクを使用して、通信する方法:クライアント・コンピュータで情報パケットを生成する段階、 クライアント・コンピュータとサーバ・コンピュータとの間に仮想専用接続を形成するのに用いられるデータを、情報パケットのペイロード部に挿入することによって、クライアント・コンピュータ内のアプリケーション層で情報パケットを修正する段階、および 修正された情報パケットを、コンピュータ・ネットワーク上でクライアント・コンピュータからサーバ・コンピュータに送信する段階。
- 76修正された情報パケットを、コンピュータ・ネットワーク上で送信する前にファイアウォールを通過させる段階をさらに含む、請求項75記載の方法。
- 77仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータによってクライアント・コンピュータに提供される所定のレベルのサービスに対応する、請求項75記載の方法。
- 78コンピュータ・ネットワーク上でサーバ・コンピュータから送信された情報パケットを、クライアント・コンピュータ内のアプリケーション層で受信する段階、および 情報パケットが、仮想専用接続を形成するのに用いられるデータを含んでいるかどうかを、クライアント・コンピュータのアプリケーション層で判定する段階をさらに含む、請求項75記載の方法。
- 79修正された情報パケットがUDPプロトコル情報パケットである、請求項75記載の方法。
- 80修正された情報パケットが、TCP/IPプロトコル情報パケットおよびICMPプロトコル情報パケットのうちの1つである、請求項75記載の方法。
- 81仮想専用接続を形成するのに用いられるデータが、擬似乱数シーケンスに従って変化する1つまたは複数のデータ値を含む、請求項75記載の方法。
- 82仮想専用接続を形成するのに用いられるデータが、クライアント・コンピュータとサーバ・コンピュータとの間で送信される情報パケット内のコンピュータ・ネットワーク・アドレスを擬似乱数的に変更するのに用いられる、コンピュータ・ネットワーク・アドレス・ホッピング方式に基づく、請求項75記載の方法。
- 83仮想専用接続を形成するのに用いられるデータが、クライアント・コンピュータとサーバ・コンピュータとの間で送信される各情報パケット内の値を、妥当な値の移動ウィンドウと比較することに基づく、請求項75記載の方法。
- 84仮想専用接続を形成するのに用いられるデータが、各情報パケットのヘッダ内のディスクリミネータ・フィールドを、クライアント・コンピュータ用に維持されている妥当なディスクリミネータ・フィールドのテーブルと比較することに基づく、請求項75記載の方法。
- 85コンピュータ・ネットワークがインターネットを含む、請求項75記載の方法。
- 86コンピュータ可読記憶媒体であって、 記憶領域、および コンピュータ・ネットワーク上で、クライアント・コンピュータとサーバ・コンピュータとの間の専用通信リンクを使用して通信する方法に関する、コンピュータ可読命令を含み、該方法が、 クライアント・コンピュータで情報パケットを生成する段階、 クライアント・コンピュータとサーバ・コンピュータとの間に仮想専用接続を形成するのに用いられるデータを、情報パケットのペイロード部に挿入することによって、クライアント・コンピュータ内のアプリケーション層で情報パケットを修正する段階、および 修正された情報パケットをコンピュータ・ネットワーク上でクライアント・コンピュータからサーバ・コンピュータに送信する段階を含む、コンピュータ可読記憶媒体。
- 87修正された情報パケットを、コンピュータ・ネットワーク上で送信する前にファイアウォールを通過させる段階をさらに含む、請求項86記載のコンピュータ可読記憶媒体。
- 88仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータによってクライアント・コンピュータに提供される、所定のレベルのサービスに対応する、請求項86記載のコンピュータ可読記憶媒体。
- 89コンピュータ・ネットワーク上でサーバ・コンピュータから送信された情報パケットを、クライアント・コンピュータ内のアプリケーション層で受信する段階、および 情報パケットが、仮想専用接続を形成するのに用いられるデータを含んでいるかどうかを、クライアント・コンピュータのアプリケーション層で判定する段階をさらに含む、請求項86記載のコンピュータ可読記憶媒体。
- 90修正された情報パケットがUDPプロトコル情報パケットである、請求項86記載のコンピュータ可読記憶媒体。
- 91修正された情報パケットが、TCP/IPプロトコル情報パケットおよびICMPプロトコル情報パケットのうちの1つである、請求項86記載のコンピュータ可読記憶媒体。
- 92仮想専用接続を形成するのに用いられるデータが、擬似乱数シーケンスに従って変化する1つまたは複数のデータ値を含む、請求項86記載のコンピュータ可読記憶媒体。
- 93仮想専用接続を形成するのに用いられるデータが、クライアント・コンピュータとサーバ・コンピュータとの間で送信される情報パケット内のコンピュータ・ネットワーク・アドレスを、擬似乱数的に変更するのに用いられる、コンピュータ・ネットワーク・アドレス・ホッピング方式に基づく、請求項86記載のコンピュータ可読記憶媒体。
- 94仮想専用接続を形成するのに用いられるデータが、クライアント・コンピュータとサーバ・コンピュータとの間で送信される各情報パケット内の値を、妥当な値の移動ウィンドウと比較することに基づく、請求項86記載のコンピュータ可読記憶媒体。
- 95仮想専用接続を形成するのに用いられるデータが、各情報パケットのヘッダ内のディスクリミネータ・フィールドを、クライアント・コンピュータ用に維持されている妥当なディスクリミネータ・フィールドのテーブルと比較することに基づく、請求項86記載のコンピュータ可読記憶媒体。
- 96コンピュータ・ネットワークがインターネットを含む、請求項86記載のコンピュータ可読記憶媒体。
- 97コンピュータ・ネットワーク上で、サーバ・コンピュータとクライアント・コンピュータとの間の専用通信リンクを使用して通信する方法であって、 サーバ・コンピュータで情報パケットを生成する段階、 サーバ・コンピュータとクライアント・コンピュータとの間に仮想専用接続を形成するのに用いられるデータを、情報パケットのペイロード部に挿入することによって、サーバ・コンピュータのオペレーティング・システム内のカーネル層で、情報パケットを修正する段階、および 修正された情報パケットを、コンピュータ・ネットワーク上でサーバ・コンピュータからクライアント・コンピュータ内のアプリケーション層に送信する段階を含む方法。
- 98修正された情報パケットが、コンピュータ・ネットワーク上で送信された後、クライアント・コンピュータでアプリケーション層によって受信される前に、修正された情報パケットをファイアウォールに通過させる段階をさらに含む、請求項97記載の方法。
- 99仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータによってクライアント・コンピュータに提供される、所定のレベルのサービスに対応する、請求項97記載の方法。
- 100修正された情報パケットがUDPプロトコル情報パケットである、請求項97記載の方法。
- 101修正された情報パケットが、TCP/IPプロトコル情報パケットおよびICMPプロトコル情報パケットのうちの1つである、請求項97記載の方法。
- 102仮想専用接続を形成するのに用いられるデータが、擬似乱数シーケンスに従って変化する1つまたは複数のデータ値を含む、請求項97記載の方法。
- 103仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータとクライアント・コンピュータとの間で送信される、修正された情報パケット内のコンピュータ・ネットワーク・アドレスを擬似乱数的に変更するのに用いられるコンピュータ・ネットワーク・アドレス・ホッピング方式に基づく、請求項97記載の方法。
- 104仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータとクライアント・コンピュータとの間で送信される各データの修正された情報パケット内の値を、妥当な値の移動ウィンドウと比較することに基づくデータである、請求項97記載の方法。
- 105仮想専用接続を形成するのに用いられるデータが、修正された各情報パケットのヘッダ内のディスクリミネータ・フィールドを、サーバ・コンピュータ用に維持されている妥当なディスクリミネータ・フィールドのテーブルと比較することに基づく、請求項97記載の方法。
- 106コンピュータ・ネットワークがインターネットを含む、請求項97記載の方法。
- 107コンピュータ可読記憶媒体であって、 記憶領域、および コンピュータ・ネットワーク上で、サーバ・コンピュータとクライアント・コンピュータとの間の専用通信リンクを使用して通信する方法に関する、コンピュータ可読命令を含み、該方法が、 サーバ・コンピュータで情報パケットを生成する段階、 サーバ・コンピュータとクライアント・コンピュータとの間に仮想専用接続を形成するのに用いられるデータを、情報パケットのペイロード部に挿入することによって、サーバ・コンピュータのオペレーティング・システム内のカーネル層で情報パケットを修正する段階、および 修正された情報パケットを、コンピュータ・ネットワーク上でサーバ・コンピュータからクライアント・コンピュータ内のアプリケーション層に送信する段階を含む、コンピュータ可読記憶媒体。
- 108修正された情報パケットが、コンピュータ・ネットワーク上で送信された後、クライアント・コンピュータでアプリケーション層によって受信される前に、修正された情報パケットをファイアウォールに通過させる段階をさらに含む、請求項107記載のコンピュータ可読記憶媒体。
- 109仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータによってクライアント・コンピュータに提供される、所定のレベルのサービスに対応する、請求項107記載のコンピュータ可読記憶媒体。
- 110修正された情報パケットがUDPプロトコル情報パケットである、請求項107記載のコンピュータ可読記憶媒体。
- 111修正された情報パケットが、TCP/IPプロトコル情報パケットおよびICMPプロトコル情報パケットのうちの1つである、請求項107記載のコンピュータ可読記憶媒体。
- 112仮想専用接続を形成するのに用いられるデータが、擬似乱数シーケンスに従って変化する1つまたは複数のデータ値を含む、請求項107記載のコンピュータ可読記憶媒体。
- 113仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータとクライアント・コンピュータとの間で送信されるパケット内のコンピュータ・ネットワーク・アドレスを、擬似乱数的に変更するのに用いられる、コンピュータ・ネットワーク・アドレス・ホッピング方式に基づく、請求項107記載のコンピュータ可読記憶媒体。
- 114仮想専用接続を形成するのに用いられるデータが、サーバ・コンピュータとクライアント・コンピュータとの間で送信される、各データの修正された情報パケット内の値を、妥当な値の移動ウィンドウと比較することに基づく、請求項107記載のコンピュータ可読記憶媒体。
- 115仮想専用接続を形成するのに用いられるデータが、修正された各情報パケットのヘッダ内のディスクリミネータ・フィールドを、サーバ・コンピュータ用に維持されている妥当なディスクリミネータ・フィールドのテーブルと比較することに基づく、請求項107記載のコンピュータ可読記憶媒体。
- 116コンピュータ・ネットワークがインターネットを含む、請求項107記載のコンピュータ可読記憶媒体。
Independent claims116
258 paragraphs, as filed
<u style="single">Cross-reference of related applications</u> This application is a partial continuation patent application of U.S. Patent Application No. 09 / 504,783, which was filed on February 15, 2000, and U.S. Patent Application No. 09 / 504,783 was filed on October 29, 1999. Claims the priority of the filed US Patent Application No. 09 / 4,29,643 filed in, and is a partial continuation patent application of this application. The subject matter of U.S. Patent Application No. 09 / 4,29,643, which is incorporated herein by reference, is U.S. Patent Application No. 60 / 106,261 (filed October 30, 1998) and No. 60 / 137,704 (June 1999). 7th application). This application also relates to US Patent Application No. 09 / 558,210 (Patent Attorney Case Registration No. 479.86839), filed April 26, 2000 and incorporated herein by reference.
<u style="single">Background of the invention</u> A wide variety of methods have been proposed and implemented to ensure the security and anonymity of communications over the Internet. This variety is due in part to the different needs of different Internet users. Figure 1 shows the basic heuristic structure that helps discuss these various security techniques. The two terminals, that is, the source terminal 100 and the destination terminal 110, communicate with each other via the Internet. It is desirable that the communication be secure, that is, the communication is not eavesdropped. For example, terminal 100 may send confidential information to terminal 110 via the Internet 107. It may also be desirable for the listener to be unaware that the terminal 100 is communicating with the terminal 110. For example, if terminal 100 is a user and terminal 110 operates a website, then the user of terminal 100 knows who in the network is "accessing" which website. You may not want to be. So, for example, wanting to keep the subject of their market research private, and thus preventing outsiders from knowing which of the websites or other Internet resources they are "accessing". Anonymity is important for companies that want to. These two security issues can be called data security and anonymity, respectively.
Data security is usually addressed using some form of data encryption. The encryption key 48 is known on both the source terminals 100 and 110. This key may be a private key and a public key on the source terminal 100 and the destination terminal 110, respectively, or a symmetric key (the same key is used by both parties for encryption and decryption). Many encryption methods are known and can be used in this case.
To hide traffic from local administrators or ISPs, users can use local epoxies when communicating with external epoxies through encrypted channels so that this local administrator or ISP sees only encrypted traffic. You can use the server. The proxy server prevents the called server from determining the identity of the calling client. This system uses an intermediate server that intervenes between the client and the destination server. The called server only looks at the Internet Protocol (IP) address of the proxy server, not the calling client. The target server only sees the address of the external proxy. This method relies on a trusted external proxy server. In addition, the proxy method is easily affected by the traffic analysis method for determining the IDs of the sender and the receiver. Another important limitation of proxy servers is that the server knows the identities of both the caller and the called party. In many cases, the source terminal, such as terminal A, wants to hide the terminal's ID from the proxy if a proxy server is provided by the Internet service provider (ISP).
To disable traffic analysis, a method called Chaum's mix uses a proxy server that sends and receives fixed-length messages, including dummy messages. Multiple source terminals are connected to multiple target servers through a mix (server). It is difficult to determine which source terminal is communicating with which of the connected target servers, and a dummy message allows the listener to detect the communication pair by analyzing the traffic. Becomes difficult. The disadvantage of this method is that the mix server can be breached. One way to deal with this danger is to distribute responsibility across multiple mixes. That is, even if one mix is broken, the IDs of the source terminal and the target terminal can be kept hidden. This method requires some alternative mixes so that the intermediate server between the source terminal and the target terminal cannot be determined unless a plurality of mixes are compromised. In this method, the message is covered with multiple encrypted address layers. The first mix in the sequence can only decode the outer layer of the message to know the next destination mix in the sequence. The second mix decodes this message to find out the next mix, and so on. The target server receives the message and optionally receives a multilayer encrypted payload containing return information to send back the data as well. The only way to disable such a mix scheme is to collusion the mix. If all the packets are fixed length and the packets are mixed with dummy packets, then any kind of traffic analysis is not possible.
Another anonymity technique called "cloud" is a technique that protects the identity of the source terminal from intermediate proxies by making the source terminal belong to a proxy group called the cloud. The cloud proxy intervenes between the source terminal and the target terminal. Each proxy through which the message passes is randomly selected by the upstream proxy. Each intermediate proxy can send a message to another randomly selected proxy or destination in the "cloud". Therefore, even cloud members cannot determine if the originator of the message is the previous proxy or if the message was only forwarded from another proxy.
The ZKS (Zero Norridge System) Anonymous IP Protocol allows users to choose between five different anonymous ones, while desktop software encrypts outbound traffic and User Datagram Protocol (UDP) packets. Hidden inside. The first server in the 2+ -hop system gets the UDP packet, strips one encryption layer, adds another encryption layer, and then sends this traffic to the next server. This server removes yet another encryption layer and adds a new encryption layer. The user can control the number of hops. At the last server, traffic is decrypted with an untraceable IP address. This technique is called onion routing. This method can be disabled using traffic analysis. In a simple example, a burst of packets from a user during a low duty period may reveal the sender and receiver identities.
Firewalls attempt to protect the LAN from unauthorized access, malicious use of computers connected to the LAN, or damage to such computers. A firewall is a centralized system that needs to maintain an administrative overhead. Firewalls can be broken by virtual machine applications (applets). Such applications cause a security breach, for example by sending sensitive information to a server outside the firewall or recommending that a modem be used to bypass firewall security. Infiltrate. Firewalls are not useful for distributed systems such as business travelers, extranets, and small teams.
<u style="single">Outline of the invention</u> Security mechanisms that communicate over the Internet, including a protocol called the Tunnel Azil Routing Protocol (TARP), use a unique two-layer cryptographic format and a specialized TARP router. TARP routers are similar in function to legitimate IP routers. Each TARP router has one or more addresses and uses the usual IP protocols to send IP packet messages (packets or datagrams). An IP packet exchanged between TARP terminals via a TARP router is an actually encrypted packet in which the true destination address is hidden except for the TARP router and server. TARP A regular IP header or "plain" or "external" IP header attached to an IP packet contains only the address of the next hop router or destination server. That is, the IP header of a TARP packet does not always indicate the last destination in the destination field of the IP header, but always points to the next or last destination in a set of TARP router hops. This means that the intercepted TARP packet has no clear indication of the true destination of the TARP packet, since the destination is always the next hop TARP router and the final destination.
The true destination of each TARP packet is hidden in the encryption layer generated using the link key. The link key is an encryption key used for encrypted communication between hops intervening between the source TARP terminal and the destination TARP terminal. Each TARP router can remove the encryption outer layer to know the destination router of each TARP packet. The receiving TARP or routing terminal identifies the sending terminal by the sender / receiver IP number in the plaintext IP header to identify the link key required to decrypt the encrypted outer layer of the TARP packet. be able to.
After the encrypted outer layer is removed, the TARP router determines the final destination. Each TARP packet 140 receives a minimum number of hops to help disable traffic analysis. Hops can be randomly selected or can be of constant value. As a result, each TARP packet can randomly move between several geographically distinct routers before arriving at the destination. Since each move is independently and randomly determined, it is very likely that it will be different for each packet that makes up a given message. This function is called azil routing. The various packets take different routes, making it difficult for an intruder to get all the packets that make up the entire multi-packet message. The advantage associated with this is the advantage related to the encryption inner layer described later. Azil routing is combined with other features that facilitate this purpose: allowing any message to be split into multiple packets.
The IP address of the TARP router can be changed, and this function is called IP agility. Each TARP router may change its IP address independently or under the direction of another TARP terminal or TARP router. Another modifiable identifier or address is also defined. This address, called the TARP address, is known only to TARP routers and TARP terminals and can be correlated at any time by the TARP router or TARP terminal using a look-up table (LUT). When the TARP router or TARP terminal changes its IP address, it updates other TARP routers or TARP terminals, and these TARP routers or TARP terminals update their respective LUTs.
The message payload is hidden in the encrypted inner layer in the TARP packet, which cannot be unlocked without using the session key. The session key is a key that cannot be used by any of the intervening TARP routers. The session key is used to decrypt the payload of the TARP packet and allow the data stream to be reconstructed.
The link key and session key can be used to keep the communication private, and the link key and session key can be shared and used according to any desired method. For example, you can use a public / private key or a symmetric key.
When transmitting a data stream, the TARP source terminal composes a series of TARP packets from a series of IP packets generated by a network (IP) layer process. (Note that the "network layer," "data link layer," "application layer," etc. used herein correspond to open system interconnect (OSI) network terminology.) The payload is assembled as blocks and chain blocks encrypted using the session key. Of course, in this case, it is assumed that all IP packets are destined for the same TARP terminal. This block is then interleaved, and the interleaved encrypted block is split into a set of payloads for each TARP packet to be generated. Then, using the IP header obtained from the data stream packet, a special TARP header IP for each payload<sub>r</sub>Is added. The TARP header can be the same as a regular IP header or can be customized in some way. The TARP header is a method or data for deinterleaving the data on the destination TARP terminal, a time-to-lib (TTL) parameter indicating the number of hops to perform, whether the payload contains, for example, TCP data or UDP. Data type identifier indicating whether the data is included, the sender's TARP address, the destination TARP address, an indicator of whether the packet contains actual data or decoy data, or the decoy data is TARP payload data. It should include a method of removing decoy data when disseminated in some way through.
Although chain block ciphers are discussed herein for session keys, it should be noted that any encryption method can be used. Preferably, as with chain block ciphers, methods should be used that make unauthorized decryption difficult unless the entire result of the encryption process is obtained. Therefore, separating the encrypted block between multiple packets and making it difficult for an intruder to access all such packets gives the content of the communication a special layer of security.
Decoy data or dummy data can be added to the stream to help disable traffic analysis by reducing the peak-to-average network load. More decoys during low traffic periods in response to time or other criteria so that a communication burst at one point in the Internet can be combined with a communication burst at another point to make the communication endpoint invisible. -It is desirable to give the TARP process the ability to generate data.
Dummy data allows the data to be split into more unobtrusive sized packets to increase the size of the interleaved window, while at the same time helping to maintain a reasonable size for each packet. (The packet size can be a single standard size, or you can choose from a range of sizes.) One main reason why it is desirable to split each message into multiple packets is before interleaving. This is apparent when the first layer of encryption is formed using a chain block cipher. A single block cipher can be applied to part or all of the message, and then that part or whole can be interleaved to obtain several separate packets. Given the difficulty of argill IP routing of packets and the associated restructuring of the entire sequence of packets to form a single block-encrypted message element, decoy packets are data streams. It turns out that it significantly increases the difficulty of reconstructing the whole.
The above scheme can be fully implemented by the process of operating between the data link layer and the network layer of each server or terminal participating in the TARP system. Since the above-mentioned encryption system can be inserted between the data link layer and the network layer, the process used to support encrypted communication is the process above the IP (network) layer. On the other hand, it may be completely transparent. The TARP process may also be completely transparent to the data link layer process. Therefore, neither the operation above the network layer nor the operation below the data link layer is affected by inserting the TARP stack. This greatly increases the difficulty of unauthorized access to the network layer (for example, by hackers), thus providing additional security for all processes above the network layer. Even for newly developed servers running at the session layer, all processes below the session layer can be compromised. Note that this structure distributes security. That is, for example, a notebook computer used by a mobile manager can communicate over the Internet without compromising security.
IP address changes by TARP terminals and TARP routers can be done at regular or random intervals, or when an "attack" is detected. Changing the IP address suppresses traffic analysis, which allows you to know which computer is communicating, and provides some protection against attacks. The degree of protection against attacks is approximately proportional to the rate at which the host's IP address changes.
As mentioned above, the IP address can be changed in response to an attack. For example, an attack can be known by a series of messages that were organized by the router to indicate that it was being investigated in some way. When an attack is detected, the TARP layer process can respond to this event by changing its IP address. The TARP layer process can also create sub-processes that maintain the initial IP address and in some way continue to interact with the attacker.
Decoy packets can be generated by each TARP terminal according to certain criteria determined by the algorithm. For example, the algorithm may be a random algorithm that requires random packets to be generated when the terminal is idle. Alternatively, the algorithm can generate more decoy packets at low traffic in response to detection of time or low traffic. Note that packets are preferably generated as a group of sizes that simulate the actual message, rather than being generated one at a time. Also, the background loop may have a latch that increases the likelihood of inserting a decoy packet when the message stream is being received so that the decoy packet can be inserted into a regular TARP message stream. it can. Alternatively, if a large number of decoy packets are received along with legitimate TARP packets, the algorithm can increase the rate at which these decoy packets are removed rather than forwarded. When decoy packets are removed and generated in this way, the apparent incoming message size is different from the apparent outgoing message size, and traffic analysis can be disabled.
In various other aspects of the invention, it is possible to configure a scalable version of the system in which multiple IP addresses are pre-assigned to each communication node pair in the network. Each node pair agrees on an algorithm for "hopping" between IP addresses (both sender and receiver), so the listener is apparently non-contiguous in packets transmitted between communication node pairs. View the IP address of the act. Duplicate IP addresses or "reusable" IPs for several different users on the same subnet, as each node only verifies that it contains a valid source / destination pair according to the agreed algorithm. Addresses can be assigned. Preferably, the source / destination pair is reused between two nodes during a given end-to-end session unless the IP block size is limited or the session is long. There is nothing to do.
Further improvements described in this partial continuation application include (1) a load balancer that distributes packets across different transmission paths depending on the quality of the transmission path, and (2) virtual in response to domain name queries. DNS proxy server that transparently forms a dedicated network, (3) Large and small link bandwidth management function to prevent denial of service attacks (attacks) at system checkpoints, (4) Synchronize sender and receiver A traffic limiter that regulates incoming packets by limiting the speed at which it can, and (5) signaling that allows multiple nodes to communicate with the central node by splitting the communication function between two separate entities. -Includes a synchronizer.
The present invention provides a basic technique for implementing a secure virtual Internet by using a new Azil network protocol built on the existing Internet Protocol (IP). This secure virtual Internet works on the existing Internet structure infrastructure and interfaces with client applications in the same way as the existing Internet. The basic technologies provided by the present invention that support this secure virtual Internet are "one-click" and "no-click" technologies that are part of the secure virtual Internet, and the secure domain name service (SDNS) for the secure virtual Internet. And includes new techniques for interconnecting secure virtual Internet with specific client applications. According to the present invention, the secure domain name service not only realizes a method of registering a domain name and an address and providing a service to the domain name and address, but also interfaces with an existing application.
According to one aspect of the invention, the user conveniently does not have to enter user identification information, a password, and / or an encryption key to establish a VPN, "one click", "no". A VPN can be established using "click" technology. The advantages of the present invention come from a method of establishing a secure communication link between a first computer and a second computer on a computer network such as the Internet. In one aspect, the secure communication mode is preferably by simply selecting an icon displayed on the first computer, without the user entering encryption information for establishing the secure communication mode of communication. Made available on the first computer. Alternatively, the secure communication mode of communication can be enabled by entering a command on the first computer. A secure communication link is then established between the first computer and the second computer on the computer network based on the secure communication mode of the enabled communication. According to the present invention, it is determined whether or not the secure communication software module is stored in the first computer in response to the step of establishing the secure communication mode of communication. Then, when this software module is not stored on the first computer, the predetermined computer network address is accessed and the secure communication software module is loaded. The proxy software module is then stored on the first computer. A secure communication link is a virtual dedicated network communication link on a computer network. Preferably, the virtual-only network may be based on inserting one or more data values, which vary according to the pseudo-random sequence, into each data packet. Alternatively, the virtual-only network allows the second computer to compare the data values in each data packet with the moving window of reasonable values sent between the first computer and the second computer. , A computer network address hopping method used to pseudo-randomly change a computer network address or other data value in a packet sent between a first computer and a second computer. May be based on. Yet another option provides a virtual-only network based on a comparison of the discriminator fields in each data packet with a table of reasonable discriminator fields maintained for the first computer. To.
According to another aspect of the invention, commands are entered that define the setup parameters associated with the secure communication link mode of communication. Therefore, the secure communication mode is automatically established when a communication link is established on the computer network.
The present invention also provides a computer system having a display showing a communication link with a computer network and a hyperlink establishing a virtual dedicated network through the computer network. Establishing a virtual-only network Choosing a hyperlink establishes a virtual-only network on your computer network. A non-standard top-level domain name is then transmitted over virtual-only network communication to a given computer network address, such as a computer network address for secure domain name services (SDNS).
The present invention provides a domain name service that provides a secure computer network address for a secure non-standard top-level domain name. The advantages of the present invention are provided by a portal connected to a computer network such as the Internet, and a secure domain name service for computer networks including a domain name database connected to the computer network through the portal. According to the present invention, the portal authenticates queries regarding secure computer network addresses, and the domain name database stores secure computer network addresses for computer networks. Each secure computer network address is an address based on a non-standard top-level domain name such as .scom, .sorg, .snet, .snet, .sedu, .smil, and .sint.
The present invention provides a method of encapsulating existing application network traffic at the application layer of a client computer so that the client application can securely communicate with a server protected by the Azil network protocol. To do. The advantages of the present invention are provided by a method of communicating over a computer network such as the Internet using a dedicated communication link between a client computer and a server computer. According to the present invention, information packets are transmitted from a client computer to a server computer on a computer network. The information packet contains data that is inserted into the packet payload at the application layer of the client computer and is used to form a virtual dedicated connection between the client computer and the server computer. The modified information packet can be sent through a firewall before being sent to the server computer on the computer network, and the invention acts on existing protocols (ie UDP, ICMP, and TCP). Makes it easier to penetrate the firewall. Information packets are received at the kernel layer of the server-side operating system. The kernel layer of the operating system on the host computer then determines whether the information packet contains the data used to form a virtual-only connection. The server side responds by sending an information packet modified at the kernel layer to the client computer so that the payload portion of the response information packet contains the virtual dedicated connection information. Preferably, the information packet from the client computer and the response information packet from the server side are UDP protocol information packets, respectively. Alternatively, both of the two information packets may be TCP / IP information packets or ICMP protocol information packets.
<figref num="1">It is a figure of the secure communication via the Internet by the aspect of the prior art.</figref><figref num="2">It is a figure of the secure communication via the Internet by the aspect of this invention.</figref><figref num="3A">It is a figure of the process of forming the tunneled IP packet by the aspect of this invention.</figref><figref num="3B">It is a figure of the process of forming a tunneled IP packet by another aspect of this invention.</figref><figref num="4">It is a figure of the OSI layer position of the process which can be used to carry out this invention.</figref><figref num="5">It is a flowchart which shows the process of routing a tunneled packet by this invention.</figref><figref num="6">It is a flowchart which shows the process of forming a tunneled packet according to the aspect of this invention.</figref><figref num="7">It is a flowchart which shows the process of receiving a tunneled packet according to the aspect of this invention.</figref><figref num="8">It is a diagram showing how to establish and synchronize a secure session between a client and a TARP router.</figref><figref num="9">The IP address hopping method between the client computer and the TARP router using the send and receive tables in each computer is shown.</figref><figref num="10">Shows physical link redundancy between three Internet Service Providers (ISPs) and client computers.</figref><figref num="11">Shows how to embed multiple IP packets in a single "frame", such as an Ethernet (registered trademark) frame, and how to use the discriminator field to hide the true packet receiver. Is further shown.</figref><figref num="12A">Indicates the system that uses the hopped hardware address, the hopped IP address, and the hopped discriminator field.</figref><figref num="12B">Here are several different techniques for hopping a combination of hardware address, IP address, and discriminator field.</figref><figref num="13">Demonstrates a technique for automatically reestablishing synchronization between the sender and receiver by using partially exposed synchronization values.</figref><figref num="14">Demonstrates a "checkpoint" method that restores synchronization between the sender and receiver.</figref><figref num="15">The details of the checkpoint method shown in FIG. 14 are shown.</figref><figref num="16">It shows how to decompose two addresses into multiple segments and compare them with the existence vector.</figref><figref num="17">Shows the storage array of active addresses on the receiving side.</figref><figref num="18">The storage array on the receiving side after receiving the synchronization request is shown.</figref><figref num="19">Shows the receiving storage array after the new address is generated.</figref><figref num="20">Shows a system that uses a distributed transmit path.</figref><figref num="21">Figure 20 shows multiple link transmission tables that can be used to route packets within the system.</figref><figref num="22A">A flowchart for adjusting the weight value distribution related to a plurality of transmission links is shown.</figref><figref num="22B">A flowchart for setting the weight value to zero when the sender is turned off is shown.</figref><figref num="23">A system using a distributed transmission path with an adjusted weight value distribution for each path is shown.</figref><figref num="24">An example of using the system of FIG. 23 is shown.</figref><figref num="25">Indicates a traditional domain name lookup service.</figref><figref num="26">Shows a system that uses a DNS proxy server that allows transparent VPN creation.</figref><figref num="27">The steps that can be taken to realize transparent VPN creation based on the DNS reference function are shown.</figref><figref num="28">Indicates a system with a link guard feature that prevents packets from being overloaded on the low bandwidth link LOW BW.</figref><figref num="29">An embodiment of a system using the principles of FIG. 28 is shown.</figref><figref num="30">Shown is a system that regulates packet transmission speed by slowing down the speed at which synchronization takes place.</figref><figref num="31">The signaling server 3101 and the transparent server 3102 used to establish a VPN with client computers are shown.</figref><figref num="32">The message flow related to the synchronization protocol shown in Fig. 31 is shown.</figref><figref num="33">It is a system block diagram of a computer network suitable for using the "one-click" communication link of the present invention.</figref><figref num="34">It is a flow chart at the time of installing and establishing a "one-click" secure communication link on a computer network according to the present invention.</figref><figref num="35">It is a flow chart at the time of registering the safety domain name by this invention.</figref><figref num="36">FIG. 5 is a system block diagram of a computer network in which the dedicated connection according to the invention can be configured to more easily cross a firewall between two computer networks.</figref><figref num="37">It is a flow chart when establishing a virtual private connection which is encapsulated by using an existing network protocol.</figref>
<u style="single">Detailed description of aspects</u> As can be seen in Figure 2, the security mechanism for communicating over the Internet is that each router has one or more IP addresses and uses regular IP protocols with TARP Packet 140. It uses some special routers or servers called TARP routers 122-127, which are similar to legitimate IP routers 128-132 in that they send IP packet messages similar to regular packets. .. The TARP packet 140 is identical to a regular IP packet message routed by legitimate IP routers 128-132, as each contains a destination address similar to a regular IP packet. But TARP packet 140 The IP header does not indicate the last destination in the destination field of the IP header, but always points to the next or last destination in a set of TARP router hops, namely the TARP terminal 110. Since the header of the TARP packet contains only the next hop destination, the destination is always the next hop TARP router and the last destination, i.e. the TARP terminal 110, so the intercepted TARP packet is the true of that TARP packet. There is no clear indication of the destination of the call.
The true destination of each TARP packet is hidden in the encrypted outer layer generated using the link key 146. The link key 146 is used for encrypted communication between the endpoint (TARP terminal or TARP router) of a single link in the chain of hops connecting the source TARP terminal 100 and the destination TARP terminal 110. It is an encryption key. Each TARP router 122-127 can know the true destination of the TARP packet using the link key 146 used to communicate with the previous hop in the chain. The receiving TARP or routing terminal can indicate the link key used by the sending field in the plaintext IP header to identify the link key needed to decrypt the encrypted outer layer of the TARP packet. ) The sending terminal can be identified. Alternatively, the ID can be hidden by another encryption layer in the available bits in the plaintext IP header. When each TARP router receives a TARP message, it determines whether the message is a TARP message by using the authentication data in the TARP packet. This can be recorded in the available bytes in the IP header of the TARP packet. Alternatively, the TARP packet can be authenticated by attempting decryption using the link key 146 and determining if the result is the expected result. This method has a computational advantage because it does not involve a decoding process.
After the decryption outer layer is completed by TARP routers 122 to 127, the TARP router determines the final destination. The system is preferably configured to allow each TARP packet 140 to undergo a minimum number of hops to help disable traffic analysis. A time-to-live counter in the IP header of a TARP message can be used to indicate the number of remaining TARP router hops to complete. Each TARP router then decrements this counter to determine whether the TARP packet 140 should be forwarded to the other TARP routers 122-127 or to the destination TARP terminal 110. When the time-to-live counter becomes zero or less after the decrement, as an example of use, the TARP router that has received the TARP packet 140 can transfer the TARP packet 140 to the destination TARP terminal 110. If the time-to-live counter exceeds zero after the decrement, as an example, the TARP router that received the TARP packet 140 will have this TARP terminal 122-127 randomly selected by this current TARP terminal. TARP packet 140 can be forwarded. As a result, each TARP packet 140 is routed through the minimum number of hops of randomly selected TARP routers 122-127.
Therefore, each TARP packet randomly travels between several geographically distinct routers before arriving at the destination, regardless of the traditional factors that determine traffic within the Internet. Since it is determined independently and randomly as described above, it is very likely that it will be different for each packet that makes up a given message. This function is called azil routing. For reasons that will soon become apparent, different packets take different paths, making it difficult for an intruder to get all the packets that make up the entire multi-packet message. Azil routing is combined with other features that facilitate this purpose: allowing any message to be split into multiple packets.
The TARP router has the IP address used by the TARP router as the IP header IP of the TARP packet.<sub>C</sub>Receive a TARP packet when it matches the IP address in. However, the IP address of the TARP router does not have to be constant. To avoid and manage attacks, each TARP router can change its IP address independently or under the direction of another TARP terminal or TARP router. Another modifiable identifier or address is also defined. This address, called the TARP address, is known only to TARP routers and TARP terminals and can be correlated at any time by the TARP router or TARP terminal using a look-up table (LUT). When the TARP router or TARP terminal changes its IP address, it updates other TARP routers or TARP terminals, and these TARP routers or TARP terminals update their respective LUTs. In fact, the TARP router must use the router's own LUT to translate the TARP address to the actual IP address whenever it references the destination address in the encrypted header.
Any TARP router that receives a TARP packet can determine the final destination of the packet, but the message payload is embedded in the encrypted inner layer inside the TARP packet that cannot be unlocked without the use of a session key. The TARP routers 122 to 127 intervening between the source TARP terminal 100 and the destination TARP terminal 110 cannot use the session key. The session key can be used to decrypt the payload of TARP packet 140 and reconstruct the entire message.
In one embodiment, the link key and session key can be used to keep the communication private, and the link key and session key can be shared and used according to any desired method. For example, public key method can be used to transfer a public or symmetric key between a link endpoint or a session endpoint. Any of a variety of other mechanisms that secure the data so that only authorized computers can access the private information in the TARP packet 140 can be used as needed.
As can be seen in FIG. 3a, when constructing a series of TARP packets, the data stream 300 such as IP packets 207a, 207b, 207c, that is, the series of packets formed by the network (IP) layer process, is a series. Divided into smaller segments. In this example, segments 1-9 of equal size are defined and used to form a set of interleaved data packets A, B, and C. In this case, assuming that the number of interleaved packets A, B, and C formed is three, the IP packets 207a to 207c used to form the three interleaved packets A, B, and C. Assume that the number is also three. Of course, the number of IP packets deployed in the group of interleaved packets can be any convenient number as well as the number of interleaved packets in which the incoming data stream is deployed. The number of interleaved packets in which the data stream is expanded is called the interleaved window.
When creating a packet, the sending software interleaves the regular IP packet 207a with subsequent packets to form a new set of interleaved payload data 320. This payload data 320 then forms a set of session key encrypted payload data 330 using the session key, where each data A, B, and C forms the payload of the TARP packet. Encrypted by. New TARP packet IP using the IP header data of the first packet 207a ~ 207c<sub>T</sub>Is formed. TARP packet IP<sub>T</sub>Can be the same as a regular IP header, or can be customized in some way. In a preferred embodiment, the TARP packet IPT is an IP header containing additional data that provides the following information necessary for routing and reconstructing messages. Some of this data is usually contained in a regular IP header, or can be included in a regular IP header. 1. Window sequence number-An identifier that indicates where the packet belongs in the first message sequence. 2. Interleaved Sequence Number-An identifier that indicates the interleaved sequence used to form a packet so that it can be deinterleaved with other packets in the interleaved window. 3. Time to Live (TTL) Data-Indicates the number of TARP router hops a packet should perform before it arrives at its destination. Note that the TTL parameter can provide data to be used in the probabilistic formula to determine whether a packet should be routed to a destination or another hop. 4. Data type identifier-Indicates whether the payload should contain, for example, TCP data or UDP data. 5. Sender Address-Indicates the sender's address in the TARP network. 6. Destination Address-Indicates the address of the destination terminal in the TARP network. 7. Decoy / Real-Indicator of whether the packet contains actual message data, dummy decoy data, or a combination.
Obviously, packets entering a single interleaved window must contain only packets with a common destination. Therefore, in the example shown, it is assumed that all IP headers of IP packets 207a-207c contain the same destination address or are received by at least the same terminal so that they can be deinterleaved. Note that dummy or decoy data or packets can be added to form an interleaved window that is otherwise required by a given message size. Adding decoy or dummy data to the stream to even out the load on the network can help disable traffic analysis. Therefore, more during low traffic periods in response to time or other criteria so that the communication burst at one point in the Internet can be combined with the communication burst at another point to make it impossible to know the communication endpoint. It is desirable to give the TARP process the ability to generate decoy data for.
Dummy data allows the data to be split into more unobtrusive sized packets to increase the size of the interleaved window, while at the same time helping to maintain a reasonable size for each packet. (The packet size can be a single standard size, or you can choose from a range of sizes.) One main reason why it is desirable to split each message into multiple packets is before interleaving. This is apparent when the first layer of encryption is formed using a chain block cipher. A single block cipher can be applied to part or all of the message, and then that part or whole can be interleaved to obtain several separate packets.
As can be seen with reference to FIG. 3b, in the alternative aspect of the TARP packet configuration, a series of IP packets are accumulated to form a predetermined interleaved window. A single block 520 for chain block ciphers is constructed using the payload of the packet and the session key. It is assumed that the payload used to form the block is destined for the same terminal. The block size can match the interleaved window shown in the example aspect of Figure 3b. After encryption, the encrypted block is split into separate payloads and segments, which are interleaved as in the aspect of Figure 3a. The resulting interleaved packets A, B, and C are then packaged as TARP packets with TARP headers, as in the example in Figure 3a. The rest of the process is shown in Figure 3a and is as discussed with reference to Figure 3a.
After the TARP packet 340 is formed, the TARP header IP<sub>T</sub>The entire TARP packet 340, including, is encrypted using the link key to communicate with the first hop TARP router. The first hop TARP router is randomly selected. The final unencrypted IP header IPC is added to each encrypted TARP packet 240 to form a regular IP packet 360 that can be sent to the TARP router. Note that the process of configuring TARP packet 360 does not need to be step-by-step as described above. The above description is only a useful heuristic for describing the final product, the TARP packet.
Note that the TARP packet IPT can have a complete custom header configuration that is quite different from the regular IP header, except that it contains the information identified above. This is because this header is only interpreted by the TARP router.
The above method can be fully implemented by the process of operating between the data link layer and the network layer of each server or terminal participating in the TARP system. As can be seen with reference to FIG. 4, the TARP transceiver 405 may be a source terminal 100, a destination terminal 110, or TARP routers 122 to 127. At each TARP transceiver 405, a sender process is generated that receives regular packets from the network (IP) layer and produces TARP packets that can be transmitted over the network. A receiver process is generated that receives a regular IP packet, including a TARP packet, and produces a regular IP packet that is "passed" to the network (IP) layer. If the TARP transceiver 405 is a router, the received TARP packet 140 is authenticated as a suitable TARP packet and then only passed to another TARP router or TARP destination terminal 110 as a stream of IP packet 415. Note that it is not processed. The process of intervention, the "TARP layer" 420, can be combined with the data link layer 430 or network layer 410. In either case, this process intervenes in data link layer 430 to receive legitimate IP packets, including embedded TARP packets, and "pass" a series of reassembled IP packets to network layer 410. .. As an example of combining TARP layer 420 with data link layer 430, a program can extend the normal process of executing a communication card, such as an Ethernet® card. Alternatively, the TARP layer process can form a part of a dynamically loadable module that is loaded and performed to support communication between the network layer and the data link layer.
Since the above-mentioned encryption system can be inserted between the data link layer and the network layer, the process used to support encrypted communication is the process above the IP (network) layer. On the other hand, it may be completely transparent. The TARP process may also be completely transparent to the data link layer. Therefore, neither the operation above the network layer nor the operation below the data link layer is affected by inserting the TARP stack. This greatly increases the difficulty of unauthorized access to the network layer (for example, by hackers), thus providing additional security for all processes above the network layer. Even for newly developed servers running at the session layer, all processes below the session layer can be compromised. Note that this structure distributes security. That is, for example, a notebook computer used by a mobile manager can communicate over the Internet without compromising security.
Note that IP address changes by TARP terminals and TARP routers can be done at regular or random intervals, or when an "attack" is detected. Changing the IP address suppresses traffic analysis, which allows you to know which computer is communicating, and provides some protection against attacks. The degree of protection against attacks is approximately proportional to the rate at which the host's IP address changes.
As mentioned above, the IP address can be changed in response to an attack. For example, an attack can be known by a series of messages that were organized by the router to indicate that it was being investigated in some way. When an attack is detected, the TARP layer process can respond to this event by changing its IP address. To do this, the TARP process constructs a TARP-formatted message, for example, in the form of Internet Control Message Protocol (ICMP) datagrams. This message contains the TARP address of the machine, the previous IP address of the machine, and the new IP address of the machine. The TARP layer sends this packet to at least one known TARP router, which receives the message, validates it, and then LUTs the router itself with the new IP address of the TARP address mentioned above. Update. The TARP router then creates a similar message and broadcasts this message to those TARP routers so that other TARP routers can update the LUT. This update process should be relatively fast, as the total number of TARP routers on a given subnet is expected to be relatively small. However, this process may not work well with a relatively small number of TARP routers and / or a relatively large number of clients. For this reason, this structure has been modified to provide scaling. This improvement yielded the second aspect described below.
The TARP process can also create sub-processes that maintain the initial IP address when an attack is detected and continue to interact with the attacker. This dialogue gives you the opportunity to track down the attacker or study the attacker's method (inside the fishbowl, which "thinks" of the fishbowl as the sea, but is actually caught and observed. It's called "fish bowling", likened to a small fish in the sea). The history of communications between the attacker and the abandoned (fish-bowled) IP address can be recorded or transmitted for human analysis, or further synthesized to respond in some way.
As mentioned above, the TARP terminal or TARP router can add decoys or dummy data or packets to the outgoing data. Such decoy packets not only conveniently distribute the data into more separate packets, but also even out the additions on the inactive part of the Internet to help nullify traffic analysis attempts. You can also.
Decoy packets can be generated by each TARP terminal 100, 110 or each router 122-127 according to certain criteria determined by the algorithm. For example, the algorithm may be a random algorithm that requires random packets to be generated when the terminal is idle. Alternatively, the algorithm can generate more decoy packets at low traffic in response to detection of time or low traffic. Note that packets are preferably generated as a group of sizes that simulate the actual message, rather than being generated one at a time. Also, the background loop may have a latch that increases the likelihood of inserting a decoy packet when the message stream is being received so that the decoy packet can be inserted into a regular TARP message stream. it can. That is, when a series of messages are received, the decoy packet generation rate can be increased. Alternatively, if a large number of decoy packets are received along with legitimate TARP packets, the algorithm can increase the rate at which these decoy packets are removed rather than forwarded. When decoy packets are removed and generated in this way, the apparent incoming message size is different from the apparent outgoing message size, and traffic analysis can be disabled. Whether it is a decoy packet or another packet, the packet reception rate can be shown to the decoy packet removal process and the decoy packet generation process through the perishable decoy legitimate packet counter. (Perishable counters respond to time to contain large values when rapidly and continuously incremented, and small values when incremented slowly or rapidly and continuously a small number of times. It is a counter that resets or decrements the value.) The destination TARP terminal 110 simply routes the packet.
As can be seen in FIG. 5, the following specific steps can be used in the above-mentioned method of routing TARP packets.
-A background loop operation that applies the algorithm that determines the generation of S0 decoy IP packets is executed. This loop is interrupted when an encrypted TARP packet is received. -S2 TARP packets can be inspected and authenticated in some way before attempting to decrypt them using the link key. That is, the router can ensure that the packet is a genuine TARP packet by performing the selected action on some data contained with the plaintext IP header attached to the encrypted TARP packet contained in the payload. Can be determined. This makes it possible to avoid performing decryption on packets that are not genuine TARP packets. The S3 TARP packet is decrypted, revealing the destination TARP address and whether this packet is a decoy packet or part of the actual message. S4 If this packet is a decoy packet, the perishable decoy counter is incremented. S5 The router can choose to discard the packet if it is a decoy packet, based on the decoy generation / removal algorithm and the perishable decoy counter value. If the received packet is a decoy packet and it is determined that it should be discarded (S6), control returns to step S0. -The TTL parameter of the S7 TARP header is decremented to determine if the TTL parameter is greater than zero. If the S8 TTL parameter is greater than zero, a TARP address is randomly selected from the list of TARP addresses maintained by the router, and the link key and IP address corresponding to this TARP address is the new one containing this TARP packet. It is stored so that it can be used when creating an IP packet. If the S9 TTL parameter is less than or equal to zero, the link key and IP address corresponding to the destination TARP address is stored for use when creating a new IP packet containing this TARP packet. -S10 TARP packet is encrypted using the stored link key. S11 An IP header is added to the packet containing the stored IP address, the encrypted TARP packet is covered with the IP header, and the completed packet is sent to the next hop or destination.
As can be seen with reference to FIG. 6, the following specific steps can be used in the above method of generating TARP packets.
-S20 background loop operation applies an algorithm that determines the generation of decoy IP packets. This loop is interrupted when a data stream containing IP packets is received for later transmission. -S21 Received IP packets are grouped as a set of messages having a fixed IP destination address. This set is further divided to match the maximum size of the interleaved window. The set is encrypted and interleaved to give a set of payloads that will be TARP packets. -The TARP address corresponding to the S22 IP address is determined from the reference table and stored to generate the TARP header. The initial TTL count is generated and stored in the header. The TTL count can be a random value with a minimum and maximum value, a constant value, or can be determined by some other parameter. The S23 window sequence number and interleaved sequence are recorded in the TARP header of each packet. S24 One TARP router address is randomly selected for each TARP packet and the IP address corresponding to this address is stored for use in the plaintext IP header. The link key corresponding to this router is identified, and TARP packets containing interleaved and encrypted data and TARP headers are encrypted using this link key. S25 A plaintext IP header with the actual IP address of the first hop router is generated and attached to each of the encrypted TARP packets and the resulting packet.
As can be seen with reference to FIG. 7, the following specific steps can be used in the above-mentioned method of receiving TARP packets.
-A background loop operation that applies the algorithm that determines the generation of S40 decoy IP packets is executed. This loop is interrupted when an encrypted TARP packet is received. The S42 TARP packet is examined and authenticated before it is decrypted using the link key. The S43 TARP packet is decrypted with the appropriate link key, revealing the destination TARP address and whether this packet is a decoy packet or part of the actual message. S44 If this packet is a decoy packet, the perishable decoy counter is incremented. The S45 receiver may choose to discard the packet, if it is a decoy packet, based on the decoy generation / removal algorithm and the perishable decoy counter value. S46 TARP packets are cached until all packets that form an interleaved window have been received. -S47 Packets are deinterleaved after all packets in the interleave window have been received. S48 The packet block of each combined packet that forms the interleaved window is then decrypted using the session key. · S49 Then the decrypted block is split using window sequence data and IP<sub>r</sub>IP with normal header<sub>C</sub>It is changed to the header. Window sequence number is IP<sub>C</sub>Included in the header. -S50 Then the packet is passed to the IP layer process.
<u style="single">1. Increased scaling potential</u> The IP agility feature described above depends on the ability to send IP address changes to all TARP routers. Each aspect that includes this feature is referred to as a "boutique" aspect because of the potential limitations in scaling such features for large networks such as the Internet. (But the boutique aspect is robust when used on a small network, for example a small virtual private network). One problem with the boutique aspect is that if IP address changes occur frequently, the number of TARP routers and / or clients is very high due to the message traffic needed to update all routers fast enough. If the number increases, the Internet will be heavily loaded. The bandwidth load used to update all TARP routers, for example the bandwidth load applied to the network in ICMP packets, exceeds the capacity of the Internet for large implementations close to the scale of the Internet. there is a possibility. In other words, the scaling potential of boutique systems is limited.
A system can be configured that trades some of the features of the above embodiments to provide the benefits of IP agility without additional message load. This is done by IP address hopping according to a shared algorithm that manages IP addresses used between links participating in communication sessions between nodes, such as TARP nodes. (Note that the IP hopping technique can also be applied to boutique aspects.) The IP agility features discussed for boutique systems are distributed under this scalable method and managed by the shared algorithm described above. Can be modified as follows. Other features of the boutique system can be combined with this new kind of IP agility r.
This new aspect has the advantage of providing local algorithms exchanged by each pair of nodes communicating and IP agility managed by a set of IP addresses. This local management is session independent in that it can manage communication between node pairs, regardless of the session or endpoint transferred between the node pairs that communicate directly.
In this scalable aspect, a block of IP addresses is assigned to each node in the network. (This scaling potential increases in the future when Internet Protocol addresses increase to 128-bit fields and the number of clearly addressable nodes increases significantly). Therefore, each node can communicate with other nodes in the network using any of the IP addresses assigned to that node. In practice, each node pair that communicates can communicate with each other using multiple source and destination IP addresses.
Each communicating node pair in the chain participating in any session has two IP address blocks called net blocks, an algorithm, and the next source / source used to send the next message. Stores a randomized seed for selecting a destination IP address pair for each net block. In other words, this algorithm manages the sequential selection of IP address pairs from each netblock, one sender IP address, and one receiver IP address. The combination of algorithm, seed, and net block (IP address block) is called "hop block". The router issues separate send and receive hop blocks to the router's clients. The transmit and receive addresses in the IP header of each outgoing packet sent by the client are filled with the transmit and receive IP addresses managed by the algorithm. The algorithm is "clocked" (indexed) by the counter each time a pair is used so that the algorithm creates a new transmit pair for the next packet to be transmitted.
The router's receive hop block is the same as the client's send hop block. The router uses the receive hop block to predict what the outbound IP address / inbound IP address pair will be for the next expected packet from this client. Since each packet may not be received in order, it is not possible for the router to reliably predict what IP address will come on the next sequential packet. The router takes this issue into account and produces a range of predictions that include the number of outgoing packet sending / receiving addresses that may follow the next packet received. Therefore, if a given packet is very unlikely to arrive at the router before the five packets previously sent by the client, the router should compare to the next packet received. Six transmit / receive IP address pairs (or "hop windows") can be generated. When a packet is received, it is marked in the hop window as received, so a second packet with the same IP address pair is dropped. If an out-of-sequence packet does not arrive within a given timeout period, it may be required to be retransmitted, or simply received, depending on the protocol used for the communication session and, in some cases, by convention. Can be discarded from the table.
When the router receives the client's packet, it compares the packet's outgoing and incoming IP addresses with the next N expected outgoing IP address receiving address pairs, and if the packet is not a member of this set, Reject the packet. Incoming packets that do not have the expected source / destination IP address that fits in the window are rejected, thus blocking possible hackers. (With the number of possible combinations, it is difficult to randomly fit a fairly large window into it.) If the packet is a member of this set, the router accepts the packet and further processes it. To do. This link-based IP hopping scheme, called "IHOP", is a network element that is independent and does not necessarily involve the elements of the boutique system described above. When the routing agility feature described for the boutique aspect is combined with this link-based IP hopping scheme, the next step in the router is to decrypt the TARP header to determine the destination TARP router for the packet, and the next step in the packet. It is to determine what the hop should be. The TARP router then forwards the packet to a random TARP router or to the destination TARP router where the destination router establishes link-based IP hopping communication.
Figure 8 shows how client computer 801 and TARP router 811 should establish a secure session. Client 801 sends a "safe synchronization" request ("SSYN") packet 821 to TARP router 811 when establishing a HOP session with TARP router 811. This SYN packet 821 contains the authentication token of client 811 and can be sent to router 811 in encrypted format. The destination and destination IP numbers on packet 821 are the current static IP address of client 801 and the "known" static IP address of router 811. (For security reasons, it is desirable to reject any packet from outside the local network whose destination is a known static IP address of the router.) Router 811 receives SSYN packet 821 of client 801 and receives SSYN packet 821 of client 801. After verifying the validity, it responds by sending an encrypted "safe synchronization acknowledgment" ("SSYN ACK") 822 to the client 801. This SSYN The ACK822 includes a transmit hop block and a receive hop block that the client 801 uses when communicating with the TARP router 811. Client 801 acknowledges and responds with response packet 822 of TARP router 811 by generating an encrypted SSYN ACK ACK packet 823 sent from that static IP address to a known fixed IP address of TARP router 811. Client 801 simultaneously generates SSYN ACK ACK packets. This SSYN ACK packet, called the Safe Session Initialization (SSI) packet 824, is in the client's transmit table 921 (Figure 9), which is specified in the transmit hop block given by the TARP router 811 in the SSYN ACK packet 822. Sent with the first {sender, receiver} IP pair. The TARP router 811 is an SSI transmitted with the first {sender, receiver} IP pair in the TARP router's transmit table 923. Respond to SSI packet 824 with ACK packet 825. After these packets are successfully exchanged, a secure communication session is established and all other secure communications between the client 801 and the TARP router 811 will continue this secure session as long as synchronization is maintained. It is done through. If synchronization is lost, the client 801 and TARP router 802 can reestablish a secure session by the procedure outlined in Figure 8 and described above.
When a secure session is active, both client 901 and TARP router 911 (Figure 9) maintain the transmit tables 921, 923 and receive tables 922, 924 given by the TARP router during session synchronization 822, respectively. It is important that the sequence of IP pairs in the client send table 921 is the same as the sequence of IP pairs in the TARP router receive table 924. Similarly, the sequence of IP pairs in the client receive table 922 must be the same as the sequence of IP pairs in the router send table 923. This is necessary to maintain session synchronization. Client 701 needs to maintain only one outbound table 921 and one inbound table 922 during a secure session. Each sequential packet sent by client 901 uses the next {sender, receiver} IP address pair in the transmit table, whether it is a TCP session or a UDP session. The TARP router 911 expects that each packet arriving from client 911 holds the next IP address shown in the receive table.
However, packets may not arrive in order, so the router can maintain a "look ahead" buffer in the receive table, making IP pairs that have already been received as invalid IP pairs for future packets. Mark. Future packets that are in the IP look ahead buffer but contain IP pairs that are marked as received IP pairs are dropped. Communication from TARP router 911 to client 901 is maintained as well. In particular, Router 911 selects the next IP address pair from Router 911's transmit table 923 when configuring a packet to send to Client 901, and Client 901 chooses the expected IP on the packet it receives. Maintain a pair of look-ahead buffers. Each TARP router maintains a separate transmit table / receive table pair for each client that has a secure session with the TARP router or has a secure session through the TARP router.
The client receives the client's hop block that links it to the Internet from the first server, while the router exchanges the hop block. When a router establishes a link-based IP hopping communication method with other routers, each pair exchange router exchanges its transmit hop block. The transmit hop block of each router becomes the receive hop block of the other router. Communication between routers is managed as described in the example where the client sends a packet to the first router.
The above method works well in an IP environment, but many local networks connected to the Internet are Ethernet® systems. Ethernet must use known processes (Address Decomposition Protocol and Reverse Address Decomposition Protocol) to translate the IP address of the called device into a hardware address and vice versa. The same is true. However, when using the link-based IP hopping method, the correlation process becomes cumbersome. An alternative to the link-based IP hopping method can be used within an Ethernet® network. In this solution, a node that links the Internet to Ethernet® (called a border node) can communicate with nodes outside the Ethernet® LAN using a link-based IP hopping method. YoTo do it. Within an Ethernet® LAN, each TARP node has a single IP address that is traditionally addressed. The TARP node in the LAN uses a single IP header extension field to authenticate the packet, rather than comparing the {sender, receiver} IP address pairs to authenticate the packet. Therefore, the border node uses the algorithm shared by the TARP node in the LAN to generate the symbol stored in the empty field in the IP header, and the TARP node in the LAN is from this particular source IP address. Generates a range of symbols based on the node's own expectations for the next packet expected to be received. A packet is rejected if it does not fit within the expected set of symbols (for example, a number) and accepted if it fits. Communication from the TARP node in the LAN to the border node is performed in the same way. However, for security reasons, the algorithms are necessarily different. Therefore, each communication node generates a transmission table and a reception table as in FIG. That is, the transmission table of the TARP node in the LAN is the same as the reception table of the border node, and the reception table of the TARP node in the LAN is the same as the transmission table of the border node.
The algorithm used for IP address hopping can be any desired algorithm. For example, the algorithm may be a pseudo-random number generator that generates numbers in a range that covers an allowed IP address with a given seed. Alternatively, session participants can assume certain algorithms and simply specify the parameters to apply them. For example, the hypothesized algorithm may be a particular pseudo-random number generator, where session participants can simply exchange seed values.
Note that there is no permanent physical difference between the source terminal node and the destination terminal node. Any device at any endpoint can initiate pair synchronization. Also note that authentication / synchronization requests (and acknowledgments) and hop block exchanges can all be performed by a single message so that separate message exchanges are not required.
As another extension of the structure described above, multiple physical paths can be used by the client to provide link redundancy and also prevent attempts to deny services and traffic monitoring. As shown in Figure 10, for example, client 1001 can establish three simultaneous sessions with each of the three TARP routers given by different ISPs 1011, 1012, 1013. As an example, client 1001 can connect to an ISP using three different telephone lines 1021, 1022, 1023, two telephone lines and a cable modem, and so on. In this method, the packets to be transmitted are randomly transmitted between various physical paths. This structure provides a high degree of communication redundancy and provides improved protection against denial of service attacks and traffic monitoring.
<u style="single">2. Other extensions</u> Various extensions of the techniques, systems, and methods described above will be described below. As mentioned above, the security of communications between computers within a computer network (Internet, Ethernet®, etc.) is the apparently random source of data packets transmitted over the network, the Internet. -It can be improved by using the protocol (IP) address and the destination IP address. This feature prevents the listener from determining which computer in the network is communicating, and at the same time, the given data packet received by the two communicating computers is a legitimate packet. Make it easy to recognize whether or not it is. In one aspect of the system described above, the IP header extension field is used to authenticate incoming packets over Ethernet®.
Various extensions of the aforementioned techniques described herein include (1) using the hopped hardware or "MAC" address in a broadcast network, and (2) having the computer synchronize with the sender. Self-synchronization techniques that allow automatic recovery, (3) synchronization algorithms that allow sender and receiver computers to quickly reestablish synchronization in the event of a packet loss event or other event, and (4) It includes a fast packet rejection mechanism that rejects invalid packets. Any or all of these extensions can be combined with the features described above in any of a variety of ways.
<u style="single">A. Hardware address hopping</u> Internet Protocol-based communication techniques on a LAN or Internet Protocol-based communication techniques over any dedicated physical medium typically embed IP packets within sub-packets, often referred to as "frames." As shown in FIG. 11, for example, the first Ethernet® frame 1150 comprises a frame header 1101 and two embedded IP packets IP1 and IP2, whereas a second Ethernet® ) · Frame 1160 has a different frame header 1104 and a single IP packet IP3. Each frame header generally contains source hardware address 1101A and destination hardware address 1101B. In FIG. 11, other known fields in the frame header are omitted for clarity. Two hardware nodes communicating over a physical communication channel insert appropriate source and destination hardware addresses that indicate which node on the channel or network should receive the frame.
A malicious listener can obtain information about the contents of a frame and / or the communicator of that frame by examining the frame on the local network (or in addition to it) rather than the IP packet itself. This is especially true for broadcast media such as Ethernet, where the hardware address of the machine that generated the frame and the hardware address of the machine that the frame is sent to must be inserted in the frame header. All nodes on the network can optionally see all packets sent over the network. This can be a problem for secure communications, especially if the communicator does not want a third party to be able to identify who is exchanging information. One way to deal with this problem is to extend the address hopping method to the hardware layer. According to various aspects of the invention, the hardware address is "hopped" in a manner similar to the method used to change the IP address, so the listener generated a particular message. It is not possible to determine which hardware node it is, or which node the intended receiver is.
Figure 12A shows a system in which medium access control (MAC) hardware addresses are hopped to improve security on networks such as Ethernet®. Although this description cites an exemplary case of an Ethernet® environment, the principles of the invention can be applied to other types of communication media as well. For Ethernet®, the sending and receiving MAC addresses are inserted into an Ethernet® frame and can be seen by anyone on the LAN within the broadcast range of that frame. In order to realize secure communication, it is desirable to generate a frame having a MAC address that does not belong to a specific transmitting side or receiving side.
As shown in Figure 12A, computer nodes 1201 and 1202 communicate over a communication channel such as Isanet. Each node runs one or more application programs 1203 and 1218 that communicate by sending packets with communication software 1204 and 1217, respectively. Examples of application programs include video conferencing, email, document processing programs, and so on. Communication software 1204 and 1217 can include, for example, an OSI layered structure or "stack" that standardizes different services realized at different functional levels.
The lowest levels of communication software 1204 and 1217 communicate with hardware components 1206 and 1214, respectively, and each component allows one or more registers to reconfigure or control the hardware according to various communication protocols. It can include 1207 and 1215. Hardware components (eg, Ethernet® network interface cards) communicate with each other via communication media. Each hardware component is typically pre-assigned with a fixed hardware address or MAC number that identifies the hardware component to other nodes on the network. As described in detail below, various aspects of the principles of the invention are one or more algorithms that track a range of valid addresses to validate received packets. Allows "hopping" of different addresses using multiple move windows. Packets transmitted according to one or more principles of the invention are generally "safe" packets to distinguish them from regular data packets sent in clear text using machine-correlated regular addresses. Or called "secure communication".
One simple way to generate an unattributable MAC address is an extension of the IP hopping method. In this case, the two machines on the same LAN communicate securely, exchanging random number generators and seeds, and creating a sequence of quasi-random MAC addresses for synchronous hopping. In this case, the implementation and synchronization issues are similar to the same IP hopping issue.
However, this technique can use the currently active MAC address on the LAN, which can disrupt communication between these machines. Since Ethernet (registered trademark) MAC addresses are currently 48 bits in length, the chances of random abuse of active MAC addresses are actually extremely low. However, this number includes a large number of nodes (as seen in a wide range of LANs), a large number of frames (as in the case of packet voice or streaming video), and a large number of parallel virtual private networks (VPNs). When multiplied by the number of, the possibility of using the MAC address of an insecure machine in the address hopping frame is not negligible. Simply put, any method that has the potential to disrupt communication on other machines on the LAN is opposed by a visionary system administrator. Nevertheless, this is technically feasible and can be safely done on a LAN with a small number of machines, or if all machines on the LAN have MAC hop communication. be able to.
Synchronous MAC address hopping can involve some overhead when establishing a session, especially if there are multiple sessions or nodes involved in the communication. An easier way to randomize the MAC address is to allow each node to receive and process any frame that occurs on the network. Typically, each network interface driver checks the destination MAC address in the header of every frame that occurs to see if it matches the machine's MAC address. If they do not match, this frame is discarded. However, in one aspect, these checks can be overridden and any packets generated are passed to the TARP stack for processing. This is called "promise cure" mode because every frame that occurs is processed. Promiscuous mode ensures that the destination machine can process the frame, allowing the sender to use a completely random MAC address that is out of sync. The TARP stack handles the determination of whether a packet is destined for that machine, and the TARP stack checks to see if the source and destination IP addresses match in the TARP stack's IP synchronization table. .. If no match is found, this packet is dropped. If there is a match, the packet is released and the inner header is evaluated. If the inner header indicates that the packet is destined for this machine, the packet is pushed onto the IP stack, otherwise the packet is dropped.
One drawback of purely random MAC address hopping is the effect of this hopping on processing overhead. That is, the machine's CPU is used much more often than if the network interface driver unilaterally discriminates and rejects packets because it must handle every frame that occurs. As a compromise, a single fixed MAC address or a small number of MAC addresses (eg, Ethernet®) should be used for MAC hop communication, regardless of the actual recipient of the message. There is a method of selecting one MAC address for each virtual dedicated network). In this mode, the network interface can inspect each frame that occurs against one (or a few) pre-established MAC addresses, which allows the CPU to make no distinction between physical layer packets. I'm done. With this method, important information is not leaked to intruders on the LAN. In particular, any secure packet can be pre-identified by the unique packet type in the outer header. However, because all machines that communicate securely either use the same MAC address or choose from a small set of given MAC addresses, the association between a particular machine and a particular MAC address is effectively lost. Will be.
With this method, the CPU cannot communicate securely (or) because the network interface driver cannot always unilaterally distinguish between secure packets destined for this machine and secure packets from other VPNs. Used more often than in the case of synchronous MAC address hopping). However, it is easy to eliminate unsafe traffic on network interfaces, thus reducing the amount of processing required by the CPU. If there are boundary conditions where these do not apply, for example, if all traffic on the LAN is safe, the CPU will be used as much as purely random address hopping. Alternatively, if each VPN on the LAN uses a different MAC address, the network interface can completely distinguish secure frames destined for the local machine from the secure frames that make up other VPNs. it can. These are technical trade-offs and can be best handled by giving management options when the user installs the software and / or establishes a VPN.
However, even in this case, there is still a small possibility that the MAC address used by one or more nodes on the LAN will be selected. One solution to this problem is to officially assign one address or a range of addresses used in MAC hop communication. This is typically done through an assignment number registration authority, for example, in the case of Ethernet®, the Institute of Electrical and Electronics Engineers (IEEE) has assigned a MAC address range to the vendor. The officially assigned address range ensures that secure frames fit into properly configured and properly functioning machines on the LAN.
Next, reference is made to FIGS. 12A and 12B to illustrate a number of combinations and features according to the principles of the invention. As mentioned above, assume that the two computer nodes 1201 and 1202 are communicating over a network or communication medium such as Ethernet®. The communication protocols of each node (1204 and 1217, respectively) include modified elements 1205 and 1216 that perform certain functions derived from standard communication protocols. In particular, computer node 1201 has an apparently random source and destination IP address (and, in one embodiment, an apparently random IP header) to send each packet to the other computer node. Perform the first "hop" algorithm 1208X to select the discriminator field). For example, node 1201 maintains an outbound table 1208 that contains a triad of destination (S), destination (D), and discriminator fields (DS) that are inserted in the outgoing IP packet header. This table is generated by using the appropriate algorithm known to the receiving node 1202 (eg, a random number generator seeded with the appropriate seeds). As each new IP packet is formed, the sender's sending table 1208 sequential entries are used to fill in the IP source, IP destination, and IP header extension fields (for example, the discriminator field). It will be appreciated that the send table does not need to be pre-created, but instead can be created by running an algorithm during operation as it forms each packet.
On the receiving node 1202, the same IP hop algorithm 1222X is maintained, and the above algorithm is added to the receiving table 1222, which lists the valid triplets of source IP address, destination IP address, and discriminator field. Used to generate using. This is indicated by the fact that the first five entries in transmit table 1208 match the second five entries in receive table 1222. (Each table can be slightly off at any particular time due to packet loss, out-of-order packets, or transmission delays). Node 1202 also maintains a receive window W3 that represents a list of valid IP sources, IP destinations, and discriminator fields that are accepted when received as part of an incoming IP packet. When a packet is received, window W3 slides down the list of valid entries, so the possible valid entries change over time. Two packets that arrive in the wrong order but nevertheless match the entry in window W3 are accepted. Packets that do not fit in window W3 are rejected as invalid packets. The length of window W3 can be adjusted as needed to reflect network delay or other factors.
Node 1202 maintains a similar outbound table 1221 to create IP packets and frames destined for node 1201 using a different hopping algorithm 1221X, and node 1201 uses the same algorithm 1209X. And maintain a matching receive table 1209. When node 1202 sends a packet to node 1201 using an apparently random IP destination, IP destination, and / or discriminator field, node 1201 puts the incoming packet value into node 1201's receive table. Match the value that fits within the maintained window W1. In practice, the transmit table 1208 on node 1201 and the receive table 1222 on the receiving node 1202 are synchronized (ie, the entries are selected in the same order). Similarly, the transmit table 1221 on node 1202 and the receive table 1209 on node 1201 are synchronized. Figure 12A shows a common algorithm for the source, destination, and discriminator fields (for example, using different seeds for each of the three fields), but in reality it uses a completely different algorithm. It will be understood that the values of each of these fields can be established. It will also be appreciated that one or two fields can be "hopped" instead of all three fields as shown.
According to another aspect of the invention, in order to improve security within a local area network or broadcast network, a hardware address or "" instead of or with the IP address and / or discriminator field. The "MAC" address is hopped. For this purpose, node 1201 has a source hardware address and a source hardware address that is inserted into the frame header (for example, fields 1101A and 1101B in Figure 11) that is synchronized with the corresponding receive table 1224 at node 1202. Further maintains the outbound table 1210, which generates the destination hardware address using the outbound algorithm 1210X. Similarly, node 1202 maintains a different outbound table 1223 containing source and destination hardware addresses that are synchronized with the corresponding inbound table 1211 on node 1201. Thus, an outgoing hardware frame originates from a completely random node on the network, even though each receiver can determine if a given packet is destined for the receiver. And it looks like it will be sent to such a node. It will be appreciated that the hardware hopping feature can be performed at a different communication protocol level than the IP hopping feature (for example, with the card driver or the hardware card itself to improve performance).
FIG. 12B shows three different aspects or modes that can be used using the principles described above. In the first mode, called "promise cure" mode, there is no hardware address common to all nodes on the network (for example, a fixed address for the source and another fixed address for the destination) or completely none. An artificial hardware address is used, so no particular packet can be attributed to a single node. Each node initially accepts all packets containing a common (or random) hardware address and examines the IP address or discriminator field to determine if the packet is destined for that node. There must be. Note that the IP address and / or discriminator field can be changed according to the algorithm described above. As mentioned earlier, this increases the overhead of each node by requiring additional processing to determine if a given packet has a reasonable source and destination hardware address. there's a possibility that.
A second mode, called "Promise Cures Per VPN" mode, uses a small set of fixed hardware addresses and is fixed to all nodes communicating over the virtual private network Source / Destination hardware. The address is used. For example, if you have 6 nodes on Ethernet and the network is split into two dedicated virtual networks so that each node on one VPN can only communicate with the other two nodes on that VPN. You can use two sets of hardware addresses, one for the first VPN and the second for the second VPN. This reduces the amount of overhead required to inspect for valid frames, as it only needs to inspect packets arriving from the specified VPN. Again, you can hop the IP address and one or more discriminator fields as described above for secure communication within the VPN. Of course, this solution disables VPN anonymity (ie, it's easy for outsiders to know which VPN the traffic belongs to, but outsiders identify it. Cannot be correlated with machine / person). You also need to use discriminator fields to reduce your chances of being hit by some kind of DoS attack. (For example, the absence of a discriminator field allows an attacker on the LAN to create a stream of frames containing the MAC address used by the VPN. Excessive to reject such frames. The discriminator field, which may require processing overhead, provides a low overhead means of rejecting pseudo-packets.)
In a third mode, called "hardware hopping" mode, the hardware address is changed, as shown in Figure 12A, which constantly changes the hardware source address and the hardware destination address, and the address is It becomes unattributable. Of course, variations of these aspects are possible and the invention is not limited in any way by these examples.
<u style="single">B. Address space expansion</u> Address hopping ensures security and privacy. However, the level of protection is limited by the number of addresses in the hopped block. The hop block indicates a field that is adjusted for each packet to realize VPN. For example, if two nodes communicate using IP address hopping, where each block uses a hop block consisting of four addresses (2 bits), there are 16 possible address pair combinations. For size 16 windows, most address pairs are accepted as valid pairs most of the time. This limitation can be lifted by using the discriminator field in addition to or instead of the hop address field. Discriminator fields are hopped just like address fields and are used to determine if a packet should be processed by the receiver.
Suppose two clients, each using a 4-bit hop block, want the same level of protection given to clients communicating via IP hopping between two A blocks (effective for hopping). 24 bits). This level of protection is achieved when a 20-bit discriminator field is used with a 4-address bit that is useful for hopping in the IP address field. The 24-bit discriminator field achieves a similar level of protection if the address field is not hopped or ignored. The discriminator field has two advantages: (1) any high level of protection can be achieved, and (2) protection is achieved without address hopping. This is important in environments where address hopping causes routing problems.
<u style="single">C. Synchronization technique</u> Subsequent communication between the two nodes after the sender and receiver nodes have exchanged algorithms and seeds (or similar information sufficient to generate a quasi-random source table and a quasi-random destination table). Is generally assumed to proceed smoothly. However, in reality, the two nodes can lose synchronization due to network delays or failures, or other problems. Therefore, it is desirable to provide a means of reestablishing synchronization between nodes in the network that have lost synchronization.
One possible technique is to have each node supply an acknowledgment when each packet is successfully received and retransmit the unacknowledged packet if the acknowledgment is not received within a period of time. However, this approach increases overhead costs and can become unusable in high throughput environments such as streaming video and streaming audio.
Another technique uses an automatic synchronization technique referred to herein as "self-synchronization." With this technique, synchronization information is embedded in each packet, which allows the receiver to regain its own synchronization when a single packet is received if it determines that it has lost synchronization with the sender. it can. (If communication is already in progress and the receiver determines that it is still in sync with the sender, there is no need to resynchronize.) The receiver expires, for example, after a period of time, and each Out of sync can be detected by using a "dead man" timer that is reset by a valid packet in. Hashing can time stamp public sync fields (see below) to prevent packet retry attacks.
In one embodiment, a "synchronization field" is added to the header of each packet transmitted by the sender. This synchronization field may be in clear text or may be part of an encrypted portion of the packet. Assuming that the sender and receiver have selected a random number generator (RNG) and a seed value, this combination of RNG and seed can be used to generate a random number array (RNS). The RNS is then used to generate the source / destination IP pair (and optionally the discriminator field and the hardware source and hardware destination addresses) as described above. However, it is possible to generate the Nth random number in a sequence without generating the entire sequence (or the first N-1 values). If the sequence index N is known, a random value corresponding to this index can be generated directly (see below). Various RNGs (and seeds), each with a different base period, can be used to generate source and destination IP sequences, but the basic concept still applies. For simplicity, the discussion below assumes that IP source-destination address pairs (only) are hopped using a single RNG sequencing mechanism.
The synchronization fields in each packet header are indexed (ie, sequence numbered) by the "self-synchronization" feature to the RNS used to generate the IP pair. Indexing the RNG used to generate the RNS in this way produces a specific random number value, which in turn produces a specific IP pair. That is, the IP pair can be generated directly from the RNG, seed, and index number, and this method does not need to generate the entire sequence of random numbers that precedes the sequence value associated with the given index number. ..
Since it is assumed that the communicator has already exchanged RNG and seeds, the only new information that must be given to generate an IP pair is the sequence number. If this number is given in the packet header by the sender, the receiver can simply enter this number into the RNG to generate an IP pair, so the IP pair shown in the packet header is valid. It can be verified that there is. In this method, if the sender and receiver lose synchronization, the receiver compares the IP pair in the packet header with the IP pair generated from the index number when a single packet is received. You can get back in sync immediately with. Therefore, when a single packet is received, synchronized communication can be resumed, which makes this method ideal for multicast communication. In extreme cases, the synchronization table is completely unnecessary. That is, the sender and receiver can just use the index number in the synchronization field to validate the IP pair on each packet, thereby eliminating the table altogether.
The aforementioned method has certain inherent security issues associated with it. That is, it is a matter of arrangement of synchronization fields. If this field is placed in the outer header, an intruder can see the value of this field and the relationship between that value and the IP stream. This, in some cases, affects the algorithm used to generate the IP address sequence, thus affecting the security of the communication. However, if this value is placed in the inner header, the sender cannot extract the synchronization value and check the validity of the IP pair unless the inner header is decrypted. In this case, the receiver is exposed to some sort of denial of service (DoS) attack, such as packet playback. That is, if the receiver cannot validate the IP pair without decrypting the packet, and the attacker simply retransmits the previously valid packet, a significant amount of decryption must be performed. There is a risk of having to do it.
A possible trade-off between algorithm security and processing speed is to split the sync value between the inner header (encrypted) and the outer header (unencrypted). That is, if the sync value is long enough, it can be divided into a rapidly changing part that can be displayed in plaintext and a fixed (or very slowly changing) part that must be protected. The part that can be displayed in plain text is called the "public synchronization" part, and the part that must be protected is called the "private synchronization" part.
Both public and private syncs are required to generate full sync values. However, the private part can be chosen to be fixed or change only from time to time. Therefore, the private sync value can be stored by the receiver and can be retrieved without decoding the header. If the sender and receiver have already agreed on how often the private part of the synchronization changes, the receiver chooses if the communication gap that caused the loss of synchronization exceeds the lifetime of the previous private synchronization. A single header can be decrypted to extract a new private sync. In this case, the amount of decryption is not annoying and therefore the receiver is not exposed to a denial of service attack simply because it sometimes needs to decrypt a single header.
In this one implementation, a hash function is used with a one-to-one mapping to generate a private sync and a public sync from the sync values. This implementation is shown in Figure 13, where (for example) the first ISP1302 is the sender and the second ISP1303 is the receiver. (Other alternatives are possible in Figure 13.) The packet being sent is an unencrypted public header or "outer" header 1305 and a private header encrypted using, for example, a link key. Or with an "inner" header 1306. The outer header 1305 contains a public sync section, whereas the inner header 1306 contains a private sync section. The receiving node uses the decoding function 1307 to decode the inner header and extract the private sync. This step is only necessary when the currently buffered private sync has expired. (If the currently buffered private sync is still in effect, this private sync is simply extracted from memory and "added" (or reverse hashed) to the public sync as shown in stage 1308.) Public sync And the decrypted private synchronization part are combined by the function 1308, and the combination synchronization 1309 is generated. Combination synchronization (1309) is then sent to RNG (1310) and compared with the IP address pair (1311) to validate the packet or reject the packet.
An important point of this structure is the concept of "future" and "past" in which public synchronization values are involved. The sync value itself should be a random value to prevent spoofing attacks, but the receiver will still receive this sync value even if the packet containing the sync value already sent has not actually been received by the receiver. It is important to be able to identify immediately. One solution is that hashing adds a timestamp or sequence number to the public sync, so this public sync is immediately extracted, inspected, and destroyed, thereby validating the public sync itself. You can check.
In one embodiment, the packet can be inspected by comparing the source / destination IP pair generated by the synchronization field with the pair indicated in the packet header. If (1) the pair matches, (2) the timestamp is valid, and (3) the deadman timer has expired, the synchronization will be re-synchronized. Otherwise, the packet will be rejected, if sufficient processing power is available, the deadman timer and synchronization table can be circumvented, and the receiver will simply resynchronize for every packet (eg, validate). ).
The above method may require large integer (for example, 160 bits) computations that affect its implementation. The absence of such large integer registers affects throughput and, in some cases, security in terms of denial of service. Nevertheless, as the large integer calculation processing function becomes widespread, the cost of implementing such a function will be reduced.
<u style="single">D. Other synchronization methods</u> As mentioned above, if more than W consecutive packets are lost between the communication side and the receiving side in the VPN (W is the window size), the receiving side window is not updated and the sending side is , Do not send packets that are not in the receiving window. The sender and receiver will probably not regain synchronization until a random pair in the window is accidentally repeated. Therefore, it is necessary to synchronize the sender and receiver whenever possible and reestablish it whenever synchronization is lost.
The synchronization between the sender and the receiver that lost synchronization can be restored using a "checkpoint" method. This method uses checkpoint messages with random IP address pairs to convey synchronization information. In one embodiment, two messages are used to convey the following synchronization information between the sender and receiver: 1.SYNC_REQ is a message used by the sender to indicate that it needs to be synchronized. 2.SYNC_ACK is a message used by the receiver to inform the sender that the receiver has been synchronized.
According to a variant of this technique, both the sender and receiver maintain the following three checkpoints (see Figure 14): 1. On the sending side, ckpt_o (checkpoint old) is the IP pair used to resend the last SYNC_REQ packet to the receiving side. On the receiving side, ckpt_o (checkpoint old) is an IP pair that repeatedly receives SYNC_REQ packets from the transmitting side. 2. On the sending side, ckpt_n (checkpoint new) is the IP pair used to send the next SYNC_REQ packet to the receiving side. On the receiving side, ckpt_n ("checkpoint new") receives a new SYNC_REQ packet from the sending side, rearranges the receiving window, sets ckpt_o to ckpt_n, generates a new ckpt_n, and sets a new ckpt_r. It is an IP pair to be generated. 3. On the sending side, ckpt_r is the IP pair used to send the next SYNC_ACK packet to the receiving side. On the receiving side, ckpt_r is an IP pair that receives a new SYNC_ACK packet from the transmitting side and generates a new ckpt_n. Since SYNC_ACK is transmitted from the receiving ISP to the sending ISP, the sending ckpt_r points to the receiving ckpt_r and the receiving ckpt_r points to the sending ckpt_r (see Figure 14).
When the sender starts synchronization, the IP pair that the sender uses to send the next data packet is set to a given value, and when the receiver first receives SYNC_REQ, the receiver window displays the next IP pair on the sender. Is updated to be central.
Synchronization can be started by a packet counter (for example, every N packets sent), by a timer (starting synchronization every S seconds), or theirs. It can also be started by a combination. See Figure 15. From the sender's point of view, this technique works as follows. (1) Each sender periodically sends a "synchronization request" message to the receiver to confirm that the receiver is in sync. (2) The receiver sends back a "synchronization confirmation" message if it is still in sync. (If this works, no further action is required). (3) If the "synchronization confirmation" is not received within a certain period, the sender sends the synchronization request again. If the sender reaches the next checkpoint without receiving a "sync confirmation" response, synchronization is lost and the sender must stop sending. The sender continues to send sync_reqs until it receives sync_ack, at which point the transmission is reestablished.
From the receiving side, this method works as follows. (1) When the receiving side receives the "synchronization request" request from the sending side, it advances the window to the next checkpoint position (in some cases, skips the pair if necessary) and sends the "synchronization response" message to the sending side. Send to. If synchronization is not lost, "jump ahead" advances to the next available address pair in the table (ie, normal forward).
If an intruder captures a "sync request" message and attempts to interfere with the communication by sending a new "sync request" message, either synchronization has been established or this message actually helps to reestablish synchronization. If, this message is ignored.
The windows are realigned whenever a resync occurs. With this realignment, the receiving window is updated to span the address pair used by the packet sent immediately after the SYNC_REQ packet was sent. Usually, the sender and the receiver are synchronized with each other. However, in the event of a network event, the receiving window may have to be advanced by a number of steps during resynchronization. In this case, it is desirable to advance the window without having to sequentially advance between the intervening random numbers. (This feature is also desirable for the automatic synchronization techniques described above).
<u style="single">E. Random number generator with jump ahead function</u> An attractive way to generate randomly hopped addresses is to use the same random number generator on the sender and receiver and proceed with this program when a packet is sent and received. There are a number of random number generation algorithms that can be used. Each algorithm has advantages and disadvantages over address hopping applications.
The linear random number generator (LCR) is a fast and simple random number generator with distinctive features that can efficiently jump n steps ahead. LCR uses the following iteration to seed X<sub>0</sub>Random number X starting with<sub>1</sub>, X<sub>2</sub>, X<sub>3</sub>, ..., X<sub>K</sub>To generate. (Number 1) X<sub>i</sub>= (aX<sub>i-1</sub>+ b) mod c (1) In the formula, a, b, and c are the codes that define a particular LCR. X<sub>i</sub>Another formula for, i.e. (Number 2) X<sub>i</sub>= ((a<sup>i</sup>(X<sub>0</sub>+ b) -b) / (a-1)) mod c (2) Enables the jump ahead function. Coefficient a<sub>i</sub>Can be very large, even if i is small, if not constrained. Therefore, some special characteristics of modulo arithmetic can be used to adjust the size and processing time required to calculate (2). (2) can be written as the following equation. (Number 3) X<sub>i</sub>= (a<sup>i</sup>(X<sub>0</sub>(a-1) + b) -b / (a-1) mod c (3) The following can be shown. (Number 4) (a<sup>i</sup>(X<sub>0</sub>(a-1) + b) -b) / (a-1) mod c = ((a<sup>i</sup>mod ((a-1) c) (X<sub>0</sub>(a-1) + b) -b) / (a-1)) mod c (4) (X<sub>0</sub>(a-1) + b) to (X<sub>0</sub>(a-1) + b) Store as mod c, store b as b mod c, a<sup>i</sup>mod ((a-1) c) can be calculated (this requires 0 (log (i)) steps).
A practical implementation of this algorithm jumps a certain distance n between each synchronization. This corresponds to synchronization every n packets. The window starts after n IP pairs start after the previous window started. Node is X<sub>j</sub><sup>w</sup>That is, the random number at the Jth checkpoint is X<sub>0</sub>1 degree per LCR, using n as i<sup>n</sup>Memorize mod ((a-1) c) and (Number 5) X<sub>j + 1</sub><sup>w</sup>= X<sub>n (j + 1)</sub>= ((a<sup>n</sup>mod ((a-1) c) (X<sub>j</sub><sup>w</sup>(a-1) + b) -b) / (a-1)) mod c (5) Can be set to generate a random number for j + 1th synchronization. Nodes can use this configuration to jump any (but constant) distance ahead during each synchronization within a fixed amount of time (independent of n).
Therefore, pseudo-random number generators, especially LCRs, generally repeat the cycle. This repetition can be a weakness of the IP hopping method. That is, the enemy can predict future sequences simply by waiting for repetition. One way to address this weakness is to write a random number generator with a known long cycle. This sequence can be replaced with a new random number generator before the random sequence is repeated. LCRs with known long cycles can be constructed. This is not currently the case with many random number generators.
Random number generators are not cryptographically secure. The enemy can derive RNG parameters by examining the output or part of it. This applies to LCG. This weakness can be mitigated by incorporating an encryption program configured to make the output part of a random number generator. Random number generators prevent the enemy from attacking cryptographic programs, such as known plaintext attacks.
<u style="single">F. Example of random number generator</u> Consider RNG with a = 31, b = 4, and c = 15. In this case, formula (1) is (Number 6) X<sub>i</sub>= (31X<sub>i-1</sub>+4) mod 15 (6) become.
X<sub>0</sub>When = 1 is set, formula (6) produces sequences 1, 5, 9, 13, 2, 6, 10, 14, 3, 7, 11, 0, 4, 8, 12. This sequence repeats infinitely. If you want to jump three numbers ahead in this sequence, a<sup>n</sup>=31<sup>3</sup>= 29791, c<sup>*</sup>(a-1) = 15 * 30 = 450, and a<sup>n</sup> mod ((a-1) c) = 31<sup>3</sup>mod (15 * 30) = 29791 mod (450) = 91. Formula (5) is (Number 7) ((91 (X)<sub>i</sub>30 + 4) -4) / 30) mod 15 (7) Table 1 shows the jump-ahead calculation in (7). This calculation starts at 5 and jumps 3 ahead.
<tables num="1"><img file="JP2011109651A_D0001.tif" /></tables>
<u style="single">G. Fast packet filter</u> The address hopping VPN immediately determines if the packet has a reasonable head and therefore requires further processing or has an unreasonable header (harmful packet) and should be rejected immediately. Must. Such high-speed determination is called "high-speed packet filtering". This feature protects the VPN from enemy attacks (so-called "denial of service" attacks) that instantly create a stream of harmful packets on the receiving side to saturate the receiving processor. High-speed packet filtering is an important function for implementing VPN on shared media such as Ethernet (registered trademark).
Assuming that all participants in the VPN share an unassigned "A" address block, one possibility is an experimental "A" that will not be assigned to a machine that is not address hopping on the shared medium. The "A" block is used. The "A" block has a 24-bit address that can be hopped as opposed to the 8-bit in the "C" block. In this case, the hop block becomes an "A" block. Experimental "A" blocks are likely to be used on Ethernet® for the following reasons: 1. The address is invalid outside of Ethernet® and will not be routed by the gateway to a valid external destination. 2. You can hop within each "A" block 2<sup>24</sup>There are (~ 16 million) addresses. This creates> 280 trillion possible address pairs, making it very unlikely that the enemy will be able to guess a valid address. Also, the likelihood of collisions between different VPNs is low enough to tolerate (all VPNs on the shared medium independently generate a random address pair from the "A" block). 3. Packets (unless the machine is in Promise Cures mode) are not received by users on Ethernet® and not on VPN, with minimal impact on non-VPN computers. It can be suppressed to the limit.
This Ethernet® example is used to illustrate one implementation of fast packet filtering. The ideal algorithm immediately examines the packet header to determine if the packet is harmful and either rejects any harmful packet or determines which active IP pair the packet header matches. To do. The problem in this case is that of traditional associate memory. Various techniques have been developed to solve this problem (hashing, B-trees, etc.). Each of these methods has advantages and disadvantages. For example, a hash table can work very quickly in a statistical sense, but in some cases it can degenerate into a much slower algorithm. This slowness may persist over a period of time. Hashing is unacceptable because malicious packets always need to be dropped immediately.
<u style="single">H. Existence vector algorithm</u> The existence vector is an n-bit number (0 to 2 respectively).<sup>n</sup>A 2n long bit vector that can be indexed by (range up to -1). The existence of k n-bit numbers (not necessarily unique) can be indicated by setting the bits in the existence vector indexed by each number to 1. The n-bit number x is one of the k numbers only if the xth bit of the existence vector is 1. A fast packet filter can be performed by indexing the existence vector and looking for 1. This method is called "testing".
For example, suppose you need to use an existence vector to represent number 135. The 135th bit of the vector is set. Therefore, by inspecting one bit, the 135th bit, it is possible to quickly determine whether address 135 is valid. Existence vectors can be pre-created to correspond to table entries for IP addresses. In practice, the incoming address can be used as an index for long vectors to make comparisons very quickly. As each RNG generates a new address, the presence vector is updated to reflect this information. As the window moves, the presence vector is updated to zero addresses that are no longer valid.
There is a trade-off between test efficiency and the amount of memory needed to store the existence vector. For example, if a 48-bit hopping address needs to be used as an index, the existence vector must have 35 terabytes. It is clear that this is practically too large. Instead, you can split the 48 bits into several smaller fields. For example, 48 bits can be subdivided into four 12-bit fields. This reduces the storage requirement to 2048 bytes and instead requires processing malicious packets from time to time. In reality, further processing is not allowed unless each decomposed address part, rather than one long existence vector, matches all four short existence vectors. (If the first part of the address part does not match the first existence vector, then there is no need to check the remaining three existence vectors).
The y-th bit of the existence vector is 1 only if one or more addresses whose corresponding fields are y are active. An address is active only if each existence vector indexed by the appropriate subfield of that address is 1.
Consider a window consisting of 32 active addresses and 3 checkpoints. Harmful packets are rejected by indexing one presence vector over a period of more than 99%. Harmful packets are rejected by indexing all four presence vectors over a period of time greater than 99.9999995%. On average, harmful packets are rejected with less than 1.02 presence vector indexing operations.
A small number of harmful packets that pass the fast packet filter are rejected when the matching pair is not found in the active window or is an active checkpoint. Harmful packets that unexpectedly match a header are rejected when VPN software attempts to decrypt this header. However, these cases are extremely rare. There are many other means of constructing this method to balance space and velocity.
<u style="single">I. Other synchronous extensions</u> A slightly modified form of the synchronization technique described above can be used. The basic principle of the checkpoint synchronization method described above is the same. However, the treatment of receiving a checkpoint is slightly different. In this variant, the receiver maintains OoO ("out of order") or 2xWINDOW_SIZE + OoO active addresses. (1 OoO WINDOW_SIZE and WINDOW_SIZE 1). OoO and WINDOW_SIZE are tunable parameters, OoO is the minimum number of addresses needed to deal with lost packets due to events in the network or out-of-order arrivals, and WINDOW_SIZE is issued by SYNC_REQ. The number of packets sent before being done. FIG. 17 shows a storage array of receiving active addresses.
The receiver starts with the first 2xWINDOW_SIZE addresses that are loaded and active (ready to receive data). When the packet is received, the corresponding entry is marked "used" and the packet can no longer be received. The sender maintains a packet counter that is initially set to 0 and contains the number of data packets transmitted since the last initial transmission of the SYNC_REQ received. When the packet counter on the transmitting side becomes equal to WINDOW_SIZE, the transmitting side generates SYNC_REQ and performs the initial transmission thereof. When the receiver receives the SYNC_REQ corresponding to its current CKPT_N, it generates the next WINDOW_S address, starting at the first position after the last active address and after reaching the end of the array. Start loading these addresses in order to return to the beginning of. The array on the receiving side is as shown in FIG. 18 when SYNC_REQ is received. In this case, when SYNC_REQ is received, a few packets are lost or received in the wrong order.
Figure 19 shows the receiving array after the new address has been generated. If the sender does not receive SYNC_ACK, it reissues SYNC_REQ at regular intervals. When the sender receives SYNC_ACK, the packet counter is decremented by WINDOW_SIZE. When the packet counter reaches 2xWINDOW_SIZE-OoO, the sender stops sending data packets until it finally receives the appropriate SYNC_ACK. The sender then resumes sending the data packet. Future behavior is primarily the repetition of this initial cycle. The advantages of this method are as follows. 1. Efficient jump ahead is not required in random number generators. 2. Packets that do not have a corresponding entry on the receiving side will not be sent. 3. No timer-based resynchronization required. This is the result of 2. 4. The receiver is always capable of accepting no more than OoO sent data messages from the last sent message.
<u style="single">J. Distributed transmission path variant</u> Other embodiments incorporating the various principles of the present invention are shown in FIG. In this embodiment, the message transmitting system includes a first computer 2001 that communicates with a second computer 2002 via a network of intermediate computers 2011. In one variant of this aspect, the network comprises two edge routers, each linked to multiple Internet Service Providers (ISPs) 2005-2010. Each ISP is combined with a plurality of other ISPs in the configuration shown in FIG. 20, which is only a typical configuration and is not restrictive. Each connection between ISPs is coded in Figure 20 to indicate a particular physical transmission path (for example, AD is the physical linking ISP A (element 2005) to ISP D (element 2008). Path). Packets arriving at each edge router are selectively sent to one of the ISPs to which the router is connected based on a random or semi-random selection criterion.
As shown in Figure 21, computer 2001 or Edge Router 2003 identifies a valid set of IP addresses that can be used to send a packet for each potential transmission path in the network, multiple link transmissions. Incorporates table 2100. For example, AD table 2101 contains multiple randomly or quasi-randomly generated IP source / destination pairs. When sending a packet from the first computer 2001 to the second computer 2002, one link table is randomly selected (or semi-randomly) and the next valid destination / destination address in this table. Packets are sent over the network using pairs. For example, if you randomly select Path AD, then (ISP A (Element 2005) and ISP Packets are sent using the following source / destination IP address pairs (predetermined to be sent to and from B (element)): If one of the outbound paths deteriorates or becomes inoperable, the link table is set to the "down" state as shown in table 2105, and therefore an address is selected from this table. It can be prevented from being done. Other transmission paths are not affected by this corrupted link.
<u style="single">3. Some continuous improvements</u> In the following, various improvements and features applicable to the above aspects will be described. These improvements include (1) a load balancer that distributes packets across different transmission paths depending on the quality of the transmission path, and (2) transparently forming a virtual dedicated network in response to domain name queries. DNS proxy server to use, (3) large and small link bandwidth management function to prevent denial of service attacks at system checkpoints, and (4) limit the speed at which senders and receivers can be synchronized. It includes a traffic limiter that regulates incoming packets by means of (5) a signaling synchronizer that allows a large number of nodes to communicate with the central node by splitting the communication function between two separate entities. Each improvement will be considered separately below.
A.<u style="single">Load balancer</u> The various aspects described above include a system in which a transmitting node and a receiving node are combined through a plurality of transmission paths, and consecutive packets are distributed quasi-randomly on the plurality of paths. See, for example, FIGS. 20 and 21 and the accompanying description. With the improvements of the present invention, this basic concept is extended to include the step of distributing packets across different paths so that the load on the paths is roughly balanced depending on the quality of the transmission link.
In one embodiment, the system includes transmit and receive nodes linked through multiple transmission paths, optionally with varying transmission qualities. Consecutive packets are transmitted on the path based on the weight value distribution function for each path. The speed at which packets are sent on a given path can be different for each path. The relative "health" of each transmission path is monitored to identify degraded paths. In one embodiment, the health of each path is monitored on the transmitting side by comparing the number of packets transmitted with the number of packet acknowledgments received. Each transmission path contains a logically separated path (eg, a dial-up telephone line, computer network, router, bridge, etc.) that is contained within a broadband communication medium, even if it contains a physically separated path (eg, dial-up telephone line, computer network, router, bridge, etc.). For example, it may include FDM, TDM, CDMA, or other types of modulated or unmodulated transmission links).
When the transmission quality of a path is lower than a predetermined threshold and there is another path that can send the packet, the sender changes the weight value used for that path and goes through that path. Reduces the likelihood that a given packet will be sent. The weights are preferably set to greater than or equal to the minimum value that maintains nominal traffic on the path. The weights of the other available paths are modified to compensate for the affected path changes. The quality of the path deteriorates (ie, when no packets arrive at the destination) until the sender is turned off by the synchronization feature, and the weight is set to zero. If all senders are turned off, no packets will be sent.
Traditional TCP / IP protocols include a "throttle" feature that slows down the transmission of packets when it is determined that a delay or error has occurred during transmission. In this regard, in some cases a timer may be used to determine if a packet has been received. However, these traditional techniques for limiting the transmission of packets do not involve multiple transmission paths between two nodes, where transmissions beyond a particular path to other paths are modified based on the quality of the link. ..
According to some embodiments, a linear or exponential decay formula is applied to attenuate possible oscillations in other ways if the weight distribution changes significantly (eg, according to a step function). The weight value can be reduced over the time that the degraded path is likely to be used. Similarly, as the normality of a degraded path improves, the weight value of that path is gradually increased.
The health of the transmission link can be assessed by comparing the number of packets acknowledged in the transmit window (see aspects above) with the number of packets transmitted within that window, and transmission. It can be evaluated by the state of the side (ie, on or off). In other words, in one particular practice, rather than accumulating overall transmission statistics for a path over a period of time, the "window" concept described above is used to assess the health of the transmission path.
The same method can be used to move the virtual circuit path from the "abnormal" path to the "normal" path and select the path for the new virtual circuit.
FIG. 22A shows a flowchart for adjusting weight values associated with a plurality of transmission links. Assume that software running on one or more computer nodes performs each step shown in Figure 22A. It is also assumed that software to be executed by a computer can be stored on a computer-readable medium such as a magnetic disk or an optical disk.
First, in step 2201, the transmission quality of a given transmission path is measured. As mentioned above, this measurement is based on a comparison of the number of packets sent on a particular link with the number of packet acknowledgment signals received on this link (eg, per unit time or in absolute terms). be able to. Alternatively, the quality can be evaluated by comparing the number of packets acknowledged in the transmit window with the number of packets transmitted in this window. In another variant, the number of unreceived synchronous messages can be used to indicate link quality. Of course, many other variants are possible.
At step 2202, a check is performed to determine if multiple senders (eg, transmission paths) are turned on. If more than one sender is not turned on, this process ends and resumes at stage 2201.
At step 2203, the link quality is compared to a given threshold (eg 50% or any indefinite). If the quality is below the threshold, step 2207 is checked to determine if the weight is above the minimum level (eg 1%). If not exceeded, the weight is set to the minimum level at stage 2209 and processing resumes at stage 2201. If the weights exceed the minimum level, at stage 2208 the weights gradually decrease for this path, then at stage 2206 the weights of the remaining passes are adjusted to compensate (eg, the weights increase). ..
If the quality of the path is greater than or equal to the threshold in step 2203, then in step 2204 a check is made to determine if the weight is less than the steady state value of the path. In that case, step 2205 increases the weights closer to the steady-state value, and step 2206 adjusts the weights of the remaining paths to compensate (eg, reduce the weights). If the weight is greater than or equal to the steady-state value at step 2204, processing resumes at step 2201 without adjusting the weight.
The weight can be adjusted incrementally according to various functions, preferably by gradually changing the value. In one embodiment the weights are adjusted using a linear decrement function and, according to another aspect, an exponential decay function is used. Gradually changing the weights can help dampen the oscillators that would otherwise occur if the probabilities change abruptly.
Although not explicitly shown in Figure 22A, the process can only be performed cyclically (eg, according to a time schedule), or it can operate continuously, such as in background operating mode. In one aspect, the combined weights of all potential paths should add up to 1 (unity) (for example, reducing the weight of one path selects the other path) Corresponding weight Is expected to increase).
Adjustments to the weight values of other paths can be proportionally distributed. For example, reducing the weight value of one pass by 10% distributes the increment evenly to the weights of the remaining passes. Alternatively, the weighting may be adjusted according to the desired weighted formula (eg, supporting a normal path over a less normal path). In another variant, the difference in weight values can be amortized over the remaining links in proportion to the traffic weighting.
Figure 22B shows the steps that can be taken to block a transmission link that turns off the sender. At stage 2210, a sender blocking event occurs. At step 2211 a test is performed to determine if at least one sender is still on. If no sender is turned on, at step 2215, all packets are dropped until the sender is turned on. In step 2211 if at least one sender is turned on, in step 2212 the path weights are set to zero and the remaining path weights are adjusted accordingly.
FIG. 23 shows a computer node 2301 that utilizes various principles of the above aspects. Suppose two computer nodes of the type shown in Figure 23 communicate over multiple separate physical transmission paths. As shown in FIG. 23, the four transmission paths X1 through X4 are defined for communication between the two nodes. Each node contains a packet sender 2302 that operates according to the transmission table 2308 described above. (The packet sender can operate without using the IP hopping feature described above, but the following discussion assumes that some form of hopping is used with the path selection mechanism). The computer node also includes a packet receiver 2303 that operates according to receive table 2309, including a moving window W that moves when a valid packet is received. Invalid packets with source and destination addresses that do not enter window W are rejected.
When each packet is ready to be sent, the source and destination IP addresses (or other discriminator values) are selected from transmission table 2308 according to any of the various algorithms described above, 4 A packet containing these source / destination address pairs corresponding to the nodes to which the two transmission paths are concatenated is generated for transmission path switch 2307. Switch 2307, which may include software features, selects one of the available transmission paths according to the weight distribution table 2306. For example, if path X1 has a weight of 0.2, packets will be sent every five on path X1. The same method applies to the other paths shown. Initially, the weight value of each link can be set to be proportional to the bandwidth, which is referred to as the "steady state" value of the weight value.
The packet receiver 2303 operates as described above to generate an output to the link quality measurement function 2304 that determines the quality of each transmission path (the input to the packet receiver 2303 that receives the incoming packet is clear in the figure. Omitted to make). The link quality measurement function 2304 compares the link quality with the threshold value of each transmission link and generates an output to the weight adjustment function 2305 if necessary. If weight adjustment is required, the weights in Table 2306 are adjusted accordingly, preferably according to a tapering (eg, linear or exponential decay) function. In one embodiment, the weight values for all available paths are initially set to the same value, and the weights are changed to reflect the difference only when the quality of the paths deteriorates.
The link quality measurement function 2304 can be operated as part of the synchronizer function described above. That is, if the receiver detects that a resynchronization has occurred and the synchronization has been lost (for example, the result is out of order and the synchronization window W has advanced), this fact is used by the link quality measurement function 2304. Can be driven. According to one embodiment, load balancing is performed using information obtained during normal synchronization that is slightly increased to convey the health of the link from the receiver to the sender. The receiving side maintains MESS_R (W), which is the count value of the messages received in the synchronization window W. Upon receiving the synchronization request (SYNC_REQ) corresponding to the end point of window W, the receiving side includes the counter MESS_R in the resulting synchronization acknowledgment (SYNC_ACK) that is sent back to the transmitting side. This allows the sender to evaluate the health of the link by comparing the transmitted message with the received message.
If synchronization is completely lost, the weight adjustment function 2305 reduces the weight value on the affected path to zero. When synchronization is restored, the weight value of the affected path is gradually increased to the initial value. Alternatively, the quality of the link can be measured by assessing the length of time required for the receiver to acknowledge the synchronization request. In one embodiment, a separate transmit and receive table is used for each transmit path.
When the sender receives a SYNC_ACK, MESS_R is compared to the number of messages sent in the window (MESS_T). When the sender receives the SYNC_ACK, the traffic probability is checked and will be adjusted if necessary. MESS_R is compared to the number of messages sent within the window (MESS_T). There are two possibilities: 1. If MESS_R is less than the threshold THRESH, the link is considered abnormal. If the sender is turned off, the sender is turned on and the weight P for that link is set to the minimum value MIN. This is expected to keep a small amount of traffic on the link for monitoring until it recovers. When the sender is turned on, the weight P of the link is considered to be set as follows. (Number 8) P = α × MIN + (1-α) × P (1) Equation (1) exponentially reduces the traffic weight value to MIN during the period of service degradation. 2. If the link's MESS_R is THRESH or greater, the link is considered normal. If the weight P of the link is greater than or equal to the steady-state value S of the link, then P is invariant. If the weight P of the link is less than THRESH, then P is considered to be set as: (Number 9) P = β × S + (1-β) × P (2) In the equation, β is a parameter such that 0 <= β <= 1 that determines the attenuation factor of P. Equation (2) is thought to increase the traffic weight exponentially to S during the duration of the accepted service.
Next, a detailed example will be described with reference to FIG. 24. As shown in FIG. 24, the first computer 2401 communicates with the second computer 2402 through two routers 2403 and 2404. Each router is coupled to another router through three transmission links. As mentioned above, these may be physically discrete links or logical links (including virtual private networks).
The first link L1 can maintain a transmit bandwidth of 100 Mb / s and has a window size of 32, the link L2 can maintain 75 Mb / s and has a window size of 24, and more. Suppose link L3 can maintain 25 Mb / s and the window size is 8. Therefore, the combined link can maintain 200 Mb / s and the steady-state traffic weight is 0.5 for link L1, 0.375 for link L2, and 0.125 for link L3. MIN = 1Mb / s, THRESH = 0.8MESS_T for each link, α = 0.75 and β = 0.5. These traffic weights are considered to remain stable until the link is stopped to synchronize or reports that fewer packets than THRESH have been received. Consider the following event sequence. 1. Link L1 receives a SYNC_ACK containing 24 MESS_Rs, indicating that only 75% of the MESS_T (32) messages sent in the last window were successfully received. Link L1 is lower than THRESH (0.8). It is considered that the traffic weight value of link L1 decreases to 0.12825, while the traffic weight value of link L2 increases to 0.65812, and the traffic weight value of link L3 increases to 0.217938. 2. Links L2 and L3 remain normal and link L1 shuts down to synchronize. It is then believed that the traffic weight value for link L1 is set to 0, the traffic weight value for link L2 is set to 0.75, and the traffic weight value for link L3 is set to 0.25. 3. Link L1 receives a SYNC_ACK containing 0 MESS_R, indicating that none of the MESS_T (32) messages sent in the last window was successfully received. Link L1 is considered to be lower than THRESH. It is considered that the traffic weight value of link L1 increases to 0.005, the traffic weight value of link L2 decreases to 0.74625, and the traffic weight value of link L3 decreases to 0.24875. 4. Link L1 receives a SYNC_ACK containing 32 MESS_Rs, indicating that 100% of the MESS_T (32) messages sent in the last window were successfully received. Link L1 is considered to exceed THRESH. It is considered that the traffic weight value of link L1 increases to 0.2525, the traffic weight value of link L2 decreases to 0.560625, and the traffic weight value of link L3 decreases to 0.186875. 5. Link L1 receives a SYNC_ACK containing 32 MESS_Rs, indicating that 100% of the MESS_T (32) messages sent in the last window were successfully received. Link L1 exceeds THRESH. It is considered that the traffic weight value of link L1 increases to 0.37625, the traffic weight value of link L2 decreases to 0.4678125, and the traffic weight value of link L3 decreases to 0.1559375. 6. Link L1 remains normal and the traffic probability approaches its steady-state traffic probability.
B.<u style="single">Create a virtual private network transparently using a DNS proxy</u> The second improvement concerns the automatic creation of a virtual private network (VPN) in response to the domain name server lookup feature.
Traditional Domain Name Servers (DNS) provide a lookup function that returns the IP address of the requested computer or host. For example, when a computer user enters the web name "Yahoo.com", the user's web browser sends a request to DNS, which returns this web name to the user's browser and then to the destination website. Translated into a 4-split IP address used by the browser to contact.
This conventional method is shown in FIG. The user's computer 2501 includes a client application 2504 (eg, a web browser) and an IP protocol stack 2505. When the user enters the name of the destination host, a request DNS REQ (through IP protocol stack 2505) is made to DNS 2502 asking for a reference to the IP address associated with this name. DNS can return the IP address DNS RESP to the client application 2504 and use the IP address to communicate with host 2503 through separate transactions such as PAGE REQ and PAGE RESP.
In the traditional structure shown in FIG. 25, an unscrupulous listener on the Internet can intercept DNS REQ and DNS RESP packets and thus know what IP address the user is touching. For example, if a user wants to set up a secure communication path with a website named "Target.com" and the user's browser contacts DNS to find the IP address of that website. , The true IP address of the website will be revealed on the Internet as part of the DNS query. This hinders anonymous communication on the Internet.
One traditional method of providing a secure virtual private network over the Internet is to provide a DNS server with the public key of the machine to which the DNS server has an address. Therefore, the host can automatically search for the public key of the host of the communication partner so that the VPN can be set without having the user enter the public key of the destination host. Implementation of this standard is currently being developed as part of the FreeS / WAN project (RFC2535).
This conventional method has certain drawbacks. For example, any user can make a DNS request. In addition, DNS requests will have the same value for all users.
According to certain aspects of the invention, if a dedicated DNS server captures a DNS request and the request comes from a special type of user (eg, a user for whom a secure communication service is defined), the server It does not return the true IP address of the target node, but instead automatically configures a virtual private network between the target node and the user. VPNs are preferably performed using the IP address "hopping" feature of the basic invention described above, and even if packets in communication are intercepted, it is not possible to determine the true identity of the two nodes. It is carried out as follows. For DNS requests that are determined not to require secure services (for example, unregistered users), the DNS server makes the request transparent, provided that the requesting host has permission to resolve the insecure site. "Pass", provides normal lookup functionality, and returns the IP address of the target web server. Different users can provide different results if they make the same DNS request.
Figure 26 shows a system that uses the various principles summarized above. The user's computer 2601 includes a traditional client (eg, a web browser) 2605, and preferably an IP protocol stack 2606 that operates according to the IP hopping function 2607 outlined above. The modified DNS server 2602 includes the traditional DNS server function 2609 and DNS proxy 2610. The gatekeeper server 2603 is inserted between the modified DNS server and the secure target site 2604. The "insecure" target site 2611 is also accessible via the traditional IP protocol.
According to one aspect, the DNS proxy 2610 intercepts all DNS lookup functions from client 2605 to determine if access to a secure site has been requested. If access to a secure site is requested (as determined by, for example, domain name extension, or a reference to an internal table of such site), DNS Proxy 2610 will allow the user to access this site. Determine if you have sufficient security privileges. If you have sufficient security privileges, DNS Proxy 2610 sends a message to Gatekeeper 2603 asking you to create a virtual private network between user computer 2601 and secure target site 2604. In one embodiment, the gatekeeper 2603 creates a "hop block" used by computer 2601 and secure target site 2604 for secure communication. The gatekeeper 2603 then conveys these to the user computer 2601. The DNS proxy 2610 then forwards and resolves the address to the DNS proxy 2610 (this address may differ from the actual target computer) by the gatekeeper 2604, preferably using a secure management VPN. -Return to computer 2601. The returned address does not have to be the actual address of the destination computer.
When a user requests a reference to an insecure website such as Site 2611, the DNS proxy simply passes the reference request and sends it to the traditional DNS server 2609, where the request is processed as before and the insecure website. It is expected to return the IP address of 2611. If the user requests a secure website reference, but is unreliable to create such a connection, DNS Proxy 2610 returns an "unknown host" error to the user. In this way, different reference results are provided to different users requesting access to the same DNS name.
Gatekeeper 2603 may be implemented on a separate computer (as shown in Figure 26) or as a feature within the modified DNS server 2602. In general, the gatekeeper 2703 is expected to facilitate the distribution and exchange of information necessary for secure communication, such as by using "hopping" IP addresses. A secure host such as Site 2604 is assumed to have secure communication capabilities such as IP hopping feature 2608.
For convenience, it will be recognized that the functions of DNS Proxy 2610 and DNS Server 2609 can be combined into a single server. In addition, element 2602 is shown as a combination of the functionality of the two servers, but the two servers can operate independently.
Figure 27 shows the steps that DNS Proxy Server 2610 can take to handle a request for a DNS reference to a secure host. At stage 2701, a DNS lookup request is received for the target host. At stage 2702, a check is performed to determine if access to a secure host has been requested. If access to a secure host is not requested, at stage 2703, this DNS request is sent to traditional DNS server 2609, which refers to the IP address of the target site and further processes the user. Return to the application.
If access to a secure host is requested at stage 2702, further inspection is performed at stage 2704 to determine if the user is allowed to connect to that secure host. Such checks can be done by looking at the list stored inside the allowed IP addresses, or by communicating with the gatekeeper 2603 (eg, secure "management"). On the VPN). It will be recognized that different levels of security will be provided for different categories of hosts. For example, some sites may be designated as sites with a certain security level, and the security level of the user requesting access must match that security level. A user's security level can also be determined by sending a request message back to the user's computer asking them to prove that they have sufficient privileges.
If the user does not have permission to access the secure site, an "Unknown Host" message is returned (step 2705). If the user has sufficient security privileges, step 2706 establishes a secure VPN between the user's computer and a secure target site. As mentioned above, this is preferably done by distributing a hopping expression performed between the user's computer and a secure target site, preferably performed transparently to the user (ie). , The user does not have to be involved in creating a secure link). Any of the various fields can be "hopping" for secure communication, as described in various aspects of the application (eg, IP source / destination addresses, fields in headers, etc.).
The gatekeeper 2603 can embed some or all security features in the gatekeeper 2603 to handle all requests to connect to a secure site. In this embodiment, the DNS proxy 2610 communicates with the gatekeeper 2603 to determine if a user can access a particular website (preferably via a secure management VPN). Various scenarios for implementing these functions are described by the following examples.
<u style="single">Scenario # 1</u>:: The client has permission to access the target computer, and the gatekeeper has the rule of creating a VPN for the client. In this scenario, the client's DNS request is received by DNS proxy server 2610, which forwards this request to gatekeeper 2603. The gatekeeper establishes a VPN between the client and the requested target. The gatekeeper provides the DNS proxy with the destination address, and then the DNS proxy returns the resulting resolved name. The resolved address can be sent back to the client in a secure managed VPN.
<u style="single">Scenario # 2</u>:: The client does not have permission to access the target computer. In this scenario, the client's DNS request is received by DNS proxy server 2610, which forwards this request to gatekeeper 2603. The gatekeeper rejects the request and informs DNS proxy server 2610 that it could not find the target computer. DNS Proxy 2610 then returns an "Unknown Host" error message to the client.
<u style="single">Scenario # 3</u>:: The client has permission to connect using a regular non-VPN link, and the gatekeeper does not have the rule to set up a VPN for the client to the target site. In this scenario, the client's DNS request is received by the DNS proxy server 2610, which inspects this rule and determines that the VPN is useless. The gatekeeper 2603 then informs the DNS proxy server that it will forward this request to the traditional DNS server 2609, which resolves the request and returns the result to the DNS proxy server and back to the client. ..
<u style="single">Scenario # 4</u>:: The client does not have permission to establish a normal / non-VPN link, and the gatekeeper does not have the rule to create a VPN for the client to the target site. In this scenario, the DNS proxy server receives the client's DNS request and forwards it to gatekeeper 2603. Gatekeeper 2603 determines that no special VPN is needed, but the client is not authorized to communicate with non-VPN members. The gatekeeper rejects this request and causes DNS proxy server 2610 to return an error message to the client.
C.<u style="single">Bandwidth management from large links to small links</u> One feature of the basic structure is that it prevents so-called "denial of service" attacks that can occur when a computer hacker floods a known Internet node with packets, thus allowing the node to communicate with other nodes. Is the ability to prevent. Internet nodes are protected against floods targeting a single IP address because the IP address or other fields are "hopping" and packets arriving with an invalid address are immediately dropped.
Convinced in a system where a computer is coupled through a link with limited bandwidth (eg, an edge router) to a node (eg, an Internet service provider) that can support a link with much higher bandwidth. Hackers can take advantage of potential weaknesses. With reference to FIG. 28, assume that the first host computer 2801 communicates with the second host computer 2804 using the IP address hopping principle described above. The first host computer is coupled to the Internet Service Provider (ISP) 2803 via a low bandwidth link (LOW BW) through Edge Router 2802, and then a high bandwidth link through a portion of the Internet. It is attached to the second host computer 2804 via (HIGH BW). In this structure, ISPs can support high bandwidth for the Internet, but much less bandwidth for Edge Router 2802.
Suppose a computer hacker can send a large number of dummy packets addressed to the first host computer 2801 across the high bandwidth link HIGH BW. Normally, the host computer can reject these packets immediately because they do not enter the acceptance window allowed by the IP address hopping method. However, the packet must cross the low-bandwidth link LOW BW and therefore occupy this lower-bandwidth link before it is received by the host computer 2801. Therefore, the link to the host computer 2801 is effectively flooded before the packet can be dropped.
According to one improvement of the present invention, the "link guard" function 2805, which immediately discards a packet destined for a low bandwidth target node when it is not a valid packet, provides a high bandwidth node (a high bandwidth node ( For example, it is inserted in ISP2803). Each packet destined for a low bandwidth node is cryptographically authenticated to determine if it belongs to a VPN. If it is not a valid VPN packet, it will be dropped on the high bandwidth node. Packets are sent with higher priority if they are authenticated as belonging to a VPN. The packet is sent with a lower quality service (eg, lower priority) if it is a valid non-VPN packet.
In one embodiment, the ISP uses a packet protocol to distinguish between VPN packets and non-VPN packets. For IPSEC [rfc 2401], the packet has IP protocols 420 and 421. For TARP VPN, the packet has an undefined IP protocol. The ISP's link guard, 2805, maintains a valid VPN table that is used to verify that VPN packets are implicitly valid.
According to one embodiment, packets that do not fit within the hop window used by the node on the low bandwidth link are either rejected or sent with lower quality service. One way to do this is for both the high bandwidth node and the low bandwidth node to track the hopping packets (for example, when a valid packet is received, the high bandwidth node will open its hopping window. To provide a copy of the IP hopping table used by the low bandwidth node to the high bandwidth node. In such a scenario, the high bandwidth node discards packets that do not enter the hopping window before they are sent over the low bandwidth link. So, for example, ISP2903 maintains a copy 2910 of the receive table used by host computer 2901. Incoming packets that do not fit in this receive table are discarded. According to a different aspect, the link guard 2805 is a locked hash message authentication code (HMAC) [rfc. 2104] is used to validate each VPN packet. According to another aspect, separate VPNs (eg, using hop blocks) can be established for communication between the low bandwidth node and the high bandwidth node (ie, arrive at the high bandwidth node). Packets are translated into different packets before being sent to the low bandwidth node).
As shown in Figure 29, for example, the first host computer 2900 is communicating with the second host computer 2902 on the Internet, and the path is a high bandwidth link HIGH BW to ISP 2901 and Suppose it contains a low bandwidth link LOW BW via edge router 2904. According to the basic structure described above, the first host computer 2900 and the second host computer 2902 exchange hop blocks (or hop block algorithms) and match transmit and receive tables 2905, You can create 2906, 2912, and 2913. Then, according to the basic structure, the two computers send packets with an implicitly random IP source address and IP destination address, and each computer receives a valid packet. Moves the corresponding hopping window in its receive table.
Computers that are unscrupulous that packets with a range of IP addresses (for example, addresses 100 to 200 for simplicity) are being sent to the ISP 2901 and these packets are being forwarded over a low bandwidth link. Suppose the hacker 2903 can infer. Therefore, the hacker's computer 2903 has a low bandwidth link LOW for packets with addresses in the range 100-200. Those packets can be "flooded" in anticipation of being forwarded along the BW and thus occupying low bandwidth links. The fast packet rejection mechanism in the first host computer 3000 is almost useless in rejecting these packets. This is because the low bandwidth links are effectively congested before these packets are rejected. However, according to one aspect of the improvement, VPN Link Guard 2911 prevents this attack from affecting the performance of VPN traffic. This is because these packets are either rejected as invalid VPN packets or are provided with lower quality service than VPN traffic over links with relatively narrow bandwidth. However, denial of service flood attacks still block non-VPN traffic.
According to one aspect of the improvement, the ISP 2901 maintains a VPN separate from the first host computer 2900 and therefore has a different IP header before packets arriving at the ISP are sent to the host computer 2900. Convert to a packet with. The encryption key used to authenticate the VPN packet with Link Guard 2911 and the encryption key used to encrypt and decrypt the VPN packet with Host 2902 and Host 2901 can be different, and therefore Link Guard 2911. Does not have access to dedicated host data and can only authenticate these packets.
According to a third aspect, the low bandwidth node instructs the high bandwidth node to block all transmissions to a particular IP address so that only hopping packets are forwarded to the low bandwidth node. Message can be sent to high bandwidth nodes. This aspect prevents hackers from flooding packets that use a single IP address. According to a fourth aspect, a high bandwidth node is a packet sent to a low bandwidth node when the transmission rate exceeds a predetermined threshold of any given IP address. Can be configured to discard. This allows hopping packets to pass through. In this case, link guard 2911 can be used to detect that the rate of packets for a given IP address exceeds the threshold rate. Other packets addressed to the same IP address are either dropped or sent with a relatively low priority (for example, delayed).
D.<u style="single">Traffic limiter</u> In a system where multiple nodes communicate using "hopping" technology, an unscrupulous insider can internally flood the system with packets. To prevent this possibility, one improvement of the invention is to set up a "contract" between the nodes in the system so that the receiver can impose a bandwidth limit on each packet sender. Accompany. One technique for doing this is to delay the acceptance of checkpoint synchronization requests from the sender until a period of time has passed (eg, 1 minute). Each receiver can effectively adjust the speed at which the hopping window moves by delaying the "SYNC ACK" response to the "SYNC_REQ" message.
A simple modification of the checkpoint synchronizer can protect the receiver from accidental or intentional overload by an internal traitorous client. This fix is based on the receiver not updating the table until a SYNC_REQ for the hopping address CKPT_N is received. This can easily be done by delaying the generation of a new CKPT_N until the appropriate interval has elapsed since the previous checkpoint.
Suppose the receiver wants to limit the reception from the sender to 100 packets per second, and the checkpoint synchronization message is triggered every 50 packets. Appropriate senders issue new SYNC_REQ messages less than every 0.5 seconds. The receiver can delay the improper sender from synchronizing by delaying the issuance of CKPT_N for 0.5 seconds after the last SYNC_REQ is received.
In general, if M receivers need to limit the total number of N senders that issue a new SYNC_REQ message each time they receive W messages to R messages per second, then each receiver. Can delay the issuance of a new CKPT_N until M × N × W / R seconds have elapsed since the last SYNC_REQ was received and accepted. If the sender exceeds this rate between a pair of checkpoints, it issues this checkpoint before the receiver is ready to receive a new checkpoint, and SYNC_REQ is discarded by the receiver. After this, the transmitting side reissues SYNC_REQ every T1 second until SYNC_ACK is received. The receiver finally updates CKPT_N and SYNC_REQ is acknowledged. If the transmission speed significantly exceeds the permissible speed, the transmitting side stops until the transmission speed reaches an appropriate speed. If the transmitting side slightly exceeds the permissible speed, the synchronization is delayed several times until the transmitting speed reaches an appropriate speed, and then the synchronization is finally stopped. Hacking the sender's code that does not block can only cause the sender to lose the accept window. In this case, the transmitting side can recover the window and proceed with the operation only after the transmitting speed becomes an appropriate speed again.
Two practical issues must be considered when implementing the above method. 1. Due to statistical fluctuations in traffic arrival time and load balancing non-uniformity, the receiving speed must be slightly faster than the permissible speed. 2. The above algorithm may artificially reduce the bandwidth of the sender because the sender continues to transmit correctly for a period of time after the SYNC_REQ is transmitted. If the event causes the adapted sender to be unable to synchronize for a period of time (eg, the period during which the network discards SYNC_REQ or SYNC_ACK), the time that SYNC_REQ is accepted will be slower than expected. After this, the sender sends a smaller number of messages than expected before meeting the next checkpoint. The new checkpoint is not activated and the sender must resend SYNC_REQ. From the receiving side, this appears as if the transmitting speed of the transmitting side is inappropriate. Therefore, from the sender's point of view, the next checkpoint seems to be accepted late. This has the effect of reducing the permissible packet rate on the transmitting side until the transmitting side transmits at a packet rate slower than the agreed rate over a period of time.
To prevent this, the receiver keeps track of the number of times the last C SYNC_REQ was received and accepted, and the time to activate CKPT_N is M × N × W / after the last SYNC_REQ was received and received. R seconds later, 2 × M × N × W / R seconds after the SYNC_REQ following the last SYNC_REQ was received and accepted, and C × M after the (C-1) th SYNC_REQ was received from the last SYNC_REQ. The minimum value after × N × W / R seconds shall be used. This prevents the receiver from improperly limiting the packet speed of the sender if at least one of the last C SYNC_REQ is processed in the first attempt.
Figure 30 shows a system that uses the above principles. In FIG. 30, the two computers 3000 and 3001 are assumed to communicate over network N according to the "hopping" principle described above (eg, hopping IP address, discriminator value, etc.). For simplicity, the computer 3000 is referred to as the receiving computer and the computer 3001 is referred to as the transmitting computer. However, of course, full-duplex operation is assumed. Further, although only a single sender is shown, multiple senders may transmit to the receiver 3000.
As mentioned above, the receiving computer 3000 maintains a receiving table 3002 that includes a window W that defines a valid IP address pair that will be accepted when it appears in the incoming data packet. The sending computer 3001 maintains a transmission table 3003 for selecting the next IP address pair when sending a packet to the receiving computer 3000. (For illustration purposes, window W is also shown relative to transmission table 3003). As the sending computer navigates the table, it eventually generates a SYNC_REQ message, as shown in feature 3010. This message is a request from the receiver 3000 to synchronize the receive table 3002 where the sender 3001 expects a response of the form CKPT_N (included as part of the SYNC_ACK message). The sending computer 3001 generates a SYNC_REQ message faster than usual if it sends more messages than it is assigned. (If the sender has been modified to not generate a SYNC_REQ message, the sender cannot synchronize and was generated by the sender 3001 because the receiver 3000 immediately rejects packets that do not enter window W. Extra packets are dropped).
According to the improvements described above, the receiving computer 3000 performs a certain step when a SYNC_REQ message is received, as shown in FIG. At step 3004, the receiving computer 3000 receives the SYNC_REQ message. At stage 3005, an inspection is performed to determine if there are duplicate requests. If there are duplicates, the request is dropped at stage 3006. A check is performed to determine if the SYNC_REQ received from the sender 3001 in step 3007 is received at a speed that exceeds the permissible speed R (ie, the time cycle of the last SYNC_REQ message). The value R may be constant or may be varied as needed. If the speed exceeds R, at stage 3008, the next activation of the next CKPT_N hopping table entry is delayed by W / R seconds after the last SYNC_REQ is accepted.
If there are no duplicate requests, at step 3109, the next CKPT_N value is calculated and inserted into the receiving hopping table before the next SYNC_REQ from the sender 3101. The transmitting side 3101 then processes SYNC_REQ as usual.
E.<u style="single">Signaling synchronizer</u> Systems in which a large number of users communicate with a central node using secure hopping techniques require a large amount of memory for the hopping table and the data structures it supports. For example, if a website's million subscribers occasionally communicate with that website, the site must maintain a million hopping tables, and thus the system is actually in operation at any given time. Valuable computer resources are exhausted, even though only a small percentage of all subscribers use it. The preferred solution is a system that allows a maximum number of simultaneous links to be maintained, but "recognizes" millions of registered users at any given time. In other words, of the million registered users, thousands at a time communicate with the central server at the same time without having to keep the server with a million hopping tables of the right size. be able to.
One solution is to have a central node with two nodes, a signaling server that initiates sessions for users to log on and off (requires a minimal size table), and a relatively large one for users. It is to split into a transport server that contains a hopping table. The signaling server listens to millions of known users and rejects other (inappropriate) packets at high speed. When a packet is received from a known user, the signaling server activates a virtual-only link (VPL) between the user and the transport server to which the hopping table is assigned and maintained. When the user logs on to the signaling server, the user's computer is given a hopping table to communicate with the transport server and thus activate the VPL. The VPL may be detached when it has been inactive for a period of time, or it may be detached at user logout. Communication with a signaling server that allows users to log on and off can be done using the dedicated version of the checkpoint method described above.
Figure 31 shows a system that uses one of the above principles. In FIG. 31, the signaling server 3101 and the transport server 3102 communicate via a link. The signaling server 3101 includes a number of small tables 3106 and 3107 that contain enough information to authenticate communication requests to one or more clients 3103 and 3104. As described in detail below, these small tables are advantageous because they can be constructed as a special case of the synchronous checkpoint table described above . The transport server 3102 is preferably an independent computer that communicates with the signaling server 3101 and is a relatively small number of relatively large hopping tables 3108 that can be assigned to create a VPN with one client computer. , 3109, and 3110.
According to one aspect, a client who has already registered with the system (eg, through a system administration function, user registration procedure, or some other method) requests a computer (eg, a website) for information. Send. In one variant, this request is made using "hopping" packets, which causes the signaling server 3101 to immediately send invalid packets from an unauthorized computer such as the hacker computer 3105. Reject. A "managed" VPN can be established between all clients and the signaling server to prevent hackers from flooding signaling server 3101 with inappropriate packets. Details of this method are shown below.
The signaling server 3101 receives the request 3111 and uses it to determine that the client 3103 is an invalid registered user. The signaling server 3101 then issues a request to the transport server 3102 to allocate a hopping table (or hopping algorithm or other method) to create a VPN containing the client 3103. The assigned hopping parameters are returned to the signaling server 3101 (path 3113), which then feeds the hopping parameters in cryptographic form to the client 3103 via path 3114.
The client 3103 then communicates with the transport server 3102 using the conventional hopping techniques described above. Recognizing that the signaling server 3101 and the transport server 3102 are shown as two separate computers, and of course they may be combined into a single computer and these functions may be performed on this single computer. It is thought that it will be done. Alternatively, without departing from the principles of the present invention, the functionality shown in FIG. 31 can be subdivided differently from that shown.
One advantage of the above techniques is that the signaling server 3101 only needs to maintain a small amount of information about a large number of potential users and nevertheless from unauthorized users such as the hacker computer 3105. It retains the ability to immediately reject packets. Instead, the relatively large data tables needed to perform the hopping and synchronization functions are maintained within the transport server 3102, and these tables are relatively assigned only to the "active" links. A small number is sufficient. If the VPN is inactive for a period of time (for example, one hour), the transport server 3102 or signaling server 3101 can automatically disconnect the VPN.
Next, how to use a special case of the checkpoint synchronization function to implement the above-mentioned signaling method will be described in detail.
Signaling synchronizers are needed to support large numbers (millions) of fixed, low-bandwidth connections. Therefore, the signaling synchronizer must minimize VPL memory usage while providing security through hopping technology. To reduce memory usage on the signaling server, the data hopping table can be completely eliminated or the data can be carried as part of the SYNC_REQ message. The tables used by the server side (receiver side) and the client side (sender side) are outlined as element 3106 in Figure 31.
The meaning and behavior of CKPT_N, CKPT_O, and CKPT_R are the same as in the previous description, except that CKPT_N can receive a combination of data and SYNC_REQ messages or SYNC_REQ messages that do not contain data.
This protocol is an extension of the above-mentioned synchronizer as it is. Suppose the client sender is on and the table is synchronized. Initial tables can be generated "out of sync". For example, a client can log in to a web server to establish an account on the Internet. The client receives an encrypted key or the like on the Internet. Meanwhile, the server configures a signaling VPN on the signaling server.
Suppose the client application needs to send a packet to the server over the client's fixed signaling VPL.
1. The client sends a message marked as a data message on the inner header using the sender's CKPT_N address. The client turns off the sender and starts timer T1 indicating CKPT_O. The message may be one of three types, DATA, SYNC_REQ, and SYNC_ACK. Normal algorithms can prevent some potential problems by identifying each message type as part of an encrypted inner header field. In this algorithm, data and SYNC_REQ are sent at the same address, so it is important for the signaling synchronizer to distinguish between data packets and SYNC_REQ.
2. When the server receives a data message on its CKPT_N, it validates this message and forwards it along the stack. The message can be verified by inspecting the message type and other information (ie, user trust) contained in the inner header. The server replaces that CKPT_O with CKPT_N and generates the next CKPT_N. The server updates its sender CKPT_R to correspond to the client receiver CKPT_R and sends a SYNC_ACK with CKPT_O in its payload.
3. When the client receiver receives a SYNC_ACK on the CKPT_R with a payload that matches the sender CKPT_O and the sender is off, the sender is turned on and the receiver CKPT_R is updated. If the payload of SYNC_ACK does not match the sender CKPT_O or the sender is on, SYNC_ACK is simply discarded.
4. T1 expires: If the sender is off and the client's sender CKPT_O matches the timer-related CKPT_O, the sender restarts timer T1 indicating CKPT_O and uses the sender's CKPT_O address. SYNC_REQ is sent. In other cases, no action can be taken.
5. When the server receives SYNC_REQ on that CKPT_N, it replaces that CKPT_O with CKPT_N and generates the next CKPT_N. The server updates its sender CKPT_R to correspond to the client receiver CKPT_R and sends a SYNC_ACK with CKPT_O in its payload.
6. When the server receives SYNC_REQ on its CKPT_O, it updates its sender CKPT_R to correspond to the client's receiver CKPT_R and sends a SYNC_ACK containing CKPT_O in its payload.
Figure 32 shows a message flow that emphasizes this protocol. As you can see from top to bottom, the client uses its sender CKPT_N to send data to the server. The client sender is turned off and the retry timer is turned off. The client sender then loads CKPT_N into CKPT_O and updates CKPT_N. This message is successfully received and forwarded along the stack. This message also synchronizes the receiver, that is, the server loads CKPT_N into CKPT_O, generates a new CKPT_N, generates a new CKPT_R on the server sender, and sends a SYNC_ACK containing the server-side receiver CKPT_O. .. SYNC_ACK is successfully received by the client. The client receiver's CKPT_R is updated, the sender is turned on, and the retry timer is stopped. The client sender is ready to send a new data message.
The client then uses its sender CKPT_N to send data to the server. The client sender is turned off and the retry timer is turned off. The sender does not send the message as long as it is turned off. The client sender then loads CKPT_N into CKPT_O and updates CKPT_N. This message is lost. The client-side timer expires, resulting in a SYNC_REQ being sent over the client-sending CKPT_O (this is done until the client receives a SYNC_ACK). SYNC_REQ is successfully received by the client. SYNC_REQ synchronizes the receiver, that is, the server loads CKPT_N into CKPT_O, creates a new CKPT_N, generates a new CKPT_R on the server sender, and sends a SYNC_ACK containing the CKPT_O on the server receiver. SYNC_ACK is successfully received by the client. The client receiver's CKPT_R is updated, the sender is turned on, and the retry timer is stopped. The client sender is ready to send a new data message.
There are many other scenarios that follow this flow. For example, SYNC_ACK can be lost. The sender continues to resend SYNC_REQ until the receiver synchronizes and responds.
The above procedure allows the signaling server 3201 to authenticate the client with the signaling server while maintaining the ability to immediately reject invalid packets, such as those generated by the hacker computer 3205. In various aspects, the signaling synchronizer mimics the synchronizer. The signaling synchronizer provides the same protection as the hopping protocol and does this for many low bandwidth connections.
F. One-Click Secure Online Communication and Secure Domain Name Service The present invention provides a technique for establishing a secure communication link between a first computer and a second computer on a computer network. Preferably, the user communicates securely using a single mouse click, or a corresponding minimum input from another input device, such as a keystroke entered on the keyboard or a click entered through a trackball. Enable the link. Alternatively, the safety link is automatically established as the default setting when you start your computer (ie, no clicks). FIG. 33 is a computer network system block diagram 3300 to which the one-click secure communication method of the present invention is appropriate. In FIG. 33, a computer terminal such as a personal computer (PC) or a client computer 3301 is connected to a computer network 3302 such as the Internet through ISP3303. Alternatively, computer 3301 can connect to computer network 3302 through an edge router. The computer 3301 includes an input device such as a keyboard and / or a mouse, and a display device such as a monitor. Using a browser 3306 that is installed and runs on computer 3301 in a known way, computer 3301 still communicates with other computer 3304 connected to computer network 3302 via communication link 3305. Can be done.
Computer 3304 may be, for example, a server computer used to carry out electronic commerce. In situations where the computer network 3302 is the Internet, the computer 3304 usually has a standard top-level domain name such as .com, .net, .org, .edu, .mil, or .gov.
FIG. 34 is a flow diagram 3400 when a "one-click" secure communication link is installed and established on a computer network according to the present invention. At stage 3401, computer 3301 is connected to server computer 3304 over a non-VPN communication link 3305. The web browser 3306 displays the web page associated with the server 3304 in a known manner. According to one variant of the invention, the display of computer 3301 is a virtual private network (VPN) communication link ("go secure" hyperlink) between terminal 3301 and server 3304 through computer network 3302. ) Includes a hyperlink to select, or an icon representing the hyperlink. Preferably, the "go secure" hyperlink is displayed as part of a web page downloaded from the server computer 3304, thereby indicating that the entity providing server 3304 also implements VPN functionality.
The user of computer 3301 knows that the current communication link between computer 3301 and server computer 3304 is an unsecured non-VPN communication link by displaying a "go secure" hyperlink. At stage 3402, it is determined whether the user of computer 3301 has selected the "go secure" hyperlink. If not selected, processing resumes using an unsecured (traditional) communication method (not shown). If at stage 3402 it is determined that the user has selected a "go secure" hyperlink, the flow goes to stage 3403, where the VPN communication software module is installed on the computer 3301, related to the hyperlink. Judged by the object to be installed. Alternatively, the user can enter a "go secure" command on computer 3301.
If the object determines at stage 3403 that a software module is installed, the flow proceeds to stage 3407. If, at stage 3403, the object determines that the software module is not installed, the flow proceeds to stage 3404, where there is a known non-VPN between computer 3301 on computer network 3302 and website 3308. Communication link 3307 is started. Website 3308 is accessible from all computer terminals connected to computer network 3302 through a non-VPN communication link. After connecting to website 3308, you can download and install software modules that establish secure communication links on computer network 3302. The flow proceeds to stage 3405, where after the computer 3301 is connected to the website 3308, the software module that establishes the communication link is downloaded and installed as the software module 3309 on the computer terminal 3301 in a known manner. At stage 3405, the user can optionally select parameters for the software module to enable secure communication modes for communication for all communication links on computer network 3302. Then, at step 3406, the communication link between computer 3301 and website 3308 is terminated in a known manner.
A user of computer 3301 has enabled a secure communication mode of communication between computer 3301 and server computer 3304 by clicking the "go secure" hyperlink. According to a variant of the invention, the user only has to click on the "go secure" hyperlink. The user does not have to enter user identification information, a password, or an encryption key to establish a secure communication link. All steps required to establish a secure communication link between computer 3301 and server computer 3304 are transparent to the user of computer 3301.
At stage 3407, the secure VPN communication mode of operation is enabled and software module 3309 begins establishing the VPN communication link. In one aspect, software module 3309 automatically replaces the server 3304 top-level domain name in the browser 3406 with the server computer's secure top-level domain name. For example, if server 3304 has a top-level domain name of .com, software module 3309 replaces the .com top-level domain name with a .scom top-level domain name. In this case, "s" stands for secure. Alternatively, software module 3409 can replace the top-level domain name of server 3304 with another non-standard top-level domain name.
Because the secure top-level domain name is a non-standard domain name, queries to the Standard Domain Name Service (DNS) return a message stating that the URL is unknown. According to the present invention, software module 3409 includes a URL for querying the Safe Domain Name Service (SDNS) to obtain a URL for a secure top-level domain name. In this regard, software module 3309 accesses safety portal 3310, which connects safety network 3311 to computer network 3302. The secure network 3311 includes an internal router 3312, a secure domain name service (SDNS) 3313, a VPN gatekeeper 3314, and a secure proxy 3315. Secure networks can include email 3316, multiple chat rooms (only one chat room 3317 is shown), and other network services such as Standard Domain Name Service (STD DNS) 3318. Of course, the secure network 3311 may include other resources and services not shown in Figure 33.
If software module 3309 replaces the standard top-level domain name of server 3304 with a secure top-level domain name, software module 3309 is in step 3408, preferably using the management VPN communication link 3319, a secure portal. Send a query to SDNS3313 through 3310. In this configuration, the secure portal 3310 can only be accessed using a VPN communication link. Preferably, such a VPN communication link is a pseudo-random sequence; an IP address hopping method that pseudo-randomly changes the IP address in a packet sent between a client computer and a secure target computer; known. Periodic change of at least one field in a series of data packets according to the sequence of; in the header of each data packet compared to the table of valid IP addresses maintained in the table of the second computer. Internet Protocol (IP) address and / or source / destination IP address pair for each data packet selected according to the comparison of the address in the head of each data packet with the moving window of a reasonable IP address. It may be a technically based link that rejects data packets with IP addresses that are inserted and do not enter the moving window. Other types of VPNs can also be used. Security portal 3310 authenticates queries from software module 3309 based on the specific information hopping technology used for VPN communication link 3319.
SDNS3313 includes a cross-reference database of secure domain names and corresponding secure network addresses. That is, SDNS3313 stores the computer network address corresponding to the secure domain name for each secure domain name. The entity may register a secure domain name in SDNS3313 so that users who desire a secure communication link with the entity's website can automatically obtain the secure computer network address of this secure website. .. In addition, an entity can register multiple safety domain names, each representing a different priority level of access to a safety website in the access level hierarchy. For example, a stock exchange website may provide user-safe access so that a refusal to request a service from a website is invalidated for a user who subscribes to a secure website service. For example, various subscription levels can be set based on fees, thus allowing the user to select the desired guarantee level for connecting to a security securities trading website. When a user queries SDNS3313 for a secure computer network address on a stock exchange website, SDNS3313 determines a particular secure computer network address based on the user's ID and the user's subscription level.
At stage 3409, SDNS3313 accesses VPN gatekeeper 3314 when establishing a VPN communication link between software module 3309 and secure server 3320. Server 3320 can only be accessed via a VPN communication link. The VPN gatekeeper 3314 prepares for the computer 3301 and the secure web server computer 3320, or the secure edge router of the secure computer 3320, thereby creating a VPN. The secure server computer 3320 is the same server that has both the non-VPN communication link function and the VPN communication link function as shown by the server computer 3322, even if it is a server computer different from the server computer 3304. -It may be a computer. As you can see back in Figure 34, at step 3410, SDNS3313 returns a secure URL to software module 3309 for the .scom server address of secure server 3320, which corresponds to server 3304.
Alternatively, the SDNS3313 can be accessed "in the clear" through the security portal 3310, i.e., without using the management VPN communication link. In this situation, the secure portal 3310 preferably authenticates the query using a known technique, such as an encryption technique, before allowing the query to be sent to SDNS3319. Since the initial communication link in this situation is not a VPN communication link, the response to the query may be "plaintext". The querying computer can use the plaintext query to establish a VPN link with the desired domain name. Alternatively, the query to SDNS3313 may be in clear text, and SDNS3313 and the gatekeeper 3314 can act to establish a VPN communication link with the querying computer to send the response.
At stage 3411 the software module 3309 accesses the secure server 3320 through the VPN communication link 3321 based on the VPN resource assigned to the VPN gatekeeper 3314. At stage 3412, the web browser 3306 displays a secure icon indicating that the current communication link with the server 3320 is a secure VPN communication link. Further communication between the server 3301 and the computer 3320 is done over the VPN, for example using the "hopping" method discussed above. When the VPN link 3321 ends at stage 3413, the flow proceeds to stage 3414, where software module 3309 automatically replaces the secure top-level domain name with the corresponding unsafe top-level domain name on server 3304. Browser 3306 accesses standard DNS3325 to get the unsecured URL of server 3304. The browser 3306 then connects to the server 3304 by a known method. At stage 3415, browser 3306 displays a "go secure" hyperlink, or icon, for selecting a VPN communication link between terminal 3301 and server 3304. Again, by displaying a "go secure" hyperlink, the user knows that the current communication link is an unsecured non-VPN communication link.
When installing software module 3309 or when the user is offline, the user may optionally specify that all communication links established on computer network 3302 are secure communication links. it can. Therefore, whenever a communication link is established, the link is a VPN link. Therefore, software module 3309 transparently accesses SDNS3313 to obtain the URL of the selected secure website. In other words, in one aspect, the user does not have to "click" on the safety option each time he or she makes a secure communication.
In addition, the user of computer 3301 can arbitrarily select a secure communication link through proxy computer 3315. Therefore, computer 3301 can establish a VPN communication link 3323 with secure server computer 3320 through proxy computer 3315. Alternatively, computer 3301 can establish a non-VPN communication link 3324 with an unsafe website such as unsafe server computer 3304.
FIG. 35 shows a flow diagram 3500 when registering a safety domain name according to the present invention. At stage 3501, the requester visits website 3308 and logs in to the secure domain name registration service available through website 3308. At stage 3502, the requester completes an online registration form to register a secure domain name with a top-level domain name such as .com, .net, .org, .edu, .mil, or .gov. Of course, other secure top-level domain names may be used. Preferably, the requester must have already registered an unsafe domain name that corresponds to the equivalent secure domain name requested. For example, a requester attempting to register the secure domain name "website.scom" must already have the corresponding unsafe domain name "website.com" registered.
At stage 3503, the secure domain name registration service on website 3308 uses, for example, the standard DNS 3322, using a whois query to determine ownership information about the unsafe domain name that corresponds to the requested secure domain name. Query the insecure domain name server database of. At stage 3504, the secure domain name registration service on website 3308 receives a response from standard DNS 3322 and at stage 3505 determines if there is inconsistent ownership information for the corresponding unsafe domain name. If there is no inconsistent ownership information, the flow goes to stage 3507, if there is inconsistent ownership information, it goes to stage 3506, where the inconsistent ownership information is provided to the requester. The flow returns to stage 3502.
When there is no inconsistent ownership information in step 3505, the Secure Domain Name Registration Service (Website 3308) informs the requester that there is no inconsistent ownership information and validates the information entered in the online form. Prompt the requester to select an approved payment form. After confirming the information entered and the appropriate payment information, the flow proceeds to stage 3508, where the newly registered secure domain name is sent over communication link 3326 to SDNS3313.
In step 3505, if the requested secure domain name does not have a corresponding equivalent unsafe domain name, the invention informs the requester of this situation and, with respect to the increase in charges, the corresponding equivalent unsafe domain name. Encourage the requester to obtain. By accepting this offer, the invention will automatically register the corresponding equivalent unsafe domain name in standard DNS 3325 in a known manner. The flow then proceeds to stage 3508.
G. Tunneling secure address hopping protocol with existing protocol using web proxy The present invention also provides a technique for implementing the above-mentioned field hopping method in a client-side application program of a firewall between two computer networks and a server-side network stack of the firewall. The present invention uses a new secure disconnection protocol that properly denies the denial of service function by forming this protocol layer on top of existing IP protocols such as the ICMP protocol, UDP protocol, and TCP protocol.
According to the present invention, communication is protected by a client-side proxy application program that accepts unencrypted and unprotected communication packets from a local browser application. The client-side proxy application program tunnels unencrypted and unprotected communication packets with a new protocol, thereby protecting the communication from server-side denial of service. Of course, unencrypted and unprotected communication packets may be encrypted prior to tunneling.
The client-side proxy application program is not an operating system extension and does not require modification of the operating system network stack and drivers. Therefore, clients are easier to install, remove, and maintain than VPNs. In addition, client-side proxy applications can pass through the joint firewall using much smaller "holes" in the firewall, which is less likely to be a security risk than passing a protocol-tier VPN through the joint firewall. ..
The server-side implementation of the present invention, similar to a standard virtual dedicated network, authenticates field-hopping valid packets as valid or invalid at a very early stage of server packet processing, and normal TCP. / Minimizes the impact of requesting and denying services compared to IP and HTTP communications, thereby protecting the server from invalid communications.
FIG. 36 is a system block diagram of a computer network 3600, where the virtual private connection according to the invention can be configured to more easily cross a firewall between two computer networks. FIG. 37 is a flow diagram 3700 when establishing a virtual dedicated connection encapsulated by using an existing network protocol.
In Figure 36, a local area network (LAN) 3601 is connected to another computer network 3602, such as the Internet, through firewall configuration 3603. The firewall configuration works in a known way to interconnect LAN3601 and computer network 3602 and protect LAN3601 from attacks initiated outside LAN3601.
The client 3604 is connected to the LAN 3601 by a known method. The client computer 3604 includes an operating system 3605 and a web browser 3606. The operating system 3605 provides the kernel mode function that runs the client computer 3604. Browser 3606 is an application program that accesses computer network resources connected to LAN 3601 and computer network 3602 in a known manner. According to the present invention, a proxy application 3607 is also stored on the client computer 3604, which works with the browser 3606 at the application layer. Proxy application 3607 runs at the application tier within client computer 3604 and, when enabled, forms a virtual private connection between client computer 3604 connected to LAN3601 or computer network 3602 and server computer. Modify the unprotected and unencrypted message packet generated by the browser 3606 by inserting data into the message packet used to do so. According to the present invention, a virtual-only connection does not provide the same level of security for a client computer as a virtual-only network. Virtual-only connections can conveniently authenticate, for example, to quickly reject a denial of a service attack, thereby providing different levels of service that a user can subscribe to.
The proxy application 3607 runs at the application layer within the client computer 3604 and is conveniently installed and uninstalled by the user. During installation, the proxy application 3607 preferably configures the browser 3606 to use the proxy application for all web communications. That is, the payload portion of every message packet is modified with data to form a virtual-only connection between the client computer 3604 and the server computer. Preferably, the data for forming the virtual private connection includes the field hopping data described above in connection with the VPN. Alternatively, the modified message packet can match the TCP / IP or ICMP protocol. Alternatively, the proxy application 3606 can be selected and enabled, for example by an option provided by the browser 3606. In addition, the proxy so that the data for forming a virtual-only connection between the client computer 3604 and the specified host computer modifies only the payload portion of the specially specified message packet. Application 3607 can be enabled. The specially specified message packet may be, for example, a given given domain name of choice.
As can be seen in Figure 37, at stage 3701, browser 3606 generates an unprotected and unencrypted message packet. At stage 3702, proxy application 3607 removes the payload portion of all message packets by tunneling data to the payload portion to form a virtual-only connection between the client computer 3604 and the destination server computer. Fix it. At stage 3703, the modified message packet is sent from client computer 3604 on computer network 3602, for example to website (server computer) 3608.
Website 3608 includes a VPN guard section 3609, a server proxy section 3610, and a web server section 3611. VPN Guard 3609 is embedded within the kernel layer of Website 3608's operating system so that large bandwidth attacks on Website 3608 can be quickly rejected. When client computer 3604 initiates an authenticated connection with website 3608, VPN guard 3609 is tuned by the hopping sequence contained in the message packet from client computer 3604, thereby in step 3704. Performs strong authentication of client packet streams entering website 3608. The VPN guard unit 3609 can be configured to perform various levels of authentication depending on the service level to which it is subscribed, and thus to provide various levels of quality. That is, the VPN guard unit 3609 passes all message packets until a service attack rejection is detected, and if rejected, it matches a hopping sequence such as the adjusted hopping sequence of the present invention. It can be configured to allow only client packet streams.
The server proxy section 3610 also runs at the kernel layer within website 3608 and captures incoming message packets from client computer 3604 at the VPN level. At stage 3705, the server proxy section 3610 authenticates the message packet at the kernel level in the host computer 3604 using the IP address, UDP port, and discriminator fields. The authenticated message packet is then forwarded to the web server unit 3611 as a normal TCP web transaction.
At step 3705, the web server unit 3611 responds to the message packet received from the client computer 3604 by generating a response message packet according to the particular nature of the message packet. For example, when a client computer requests a web page, the web server unit 3611 generates a message packet corresponding to the requested web page. At stage 3706, the response message packet passes through the server proxy section 3610, which forms a virtual-only connection between the host computer 3608 and the client computer 3604 on computer network 3602. The data used for is inserted into the payload part of the message packet. Preferably, the data for forming the virtual private connection includes field hopping data as described above in connection with VPN. The server proxy section 3610 operates at the kernel layer in the host computer so as to insert virtual dedicated connection data into the payload section of the response message packet. Preferably, the modified message packet sent by the host computer 3608 to the client computer 3604 follows the UDP protocol. Alternatively, the modified message packet may follow the TCP / IP or ICMP protocol.
At stage 3707, the modified packet is sent from host computer 3608 on computer network 3602 and passes through firewall 3603. After passing through the firewall 3603, the modified packet is sent over LAN3601 to client computer 3604 and at stage 3708, received by proxy application 3607 at the application layer within client computer 3604. The proxy application 3607 acts to quickly evaluate the modified message packet and decide whether to accept or discard the received packet. If the virtual-only connection data inserted in the received information packet matches the expected virtual-only connection data, the received packet is accepted. If they do not match, the received packet is dropped.
Although the present invention has been described in the context of the illustrated embodiments, it is believed and understood that modifications can be made without departing from the true spirit and scope of the invention.
42 sheets
Sheet 1 Sheet 2 Sheet 3 Sheet 4 Sheet 5 Sheet 6 Sheet 7 Sheet 8 Sheet 9 Sheet 10 Sheet 11 Sheet 12 Sheet 13 Sheet 14 Sheet 15 Sheet 16 Sheet 17 Sheet 18 Sheet 19 Sheet 20 Sheet 21 Sheet 22 Sheet 23 Sheet 24 Sheet 25 Sheet 26 Sheet 27 Sheet 28 Sheet 29 Sheet 30 Sheet 31 Sheet 32 Sheet 33 Sheet 34 Sheet 35 Sheet 36 Sheet 37 Sheet 38 Sheet 39 Sheet 40 Sheet 41 Sheet 42
Every citation, both ways
| Document | Relation | Office | Cited during |
|---|---|---|---|
| EP0814589A2 | Cites | European Patent Office (EPO) | Search report |
| EP0814589A2 | Cites | European Patent Office (EPO) | Examiner |
| EP0838930A2 | Cites | European Patent Office (EPO) | Search report |
| EP0838930A2 | Cites | European Patent Office (EPO) | Examiner |
| JP2003527799A | Cites | Japan | Examiner |
| JP2003527799A | Cites | Japan | Search report |
| GB2317792A | Cites | United Kingdom | Search report |
| GB2317792A | Cites | United Kingdom | Examiner |
| GB2340702A | Cites | United Kingdom | Examiner |
| GB2340702A | Cites | United Kingdom | Search report |
| US5588060A | Cites | United States of America | Examiner |
| US5588060A | Cites | United States of America | Search report |
| US5689566A | Cites | United States of America | Examiner |
| US5689566A | Cites | United States of America | Search report |
| WO9827783A1 | Cites | World Intellectual Property Organization (WIPO) | Examiner |
| WO9827783A1 | Cites | World Intellectual Property Organization (WIPO) | Search report |
| WO9855930A1 | Cites | World Intellectual Property Organization (WIPO) | Search report |
| WO9855930A1 | Cites | World Intellectual Property Organization (WIPO) | Examiner |
| JPN6010023143; 高田 学也: 'クラッカ対策に米国ベンダーが本腰 追跡ツール、安全の高いDNSソフトが登場' 日経コミュニケーション 第257号, 19971113, p.87 | Non-patent | – | Search report |
| JPN6010023143; 高田 学也: 'クラッカ対策に米国ベンダーが本腰 追跡ツール、安全の高いDNSソフトが登場' 日経コミュニケーション 第257号, 19971113, p.87 | Non-patent | – | Examiner |
222 members in 9 offices
Priority claims2
| Document | Office | Kind | Date |
|---|---|---|---|
| 09558209 | United States of America | – | |
| 55820900 | United States of America | A |
Members222
| Document | Office | Kind | |
|---|---|---|---|
| CA2349519A1 | Canada | A1 | |
| CA2349520A1 | Canada | A1 | |
| CA2723504A1 | Canada | A1 | |
| WO0027086A2 | World Intellectual Property Organization (WIPO) | A2 | |
| WO0027090A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU1455300A | Australia | A | |
| AU1600300A | Australia | A | |
| WO0027086A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO0027090A3 | World Intellectual Property Organization (WIPO) | A3 | |
| WO0027090A9 | World Intellectual Property Organization (WIPO) | A9 | |
| EP1125414A2 | European Patent Office (EPO) | A2 | |
| EP1125419A2 | European Patent Office (EPO) | A2 | |
| WO0161922A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU3812301A | Australia | A | |
| WO0186911A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU5914101A | Australia | A | |
| WO0192997A2 | World Intellectual Property Organization (WIPO) | A2 | |
| AU5914001A | Australia | A | |
| JP2002529779A | Japan | A | |
| JP2002529965A | Japan | A | |
| WO0192997A3 | World Intellectual Property Organization (WIPO) | A3 | |
| US2002161884A1 | United States of America | A1 | |
| US2002161925A1 | United States of America | A1 | |
| US6502135B1 | United States of America | B1 | |
| WO0186911A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1284079A2 | European Patent Office (EPO) | A2 | |
| US2003037142A1 | United States of America | A1 | |
| WO0161922A3 | World Intellectual Property Organization (WIPO) | A3 | |
| EP1302047A2 | European Patent Office (EPO) | A2 | |
| EP1305914A2 | European Patent Office (EPO) | A2 | |
| AU761388B2 | Australia | B2 | |
| US2003167342A1 | United States of America | A1 | |
| US6618761B2 | United States of America | B2 | |
| JP2003527799A | Japan | A | |
| AU765914B2 | Australia | B2 | |
| JP2003535560A | Japan | A | |
| US2004003116A1 | United States of America | A1 | |
| JP2004507909A | Japan | A | |
| US2004098485A1 | United States of America | A1 | |
| US2004103205A1 | United States of America | A1 | |
| US2004107285A1 | United States of America | A1 | |
| US2004107286A1 | United States of America | A1 | |
| US6826616B2 | United States of America | B2 | |
| US6834310B2 | United States of America | B2 | |
| US6839759B2 | United States of America | B2 | |
| US6907473B2 | United States of America | B2 | |
| EP1542429A1 | European Patent Office (EPO) | A1 | |
| EP1284079B1 | European Patent Office (EPO) | B1 | |
| US7010604B1 | United States of America | B1 | |
| DE60116754D1 | Germany | D1 | |
| US2006123134A1 | United States of America | A1 | |
| DE60116754T2 | Germany | T2 | |
| US7133930B2 | United States of America | B2 | |
| EP1755307A2 | European Patent Office (EPO) | A2 | |
| EP1755315A2 | European Patent Office (EPO) | A2 | |
| US7188180B2 | United States of America | B2 | |
| JP3923312B2 | Japan | B2 | |
| US2008005792A1 | United States of America | A1 | |
| US2008034201A1 | United States of America | A1 | |
| US2008040783A1 | United States of America | A1 | |
| US2008040791A1 | United States of America | A1 | |
| US2008040792A1 | United States of America | A1 | |
| US7418504B2 | United States of America | B2 | |
| US2008216168A1 | United States of America | A1 | |
| US2008222415A1 | United States of America | A1 | |
| US7490151B2 | United States of America | B2 | |
| EP1125419B1 | European Patent Office (EPO) | B1 | |
| AT441275T | Austria | T | |
| ATE441275T1 | Austria | T1 | |
| DE69941338D1 | Germany | D1 | |
| JP2010063126A | Japan | A | |
| JP4451566B2 | Japan | B2 | |
| EP2197176A1 | European Patent Office (EPO) | A1 | |
| EP1755315A3 | European Patent Office (EPO) | A3 | |
| EP1755307A3 | European Patent Office (EPO) | A3 | |
| EP1125414B1 | European Patent Office (EPO) | B1 | |
| AT492973T | Austria | T | |
| ATE492973T1 | Austria | T1 | |
| DE69943057D1 | Germany | D1 | |
| EP2290904A1 | European Patent Office (EPO) | A1 | |
| US7921211B2 | United States of America | B2 | |
| EP2312808A1 | European Patent Office (EPO) | A1 | |
| US7933990B2 | United States of America | B2 | |
| CA2349520C | Canada | C | |
| US7945654B2 | United States of America | B2 | |
| EP2323335A2 | European Patent Office (EPO) | A2 | |
| JP2011109651AThis record | Japan | A | |
| EP2330801A1 | European Patent Office (EPO) | A1 | |
| JP2011124985A | Japan | A | |
| US2011167087A1 | United States of America | A1 | |
| US7987274B2 | United States of America | B2 | |
| US2011185053A1 | United States of America | A1 | |
| US2011185169A1 | United States of America | A1 | |
| US2011191582A1 | United States of America | A1 | |
| CA2349519C | Canada | C | |
| US7996539B2 | United States of America | B2 | |
| JP4756811B2 | Japan | B2 | |
| JP2011182427A | Japan | A | |
| US2011225419A1 | United States of America | A1 | |
| JP2011193477A | Japan | A |
19 legal events, as the office reported them to INPADOC
Over the term
Point at a mark for the eventEvents
| Event | Code | |
|---|---|---|
| Cancellation because of completion of termEXPY | EXPY | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Receipt of annual feesJAPANESE INTERMEDIATE CODE: R250R250 | R250 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| Certificate of patent or registration of utility modelJAPANESE INTERMEDIATE CODE: R150R150 | R150 | |
| First payment of annual fees (during grant procedure)JAPANESE INTERMEDIATE CODE: A61A61 | A61 | |
| Written decision to grant a patent or to grant a registration (utility model)JAPANESE INTERMEDIATE CODE: A01A01 | A01 | |
| Decision of grant or rejection writtenTRDD | TRDD | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 | |
| Written amendmentJAPANESE INTERMEDIATE CODE: A523A521 | A521 | |
| Written permission of extension of timeJAPANESE INTERMEDIATE CODE: A602A602 | A602 | |
| Written request for extension of timeJAPANESE INTERMEDIATE CODE: A601A601 | A601 | |
| Notification of reasons for refusalJAPANESE INTERMEDIATE CODE: A131A131 | A131 |
Numbers
- Publication
- 2011109651
- Application
- 239225
Titles2
- Japanese
- 保証されたシステム可用性を有する安全通信用のアジル・ネットワーク・プロトコルの改良
- English
- Improvements to the Azil Network Protocol for secure communications with guaranteed system availability
Classification
- CPC, 17
- H04L63/162
- H04L45/24
- H04L45/28
- H04L61/35
- H04L63/0272
- H04L63/029
- H04L63/0414
- H04L63/1458
- H04L63/1491
- H04L63/164
- H04L63/166
- H04L61/45
- H04L61/5007
- H04L61/5076
- H04L61/00
- H04L61/5092
- H04L2101/604
- IPC, 8
- H04L12 22
- G09C1 00
- H04L9 08
- H04L9 06
- H04L9 28
- H04L12 66
- H04L45 24
- H04L45 28