JP5804439B2 - Ｉｄ／ロケータ分離ベースのネットワークにおいてネームレジストリ，ネットワークアクセスおよびデータ通信を安全に行う方法 - Google Patents

Description

本発明により，ＩＤ／ロケータ分離の概念に基づいた新世代ネットワークが安全なものとなる。より詳しく説明すると，（ａ）ホストのホスト名，ホストＩＤ，ロケータ，セキュリティキー，およびその他のパラメータ，を保存するネームレジストリ（ｂ）ネットワークアクセス，および（ｃ）ホスト間通信，のためのセキュリティ・メソッドである。

インターネットサービスを安全に行うために使用されてきた以下の既存の技術は，本発明に関連している。

ＤＮＳＳＥＣ（Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ Ｓｅｃｕｒｉｔｙ Ｅｘｔｅｎｓｉｏｎｓ）は，ＤＮＳサーバのグローバルシステムにおいて，ドメイン名，ＩＰアドレスおよび他のパラメータを安全に保存するために用いられる（［ＤＮＳＳＥＣ］）。そして，階層信頼モデルを使用することによって，ＤＮＳＳＥＣは，前記サーバからＤＮＳレコードを要求しているホストに前記ＤＮＳレコードを安全に送信できるという保証を提供する。それにより，ＤＮＳレコードの完全性，すなわち，ネットワークを介して送信される際に，盗聴者がこれらのレコードを変更することはできないということ，が保護されている。

ＩＰｓｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）は，現在のインターネットにおいて，ＩＰ層の接続を保護するためのセキュリティ機構である（［ＩＰｓｅｃ］）。ＩＰｓｅｃは，データパケット内のＩＰヘッダとペイロードの両方の完全性を保護する，すなわち，パケットの受信側が，盗聴者によってこれらのパケットが変更されていないことを検証することができる。

しかし，ＩＰｓｅｃは，ＩＤ／ロケータ分離に基づく新世代ネットワークには正しく適用されない。このネットワークは，異なるタイプのネットワーク層プロトコルを使用できるヘテロジニアスネットワークの異なる部分をパケットが横断する際に，ＩＰヘッダの変更を必要とするためである。

特開２００８−３１２１９１号公報には，ＩＤ／ロケータ分離に基づく新世代ネットワークアーキテクチャの基本的な概念アーキテクチャについて記載されている。これは，ゲートウェイ，ホスト（すなわちノード）とネームサーバ，およびそれらの相互作用などの異なったコンポーネントの機能を開示している。

特開２００８−３１２１９１号公報には，ノード名すなわちホスト名とＩＤを形成するための方法，ＩＤ／ロケータ分離ネットワークアーキテクチャのプロトコルスタック，ＩＤ／ロケータ分離ベースの通信初期化プロセス，ＩＤ／ロケータ分離をサポートしている階層ネットワーク構造について記載されている。

ホストＩＤでもロケータでもあるＩＰアドレスの多重化されたセマンティクスによって引き起こされる問題を解消するために，ネットワークアーキテクチャにＩＤ／ロケータ分離の概念を導入する様々なアプローチについて近年議論されてきた。ＩＤ／ロケータ分離アーキテクチャは，ホストＩＤとロケータに対する値の別個のセットを使用しており，それらのマッピングは，複数のマッピングサーバに保存されている。ロケータ／ＩＤ分離プロトコル（ＬＩＳＰ）［ＬＩＳＰ］は，ＢＧＰルーティングテーブルの増加率とバックボーンネットワークにおける経路更新頻度を減らすために，エッジルータにＩＤ／ロケータ分離を導入している。ホストアイデンティティプロトコル（ＨＩＰ）［ＨＩＰ］は，セッションの確立とモビリティ機能を安全にするために，ホストプロトコルスタックにおいてＩＤ／ロケータ分離を適用している。同様に，Ｓｈｉｍ６［Ｓｈｉｍ６］は，ホストがマルチホーミングをサポートできるように，ＩＤ／ロケータを適用している。上記の各プロトコルは，現在のインターネットの特定の問題（すなわちルーティングの拡張性，安全なモビリティ，およびマルチホーミング）に取り組もうとする一方で，ＨＩＭＡＬＩＳ（Ｈｅｔｅｒｏｇｅｎｅｉｔｙ Ｉｎｃｌｕｓｉｏｎ ａｎｄ Ｍｏｂｉｌｉｔｙ Ａｄａｐｔａｔｉｏｎ ｔｈｒｏｕｇｈ Ｌｏｃａｔｏｒ ＩＤ Ｓｅｐａｒａｔｉｏｎ）［ＨＩＭＡＬＩＳ］は，モビリティ，マルチホーミング，拡張性のあるルーティングおよびネットワーク層でのヘテロジニアスのプロトコルをよりよくサポートすることができる，ＩＤ／ロケータ分離のコンセプトに基づいた一般的なアーキテクチャを提案する。これらの提案は，ネットワークにパケットを転送した際に指定された名前やＩＤに対応するロケータを見つけるために，ＩＤ／ロケータマッピングデータを取得する必要がある。これらは，ホストが，（移動が原因で）ロケータを変更した，または（マルチホーミングが原因で）新しいロケータを追加した時に，マッピングデータを更新する必要がある。ドメインネームシステム（ＤＮＳ）は，動的マッピングデータのこの種の高速な更新には適していない。ＤＮＳサーバ［ＤＮＳ２］のグローバルシステムにキャッシュされたデータの複数のコピーが存在するためである。

それゆえに，動的ホストのＩＤ／ロケータマッピングデータを保存するためには，ＤＮＳサーバに加えて，追加のサーバが必要となる。このため，前記文献においては，例えば，ＬＩＳＰのためのＡＬＴ［ＡＬＴ］，ＨＩＰのためのランデブーサーバ，ＨＩＭＡＬＩＳのためのホスト名の登録，が提案されている。しかし，これらの提案には，更新および取得手続きを一括して保護するためのセキュリティ機能が内蔵されていない。この特許出願は，前記システムを安全にする方法について規定している。

ＨＩＰは，ホスト間の安全なセッションを確立するために，証明書と公開鍵を使用しているが，ＩＤ／ロケータマッピングの更新，取得，ネットワークアクセスプロセスのセキュリティをカバーしてはいない。ＤＮＳセキュリティ［ＤＮＳＳＥＣ］は，ドメインレコードを安全に配布し，または取得するために，証明書と公開鍵を使用するが，レコードの頻繁な更新には適していない。

前述したように，ＤＮＳＳＥＣ［ＤＮＳＳＥＣ］は，ＤＮＳサーバが構成するグローバルシステムにおいて，ドメイン名，ＩＰアドレス，または他のパラメータのレコードを安全に保存するために使用される。しかし，ＤＮＳは，モバイルデバイスをサポートするために，レコードを頻繁に更新するのには適していない。

同様に，ＩＰｓｅｃは，ＩＤ／ロケータ分離に基づく新世代ネットワークに正しく適用されない。このネットワークは，異なるタイプのネットワーク層プロトコルを使用できるヘテロジニアスネットワークの異なる部分をパケットが横断する際に，ＩＰヘッダの変更を必要とするためである。それゆえに，新世代ネットワークにおいては，ペイロードまたはデータパケットは，識別層に実装された新しい機能によって保護されるべきである。言い換えれば，識別層は，セキュリティパラメータを折衝することや，認証データまたは事前に折衝したセキュリティパラメータを用いて計算された完全性チェック値を入れるためにパケットにおけるＩＤヘッダを使用することによって，パケットを保護するための機能を有するべきである。パケットの受信側は，パケットがネットワーク上で変更されていないことを確認するために，ＩＤヘッダに含まれる完全性チェック値を検証する。それゆえ，この目的のために，我々はＩＤｓｅｃ機構を発明した。

上述の問題点は，特許請求の範囲に記載された発明によって解決される。

本発明の第一の側面は，インターネットネットワークシステム１におけるホスト名解決ための方法に関する。本システムは，送信元ホスト（ＳＨ）１２，第一ゲートウェイ（ＧＷ）１３およびローカルネームサーバ（ＬＮＳ）１４を備える，第一エッジネットワーク１１と，ドメインネームレジストリ（ＤＮＲ）２２とホストネームレジストリ（ＨＮＲ）２３を備える，論理制御ネットワーク２１と，第一エッジネットワーク１１または第２エッジネットワーク３２におけるターゲットホスト（ＴＨ）３１と，第一エッジネットワーク１１，論理制御ネットワーク２１，および第二エッジネットワーク３２と接続するためのルータ４２を含む，グローバルトランジットネットワーク４１と，を備えている。

ホスト名解決の方法は，以下のステップを含む。

ＳＨ１２は，ＴＨ３１のホスト名を知っており，ＴＨのＩＤ，ＴＨのロケータ，ＴＨの公開鍵（ＰＫ）が一つ以上得られるよう，ＴＨ３１のホスト名を含むホスト名解決クエリをＬＮＳ１４へ送信する。

ＬＮＳ１４は，ホスト名解決クエリを受信し，その後，ＴＨ３１が第一エッジネットワーク１１にあるか否かを検証する。

ＬＮＳ１４は，ＴＨ３１が第一エッジネットワーク１１に位置していると判断できない場合には，ＴＨ３１のホスト名が含まれる第一のクエリをＤＮＲ２２に送信する。

ＤＮＲ２２は，第一のクエリを受信し，その後，第一の応答をＬＮＳ１４へ送信する。ここで，第一の応答には，ＨＮＲのＩＤ，ＨＮＲのロケータ，およびＨＮＲのＰＫを含む，ＨＮＲの情報が含まれている。前記応答には，ルートＤＮＲからのＤＮＲの認証チェーン，ＤＮＲのＰＫ，およびＤＮＲの秘密鍵を使用して作成されたＤＮＲの署名を含んでいてもよい。

ＬＮＳ１４は，第一の応答を受信し，その後，ＨＮＲの情報を使用して，第二のクエリをＨＮＲ２３へ送信する。第二のクエリは，ＴＨのＩＤ，ＴＨのロケータおよびＴＨのＰＫをＬＮＳ１４に提供することをＨＮＲ２３に要求する。

ＨＮＲ２３は，第二のクエリを受信し，その後，第二の応答をＬＮＳ１４へ送信する。第二の応答は，ＴＨのＩＤ，ＴＨのロケータおよびＴＨのＰＫを含んでいる。また，ＨＮＲの秘密鍵を使用して作成されたＨＮＲの署名を含んでいてもよい。

ＬＮＳ１４は，第二の応答を受信し，ＨＮＲのＰＫを用いて第二の応答メッセージの真正性を検証するための機能を実行する。検証では，ＨＮＲのＰＫだけでなく，ＤＮＲの認証チェーンを使用することが好ましい。

検証結果が可である場合には，ＬＮＳ１４はホスト名解決応答をＳＨ１２に送信する。前記応答には，ＴＨのＩＤ，ＴＨのロケータおよびＴＨのＰＫが含まれる。

ＳＨ１２は，ホスト名解決応答において，ＴＨのＩＤ，ＴＨのロケータおよびＴＨのＰＫを受信する。

第一の側面の好ましい実施形態は，ＨＮＲのＩＤとＨＮＲのロケータをＨＮＲの情報に含めることである。ＨＮＲの情報は，ＨＮＲのＰＫをさらに含んでもよい。
第一の応答は，ＤＮＲのＰＫ，ＤＮＲの秘密鍵を使用して作成したＤＮＲの署名をさらに備え，ＤＮＲのＰＫおよびＤＮＲの署名は，ＤＮＲからの第一の応答を検証することに使用される。ＨＮＲのＰＫは，ＨＮＲ２３からの第二の応答を検証するために使用される。

第一の側面の別の好ましい実施形態は，第一エッジネットワーク１１が，認証エージェント（ＡＡ）１５および動的ホスト構成プロトコルサーバ（ＤＨＣＰ）１６と，をさらに備えることである。

第一ゲートウェイ（ＧＷ）１３，ＬＮＳ１４およびＡＡ１５は，それらの間で交換されるメッセージを保護するために使用されるペアワイズ共有鍵である，ＡＡ−ＧＷｓｈＫｅｙ，ＡＡ−ＬＮＳｓｈＫｅｙとＬＮＳ−ＧＷｓｈＫｅｙを有する。

前記方法は，ＳＨ１２がホスト名解決クエリを送信する前に，ＳＨ自身のＬＬｏｃ，第一ＧＷのＩＤとＬＬｏｃ，ＬＮＳのＩＤとＬＬｏｃ，ＡＡのＩＤとＬＬｏｃと，をＤＨＣＰから取得するための初期設定ステップ（Ｓ２０１）と，第一エッジネットワークにおいて前記ＳＨを認証するための認証ステップ（Ｓ２０２）と，第一ＧＷ１３とＬＮＳ１４に登録された，ＳＨのホスト名，ＩＤ，ＰＫおよびＬＬｏｃを作成するためのローカル登録ステップ（Ｓ２０３）と，ＨＮＲにおいて前記ＳＨのロケータを更新するためのＨＮＲ更新ステップ（Ｓ２０４）と，をさらに備えていてもよい。

認証ステップ（Ｓ２０２）は，初期設定ステップ（Ｓ２０１）の後に実行されるステップである。このステップでは，ＳＨ１２は，第一のホスト登録要求をＡＡ１５に送信する。ここで第一のホスト登録要求は，ＳＨのホスト名，ＳＨのＩＤ，ＳＨのＰＫ，およびＳＨ１２がサポートしている完全性チェックアルゴリズムのリストを含む。
ＡＡ１５は，第一のホスト登録要求を受信し，その後，ＨＮＲからＳＨのＩＤとＰＫを取得するために，請求項１に記載されたホスト名解決を同様に行う。ＡＡ１５は，ＳＨによって送信されたホスト情報と，ＨＮＲから得られたホスト情報が同じであることを検証する。ＡＡ１５は，ＡＡがサポートできる完全性チェックアルゴリズムの種類に基づいて，完全性チェックアルゴリズムを選択する。ＡＡ１５は，アクセスＩＤおよびシークレットアクセスキーを割り当てる。ＡＡ１５は，完全性チェックアルゴリズム，アクセスＩＤおよびシークレットアクセスキーを含む第一のホスト登録応答をＳＨ１２へ送信する。ここで，アクセスＩＤおよびシークレットアクセスキーは，ＳＨのＰＫで暗号化される。
ＳＨ１２は，第一のホスト登録応答を受信する。

ローカル登録ステップ（Ｓ２０３）は，認証ステップ（Ｓ２０２）後のステップである。このステップでは，ＳＨ１２は，完全性チェックアルゴリズムにおいてアクセスキーを使用して計算されたＨＭＡＣ含めることによって完全性が保護されている，ＳＨのホスト名，ＳＨのＩＤ，ＳＨのＬＬｏｃ，ＳＨのＰＫが含まれる第二のホスト登録要求をＡＡ１５へ送信する。ＡＡ１５は，第二のホスト登録要求を受信する。ＡＡ１５は，ＧＷ宛てのホスト登録メッセージを第一ＧＷ１３へ送信する。ＧＷ宛てのホスト登録メッセージは，ＡＡ−ＧＷｓｈＫｅｙによって暗号化された，ＳＨのホスト名，ＳＨのＩＤ，ＳＨのＬＬｏｃ，ＳＨのＰＫおよびアクセスキーを含んでいる。また，ＡＡ１５は，ＬＮＳ宛てのホスト登録メッセージをＬＮＳ１４へ送信する。ＬＮＳ宛てのホスト登録メッセージは，ＡＡ−ＬＮＳｓｈＫｅｙによって暗号化された，ＳＨのホスト名，ＳＨのＩＤ，ＳＨのＬＬｏｃ，ＳＨのＰＫおよびアクセスキーを含んでいる。
第一ＧＷ１３は，ＧＷ宛てのホスト登録メッセージを受信し，ＡＡ−ＧＷｓｈＫｅｙを用いてこれを復号化する。第一ＧＷ１３は，ＧＬｏｃをＳＨ１２に割り当て，第一ＧＷ１３のメモリに，ＳＨのＧＬｏｃを保存する。第一ＧＷ１３は，ＧＷから、ＳＨのＧＬｏｃを含むホスト登録応答メッセージをＡＡ１５に送信する。ＬＮＳ１４は，ＬＮＳ宛てのホスト登録メッセージを受け取り，ＡＡ−ＬＮＳｓｈＫｅｙを使用してこれを読み取り，ＬＮＳ１４は，ＳＨのホスト名，ＳＨのＩＤ，ＳＨのＬＬｏｃ，ＳＨのＰＫおよびアクセスキーを保存する。ＬＮＳ１４は，ＬＮＳからホスト登録応答メッセージをＡＡ１５へ送信する。ＡＡ１５は，ＳＨのＧＬｏｃを含む第二のホスト登録応答をＳＨ１２に送信する。ＳＨ１２は，第二のホスト登録応答を受信する。

ＨＮＲ更新ステップ（Ｓ２０４）は，ローカル登録ステップ（Ｓ２０３）の後に実行される。このステップでは，ＳＨ１２は，第三のホスト登録要求をＨＮＲ２３に送信する。第三のホスト登録要求は，ＳＨ−ＨＮＲｓｈＫｅｙによって暗号化されたＳＨのホスト名，ＳＨのＩＤ，ＳＨのＧＬｏｃを含んでいる。ＨＮＲ２３は，第三のホスト登録要求を受信し，ＳＨ−ＨＮＲｓｈＫｅｙを用いてこれを読み取る。ＨＮＲ２３は，ＨＮＲのレコードにおいてＳＨのＧＬｏｃを更新し，第三のホスト登録応答をＳＨ１２へ送信する。

第一の側面の別の好ましい実施形態は，ＳＨ１２とＴＨ１３の２つのホスト間の通信セッションを確立するための手順をさらに含む方法である。

ＳＨ１２は，通信要求をＴＨ３１へ伝えるよう，第一の通信初期化要求メッセージをＴＨ３１へ送信する。第一の通信初期化要求メッセージは，ＳＨおよびＴＨのＩＤと，ＳＨのホスト名，ＰＫおよびＧＬｏｃと，ＴＨのＧＬｏｃと，完全性チェックアルゴリズムのリストと，ＳＨの署名を含んでいる。“ｉｎｉｔ”の語は，初期化を意味している。

ＴＨ３１は，第一の通信初期化要求メッセージを受信し，ＴＨ３１の一時バッファに，ＳＨのＩＤ，ＧＬｏｃ，ＰＫおよびＬＬｏｃと，選択された完全性チェックアルゴリズムを保存する。

ＴＨ３１は，上記の方法に従ってホスト名解決処理を行うことによってＨＮＲからＳＨのＩＤとＰＫを取得することにより，ＳＨの真正性を検証する。

ＴＨ３１は，ＴＨ３１が二つ以上ＧＬｏｃを有する場合にＴＨのＧＬｏｃを含む第一の通信初期化応答をＳＨ１２に送信する。第一の通信初期化応答は，ＴＨの秘密鍵を用いるＴＨの署名によって保護されている。

ＳＨ１２は，第一の通信初期化応答を受信し，ＳＨとＴＨとの間で交換されるパケットの完全性を保護するために使用される秘密セッション鍵（ｓｅｓｓＫｅｙ）と，ｓｅｓｓＫｅｙに関連付けられている有効期間を生成する。

ＳＨ１２は，ＴＨのＩＤ，ＰＫ，ｓｅｓｓＫｅｙおよび有効期間をＳＨの一時バッファに保存する。ＳＨ１２は，ＴＨのＰＫによって暗号化されたｓｅｓｓＫｅｙを含む第二の通信初期化応答，およびＳＨの秘密鍵によって署名されたメッセージをＴＨ３１へ送信する。ＴＨ３１は，第二の通信初期化応答を受信し，一時バッファ（ＳＨのＩＤ，ＧＬｏｃ，ＰＫおよびＬＬｏｃを含む）およびｓｅｓｓＫｅｙをＴＨ３１のセキュリティアソシエーションテーブル（ＳＡＴ）にコピーする。

ＴＨ３１は，通信初期化完了メッセージをＳＨ１２へ送信する。通信初期化完了メッセージは，ｓｅｓｓＫｅｙを使用して計算したＨＭＡＣにより保護されている。

ＳＨ１２は，通信初期化完了メッセージを受信し，ＴＨ３１が接続要求を受け入れたか否かを確認するために，通信初期化完了メッセージを検証する。ＳＨ１２は，ＳＨのＩＤ，ＧＬｏｃ，ＰＫおよびＬＬｏｃを含む一次バッファを，ＳＨ１２のＳＡＴにコピーする。ＳＨ１２は，ＴＨ３１へのデータの送信，またはＴＨ３１からのデータの受信を開始する。

本発明は，主に新世代ネットワークの以下の三つの機能を安全に行うための方法，すなわち，（１）ネームレジストリ機能（２）ネットワークアクセス機能，および（３）セッションの確立とデータパケット通信機能，について規定する。

ネームレジストリを安全にするために，本発明は，ＤＮＲおよびＨＮＲレコードのようなドメインネームレジストリ（ＤＮＲ）およびホストネームレジストリ（ＨＮＲ）のそれぞれにおいて，ホスト名，ホストＩＤ，ロケータ，（公開鍵すなわちＰＫのような）セキュリティキー，および他のパラメータを保存し，更新するためのセキュリティ方法について規定する。また，ホスト名に対応したホストＩＤ，ロケータ，ＰＫ，および他のパラメータをこれらのネームレジストリから取得，または入手するために使用されるホスト名解決のためのセキュリティ方法について規定する。本発明は，ＤＮＲレコードを保存，更新，取得するプロセスを安全にするために，ＤＮＳＳＥＣ［ＤＮＳＳＥＣ］の概念を拡張している。同時に，本発明においては，ＨＮＲレコードを保存，更新，取得するプロセスを安全にするために，新規な方法を開発した。

本発明は，ネットワークアクセスプロセスを安全にするために，ホスト（すなわち，デバイス）をネットワークに安全に接続するための方法について規定する。これには，ホストを認証し，ホストにロケータと共有鍵を安全に割り当て，ホスト関連情報（ホスト名，ＩＤ，ロケータ，セキュリティキーなど）をアクセスネットワークエンティティ（ゲートウェイ，ネームサーバ，および認証エージェント）に安全に登録するためのセキュリティ機能が含まれている。ホストを認証するために，認証エージェントは，ホストによって請求された際に，ホストが実際にホスト名，ホストＩＤおよび公開鍵を所有していることを検証するために，ＨＮＲレコードを使用する。

本発明は，二つのホストの間の通信セッションを安全にするために，プロトコルスタックの識別層からのシグナリングメッセージを交換するための方法を規定する。これらのシグナリングメッセージを介して，ホストは，セキュリティパラメータを折衝し，これらをセキュリティアソシエーションデータベースに保存する。これらは，認証データや完全性チェック値（ＩＣＶ）を計算するためにセキュリティアソシエーションを使用し，これはパケットのＩＤヘッダで送信される。受信側は，セキュリティアソシエーションを使用してＩＣＶを検証し，データパケットが認証されたホストから送信されたこと，およびネットワークを介して送信されている間にデータパケットが変更されていないことを保証する。

本発明の効果は，利用者が自由にネットワークサービスを使用できるように，ＩＤ／ロケータに基づく新世代ネットワークを安全にすることである。

図１は，本発明のネットワークアーキテクチャ構成要素を示す。 図２は，ホスト名解決手順のフローチャートである。 図３は，ネットワークアクセス手順のフローチャートである。 図４は，ＤＮＲの階層構造を示す図である。 図５は，ホスト登録メッセージのフォーマットである。 図６は，ホスト名解決のために交換されるメッセージのシーケンスを示す。 図７は，ホスト名解決のために交換されるメッセージのシーケンスを示す。［ローカルネームサーバ（ＬＮＳ）が，送信元ＧＷにおいてターゲットホストのＩＤ／ロケータマッピングの登録を行った場合］。 図８は，ホスト名解決のために交換されるメッセージのシーケンスを示す。［送信元ホストが，送信元ＧＷにおいてターゲットホストのＩＤ／ロケータマッピングの登録を行った場合］。 図９Ａは，ホスト登録のために交換されるメッセージのシーケンスの一部を示す（初回登録用）。 図９Ｂは，ホスト登録のために交換されるメッセージのシーケンスの残りの部分を示す（初回登録用）。 図１０Ａは，ネットワークアクセスのために交換されるメッセージのシーケンスの一部を示す。 図１０Ｂは，ネットワークアクセスのために交換されるメッセージのシーケンスの残りの部分を示す。 図１１は，ＩＤヘッダフォーマットの例である。 図１２は，セキュリティパラメータの折衝を除いて，ピアホスト登録の暗黙実行を伴う、通信セッションを確立するために交換される制御パケットのシーケンスを示す。 図１３は，セキュリティパラメータの折衝を除いて，ピアホスト登録の明示的実行を伴う通信セッションを確立するために交換される制御パケットのシーケンスを示す。 図１４は，セキュリティパラメータの折衝を伴う通信セッションを確立するために交換される制御パケットのシーケンスを示す。［Ｔ−ＧＷおよびＳ−ＧＷにおけるピアホスト登録は，シーケンス中には示していない。］ 図１５は，ＩＤｓｅｃ認証ヘッダフォーマットの例である。 図１６は，ＩＤ／ロケータマッピングを安全に取得するために交換されるメッセージのシーケンスを示す。 図１７は，ホスト登録制御メッセージフォーマットの例である。 図１８Ａは，ネットワークアクセスセキュリティのために交換されるメッセージのシーケンスの一部である。 図１８Ｂは，ネットワークアクセスセキュリティのために交換されるメッセージのシーケンスの残りの部分を示す。 図１９は，ＩＤヘッダフォーマットの例である。 図２０は，通信セッションセキュリティ手順において交換されるメッセージのシーケンスを示す。

図１は，本発明のセキュリティ方法を説明するためのネットワークアーキテクチャの構成要素を示している。図１に示すように，本発明のインターネットネットワークシステム１は，第一エッジネットワーク１１と，論理制御ネットワーク２１と，第二エッジネットワーク３２におけるターゲットホスト（ＴＨ）３１と，グローバルトランジットネットワーク４１と，を備えている。

第一エッジネットワーク１１は，送信元ホスト（ＳＨ）１２と，第一ゲートウェイ（ＧＷ）１３と，ローカルネームサーバ（ＬＮＳ）１４と，を備えている。第一エッジネットワーク１１は，認証エージェント（ＡＡ）１５を備えていてもよい。

論理制御ネットワーク２１は，ドメインネームレジストリ（ＤＮＲ）２２と，ホストネームレジストリ（ＨＮＲ）２３を備えている。

図1において，ＴＨ３１は，第二エッジネットワーク３２内にある。ＴＨは，第一エッジネットワーク１１内に配置されていてもよい。第二エッジネットワーク３２は，第一エッジネットワーク１１と同様の構造を有する。第二エッジネットワーク３２は，第二ゲートウェイ（ＧＷ）３３と第二ローカルネームサーバ（ＬＮＳ）３４を備えている。第二エッジネットワーク３２は，認証エージェント（ＡＡ）３５をさらに備えていてもよい。

グローバルトランジットネットワーク４１は，第一エッジネットワーク１１，論理制御ネットワーク２１，およびＴＨ３１と接続するために，複数のルータ４２を備えている。グローバルトランジットネットワークは，パケットヘッダに存在するグローバルロケータ（Ｇｌｏｃ）に基づいて，あるエッジネットワークから別のエッジネットワークへとパケットを転送する。同様に，エッジネットワークは，エッジネットワーク内でパケットを転送するためにローカルロケータ（Ｌｌｏｃ）を使用する。パケットがエッジネットワークからグローバルネットワークへと流れた時，パケットヘッダのＬＬｏｃは対応するＧＬｏｃに置き換えられる。デバイス，すなわちホストがエッジネットワークに接続すると，そのＬＬｏｃとＧＬｏｃの両方が取得される。ホストは，それが作成し，ネットワーク内に入れるパケットのヘッダにおいてＬＬｏｃを使用する。同様に，ホストは，ヘッダの送信先ロケータフィールドにおいて，そのＬＬｏｃを含むパケットを受信する。ホストは，通信初期化やモビリティシグナリングのような，のシグナリングメッセージにおいてＧＬｏｃを使用する。

ホスト名解決
図２は，ホスト名解決手順のフローチャートを示す。ホスト名解決のための方法は，ターゲットホストのホスト名によって検索された時に，ターゲットホストのＩＤ，ロケータ，公開鍵（ＰＫ）を取得する手順である。図２において，Ｓはステップを表している。図２に示すように，ＴＨのＩＤ，ＴＨのロケータ，ＴＨのＰＫが一つ以上得られるよう，ＳＨ１２はホスト名解決クエリをＬＮＳ１４へ送信する（ステップ１０１）。ＳＨ１２は始めにＴＨ３１のホスト名を知っているが，ＴＨ３１と通信するために必要なすべての情報を知っているわけではない。ホスト名解決要求は，ホストがＬＮＳと共有しているアクセスキーを使用して計算したＨＭＡＣ（Ｈａｓｈ−ｂａｓｅｄ ｍｅｓｓａｇｅ ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｃｏｄｅ）によって，完全性が保護されている。

ＬＮＳ１４は，ＳＨ１２からホスト名解決クエリを受信する。ＬＮＳ１４およびＳＨ１２は，同一のエッジネットワーク内，すなわち，第一エッジネットワーク１１内に存在する。ＬＮＳ１４は，ＴＨ３１が第一エッジネットワーク内に存在するかどうかを調べるために，そのメモリをチェックする（Ｓ１０２）。ＴＨが第一エッジネットワーク内に存在する場合には，ＴＨのホスト名，ＩＤ，ロケータおよびＰＫを含むその情報は，ＬＮＳ１４のメモリに保存され，ＴＨのＩＤとロケータはＧＷ１３に保存されている。

ＬＮＳ１４が第一エッジネットワーク１１内にＴＨ３１が存在すると判断できない場合には，ＬＮＳ１４はＤＮＲ２２に第一のクエリを送信する（ステップ１０３）。第一のクエリには，ＴＨのホスト名が含まれている。第一のクエリは，ＨＮＲのＩＤ，ＧＬｏｃ，およびＰＫを含む第一の応答をＬＮＳ１４に提供するようＤＮＲ２２に対して要求する。

ＬＮＳ１４はＴＨ３１が第一エッジネットワーク１１内に存在すると判断できる場合には，ＬＮＳ１４はホスト名解決応答をＳＨ１２へ送信する（ステップ１０４）。ＴＨ３１が第一エッジネットワーク１１内に存在している場合には，第一エッジネットワーク１１は，ＴＨのＩＤ，ＴＨのロケータ，ＴＨの公開鍵（ＰＫ）を含む，ＴＨの情報を有している。情報は，メモリ，テーブル，または第一ＧＷ１３のデータベースに保存されてもよい。ＬＮＳ１４は，ＴＨの情報を取得した後に，ＴＨの情報を含むホスト名解決応答をＳＨ１２へ送信する。

ＤＮＲ２２は，第一のクエリを受信すると，第一の応答をＬＮＳ１４へ送信する（ステップ１０５）。第一の応答には，ＨＮＲのＩＤ，ＧＬｏｃ，およびＰＫを含む，ＨＮＲの情報が含まれている。第一の応答は，ＤＮＲの公開鍵と，ルートＤＮＲ（図示せず）からのＤＮＲの認証チェーンと，ＤＮＲの秘密鍵を使用して作成されたＤＮＲの署名と，をさらに含んでもよい。ＤＮＲによって送信された応答の真正性を検証するために，ＬＮＳによって，ＤＮＲの公開鍵，ＤＮＲの認証チェーン，およびＤＮＲの署名が使用される。

ＬＮＳ１４は，ステップ１０５において，ＤＮＲ２２によって発行された第一の応答を受信する。第一の応答には，ＨＮＲのＩＤ，ＨＮＲのロケータ等のＨＮＲの情報，およびＨＮＲのＰＫが含まれている。ＬＮＳ１４は，ＤＮＲの公開鍵と証明書を使用して，ＤＮＲの署名を検証する。つまり，ＬＮＳ１４は，第一の応答においてＤＮＲから受け取ったＨＮＲの情報の真正性を検証する。ＬＮＳは，しばらくの間，そのバッファメモリ内にＨＮＲの情報を保存（すなわち，キャッシュ）する。
そして，ＬＮＳ１４は，ＨＮＲの情報を使用して，第二のクエリをＨＮＲ２３に送信する（ステップ１０６）。第二のクエリは，ＴＨのＩＤ，ＴＨのロケータおよびＴＨのＰＫをＬＮＳ１４に提供することをＨＮＲ２３に要求する。

ＨＮＲ２３は，ＬＮＳ１４によって発行された第二のクエリを受信する。そして，ＨＮＲ２３は，ＴＨのＩＤ，ＴＨのロケータ，およびＴＨのＰＫをＨＮＲ２３のメモリから取得する。例えば，第二のクエリは，ＴＨのホスト名を含んでおり，ＨＮＲ２３は，ＨＮＲのメモリにおいてＴＨのホスト名を検索することで，ＴＨのＩＤ，ＴＨのロケータ，およびＴＨのＰＫを取得することができる。ＨＮＲ２３は，第二の応答をＬＮＳ１４へ送信する（ステップ１０７）。第二の応答には，ＴＨのＩＤ，ＴＨのロケータおよびＴＨのＰＫが含まれる。メッセージの完全性を保護するために，第二の応答メッセージにも，ＨＮＲの署名が含まれている。ＨＮＲに保存されたＴＨのロケータは，ＴＨのＧＬｏｃであることに注意されたい。

ＬＮＳ１４は，第二の応答を受信する。第二の応答には，ＴＨのＩＤ，ＴＨのロケータ，ＴＨのＰＫ，およびＨＮＲの署名が含まれている。そして，ＬＮＳ１４は，ＤＮＲからの第一の応答で受け取ったＨＮＲの公開鍵を使用してＨＮＲ署名を検証する。

検証結果が可であった場合には，ＬＮＳ１４は，ＴＨのＩＤ，ＴＨのロケータおよびＴＨのＰＫを含むホスト名解決応答をＳＨへ送信する（ステップ１０９）。ホスト名解決応答は，ＬＮＳ１４およびＳＨ１２の間で共有される秘密アクセス鍵を使用して作成されたＨＭＡＣによって保護されている。

検証結果が「検証不可」または否であった場合には，ＬＮＳ１４はホスト名解決応答をＳＨ１２に送信する（ステップ１１０）。ホスト名解決応答は，拒否を含んでいてもよい。

ネットワークアクセス
図３は，ネットワークアクセス手順のフローチャートを示している。ネットワークアクセス手順には，ホスト（例えば，ＳＨ）が他のホストと通信することを許可する前に，ネットワークによってホストが認証されることが含まれる。また，ネットワークアクセス手順は，ホストとネットワークの間で交換されるメッセージを保護するために使用される，ホストとネットワークにおけるセキュリティコンテキスト（アクセスＩＤとアクセスキーからなる）を作成する。

第一エッジネットワーク１１は，認証エージェント（ＡＡ）１５および動的ホスト構成プロトコルサーバ（ＤＨＣＰ）１６を備える。動的ホスト構成プロトコルとは，ネットワーク管理者が，組織のネットワーク内のインターネットプロトコル（ＩＰ）アドレスの割り当てを一元的に管理し，自動化することを可能にする通信プロトコルである。インターネットプロトコルを使用するにあたり，インターネットに接続できる各マシンは，固有のＩＰアドレスを必要とする。ＩＰアドレスは，インターネットが特定のコンピュータに対して接続された際に割り当てられる。

第一ゲートウェイ（ＧＷ）１３，ＬＮＳ１４，およびＡＡ１５は，これらの間で交換されるメッセージを保護するために使用される，ＡＡ−ＧＷｓｈＫｅｙ，ＡＡ−ＬＮＳｓｈＫｅｙ，およびＬＮＳ−ＧＷｓｈＫｅｙを共有している。

ネットワークアクセス手順は，ＳＨのローカルロケータ（ＬＬｏｃ）とグローバルロケータ（ＧＬｏｃ），第一ＧＷのＩＤとＬＬｏｃ，ＬＮＳのＩＤとＬＬｏｃ，ＡＡのＩＤとＬＬｏｃをＤＨＣＰから取得するための初期設定ステップ（ステップ２０１）と，ＳＨを認証するための認証ステップ（ステップ２０２）と，第一ＧＷ１３およびＬＮＳ１４に登録される，ＳＨのホスト名，ＩＤ，ＰＫおよびＬＬｏｃを作成するためのローカル登録ステップ（ステップ２０３）と，ＨＮＲにおいてＳＨのＩＤ／ロケータマッピングを更新するためのＨＮＲ更新ステップ（ステップ２０４）と，を含む。

ＳＨまたはＴＨとなるあるホストが，エッジネットワークが利用可能であることを検出した時に，初期設定ステップ（ステップ２０１）が実行される。以下の説明では，ホストがＳＨであるものとして説明する。ＳＨは，（たとえば，電波スペクトルまたは有線接続を検出することによって）エッジネットワークの存在を認識し，エッジネットワーク１１に加わるために，ＤＨＣＰ発見メッセージをＤＨＣＰ１６に送信する。ＤＨＣＰ１６は，ＤＨＣＰ発見メッセージを受信し，ＳＨのＬＬｏｃ，第一ＧＷ１３のＩＤおよびＬＬｏｃ，ＬＮＳ１４のＩＤおよびＬＬｏｃ，ＡＡ１５のＩＤおよびＬＬｏｃなどのパラメータを含むＤＨＣＰ提供メッセージを発行する。ＳＨ１２は，これらのパラメータをその設定ファイルに保存し，これらのパラメータを含むＤＨＣＰ要求をＤＨＣＰ１６に発行する。ＤＨＣＰ１６はＤＨＣＰ要求を受信し，ＳＨ１２への受信通知であるＤＨＣＰ ＡＣＫを発行し返す。

認証ステップ（ステップ２０２）とは，初期設定ステップ（ステップ２０１）の後に，ＳＨ１２を認証するためのステップである。

ＳＨ１２は，第一のホスト登録要求をＡＡ１５に送信する。第一のホスト登録要求には，ＳＨのホスト名，ＳＨのＩＤ，ＳＨのＰＫおよび完全性チェックアルゴリズムの種類が含まれている。完全性チェックアルゴリズムの種類は，ＳＨが，ＡＡ１５，ＧＷ１３およびＬＮＳ１４と交換するメッセージを保護するためのＨＭＡＣの計算の際に使用しようとするものである。

ＡＡ１５は，第一のホスト登録要求を受信する。ＡＡは，ＨＮＲ２３からＳＨのレコードを取得することにより，ＳＨの同一性（すなわち，ホスト名，ＩＤ，およびＰＫ）を検証する。ＨＮＲ２３からＳＨのレコードを取得するためのプロセスは，図２に示した通りである。ＡＡ１５は，ネットワークがサポートすることができる完全性チェックアルゴリズムの種類に基づいて，完全性チェックアルゴリズムを選択する。完全性チェックアルゴリズムの例は，ＨＭＡＣ−ＳＨＡ１である。ＡＡ１５は，ＡＡにアクセスするために使用される識別子であるアクセスＩＤ，およびシークレットアクセスキーを割り当てる。シークレットアクセスキーとは，ホストが，ＡＡ１５，ＬＮＳ１４，およびＧＷ１３などのエッジネットワークエンティティと交換されるメッセージの認証と完全性保護のために使用する，共有秘密鍵のことである。アクセスキーは，一定の有効期間を有する。ＡＡ１５は，第一のホスト登録応答をＳＨ１２へ送信する。応答には，完全性チェックアルゴリズム，アクセスＩＤおよびアクセスキーが含まれる。アクセスＩＤとシークレットアクセスキーは，ＳＨのＰＫによって暗号化されている。

ＳＨ１２は，第一のホスト登録応答（返答）を受信する。応答には，完全性チェックアルゴリズム，アクセスＩＤおよびシークレットアクセスキーが含まれる。

ローカル登録ステップ（ステップ２０３）は，ＧＷ１３およびＬＮＳ１４に登録されるＳＨのホスト名，ＩＤ，ＰＫおよびＬＬｏｃを作成するためのステップである。ローカル登録ステップ（ステップ２０３）は，認証ステップ（ステップ２０２）の後のステップである。以下に示すのは，ステップの一例である。

まず，ＳＨ１２は，第二のホスト登録要求をＡＡ１５へ送信する。要求には，ＳＨのホスト名，ＳＨのＩＤ，ＳＨのＬＬｏｃ，ＳＨのＰＫおよびアクセスキーが含まれており，要求はアクセスキーによって暗号化されている。ＡＡ１５は，第二のホスト登録要求を受信する。ＡＡ１５は，ＧＷ宛てのホスト登録メッセージをＧＷ１３に送信する。メッセージには，ＡＡ−ＧＷｓｈＫｅｙによって暗号化された，ＳＨのホスト名，ＳＨのＩＤ，ＳＨのＬＬｏｃ，ＳＨのＰＫおよびアクセスキーが含まれている。ＡＡ１５は，ＬＮＳ宛てのホスト登録メッセージをＬＮＳ１４に送信する。メッセージには，ＡＡ−ＬＮＳｓｈＫｅｙによって暗号化された，ＳＨのホスト名，ＳＨのＩＤ，ＳＨのＬＬｏｃ，ＳＨのＰＫおよびアクセスキーが含まれている。

ＧＷ１３は，ＧＷ宛てのホスト登録メッセージを受信し，ＡＡ−ＧＷｓｈＫｅｙを用いてメッセージを復号化することによって，ＧＷ宛てのホスト登録メッセージを読み取る。ＧＷ１３は，ＧＬｏｃをＳＨ１２に割り当て，第一ＧＷ１３のメモリに，ＳＨのＩＤ，ＬＬｏｃ，ＧＬｏｃ，アクセスＩＤおよびアクセスキーを保存する。第一ＧＷ１３は，ホスト登録メッセージをＧＷからＡＡ１５へと送信する。ＳＨのＧＬｏｃを含むメッセージは，ＡＡ−ＬＮＳｓｈＫｅｙによって暗号化されている。ＡＡ１５はそれを受信する。

ＬＮＳ１４は，ＬＮＳ宛てのホスト登録メッセージを受信し，ＡＡ−ＬＮＳｓｈＫｅｙを用いてＬＮＳ宛てのホスト登録メッセージを読み取る。ＬＮＳ１４は，ＳＨのホスト名，ＳＨの仮ＩＤ，ＳＨのＬＬｏｃ，ＳＨのＰＫおよびアクセスＩＤ，さらにはアクセスキーを，ＬＮＳ１４のメモリに保存する。ＬＮＳ１４は，ホスト登録メッセージをＬＮＳからＡＡ１５へと送信する。ＡＡ１５はそれを受信する。

ＡＡ１５は，第二のホスト登録応答をＳＨ１２に送信する。この応答には，ＳＨのＧＬｏｃが含まれている。

ＨＮＲ更新ステップ（ステップ２０４）は，ＨＮＲを更新するためのステップである。ＨＮＲ更新ステップ（ステップ２０４）は，ローカル登録ステップ（ステップ２０３）の後のステップである。以下に示すのは，ステップの一例である。

ＳＨ１２は，第三のホスト登録要求をＨＮＲ２３に送信する。要求には，ＳＨのホスト名，ＳＨのＩＤおよびＳＨのＧＬｏｃが含まれており，要求はＳＨ−ＨＮＲｓｈＫｅｙによって暗号化されている。ＨＮＲ２３は，第三のホスト登録要求を受信し，ＳＨ−ＨＮＲｓｈＫｅｙを用いて第三のホスト登録要求を読み取る。ＨＮＲ２３は，ＨＮＲのレコードにおけるＳＨのＧＬｏｃを更新し，第三のホスト登録応答をＳＨ１２に送信する。

通信セッションのセキュリティ手順
通信セッションのセキュリティ手順において，ＳＨ１２およびＴＨ３１は互いに認証し合い，第三者によるデータの変更を防ぐことによってデータの完全性を保護する。

ＳＨ１２は，第一の通信初期化要求メッセージをＴＨ３１に送信する。メッセージには，ＳＨおよびＴＨのＩＤ，ＳＨのホスト名，ＰＫおよびＧＬｏｃ，ＴＨのＧＬｏｃ，および完全性チェックアルゴリズムのリストが含まれる。メッセージには，その秘密鍵を使用して作成されたＳＨの署名も含まれている。

ＴＨ３１は，第一の通信初期化要求メッセージを受信し，ＳＨのＩＤ，ＧＬｏｃ，ＰＫおよびＬＬｏｃ，さらには選択された完全性チェックアルゴリズムをＴＨ３１の一時バッファに保存する。ＴＨ３１は，先に説明したように，ホスト名解決を実行することによって，ＨＮＲからＳＨのＩＤおよびＰＫを取得することで，ＳＨの真正性を検証する。ＴＨ３１は，ＳＨから提供されたＳＨ１２のＩＤおよびＰＫと，ＨＮＲから取得したＳＨ１２のＩＤおよびＰＫとを比較する。それらが同一である場合には，ＴＨ３１はＳＨを認証し，以下のステップを実行する。それ以外の場合には，ＴＨ３１は，通信初期化要求を単に無視し，ＳＨの情報を一時バッファから削除する。

ＴＨ３１が２つ以上のＧＬｏｃを有する場合には，ＴＨ３１は，ＴＨのＧＬｏｃを含む第一の通信初期化応答をＳＨ１２へと送信する。ＴＨ３１が一つしかＧＬｏｃを有していない場合には，その応答にはＴＨのＧＬｏｃが含まれなくてもよい。第一の通信初期化応答は，ＴＨの秘密鍵によって署名されている。ＳＨ１２は，第一の通信初期化応答を受信し，秘密セッション鍵（ｓｅｓｓＫｅｙ）を生成する。ｓｅｓｓＫｅｙは，ＳＨとＴＨの間で交換されるパケットの完全性を保護するために使用される。すなわち，各パケットは，ｓｅｓｓＫｅｙを使用して計算されたＨＭＡＣを含む。ｓｅｓｓＫｅｙを使ってＨＭＡＣを計算し，新たに計算されたＨＭＡＣと送信側がパケットに含ませたＨＭＡＣとを比較することによって，パケットの受信側は，パケットが完全なままであるかということ（つまり，途中でいかなる盗聴者によっても変更されていないということ）を検証することができる。ｓｅｓｓＫｅｙは有効期間を有する。ＳＨ１２は，ＴＨのＩＤ，ＰＫ，ｓｅｓｓＫｅｙおよびｓｅｓｓＫｅｙの有効期間をＳＨ１２の一時バッファに保存する。

ＳＨ１２は，第二の通信初期化応答をＴＨ３１に送信する。応答にはＴＨのＰＫによって暗号化されたｓｅｓｓＫｅｙが含まれており，応答メッセージはＳＨの秘密鍵によって署名されている。ＴＨ３１は，第二の通信初期化応答を受信し，ＳＨ１２から受け取ったＳＨのホスト名，ＩＤおよびＰＫを，ＨＮＲから取得したＳＨのホスト名，ＩＤおよびＰＫと比較することで，ＳＨの同一性を確認する。

検証が成功した場合には，ＴＨ３１は，ＳＨのＩＤ，ＧＬｏｃ，ＰＫとＬＬｏｃおよびｓｅｓｓＫｅｙを含む一時バッファを，ＴＨ（３１）のセキュリティアソシエーションテーブル（ＳＡＴ）にコピーする。

ＴＨ３１は，通信初期化完了メッセージをＳＨ１２に送信する。メッセージは，ｓｅｓｓＫｅｙを用いて計算されたＨＭＡＣにより完全性が保護されている。ＳＨ１２は，通信初期化完了メッセージを受信し，ＴＨ３１が接続要求を受け入れたかどうかを確認するために，通信初期化完了メッセージをチェックする。

ＳＨ１２は，ＴＨのＩＤ，ＧＬｏｃ，ＰＫおよびＬＬｏｃを含む一次バッファをＳＨ１２のＳＡＴにコピーする。また，ＳＨ１２は，ｓｅｓｓＫｅｙをＳＡＴに保存する。

ＳＨ１２は，ＴＨ３１へのデータの送信を開始する，またはＴＨ３１からのデータの受信を開始する。

［実施例１］
このセクションでは，三つのステップで，本発明の第一の実施例を説明する。最初のセクションでは，ネームレジストリのセキュリティについて記載する。第二のセクションでは，ネットワークアクセスのセキュリティについて記載する。最後のセクションでは，データ通信を安全にするためのセキュリティ方法について記載する。

ネームレジストリのセキュリティ
ネームレジストリは，２つのタイプのレジストリ，すなわちＤＮＲとＨＮＲによって構成される［ＨＩＭＡＬＩＳ］。ＤＮＲは，ドメイン名（例えば，ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ）と，ＨＮＲのＩＤおよびロケータとの間のマッピングを保存する。一方，ＨＮＲは，ホスト名と，ホストのホストＩＤ，ロケータ，ＰＫおよび他のパラメータとの間のマッピングを保存している。

本発明は，ＤＮＲとＨＮＲのためのセキュリティ方法を規定する。本発明は，ＤＮＲのセキュリティのために，ＤＮＳＳＥＣ［ＤＮＳＳＥＣ］で使用される概念と手順を拡張するものであり，ＨＮＲを安全にするための新しい方法を規定する。

図４に示すように，ＤＮＲは階層構造で構成されている。

ＤＮＲレコードを安全にするために，ＤＮＳＳＥＣ［ＲＦＣ４０３５；ＤＮＳセキュリティ拡張のためのプロトコル変更：ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ４０３５．ｔｘｔ］を使用した。

我々は，ＨＮＲサーバにドメイン名をマッピングするために，ＳＲＶリソースレコード［ＲＦＣ２７８２，Ｒｅｓｏｕｒｃｅ Ｒｅｃｏｒｄ （ＲＲ） ｔｙｐｅ ｃｏｄｅ＝３３］を使用する。［ＲＦＣ２７８２］は，「サービスの場所を指定するためのＤＮＳ ＲＲ（ＤＮＳ ＳＲＶ）」と題されており，「ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２７８２．ｔｘｔ」から取得することができる。ＳＲＶ ＲＲの形式（ＲＦＣ２７８２で規定されている。２ページ目。）は，＿ｓｅｒｖｉｃｅ．＿ｐｒｏｔｏ．ｎａｍｅ ＴＴＬ ＣＬＡＳＳ ＳＲＶ ｐｒｉｏｒｉｔｙ Ｗｅｉｇｈｔ Ｐｏｒｔ♯ ＴａｒｇｅｔＳｅｒｖｅｒである。

我々は，ホストＩＤを保存するための新しいＲＲタイプのＨＩＤを作成した。

ＤＮＲレコードとＨＮＲレコードの例
以下は，（ｉｄｌｏｃ．ｎｗｇｎ．ｊｐゾーンの）ＤＮＲレコードの例である。
＿ｈｎｒ．＿ｕｄｐ．ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ３６００ ＩＮ ＳＲＶ ０ ０ ２９００ ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ
(これはｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐドメインのＨＮＲが，ＵＤＰポート番号２９００を使用することを意味する。)
＿ｈｎｒ．＿ｔｃｐ．ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ３６００ ＩＮ ＳＲＶ ０ ０ ２９００ ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ
（これはｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐドメインのＨＮＲが，ＴＣＰポート番号２９００を使用していることを意味する。）
ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ＩＮ ＨＩＤ ＦＦＦＦ−ＦＦＦ０−０００１−ＦＦ０１−３ＥＡ３−８２Ｄ２−Ｂ９４８−Ｂ３５Ｃ
（このレコードは，ＦＦＦＦ−ＦＦＦ０−０００１−ＦＦ０１−３ＥＡ３−８２Ｄ２−Ｂ９４８−Ｂ３５ＣなどＨＮＲのホストＩＤを指定する。）
ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ＩＮ Ａ １３３．３２．１４９．１
（このレコードは，１３３．３２．１４９．１としてＨＮＲのＩＰｖ４ロケータを指定する）。
ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ＩＮ ＡＡＡＡ ２００１：ＢＥＥＦ：：１００１：１
（このレコードは，２００１：ＢＥＥＦ：：１００１：１として，ＨＮＲのＩＰｖ６ロケータを指定する。）
ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ＜ＴＴＬ＞ ＩＮ ＤＳ ＜ｋｅｙ ｔａｇ＞ ＜ａｌｇｏｒｉｔｈｍ＞ ＜ｄｉｇｅｓｔ ｏｆ ＨＮＲ‘ｓ ＤＮＳＫＥＹ＞
（このＤｅｌｅｇａｔｅ Ｓｉｇｎｅｒ ｒｅｃｏｒｄは，ＨＮＲのＤＮＳＫＥＹに署名する権威のシグネチャを与える。これらのパラメータの説明は，ＲＦＣ４０３５に記載されている。）

上記の例では示されていないが，ＤＮＲレコードはＲＲＳＩＧ（Ｒｅｓｏｕｒｃｅ Ｒｅｃｏｒｄ Ｓｉｇｎａｔｕｒｅ）およびＤＮＳＫＥＹレコードも含んでおり，それらのフォーマットは，ＤＮＳＳＥＣ［ＲＦＣ４０３５］で規定されている。

以下は，（ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐゾーンの）ＨＮＲレコードの例である。
ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ＜ＴＴＬ＞ ＩＮ ＤＮＳＫＥＹ ＜ｐｒｏｔｏｃｏｌ ｖａｌｕｅ＞ ＜ｐｕｂｌｉｃ ｋｅｙ ａｌｇｏｒｉｔｈｍ＞ ＜ＨＮＲ ｐｕｂｌｉｃ ｋｅｙ＞
（このＤＮＳＫＥＹレコードは，ＨＮＲレコードに署名するために使用されているＨＮＲの公開鍵の値を提供する。署名は，ＲＲＳＩＧレコードに保存されている。）
ｈｏｓｔ０１♯ ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ＩＮ ＨＩＤ ＦＦＦ−ＦＦＦＦ−０００１−ＦＦ０１−３ＥＡ３−８２Ｄ２−Ｂ９４８−Ｂ３５Ｃ
ｈｏｓｔ０１♯ ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ＩＮ Ａ １３３．２４３．１１９．１９２
ｈｏｓｔ０１♯ ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ＩＮ ＡＡＡＡ ２００１：ＢＥＥＦ：：２００１：１
ｈｏｓｔ０１♯ｅａｓｔ．ｉｄｌｏｃ．ｎｗｇｎ．ｊｐ ＩＮ ＰＫ ＜公開鍵；パラメータはＤＮＳＫＥＹと同様である。）

上記の例では，ＰＫリソースレコード（ＲＲ）タイプは，ホストの公開鍵を保存するために作成されている（ホストに送信されるデータパケットを暗号化するために使用される）。各ＨＮＲレコードは，ＲＲＳＩＧレコードを含んでもよい。

ＨＮＲ登録によるＤＮＲレコードの作成
ＨＮＲ登録メッセージを送信することによって，ＨＮＲは，そのＩＤ，そのＧＬｏｃ，そのＰＫおよび他のパラメータをＤＮＲに保存する。ＨＮＲ登録メッセージの形式は，ＤＮＳ ＵＰＤＡＴＥ［ＲＦＣ２１３６は，「ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２１３６．ｔｘｔ」で入手できる］で規定されている動的ＤＮＳ更新メッセージと同様である。メッセージが途中で変更されること防ぐために，メッセージにはＴＳＩＧ［ＲＦＣ２８４５で規定されており，「ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２８４５．ｔｘｔ」で入手できる］が含まれている。ＴＳＩＧ（Ｔｒａｎｓａｃｔｉｏｎ ＳＩＧｎａｔｕｒｅ）とは，コンピュータネットワークプロトコルである。これは，動的ＤＮＳデータベースへの更新を認証する手段を提供するために，ドメインネームシステム（ＤＮＳ）で主に使用される。

各々のＨＮＲは，権威ＤＮＲを有しており，しかるべき方法を用いて共有秘密鍵を設定している。ＨＮＲは，そのＤＮＲのＩＤおよびＤＮＲのＧＬｏｃ（ネットワーク管理者は，ＨＮＲのセットアップファイルにこれらを保存する）を知っている。一つのＤＮＲは，複数の（すなわちｎ個の）ＨＮＲをサポートすることができる。ｎの値は，ＤＮＲが保持し更新できるＨＮＲレコードの数に依存する。ＨＮＲは，ＨＮＲ登録要求を権威ＤＮＲに送信する。メッセージは，ＨＮＲとＤＮＲの間で共有される秘密鍵を使用して計算されるＴＳＩＧ（［ＲＦＣ２８４５］）で保護されている。

ホスト登録によるＨＮＲレコードの作成
ホストは，図５で規定された形式のホスト登録メッセージを送信することにより，そのホスト名，ＩＤ，ロケータ，ＰＫおよび他のパラメータをＨＮＲに保存する。メッセージは，２つの部分，すなわち基本ヘッダおよびパラメータフィールド，を有する。基本ヘッダは３２バイトのサイズを持ち，以下のフィールドで構成されている。
メッセージタイプ（２バイト）：メッセージのタイプを指定する。ＨＮＲにホスト登録をするために，メッセージタイプは１に設定される。（注：同じメッセージヘッダが，ホスト名解決［メッセージタイプ＝３］と，ＧＷにおけるピアホスト登録［メッセージタイプ＝２］にも使用される。）
メッセージ長（２バイト）：基本ヘッダおよびパラメータの両方を含むメッセージの長さを指定する。
予備（２バイト）：このフィールドは，本発明の将来的な拡張のための予備である。
制御フラグ（２バイト）：このフィールドは，メッセージに関連付けられている追加的な意味を指定するために使用される。各フラグは１ビットの長さである。以下のフラグが定義されている。
メッセージが「要求」メッセージであることを示す場合には，Ｒを１に設定する。Ｒ＝０の場合には，メッセージは応答メッセージである。要求メッセージおよび応答メッセージは，同じシーケンス番号およびアクセスＩＤを有している。
ホスト名，ホストＩＤ，ロケータまたは他のパラメータの「新たな」登録のためのメッセージであることを示す場合には，Ｎを１に設定する。
登録の「更新」のためのメッセージであることを示す場合には，Ｕを１に設定する。
登録の「終了」のためのメッセージであることを示す場合には，Ｔを１に設定する。
ＩＤ，ロケータまたは他のパラメータをＧＷに登録する要求であることを示す場合には，Ｇを１に設定する。
ＩＤ，ロケータまたは他のパラメータをローカルネームサーバ（ＬＮＳ）に登録するための要求であることを示す場合には，Ｓを１に設定する。
ＩＤ，ロケータまたは他のパラメータをＨＮＲに登録する要求であることを示す場合には，Ｈを１に設定する。
送信側が受信側から受信通知を受信することを望むことを示す場合には，要求メッセージのみＡを１に設定する。
「ピア」ホストのホスト名，ＩＤ，およびロケータをＧＷに登録するための要求メッセージでは，Ｐを１に設定する。
シーケンス番号（４バイト）：メッセージのシーケンス番号を指定する。
アクセス識別子（４バイト）：ホストがネットワークに接続する際にアクセスネットワークによって与えられたアクセス識別子を指定する。シーケンス番号とアクセス識別子の組み合わせは，メッセージを一意に識別する。

パラメータフィールドには，１つ以上のパラメータの形式でメッセージ内容が入る。例えば，ホストＩＤ，ロケータ，ＰＫまたは他の情報は，このフィールドに含まれる。各パラメータは，パラメータタイプ（２バイト）とパラメータ長（２バイト）のフィールドを含み，これにパラメータ値が続く。パラメータ値のサイズは，例えばＩＰｖ４のロケータのために４バイト，ＩＰｖ６ロケータために１６バイト，およびホストＩＤのために１６バイト，のように変えることができる。

ホストが上記で指定した新しいネットワークに接続する場合，ホスト（または認証エージェント）は，ホスト名，ホストＩＤ，ロケータ，ＰＫおよびその他のパラメータを含むホスト登録メッセージまたは更新メッセージをＨＮＲに送信する。ＨＮＲは，そのデータベースにホスト情報を保存する。データベースの内容は，ＨＮＲレコードと呼ばれる。

ホスト名解決プロセス
ホスト解決プロセスは，要求（またはクエリ）メッセージおよび応答（または返答）メッセージのシーケンスを含む（図６参照）。これらのメッセージは，アプリケーション層から交換される。ホスト名解決と応答メッセージは，ＤＮＳクエリおよび応答で使用されるのと同じポート番号を使用してもよい。図には，２つの例が含まれている：（１）ＬＮＳが，ターゲットホストのＩＤおよびロケータをＧＷに登録する場合（ホスト登録要求メッセージにおいて，Ｇフラグが１に設定されているため），および（２）送信元ホストが，ターゲットホストのＩＤおよびロケータをＧＷに登録する場合（ホスト登録要求において，Ｇ＝０であるため）。このプロセスは，他のホスト（ターゲットホストと呼ばれるホスト，すなわちＴＨ）のホストＩＤ，ロケータ，またはＰＫについて知ろうとしているホスト（送信元ホストと呼ばれるホスト，すなわちＳＨ）によって開始される。ホスト名解決にあたり，送信元ホストは，最初にターゲットホストのホスト名のみしか知らない。送信元ホストは，ＴＨのホスト名を含むホスト名解決要求を送信し，リソースレコード（ＲＲ）としてＨＮＲからＴＨのＩＤ，ロケータ，およびＰＫを含む応答の返信を受ける。送信元ホストは，ターゲットホストとの通信セッションを開始するために，ターゲットホストのＩＤ，ロケータおよびＰＫを使用する。

ホスト名解決手順の詳細を以下に示す。
（ａ）送信元ホストは，ターゲットホストのＩＤ，ロケータまたはＰＫを得るためのホスト名解決要求を送信する。それは，送信元ローカルネットワークがサポートできるロケータタイプを要求する。（例えば，送信元ローカルネットワークが，ＩＰｖ４（またはＩＰｖ６）プロトコルのみをサポートしている場合には，送信元ホストは，ターゲットホストのＩＰｖ４（またはＩＰｖ６）ロケータのみを取得するためのホスト名解決要求を発行する。送信元ローカルネットワークが，ＩＰｖ４とＩＰｖ６の両方のプロトコルをサポートしている場合には，送信元ホストは，ターゲットホストのＩＰｖ４とＩＰｖ６の両方のロケータを取得するためのホスト名解決要求を発行する。）

（ｂ）ホスト名解決要求は，ネームリゾルバとして働くＬＮＳによって受信される。ＬＮＳは，ターゲットホストが同じネットワーク内に配置されているかどうかを確認するために，まず自身のホストテーブルをチェックする。レコードが見つからなかった場合，ＬＮＳは，ＤＮＲにクエリを送信し，次いで，ＨＮＲにもう一つのクエリを送信ことによって，ＴＨのホスト名を，ＴＨのＩＤ，ロケータおよびＰＫへと解決する。ＤＮＲおよびＨＮＲクエリの両者の形式は，ＤＮＳＳＥＣクエリと同様である。

（ｃ）（ＩＰｖ４とＩＰｖ６の両タイプの）ＨＮＲのＩＤおよびロケータが，ＤＮＲから取得される。送信元ＧＷがグローバルネットワークにおいて１つのプロトコルタイプのみをサポートしているかどうかに基づいて，ＬＮＳは，（ＨＮＲの）ロケータのあるタイプのみを要求することとしてもよい。

（ｄ）同様に，ＬＮＳは，送信元ＧＷがグローバルネットワークインタフェースでサポートしているロケータＲＲタイプを取得するために，ＨＮＲクエリメッセージを発行する。（例えば，ＧＷのグローバルインターフェイスがＩＰｖ４（またはＩＰｖ６）プロトコルのみをサポートしている場合には，ＬＮＳは，ターゲットホストのＩＰｖ４（またはＩＰｖ６）ロケータのみを提供するようＨＮＲに要求する。このようにして，ＬＮＳは，送信元ＧＷが理解することができるターゲットホストのロケータタイプを受け取る。）

（ｅ）ＬＮＳは，ＤＮＳＳＥＣのセキュリティ機能を使用して，ターゲットホストのＲＲの真正性を検証する。

（ｆ）この時点で，ＬＮＳはターゲットホストのＩＤとグローバルロケータを有している。送信元ホストがホスト名解決要求メッセージにＧ＝１を設定していた場合（図７参照）には，ホスト登録要求［メッセージタイプ＝２］を送信することで，送信元ＧＷにそれらを登録することができる。ＧＷは，送信元ホストの対応するホストとして，ＧＷのＩＤテーブルにターゲットホストのＩＤとロケータを追加する。そして，ホスト登録要求メッセージに“Ａ”フラグが設定されていた場合には，ＧＷは応答（または受信通知すなわちＡＣＫ）メッセージをＬＮＳに送信するとしてもよい。ＬＮＳは，シグナリングオーバーヘッドを低減するために，ホスト登録要求のＡフラグの設定を解除してもよい。ＬＮＳとＧＷとの間で交換されるメッセージは，ＬＮＳとＧＷが共有するセキュリティキー（ＬＮＳ−ＧＷｓｈＫｅｙ）によって保護されている。この時点で，ＬＮＳは，ターゲットホストのローカルロケータとして（ピアホスト登録が行われている）ＧＷのローカルロケータを，ＨＮＲから受信した応答に追加し，応答をホストへと転送する。つまり，ローカルリゾルバすなわちＬＮＳは，ターゲットのローカルロケータとして（ＬＬＯＣのＲＲタイプとして），ＧＷのローカルロケータを追加することにより，送信元ホストへ返答する。注：ＬＬＯＣのＲＲタイプはＨＮＲ／ＤＮＲに保存されない。むしろ，エッジネットワークに位置するＬＮＳによって供給される。

（ｇ）ホストから受信したホスト名解決要求においてＧ＝０であった場合には，ＬＮＳは，ターゲットホストのＩＤとＧＬｏｃを送信元ＧＷに登録しない。むしろ，ホスト名解決応答において，ホストにすべてのＧＬｏｃを提供する。ターゲットホストに対する複数のＧＬｏｃが存在する場合には，ホストは，アルゴリズムを用いて，ターゲットホストのロケータ選択を行う。

そして，図８に示すように，ホスト登録要求を送信することにより，選択されたＧＬｏｃをＧＷに登録する。ホストとＧＷの間で交換されたメッセージは，アクセスＩＤを含んでおり，アクセスキーによって保護されている。アクセスＩＤとアクセスキーは，ホストがエッジネットワークに接続中にＡＡから受け取ったものである。シーケンス番号はホストがローカルネットワークエンティティ（ＡＡ，ＬＮＳおよびＧＷ）と交換するための制御パケットの数に依存するシーケンス番号である。ＧＷがホストに応答を送り返す必要がないように（オーバーヘッドを低減するために），ホストは，登録要求メッセージにＡ＝０を設定してもよい。

このように，ホスト名解決によって，送信元ホストは，ターゲットホストのＧＬｏｃを受け取る。送信元ホストがエッジネットワークにおいてグローバルプロトコルを使用する場合にのみ，送信元ホストは，ネットワーク層プロトコルパケットで（パケットネットワークヘッダで）ターゲットＧＬｏｃを使用する。それ以外の場合は，パケットヘッダ内のターゲットホストのＬＬｏｃとして送信元ＧＷのＬＬｏｃを使用し，パケットをＧＷへと転送する。それは，モビリティおよび他のシグナリングメッセージにおいて，ターゲットＧＬｏｃを使用する。

ネットワークアクセスセキュリティ
ネットワークアクセスとは，ネットワークサービスを使用する前に，ユーザデバイスやホストがネットワークに接続されるプロセスである。

背景情報
（数か国にわたる可能性もある）広範囲に広がるインターネットのような大規模ネットワークは通常，２種類ネットワーク，すなわち，エッジネットワークおよびバックボーンネットワーク，で構成されている。エッジネットワークは，ユーザデバイスまたはホストへのネットワーク接続を提供する。一方，バックボーンネットワークは，２つ以上のエッジネットワーク同士を接続する。本発明においては，エッジネットワークはアクセスネットワークとも呼ばれており，バックボーンネットワークはコアまたはグローバルネットワークとも呼ばれている。ローカルネットワークにおけるデバイスのロケータ（すなわち，位置識別子）は，ローカルロケータ（ＬＬｏｃ）と呼ばれており，グローバルネットワークにおけるデバイスのロケータは，グローバルロケータ（ＧＬｏｃ）と呼ばれている。ホストは，ホスト自身のＧＬｏｃとして，ＧＷのＧＬｏｃを使用することを許可されている。

各々のエッジネットワークは，以下の４つのエンティティを有している。つまり，動的ホスト構成プロトコル（ＤＨＣＰ）サーバ，認証エージェント（ＡＡ），ローカルネームサーバ（ＬＮＳ），およびゲートウェイ（ＧＷ）である（これらは，同じマシンに併置することもできるし，あるいは，別々に存在することもできる）。

ＡＡは，ホストがエッジネットワークに接続した際にホストを認証する。ＡＡは，ネットワークアクセス認証サーバの機能を備えている。つまり，ＡＡはホストから認証要求を受信し，これと（ホスト名解決によって得られた）ＨＮＲにおけるホストのレコードとを比較することで，ホスト情報を検証する。ＡＡは，ホストを認証するために，追加的な認証サーバにもコンタクトするとしてもよい。

ＬＮＳは，この時点で，エッジネットワークに接続されているローカルホストの（ホスト名，ＩＤ，ＬＬｏｃ，ＰＫなどを含む）レコードを保存する。

ＧＷは，グローバルネットワークとエッジネットワークを接続している。ＧＷは，そのＩＤテーブルに保存されているＩＤ／ロケータマッピングを使用して，Ｌ３プロトコル変換を提供する（テーブルエントリは，後に説明するホスト登録，またはホスト名解決によって作成される）。

ＤＨＣＰサーバは，初期設定パラメータ（例えば，ホストのＬＬｏｃ，ＡＡのＩＤおよびＬＬｏｃ，ＬＮＳのＩＤおよびＬＬｏｃ，ＧＷのＩＤおよびＬＬｏｃ）をホストに提供する。

これらのエンティティのいずれか２つの間で交換される全てのメッセージは，メッセージに対して計算されたＨＭＡＣ（Ｈａｓｈ−ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）と，共有秘密鍵を使用することによって保護される。我々は，ＡＡ，ＬＮＳ，およびＧＷが，ＡＡ−ＬＮＳｓｈＫｅｙ，ＡＡ−ＧＷｓｈＫｅｙ，とＬＮＳ−ＧＷｓｈＫｅｙに代表される三つの異なる秘密鍵を有していることを前提としている。ＡＡ，ＬＮＳ，およびＧＷは，それらの間で交換されるメッセージを保護するために，これらの秘密鍵を使用する。

初回ホスト登録手順
この節では，ホストが初めてネットワークに接続される手順について説明する。手順は，図９Ａおよび図９Ｂに示されている。これらのメッセージは，アプリケーション層から交換される。これらは，いくつかの未使用のポート番号を使用してもよい。あるいは，それらは，ＩＤレイヤから交換することができる。
ホストは初めてスイッチを入れられると，ホストは最初に（ユーザ名，使用法，日付，場所などに関連する属性を使用して，自身でまたはその所有者／管理者の助けを借りて）そのローカルホスト名，およびそのＰＫを設定する。

その後，ホストは，ＤＨＣＰプロトコル［ＤＨＣＰ］を実行することによって，その周囲にその“ホーム”エッジネットワークを検索する。ＤＨＣＰによって，ホストは，ＡＡ，ＬＮＳ，およびＧＷのＩＤとＬＬｏｃだけでなく，自身の一時ＬＬｏｃを取得する。これらのパラメータを取得した後，認証ステップが開始される。

認証のために，ホストはホスト登録要求をＡＡへ送信する。要求メッセージには，ローカルホスト名と，ブートアクセスＩＤおよびブートアクセスキーなどのセキュリティパラメータが含まれている。［我々は，何らかの他の手段によって（おそらくは初回の鍵割り当て方法によって），ホストがすでにそのホームネットワークからブートアクセスＩＤおよびブートアクセスキーを取得していることを前提としている。ホストは，ホームネットワークとのホストの認証のために，そのブートアクセスＩＤおよびブートアクセスキーを使用する。］

ホストはそのホストＩＤがまだ設定されていないため，ホスト登録要求メッセージには，ホストＩＤが含まれていない。ホスト登録メッセージの形式は，図５に示している。メッセージヘッダにおけるアクセスＩＤは，このメッセージではブートアクセスＩＤに設定されている。

ＡＡは，ホストの真正性を検証し（つまり，ブートアクセスＩＤおよびブートアクセスキーを検証し），新しいアクセスＩＤ（ａｃｃｅｓｓＩＤ）およびアクセスキー（ａｃｃｅｓｓＫｅｙ）をホストに割り当てる。アクセスキーは，後に，ＡＡ，ＬＮＳ，およびＧＷにおいて，自身を認証するためにホストによって使用される。アクセスキーは，それがホストに割り当てられる時にＡＡによって指定されたある一定の有効期間を有している。同じアクセスＩＤは，ホストがエッジネットワークエンティティ（例えば，ＡＡ，ＬＮＳ，およびＧＷ）と交換するすべての制御メッセージにおいて使用される。アクセスＩＤとシーケンス番号（ｓｅｑ．ｎｏ．）の組み合わせは，メッセージを一意に表す。

そして，ホストは，そのホスト名と公開鍵（ＰＫ）を含んだもう一つのホスト登録要求をＡＡに送信する。ＡＡは，ホスト登録メッセージをＨＮＲに転送する。メッセージは，事前に共有された秘密鍵（ＡＡ−ＨＮＲｓｈＫｅｙ）によって保護されている。我々は，“ホーム”ＡＡが，その構成ファイルからＨＮＲのＩＤ，ロケータおよびＡＡ−ＨＮＲｓｈＫｅｙを知っていることを前提としている。

ＨＮＲは，そのドメイン内のホスト名の一意性をチェックし，ドメイン名，ホストＩＤの接頭辞と共有鍵（有効期間内は有効なＨｏｓｔ−ＨＮＲｓｈＫｅｙ）をホストに割り当てる。ＨＮＲは，ホスト名，ＰＫ，およびＨｏｓｔ−ＨＮＲｓｈＫｅｙ（有効期間と共に）をＨＮＲレコードに保存する。そして，ＨＮＲは，ホストのＰＫを用いてＨｏｓｔ−ＨＮＲｓｈＫｅｙとその有効期間を暗号化することで，ホスト登録応答メッセージをＡＡに送信する。ＡＡは，応答メッセージをホストに転送する。

ホストは，そのローカルホスト名およびグローバルドメイン名を連結することによって，グローバルなホスト名を設定する。また，そのグローバルなホスト名をハッシングし，接頭辞，範囲，バージョンラベルを追加することによって，ホストのＩＤを形成する。ホストＩＤの生成についての詳細は，［ＰＬＴ１，特開２００８―３１２１９１］に記載されている。ホストは，ホスト名，ＩＤ，およびＨｏｓｔ−ＨＮＲｓｈＫｅｙ（有効期間と共に）は，ホスト構成ファイルに保存する。そして，ホストは，そのグローバルホスト名，ＩＤ，およびＬＬｏｃを含む，ホスト登録メッセージ［Ｒ，Ｎ，Ｇ，Ｓ，およびＡフラグが１に設定されている］をＡＡに送信することによって，ローカル登録を行う。ＡＡはホスト情報をＧＷおよびＬＮＳに登録する。また，ＧＷは，ホストに対してＧＬｏｃ（これも有効期間を有している）も提供する（注：ＧＬｏｃは，グローバルネットワーク側から取得したＧＷのロケータである）。ＧＷおよびＬＮＳへの登録を終えた後，ＡＡは，ＧＬｏｃを含むホスト登録応答メッセージをホストに返信する。

ホストは，そのＧＬｏｃをその構成ファイルに保存し，ＡＡを介してホスト登録メッセージを送信することによって，ＨＮＲレコードの更新を行う。これにより，ホストの初回ネットワークアクセス手順と，ＨＮＲおよびホームエッジネットワークにおける登録が完了する。この時点で，ホストが他のホストとの通信のための準備ができている。ホストは，以下の段落で説明するネットワークアクセス手順を実行して，他のエッジネットワークに移動することもできる。

ネットワークアクセスセキュリティは，エッジネットワークへの接続をホストに許可する前に，ホストの認証を提供する。上の段落で説明したようにＨＮＲにおけるホスト登録が完了した後，ホストは，新しいエッジネットワーク（ホストのホームネットワークとは異なっていてもよい）に移動することができ，以下の段落で説明するようなネットワークアクセス手順を用いて新しいネットワークに接続されることができる。

ネットワークアクセス手順
この節では，ホストがネットワークに接続される手順について説明する。手順は，図１０Ａおよび図１０Ｂに示されている。これらのメッセージは，アプリケーション層から交換される。ＤＨＣＰは，クライアントのためにポート番号４４６を使用し，サーバプロトコルのためにポート番号４４７を使用する。いくつかの未使用のポート番号は，ホスト登録メッセージのために使用されることができる。あるいは，ホスト登録メッセージは，識別層から交換されることができる。この手順のステップは，ホストの初回登録のために前節に記載したものと同様である。以下の段落では，異なる点についてのみ説明する。

認証のためにホストによって送信された第一のホスト登録メッセージには，そのグローバルホスト名，ＩＤ，ＰＫおよび一つ以上の完全性アルゴリズムのタイプが含まれている。完全性アルゴリズムは，ＡＡ，ＧＷ，およびＬＮＳと交換される後続のメッセージを保護するＨＭＡＣを計算するのにホストが使用しようとする。

（ホスト解決プロセスを通じてＨＮＲからホストレコードを取得することによって）ホストＩＤを検証した後，ＡＡは，ホストによって提供されたリストから適切な完全性アルゴリズムを選択する。完全性チェックアルゴリズムは，ＨＭＡＣ−ＳＨＡ１［ＲＦＣ２４０４で規定されており，「ｈｔｔｐ：／／ｗｗｗ.ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２４０４．ｔｘｔ」から入手できる］であってもよい（ＨＭＡＣアルゴリズムは，ＲＦＣ２１０４で定義されており，「ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２１０４．ｔｘｔ」から入手できる）。ＡＡは，アクセスＩＤおよびアクセスキーをホストに割り当てもする。ホスト応答メッセージでは，ホストのＰＫによってアクセスキーが暗号化されている。

ＡＡから認証された後，ホストは，ローカル登録およびＨＮＲ更新プロセスを実行する。これらは，前のセクションで説明したホームネットワークへの初回登録で実行されたプロセスと同様である。

ホストとネットワーク間のセキュリティアソシエーションの有効期間が満了しようとする時，ホストは，ホスト登録メッセージをＡＡに送信することによってそれを更新する。また，ＡＡは，図１０Ａと図１０Ｂに示されているローカル登録と同様のプロセスによって，ＧＷおよびＬＮＳに保存されているホスト情報の更新やアップデートを行う。同様に，ホストが（プロアクティブに，すなわちｍａｋｅ−ｂｅｆｏｒｅ−ｂｒｅａｋハンドオーバーに）別のアクセスネットワークに移動している時には，図１０Ａおよび図１０Ｂに示すように，グレースフルな切断またはプロセスの終了が実行される。

ホスト間通信のセキュリティ
送信元ホストがターゲットホストと通信しようとする場合には，前者はまず，前のセクションで説明したようにホスト名解決手順を用いることによって，ターゲットホストのホスト名を解決する。そして，送信元ホストは，共有秘密鍵などのセキュリティパラメータを折衝するのと同様にして，そのホスト名，ＩＤおよびロケータを知らせるために，制御シグナリングパケットをターゲットホストと交換する。セキュリティパラメータは，ホストが，ホスト間で交換されるシグナリングとデータパケットを保護するために使用するセキュリティコンテキストを構成する。これらの制御パケットは，アプリケーション層から，または識別層のいずれかから交換することができる。それは実装に依存している。しかし，我々は，識別層における実装が，より効果的であると考えている。

識別層プロトコルは，すべての制御パケットとデータパケットに，ＩＤヘッダを添付する。ＩＤヘッダの形式は，以下に規定され，図１１に示されている。

識別ヘッダ
識別ヘッダすなわちＩＤヘッダは，２つの部分，すなわち基本ヘッダおよびオプショナルなパラメータを有する。

基本ヘッダのサイズは４０バイトである。オプショナルなパラメータは，可変サイズのものとすることができる。オプショナルなパラメータフィールドには，識別層から発生した制御情報（例えば，追加のロケータ，セキュリティ関連のパラメータ）が入る。これには，データパケットを保護するために，認証データや完全性チェック値が入る。また，ホスト登録手順がアプリケーション層の代わりに識別層に実装されている場合には，ホスト登録制御メッセージも入る。

基本ヘッダは，以下のフィールドを有する。

次ヘッダ（１バイト）：パケットペイロード（通常はトランスポートプロトコル番号）において次のヘッダのプロトコル番号を指定する。ペイロードがない場合には，次ヘッダ＝ＮＯ＿ＮＸＴ＿ＨＤＲ（５９）である。
ヘッダ長（１バイト）：オプショナルなパラメータを含むＩＤヘッダの長さを指定する。
Ｐ（１ビット）：パケットが任意の上位層ペイロードを含んでいる場合を指定する場合には，１に設定される。
タイプ（７ビット）：識別層のパケットタイプ（ｐタイプ），すなわち，パラメータフィールドが有する制御メッセージのタイプ，を指定する。
バージョン（４ビット）：識別層プロトコルのバージョンを指定する。
Ｃ（１ビット）：ＩＤヘッダが制御メッセージ（パラメータフィールドが有する）を有する場合には，１に設定される。
チェックサム（２バイト）：パラメータフィールドが有するＩＤ基本ヘッダや制御メッセージをカバーするチェックサムを指定する。
制御フラグ（２バイト）：ＩＤの性質や，ロケータとそれらのマッピング（持続的／一時的，アノニマス等）などの追加的な制御情報を指定する。二つのフラグＳとＡは，以下のように定義されている。Ｓ＝１は，識別層に実装されたセキュリティ機能が使用されていることを示している。Ａ＝１は，送信元ホストが送信先ホストに１パケットのみを送信しようとしており，したがって，送信先ホストまたはＧＷは，送信元ホストのＩＤ／ロケータマッピングを保存する必要が無いということを示している。

+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +
｜Ｓ｜ 予備 ｜Ａ｜
+ - + - + - + - + - + - + - + - + - + - + - + - + - + - + - + - +

送信元ＩＤ（１６バイト）：送信元ホストＩＤを含んでいる。

送信先ＩＤ（１６バイト）：送信先ホストＩＤまたはターゲットホストＩＤを含んでいる。

以下において，我々は，セキュリティを除き，セキュリティパラメータ折衝手順を含む，ホスト間の通信セッションを開始する手順を説明する。

通信セッション確立手順（セキュリティパラメータ折衝を除く）：
ネットワークアプリケーションが，識別層からのセキュリティサービスを要求しない場合には，通信セッションを確立するために交換される制御パケットのシーケンスは，図１２に示されており，以下に説明する。

送信元ホスト内のアプリケーションは，ターゲットホスト名解決をした後，送信元および送信先ＩＤ，およびトランスポートプロトコルのポート番号を使用してソケットを識別することによって，（ソケットＡＰＩ（ａｐｐｌｉｃａｔｉｏｎ ｐｒｏｇｒａｍ ｉｎｔｅｒｆａｃｅ）におけるセキュリティオプション無しで）ソケットをオープンにする。

送信元識別層は，通信初期化要求メッセージを送信する。通信初期化要求メッセージは，送信元および送信先のＩＤとして，識別ヘッダに送信元ホスト（ＳＨ）とターゲットホスト（ＴＨ）のＩＤを含み，識別ヘッダパラメータフィールド中にＳＨのホスト名，およびＳＨとＴＨのＧｌｏｃを含み，Ｓフラグが０であり，ｐタイプが１である。ネットワーク層ヘッダにおいて，ＳＨのＬＬｏｃとＳ−ＧＷのＬＬｏｃは，送信元および送信先ロケータフィールドで使用されている。

パケットが送信元ＧＷ（Ｓ−ＧＷ）に到達すると，ＳＨとＴＨのＩＤ／ＧＬｏｃマッピングの両方が含まれているそのＩＤテーブルを使用して，ネットワーク層ロケータ（プロトコル）がグローバルロケータへ変換され，パケットをターゲットＧＷ（Ｔ−ＧＷ）へと転送する。

Ｔ−ＧＷは，ＴＨのＩＤ／ＬＬｏｃマッピングを取得するために，Ｔ−ＧＷのＩＤテーブルを参照することによって，ネットワーク層ヘッダを再度変換する。それは，ネットワークヘッダにおいて，ＴＨのＬＬｏｃを送信先ロケータとして使用し，自身のＬＬｏｃを送信元ロケータとして使用する。そして，パケットはＴＨに転送される。Ｔ−ＧＷのＩＤテーブルには，まだ，ＳＨのＩＤ／ＧＬｏｃマッピングが含まれていないことに注意されたい。このマッピング無しでは，ＴＨは，応答をＳＨに返信することはできない。ＳＨのＩＤ／ＧＬｏｃをＴ−ＧＷに登録するための方法としては，暗黙的ピアホスト登録（図１２）または明示的ピアホスト登録（図１３）の２つの方法がある。

暗黙的ピアホスト登録方法：
グローバルネットワークから受信したパケットの識別ヘッダにおいて，Ｔ−ＧＷは，まず，ｐタイプフィールドの値をチェックする。ｐタイプが１であった場合には，Ａフラグをチェックする。Ａ＝０であった場合には，ＳＨのＩＤ／ＧＬｏｃ（ＩＤは，識別ヘッダの送信元ＩＤフィールドに記載されており，ＧＬｏｃは，識別ヘッダパラメータフィールドに記載されている）がそのＩＤテーブルにキャッシュされる。そして，Ｔ−ＧＷは，（送信先ロケータフィールドにおけるＴＨのＬＬｏｃと，送信元ロケータフィールドにおける自身のＬＬｏｃを使用することによって）ネットワークヘッダを変換し，パケットをＴＨに転送する。

明示的ピアホスト登録方法：
Ｔ−ＧＷは，Ｔ−ＧＷのＩＤテーブルに，ＳＨのＩＤ／ＧＬｏｃを保存するために，ＴＨからの明示的なシグナリングを必要とする。この方法では，ＴＨが通信初期化要求パケット（ｐタイプ＝１）を受信した場合に，ホスト名解決セクションにてすでに記載したピアホスト登録を行う。

これらの方法はどちらも長所と短所がある。暗黙的な方法は，ターゲットホストからのシグナリングを低減させるためには良いが，セキュリティ攻撃に対して脆弱である可能性がある。明示的な方法は，ターゲットホストが送信元ホストと通信しようと決定するまで，ＧＷが送信元ホストのＩＤ／ＧＬｏｃマッピングを保存しないという意味で，ＧＷのためにはより良い。通信しようとしない場合には，ピアホスト登録は行われない。また，ＴＨが複数のＧＬｏｃを有し，新たなＧＬｏｃ（ＳＨが通信初期化メッセージにて通知したものとは異なる）を望む場合，明示的なシグナリング方法は適切であり，新しいＧＬｏｃのためのエントリポイントである別のＧＷに，ピアホスト登録を行うことができる。

ＴＨがネットワークに接続する時に，ＴＨとＴ−ＧＷは，ピアホスト登録方法について折衝する。

通信初期化要求パケットを受信した後，ＴＨは，ＳＨのＩＤ，ＧＬｏｃとＬＬｏｃ（すなわち，Ｔ−ＧＷのＬＬｏｃ）をそのＩＤテーブルに追加する。そして，その識別ヘッダがｐタイプ＝２，Ｓ＝０，Ａ＝０である通信初期化応答メッセージを構成する。識別ヘッダパラメータフィールドは，（ＴＨが複数のＧｌｏｃを有する場合には）ＴＨの追加的なＧＬｏｃを含んでもよい。応答メッセージは，送信元ロケータおよび送信先ロケータに，ＴＨのＬＬｏｃと，Ｔ−ＧＷのＬＬｏｃを有している。そして，パケットは，Ｔ−ＧＷに送信される。Ｔ−ＧＷは，そのＩＤテーブルを用いてネットワークヘッダを変換する。このようにして応答パケットはＳＨに到達する。

通信初期化応答を受信した後，ＳＨは，ＴＨの追加的なＧＬｏｃ（もしあれば）を，そのＩＤテーブルに追加する（ＴＨの追加的なＧＬｏｃにパケットを送信しようとする場合には，ＳＨは，Ｓ−ＧＷへのピアホスト登録も行う）。こうして，ＳＨは，識別ヘッダｐタイプ＝０ｘ８０，パラメータなしを設定することによって，データパケットの送信を開始する。これらのパケットは，Ｓ−ＧＷおよびＴ−ＧＷを経由してＴＨに到達する。Ｓ−ＧＷおよびＴ−ＧＷでは，これらのパケットは，ネットワークヘッダ変換を受ける。

通信セッション確立手順（セキュリティパラメータ折衝を含む）：
ネットワークアプリケーションが，識別層のセキュリティ機能を必要とする時には，通信初期化フェーズにおいて４つの制御パケットを交換することによって，送信元ホストとターゲットホストが，セキュリティパラメータ（セッション秘密鍵および完全性アルゴリズムなど）を折衝する。４つの制御パケットは，図１４に示されている。

最初の二つの制御パケットは，前節において交換されたものと同様である。ＩＤ基本ヘッダに存在するホストＩＤの値と，ネットワークヘッダにおけるロケータは，前節で述べたものと同じである。

通信初期化要求メッセージには，送信元ホストのＰＫおよび完全性アルゴリズムリスト（ＨＭＡＣ−ＳＨＡ１およびＨＭＡＣ−ＳＨＡ２５６など）も含まれている。これらは，４つの制御パケットの後で交換されるデータパケットを保護するために認証データまたは完全性チェック値を計算するのと同様，制御パケットを保護するためのＨＭＡＣを計算するのに使用することができる。Ｓフラグは，１に設定される。前述したように，通信初期化パケットは，ネットワーク層プロトコル変換を受けてＳ−ＧＷおよびＴ−ＧＷを通過する。

通信初期化要求を受信すると，ターゲットホストは，選択された完全性アルゴリズムだけでなく，ＳＨのＩＤ，ＧＬｏｃ，ＰＫおよびＬＬｏｃ（すなわち，Ｔ−ＧＷのＬＬｏｃ）も一時バッファに保存する。そして，その識別ヘッダがｐタイプ＝２，Ｓ＝１，Ａ＝０である通信初期化応答１メッセージを構成する。識別ヘッダパラメータフィールドは，ＴＨの追加的なＧＬｏｃを含んでもよい（ＴＨが複数のＧｌｏｃを有している場合）。メッセージは，ＴＨの秘密鍵でパケットを署名することによって保護される。署名（ＳＩＧ）は，ＩＤヘッダのパラメータフィールドに含まれている。そして，パケットは，ＳＨに送信される。

ＳＨは，ホスト間で交換されるパケットを保護するために使用される秘密セッション鍵（ｓｅｓｓＫｅｙ）を生成する。有効期間もｓｅｓｓＫｅｙに関連付けられている。そして，ＳＨは，ＴＨのＩＤ，ＰＫ，ｓｅｓｓＫｅｙ，およびその有効期間は，一時バッファに保存する。その後，ＴＨのＰＫで暗号化されたｓｅｓｓＫｅｙを含む通信初期化応答２メッセージが構成される。メッセージは，ＳＨの秘密鍵によって署名され，ＴＨに送信される。

ＳＨの同一性を検証するために，ＴＨは，ＳＨから受け取ったＳＨのホスト名，ＩＤおよびＰＫを，ホスト名解決プロセスを行うことによってＳＨのＨＮＲから取得した同様の値と比較する。検証が成功した場合には，ＴＨは，ＳＨのパラメータを含む一時バッファを，セキュリティアソシエーションテーブル（ＳＡＴ）にコピーする。また，通信初期化応答２メッセージで受信したｓｅｓｓＫｅｙと関連する有効期間をＳＡＴに追加する。そして，セッション開始プロセスの結果を含めることによって，通信初期化完了メッセージを構成する。メッセージはｓｅｓｓＫｅｙを用いて計算されたＨＭＡＣを含めることによって保護される。通信初期化完了メッセージは，ＳＨに送信される。

ＳＨは，ＴＨが送信元ホストからの接続要求を受け入れたかどうかを判断するために，通信初期化完了メッセージ内の結果パラメータを検証する。ＴＨが通信初期化応答メッセージ２でＳＨが提案したものからｓｅｓｓＫｅｙの有効期間の値を変更した場合、その値を含んでいてもよい。結果が可である場合には，ＳＨは，セキュリティパラメータを含んでいる一時バッファを，ＳＨのＳＡＴにコピーする。

Ｔ−ＧＷおよびＳ−ＧＷにおけるピアホスト登録はシーケンスに示していないが，前節で述べたように実行される。そして，送信元ホストは，折衝されたセキュリティパラメータを用いて計算された認証データまたは完全性チェック値をそのＩＤヘッダに含むデータパケットの送信を開始する。我々は，この機能をＩＤｓｅｃと呼んでいる。

ＩＤｓｅｃ−識別層からのデータパケットのセキュリティ
前節で説明した通信初期化プロセスを用いてホストにおいて確立されたセキュリティコンテキストは，データパケットの完全性および発信元の認証を提供するために使用される。

図１５に示すように，データパケットのシーケンス番号と完全性チェック値（ＡＵＴＨ＿ＤＡＴＡ）は，ＩＤヘッダのパラメータフィールドに含まれている。ＩＤヘッダ基本フィールド：Ｓ＝１；ｐタイプ＝ＩＤｓｅｃヘッダ（０ｘ８１）である。

ＡＵＴＨ＿ＤＡＴＡとは，通信初期化フェーズ中に折衝された完全性アルゴリズムを使用して，ＩＤヘッダ（認証データフィールド値は，この計算のためにゼロに設定されている）と上位レベルのペイロードに対して計算されたＨＭＡＣである。アルゴリズムは，ＨＭＡＣ−ＳＨＡ１［ＲＦＣ２４０４で規定されている］であってもよい。

ＩＤｓｅｃ認証ヘッダを持つパケットを受信すると，受信側は，必要なセキュリティパラメータに対するＳＡＴを参照することによって，パケットの完全性の検証と，送信元の認証を実行する。

［実施例２］
ＨＩＭＡＬＩＳアーキテクチャは，エッジネットワーク，グローバルトランジットネットワーク，および論理制御ネットワークから構成されており，図１に同様である。

エッジネットワーク
エッジネットワークは，様々なエンドシステムやホストへのネットワークアクセスを提供する。エッジネットワークの各々は，例えば，異なる第３層，すなわち，Ｌ３プロトコルを使用してもよい。エッジネットワークは，以下のエンティティで構成されている。つまり，ゲートウェイ（ＧＷ），ローカルネームサーバ（ＬＮＳ），認証エージェント（ＡＡ），およびホストである。

ＧＷは，エッジネットワークをグローバルトランジットネットワークと接続する。ＧＷは，そのＩＤテーブルに保存されているＩＤ／ロケータマッピングを使用することによって，Ｌ３プロトコル変換（エッジネットワークが，トランジットネットワークとは別のＬ３プロトコルを使用している場合）および／またはロケータ変換（エッジネットワークが別のネットワークロケータスペースを使用する場合）を行う。データパケットは，ＩＤヘッダ内およびネットワークヘッダ内のそれぞれの，送信元および送信先ＩＤ，およびロケータの両方を有する。ＡＡは，エッジネットワークに接続する時に，アクセス制御機能を提供する，すなわち，ホストを認証する。つまり，ＡＡは，ホストから認証要求を受信し，これと，ホストネームレジストリ（ＨＮＲ）に保存されているホストのレコードと比較することによって，ホスト情報を検証する。ＬＮＳは，すべてのローカルホストのホスト名，ＩＤ，ローカルロケータ（ＬＬｏｃ）および公開鍵（ＰＫ）をホストテーブルに保存する。ＡＡ，ＬＮＳ，およびＧＷは，同じ信頼ドメインに属しており，それらの間で交換されるメッセージを保護するために，ペアごとの共有秘密鍵を有している。つまり，これらのエンティティ間で交換されるいかなるメッセージも，メッセージに対して計算されたＨＭＡＣ（Ｈａｓｈ−ｂａｓｅｄ Ｍｅｓｓａｇｅ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ Ｃｏｄｅ）と，共有秘密鍵と，を使用することによって保護されている。

ホストは，そのホスト名，ＩＤ，およびＰＫを有しており，エッジネットワークからホストのローカルロケータおよびグローバルロケータを取得する。ホスト名は，二つの部分，ローカルホスト名およびグローバルドメイン名を有しており，「＃」記号によって互いに接続されている。ホスト名の例は，ｍｙｈｏｓｔ＃ｍｙｄｏｍａｉｎ．ｃｏｍである。ｍｙｈｏｓｔはローカルな部分であり，ｍｙｄｏｍａｉｎ．ｃｏｍは，グローバルドメイン名である。ホスト名は世界的に唯一のものである。ホスト名とＩＤの設定方法の詳細は，“［ＨＩＭＡＬＩＳ］ ＨＩＭＡＬＩＳ：Ｈｅｔｅｒｏｇｅｎｅｉｔｙ Ｉｎｃｌｕｓｉｏｎ ａｎｄ Ｍｏｂｉｌｉｔｙ Ａｄａｐｔａｔｉｏｎ ｔｈｒｏｕｇｈ Ｌｏｃａｔｏｒ ＩＤ Ｓｅｐａｒａｔｉｏｎ ｉｎ Ｎｅｗ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ，ＩＥＩＣＥ Ｔｒａｎｓａｃｔｉｏｎ ｏｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ，Ｖｏｌ．Ｅ９３−Ｂ，Ｎｏ．３，Ｐｐ．４７８−４８９，Ｍａｒｃｈ ２０１０．”に記載されている。ホストがエッジネットワークに接続する時には，エッジネットワーク内でのルーティングおよびパケットの転送のために，エッジネットワークのＬ３プロトコルによって使用されるロケータの名前空間の空間からそのＬＬｏｃを取得する。また，ホストは，ホストのグローバルロケータ（ＧＬｏｃ）を取得し，これは実際にはグローバルトランジットネットワークによって割り当てられたＧＷのグローバルロケータである。ホストは，パケットのＬ３プロトコルヘッダにおいてそのＬＬｏｃのみを使用し，一方で，セッションの確立とモビリティシグナリングのためにＧＬｏｃを使用する。ホストは，それ自身とピアホストのＩＤ，ロケータ，ＰＫ，およびパラメータを含むセキュリティアソシエーションテーブル（ＳＡＴ）を維持する。

ＧＷ，ＬＮＳ，およびＡＡに加えて，エッジネットワークは，ＧＷ，ＡＡおよびＬＮＳのＩＤとロケータなどの初期設定パラメータをホストに提供する別の機能エンティティをも含んでいる。動的ホスト構成プロトコル（ＤＨＣＰ）またはルータ広告は，この目的のために使用することができる。

グローバルトランジットネットワーク
グローバルトランジットネットワークとは，あるエッジネットワークから別のエッジネットワークへとパケットを転送するために使用される，同一のネットワーク層プロトコル（グローバルネットワーク層プロトコルと呼ばれる）およびグローバルロケータのための単一の番号スペースを使用するサービスプロバイダーのバックボーンネットワークの集合体である。グローバルネットワークは，パケットヘッダ内の送信先ロケータに基づいて，パケットを転送するための高速リンクとルータで構成されている。ネットワークプロトコル変換は，ルータで発生しない。つまり，エッジネットワークとトランジットネットワークの境界に位置するＧＷのみが，その境界を越えて広がる通信のために，ローカルネットワーク層プロトコル（および／またはＬＬｏｃ）を，グローバルネットワーク層プロトコル（および／またはＧＬｏｃ）へ，およびその逆へ，と変換する。

論理制御ネットワーク
論理制御ネットワークは，ホスト名，ＩＤ，ＧＬｏｃおよびセキュリティキーマッピングレコードを保存し提供するために，ＤＮＲ（Ｄｏｍａｉｎ Ｎａｍｅ Ｒｅｇｉｓｔｒｙ）とＨＮＲからなるホスト名解決システムを含んでいる。ＤＮＲは，ドメイン名と，ＨＮＲのＩＤおよびロケータとの間のマッピングを保存する。一方，ＨＮＲは，ホスト名と，ホストのＩＤ，ＧＬｏｃおよびＰＫとの間のマッピングを保存する。ＨＮＲは移動しないため，ＤＮＲレコードは大抵は静的である。一方，ホストが移動に応じてそれらのＧＬｏｃを変更した時にＨＮＲレコードが更新される必要があるため，ＨＮＲレコードは動的である。各ドメイン名に対して，グローバルホスト名におけるドメイン名を共有するすべてのホストのレコードを保存する少なくとも一つの権威ＨＮＲが存在している。ＤＮＳ構造は，静的マッピング情報を保存および取得するのに適しているので，ＤＮＲは，ＤＮＳのものと同様の階層構造で構築されている。ＨＮＲは，フラットな構造を持っている。

提案されたセキュリティ方式は，ＨＮＲを信頼できるアンカーポイントとする。これにより，ＨＮＲレコードの使用すればネットワークアクセス，通信セッション，およびモビリティが安全となる。つまり，エッジネットワークは，ホストがネットワークにアクセスすることを許可する前に，ホストを認証するためにＨＮＲから取得したホストのレコードを使用する。同様に，ホストは，別のホストと安全な通信セッションを確立する前に，その別のホストを認証するためにその別のホストのレコードを利用することができる。同様に，ネットワークアクセスおよび通信セッションセキュリティ機能を組み合わせることにより，モビリティプロセスを安全にすることができる。我々は，次節において，これらのセキュリティ機能について説明する。

マッピング登録および取得セキュリティ
この段落と次の段落では，ＤＮＲとＨＮＲにおけるＩＤ／ロケータマッピングレコードの登録および更新のためのセキュリティ機能について説明する。取得に対しても同様である。

登録と更新
メッセージの完全性を保護するためのＴＳＩＧ（ｔｒａｎｓａｃｔｉｏｎａｌ ｓｉｇｎａｔｕｒｅ）［ＲＦＣ２８４５］を使用して，ＤＮＳ ＵＰＤＡＴＥ［ＲＦＣ２１３６］によってＤＮＳＳＥＣ［ＲＦＣ４０３５］のリソースレコード（ＲＲ）が作成されるのと同様の方法で，ＤＮＲレコードは，ＨＮＲによって作成され，または更新される。次のセクションで説明する手順を用いてホストがエッジネットワークに接続する時に，ホストによってＨＮＲレコードが作成され，または更新される。ＤＮＲとＨＮＲの両者は，ＤＮＳリソースレコードと同様の形式でそれらのレコードを保存する。

ＤＮＲおよびＨＮＲレコード取得セキュリティ
ＨＮＲレコードは，図１６に示すように，要求（またはクエリ）および応答（または返答）のシーケンスを含むホスト名解決手順を実行することによって取得される。矢印は，メッセージがあるエンティティから別のエンティティへと流れることを示しており，角括弧内の値は，メッセージに含まれるパラメータを示している。この手順は，別のホストとのセッションを開始するために別のホスト（ターゲットホストと呼ばれる）のＩＤ，ロケータ，およびＰＫについて知ろうとしているホスト（送信元ホストと呼ばれる）によって開始される。ホスト名解決のために，送信元ホストは，最初は，ターゲットホストのホスト名のみを知っている。送信元ホストは，ターゲットホスト名を含むホスト名解決要求を送信し，そして，ＨＮＲからターゲットホストのＩＤ，ロケータ，およびＰＫを含む返答を受信する。

ホスト名解決手順を以下に示す。送信元ホストは，共有アクセスキーを使用して計算されたＨＭＡＣによって保護されたホスト名解決要求を，ＬＮＳ（ローカルリゾルバとも呼ばれる）に送信する。リゾルバは，ターゲットホストが同じエッジネットワーク内に位置しているかどうかを確認するために，まず自身のレコードをチェックする。レコードが見つからなかった場合には，まずＤＮＲにクエリを送信することで，ホスト名を解決し，次いでＨＮＲにもう一つのクエリを送信する。ＤＮＲおよびＨＮＲ両者のクエリの形式は，ＤＮＳＳＥＣクエリと同様である。ＤＮＲからＨＮＲのＩＤとロケータが得られ，同時に，ＨＮＲから，ターゲットホストのＩＤ，ＧＬｏｃ，およびＰＫ，これらのレコードの真正性および完全性を検証するために必要な鍵と署名が得られる。ＬＮＳは，ＤＮＳＳＥＣのセキュリティ機能を使用してＲＲの真正性を検証する。ＬＮＳは，ＤＮＲレコードをキャッシュしてもよいが，ＨＮＲレコードをキャッシュしなくてもよい。

ＬＮＳは，ＨＭＡＣによって保護されているホスト名解決応答メッセージにおいて，ターゲットホストのＲＲを送信元ホストへと転送する。送信元ホストは，送信元ホストのセキュリティアソシエーションテーブル（ＳＡＴ）にＲＲを保存し，メッセージ内のターゲットロケータパラメータフィールドをチェックすることによって，送信元エッジネットワークの外にターゲットホストが位置していることを知る。そして，アクセスキーを使用して計算されたＨＭＡＣによって再度保護されたホスト登録メッセージを送信することによって，ターゲットホスト名，ＩＤ，およびＧＬｏｃ（複数のＧＷを有している場合には，そのうちの一つが，ＧＷ選択アルゴリズムに基づいて選択される）を送信元ＧＷに登録する。ＧＷは，ターゲットホストのＩＤとＧＬｏｃをそのＩＤテーブルに追加し，そして，ホスト登録要求メッセージにａｃｋフラグ“Ａ”が設定されていた場合には，応答（すなわちａｃｋ）を送信元ホストに送信する。送信元ホストは，ターゲットホストのＬＬｏｃとしてＧＷのＬＬｏｃを使用しており，それに応じて，発信パケットをＧＷに送信し，ＧＷは，パケットヘッダ内のＬ３プロトコルまたはロケータを変換するためのターゲットホストのＧＬｏｃを見つけるために，そのＩＤテーブルを検索する。

別の方法として，ＬＮＳはターゲットホストの情報を送信元ＧＷに登録することができるが，それは，ホスト名解決要求メッセージにフラグを設定することによって［フラグＧ＝１を設定することによって］送信元ホストがそれを選択した場合である。ＬＮＳは，ＨＭＡＣによってメッセージを保護するために，ＧＷとの共有鍵を使用する。

制御メッセージの形式
ホストによってアクセスネットワークエントリとの間で，またはＨＮＲとの間で交換される制御メッセージのヘッダは，図１７に示す。基本ヘッダは１６バイト長と６つのフィールドで構成されている。つまり，タイプ（２バイト），長さ（２バイト），予備（２バイト），制御フラグ（２バイト），シーケンス番号（４バイト），およびアクセス番号（４バイト）である。メッセージタイプは，例えば，ホスト登録のためには１，ピアホスト登録のためには２，ホスト名解決のためには３などのメッセージのタイプを指定する。メッセージ長は，基本ヘッダおよびパラメータの両者を含むメッセージの長さを指定する。制御フラグは，メッセージに関連付けられている追加的な意味を指定する。Ｒ（要求のためには１／返答のためには０），Ｎ（新規登録），Ｕ（更新登録），Ｔ（登録の終了），Ｇ（ＧＷへの登録），Ｓ（ＬＮＳへの登録）Ｈ（ＨＮＲへの登録），Ａ（ａｃｋ要求），およびＰ（ピアホスト登録）といったフラグビットが定義される。シーケンス番号はメッセージのシーケンス番号を指定し，アクセス識別子は，ネットワークアクセス時にホストがエッジネットワークから取得するホストのアクセスＩＤを指定する（後述する）。シーケンス番号とアクセス識別子の組み合わせは，メッセージを一意に識別する。

パラメータフィールドには，一つ以上のパラメータ形式でメッセージ内容が入る。例えば，ホストＩＤ，ロケータ，ＰＫまたは他の情報は，このフィールドに含まれる。パラメータは，ＴＬＶ形式，すなわち，タイプ（１バイト），長さ（１バイト）と値（可変サイズ）で規定されている。

ネットワークアクセスセキュリティ
ネットワークアクセスセキュリティ機能は，ホストを認証し，自身の情報（主にＩＤおよびロケータ）を，ＡＡ，ＬＮＳ，ＧＷ，およびＨＮＲに安全に登録するためのものである。ホストには，アクセス識別子（ａｃｃｅｓｓＩＤ）およびアクセスキー（ａｃｃｅｓｓＫｅｙ）も与えられており，これらは，メッセージおよびアクセスキーに対して計算されたＨＭＡＣを含めることによって，後に続くシグナリングメッセージを保護するために使用される。図１８Ａおよび図１８Ｂに示すように，ネットワークアクセス手順は，４つのステップ，すなわち，初期設定，認証，ローカル登録，およびＨＮＲの更新から成る。ＡＡ，ＬＮＳ，およびＧＷは同じ信頼ドメインに属しているため，我々は，ＡＡ，ＬＮＳ，およびＧＷが，これらの間で交換されるメッセージを保護するために使用される，事前に共有された秘密鍵，ＡＡ−ＧＷｓｈＫｅｙ，ＡＡ−ＮＳｓｈＫｅｙ，およびＬＮＳ−ＧＷｓｈＫｅｙを有していることを前提としている。

ホストがその周囲でエッジネットワークを利用可能であることを検出すると，ホストは，ＤＨＣＰを実行することまたはルータ広告を経由することによって，ＡＡ，ＬＮＳ，およびＧＷのＩＤおよびＬＬｏｃとともに，自身のＬＬｏｃなどの初期設定パラメータを取得する。これらのパラメータを取得した後，ホストは，ホスト登録要求をＡＡに送信することによって認証フェーズに入る。要求メッセージには，グローバルホスト名，ＩＤ，ＰＫ，およびホストがＡＡ，ＧＷ，およびＬＮＳと交換される後続のメッセージを保護するためのＨＭＡＣを計算するために使用することを求める一つ以上の完全性チェックアルゴリズムのタイプが含まれる。（先に説明したように，ホスト名解決の手順を通じて，ＨＮＲからホストレコードを取得することによって）ホストの同一性を確認した後，ＡＡは，適切な完全性チェックアルゴリズムを選択する。これは，ＨＭＡＣ―ＳＨＡ１であってもよい。ＡＡはまた，アクセスＩＤと秘密のアクセスキー（一定の有効期間を有する）を割り当て，ホストのＰＫで暗号化されたアクセスキーを含むホスト登録応答メッセージをホストに返信する。前述したように，アクセスキーは，ホストがエッジネットワークエンティティ，すなわち，ＡＡ，ＬＮＳ，およびＧＷとの間で交換する制御メッセージを保護するために使用される。

そして，ホストは，ＬＮＳおよびＧＷに登録されているそのホストのホスト名，ＩＤ，ＰＫ，およびＬＬｏｃを所有するために，もう一つのホスト登録要求をＡＡに送信することによって，ローカルの登録フェーズに入る。ホストのこの意図は，メッセージヘッダにＧおよびＳフラグを設定することによって示される。続いて，ＡＡは，秘密鍵であるＡＡ−ＧＷｓｈＫｅｙおよびＡＡ−ＮＳｓｈＫｅｙを使用して計算されたＨＭＡＣで保護されたホスト登録メッセージをそれぞれ送信することによって，ホスト情報（アクセスキーを含む）をＧＷおよびＬＮＳに登録する。この登録中に，ＧＷも，ＧＬｏｃ（一定の有効期間を有する）をホストに割り当て，ホスト情報をＧＷのＩＤテーブルに保存する。ＧＷは後に，パケットヘッダ内のＬ３プロトコル（ロケータ）を変換するためにＩＤテーブルを使用する。同様に，ＬＮＳもホスト情報をホストテーブルに保存する。同じネットワーク内にある別のホストが，前記のホストと通信することを希望する場合に，ホストテーブルは，ホスト名をＩＤ，ＬＬｏｃ，およびＰＫへと解決するために使用される。ＧＷおよびＬＮＳの登録を終えた後，ＡＡはＧＬｏｃを含むホスト登録メッセージをホストに返信する。これにより，ローカル登録プロセスは終了する。

ホストが一度ＧＬｏｃを取得してしまえば，ホストは，ＡＡを介してホスト登録メッセージ（フラグＵ＝１によって）を送信することによって，ＨＮＲでホストのレコードを更新する。メッセージは，ホストが初めてＨＮＲにホストの情報を登録したときに得た共有秘密鍵であるＨｏｓｔ−ＨＮＲｓｈＫｅｙによって保護されている。ＨＮＲの更新が完了すれば，ネットワークアクセス手順は完了する。この時点で，ホストは他のすべてのホストとの通信するための準備ができている。同様に，アクセスキーの有効期間が満了しようとしているか，ホストが別のアクセスネットワークへ移動しているときには，ホスト登録メッセージ（フラグＴ＝１によって）をＡＡに送信することによって，ホストはエッジネットワークとのそのセキュリティアソシエーションを更新するか，または終了することができる。

通信セッションのセキュリティ
パケットの識別ヘッダに認証データを含ませることによって，通信セッションは安全にされる。この方式では，パケットの発信元の認証と完全性を保証する。認証データは，ホスト名解決プロセスに続くセッション開始フェーズの間に確立されたセキュリティコンテキストを使用することによって，計算される。

ヘッダを識別する
識別層ヘッダフォーマットを図１９に示す。基本ヘッダのサイズは，４０バイト長であり，可変サイズのオプショナルなパラメータフィールドは，他の制御メッセージ，例えばセキュリティパラメータの折衝メッセージやモビリティシグナリングメッセージの他に，認証データを入れるために使用される。基本的なヘッダフィールドは，以下のものである。次ヘッダ（１バイト）は，パケットのペイロードの次のヘッダのプロトコル番号（通常はトランスポートプロトコル番号）を指定する。ペイロードが無い場合には，次ヘッダ＝ＮＯ＿ＮＸＴ＿ＨＤＲ（５９）となる。ヘッダ長（１バイト）は，オプショナルなパラメータを含むＩＤヘッダの長さを指定する。Ｐ（１ビット）は，パケットが，任意の上位層ペイロードを含むかどうかを指定する。タイプ（７ビット）は，ＩＤレイヤパケットタイプ（ｐタイプ），すなわち，パラメータフィールドに入れられる制御メッセージのタイプを指定する。バージョン（４ビット）は，１である識別層プロトコルのバージョンを指定する。Ｃ（１ビット）は，ＩＤヘッダが（パラメータフィールドで運ばれる）制御メッセージを有するかどうかを指定する。チェックサム（２バイト）は，ＩＤ基本ヘッダやパラメータをカバーするチェックサムを指定する。制御フラグ（２バイト）は，ＩＤの性質や，ロケータとそれらのマッピング（持続的／一時的，アノニマス等）などの追加的な制御情報を指定する。フラグＳは，識別層に実装されたセキュリティ機能が使用されていることを示すために，１に設定されている。

セキュリティパラメータの折衝
アプリケーションが，識別層からセキュリティを必要するとき，送信元ホスト（ＳＨ）とターゲットホスト（ＴＨ）は，図２０に示すように，識別層から４つの制御パケットを交換することによって，セキュリティコンテキスト（例えば，セッション秘密鍵および完全性チェックアルゴリズムのような）を確立する。ＳＨは，送信元と送信先のＩＤとして識別ヘッダにＳＨとＴＨのＩＤ，ＳＨのホスト名，ＰＫ，ＳＨおよびＴＨのＧＬｏｃ，および完全性チェックアルゴリズムのリストをパラメータフィールドに含み，Ｓフラグが１であり，ｐタイプが１である通信初期化要求メッセージを送信する。ネットワーク層ヘッダにおいて，ＳＨのＬＬｏｃとＳ−ＧＷのＬＬｏｃは，送信元および送信先ロケータフィールドで使用さる。パケットが送信元ＧＷ（Ｓ−ＧＷ）に到達すると，ホスト名解決の間に得られた，ＳＨとＴＨのＩＤ／ＧＬｏｃのマッピングの両者を含むＳ−ＧＷのＩＤテーブルを使用して，ネットワーク層ロケータ（プロトコル）をグローバルロケータに変換する。そして，ターゲットＧＷ（Ｔ−ＧＷ）にパケットを転送する。ＴＨのＩＤ／ＬＬｏｃマッピングのためのＴ−ＧＷのＩＤテーブルを参照することによって，Ｔ−ＧＷは，再度ネットワーク層ヘッダを変換する。ネットワークヘッダでは，送信元ロケータではＴＨのＬＬｏｃを使用し，送信先ロケータとしては自身のＬＬｏｃを使用している。そして，パケットはＴＨに転送される。Ｔ−ＧＷのＩＤテーブルには，まだ，ＳＨのＩＤ／ＧＬｏｃマッピングが含まれていないことに注意されたい。そして，このマッピングが無ければ，ＴＨはＳＨに応答を返信することができない。ＳＨのＩＤ／ＧＬｏｃをＴ−ＧＷに登録するための方法としては，暗黙的ピアホスト登録または明示的ピアホスト登録の２つの方法がある。暗黙的ピアホスト登録においては，Ｔ−ＧＷは，パケットヘッダからＳＨのＩＤ／ＧＬｏｃを抽出し，それをＩＤテーブルに保存する。一方，明示的な登録においては，ＴＨは，図に示すように，ピアホスト登録を行う必要がある。

通信初期化要求を受信すると，ＴＨは，選択された完全性チェックアルゴリズムと共に，ＳＨのＩＤ，ＧＬｏｃ，ＰＫおよびＬＬｏｃ（すなわち，Ｔ−ＧＷのＬＬｏｃ）を一時バッファに保存する。そして，その識別ヘッダがｐタイプ＝２，Ｓ＝１，Ａ＝０である，通信初期化応答１メッセージを構成する。（ＴＨが複数のＧＬｏｃを有している場合には）識別ヘッダパラメータフィールドは，ＴＨの追加的なＧＬｏｃを含んでもよい。メッセージは，ＴＨの秘密鍵でパケットを署名することによって保護されている。署名（ＳＩＧ）は，ＩＤヘッダのパラメータフィールドに含まれている。そして，パケットは，ＳＨに送られる。

ＳＨは，ホスト間で交換されるパケットを保護するために使用される秘密のセッション鍵（ｓｅｓｓＫｅｙ）を生成する。有効期間もｓｅｓｓＫｅｙに関連付けられている。そして，ＳＨは，ＴＨのＩＤ，ＰＫ，ｓｅｓｓＫｅｙ，および有効期間を一時バッファに保存する。その後，ＴＨのＰＫで暗号化されたｓｅｓｓＫｅｙ含む通信初期化応答２メッセージが構成される。メッセージは，ＳＨの秘密鍵によって署名され，ＴＨに送信される。
ＳＨの同一性を検証するために，ＴＨは，ＳＨから受け取ったＳＨのホスト名，ＩＤおよびＰＫを，ホスト名解決プロセスを行うことによってＳＨのＨＮＲから取得した同様の値と比較する。検証が成功した場合には，ＴＨは，ＳＨのパラメータを含む一時バッファを，セキュリティアソシエーションテーブル（ＳＡＴ）にコピーする。また，通信初期化応答２メッセージで受信したｓｅｓｓＫｅｙをＳＡＴに追加する。そして，セッション開始プロセスの結果を含めることによって，通信初期化完了メッセージを構成する。メッセージは，ｓｅｓｓＫｅｙを使用して計算したＨＭＡＣ含めることによって保護される。通信初期化完了メッセージは，ＳＨに送信される。

ＳＨは，ＴＨが接続要求を受け入れたかどうかを知るために，通信初期化完了メッセージ内の結果のパラメータをチェックする。ＴＨが通信初期化応答メッセージ２でＳＨが提案したものからｓｅｓｓＫｅｙの有効期間の値を変更した場合、その値を含んでいてもよい。結果が可であれば，ＳＨは，そのセキュリティパラメータを含む一時バッファをそのＳＡＴにコピーする。

そして，送信元ホストは，パケットシーケンス番号と，通信初期化フェーズ中に折衝された完全性チェックアルゴリズムを使用することによって識別層プロトコルデータユニット（ＰＤＵ）とｓｅｓｓＫｅｙに対して計算されたＨＭＡＣである認証データを，そのＩＤヘッダ中に含むデータパケットの送信を開始する。これらのパケットを受信すると，ＴＨは，関連するセキュリティコンテキストのためのＳＡＴを参照することによって，パケットの完全性チェックと送信元の認証を実行する。

モビリティプロセスのセキュリティ
ネットワークアクセスセキュリティおよび通信セッションセキュリティの機能は，モビリティプロセスを安全にするために活用することができる。すなわち，ネットワーク接続プロセス中にホストとネットワークとの間において，またはセッション初期化プロセス中にホスト間において，確立されたセキュリティコンテキストは，ホストがあるエッジネットワークから別のエッジネットワークに移動する時に，モビリティ管理機能を安全に行うために使用することができる。モビリティ管理においては，モバイルホスト（ＭＨ）は，以下のシグナリング機能を実行する。つまり，（ａ）新しいエッジネットワークから新しいロケータを取得するためのネットワークアクセス，（ｂ）ハンドオーバー中に，古いＧＷが，新しいＧＷにパケットを転送できるように，ＭＨの新しいＧＬｏｃにより古いＧＷを更新すること，（ｃ）パケットが新しい場所に転送されるように，ピアまたは通信ホスト（ＣＨ）とそのＧＷを更新すること，（ｄ）ＭＨの新しいＧＬｏｃによりＭＨのＨＮＲを更新すること，および（ｅ）古いエッジネットワークからグレースフルに切断することである。機能（ａ），(ｂ)，（ｄ）および（ｅ）は，ネットワークアクセスセキュリティに関連し，（ｃ）は通信セッションのために設けられたセキュリティコンテキストを用いて安全に行うことができる。

本発明は，情報通信技術産業において用いることができる。本発明は，ネットワークサービスにスムーズにアクセスしながら，ユーザデバイスがあるネットワークから別のネットワークに移動することができる，モバイルおよびヘテロジニアスネットワークにおいて特に好適である。ユーザデバイスは認証されて，ネットワークへの安全で最適な接続が提供される。例えば，スマートフォンやラップトップコンピュータを持つユーザは，彼／彼女が無線ＬＡＮ（Ｗｉｆｉ）ネットワークから，ＷｉＭＡＸネットワークやセルラーネットワークに移動した場合であっても，ネットワークへの接続を維持し続けることができる。これらの３つのネットワークのすべてが同じ場所で利用可能なとき，ユーザは，アプリケーション要求に基づいた最適なネットワークを安全に選択することができる。

１ インターネットネットワークシステム
１１ エッジネットワーク
１２ 送信元ホスト（ＳＨ）
１３ 第一ゲートウェイ（ＧＷ）
１４ ローカルネームサーバ（ＬＮＳ）
１５ 認証エージェント（ＡＡ）
２１ 論理制御ネットワーク
２２ ドメインネームレジストリ（ＤＮＲ）
２３ ホストネームレジストリ（ＨＮＲ）
３１ ターゲットホスト（ＴＨ）
３２ 第二エッジネットワーク
３３ 第二ゲートウェイ（ＧＷ）
３４ 第二ローカルネームサーバ（ＬＮＳ）
３５ 認証エージェント（ＡＡ）
４１ グローバルトランジットネットワーク
４２ ルータ

特開２００８−３１２１９１号公報

［ＤＮＳ］ ＲＦＣ １０３５， Ｄｏｍａｉｎ ｎａｍｅｓ − Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ ａｎｄ ｓｐｅｃｉｆｉｃａｔｉｏｎ， Ｎｏｖｅｍｂｅｒ １９８７． ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ１０３５．ｔｘｔ ［ＤＮＳＳＥＣ］ ＲＦＣ ４０３４， Ｒｅｓｏｕｒｃｅ Ｒｅｃｏｒｄｓ ｆｏｒ ｔｈｅ ＤＮＳ Ｓｅｃｕｒｉｔｙ Ｅｘｔｅｎｓｉｏｎｓ， Ｍａｒｃｈ ２００５． ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ４０３４．ｔｘｔ， Ｒ． Ｍｏｓｋｏｗｉｔｚ， Ｐ． Ｎｉｋａｎｄｅｒ， Ｐ．Ｊｏｋｅｌａ， ａｎｄ Ｔ． Ｈｅｎｄｅｒｓｏｎ， "Ｈｏｓｔ ｉｄｅｎｔｉｔｙ ｐｒｏｔｏｃｏｌ，" ＲＦＣ ５２０１， Ａｐｒｉｌ ２００８． ［ＤＮＳ ＵＰＤＡＴＥ］ ＲＦＣ ２１３６， Ｄｙｎａｍｉｃ Ｕｐｄａｔｅｓ ｉｎ ｔｈｅ Ｄｏｍａｉｎ Ｎａｍｅ Ｓｙｓｔｅｍ （ＤＮＳ ＵＰＤＡＴＥ）， Ａｐｒｉｌ １９９７． ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２１３６．ｔｘｔ ［ＴＳＩＧ］ ＲＦＣ ２８４５， Ｓｅｃｒｅｔ Ｋｅｙ Ｔｒａｎｓａｃｔｉｏｎ Ａｕｔｈｅｎｔｉｃａｔｉｏｎ ｆｏｒ ＤＮＳ （ＴＳＩＧ）， Ｍａｙ ２０００． ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ２８４５．ｔｘｔ ［ＩＰｓｅｃ］ ＲＦＣ ４３０１， Ｓｅｃｕｒｉｔｙ Ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｔｈｅ Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ， Ｄｅｃｅｍｂｅｒ ２００５． ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ４３０１．ｔｘｔ ［ＨＩＰ］ ＲＦＣ ５２０１， Ｈｏｓｔ Ｉｄｅｎｔｉｔｙ Ｐｒｏｔｏｃｏｌ， Ａｐｒｉｌ ２００８． ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｒｆｃ／ｒｆｃ５２０１．ｔｘｔ ［ＨＩＭＡＬＩＳ］ ＨＩＭＡＬＩＳ： Ｈｅｔｅｒｏｇｅｎｅｉｔｙ Ｉｎｃｌｕｓｉｏｎ ａｎｄ Ｍｏｂｉｌｉｔｙ Ａｄａｐｔａｔｉｏｎ ｔｈｒｏｕｇｈ Ｌｏｃａｔｏｒ ＩＤ Ｓｅｐａｒａｔｉｏｎ ｉｎ Ｎｅｗ Ｇｅｎｅｒａｔｉｏｎ Ｎｅｔｗｏｒｋ， ＩＥＩＣＥ Ｔｒａｎｓａｃｔｉｏｎ ｏｎ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ， Ｖｏｌ．Ｅ９３−Ｂ， Ｎｏ．３， Ｐｐ． ４７８−４８９， Ｍａｒｃｈ ２０１０． ［ＤＨＣＰ］ ＲＦＣ ２１３１， Ｄｙｎａｍｉｃ Ｈｏｓｔ Ｃｏｎｆｉｇｕｒａｔｉｏｎ Ｐｒｏｔｏｃｏｌ， Ｍａｒｃｈ １９９７． ｈｔｔｐ：／／ｗｗｗ ｉｅｔｆ ｏｒｇ／ｒｆｃ／ｒｆｃ２１３１ ｔｘｔ ［ＬＩＰＳ］ Ｄ． Ｆａｒｉｎａｃｃｉ， Ｖ． Ｆｕｌｌｅｒ， Ｄ． Ｍｅｙｅｒ， ａｎｄ Ｄ． Ｌｅｗｉｓ， "Ｌｏｃａｔｏｒ／ＩＤ ｓｅｐａｒａｔｉｏｎ ｐｒｏｔｏｃｏｌ （ＬＩＳＰ），"Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ， ｈｔｔｐ：／／ｗｗｗ．ｉｅｔｆ．ｏｒｇ／ｉｄ／ｄｒａｆｔ−ｉｅｔｆ−ｌｉｓｐ−１６．ｔｘｔ， Ｏｃｔ． ２０１１． ［Ｓｈｉｍ６］ Ｅ． Ｎｏｒｄｍａｒｋ ａｎｄ Ｍ． Ｂａｇｎｕｌｏ， "Ｓｈｉｍ６： Ｌｅｖｅｌ ３ ｍｕｌｔｉｈｏｍｉｎｇ ｓｈｉｍ ｐｒｏｔｏｃｏｌ ｆｏｒ ＩＰｖ６，"ＲＦＣ ５５３３， Ｊｕｎｅ ２００９． ［ＨＩＭＡＬＩＳ］ Ｖ．Ｐ． Ｋａｆｌｅ ａｎｄ Ｍ． Ｉｎｏｕｅ， "ＨＩＭＡＬＩＳ： Ｈｅｔｅｒｏｇｅｎｅｉｔｙ ｉｎｃｌｕｓｉｏｎ ａｎｄ ｍｏｂｉｌｉｔｙ ａｄａｐｔａｔｉｏｎ ｔｈｒｏｕｇｈ ｌｏｃａｔｏｒ ＩＤ ｓｅｐａｒａｔｉｏｎ ｉｎ ｎｅｗ ｇｅｎｅｒａｔｉｏｎ ｎｅｔｗｏｒｋ，" ＩＥＩＣＥ Ｔｒａｎｓ． Ｃｏｍｍｕｎ．， ｖｏｌ． Ｅ９３−Ｂ， ｎｏ． ３， Ｍａｒｃｈ ２０１０． ［ＤＮＳ２］ Ｖ．Ｐ． Ｋａｆｌｅ， Ｈ． Ｏｔｓｕｋｉ， ａｎｄ Ｍ． Ｉｎｏｕｅ， "Ａｎ ＩＤ／ｌｏｃａｔｏｒ ｓｐｌｉｔ ａｒｃｈｉｔｅｃｔｕｒｅ ｆｏｒ ｆｕｔｕｒｅ ｎｅｔｗｏｒｋｓ，" ＩＥＥＥ Ｃｏｍｍｕｎ． Ｍａｇ．， ｖｏｌ． ４８，ｎｏ． ２， Ｆｅｂ． ２０１０． ［ＡＬＴ］ Ｖ． Ｆｕｌｌｅｒ， Ｄ． Ｆａｒｉｎａｃｃｉ， Ｄ． Ｍｅｙｅｒ， Ａｎｄ Ｄ． Ｌｅｗｉｓ， "ＬＩＳＰ ａｌｔｅｒｎａｔｅ ｔｏｐｌｏｇｙ （ＬＩＳＰ＋ＡＬＴ），" Ｉｎｔｅｒｎｅｔ−Ｄｒａｆｔ， ＩＥＴＦ， Ｓｅｐ ２０１１．

Claims (4)

1. インターネットネットワークシステム（１）におけるホスト名解決方法であって，
   上記システムは，
   送信元ホスト（ＳＨ）（１２），第一ゲートウェイ（ＧＷ）（１３），およびローカルネームサーバ（ＬＮＳ）（１４）を備える，第一エッジネットワーク（１１）と，
   ドメインネームレジストリ（ＤＮＲ）（２２）と，ホストネームレジストリ（ＨＮＲ）（２３）を備える，論理制御ネットワーク（２１）と，
   前記第一エッジネットワーク（１１）または第二エッジネットワーク（３２）内のターゲットホスト（ＴＨ）（３１）と，
   前記第一エッジネットワーク（１１），前記論理制御ネットワーク（２１），および前記第二エッジネットワーク（３２）と接続するためのルータ（４２）を備えるグローバルトランジットネットワーク（４１）と，を備え，
   前記方法は，
   前記ＴＨ（３１）のホスト名を知っている前記ＳＨ（１２）が，前記ＴＨ（３１）のＩＤ，前記ＴＨのロケータおよび前記ＴＨの公開鍵（ＰＫ）のうちの任意の一つ以上を得るように，前記ＴＨ（３１）のホスト名を含むホスト名解決クエリを前記ＬＮＳ（１４）に送信し，
   前記ＬＮＳ（１４）が前記ホスト名解決クエリを受信し，前記ＴＨ（３１）が前記第一エッジネットワーク（１１）内にあるか否かを検証し，
   前記ＬＮＳ（１４）が，前記ＴＨ（３１）が前記第一エッジネットワーク（１１）内に配置されていると判断できない場合には，前記ＬＮＳ（１４）は，前記ＴＨ（３１）の前記ホスト名を含む第一のクエリを前記ＤＮＲ（２２）送信し，
   前記ＤＮＲ（２２）が前記第一のクエリを受信し，次いで，前記ＤＮＲ（２２）は第一の応答を前記ＬＮＳ（１４）に送信し，ここで，前記第一の応答は，前記ＨＮＲのＩＤ，前記ＨＮＲのロケータ，および前記ＨＮＲの公開鍵を含む前記ＨＮＲの情報を含んでおり，
   前記ＬＮＳ（１４）は，前記第一の応答を受信し，次いで，前記ＬＮＳ（１４）は前記ＨＮＲの情報を用いて第二のクエリを前記ＨＮＲ（２３）に送信し，ここで，前記第二のクエリは前記ＴＨのＩＤ，前記ＴＨのロケータおよび前記ＴＨのＰＫをＬＮＳ（１４）に提供することを前記ＨＮＲ（２３）に要求し，
   前記ＨＮＲ（２３）は，前記第二のクエリを受信し，次いで，前記ＨＮＲ（２３）が第二の応答を前記ＬＮＳ（１４）に送信し，ここで，前記第二の応答は前記ＴＨのＩＤ，前記ＴＨのロケータおよび前記ＴＨのＰＫを含んでおり，
   前記ＬＮＳ（１４）は，前記第二の応答を受信し，前記ＨＮＲのＰＫを用いて前記第二の応答の真正性を検証するための機能を実行し，
   前記検証の結果が可である場合には，前記ＬＮＳ（１４）は，前記ＴＨのＩＤ，前記ＴＨのロケータおよび前記ＴＨの公開鍵（ＰＫ）を含む，ホスト名解決応答を前記ＳＨ（１２）に送信し，
   前記ＳＨ（１２）は，前記ホスト名解決応答において，前記ＴＨのＩＤ，前記ＴＨのロケータおよび前記ＴＨのＰＫを受け取る，
   ことを特徴とする方法。
2. 請求項１に記載された方法であって，
   前記第一の応答は，前記ＤＮＲのＰＫと，前記ＤＮＲの秘密鍵を用いる前記ＤＮＲの署名をさらに含み，前記ＤＮＲのＰＫと前記ＤＮＲの署名は，前記ＤＮＲ（２２）からの前記第一の応答の検証において使用される，
   ことを特徴とする方法。
3. 請求項１に記載された方法であって，
   前記第一エッジネットワーク（１１）は，認証エージェント（ＡＡ）（１５）および動的ホスト構成プロトコルサーバ（ＤＨＣＰ）（１６）をさらに備えており，
   前記第一ゲートウェイ（ＧＷ）（１３），前記ＬＮＳ（１４），および前記ＡＡ（１５）は，これらの間で交換されるメッセージを保護するために使用されるペアワイズ共有鍵である，ＡＡ−ＧＷｓｈＫｅｙ，ＡＡ−ＬＮＳｓｈＫｅｙおよびＬＮＳ−ＧＷｓｈＫｅｙを有し，
   前記方法は，前記ＳＨ（１２）がホスト名解決クエリを送信する前に，前記ＳＨ自身のＬＬｏｃと，前記第一ＧＷのＩＤとＬＬｏｃと，前記ＬＮＳのＩＤとＬＬｏｃと，前記ＡＡのＩＤとＬＬｏｃと，を前記ＤＨＣＰから取得するための初期設定ステップと，
   前記第一エッジネットワークにおいて前記ＳＨ（１２）を認証するための認証ステップと，
   前記第一ＧＷ（１３）および前記ＬＮＳ（１４）に登録される前記ＳＨのホスト名，ＩＤ，ＰＫおよびＬＬｏｃを作成するためのローカル登録ステップと，
   前記ＨＮＲ（２３）において前記ＳＨのロケータを更新するためのＨＮＲ更新ステップと，をさらに有し，
   前記初期設定のステップの後に実行される前記認証ステップでは，
   前記ＳＨ（１２）は，第一のホスト登録要求を前記ＡＡ（１５）に送信し，ここで，前記第一のホスト登録要求は，前記ＳＨのホスト名，前記ＳＨのＩＤ，前記ＳＨのＰＫ，および前記ＳＨ（１２）でサポートされている完全性チェックアルゴリズムのリストを含み，
   前記ＡＡ（１５）は，前記第一のホスト登録要求を受信し，その後，前記ＡＡは，前記ＳＨのＩＤおよびＰＫをＨＮＲ（２３）から取得するために，請求項１に記載された前記ホスト名解決を同様に実行し，
   前記ＡＡ（１５）は，前記ＳＨ（１２）によって送られたホスト情報が，前記ＨＮＲ（２３）から得たものと同じであることを確認し，
   前記ＡＡ（１５）は，前記ＡＡ（１５）がサポートすることができる完全性チェックアルゴリズムのタイプに基づいて，完全性チェックアルゴリズムを選択し，
   前記ＡＡ（１５）は，アクセスＩＤとシークレットアクセスキーを割り当て，
   前記ＡＡ（１５）は，前記完全性チェックアルゴリズム，前記アクセスＩＤおよび前記シークレットアクセスキーを含む第一のホスト登録応答を前記ＳＨ（１２）に送信し，ここで，前記アクセスＩＤと前記シークレットアクセスキーは，前記ＳＨのＰＫによって暗号化されており，
   前記ＳＨ（１２）は，前記第一のホスト登録応答を受け取り，
   前記認証ステップの後に実行される前記ローカル登録ステップでは，
   前記ＳＨ（１２）は，前記完全性チェックアルゴリズムにおいて前記アクセスキーを使用して計算されたＨＭＡＣを含むことによって完全性が保護されている，前記ＳＨのホスト名，前記ＳＨのＩＤ，前記ＳＨのＬＬｏｃ，および前記ＳＨのＰＫを含む第二のホスト登録要求をＡＡ（１５）に送信し，
   前記ＡＡ（１５）は，前記第二のホスト登録要求を受信し，
   前記ＡＡ（１５）は，ＡＡ−ＧＷｓｈＫｅｙによって暗号化された，前記ＳＨのホスト名，前記ＳＨのＩＤ，前記ＳＨのＬＬｏｃ，前記ＳＨのＰＫおよびアクセスキーを含む，ＧＷのためのホスト登録メッセージを第一ＧＷ（１３）へ送信し，
   前記ＡＡ（１５）は，ＡＡ−ＬＮＳｓｈＫｅｙによって暗号化された，前記ＳＨのホスト名，前記ＳＨのＩＤ，前記ＳＨのＬＬｏｃ，前記ＳＨのＰＫおよびアクセスキーを含む，ＬＮＳのためのホスト登録メッセージを前記ＬＮＳ（１４）へ送信し，
   前記第一ＧＷ（１３）は，ＧＷのための前記ホスト登録メッセージを受信し，ＡＡ−ＧＷｓｈＫｅｙを用いてこれを復号化し，前記第一ＧＷ（１３）は，ＧＬｏｃを前記ＳＨ（１２）に割り当て，前記ＳＨのＧＬｏｃを前記第一ＧＷ（１３）のメモリに保存し，
   前記第一ＧＷ（１３）は，ＧＷから，前記ＳＨのＧＬｏｃを含むホスト登録応答メッセージを前記ＡＡ（１５）へ送信し，
   前記ＬＮＳ（１４）は，ＬＮＳのための前記ホスト登録メッセージを受信し，ＡＡ−ＬＮＳｓｈＫｅｙを用いてこれを読み取り，前記ＬＮＳ（１４）は，前記ＳＨのホスト名，前記ＳＨのＩＤ，前記ＳＨのＬＬｏｃ，前記ＳＨのＰＫおよびアクセスキーを保存し，
   前記ＬＮＳ（１４）は，ＬＮＳからホスト登録応答メッセージを前記ＡＡ（１５）へ送信し，
   前記ＡＡ（１５）は，前記ＳＨのＧＬｏｃを含む第二のホスト登録応答を前記ＳＨ（１２）へ送信し，
   前記ＳＨ（１２）は，前記第二のホスト登録応答を受信し，
   前記ローカル登録ステップの後に実行される前記ＨＮＲ更新ステップにおいて，
   前記ＳＨ（１２）は，ＳＨ−ＨＮＲｓｈＫｅｙによって暗号化された，前記ＳＨのホスト名，前記ＳＨのＩＤおよび前記ＳＨのＧＬｏｃを含む第三のホスト登録要求を前記ＨＮＲ（２３）へ送信し，
   前記ＨＮＲ（２３）は，前記第三のホスト登録要求を受信し，前記ＳＨ−ＨＮＲｓｈＫｅｙを用いてこれを読み取り，
   前記ＨＮＲ（２３）は，前記ＨＮＲのレコードにおいて前記ＳＨのＧＬｏｃを更新し，第三のホスト登録応答を前記ＳＨ（１２）へ送信する，
   ことを特徴とする方法。
4. 前記ＳＨ（１２）および前記ＴＨ（３１）との間の通信セッションを確立するための手順をさらに含む，請求項１に記載の方法であって，
   前記ＳＨ（１２）は，前記ＴＨ（３１）に通信要求を伝えるよう，前記ＳＨ（１２）とＴＨのＩＤ，ＳＨのホスト名，ＰＫおよびＧＬｏｃ，ＴＨのＧＬｏｃ，完全性チェックアルゴリズムのリスト，およびＳＨの署名を含む，第一の通信初期化要求メッセージを前記ＴＨ（３１）に送信し，
   前記ＴＨ（３１）は，前記第一の通信初期化要求メッセージを受信し，前記ＳＨのＩＤ，ＧＬｏｃ，ＰＫおよびＬＬｏｃと，前記選択された完全性チェックアルゴリズムを，前記ＴＨ（３１）の一時バッファに保存し，
   前記ＴＨ（３１）は，請求項１に記載されたホスト名解決プロセスを実行することによって，前記ＨＮＲ（２３）から前記ＳＨのＩＤとＰＫを取得することにより前記ＳＨ（１２）の真正性を検証し，
   前記ＴＨ（３１）が二つ以上のＧＬｏｃを有する場合には，前記ＴＨ（３１）は，前記ＴＨのＧＬｏｃを含む第一の通信初期化応答を前記ＳＨ（１２）へ送信し，前記第一の通信初期化応答は，ＴＨの秘密鍵を用いたＴＨの署名によって保護されており，
   前記ＳＨ（１２）は，前記第一の通信初期化応答を受信し，前記ＳＨ（１２）および前記ＴＨ（３１）との間で交換されるパケットの完全性を保護するために使用される秘密セッション鍵（ｓｅｓｓＫｅｙと，前記ｓｅｓｓＫｅｙに関連付けられている有効期間を生成し，
   前記ＳＨ（１２）は，前記ＴＨのＩＤ，ＰＫ，ｓｅｓｓＫｅｙおよび有効期間を，前記ＳＨの一時バッファに保存し，
   前記ＳＨ（１２）は，前記ＴＨのＰＫによって暗号化されたｓｅｓｓＫｅｙを含む第二の通信初期化応答，および前記ＳＨの秘密鍵によって署名された応答メッセージを前記ＴＨ（３１）に送信し，
   前記ＴＨ（３１）は，前記第二の通信初期化応答を受信し，前記ＳＨのＩＤ，ＧＬｏｃ，ＰＫおよびＬＬｏｃと前記ｓｅｓｓＫｅｙを含む一時バッファを，前記ＴＨ（３１）のセキュリティアソシエーションテーブル（ＳＡＴ）に保存し，
   前記ＴＨ（３１）は，前記ｓｅｓｓＫｅｙを用いて計算されたＨＭＡＣによって保護されている通信初期化完了メッセージを前記ＳＨ（１２）に送信し，
   前記ＳＨ（１２）は，前記通信初期化完了メッセージ受信し，前記ＴＨ（３１）が，接続要求を受け入れたか否かを確認するために，これをチェックし，
   前記ＳＨ（１２）は，前記ＳＨのＩＤ，ＧＬｏｃ，ＰＫおよびＬＬｏｃを含む前記一時バッファを，前記ＳＨ（１２）の前記ＳＡＴにコピーし，
   前記ＳＨ（１２）は，前記ＴＨ（３１）とのデータの送信または受信を開始する，
   ことを特徴とする方法。

Images