JP6178932B2 - パケット伝送ネットワークにおけるハンドシェイクを制御するための方法及び装置 - Google Patents

Description

本発明は、パケット伝送ネットワークにおけるハンドシェイク、例えば、限定されないが、データグラムトランスポート層セキュリティ（ＤＴＬＳ：Ｄａｔａｇｒａｍ Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）環境におけるハンドシェイク動作等を制御するための方法及び装置の分野に関する。

インターネットプロトコルバージョン６（ＩＰｖ６：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ ｖｅｒｓｉｏｎ ６）は、ほとんど全ての物理的対象をインターネットにより相互接続する。これにより、例えば、ホームオートメーション及びホームセキュリティ管理、照明システム、コンピュータ化されたエネルギー監視及び管理、商品及び出荷追跡、偵察及び軍事、スマートシティ、健康管理、物流監視及び管理等の新しい応用例を開発する大いなる可能性が生まれる。無線センサネットワーク（ＷＳＮ）に低消費電力無線パーソナルエリアネットワークを介するインターネットプロトコル（ＩＰ）バージョン６（６ＬｏＷＰＡＮ）を導入することによって、資源に制約のあるデバイスをインターネットに接続することができる。このインターネットとＩＰｖ６接続された制約デバイスとからなるハイブリッドネットワークは、いわゆる「モノのインターネット」（ＩｏＴ：Ｉｎｔｅｒｎｅｔ ｏｆ Ｔｈｉｎｇｓ）を形成する。デバイスのほとんどが強力なインターネットやデバイスのほとんどが資源制約される典型的なＷＳＮとは異なり、ＩｏＴのモノは非常に多様である。ＩｏＴデバイスは、典型的なセンサノード、電球、電子レンジ、電力量計、自動車部品、スマートフォン、パーソナルコンピュータ（ＰＣ）又はラップトップ、強力なサーバマシン、さらにはクラウドでもよい。

ＩｏＴにおける無線ネットワークは低出力で損失が多いという特性を有するため、ＩｏＴではほとんどの場合、ストリーム型の送信制御プロトコル（ＴＣＰ：Ｔｒａｎｓｍｉｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）ではなく、コネクションレスユーザデータグラムプロトコル（ＵＤＰ：Ｕｓｅｒ Ｄａｔａｇｒａｍ Ｐｒｏｔｏｃｏｌ）が使用される。同期ハイパーテキスト転送プロトコル（ＨＴＴＰ：Ｈｙｐｅｒ Ｔｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）は、ＴＣＰ用に設計されており、ＵＤＰベースのＩｏＴで使用することは不可能である。したがって、ＨＴＴＰのサブセットである制約アプリケーションプロトコル（ＣｏＡＰ：Ｃｏｎｓｔｒａｉｎｅｄ Ａｐｐｌｉｃａｔｉｏｎ Ｐｒｏｔｏｃｏｌ）がＩｏＴのウェブプロトコルとして標準化されている。ＣｏＡＰは、制約デバイス及び機械同士の通信に適合している。また、インターネットプロトコルセキュリティ（ＩＰｓｅｃ：Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）は、ＩｏＴで使用することができるが、本来ＨＴＴＰやＣｏＡＰ等のウェブプロトコル用には設計されていない。ウェブプロトコルについては、トランスポート層セキュリティ（ＴＬＳ：Ｔｒａｎｓｐｏｒｔ Ｌａｙｅｒ Ｓｅｃｕｒｉｔｙ）又はその前身であるセキュアソケットレイヤ（ＳＳＬ：Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）が最も一般的なセキュリティソリューションである。しかし、コネクション型のＴＬＳプロトコルは、スマートオブジェクトにとって好適な通信方法ではないストリーム型のＴＣＰでのみ使用することができる。低消費電力無線ネットワークの損失特性のために、６ＬｏＷＰＡＮネットワークで常時接続を維持することは困難である。

ＴＬＳをＵＤＰに対応させたものは、データグラムＴＬＳ（ＤＴＬＳ：Ｄａｔａｇｒａｍ ＴＬＳ）と呼ばれている。ＤＴＬＳは、トランスポート層とアプリケーション層の間で動作することによって、１台の機械上で異なるアプリケーションのエンドツーエンド（Ｅ２Ｅ）セキュリティを保証する。認証、機密性、完全性、及び反復操作による保護を提供するＴＬＳに加え、ＤＴＬＳはさらに、クッキーの使用によるサービス妨害（ＤｏＳ：Ｄｅｎｉａｌ ｏｆ Ｓｅｒｖｉｃｅ）攻撃に対する保護を提供する。ＤＴＬＳは、アプリケーションレベルＥ２Ｅセキュリティを提供するが、ＵＤＰプロトコルでのみ使用することができる。ＩｏＴのための安全なウェブプロトコルであるセキュアＣｏＡＰ（ＣｏＡＰｓ：Ｓｅｃｕｒｅ ＣｏＡＰ）は、ＣｏＡＰの基礎的なセキュリティソリューションとしてＤＴＬＳの使用を要求する。したがって、例えばブートストラッピング等のセキュリティ問題に対して、ＩｏＴでＤＴＬＳサポートを可能にする必要がある。「ブートストラッピング」という語は、ＩＥＴＦの６ＬｏＷＰＡＮ作業部会で２００５年頃から使用されている。ブートストラッピングという語は、正常なネットワーク動作に参加できるようにノードを構成するプロセスと定義することができる。しかし、おそらくより衝撃的なことに、一般的な用法では、ブートストラッピングプロセスは、（コンピューティング初期のダイオードマトリクスＲＯＭブートストラップ等）非常にプリミティブなものから始まって、幾つかのステップで複雑なソフトウェア環境を設定することを意味する。この概念をセキュリティブートストラッピングに応用し、上記の定義と組み合わせることで、プリミティブな初期の鍵材料及びセキュリティ手順を使用して確実に安全なノード構成を設定することを表す。

ＤＴＬＳハンドシェイクの間に、クライアントとサーバは、接続のセキュリティを確立するために用いる種々のパラメータに合意する。例として、ＩＰベースの照明ネットワークでは、ＤＴＬＳハンドシェイクを使用してコミッショニング中に照明デバイスを作動させる。

図１は、クライアント（Ｃ）とサーバ（Ｓ）間の証明書を使用する典型的なＤＴＬＳハンドシェイクに関する信号図を示す。各メッセージ部分の後の括弧内の数字は、これらの部分の個々の長さをバイトで示す。

新しい接続を設定し、セキュリティパラメータの取り決めを行うために、ハンドシェイクプロトコルを使用する。クライアントは、ＣｌｉｅｎｔＨｅｌｌｏメッセージをサーバに送信することによりハンドシェイクを開始する。このメッセージは、サポートされた暗号方式、ハッシュアルゴリズム、圧縮アルゴリズム、及び乱数を含む。サーバは、クライアントが提供したものの中からサーバが選択した暗号方式及びアルゴリズムと乱数とを含むＳｅｒｖｅｒＨｅｌｌｏで応答しなければならない。幾つかあるデータの中で特に、２つの乱数を使用してマスターシークレットを計算する。サーバは、必要ならば自己を認証するための証明書を含むサーバ証明書メッセージを続ける。この場合、ＣｅｒｔｉｆｉｃａｔｅＲｅｑｕｅｓｔメッセージを送信してクライアントに認証を促すこともできる。暗号方式の中には、シークレットの計算に追加データを必要とするものがあり、追加データは、ＳｅｒｖｅｒＫｅｙＥｘｃｈａｎｇｅメッセージとともに送信することができる。上記の最後の３つのメッセージは任意であるため、ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージは、それ以上サーバからメッセージが得られないことを示す。

ハンドシェイクのこの部分は、コネクションレストランスポートプロトコルに関する問題である。というのは、トランスポート接続設定が必要なく、攻撃者は多くのＣｌｉｅｎｔＨｅｌｌｏｓをサーバに送信するのみだからである。これは、サーバのはるかに大きい応答をリダイレクトし、攻撃者の帯域幅を増加させることにより、すべてのＣｌｉｅｎｔＨｅｌｌｏに対して新しいセッションを開始し資源を配分するサーバ、又は他の犠牲者に対するサービス妨害（ＤｏＳ）攻撃に使用される。この問題を防ぐために、ＤＴＬＳは、ＨｅｌｌｏＶｅｒｉｆｙＲｅｑｕｅｓｔと呼ばれる追加のハンドシェイクメッセージを使用する。このメッセージは、ＣｌｉｅｎｔＨｅｌｌｏメッセージに応答して送信され、好ましくは署名された任意データのいわゆるクッキーを含む。サーバは、資源を配分することなくこのメッセージのみを送信する。そして、クライアントは、クッキーが付与されたＣｌｉｅｎｔＨｅｌｌｏ^＊メッセージを繰り返さなければならない。クッキー、したがって署名を検証することができれば、サーバは、クライアントが偽のアドレスを使用していないことを知る。そして、ＨｅｌｌｏＶｅｒｉｆｙＲｅｑｕｅｓｔメッセージは小さく、サーバがそれ以上データを送信する前にこれに応答する必要があるため、それ以上ＤＯＳ攻撃は起こり得ない。この検証の後、ハンドシェイクは前と同様に継続する。

ＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅメッセージの後に、クライアントは、サーバが認証を要求する場合に、ＣｌｉｅｎｔＣｅｒｔｉｆｉｃａｔｅメッセージとともに証明書を送信しなければならない。この後に、公開キー、又は使用されている暗号方式に依存する他の暗号データを含むＣｌｉｅｎｔＫｅｙＥｘｃｈａｎｇｅメッセージが続く。署名済みの証明書を検証するＣｅｒｔｉｆｉｃａｔｅＶｅｒｉｆｙメッセージを送信すべきかどうかも暗号方式に依存する。両ピアはこの時点でマスターシークレットを計算するのに十分な情報を有している。したがって、クライアントは、取り決めたパラメータ及びシークレットをこれから使用することを知らせるＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージを送信する。最後のメッセージは、ハンドシェイク全体を通じて計算されたハッシュを含む、既に暗号化されたＦｉｎｉｓｈｅｄメッセージである。サーバもＣｈａｎｇｅＣｉｐｈｅｒＳｐｅｃメッセージ及びＦｉｎｉｓｈｅｄメッセージを送信することによってハンドシェイクを終了する。

ＤＴＬＳハンドシェイクはセキュリティ接続の開始を目的としているため、ＤＴＬＳハンドシェイクを成功させて通信を開始することは非常に重要である。遅延や成功率等のＤＴＬＳハンドシェイクのパフォーマンスは、輻輳、無線損失、パケット損失率等のネットワークステータスに非常に大きく依存する。また、例えば、事前共有鍵（ＰＳＫ：Ｐｒｅ−Ｓｈａｒｅｄ Ｋｅｙ）、生の公開鍵又は証明書を用いるＤＴＬＳ等、ＤＴＬＳハンドシェイクのセキュリティモードにも依存する。というのは、異なるモードでは送信すべきパケット数が異なるためである。

遅延はパケット損失率の増大と共に増大する。より多くのパケットを送信することが必要なＤＴＬＳ証明書モードでは、遅延は他のモードよりも急速に増大する。ＰＳＫは返信確認応答モードにより一度に１個のパケットを送信し、確認応答の返信を待つ。ＡＣＫが返信されない場合は、パケットを再送信する。その結果、このモードの遅延は他のＰＳＫ方式よりもかなり大きくなる。

ＤＴＬＳハンドシェイクはセキュリティ接続の開始を目的としているため、ＤＴＬＳハンドシェイクを成功させて通信を開始することは非常に重要である。ＤＴＬＳハンドシェイクはＵＤＰ通信で用いられるため、ＤＴＬＳハンドシェイクのためのパケットが伝送中に損失することがある。確実な受信を保証するために、ＡＣＫメッセージをレシーバが生成及び送信する、確認応答（ＡＣＫ）を用いるＤＴＬＳを用いることができる。しかし、ＡＣＫパケットも損失することがある。無線損失や輻輳損失等、数種類のパケット損失がある場合には、ハンドシェイク遅延が長引く可能性がある。例えば証明書等、送信すべきメッセージが多い場合には、遅延がかなり大きくなり、ハンドシェイクの成功率が低下してしまう。したがって、確認応答を用いるＤＴＬＳは、特により多くのパケットを送信する際により大きな遅延を発生させる。さらに、チャネルパケット損失及び損失率は測定が容易ではない。

したがって、現在のＤＴＬＳハンドシェイクモード又は方式は、異なるパケット損失率で異なるパフォーマンスを発揮する。パケット損失の原因もまた、ＤＴＬＳハンドシェイクに大きな影響を与える。したがって、輻輳損失及び無線損失等のパケット損失の原因を考慮に入れ、ＤＴＬＳハンドシェイクの成功率をより高め、ＤＴＬＳハンドシェイクのパフォーマンスを改善することが必要である。特に、証明書を用いるＤＴＬＳハンドシェイクでは、ＤＴＬＳハンドシェイク中により多くのパケット交換を行わなければならない。パケット損失モード及びパケット損失率は、ＤＴＬＳの成功率及びハンドシェイク遅延に大きな影響を与える。

本発明は、遅延を低減する動的なＡＣＫを提案し、このＡＣＫを用いてパケット損失を推定し、伝送方式を調整することを目的とする。

本発明の目的は、パフォーマンスが改善されたハンドシェイク動作を提供することである。

この目的は、請求項１に記載の装置、請求項１１に記載の方法、及び請求項１２に記載のコンピュータプログラム製品により達成される。

したがって、パケット損失及び考えられる原因の検出に基づいてハンドシェイク方式を変更するために、ネットワークパケット損失率を計算し、ネットワークパケット損失の原因を推定することによって、パケットベースのネットワークにおけるハンドシェイクパフォーマンスを改善することができる。その結果、ハンドシェイクの成功率を高め、ハンドシェイク遅延を減らすことができる。

第１のオプションによれば、検出器は、受信されたパケットのシーケンスに基づいてパケット損失を検出するように適合される。より具体的な例示としてのＤＴＬＳ環境では、検出器はＤＴＬＳハンドシェイクシグナリングのＣｌｉｅｎｔＨｅｌｌｏメッセージのシーケンスに基づいてパケット損失を検出するように適合される。これにより、パケット損失を検出する簡単な手法を提供することができる。

第１のオプションと組み合わせることができる第２のオプションによれば、検出器は、受信された連続するパケット間の遅延が変化する場合、又は受信された連続するパケット間に順序逆転がある場合に、輻輳損失を検出したパケット損失の原因と判断するように適合される。この方策により、輻輳を検出したパケット損失の原因と確実に判断することができる。

上記第２のオプションと組み合わせることができる第３のオプションによれば、検出器は、検出されたパケット損失がランダムに分布している場合、又は受信された連続するパケット間の遅延がほぼ等しい場合に、無線損失を推定するように適合される。この方策により、無線損失を検出したパケット損失の原因と確実に判断することができる。

上記第２のオプションと組み合わせることができる第４のオプションによれば、検出器が無線損失を推定した場合には、コントローラはパケット損失率を推定し、パケット損失率に基づいてハンドシェイクの残り時間を推定し、残り時間を所定のハンドシェイクタイムアウトと比較し、推定された残り時間が所定のハンドシェイクタイムアウトよりも短い場合に、推定されたハンドシェイクの残り時間と所定のハンドシェイクタイムアウトとの比率に比例して、パケット伝送の伝送速度を増加させるように適合される。したがって、ハンドシェイク方式をパケット損失の原因である無線損失に適合させることができるため、ハンドシェイクパフォーマンスが改善される。

上記第３のオプションと組み合わせることができる第５のオプションによれば、検出器（Ｓ１、Ｃ１）が輻輳損失を推定した場合には、コントローラは、パケット損失率を推定し、パケット損失率に基づいてハンドシェイクの残り時間を推定し、残り時間を所定のハンドシェイクタイムアウトと比較し、推定された残り時間が所定のハンドシェイクタイムアウトよりも短い場合に、パケット伝送の伝送間隔を増加させ、伝送速度を減少させるように適合される。したがって、ハンドシェイク方式をパケット損失の原因である輻輳に適合させることができるため、ハンドシェイクパフォーマンスが改善する。

上記第３又は第５のオプションと組み合わせることができる第６のオプションによれば、検出器が輻輳損失を推定した場合及び装置がパケット伝送のサーバ側に位置する場合に、コントローラは、パケット伝送のクライアント側にハンドシェイクタイムアウトを延長することを通知するように適合される。これによって、輻輳損失の場合にハンドシェイクタイムアウトが延長され、輻輳状況を可能な限り排除するために伝送速度を減少させる。

上記第１〜第６のオプションの何れか１つと組み合わせることができる第７のオプションによれば、コントローラは、所定のハンドシェイクメッセージの最後の確認応答を受信するまでの総伝送時間を計算し、次の式を使用することによってパケット損失率を推定するように適合される。
ここで、Ｎ_Ｓは計算された総伝送時間を示し、Ｐ_Ｌは推定されたパケット損失率を示す。したがって、ハンドシェイクパフォーマンスは、特定のハンドシェイクメッセージだけに確認応答が必要となるように混合伝送方式を使用することによって改善することができる。長いパケットを有するメッセージは確認応答の必要がないため、ハンドシェイクの遅延が低減される。また、確認応答はパケット損失率の推定に使用することができる。計算されたパケット損失率は伝送方式を調整するのに使用される。特定のＤＴＬＳベースの例では、所定のハンドシェイクメッセージは、ＤＴＬＳハンドシェイクシグナリングのＣｌｉｅｎｔＨｅｌｌｏメッセージである。

なお、上記システムは、個別のハードウェアコンポーネントを有する個別のハードウェア回路として、集積チップとして、チップモジュールからなる装置として、又は、メモリに格納される、コンピュータ可読媒体上に書き込まれた、若しくは、インターネット等のネットワークからダウンロードされたソフトウェアルーチン又はプログラムによって制御される信号処理デバイス若しくはチップとして実現されてもよいことに留意されたい。

請求項１のシステム、請求項１１の方法、及び請求項１２のコンピュータプログラム製品は、特に従属請求項に規定されたような、同様の及び／又は同一の好ましい実施形態を有すると理解されるべきである。

本発明の好適な実施形態は、従属請求項又は上記実施形態の各独立請求項との任意の組み合わせであってもよいことは理解されるべきである。

本発明の上記及び他の態様は、後述する実施形態から明らかとなり、かかる実施形態を参照して解説されるであろう。

図１は、証明書を使用したＤＴＬＳハンドシェイクの概略的な信号図を示す。 図２は、第１の実施形態に係るクライアント及びサーバ間の非確認応答パケット伝送の概略的なブロック図を示す。 図３は、第１の実施形態に係るクライアント及びサーバ間の非確認応答パケット伝送のためのハンドオーバ制御方式の概略的なシステムアーキテクチャを示す。 図４は、第１の実施形態に係る非確認応答パケット伝送のためのハンドオーバ制御方式のサーバ側処理のフローチャートを示す。 図５は、第１の実施形態で使用するＣｌｉｅｎｔＨｅｌｌｏメッセージの第１のメッセージ構造を示す。 図６は、第１の実施形態に係る非確認応答パケット伝送のためのハンドオーバ制御方式のクライアント側処理のフローチャートを示す。 図７は、第２の実施形態に係るクライアント及びサーバ間の確認応答パケット伝送の概略的なブロック図を示す。 図８は、第２の実施形態で使用するＣｌｉｅｎｔＨｅｌｌｏメッセージの第２のメッセージ構造を示す。 図９は、第２の実施形態に係るクライアント及びサーバ間のハンドオーバインタラクションの信号図を示す。 図１０は、第２の実施形態に係る確認応答パケット伝送のためのハンドオーバ制御方式のサーバ側処理のフローチャートを示す。

これから、本発明の実施形態が、サーバ及びクライアント間のハンドシェイク方式を適応的に変更するＤＴＬＳハンドシェイクに基づいて説明される。

図２は、第１の実施形態に係るクライアント（Ｃ）１０及びサーバ（Ｓ）２０間の非確認応答パケット伝送の概略的なブロック図を示す。図２のケースでは、パケット１５はクライアント１０からサーバ２０に送信される。サーバは、損失パケット１７を判定するために受信したパケットのシーケンスをチェックする。

図３は、第１の実施形態に係るクライアント及びサーバ間の非確認応答パケット伝送のためのハンドオーバ制御方式の概略的なシステムアーキテクチャを示す。サーバ側及びクライアント側の両方に２つの機能ブロックがある。第１の機能ブロックは、パケット損失を検出するための検出ブロック（又は検出器）Ｃ１、Ｓ１である。この機能ブロックは、受信されたパケットに基づいてパケット損失を検出し、パケット損失率を推定する。第２の機能ブロックは、クライアント（Ｃ）及びサーバ（Ｓ）間のクライアントメッセージＣＭ１及びＣＭ２、並びにサーバメッセージＳＭ１及びＳＭ２の送受信方式（すなわち、ハンドシェイク方式）を変更するための制御ブロック（又はコントローラ）Ｃ２，Ｓ２である。この機能ブロックは、検出されたパケット損失に応じてハンドシェイク方式を変更するように適合されている。

ＤＴＬＳハンドシェイクメッセージは損失するため、ＤＴＬＳは再送信機構を必要とする。ＤＴＬＳは、各エンドポイントで１つのタイマを使用して再送信を実行する。各エンドポイントは、応答を受信するまで最後のメッセージを再送信し続ける。ＤＴＬＳプロトコルによれば、所定のハンドシェイクタイムアウトの初期のタイマ値は１ｓ（最小値はＲＦＣ２９８８に規定されている）に設定することができ、値は再送信の度に倍になり、最大で（ＲＦＣ２９８８に規定されているように）６０秒の最大値になる。現在のタイマ値は損失のない伝送が行われるまで保たれ、その後初期値にリセットされる。現在のタイマ値の１０倍も長いアイドル期間の後、タイマは初期値にリセットされる。これが起きる１つの状況は、大量のデータ転送の後に再ハンドシェイクが行われる時である。

図４は、第１の実施形態に係る非確認応答パケット伝送のためのハンドオーバ制御方式のサーバ側処理のフローチャートを示す。図４の処理は、具体的にはサーバ側でのパケット損失の検出及び方式変更機構に関する。

ステップＳ４０１において、サーバは、ＤＴＬＳプロトコルに従うハンドシェイク手順（すなわち、ＤＴＬＳハンドシェイク）のＣｌｉｅｎｔＨｅｌｌｏメッセージ及びＣｌｉｅｎｔＨｅｌｌｏ^＊メッセージの受信したパケットに基づいてパケット損失を検出する。各パケットはシリアルナンバーを有するため、サーバはパケットのシーケンスからパケット損失を検出することができる。

次に、ステップＳ４０２において、パケット損失のタイプに関する決定が行われる。このプロセスは次の基準に従って損失のタイプを決定する：
受信されたＣｌｉｅｎｔＨｅｌｌｏメッセージとＣｌｉｅｎｔＨｅｌｌｏ^＊メッセージの間に順序逆転があるか？もしそうなら、輻輳損失がある。
２つの連続的に受信されたパケット間の遅延は変化するか？もしそうなら、輻輳損失がある。
パケット損失はランダムに分布しているか、又は遅延はほぼ等しいか？もしそうなら、無線損失がある。

ステップＳ４０２において、無線損失と判定されると、手順は、パケット損失率を次の式を使用することにより、受信されたパケットに基づいて推定するステップＳ４１３に分岐する：

次に、ステップＳ４１４において、ハンドシェイクの残り時間を次の式を使用することにより推定する：

ここで、ｔは伝送間隔を示し、ｔ＝１／Ｒであり、Ｒは伝送速度を示す。

式（３）において、Ｎ（ｍ＝ｋ）は、レシーバがｍ個のパケットを無事に受信するのにかかる予想伝送時間を示す。レシーバは、受信したパケットを格納するバッファを有する。各パケットはシーケンスナンバーを有する。毎回ｍ個のパケットが同時に送信される。この伝送方式は、仕様書ＲＦＣ４３４７のセクション４．２．３、「データグラムトランスポート層セキュリティ」（ｈｔｔｐ：／／ｔｏｏｌｓ．ｉｅｔｆ．ｏｒｇ／ｈｔｍｌ／ｒｆｃ４３４７）に見られる。

予想伝送時間Ｎ（ｍ＝ｋ）は、パケット損失率に依存することは知られており、次のように示すことができる：

別法として、Ｎ（ｍ＝２４）及びＮ（ｍ＝２７）の値は、コンピュータシミュレーションから得ることができる。

次に、ステップＳ４１５において、推定した残りのハンドシェイク時間Ｄ_ｅと所定のハンドシェイクタイムアウトＤ_ｒとが比較される。ステップＳ４１５において、推定した残りのハンドシェイク時間Ｄ_ｅが所定のハンドシェイクタイムアウトＤ_ｒよりも短い、すなわちＤ_ｅ＜Ｄ_ｒと判定された場合は、手順はステップＳ４１６に分岐し、伝送速度を変更しない。そうでない場合は、手順はステップＳ４１７に分岐し、伝送速度を増加させる。例として、増加量は次の式を使用することにより計算することができる：

また、ステップＳ４０２において輻輳損失と判定されると、手順は、上記の式（１）を使用することにより受信したパケットに基づいてパケット損失率が推定されるステップＳ４０３に分岐する。次に、ステップＳ４０４において、ハンドシェイクの残り時間が上記の式（２）及び（３）を使用することにより推定される。

次に、ステップＳ４０５において、推定した残りのハンドシェイク時間Ｄ_ｅと所定のハンドシェイクタイムアウトＤ_ｒとが比較される。ステップＳ４０５において、推定した残りのハンドシェイク時間Ｄ_ｅが所定のハンドシェイクタイムアウトＤ_ｒよりも短い、すなわちＤ_ｅ＜Ｄ_ｒと判定された場合は、手順はステップＳ４０６に分岐し、伝送速度は変更されない。そうでない場合は、手順は、２７個のパケットが所定の間隔μ（μ＞１つのノードのプロセス遅延）で１個ずつ送信されるステップＳ４０７に分岐する。そして、伝送間隔が増加され、伝送速度が減少される。例として、減少量は次の式を使用することにより計算できる：

また、クライアント側はハンドシェイクタイムアウトの延長を通知されることができる。例として、ハンドシェイクタイムアウトは２倍、すなわちＤ_ｒ：＝Ｄ_ｒ＊２である。通知は、ＤＴＬＳハンドシェイクのＳｅｒｖｅｒＨｅｌｌｏメッセージにおける拡張として規定できる。

図５は、第１の実施形態で使用するＣｌｉｅｎｔＨｅｌｌｏメッセージの第１のメッセージ構造を示す。ＣｌｉｅｎｔＨｅｌｌｏメッセージは、２バイト（２Ｂ）長のプロトコルバージョン（ＰＶ）、時刻（ｔ）及びランダム（Ｒ）パラメータを含む３２バイト（３２Ｂ）長のランダムセクション（Ｒｄ）、０〜３２バイト長のセッションＩＤ（Ｓ−ＩＤ）、２バイト長の暗号方式パラメータ（ＣＳ）、１バイト長の圧縮方式（ＣＭ）パラメータ、及び、タイプ（Ｔ）及び拡張（Ｅｘｔ）部を含む拡張（ＥＸＴ）フィールドを含む。

図６は、第１の実施形態に係る非確認応答パケット伝送のためのハンドオーバ制御方式のクライアント側処理のフローチャートを示す。

ステップＳ６０１において、クライアント側でのパケット損失判定が行われる。クライアント側での判定は、パケット損失に関するサーバ側からの通知に基づくことができる、又はＨｅｌｌｏＶｅｒｉｆｙＲｅｑｕｅｓｔ、Ｃｅｒｔｉｆｉｃａｔｅ及びＳｅｒｖｅｒＨｅｌｌｏＤｏｎｅ等のサーバメッセージを含む、サーバから受信したパケットに基づくパケット損失の直接検出に基づくことができる。各パケットはシリアルナンバーを有するため、クライアントは、パケットのシーケンスからパケット損失を検出することができる。

次に、ステップＳ６０２において、損失のタイプに関する決定が行われる。損失のタイプは次の基準に基づく：
２つの連続的に受信したパケット間の遅延は変化するか？もしそうなら、輻輳損失がある。
パケット損失はランダムに分布しているか、又は遅延はほぼ等しいか？もしそうなら、無線損失がある。

ステップＳ６０２において無線損失と判定されると、手順は、上記の式（１）を使用することにより受信したパケットに基づいてパケット損失率が推定されるステップＳ６１３に分岐する。

次にステップＳ６１４において、ハンドシェイクの残り時間が次の式を使用することにより推定される：
ここで、ｔは伝送間隔を示し、ｔ＝１／Ｒであり、Ｒは伝送速度を示す。

式（１０）において、Ｎ（ｍ＝ｋ）は式（４）〜（６）に関連して上述されたように、レシーバがｍ個のパケットを無事に受信するのにかかる予想伝送時間を示す。別法として、Ｎ（ｍ＝２４）の値は、コンピュータシミュレーションから得ることができる。

次にステップＳ６１５において、推定された残りのハンドシェイク時間Ｄ_ｅと所定のハンドシェイクタイムアウトＤ_ｒとが比較される。ステップＳ６１５において、推定された残りのハンドシェイク時間Ｄ_ｅが所定のハンドシェイクタイムアウトＤ_ｒよりも短い、すなわちＤ_ｅ＜Ｄ_ｒと判定された場合は、手順はステップＳ６１６に分岐し、伝送速度は変更されない。そうでない場合には、手順はステップＳ６１７に分岐し、伝送速度は増加される。例として、増加量は上記の式（７）を使用することにより計算することができる。

また、ステップＳ６０２において輻輳損失が判定されると、手順は、上記の式（１）を使用することにより受信したパケットに基づいてパケット損失率が推定されるステップＳ６０３に分岐する。その後、ステップＳ６０４において、ハンドシェイクの残り時間が上記の式（２）及び（３）を使用することにより推定される。

次にステップＳ６０５において、推定された残りのハンドシェイク時間Ｄ_ｅと所定のハンドシェイクタイムアウトＤ_ｒが比較される。ステップＳ６０５において、推定された残りのハンドシェイク時間Ｄ_ｅが所定のハンドシェイクタイムアウトＤ_ｒよりも短い、すなわちＤ_ｅ＜Ｄ_ｒと判定された場合は、手順はステップＳ６０６に分岐し、伝送速度は変更されない。そうでない場合には、手順は２４個のパケットが所定の間隔μ（μ＞１つのノードのプロセス遅延）で１個ずつ送信されるステップＳ６０７に分岐する。そして、伝送間隔が増加され、伝送速度が減少される。例として、減少量は上記の式（８）を使用することにより計算することができる。

また、ハンドシェイクタイムアウトは延長できる。例として、ハンドシェイクタイムアウトは２倍、すなわちＤ_ｒ：＝Ｄ_ｒ＊２である。

図７は、第２の実施形態に係るクライアント（Ｃ）１０及びサーバ（Ｓ）２０間の確認応答パケット伝送の概略的なブロック図を示す。

第２の実施形態では、パケット１５の受信確認を行う動的確認応答メッセージ、すなわちパケット（ＡＣＫ）１６を使用し、これによって遅延を低減することが提案される。また、ＡＣＫ１６は、パケット損失を推定し、それに応じて伝送方式を調整するために使用することができる。ここでは、サーバ側及びクライアント側の両方に、ＩＰベースのネットワークにおけるＤＴＬＳパフォーマンスを改善する３つの機能ブロックがある。第１の機能ブロックは、確認応答を適応的に要求する要求ブロック（又はリクエスタ）である。第２のブロックは、ネットワークパケット損失率を計算し、例えば、上記の式（４）〜（６）を使用することにより、計算したパケット損失率に基づいてネットワークパケット損失の原因を推定することができる検出モジュール（又は検出器）である。第３のブロックは、パケット損失及び考えられる損失の原因の検出に基づいてＤＴＬＳハンドシェイク方式を変更することができる制御ブロック（又はコントローラ）である。

図８は、第２の実施形態で使用するＣｌｉｅｎｔＨｅｌｌｏメッセージの第２のメッセージ構造を示す。図５のフィールド及びパラメータに加えて、ＣｌｉｅｎｔＨｅｌｌｏメッセージの第２のメッセージ構造は、０〜３２バイト長のクッキーフィールド（ＣＫ）を含む。ＡＣＫの適応的要求は、例えば、「０」又は「１」の値をとる２値フラグとして拡張フィールド（ＥＸＴ）で規定され、通知されることができる。そして、サーバはＡＣＫ要求の受信に応答して次のように動作する：
ＡＣＫ＝１であれば、サーバはＡＣＫをクライアントに返信する必要がある。
ＡＣＫ＝０であれば、サーバはＡＣＫをクライアントに返信する必要がない。

図９は、第２の実施形態に係るクライアント及びサーバ間のハンドオーバインタラクションの信号図を示す。最初のＣｌｉｅｎｔＨｅｌｌｏメッセージは２つの部分ｐ１及びｐ２に分かれ、どちらもそれぞれＡＣＫ及びＨｅｌｌｏＶｅｒｉｆｙＲｅｑｕｅｓｔメッセージにより確認応答される。また、後続のＣｌｉｅｎｔＨｅｌｌｏ^＊メッセージは３つの部分ｐ１〜ｐ３に分かれ、そのうちの２つはＡＣＫにより確認応答され、残りの１つは、例えばＳｅｒｖｅｒＨｅｌｌｏ等のサーバメッセージにより確認応答される。

第２の実施形態に係るハンドシェイクインタラクションシグナリングでは、ＣｌｉｅｎｔＨｅｌｌｏ及びＣｌｉｅｎｔＨｅｌｌｏ^＊メッセージのみがＡＣＫ要求を有する。クライアント及びサーバは、送信済みパケット及び受信済みパケットの記録を用いてパケット損失を検出し、パケット損失率を推定することができる。

図１０は、第２の実施形態に係る確認応答パケット伝送のためのハンドオーバ制御方式のサーバ側処理のフローチャートを示す。クライアント側は、ＡＣＫ及びＨｅｌｌｏＶｅｒｉｆｙＲｅｑｕｅｓｔメッセージの検出による類似の手法を持つことができる。

ステップＳ１００１においてパケット損失が検出される。クライアント側及びサーバ側の両方においてパケット損失を検出するため以下のアプローチが用いられる。

タイムアウトが検出されると、クライアントはパケットを再送信しなければならない。クライアントは、サーバからＣｌｉｅｎｔＨｅｌｌｏ^＊の最後のＡＣＫを受信するまでの全伝送時間Ｎ_ｃを計算することができる。

次にクライアントは、次の式を使用することによりパケット損失率を推定することができる：

サーバは、ＣｌｉｅｎｔＨｅｌｌｏメッセージの第１の部分（ｐ１）を受信した後、ＡＣＫを送信する。タイムアウトがあると、サーバはパケットを再送信しなければならない。サーバは、クライアントからＣｌｉｅｎｔＨｅｌｌｏ^＊メッセージの部分３（ｐ３）を受信するまでの全伝送時間Ｎ_ｓを計算することができる。次にサーバは、次の式を使用することによりパケット損失率を推定することができる：

そして、クライアント及びサーバはどちらも、検出されたパケット損失の結果に従って伝送方式を変更するであろう。

ステップＳ１００２において、損失のタイプに関する決定が行われる。このプロセスは次の基準に従って損失のタイプを決定する：
受信したＣｌｉｅｎｔＨｅｌｌｏメッセージとＣｌｉｅｎｔＨｅｌｌｏ^＊メッセージとの間に順序逆転があるか？もしそうなら、輻輳損失がある。
２つの連続的に受信したパケット間の遅延は変化するか？もしそうなら、輻輳損失がある。
パケット損失はランダムに分布しているか、又は遅延はほぼ等しいか？もしそうなら、無線損失がある。

ステップＳ１００２において無線損失が判定されると、手順は、式（１３）及び（１４）に関連して上述したようにパケット損失率が推定されるステップＳ１０１３に分岐する。次にステップＳ１０１４において、ハンドシェイクの残り時間は次の式を使用することにより推定される：
ここで、ｔは伝送間隔を示し、ｔ＝１／Ｒであり、Ｒは伝送速度を示す。

式（１６）において、Ｎ（ｍ＝ｋ）は式（４）〜（６）に関連して上述されたように、レシーバがｍ個のパケットを無事に受信するのにかかる予想伝送時間を示す。別法として、
Ｎ（ｍ＝２４）及びＮ（ｍ＝２７）の値は、コンピュータシミュレーションから得ることができる。

次にステップＳ１０１５において、推定された残りのハンドシェイク時間Ｄ_ｅと所定のハンドシェイクタイムアウトＤ_ｒとが比較される。ステップＳ１０１５において、推定された残りのハンドシェイク時間Ｄ_ｅが所定のハンドシェイクタイムアウトＤ_ｒよりも短い、すなわちＤ_ｅ＜Ｄ_ｒと判定された場合は、手順はステップＳ１０１６に分岐し、伝送速度は変更されない。そうでない場合は、手順はステップＳ１０１７に分岐し、伝送速度は増加される。例として、増加量は上記の式（７）を使用することにより計算することができる。

また、ステップＳ１００２において輻輳損失が判定されると、手順は、上記の式（１）を使用することにより受信されたパケットに基づいてパケット損失率が推定されるステップＳ１００３に分岐する。その後ステップＳ１００４において、ハンドシェイクの残り時間が上記の式（１３）及び（１４）を使用することにより推定される。

次にステップＳ１００５において、推定された残りのハンドシェイク時間Ｄ_ｅと所定のハンドシェイクタイムアウトＤ_ｒとが比較される。ステップＳ１００５において、推定された残りのハンドシェイク時間Ｄ_ｅが所定のハンドシェイクタイムアウトＤ_ｒよりも短い、すなわちＤ_ｅ＜Ｄ_ｒと判定された場合は、手順はステップＳ１００６に分岐し、伝送速度は変更されない。そうでない場合は、手順は、パケットを所定の間隔μ（μ＞１つのノードのプロセス遅延）で１個ずつ送信するステップＳ１００７に分岐する。そして、伝送間隔が増加され、伝送速度が減少される。例として、減少量は上記の式（８）を使用することにより計算することができる。

また、クライアント側は、ハンドシェイクタイムアウトの延長を通知されることができる。例として、ハンドシェイクタイムアウトは２倍、すなわちＤ_ｒ：＝Ｄ_ｒ＊２である。通知は、ＤＴＬＳハンドシェイクのＳｅｒｖｅｒＨｅｌｌｏメッセージ又はＣｌｉｅｎｔＨｅｌｌｏ^＊メッセージの部分３の拡張として規定することができる。

このように第２の実施形態によれば、ＤＴＬＳハンドシェイクパフォーマンスは、ＣｌｉｅｎｔＨｅｌｌｏ及びＣｌｉｅｎｔＨｅｌｌｏ^＊だけがＡＣＫを必要とするようなやり方で混合伝送方法を使用することによって改善される。Ｃｅｒｔｉｆｉｃａｔｅ等の長いパケットを有するメッセージはＡＣＫを必要とせず、このことはハンドシェイクの遅延を低減する。また、パケット及びＡＣＫはパケット損失率の推定に使用される。計算されたパケット損失率は、伝送方式を調整して、ＤＴＬＳハンドシェイクのパフォーマンスを改善するために使用される。

要約すると、ハンドシェイク動作を制御するための方法及び装置が説明された。ＤＴＬＳは、ＩＰベースのモノのインターネットにおける重要なセキュアプロトコルである。ＤＴＬＳハンドシェイクのパフォーマンスは、ネットワークステータス、トラフィック及びパケット損失率等の影響を受ける可能性がかなり高い。したがって、パケット損失率を評価し、パケット損失の原因を推定することが提案される。そして、ＤＴＬＳハンドシェイク方式はパケット損失及びネットワークステータスの検出に基づいて適応的に変更される。結果として、ＤＴＬＳハンドシェイクの成功率及び遅延は改善されることができる。パケット損失率を評価し、パケット損失の原因を推定するために確認応答モードと非確認応答モードとは、混合的に使用され、最終的にＤＴＬＳハンドシェイクのパフォーマンスを向上させる。

図面及び前述の記述中に本発明を詳細に例示し且つ記載したが、そのような例示及び記述は例示的又は例証的と考えられるべきであり、限定的と考えられるべきでない。本発明は開示の実施形態に限定されない。提案されたハンドシェイク処理は、他のＩＰベースのセキュリティプロトコル、ＩＰ、照明制御、又はモノのインターネットのハンドシェイクに関連する応用例に適用でき、場合により標準化できる。

請求する発明を実施する当業者は、図面、開示、及び添付の請求項の検討から、開示の実施形態に対する他の変形を理解し且つ行い得る。請求項において、「有する（ｃｏｍｐｒｉｓｉｎｇ）」なる単語は、他の要素又はステップを排除するものではなく、不定冠詞「ａ」又は「ａｎ」は、複数を排除するものではない。単一のプロセッサ又は他のユニットは、請求項に記載される幾つかのアイテムの機能を充足する。特定の手段が相互に異なる従属請求項に引用されているという単なる事実は、これらの手段の組み合わせを有利に使用することができないことを示すものではない。

上記の説明は、本発明の特定の実施形態について詳述する。しかし、当然ながら、文章においてどれほど詳細に見えても、本発明は、多くの手法で実施することができ、したがって、開示された実施形態に限定されない。当然ながら、本発明の特定の特徴又は態様を説明するときに使用された特定の用語は、当該用語が関連付けられている本発明の特徴又は態様の任意の特定の特性を当該用語が含むことに限定されるように、本明細書において、再定義されることが暗に示されていると解釈されるべきではない。

単一のユニット又はデバイスが、請求項に記載される幾つかのアイテムの機能を充足する。特定の手段が相互に異なる従属請求項に記載されているという単なる事実は、これらの手段の組み合わせを有利に使用することができないことを示すものではない。

図４、図６及び図１０において示されたような説明された動作は、コンピュータプログラムのプログラムコード手段及び／又は専用ハードウェアとして実現されてもよい。コンピュータプログラムは、他のハードウェアと共に又はその一部として供給される光学記憶媒体又は固体媒体等の適切な媒体上に記憶及び／又は分散配置されてもよいが、インターネット又は他の有線若しくは無線電気通信システムを介するといった他の形式で分散配置されてもよい。

Claims (14)

1. パケット伝送ネットワークにおけるハンドシェイクを制御するための装置であって、
   ハンドシェイクベースのパケット伝送におけるパケット損失を検出し、検出された前記パケット損失の原因を推定するための検出器と、
   推定された前記原因に基づいて前記パケット伝送のハンドシェイク方式を変更するためのコントローラと、を有し、
   前記コントローラは、前記推定された原因によってもたれされるパケット損失率を推定し、前記パケット損失率に基づいてハンドシェイクの残り時間を推定し、前記残り時間と所定のハンドシェイクタイムアウトとを比較し、推定された前記残り時間が前記所定のハンドシェイクタイムアウトよりも長いと判定した場合に前記ハンドシェイク方式を変更する、装置。
2. 前記コントローラは、前記推定された残り時間が前記所定のハンドシェイクタイムアウトよりも短いと判定した場合に前記ハンドシェイク方式を変更しない、請求項１に記載の装置。
3. 前記検出器は、受信されたパケットのシーケンスに基づいて前記パケット損失を検出する、請求項１に記載の装置。
4. 前記検出器は、ＤＴＬＳハンドシェイクシグナリングのＣｌｉｅｎｔＨｅｌｌｏメッセージのシーケンスに基づいて前記パケット損失を検出する、請求項３に記載の装置。
5. 前記検出器は、受信された連続するパケット間の遅延が変化する場合、又は受信された連続するパケット間に順序逆転がある場合は検出された前記パケット損失の原因として輻輳損失を推定する、請求項１に記載の装置。
6. 前記検出器は、前記検出されたパケット損失がランダムに分布している場合、又は受信された連続するパケット間の遅延がほぼ等しい場合は無線損失を推定する、請求項１に記載の装置。
7. 前記検出器が無線損失を推定した場合は、前記コントローラは、パケット損失率を推定し、前記パケット損失率に基づいてハンドシェイクの残り時間を推定し、前記残り時間を所定のハンドシェイクタイムアウトと比較し、推定された前記残り時間が前記所定のハンドシェイクタイムアウトよりも長い場合に、前記推定されたハンドシェイクの残り時間と前記所定のハンドシェイクタイムアウトとの比率に比例して、前記パケット伝送の伝送速度を増加させる、請求項６に記載の装置。
8. 前記検出器が輻輳損失を推定した場合に、前記コントローラは、パケット損失率を推定し、前記パケット損失率に基づいてハンドシェイクの残り時間を推定し、前記残り時間を所定のハンドシェイクタイムアウトと比較し、推定された前記残り時間が前記所定のハンドシェイクタイムアウトよりも長い場合に、前記パケット伝送の伝送間隔を増加させ、伝送速度を減少させる、請求項５に記載の装置。
9. 前記検出器が輻輳損失を推定した場合、及び前記装置が前記パケット伝送のサーバ側に位置する場合に、前記コントローラは、前記パケット伝送のクライアント側に前記ハンドシェイクタイムアウトを延長することを通知する、請求項６に記載の装置。
10. 前記コントローラは、所定のハンドシェイクメッセージの最後の確認応答を受信するまでの総伝送時間を計算し、次の式を使用することによって前記パケット損失率を推定する、請求項７又は８に記載の装置：
    ここで、ＮＳは計算された前記総伝送時間を示し、ＰＬは推定された前記パケット損失率を示す。
11. 前記所定のハンドシェイクメッセージは、ＤＴＬＳハンドシェイクシグナリングのＣｌｉｅｎｔＨｅｌｌｏメッセージである、請求項９に記載の装置。
12. パケット伝送ネットワークにおけるハンドシェイクを制御する方法であって、
    ハンドシェイクベースのパケット伝送におけるパケット損失を検出することと、
    検出された前記パケット損失の原因を推定することと、
    前記推定された原因によってもたれされるパケット損失率を推定することと、
    前記パケット損失率に基づいてハンドシェイクの残り時間を推定することと、
    前記残り時間と所定のハンドシェイクタイムアウトとを比較することと、
    推定された前記残り時間が前記所定のハンドシェイクタイムアウトよりも長い場合に、推定された前記原因に基づいて前記パケット伝送のハンドシェイク方式を変更することと、を含む、方法。
13. 前記推定された残り時間が前記所定のハンドシェイクタイムアウトよりも短いと判定した場合に前記推定された原因に基づいて前記パケット伝送のハンドシェイク方式を変更しない、請求項１２に記載の方法。
14. コンピュータデバイスで実行される時、請求項１２又は１３に記載の方法を実施するためのコード手段を有する、コンピュータプログラム。