JP2006352500A - 自動鍵交換処理装置および自動鍵交換処理方法 - Google Patents

自動鍵交換処理装置および自動鍵交換処理方法 Download PDF

Info

Publication number
JP2006352500A
JP2006352500A JP2005175880A JP2005175880A JP2006352500A JP 2006352500 A JP2006352500 A JP 2006352500A JP 2005175880 A JP2005175880 A JP 2005175880A JP 2005175880 A JP2005175880 A JP 2005175880A JP 2006352500 A JP2006352500 A JP 2006352500A
Authority
JP
Japan
Prior art keywords
ipsec
packet
confirmation
communication
unit
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
JP2005175880A
Other languages
English (en)
Inventor
Kyosuke Osuga
恭輔 大須賀
Keiichi Takagaki
景一 高垣
Minoru Yamauchi
実 山内
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Panasonic Holdings Corp
Original Assignee
Matsushita Electric Industrial Co Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Matsushita Electric Industrial Co Ltd filed Critical Matsushita Electric Industrial Co Ltd
Priority to JP2005175880A priority Critical patent/JP2006352500A/ja
Publication of JP2006352500A publication Critical patent/JP2006352500A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】 自動鍵交換処理によって確立されたIPsec SAの不一致発生の防止。
【解決手段】 IPsec SAに対する削除通知メッセージを送信後、相手側通信装置が削除対象のIPsec SA情報の削除を実施したかを確認する。すなわち、該当IPsec SAを利用した“確認パケット”を送信し、相手側通信装置の応答を確認する(到達確認処理)。相手側通信装置からの応答パケットが返ってきた場合、IPsec SAが削除されていないことがわかるので、再度削除通知メッセージ及び“確認パケット”を送信することにより、相手側通信装置の状況を確認する。
【選択図】 図2

Description

本発明は、暗号通信システムに関する。さらに詳しくは、IPセキュリティプロトコル(IPsec)による暗号機能を内蔵した通信技術に関する。
RFC2401〜RFC2412(RFC:Request For Comments)には、1)IP(Internet Protocol)における暗号通信、2)IPパケットの認証を行うプロトコルであるIPセキュリティプロトコル(IPsec)、3)そのための情報を折衝する自動鍵交換(IKE:Internet Key Exchange)が、規定されている。以下、特に断らない限り、暗号通信には、IPsecの通信データに対する認証機能を含むこととする。
IPsecによる暗号機能を内蔵した通信装置は、セキュリティアソシエーション(暗号通信路:SA)と呼ぶ論理的な通信路上で暗号通信を行う。セキュリティアソシエーションでは、暗号通信で用いられる鍵情報(暗号鍵、認証鍵)や、適用する暗号アルゴリズム及び認証アルゴリズム情報などが管理される。特に、IPsecによる暗号通信で使用されるセキュリティアソシエーション(暗号通信路)をIPsec SAと呼ぶ。
暗号通信を行う2者間において、IPsec SAを確立する方法としては、両者において手動でIPsec SAの諸情報を設定する手動鍵設定方法がある。このほか、両者間で互いに暗号通信を行う正当な相手か否かを確認し、IPsec SAの諸情報を2者間で折衝して決定し、確立する自動鍵交換(IKE)方法もある。
IKEは特に、RFC2407〜RFC2409で規定されている。IKEでは、IPsec SAを確立するために折衝を行うが、この折衝を行うための制御用通信路をISAKMP SAと呼ぶ。このISAKMP SAは、IPsec SAを確立するためだけではなく、IPsec SAの更新や、切断(SA情報の削除)を行うためにも使用される。IPsec SAを切断するときには、削除通知メッセージを一方の通信装置から他方に送る。送信側は、削除通知メッセージを送信した後に、自端末内のSA情報を削除する。他方の通信装置は、削除通知メッセージを受信すると、メッセージに従ってSA情報を削除する。なお、ISAKMPは、Internet Security Association and Key Management Protocolの略であり、IKEの通信プロトコルを規定する名称である。
標準仕様書「RFC2407」、IETF、[平成16年11月29日検索]、インターネット<URL:http://www.ietf.org/rfc/rfc2407.txt> 標準仕様書「RFC2408」、IETF、[平成16年11月29日検索]、インターネット<URL:http://www.ietf.org/rfc/rfc2408.txt> 標準仕様書「RFC2409」、IETF、[平成16年11月29日検索]、インターネット<URL:http://www.ietf.org/rfc/rfc2409.txt>
しかし、上記IKEプロトコルを用いたIPsecによる暗号通信では、アプリケーション(あるいはそのユーザ)によりIPsec SAを切断しようとしても、削除通知メッセージが相手の通信装置に到達しない場合がある。この場合、一定期間、両方の通信装置間で暗号通信が成立しなくなる問題がある。
図22は、この問題の発生を示す説明図である。一方の通信装置Aで切断処理が行われると、この装置は保持しているSA情報を削除し、相手方の通信装置Bに削除通知メッセージを送信する。しかし、削除通知メッセージは、ネットワーク上で破棄される可能性がある。ここで、削除通知メッセージは、UDPプロトコルを使用したISAKMPメッセージの一つである。そのため、これがネットワーク上で破棄されたとしても、通信装置Bは削除通知メッセージを検知することができない。そのため、通信装置Bでは、該当するIPsecSA情報が存在したままとなる。なお、IPsec通信では、その通信方向毎にIPsec SAの情報を管理しており、IKEを用いた場合は、双方向通信を実現するIPsec SAを確立するため、各通信装置で管理されるIPsec SA情報としては入力用と出力用の計2つが存在する。しかし、図22では、双方向通信を前提とし、これらをまとめて一本のIPsec SAとして図示している。
前述のような、片方の通信装置にのみIPsec SA情報があり、他方の通信装置にはその情報が存在しない状態を、IPsec SA不一致の状態という。この状態において、SA情報を保持している通信装置Bは、既に保持しているIPsec SAを用いて、該当パケットを暗号化して送信する。これに対し、他方の通信装置Aでは、該当するIPsec SAを既に削除しているため、受信したパケットを廃棄し、暗号通信が成立しない。
この暗号通信不能の状態からの復帰は、次の方法で行うことができる。第1の方法は、不一致が発生しているIPsec SAの寿命が尽きるのを待って、再度IPsec SAを確立する方法である。第2の方法は、アプリケーションまたはそのユーザが、所定期間待って暗号通信が成立しないことを確認した後、保持しているIPsec SAを明示的に削除することによって、再度IPsec SAを確立する方法である。しかし、いずれにしても、一方の通信装置において、IPsec SAの切断処理を行ってから、再度IPsec SAの確立を開始できるまでに時間を要してしまう。
以上のように、アプリケーションまたはそのユーザによるIPsec SAの明示的な切断では、一方の通信装置から送信する削除通知メッセージが、相手側通信装置に到達しないことにより、IPsec SA不一致の状態が発生し、一定時間暗号通信が成立しなくなる。また、暗号通信の復帰までに時間を要する。
そこで、本発明は、上述したIKEにおける削除通知メッセージをサポートする通信装置間において、IPsec SA不一致の状態の発生を防止する技術を提供することを目的とする。
前記課題を解決するために、発明1は、IPsec(IPセキュリティプロトコル)及びIKE(Internet Key Exchange)に基づいてISAKMP SA(Internet Security Association and Key Management Protocol)及びIPsec SA(Security Association)を確立し、暗号通信を行う通信装置を提供する。この通信装置は、以下の手段を備えている。
・前記暗号通信の相手である相手通信装置の識別子と、その相手通信装置との間で確立しているIPsec SAに関する情報と、そのIPsec SAの確立に用いたISAKMP SAの識別子と、を記憶する管理手段、
・前記管理手段で記憶されているIPsec SA情報に対する削除通知メッセージを作成し、前記削除通知メッセージを前記相手通信装置に送信する削除通知メッセージ送信手段、
・前記削除通知メッセージの送信を、所定の終了条件が満たされるまで繰り返す終了条件判定手段。
アプリケーションやそのユーザによりIPsec SAを切断する場合に、削除通知メッセージを複数回送信するため、削除通知メッセージが相手に到達しない可能性を低減することができる。従って、通信装置間でのIPsec SA不一致の状態の発生を防止することができる。
発明2は、前記発明1において、前記管理手段で記憶されているIPsec SA情報は、IPsec SAの有効期限を含んでいる通信装置を提供する。この装置において、前記終了条件判定手段は、前記IPsec SAの有効期限が過ぎた場合、終了条件が満たされたと判断する。
IPsec SAの寿命が切れるとき、通信中の相手側通信装置において同じタイミングで寿命切れによるIPsec SAの削除が発生する。そのため、削除通知メッセージ送信の終了条件をIPsec SAの寿命切れとすることにより、削除通知メッセージの送信を終了することができ、かつIPsec SA不一致の状態の発生を免れるという効果が得られる。
発明3は、前記発明1において、前記削除通知メッセージの削除対象であるIPsec SA情報を用いたパケットを、前記削除通知メッセージを送信後の所定時間以内に受信したか否かを判断するパケット受信判定手段をさらに備える通信装置を提供する。この通信装置において、前記終了条件判定手段は、前記パケット受信判定手段の判断に基づいて前記終了条件が満たされたか否かを判断する。
終了条件判定手段は、削除通知メッセージを送信後の一定期間の間に、削除しようとしているIPsec SAを用いたIPsecパケットを受信しない場合、終了条件が満たされたと判断する。これにより、相手側通信装置が削除通知メッセージに応じて該当IPsec SA情報を削除済みの場合、必要以上に削除通知メッセージを再送せずに済み、通信装置やネットワークの負荷を軽減することができる。
発明4は、前記発明1において、前記相手通信装置に削除通知メッセージが到達したか否かを判断する確認手段をさらに備える通信装置を提供する。
削除通知メッセージが相手側通信装置に到達したか否かを判断することにより、相手側通信装置が該当IPsec SA情報を削除しているか否かを確認することができる。そのため、終了条件が「所定回数及び/または所定期間、削除通知メッセージを送信する」である場合、終了条件を満足しても、削除通知メッセージが相手側通信装置に到達したのか、それとも到達しなかったのか、を把握することができる。
発明5は、発明4において、前記終了条件判定手段は、前記確認手段の判断に基づいて前記終了条件が満たされたか否かを判断する通信装置を提供する。
「削除通知メッセージの相手側への到達」を終了条件にすれば、無駄な削除通知メッセージを送信しなくて済み、通信装置やネットワークの負荷を軽減することができる。
発明6は、前記発明4において、所定の終了条件が満たされるまで前記削除通知メッセージを送信しても、前記相手通信装置に前記削除通知メッセージが到達していないと前記確認手段が判断した場合、前記終了条件判定手段は、前記相手通信装置が前記削除対象のIPsec SA情報を削除していない旨を、ユーザに通知する通信装置を提供する。
削除通知メッセージを終了条件が満たされるまで再送した結果、その削除通知メッセージが相手側通信装置に到達しなかったことをユーザに通知することにより、IPsec SA不一致の状態を解消するために、そのユーザが何らかの措置をとることができる。例えば、そのユーザは、別の通信手段により、相手側通信装置のユーザに対し、IPsec SA情報を削除することを要求してもよい。
発明7は、前記発明4において、前記確認手段が以下の手段を有している通信装置を提供する。
・送信したパケットに対する応答パケットの一部もしくは全てが規定されている確認用プロトコルと、前記削除対象のIPsec SA情報と、を用いて確認パケットを作成し、前記確認パケットを送信する確認パケット送信手段、
・受信したパケットが前記削除対象のIPsec SA情報を用いている、かつ前記確認パケットに対する応答パケットであるか否かを判断する応答パケット判定手段。
この通信装置において、前記確認手段は、前記応答パケット判定手段の判断結果に基づいて、前記削除通知メッセージが前記相手通信装置に到達しているか否かを判断する。
例えば、1)TCPのSYNパケットに対するACKパケット、2)UDPのtftp(WRQ)パケットに対するtftp(ACK)パケット、3)ICMPのEcho Requestパケットに対するEcho Replyを、確認パケットに対する応答パケットの一例としてあげることができる。削除対象のIPsec SA情報を用いた確認パケットを送受信することにより、相手側通信装置が該当IPsec SA情報を削除しているか否かを確認することができる。ひいては、通信装置は、削除通知メッセージの再送の要否を知ることができる。応答パケットが帰ってくるということは、相手側通信装置が削除対象のIPsec SA情報を削除していないことを示しているからである。
発明8は、前記発明7において、前記確認パケット送信手段は、前記削除対象のIPsec SA情報を用いて暗号化されたデータを含む確認パケットを送信する通信装置を提供する。この通信装置において、前記応答パケット判定手段は、前記削除対象のIPsec SA情報を用いて前記応答パケット中のデータを復号化可能か否かを判断する。また、前記確認手段は、前記応答パケット判定手段が復号化可能と判断した場合、前記削除通知メッセージが前記相手通信装置に到達していないと判断する。
削除対象のIPsec SA情報を用いた暗号化・復号化が、通信相手との間で成立する場合、そのIPsec SA情報は両者で削除されていないことを示す。従って、確認パケット中のデータ及び応答パケット中のデータを削除対象のIPsec SA情報で暗号化・復号化することにより、削除通知メッセージの再送の要否を知ることができる。
発明9は、前記発明7において、前記IPsec SA情報には、IPsec SAを識別するIPsec SA識別子が含まれている通信装置を提供する。この通信装置において、前記応答パケット判定手段は、前記削除対象のIPsec SA識別子に基づいて、前記確認データに対する応答パケットであるか否かを判断する。
送信した確認データを含むパケットに受信したIPsecパケットのIPsec SAの識別子を、応答パケットであるかを判定する情報として使用することにより、IPsec SAの識別子のみを記憶しておけば、IPsec SAの情報を削除することができるため、通信装置内のメモリを効率的に利用することができるという効果が得られる。
発明10は、前記発明7において、前記管理手段は、IPsec SA情報と、前記相手通信装置との間で使用可能な確認用プロトコルに関する情報と、を対応づけてさらに記憶している通信装置を提供する。この通信装置において、前記確認パケット送信手段は、前記削除通知メッセージの1回目の送信に先立って1回目の確認パケットを前記相手通信装置に送信する。前記確認手段は、前記1回目の確認パケットに関する応答パケット判定手段の判断結果に基づいて、前記管理手段に記憶されている確認用プロトコルに関する情報を更新する状況確認手段をさらに有している。
プロトコルに関する情報とは、プロトコルを特定できる情報であればよい。最初の削除通知メッセージを送信する前に、相手側通信装置との間で使用可能な確認用プロトコルを確認し、これを管理手段に登録しておく。これにより、削除通知メッセージ送信後の確認パケットに対する応答パケットの信憑性を高めることができる。言い換えれば、IPsec SA情報が相手側通信装置に残っている限り応答パケットが帰ってくるはずであり、応答パケットがない場合はIPsec SA情報が相手側通信装置で削除されているはずである、という状態を作り出すことができる。
発明11は、前記発明7において、前記確認用プロトコルはTCPである通信装置を提供する。
TCPを用いれば、相手側通信装置から送信される応答パケットが再送される。そのため、ネットワーク上で応答パケットが廃棄された結果、削除通知メッセージを送信した通信装置に応答パケットが到達しない、という現象の発生を抑制することができる。
発明12は、前記発明7において、前記管理手段は、IPsec SAの有効期限を前記IPsec SA情報と対応づけてさらに記憶している通信装置を提供する。この通信装置において、前記確認パケット送信手段は、前記確認パケットを繰り返し送信する。前記確認手段は、前記IPsec SAの有効期限が満了すると、前記確認パケット送信手段による確認パケットの送信を停止させる。
削除通知メッセージと同様に確認パケットを繰り返し送信することで、再送された削除通知メッセージの有効/無効を判断することができる。確認パケットの送信をIPsec SAの寿命満了まで繰り返すことにより、相手側通信装置が確認用プロトコルに対応していない場合でも、確認パケットの送信を永遠に繰り返さずに済む。
発明13は、前記発明7において、前記確認パケット送信手段は、前記確認パケットを繰り返し送信し、前記相手通信装置から自動鍵交換処理の開始を意図するISAKMPパケットを受信した場合、前記確認パケットの送信を停止する通信装置を提供する。
発明10と同様、確認パケットを繰り返し送信することで、再送された削除通知メッセージの有効/無効を判断することができる。新規IPsec SA確立のためのISAKMPパケットを受信するまで、確認パケットの送信を繰り返すことにより、相手側通信装置が確認用プロトコルに対応していない場合でも、確認パケットの送信を永遠に繰り返さずに済む。特に、対応するIPsec SAを保持していない場合に、自動鍵交換処理の開始を意図するISAKMPパケットを送信する実装に対して有用である。
発明14は、発明7において、前記確認パケット送信手段は、確認パケットの作成において、パケットの送信元アドレスを前記自通信装置に設定されているアドレスとは異なるアドレスに書き換える通信装置を提供する。
本通信装置がIP通信を中継する中継装置である場合、IP通信を開始した通信装置から送信されるパケットを、本通信装置において擬似的に作成する。これにより、トンネルモードのためのIPsec SA情報を削除する場合も、確認パケットを用いて、相手側通信装置におけるIPsec SA情報の有無を判断することができる。
発明15は、ネットワークで接続された発明1に記載の通信装置を複数含む通信システムを提供する。
この通信システムを構成する各通信装置は、前記発明1と同様の作用効果を奏する。
発明16は、IPsec(IPセキュリティプロトコル)及びIKE(Internet Key Exchange)に基づいてISAKMP SA(Internet Security Association and Key Management Protocol)及びIPsec SA(Security Association)を確立し、暗号通信を行う通信方法を提供する。この方法は、以下のステップを含んでいる。
・前記暗号通信の相手である相手通信装置の識別子と、その相手通信装置との間で確立しているIPsec SAに関する情報と、そのIPsec SAの確立に用いたISAKMP SAの識別子と、を記憶する管理ステップ、
・前記ステップで記憶されているIPsec SA情報に対する削除通知メッセージを作成し、前記削除通知メッセージを前記相手通信装置に送信する削除通知メッセージ送信ステップ、
・前記削除通知メッセージの送信を、所定の終了条件が満たされるまで繰り返す終了条件判定ステップ。
この方法は、前記発明1の通信装置が実行する方法であり、発明1と同様の作用効果を奏する。
発明17は、IPsec(IPセキュリティプロトコル)及びIKE(Internet Key Exchange)に基づいてISAKMP SA(Internet Security Association and Key Management Protocol)及びIPsec SA(Security Association)を確立し、暗号通信を行うコンピュータ端末が実行する通信プログラムを提供する。この通信プログラムは、前記コンピュータ端末を、以下の手段として機能させる。
・前記暗号通信の相手である相手通信装置の識別子と、その相手通信装置との間で確立しているIPsec SAに関する情報と、そのIPsec SAの確立に用いたISAKMP SAの識別子と、を記憶する管理手段、
・前記管理手段で記憶されているIPsec SA情報に対する削除通知メッセージを作成し、前記削除通知メッセージを前記相手通信装置に送信する削除通知メッセージ送信手段、
・前記削除通知メッセージの送信を、所定の終了条件が満たされるまで繰り返す終了条件判定手。
この方法は、前記発明1の通信装置が実行するプログラムであり、発明1と同様の作用効果を奏する。なお、このプログラムを記録したコンピュータ読み取り可能な記録媒体も、本発明の範囲に含まれる。ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、CD−ROM、DVD、光磁気ディスク(MO)、その他のものが挙げられる。
本発明を用いれば、アプリケーションやそのユーザによりIPsec SAを切断する場合に、削除通知メッセージを複数回送信するため、削除通知メッセージが相手に到達しない可能性が低減する。また、削除通知メッセージが通信相手に到達したか否かの確認を行う。従って、通信装置間でのIPsec SA不一致の状態の発生を防止することができる。
<第1実施形態>
〔通信システムの構成〕
図1は、本発明の通信装置を用いた通信システムの構成例を示す説明図である。この通信システムは、複数の通信装置1a〜1fが、通信ネットワーク2で接続されて構成されている。通信装置1e,fは、他の通信装置1a,b,c,d間の通信を中継するルータである。以下、通信装置1e,fを他の通信装置1a〜dと区別する場合、ルータ1e,fという。暗号通信を行う形態には、トランスポートモード及びトンネルモードの2つがある。トランスポートモードは、2者間で暗号通信路(IPsec SA)を確立して暗号通信を行う形態である。例えば、通信装置1a、c間で通信を行う場合、通信装置1a、cの2者でIPsec SAを確立して暗号通信を行う。一方、トンネルモードは、主にパケットを中継する機器間でIPsec SAを確立して、暗号通信を行う。例えば、通信装置1a、c間で通信を行う場合に、ルータ1e、fの2者間でIPsec SAを確立し、両者間を経由する通信を両ルータ1e、f間で暗号化する。なお、ルータ1e、fにおいて暗号通信を行う条件次第では、ルータ1e、f間が中継する通信であっても、暗号通信を行わない場合もある。以後、単に通信装置1というときには、IPsec SAを確立することのできるルータ1e,f及び通信装置1a〜dを含む。
〔削除通知メッセージ〕
次に、IKEを用いた場合のIPsec SAの切断に用いられる削除通知メッセージについて説明する。
IKEでは、ISAKMP SAの確立及びIPsec SAの確立に、ISAKMPメッセージと呼ばれるメッセージフォーマットを用いたIPパケットの通信を行う。ISAKMP SAの確立には、例えばメインモードと呼ばれる折衝手順(トランザクション)があり、IPsec SAの確立には、例えばクイックモードと呼ばれる折衝手順がある。ISAKMP SAは、IPsec SAの確立・切断などに使用される制御用通信路である。
ISAKMP SA及びIPsec SAが確立している状態において、IPsecによる暗号通信が可能となる。暗号通信は、主として通信する情報の機密性及び完全性を保証するために使用される。暗号化・復号化を行うためには、鍵を必要とする。この鍵が第三者に知れると、第三者は容易にその暗号化された情報を復号化することができる。このため、鍵の管理は重要である。また、鍵は、暗号化された多くの時間を費やせば類推可能であり、さらに、同じ鍵を用いて暗号化された多く情報を集めれば、それだけ類推が容易となる。このため、IKEでは、IPsec SAが不要となった場合に削除し、必要なときには、再度IPsec SAを確立するための仕組みが提供されている。
その仕組みとして、ISAKMP SA及びIPsec SAの削除通知メッセージが、ISAKMPメッセージの一つとして規定されている。削除通知メッセージは、一方の通信装置におけるアプリケーションまたはユーザによる明示的なIPsec SAの切断時に、もう一方の通信装置に対し、IPsec SAの削除を通知するメッセージである。このメッセージは、削除ペイロード(Delete Payload)を含む通知メッセージ(Informational Exchange)として規定されている。このメッセージを受信した通信装置は、削除通知メッセージに該当するIPsec SAに関する情報を削除する。これにより、暗号通信を行っていた通信装置の両者において、不要となったIPsec SA情報を削除することができる。
〔発明の概要〕
図2は、図1の通信装置が行う処理の概要を示す説明図である。図1の通信システムにおける通信装置は、前述の削除通知メッセージが相手側通信装置に届かずにIPsec SA不一致の状態が発生するのを防ぐために、以下の処理を行う。以下では、説明を容易にするために、図1の通信装置1a,1cが通信する場合の通信装置1aの処理を例にとるが、どの通信装置であっても処理は同様に行われる。
通信装置の処理は、(i)プロトコル確認処理、(ii)削除通知メッセージ送信処理、(iii)到達確認処理、に大別される。このうち、削除通知メッセージ送信処理は本発明に必須の処理である。これらの処理を行うに先立ち、通信装置1は、RFCに規定された自動鍵交換処理を行い、ISAKMP SAを確立し(#1,#2,#3)、確立したISAKMP SAを用いてIPsec SAを確立する(#4,#5)。
(i)プロトコル確認処理では、通信装置1aは、相手側通信装置1cが使用可能な通信プロトコルを確認する。双方に使用可能なプロトコルを用いて、後述する確認パケットを送信するためである。確認パケットとは、削除通知メッセージが相手側通信装置1cに到達しているか否かを確認するために送信するパケットである。具体的には、通信装置1aは、通信装置1cに対してある通信プロトコルを用いて“事前確認パケット”を送信し(#6)、それに対する応答パケットを受信した場合(#7)、通信装置1cはその通信プロトコルを使用可能と判断する。事前確認パケット及び応答パケットには、確立したIPsec SAが用いられる。これにより、通信装置1aは、IPsec SA及び所定の通信プロトコルを用いた“確認パケット”が使用可能であるか、を判断する。
(ii)削除通知メッセージ送信処理では、通信装置1aにおいて、アプリケーションやユーザからのIPsec SA切断要求が発生した場合(#8)、削除通知メッセージを送信する(#9)。削除通知メッセージが通信装置1cに到達すれば、通信装置1cは削除対象のIPsec SA情報を、記憶領域から削除する(#10)。何らかの原因で削除通知メッセージが通信装置1cに到達しない場合、削除対象のIPsec SA情報は通信装置1cにそのまま残される。通信装置1aは、削除通知メッセージを終了条件が満たされるまで、繰り返し送信する。
(iii)到達確認処理では、通信装置1aは、相手側通信装置1cがIPsec SAを削除しているか否かを確認する。すなわち、削除通知メッセージ送信後、削除要求元の通信装置1aは、前記プロトコル確認処理で使用可能であることを確認した通信プロトコルを用い、“確認パケット”を送信する(#11)。確認パケットに対する応答パケットがなければ、相手側通信装置1cがIPsec SA情報を削除したと判断し、自端末のIPsec SA情報を削除する(#12)。ここでの“確認パケット”は、IPsecパケットである。確認パケットは、所定の条件を満たすまで繰り返し送信される。
以上の処理により、削除通知メッセージが相手側通信装置1cに到達したか否かを確認し、確認結果に応じて自端末のIPsec SA情報を削除する。そのため、削除通知メッセージが相手側通信装置1cに到達せず、その結果IPsec SA情報が通信装置1a,1c間で不一致の状態になることを防止できる。しかも、最初の削除通知メッセージ送信に先立ち、確認パケットを送信するためのプロトコルが使用可能か否かを確認することで、確認パケットに対する応答パケットの信頼度を高めることができる。
〔通信装置の構成〕
(1)全体構成
図3は、図1に示す通信装置1の機能ブロック図である。前述したように、通信装置1は、IPsec SAを確立することのできるルータ1e,f及び通信装置1a〜dを含む。通信装置1は、IKE処理部20と、アプリケーション部30と、IP処理部40と、通信部50と、を備えている。IP処理部40は、IPsec処理部60を備えている。なお、アプリケーション部30は、図3において一つのみ図示しているが、複数であってもよい。このような機能を有する通信装置10は、CPU、ROM、RAM、ハードディスクなどを有するコンピュータにより実現される。CPUは、IKE処理部20、アプリケーション部30、IP処理部40及び通信部50として機能する。
IKE処理部20及びIP処理部40には、相手通信装置との間で暗号通信を適用する条件が設定されている。この条件設定は、例えば、通信装置の初期設定としてなされてもいいし、アプリケーション部30からの設定としてなされてもよい。IKE処理部20は、アプリケーション部30またはIP処理部40からの要求に従い、自動鍵交換処理を行なう。アプリケーション部30は、アプリケーションのアルゴリズムに応じた所定の通信処理を相手通信装置との間で行ない、関連する送受信処理をIP処理部40に要求する。IP処理部40は、IPパケットの送受信に係る処理を行なう。通信部50は、通信媒体に特有の送受信処理を行なう。
上記構成を有する通信装置10は、次のように動作する。アプリケーション部30は、相手装置との通信を開始すると、相手装置に対してIPパケットの送信を試みる。IP処理部40では、IPsec処理部60を必要に応じて使用し、該当IPパケットが暗号通信の対象であるか否かを判定する。暗号通信の対象である場合は、IP処理部40はIPsec SA情報の存在を確認し、存在していれば該当IPパケットを暗号化して通信部50に送信要求を行なう。一方、IPsec SA情報が存在していない場合、IP処理部40は、IKE処理部20に対し、暗号化しようとするIPパケットの情報と共に、IPsec SAの確立を要求する。IKE処理部20は、受け取ったIPsec SA確立要求に従い、予め設定された条件に適合した相手装置との間で自動鍵交換処理(IKE折衝処理)を開始する。自動鍵交換処理におけるデータは、IPパケット上のUDP(User Datagram Protocol)を使用して送受信される。このため、自動鍵交換処理におけるデータの送受信には、IP処理部40が用いられる。
なお、アプリケーション部30は、その通信に先立ち、予めIKE処理部20に対し、相手側通信装置との間にISAKMP SA、およびIPsec SAの確立を指示することもできる。
(2)IKE処理部
図4は、IKE処理部20の機能構成を示す説明図である。IKE処理部20は、要求受付部21と、SA管理部22(管理手段に相当)と、SA確立部23と、ISAKMPメッセージ処理部24(削除通知メッセージ送信手段に相当)と、確認プロセス管理部25(パケット受信判定手段、確認手段、確認パケット送信手段、応答パケット判定手段に相当)と、を含む。
(2−1)要求受付部
要求受付部21は、アプリケーション部30やIP処理部40からのIPsec SA確立要求を受け付け、IKE折衝処理の開始をSA管理部22に指示する。また、要求受付部21は、相手通信装置との間で暗号通信を適用する条件の設定をSA管理部22に指示する。IKE折衝処理には、ISAKMP SAの確立・切断や、IPsec SAの確立・切断が含まれる。
(2−2)SA管理部
SA管理部22は、ISAKMP SA及びIPsec SA(以下、まとめてSAということがある)の確立・切断・更新を管理する。SAの管理のために、SA管理部22は管理テーブル22aを保持している。管理テーブル22aは、各ISAKMP SA及びIPsec SAに関する情報(以下、SA情報という)を記憶している。SA情報は、SAの確立・切断・更新に従い、登録・削除・更新される。また、SA管理部22は、ISAKMP SAが全くなくなった場合または全くなくなるに先立ち、新たなISAKMP SAをSA確立部23に再度、確立要求することができる。
図5は、SA管理部22が保持する管理テーブル22aに蓄積されるSA情報の概念説明図である。管理テーブル22aは、「ISAKMP SA ID」、「IPsec終端点」の通信装置の識別子及び「SPI」を少なくとも1レコードに含む。「ISAKMP SA ID」は、通信装置内に管理するISAKMP SAの識別子であり、Initator Cookie、もしくは、Responder Cookieなどを用いる。通信装置の識別子としては、この例ではIPアドレスを用いているが、その他の通信アドレスやMACアドレス等の装置固有情報を用いることもできる。「SPI(Security Parameter Index)」は、IPsec SAの識別子である。ISAKMP SA ID及びSPIは、異なる相手通信装置に対してであれば、同じ値を取ることもあり得る。
前述の情報に加え、この例では、「IPsec SAの状態」、「確認用プロトコル」及び「IPsec SAの有効期限」が、1レコード中にさらに含まれる。本実施形態では、IPsec SAの状態として、「使用可能」と、「使用不可」の二つの状態を管理している。「使用可能」の状態は、IPsec SA確立後の正常な状態であり、アプリケーション処理部30から要求される通信においてIPsec SAを使用可能であることを示す。一方、「使用不可」の状態は、ユーザまたはアプリケーションからIPsec SAの削除要求を受けた場合に遷移する状態であり、アプリケーション処理部30から要求される通信においてIPsec SAを使用できないことを示す。なお、SAの状態として、「使用可能」及び「使用不可」を含んでいれば、他の状態を含んでいてもよい。また、本実施の形態では、ISAKMP SAとIPsec SAが1対1で管理されているが、ISAKMP SA1つに対し、複数のIPsec SAが対応づけられている可能性もあるため、異なるレコードにおいて、ISAKMP SA IDが同じものが存在してもよい。
「確認用プロトコル」をIPsec SA毎に管理することで、各IPsec SA毎に確認パケットを送信するプロトコルを制御可能になる。プロトコル確認処理は、IPsec SAが確立している状態において実施する。「IPsec SAの有効期限」を管理することで、IPsec SAの寿命が尽きた時点を契機として、そのIPsec SAの削除通知メッセージやその確認パケットを送信することが可能となる。
この他に、各IPsec SA毎に、暗号アルゴリズム、暗号用鍵、認証アルゴリズム、認証用鍵など他の情報を管理していても構わない。
(2−3)SA確立部
SA確立部23は、SA管理部22からの要求に従ってSA確立のためのIKE折衝処理を行ない、ISAKMPメッセージ処理部24に対して対応するISAKMPメッセージの構築処理を要求する。また、SA管理部22は、相手通信装置からIKE折衝処理要求を受け取り、IKE折衝処理を行い、SA管理部22に対してSA情報の更新要求を行なう。SA確立及びIKE折衝処理そのものについては、RFCに規定されており、本発明はその範囲を逸脱しないので、説明は省略する。
(2−4)ISAKMPメッセージ処理部
ISAKMPメッセージ処理部24は、SA確立部23からの要求及びSA管理部22からの要求に対して該当するISAKMPメッセージの構築を行ない、IP処理部40に構築したメッセージを送信依頼する。また、ISAKMPメッセージ処理部24は、IP処理部40から受信したISAKMPメッセージをRFCの規定に従って解析する。受信したISAKMPメッセージが相手通信装置からのIKE折衝処理要求である場合は、SA確立部23にその処理を指示する。ISAKMPメッセージが削除通知であった場合、ISAKMPメッセージ処理部24はその削除通知に含まれる削除ペイロードを抽出し、SA管理部22にその処理を指示する。なお、ISAKMPメッセージ処理部24は、ISAKMPメッセージの送受信の際に、RFC2407〜RFC2409で規定されている所定の暗号化・復号化、認証情報の付加・認証情報の認証などを行なう。
(2−5)確認プロセス管理部
確認プロセス管理部25は、SA管理部22からの削除通知メッセージ送信要求を受け付け、削除通知メッセージの送信前及び後に、“事前確認パケット”や“確認パケット”の送信をIP処理部40に要求する。また、確認プロセス管理部25は、ISAKMPメッセージ処理部24に対し、削除通知メッセージ送信要求を行う。確認プロセス管理部25は、前記到達確認処理において、IP処理部40に対し、IPsec SAを適用する条件の問い合わせを行う。確認プロセス管理部25は、確認パケット送信及び応答パケット受信のために、IPsec処理部60に対し、IPsec暗号化・復号化処理及び認証処理を要求する。さらに、確認プロセス管理部25は、到達確認処理終了後、IPsec SA情報の更新または削除を、IP処理部40に要求する。確認プロセス管理部25の構成については、詳細を後述する。
〔確認プロセス管理部〕
(1)全体構成
図6は、確認プロセス管理部25の機能構成を示すブロック図である。確認プロセス管理部25は、確認プロセス実行部251(終了条件判定手段、確認手段及び状況確認手段に相当)、プロトコル記憶部252、確認パケット送信部253及びパケット受信判定部254(パケット受信判定手段に相当)を有している。
確認プロセス実行部251は、SA管理部22から削除通知メッセージ送信要求を受信し、削除通知メッセージの送信及び到達確認処理を行う。具体的には、確認プロセス実行部251は、確認パケット送信部253へ“事前確認パケット“及び“確認パケット”の送信を要求し、パケット受信判定部254に“応答パケット”の受信要求を行い、パケット受信判定結果を取得する。確認プロセス実行部251については、詳細を後述する。
プロトコル記憶部252は、通信装置自身が使用可能な通信プロトコルと、通信相手の応答の仕方と、を記憶している。
確認パケット送信部253は、確認プロセス実行部251から事前確認パケット及び確認パケットの送信要求を受け、暗号認証処理をIPsec処理部60に要求し、パケットの送信をIP処理部40に要求する。
パケット受信判定部254は、IP処理部40から受信パケットを取得し、そのパケットがどのようなパケットであるかを判定し、判定結果を確認プロセス実行部251へ渡す。パケット受信判定部254については、詳細を後述する。
(2)プロトコル記憶部
図7は、プロトコル記憶部252に記憶される情報の概念説明図である。プロトコル記憶部252には、通信装置自身が使用可能なプロトコルと、送信パケットと、応答パケットと、が対応づけられて記憶されている。例えば、プロトコルとしてTCPを用いる場合、SYNパケットに対しては、ACKパケットまたはRSTパケットが応答パケットである。SYNパケットとは、RFC793に規定されているコードビットのSYNフラグを立てたTCPヘッダを含むパケットである。ACKパケットとは、前記コードビットのACKの制御ビットを立てたTCPヘッダを含むパケットである。RSTパケットとは、前記コードビットのRSTの制御ビットを立てたTCPヘッダを含むパケットである。
同様に、UDPのtftp(WRQ)パケットに対しては、tftp(ACK)またはICMP(Port Unreachable)が応答パケットである。tftp(WRQ)パケットとは、IEN133に規定されたWRQ(Write Request)のペイロードを有するパケットである。tftp(ACK)パケットとは、IEN133に規定されたACK(Acknowledgement)のペイロードを有するパケットである。ICMP(Port Unreachable)パケットとは、RFC792に記載のコードフィールドにおいて、Port Unreachableであるペイロードを有するパケットである。
また、ICMPを用いる場合、Echo Requestパケットに対してEcho Replyが応答パケットである。また、Echoパケットとは、RFC792に記載されているEchoのペイロードを有するパケットである。
なお、図7は3つのプロトコルを一例として示しているが、ICMPv6 Echo Request、 Echo Replyなど、送信パケットに対する応答パケットが規定されているプロトコルを用いてもよい。さらに、本実施形態では、各確認用プロトコルをあらかじめ記憶しているが、アプリケーション処理部30などを用いて、プロトコルを動的に追加・削除してもよい。
(3)確認プロセス実行部
図8は、確認プロセス実行部251の機能ブロック図である。確認プロセス実行部251は、削除通知終了判定部510(終了条件判定手段に相当)、削除通知到達確認部520(確認手段に相当)及びプロトコル確認部530(状況確認手段に相当)を含む。
削除通知終了判定部510は、削除通知到達確認部520に対して到達確認処理要求を行う。また、削除通知終了判定部510は、所定の終了条件を満たすまで、繰り返し、ISAKMPメッセージ処理部24に対し、削除通知メッセージの送信要求を行う(発明1に対応)。所定の終了条件とは、例えばIPsec SAやISAKMP SAの有効期限の満了(発明2に対応)、削除通知メッセージの送信回数の上限値の超過、削除通知メッセージの到達の確認である。この他、削除通知メッセージの再送を終了するための条件は、必要に応じ、適宜設定可能である。
削除通知到達確認部520は、削除通知終了判定部510からの到達確認処理要求に応じ、到達確認処理を行う(発明4に対応)。到達確認処理は、確認パケット送信部253に対し、確認パケットの送信要求を行い、パケット受信判定部254から、パケット受信判定結果を取得する処理である。到達確認処理終了後、削除通知到達確認部520は、その結果を削除通知終了判定部510に通知する(発明5に対応)。
プロトコル確認部530は、確認パケットを送信するために使用可能なプロトコルを確認パケット送信前に確認し、使用可能なプロトコルをSA管理部22に通知する。
(4)パケット受信判定部
図9は、パケット受信判定部254の機能ブロック図である。パケット受信判定部254は、ISAKMPパケット解析部540、応答パケット判定部550及びIPsec受信部560を含む。ISAKMPパケット解析部540は、自動鍵交換処理の開始を意図するISAKMPパケットであるか、否かを解析する。IPsec受信部560は、IPsec SAを用いて送信されたパケットを解析する。パケット受信判定部254内では、受信したパケットについて各部がそれぞれ解析した結果を、確認プロセス実行部251に通知する。
〔通信装置が行う処理〕
次に、通信装置1が行うプロトコル確認処理、削除通知メッセージ送信処理、到達確認処理について、具体的に説明する。以下の説明において、プロトコルを確認するための確認パケットを事前確認パケットと呼び、削除通知メッセージ後の確認パケットと区別する。
(1)プロトコル確認処理
(1−1)メインルーチン
図10は、プロトコル確認処理のメインルーチンの流れの一例を示すフローチャートである。
ステップS1:まず、自動鍵交換処理が完了し、IPsec SAが「使用可能」状態となったら、SA管理部22は、確認プロセス管理部25内の確認プロセス実行部251に対して、IPsec SAが確立済みとなったことを通知する。
ステップS2:通知を受けた確認プロセス実行部251は、プロトコル確認部530の機能により、各確認用プロトコルが使用可能であるかを確認する処理を開始する。
ステップS3〜S4:プロトコル確認部530は、プロトコル記憶部252の先頭のエントリにセットし(S3)、先頭のエントリから送信パケットのペイロード及び応答パケットのペイロードを読み出す。さらに、プロトコル確認部530は、送信パケットのペイロードを確認パケット送信部253に、応答パケットのペイロードをパケット受信判定部254に、それぞれ確立済みのIPsec SA情報とともに渡す(S4)。確認プロセス実行部251は、プロトコル確認部530の機能により、確認パケット送信部253に対し、事前確認パケットの送信要求を行う(S4)。例えば、先頭のエントリがTCPプロトコルであれば、事前確認パケットはSYNフラグが有効となっているTCPヘッダを含む(前記図7参照)(発明11に対応)。
なお、実際に送信するときには、相手通信装置のアドレス、相手通信装置、および、自通信装置のポート情報の設定、チェックサム値の計算を行う必要がある。また、同時に送信パケットに対して相手側通信装置1からの送信が期待される応答パケットのペイロードを獲得する。このペイロードはACKフラグもしくはRSTフラグが有効となっているTCPヘッダを含むペイロードである。また、実際に利用する場合には相手通信装置のアドレス、相手通信装置、および、自通信装置のポート情報の設定を行う必要がある。
ステップS5:確認パケット送信部253は、事前確認パケット送信処理を行う。この処理では、確認パケット送信部253は、事前確認パケットを相手側通信装置1に送信する。
ステップS6:プロトコル確認部530は、確認パケット送信部253から事前確認パケットの送信結果を待機する。
ステップS7:プロトコル確認部530は、送信成功の通知を受けた場合、パケット受信判定部254にパケット受信要求を行う。要求を受けたパケット受信判定部254は、相手側通信装置1cからの応答パケットを待機し、応答パケットの有無をプロトコル確認部530に通知する。
“事前確認パケット”を受信した相手側通信装置1cは、TCPクライアント機能のみしかサポートしていない場合、またはTCPサーバ機能をサポートしていても、“事前確認パケット”のペイロードで要求されたTCPポートをbindしていない場合、対応するIPsec SAを利用してRSTを示す応答パケットを暗号化・認証処理を行い、通信装置1aに対して送信する。逆に、“事前確認パケット”のペイロードに指定されたTCPポートをbindしていれば、相手側通信装置1cは、ACKを示す応答パケットを通信装置1aに送信する。ACKを示す応答パケットにおいても、IPsec SAを利用して、暗号化・認証処理を行われたパケットが送信される。また、相手側通信装置1cがRSTを返さない実装の場合、応答パケットは送信されない。
ステップS8〜S9:応答パケット判定部550は、応答パケットを受信したか否かを、パケット受信判定部254からの通知に基づいて判断する(S8)。パケット受信判定処理の詳細は後述する。応答パケットを受信した場合、応答パケット判定部550は、プロトコル管理部530に通知し、プロトコル確認部530は、使用可能であることが確認されたプロトコルを、対応するIPsec SAのレコードに追加するよう、SA管理部22に要求する(S9)(発明10に対応)。応答パケットを受信しなかった場合、後述するステップS10に移行する。
ステップS10〜S11:前記ステップS6において、確認パケット送信部253から送信失敗の通知を受けた場合、プロトコル確認部530は、プロトコル記憶部252に登録されている全てのプロトコルについて事前確認パケットの送信を試みたか否かを確認する(S10)。事前確認パケットに対する応答パケットを受信できなかった場合も同様である。全てのプロトコルについて試みていれば、本処理を終了する。まだ送信を試みていないプロトコルがあれば、プロトコル記憶部252から次の確認用プロトコルを取得し(S11)、そのプロトコルを用いて事前確認パケットの送信を試みる(S4)。
以上の処理により、削除通知メッセージの後に送信する確認パケットを、どのプロトコルを用いて送信すればよいかを決定することができる。従って、確認パケットの信頼度を高め、ひいては削除通知メッセージの到達確認処理の信頼度を高めることができる。
(1−2)事前確認パケット送信処理サブルーチン
図11は、事前確認パケット送信処理サブルーチンの処理の流れの一例を示すフローチャートである。前記プロトコル確認処理のメインルーチンにおいてステップS5に移行すると、以下の処理が開始される。
ステップS501〜S502:確認パケット送信部253は、獲得した送信ペイロードがIPsec SAを適用する条件に適合するかを、IP処理部40に問い合わせる(S501)。もし、適合しないのであれば、確認パケット送信部253は、事前確認パケットの送信を行わず、プロトコル確認部530に送信失敗を通知する(S502)。適合する場合、ステップS503に移行する。
ステップS503:確認パケット送信部253は、事前確認パケットのペイロードに対してIPsec処理を行うために、事前確認パケットのペイロードとIPsec SA情報とをIPsec処理部60に渡し、暗号化・認証処理要求を行う。要求を受けたIPsec処理部60は、暗号化・認証処理を行い、確認パケット送信部253に暗号化・認証処理後の事前確認パケットのペイロードを渡す。IPsec処理部60における暗号化・認証処理については、RFC2401などに記載の処理を逸脱せず、その説明を省略する。
ステップS504〜S506:さらに、確認パケット送信部253は、そのペイロードにIPヘッダを追加することにより“事前確認パケット”を作成し(S504)、IP処理部40に対して送信要求を行う(S505)。さらに、確認パケット送信部253は、プロトコル確認部530に送信成功を通知する(S506)。送信要求を受けたIP処理部40は、通信部50を介して、構築した“事前確認パケット”を送信する。
(1−3)パケット受信判定処理サブルーチン
図12は、パケット受信判定処理サブルーチンの処理の流れの一例を示すフローチャートである。前記プロトコル確認処理のメインルーチンにおいてステップS7に移行すると、以下の処理が開始される。
ステップS701〜S702:パケット受信判定部254は、事前確認パケットの送信後、応答パケットの受信待ちを開始する。一定期間経過しても相手側通信装置1cからの応答がなければ(S701)、パケット受信判定部254は、応答パケット受信失敗をプロトコル確認部530に通知する(S702)。応答が返ってこない理由としては、ネットワーク上でパケットがロスした場合や、前述したように端末102がRSTを返さない実装の場合などがある。
ステップS703:一方、通信部50を介して相手側通信装置1cからパケットを受信した場合、パケット受信判定部254は、以下の処理により受信パケットが期待している応答パケットであるか否かを判定する。
ステップS704〜S706:まず、パケット受信判定部254は、受信したパケットがIPsecパケットでなければ、再度端末102からのパケットの受信待ちを一定期間行う(S704)。受信したパケットがIPsecパケットであれば、IPsec復号化処理を行うために、IPsec処理部60に、受信パケットと、送信した削除通知メッセージに対応するIPsec SAの情報とを渡し、復号化処理・認証処理を要求する。そして、復号化処理後のパケットが、期待している応答パケットであるかを確認する(S705)。応答パケットであれば、プロトコル確認部530に応答パケット受信成功を通知する(S706)。応答パケットでない場合は、再度、端末102からのパケットの受信待ちを一定期間行う(S701)。
本実施形態において、受信パケットの確認対象フィールドとしては、1)送信元ポート、宛先ポートが一致していること、2)コードビットフィールドにおいて、RSTまたはACKの制御ビットが立っていること、などが挙げられる。なお、上記確認対象フィールド以外に、TCPヘッダ内の各フィールド及びTCPペイロードの各フィールドを確認対象としてもよい。
なお、TCPプロトコルについて説明を行ったが、UDPプロトコル、ICMPプロトコルなど、送信するパケットに対して、応答パケットの一部もしくは全てが規定されている通信においても、同様の処理により確認することができる。
以上のように、パケット受信判定部254は、応答パケットの受信成功または失敗を、プロトコル確認部530に通知する。
なお、本実施形態では、SA管理部505における、確認用プロトコルのフィールドを「使用可能」、「使用不可」と示したが、応答パケットを記載することにより、代替してもよい。なお、その場合、プロトコル記憶部252にて、応答パケットとして、二つのペイロードを記憶している場合、確認用プロトコルの使用可能状況の確認処理にて、受信したペイロードのみをSA管理部505に記憶してもよいし、二つのペイロードを記憶してもよい。
また、応答パケットとして規定したデータをあらかじめ記憶せず、パケット受信判定処理において受信したパケットを応答パケットとして規定してもよい。
さらに、IPsec SAが確立した直後に、使用可能状況の確認処理を実施したが、通信装置相互において、IPsec SAが確立した状態であれば、プロトコル確認処理を実行するタイミング及び実施回数はこれに限定されない。事前確認パケットを複数回送信する場合、応答パケットも複数受信する可能性があるが、1つでも応答パケットとして判断できるパケットが受信できれば、それ以降のパケットは破棄してもよい。
さらに、プロトコル記憶部252に記憶したプロトコルをプロトコル確認処理にて使用したが、実際にIPsec SAを適用するアプリケーションによる通信の送受信パケットを記憶しておき、それを確認用プロトコルとして使用してもよい。
以上のように、プロトコル確認処理を行うことにより、IPsec SAが確立した状態において、対向通信装置からの応答パケットが確認できるため、より正確な到達確認処理が実施可能となる。
(2)削除通知メッセージ送信処理及び到達確認処理
(2−1)削除通知メッセージ送信要求処理
図13は、削除通知メッセージ送信要求処理の流れの一例を示すフローチャートである。
ステップS21〜S22:要求受付部21は、通信装置相互にIPsec SAが「使用可能」として確立している状態において、ユーザまたはアプリケーションによる削除要求を待機する。削除要求が発生すると、要求受付部21にて受け付けられ、SA管理部22に通知される(S22)。通知を受けたSA管理部22は、該当するIPsec SAの状態を「使用不可」とし、確認プロセス管理部25に削除通知メッセージ送信処理の実行を要求する。
ステップS23:確認プロセス管理部25は、後述する削除通知メッセージ送信処理を実行し、削除対象のIPsec SAについて削除通知メッセージを送信する。
確認プロセス管理部25内では、削除通知終了判定部510に到達確認処理の実行回数をあらかじめ規定しておく。削除通知終了判定部510は、ISAKMPメッセージ処理部24に削除通知メッセージ送信要求を行う。その後、所定の終了条件を満たさない間、削除通知メッセージ送信要求及び到達確認処理は繰り返される。以下では、説明を容易にするために、送信回数が規定した上限値を超えたとき、終了条件を満たすものとする。終了条件を満たす場合は、到達確認処理を終了する。また、規定した実行回数を超えても終了条件を満たさなければ、終了条件を満たさない場合の処理を行う。なお、規定する実行回数は、特に限定しないが、ネットワーク上でパケットが破棄されることも考慮し、本実施形態では2回と規定する。
(2−2)削除通知メッセージ送信処理
図14は、削除通知メッセージ送信処理の流れの一例を示すフローチャートである。前記図13の処理においてステップS23に移行すると、以下の処理が開始される。
ステップS31〜S32:確認プロセス実行部251は、削除通知メッセージの送信を要求されると、削除通知終了判定部510に通知する。削除通知終了判定部510は、少なくとも1つの確認用プロトコルが使用可能であるかを確認するために、SA管理部22に使用可能な確認用プロトコルがあるか、問い合わせる(S31)。問い合わせた結果、使用可能な確認用プロトコルが存在しない場合、確認用プロトコルなしの処理を行う(S32)。この処理については、後述する第3実施形態で詳述する。
ステップS33:一方、使用可能な確認用プロトコルが存在する場合、確認プロセス実行部251は、削除対象のIPsec SAに対する削除通知メッセージの送信を、ISKAMPメッセージ処理部504に要求する。ISAKMPメッセージ処理部24は、削除通知メッセージを作成し、IP処理部40に送信を要求する。なお、削除通知メッセージはRFC2407〜RFC2409に規定されている範囲を逸脱しないものとし、説明を省略する。
ステップS34〜S37:次に、削除通知終了判定部510は、SA管理部22に対し、削除対象のIPsec SAの有効期限が満了しているか否かを問い合わせる(S34)。寿命切れであれば、本処理を終了し、削除通知終了判定部510はSA管理部22にIPsec SAの削除要求を行う(後述するS37)。一方、IPsec SAが寿命切れでない場合、削除通知終了判定部510は、削除通知到達確認部520に到達確認処理要求を行う(発明5に対応)。削除通知到達確認部520は、到達確認処理を行い(S35)、削除通知メッセージの再送の終了条件を満たすか否かを判定する(S36)。終了条件を満たす場合、削除通知終了判定部510はSA管理部22にIPsec SAの削除要求を行い、削除通知メッセージ送信及び到達確認処理を終了する(S37)。終了条件を満たさない場合、ステップS38に移行する。
ステップS38〜S40:削除通知終了判定部510は、削除通知メッセージの送信回数をインクリメントする(S38)。インクリメントした送信回数が規定の上限値(この場合は“2”)を超えていたら(S39)、終了条件を満たさない場合の処理を行う(S40)(発明6に対応)。規定の上限値を超えていなければ、再度削除通知メッセージ送信を行う(S33)。
終了条件を満たさない場合の処理としては、ユーザに相手側通信装置1cにおけるIPsec SAが削除されていないことを通知するなどが挙げられる(発明6に対応)。このとき、自端末1aにおいて、SA管理部22に、該当するIPsec SA情報の削除を要求してもよいし、IPsec SAの状態を「使用不可能」とする要求をしてもよい。
なお、削除通知メッセージは、IPsec SAのための削除通知メッセージ、ISAKMP SAのための削除通知メッセージのどちらであってもよい。
以上の処理により、所定の終了条件を満たすまで、削除通知メッセージを繰り返し送信する。従って、削除通知メッセージを1回しか送信しない場合に比して、相手側通信装置に到達する確実性が増し、IPsec SA不一致の状態の発生確率を抑制することができる。
(2−3)到達確認処理サブルーチン
図15は、到達確認処理サブルーチンの処理の流れの一例を示すフローチャートである(発明4に対応)。この処理では、IPsecパケットである確認パケットを、繰り返し送信し、相手側通信装置1cからの応答パケットの有無を確認する。確認パケットの再送終了条件は、この例では、ISAKMPパケットを受信した場合及び再送回数が規定の上限値を超える場合である。確認パケットの再送終了条件は、これに限定されず、例えばIPsec SAの有効期限が満了した場合であっても良い(発明12に対応)。一方、該当のIPsec SAを用いて、暗号化された応答パケットを受信した場合、終了条件を満たさないと判断される。なお、規定の再送上限回数は、削除通知メッセージの再送上限回数以上であることが好ましく、本例では2回とする。
前記図14の処理でステップS35に移行すると、以下の処理が開始される。
ステップS51:削除通知到達確認部520は、確認パケット送信用に使用可能である確認用プロトコルをSA管理部22に問い合わせる。確認用プロトコルがある場合、SA管理部22は、管理テーブル22aから送信パケットのペイロード及び応答パケットのペイロードを読み出し、削除通知到達確認部520に渡す。削除通知到達確認部520は、送信パケットのペイロードを確認パケット送信部253に、応答パケットのペイロードをパケット受信判定部254に、それぞれ削除対象のIPsec SA情報とともに渡す。次に、削除通知到達確認部520は、確認パケット送信部253に対し、確認パケットの送信を要求する(発明7に対応)。確認パケット送信要求に対する確認パケット送信処理は、図11の事前確認パケット送信処理と同様である。
ステップS52:削除通知到達確認部520は、確認パケット送信失敗の通知を確認パケット送信部253から受信した場合は、SA管理部22に使用可能である確認用プロトコルの問い合わせを行い、失敗したプロトコル以外のプロトコルがあれば、それを使用して、再度確認パケットの送信要求を行う。もし、他のプロトコルが存在しなければ、終了条件を満たさないとして、到達確認処理を終了する(後述するS55)。
ステップS53:確認パケット送信成功の通知を確認パケット送信部253から受信した場合、削除通知到達確認部520は、パケット受信判定部254に受信判断処理サブルーチンの実行を要求し、相手側通信装置1cからの応答パケットを一定期間待機する。
ステップS54〜S55:削除通知到達確認部520は、応答パケット受信成功の通知を受信した場合(S54)、削除通知メッセージの送信終了条件を満たさないこととする(S55)(発明7に対応)。
ステップS56〜S58:削除通知到達確認部520は、応答パケット受信失敗の通知を受信した場合(S54)、その真偽を確認するために、確認パケットの再送を確認パケット送信部253に要求する。まず、削除通知到達確認部520は、確認パケットの再送終了条件が満たされているかを判断する。この例では、削除通知到達確認部520は、再送回数が規定の上限回数を超えているかを確認する(S56)。再送回数が規定の回数を超えていなければ、削除通知到達確認部520は、再送回数をインクリメントし(S57)、再度確認パケットの送信を確認パケット送信部253に対して要求する(S51)(発明12に対応)。再送回数が規定の上限回数を超えている場合、削除通知メッセージの終了条件を満たしていることとする(S58)(発明7に対応)。
なお、削除通知メッセージの送信は、1回につき1つとして説明したが、複数個同一の削除通知メッセージを送信しても構わない。同様に、到達確認処理を1つの“確認パケット”により実施するとして説明したが、複数の“確認パケット”により実施してもよい。
このように、本実施の形態によれば、到達確認処理を実施することにより、相手側通信装置においてIPsec SAが残っていることを確認することができ、必要以上にネットワーク負荷を上げずに、対向通信装置に対して、削除通知メッセージを送信することができる。
また、事前に確認用プロトコルの使用可能状況を確認することにより、より正確に到達確認処理を実施することができる。
また、確認用プロトコルとしてTCPプロトコルを利用することにより、ネットワーク上でパケットロスした場合においても、再送制御により、パケットが相手側通信装置1cに到達しやすくなる。
(2−4)受信判断処理サブルーチン
図16は、受信判断処理サブルーチンにおける処理の流れの一例を示すフローチャートである(発明7に対応)。前記図15の処理でステップS53に移行すると、以下の処理が開始される。
ステップS61:パケット受信判定部254は、相手側通信装置1cからのパケットを一定期間待機する(S61)。相手側通信装置1cからのパケットを一定期間内に受信しない場合、削除通知到達確認部520に対して応答パケット受信失敗を通知する(S62)。受信しなかった理由として、次の2つが考えられる。第1の理由は、通信装置1cが削除通知メッセージを受信し、削除対象のIPsec SA情報を削除したため、通信装置1aから送信したIPsec化された確認パケットを復号化処理できず、応答を返さない場合である。第2の理由は、相手側通信装置1cには、IPsec SA情報が残っており、応答パケットとしてIPsecパケットを送信したが、ネットワーク上のなんらかの問題により破棄される場合である。
ステップS63〜S65:パケット受信判定部254は、何らかのパケットを通信装置1cから受信した場合、そのパケットがISAKMPパケットであるか否かを確認する(S64)。受信したパケットが自動鍵交換処理開始のためのISKAMPパケットと判断された場合、パケット受信判定部254は応答パケット受信失敗を削除通知到達確認部520に通知する(S65)(発明13に対応)。これにより、確認パケットの再送は停止し、終了条件が満了していなければ削除通知メッセージが再送される。ISAKMPパケットを受信する理由として次の要因が考えられる。その要因は、通信装置1cが、IPsecパケットを受信したが該当するIPsec SA情報が存在しない場合、自動的に自動鍵交換処理を実行し、IPsec SAを確立しようとする実装である場合である。
ステップS66〜S68:受信したパケットがISAKMPパケットではない場合、パケット受信判定部254は、受信したパケットがIPsec化されたパケットであるか否かを判断する(S66)。IPsec化されたパケットであれば、パケット受信判定部254は、応答パケット判定部550にIPsec処理部60に復号処理を要求し、復号化されたパケットを取得し、確認パケットに対する応答パケットであるか否かの判断を要求する(S67)。応答パケットであった場合、応答パケット判定部550は、応答パケット受信成功を削除通知到達確認部520に通知する(S68)。(発明8に対応)逆に、受信したパケットが応答パケットではない場合や、IPsec化されたパケットでない場合、パケット受信判定部254は再度パケットの受信待ちを行う(S61)。
本実施形態では、受信したパケットが期待している応答パケットであるか否かの判断を、復号後のパケットに基づいて行うが、応答パケットのSPI値が確認パケットのSPI値と一致した場合に応答パケットであると判断してもよい(発明9に対応)。この場合、SPI値及び確認用プロトコルの使用可能状況フィールド以外の情報をSA管理部22に残しておく必要がないために、メモリの枯渇を防ぐことができる。
以上のように、パケット受信判定部254は、確認パケットに対する応答パケットの受信成功または失敗を、削除通知到達確認部520に通知する。
<第2実施形態>
本実施形態において、通信システムの構成及び通信装置の機能構成は、前記第1実施形態と同様である。本実施形態において、IP通信の送信元及び宛先は通信装置1a及び1cとし、自動鍵交換処理をルータ1e,f間にて行うトンネルモードの場合の処理について説明する。このときのルータとしての通信装置1e,fの機能について説明を行う。
(1)トンネルモードのパケット構成
図17は、IPsecトンネルモードのパケット構成の説明図である。IPsecトンネルモードは、IPパケット全体に対してセキュリティ機能を適用し、ルータが新たにトンネル配送用の外側IPヘッダ及びESPヘッダを追加したパケットによる通信である。第1実施形態にて説明したように、トンネルモードは主にパケットを中継する機器間でIPsec SAを確立して、暗号通信を行う。例えば、通信装置1a、c間でIP通信を行い、ルータ1e、f間で暗号通信を行う。この場合、内側IPヘッダの宛先、送信元は、通信装置1a、cであり、外側IPヘッダの宛先、送信元は、ルータ1e、fであり、内側IPヘッダと、外側IPヘッダの宛先、送信元は異なる。
このため、到達確認処理における確認パケット(事前確認パケットを含む)を作成する場合、第1実施形態とは異なる処理が必要となる。以下に、第1実施形態とは異なる箇所のみを説明する。
(2)管理テーブル
図18は、本実施形態の管理テーブル22bを示す図である。この管理テーブルは、第1実施形態における管理テーブル22aに、IP通信の送信元及び宛先を示すフィールドを追加した構成となっている。トンネルモードは、上記で説明の通り、IPsecによる通信の端点とIPによる通信の端点が異なる。そのため、確認パケットを作成するためには、IPsec通信の端点のみだけでは不十分であり、IP通信の送信元及び宛先が必要となる。それ以外のフィールドについては、前記管理テーブル22aと同様である。
(3)IP端点の取得
次に、前記第1実施形態と異なる処理について説明する。前記第1実施形態と本実施の形態の処理が異なる点は、自動鍵交換処理が完了し、IPsec SA確立後、IPsec SAが確立済みを通知するまでの処理である。図19は、SA管理部22におけるIPsec SA確立後の処理の流れを示すフローチャートである。この処理では、SA管理部22は、IPsec SAの確立済通知に先立ってIPsec SAが使用されるのを待ち、使用されたときのIPパケットによりIP通信の端点の情報を得る。確認パケットの作成において、トンネルモードでは、IP通信の端点を送信元及び宛先とするIPヘッダを持つIPパケット全体を、暗号化処理・認証処理の対象とする。しかし、トンネルモードでは、暗号通信の端点とIP通信の端点が異なり、暗号通信の端点同士で自動鍵交換処理を行うため、IPsec SAを確立する過程(自動鍵交換処理)及びIPsec SA確立後、通信が発生しない場合において、SA管理部22は、IP通信の端点を得ることができない。本処理は、SA管理部22がIP通信の端点を得るために行う処理である。
ステップS71〜S74:SA管理部22は、IPsec SAが確立された状態において(S71)、IP処理部40から中継処理を行うパケットの送信要求が生じるのを待機する(S72)。送信要求が生じると、送信パケットのペイロードがIPsec SAを適用する条件に適合するか否かを、IP処理部40に問い合わせる(S73)。SA管理部22は、IPsecが適用される条件のパケットであり、かつ、そのためのIPsec SAが存在しているかを判断する(S74)。IPsec SAが存在しなければ、SA管理部22は、自動鍵交換の実行をSA確立部23に要求し、IPsec SAを確立する。
ステップS75〜S77:一方、IPsec SAが存在すれば、対応するIPsec SAに対するIP通信の端点が記憶されているかを、SA管理部22は判断する(S75)。IP通信の端点が既に記憶されていれば、通常のIPsecパケットと同様に処理し、再度IP処理部からのIPsec適用問い合わせを待つ(S72)。記憶されていなければ、IPsec適用問い合わせを受けたパケットのIPヘッダから送信元及び宛先を読み出し、該当するIPsec SAのIP通信端点の送信元・宛先として管理テーブル22bに書き込む(S76)。書き込みが完了したら、SA管理部22は確認プロセス管理部25に対し、IPsec SA確立を通知する(S77)。
このように、SA管理部22において、トンネルモード時のIP通信端点を保持しておくことにより、確認パケット作成及び応答パケットの判断に活用できる。
(4)確認パケット及び応答パケットの作成
確認パケットの作成は、前記図10に示すプロトコル確認処理及び図15の到達確認処理サブルーチンにて行われる。これらの処理では、確認プロセス管理部25が暗号化・認証処理要求を行うと、IPsec処理部60では、IP通信のパケットを構築し、暗号化・認証処理対象をIPパケット全体として処理を行う(発明14に対応)。
また、応答パケットの判断は、図12に示すパケット受信判定処理及び図16に示す受信判断処理サブルーチンにて行う。これらの処理では、ペイロードの確認に加えて、復号後のIPパケットにおける送信元及び宛先が期待すべき結果であることを確認してもよい。
これ以外の処理に関しては、第1の実施の形態と同様に処理を行う。
本実施形態によれば、トンネルモード用のIPsec SAの削除通知メッセージに対しても、到達確認処理を行うことができる。
<第3実施形態>
図20は、第3実施形態の通信装置1における確認プロセス管理部25の機能ブロック図である。本実施形態において、通信システムの構成及び通信装置の機能構成は、確認プロセス管理部25にプロトコル記憶部252がないことを除き、前記第1実施形態と同様である。本実施形態における通信システムでは、第1実施形態と同様に、通信装置1a、1c間でIP通信及びIPsec通信を行う。
本実施形態では、削除通知メッセージの到達確認処理を実行しない。その代わり、所定時間、この例ではIPsec SAの有効期限が切れるまで、削除通知メッセージを繰り返し送信する(発明3に対応)。なお、到達確認処理を行わないため、プロトコル確認処理も行わない。
図21は、本実施形態における削除通知メッセージ送信処理の流れの一例を示すフローチャートである。本実施形態では、前記図14の削除通知メッセージ送信処理に代えて以下の処理により削除通知メッセージを送信する。
ステップS81〜S83:削除通知終了判定部510は、対応する削除通知メッセージの送信を、ISAKMPメッセージ処理部24に要求する(S81)。その後、削除通知終了判定部510は、SA管理部22にIPsec SAの有効期限が切れているかを問い合わせる(S82)。有効期限が切れている場合、削除通知終了判定部510は本処理を終了し、SA管理部22にIPsec SAの削除要求を行う(S83)。
ステップS84〜S86:一方、有効期限が切れていないか、寿命切れの通知を受ける前にパケット受信判定部254がIPsec化されたパケットを受信した場合(S84)、パケット受信判定部254は、そのIPsec化されたパケットを復号するIPsec SAの状態をSA管理部22に問い合わせる(S85)。該当するIPsec SAの状態が「使用不可」であった場合は、削除通知終了判定部510は再度削除通知メッセージを送信要求する(S81)。逆に「使用可能」であった場合は、寿命切れの通知またはIPsec化されたパケットの受信を待つ(S82,S84)。
これ以外の処理に関しては、第1実施形態と同様の処理のため、その説明を省略する。
なお、IPsec化されたパケットの受信待ちを終了するタイミングとして、IPsec SAの寿命切れを一例に挙げたが、そのタイミングはこれに限定されない。また、IPsec化されたパケットの受信後に、削除通知メッセージを送信する場合を例にとったが、IPsec化されたパケットの受信とは無関係に削除通知メッセージを送信してもよい。
このように、本実施形態によれば、「使用不可」のIPsec SAを使用したパケットを受信した場合に、相手側通信装置1cにIPsec SAが存在していることがわかり、その場合に、削除通知メッセージを送信することができる。
また、受信待ちを終了するタイミングをIPsec SAとすることで、相手側通信装置においてIPsec SAが削除された以降は、他の通信装置からの受信待ちしていたパケットを偽装したパケットを用いての攻撃に対して、削除通知メッセージを送信せずに済む。
<その他の実施形態>
前述した方法及びこの方法を実行するプログラム並びにこのプログラムを記録したコンピュータ読み取り可能な記録媒体も、本発明の範囲に含まれる。ここで記録媒体としては、コンピュータが読み書き可能なフレキシブルディスク、ハードディスク、半導体メモリ、CD−ROM、DVD、光磁気ディスク(MO)、その他のものが挙げられる。
本発明にかかる削除通知メッセージを送信する装置及び方法は、IPsecを用いた暗号通信を行う全ての通信装置に適用可能である。このような通信装置としては、例えばIP通信機能を有する家電機器や各種中継器を挙げることができる。
本発明の通信装置を用いた通信システムの構成例を示す説明図 図1の通信装置が行う処理の概要を示す説明図 図1に示す通信装置の機能ブロック図 IKE処理部の機能構成を示す説明図 SA管理部が保持する管理テーブル22aに蓄積されるSA情報の概念説明図 確認プロセス管理部の機能構成を示すブロック図 プロトコル記憶部に記憶される情報の概念説明図 確認プロセス実行部251の機能ブロック図 パケット受信判定部の機能ブロック図 プロトコル確認処理のメインルーチンの流れの一例を示すフローチャート 事前確認パケット送信処理サブルーチンの処理の流れの一例を示すフローチャート 事前確認パケット送信処理サブルーチンの処理の流れの一例を示すフローチャート 削除通知メッセージ送信要求処理の流れの一例を示すフローチャート 削除通知メッセージ送信処理の流れの一例を示すフローチャート 到達確認処理サブルーチンの処理の流れの一例を示すフローチャート 受信判断処理サブルーチンにおける処理の流れの一例を示すフローチャー IPsecトンネルモードのパケット構成の説明図 第2実施形態のSA管理部が有する管理テーブルに蓄積された情報の概念説明図 SA管理部22におけるIPsec SA確立後の処理の流れを示すフローチャート 第2実施形態の通信装置における確認プロセス管理部の機能ブロック図 削除通知メッセージ送信処理の流れの一例を示すフローチャート 従来の通信システムの説明図
符号の説明
1a〜f:通信装置
2:通信ネットワーク

Claims (17)

  1. IPsec(IPセキュリティプロトコル)及びIKE(Internet Key Exchange)に基づいてISAKMP SA(Internet Security Association and Key Management Protocol)及びIPsec SA(Security Association)を確立し、暗号通信を行う通信装置であって、
    前記暗号通信の相手である相手通信装置の識別子と、その相手通信装置との間で確立しているIPsec SAに関する情報と、そのIPsec SAの確立に用いたISAKMP SAの識別子と、を記憶する管理手段と、
    前記管理手段で記憶されているIPsec SA情報に対する削除通知メッセージを作成し、前記削除通知メッセージを前記相手通信装置に送信する削除通知メッセージ送信手段と、
    前記削除通知メッセージの送信を、所定の終了条件が満たされるまで繰り返す終了条件判定手段と、
    を備えることを特徴とする通信装置。
  2. 前記管理手段で記憶されているIPsec SA情報は、IPsec SAの有効期限を含んでおり、
    前記終了条件判定手段は、前記IPsec SAの有効期限が過ぎた場合、終了条件が満たされたと判断することを特徴とする、請求項1に記載の通信装置。
  3. 前記削除通知メッセージの削除対象であるIPsec SA情報を用いたパケットを、前記削除通知メッセージを送信後の所定時間以内に受信したか否かを判断するパケット受信判定手段をさらに備え、
    前記終了条件判定手段は、前記パケット受信判定手段の判断に基づいて前記終了条件が満たされたか否かを判断することを特徴とする、請求項1に記載の通信装置。
  4. 前記相手通信装置に削除通知メッセージが到達したか否かを判断する確認手段をさらに備えることを特徴とする、請求項1に記載の通信装置。
  5. 前記終了条件判定手段は、前記確認手段の判断に基づいて前記終了条件が満たされたか否かを判断することを特徴とする、請求項4に記載の通信装置。
  6. 所定の終了条件が満たされるまで前記削除通知メッセージを送信しても、前記相手通信装置に前記削除通知メッセージが到達していないと前記確認手段が判断した場合、前記終了条件判定手段は、前記相手通信装置が前記削除対象のIPsec SA情報を削除していない旨を、ユーザに通知することを特徴とする、請求項4に記載の通信装置。
  7. 前記確認手段は、
    送信したパケットに対する応答パケットの一部もしくは全てが規定されている確認用プロトコルと、前記削除対象のIPsec SA情報と、を用いて確認パケットを作成し、前記確認パケットを送信する確認パケット送信手段と、
    受信したパケットが前記削除対象のIPsec SA情報を用いている、かつ前記確認パケットに対する応答パケットであるか否かを判断する応答パケット判定手段と、を有しており、
    前記確認手段は、前記応答パケット判定手段の判断結果に基づいて、前記削除通知メッセージが前記相手通信装置に到達しているか否かを判断することを特徴とする、請求項4に記載の通信装置。
  8. 前記確認パケット送信手段は、前記削除対象のIPsec SA情報を用いて暗号化されたデータを含む確認パケットを送信し、
    前記応答パケット判定手段は、前記削除対象のIPsec SA情報を用いて前記応答パケット中のデータを復号化可能か否かを判断し、
    前記確認手段は、前記応答パケット判定手段が復号化可能と判断した場合、前記削除通知メッセージが前記相手通信装置に到達していないと判断することを特徴とする、請求項7に記載の通信装置。
  9. 前記IPsec SA情報には、IPsec SAを識別するIPsec SA識別子が含まれており、
    前記応答パケット判定手段は、前記削除対象のIPsec SA識別子に基づいて、前記確認データに対する応答パケットであるか否かを判断することを特徴とする、請求項7に記載の通信装置。
  10. 前記管理手段は、IPsec SA情報と、前記相手通信装置との間で使用可能な確認用プロトコルに関する情報と、を対応づけてさらに記憶し、
    前記確認パケット送信手段は、前記削除通知メッセージの1回目の送信に先立って1回目の確認パケットを前記相手通信装置に送信し、
    前記確認手段は、前記1回目の確認パケットに関する応答パケット判定手段の判断結果に基づいて、前記管理手段に記憶されている確認用プロトコルに関する情報を更新する状況確認手段をさらに有することを特徴とする、請求項7に記載の通信装置。
  11. 前記確認用プロトコルは、TCPであることを特徴とする、請求項7に記載の通信装置。
  12. 前記管理手段は、IPsec SAの有効期限を前記IPsec SA情報と対応づけてさらに記憶し、
    前記確認パケット送信手段は、前記確認パケットを繰り返し送信し、
    前記確認手段は、前記IPsec SAの有効期限が満了すると、前記確認パケット送信手段による確認パケットの送信を停止させることを特徴とする、請求項7に記載の通信装置。
  13. 前記確認パケット送信手段は、前記確認パケットを繰り返し送信し、前記相手通信装置から自動鍵交換処理の開始を意図するISAKMPパケットを受信した場合、前記確認パケットの送信を停止することを特徴とする、請求項7に記載の通信装置。
  14. 前記確認パケット送信手段は、確認パケットの作成において、パケットの送信元アドレスを前記自通信装置に設定されているアドレスとは異なるアドレスに書き換えることを特徴とする請求項7に記載の通信装置。
  15. ネットワークで接続された請求項1に記載の通信装置を複数含むことを特徴とする通信システム。
  16. IPsec(IPセキュリティプロトコル)及びIKE(Internet Key Exchange)に基づいてISAKMP SA(Internet Security Association and Key Management Protocol)及びIPsec SA(Security Association)を確立し、暗号通信を行う通信方法であって、
    前記暗号通信の相手である相手通信装置の識別子と、その相手通信装置との間で確立しているIPsec SAに関する情報と、そのIPsec SAの確立に用いたISAKMP SAの識別子と、を記憶する管理ステップと、
    前記ステップで記憶されているIPsec SA情報に対する削除通知メッセージを作成し、前記削除通知メッセージを前記相手通信装置に送信する削除通知メッセージ送信ステップと、
    前記削除通知メッセージの送信を、所定の終了条件が満たされるまで繰り返す終了条件判定ステップと、
    を備えることを特徴とする通信方法。
  17. IPsec(IPセキュリティプロトコル)及びIKE(Internet Key Exchange)に基づいてISAKMP SA(Internet Security Association and Key Management Protocol)及びIPsec SA(Security Association)を確立し、暗号通信を行うコンピュータ端末が実行する通信プログラムであって、
    前記暗号通信の相手である相手通信装置の識別子と、その相手通信装置との間で確立しているIPsec SAに関する情報と、そのIPsec SAの確立に用いたISAKMP SAの識別子と、を記憶する管理手段、
    前記管理手段で記憶されているIPsec SA情報に対する削除通知メッセージを作成し、前記削除通知メッセージを前記相手通信装置に送信する削除通知メッセージ送信手段、及び
    前記削除通知メッセージの送信を、所定の終了条件が満たされるまで繰り返す終了条件判定手段、
    として前記コンピュータ端末を機能させることを特徴とする通信プログラム。
JP2005175880A 2005-06-16 2005-06-16 自動鍵交換処理装置および自動鍵交換処理方法 Pending JP2006352500A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2005175880A JP2006352500A (ja) 2005-06-16 2005-06-16 自動鍵交換処理装置および自動鍵交換処理方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2005175880A JP2006352500A (ja) 2005-06-16 2005-06-16 自動鍵交換処理装置および自動鍵交換処理方法

Publications (1)

Publication Number Publication Date
JP2006352500A true JP2006352500A (ja) 2006-12-28

Family

ID=37647857

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2005175880A Pending JP2006352500A (ja) 2005-06-16 2005-06-16 自動鍵交換処理装置および自動鍵交換処理方法

Country Status (1)

Country Link
JP (1) JP2006352500A (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008199498A (ja) * 2007-02-15 2008-08-28 Nippon Telegr & Teleph Corp <Ntt> ゲートウェイ装置およびセッション管理方法
JP2008301072A (ja) * 2007-05-30 2008-12-11 Ricoh Co Ltd 暗号通信路復帰方法、暗号通信装置及び暗号通信システム
JP2009207049A (ja) * 2008-02-29 2009-09-10 Mitsubishi Electric Corp 通信装置
JP2010193044A (ja) * 2009-02-17 2010-09-02 Konica Minolta Business Technologies Inc ネットワーク機器及び通信制御方法
JP2012175121A (ja) * 2011-02-17 2012-09-10 Seiko Epson Corp 印刷装置及び印刷装置のsa確立方法
JP2012175501A (ja) * 2011-02-23 2012-09-10 Seiko Epson Corp インターネット通信システム、周辺装置、saパラメータ・セットの削除方法、及びsaパラメータ・セットの削除プログラム
JP2012177942A (ja) * 2012-06-07 2012-09-13 Ricoh Co Ltd 暗号通信路復帰方法、暗号通信装置及び暗号通信システム
US9246682B2 (en) 2013-01-21 2016-01-26 Canon Kabushiki Kaisha Communication apparatus, method for controlling communication apparatus, and program

Cited By (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008199498A (ja) * 2007-02-15 2008-08-28 Nippon Telegr & Teleph Corp <Ntt> ゲートウェイ装置およびセッション管理方法
JP2008301072A (ja) * 2007-05-30 2008-12-11 Ricoh Co Ltd 暗号通信路復帰方法、暗号通信装置及び暗号通信システム
JP2009207049A (ja) * 2008-02-29 2009-09-10 Mitsubishi Electric Corp 通信装置
JP2010193044A (ja) * 2009-02-17 2010-09-02 Konica Minolta Business Technologies Inc ネットワーク機器及び通信制御方法
US8510574B2 (en) 2009-02-17 2013-08-13 Konica Minolta Business Technologies, Inc. Network apparatus and communication controlling method
JP2012175121A (ja) * 2011-02-17 2012-09-10 Seiko Epson Corp 印刷装置及び印刷装置のsa確立方法
JP2012175501A (ja) * 2011-02-23 2012-09-10 Seiko Epson Corp インターネット通信システム、周辺装置、saパラメータ・セットの削除方法、及びsaパラメータ・セットの削除プログラム
JP2012177942A (ja) * 2012-06-07 2012-09-13 Ricoh Co Ltd 暗号通信路復帰方法、暗号通信装置及び暗号通信システム
US9246682B2 (en) 2013-01-21 2016-01-26 Canon Kabushiki Kaisha Communication apparatus, method for controlling communication apparatus, and program

Similar Documents

Publication Publication Date Title
EP3635939B1 (en) Seamless mobility and session continuity with tcp mobility option
Lindgren et al. Probabilistic routing protocol for intermittently connected networks
JP4770227B2 (ja) Sipメッセージの暗号化方法,および暗号化sip通信システム
JP4271451B2 (ja) インターネット鍵交換データパケットをフラグメント化および再組み立てするための方法および装置
Hoffman SMTP service extension for secure SMTP over transport layer security
JP3629237B2 (ja) ノード装置及び通信制御方法
EP1880525B1 (en) Host identity protocol method and apparatus
US8843738B2 (en) TLS abbreviated session identifier protocol
JP2006352500A (ja) 自動鍵交換処理装置および自動鍵交換処理方法
US7558956B2 (en) Communications device and communications program
US20110299386A1 (en) Apparatus and method for switching between redundant communication devices
US20110258450A1 (en) Method for transmitting syncml synchronization data
JP2016025658A (ja) インタレストリターン制御メッセージ
US20040162983A1 (en) Common key exchanging method and communication device
JP4215010B2 (ja) 可変ipアドレス環境下におけるセキュリティアソシエーション継続方法および端末装置
Sakane et al. Kerberized internet negotiation of keys (KINK)
Moskowitz et al. Rfc 5201: Host identity protocol
JP2006185194A (ja) サーバ装置、通信制御方法及びプログラム
JP4721715B2 (ja) 通信装置及び通信プログラム
JP2006019824A (ja) セキュア通信システム、管理装置および通信端末
JP4788264B2 (ja) 暗号化通信方法および通信装置
JP4013920B2 (ja) 通信システム、通信装置及びその動作制御方法並びにプログラム
JP2005167608A (ja) 暗号通信装置、暗号通信方法、コンピュータプログラム、及びコンピュータ読み取り可能な記録媒体
KR100925636B1 (ko) 응용 서비스 제공을 위한 비-피씨형 단말과 서버 간의 통신방법
Camarillo et al. Host Identity Protocol (HIP) Immediate Carriage and Conveyance of Upper-Layer Protocol Signaling (HICCUPS)