JP3914959B2 - Data communication method and system - Google Patents
Data communication method and system Download PDFInfo
- Publication number
- JP3914959B2 JP3914959B2 JP2006214395A JP2006214395A JP3914959B2 JP 3914959 B2 JP3914959 B2 JP 3914959B2 JP 2006214395 A JP2006214395 A JP 2006214395A JP 2006214395 A JP2006214395 A JP 2006214395A JP 3914959 B2 JP3914959 B2 JP 3914959B2
- Authority
- JP
- Japan
- Prior art keywords
- sip
- communication device
- message
- uri
- address
- 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.)
- Expired - Fee Related
Links
Images
Landscapes
- Data Exchanges In Wide-Area Networks (AREA)
Description
本発明は、データ通信方法およびシステムに関し、更に詳しくは、クライアントとサーバとの間での暗号化データ通信を可能にし、且つ、セッション管理サーバを利用して、クライアントとサーバとの間の認証手順を容易にしたデータ通信方法およびシステムを提供することにある。 The present invention relates to a data communication method and system, and more particularly, enables encrypted data communication between a client and a server, and uses a session management server to perform an authentication procedure between the client and the server. It is an object of the present invention to provide a data communication method and system that facilitates the above.
ネットワークにおける暗号化通信方法では、クライアントとサーバは、互いに意図しない相手装置との通信を防止するため、相手装置について認証手順を実行し、相手装置の認証に成功した時、通信に使用する暗号化パラメータを交換するようにしている。IETF(Internet Engineering Task Force)のRFC2401(非特許文献1)に記述されたIPsec(Internet Protocol Security)や、RFC2246(非特許文献2)に記述されたTLS(Transport Layer Security)では、通信相手の認証に公開鍵証明書が適用される。 In the encrypted communication method in the network, the client and the server execute an authentication procedure for the partner device in order to prevent communication with the other device that is not intended for each other, and the encryption used for communication when the partner device is successfully authenticated. The parameters are exchanged. In the Internet Engineering Task Force (IETF) RFC2401 (Non-Patent Document 1) and IPsec (Internet Protocol Security) described in RFC2246 (Non-Patent Document 2), authentication of a communication partner is performed. The public key certificate is applied to.
公開鍵証明書を用いた認証では、通信相手が提示した公開鍵証明書が信頼できる認証局から発行されたものであることを何らかの方法で検証する必要がある。公開鍵証明書の検証方法の1つとしては、例えば、通信相手が提示する公開鍵証明書の発行元認証局を証明するための信頼性のある認証局root証明書を何らかの方法で事前に入手しておき、通信相手の認証手順において、相手装置が提示した公開鍵証明書に付与された認証局の署名を、認証局のroot証明書の公開鍵によって検証する方法ある。この検証方法によれば、サーバとクライアントは、通信対象となる全ての通信装置の公開鍵証明書に対応して、各公開鍵証明書の発行元認証局のroot証明書を事前に用意しておく必要がある。 In authentication using a public key certificate, it is necessary to verify in some way that the public key certificate presented by the communication partner is issued from a trusted certificate authority. As one method of verifying a public key certificate, for example, a reliable certificate authority root certificate for proving the issuing certificate authority of the public key certificate presented by the communication partner is obtained in advance by some method. There is a method of verifying the signature of the certificate authority given to the public key certificate presented by the partner apparatus with the public key of the root certificate of the certificate authority in the authentication procedure of the communication partner. According to this verification method, the server and the client prepare in advance the root certificate of the issuing certificate authority of each public key certificate corresponding to the public key certificate of all communication devices to be communicated. It is necessary to keep.
例えば、図1に示すように、複数のクライアント(端末装置)CL1、CL2、CL3が、それぞれ発行元(CA1、CA2、CA3)の異なる秘密鍵SK1、SK2、SK3と公開鍵証明書PK1、PK2、PK3を所持し、サーバSV1、SV2、SV3も、それぞれ発行元(CA1、CA2、CA3)の異なる秘密鍵SK11、SK12、SK13と公開鍵証明書PK11、PK12、PK13を所持したシステムを想定する。ここで、各クライアントが、複数のサーバSV1、SV2、SV3と随時に通信できるようにするためには、図示したように、各サーバに、通信相手となる全てのクライアント装置CL1、CL2、CL3がもつ公開鍵証明書(PK1、PK2、PK3)の発行元認証局(CA1、CA2、CA3)と対応して、複数のroot証明書RT1、RT2、RT3を事前に所持しておく必要がある。同様に、各クライアントにも、通信相手となるサーバSV1、SV2、SV3がもつ公開鍵証明書(PK11、PK12、PK13)の発行元認証局(CA1、CA2、CA3)と対応して、複数のroot証明書RT1、RT2、RT3を事前に用意しておく必要がある。また、このシステム構成では、各クライアント装置とサーバは、通信相手を変えた時、その都度、認証処理を繰り返す必要がある。 For example, as shown in FIG. 1, a plurality of clients (terminal devices) CL1, CL2, and CL3 have secret keys SK1, SK2, and SK3 and public key certificates PK1 and PK2 with different issuers (CA1, CA2, and CA3), respectively. , PK3, and the servers SV1, SV2, and SV3 also have secret keys SK11, SK12, and SK13 and public key certificates PK11, PK12, and PK13 with different issuers (CA1, CA2, and CA3). . Here, in order to allow each client to communicate with a plurality of servers SV1, SV2, and SV3 at any time, as shown in the figure, each server has all client devices CL1, CL2, and CL3 as communication partners. It is necessary to have a plurality of root certificates RT1, RT2, RT3 in advance corresponding to the issuing certificate authorities (CA1, CA2, CA3) of the public key certificates (PK1, PK2, PK3). Similarly, each client also has a plurality of public key certificates (PK11, PK12, PK13) issued by certificate authorities (CA1, CA2, CA3) of the servers SV1, SV2, SV3 as communication partners, It is necessary to prepare the root certificates RT1, RT2, and RT3 in advance. In this system configuration, each client device and server needs to repeat the authentication process each time the communication partner is changed.
図2は、上記RFC2401に記述されたIPsecによる暗号化通信を行うためにクライアントが備えるソフトウェアの基本的なブロック構成を示す。
ここで、20は、ネットワークインタフェースカード(NIC)部、30は、TCP/IPレイヤ、40は、アプリケーションレイヤのソフトウェア部を示し、50は、RFC2409(非特許文献3)に記述された鍵管理(IKE:Internet Key Exchange)プロセス用のソフトウェア部を示している。IPsecエンジン31は、TCP/IPレイヤのソフトウェアの一部として装備され、送信パケットに暗号化を適用するか否かの判定情報(SP情報)を記憶したSPDB(Security Policy Data Base)32と、暗号化通信に適用する暗号化方式や暗号鍵等の情報(SA情報)を記憶したSADB(Security Association Data Base)33とを備えている。
FIG. 2 shows a basic block configuration of software included in a client for performing encrypted communication by IPsec described in RFC2401.
Here, 20 is a network interface card (NIC) unit, 30 is a TCP / IP layer, 40 is a software unit of an application layer, and 50 is a key management described in RFC 2409 (Non-Patent Document 3). A software part for an IKE (Internet Key Exchange) process is shown. The IPsec
上記クライアントの通信相手となるサーバも、図2と同様のソフトウェアを有し、クライアントとサーバのアプリケーションレイヤ同士、鍵管理プロセス同士が互いに通信するようになっている。 The server that is the communication partner of the client also has the same software as in FIG. 2, and the application layers of the client and the server and the key management processes communicate with each other.
IPsecエンジン31は、アプリケーションレイヤ40のプログラムが発行したIPパケットの送信要求を検出すると、該IPパケットのヘッダ情報をSPDB32で検証し、このIPパケットにIPsecを適用すべきか否かを判定する。IPパケットにIPsecを適用すると判断したIPsecエンジン31は、SADB33から、IPパケットに適用すべきSA(Security Association)情報を取得する。ここで、もし、SADB33に上記IPパケットと対応するSA情報が登録されていなかった場合、IPsecエンジン31は、IKE(鍵管理)プロセス50に対して、通信相手(接続先サーバ)との間での暗号鍵を含むSA情報の交換を要求する。
When detecting an IP packet transmission request issued by the
IKEプロセス50は、RFC2408(非特許文献4)に記載されたISAKMP(Internet Security Association and Key Management Protocol)に従って、通信相手とSA情報を交換する。ISAKMPでは、通信相手との間に暗号化通信路を形成した後、相手装置が通信を許容された真正な装置か否かを確認するための認証手順を実行する。IKEプロセス50は、上記認証手順によって、相手装置が暗号化通信を許容された真正な装置であることを確認すると、ISAKMPによって設定された通信路を介して、相手装置とSA情報の交換を開始する。IKEプロセス50は、通信相手とのSA情報の交換が完了すると、IPsecエンジン31に、SA情報とこれに対応したSP(Security Policy)情報を通知する。
The IKE
IPsecエンジン31は、IKEプロセス50から通知されたSP情報とSA情報をそれぞれSPDB32、SADB33に格納した後、IPパケットを上記SA情報に従って暗号化して、通信相手に送信する。通信相手となるサーバ側では、上記暗号化されたIPパケットを受信すると、IKEプロセスによって合意したSA情報に従って受信IPパケットを復号化し、サーバ側アプリケーションレイヤにIPパケットの受信を通知する。
The IPsec
一方、RFC3261(非特許文献5)には、TLS(Transport Layer Security)によって、クライアント(ユーザエージェントクライアント)とセッション管理サーバであるSIP(Session Initiation Protocol)プロキシとの間、およびSIPプロキシとサーバ(ユーザエージェント・サーバ)との間の相互認証を行って、クライアントとSIPプロキシ、SIPプロキシとサーバが暗号化通信する方法が記載されている。RFC3261のSIPモデルによれば、クライアントとサーバは、それぞれがSIPプロキシによって真正な通信相手として確認済みであり、且つ、クライアントとサーバとの間では、暗号化されたSIPメッセージが送受信されるため、クライアント、サーバ、SIPプロキシ以外の他の装置が、上記クライアントとサーバとの間の通信内容を傍受することは困難となっている。 On the other hand, RFC 3261 (Non-Patent Document 5) describes, by TLS (Transport Layer Security), between a client (user agent client) and a SIP (Session Initiation Protocol) proxy that is a session management server, and between a SIP proxy and a server (user A method is described in which the client and the SIP proxy and the SIP proxy and the server perform encrypted communication by performing mutual authentication with the agent / server. According to the RFC 3261 SIP model, the client and the server are each confirmed as a genuine communication partner by the SIP proxy, and an encrypted SIP message is transmitted and received between the client and the server. It is difficult for devices other than the client, server, and SIP proxy to intercept the communication contents between the client and the server.
SIPは、テキストベースのプロトコルであり、SIPメッセージは、ヘッダ部と、セッション内容を示すメッセージボディ部とからなる。SIPに関しては、RFC3263(非特許文献6)に記述されている。また、RFC2327(非特許文献7)には、セッション記述に適用されるSDP(Session Description Protocol)と、クライアントとサーバとの間で交換される暗号化パラメータの記述方法について開示されている。SIPモデルのクライアントとサーバは、それぞれがSIPプロキシとの間に形成した暗号通信路を介して、SIPメッセージによってセッション記述と暗号化パラメータを交換した後、上記暗号化パラメータを適用して、暗号化パケットを通信することができる。 SIP is a text-based protocol, and a SIP message is composed of a header part and a message body part indicating session contents. The SIP is described in RFC 3263 (Non-Patent Document 6). RFC 2327 (Non-Patent Document 7) discloses a method for describing an SDP (Session Description Protocol) applied to session description and an encryption parameter exchanged between a client and a server. The SIP model client and server exchange session descriptions and encryption parameters by SIP messages via an encrypted communication path formed between each of them and a SIP proxy, and then apply the above encryption parameters for encryption. Packets can be communicated.
図3は、上述したSIPプロキシを適用した認証システムの1例を示す。ここで、PRは、複数のクライアントCL1、CL2、CL3と、複数のサーバSV1、SV2、SV3とに接続されたSIPプロキシを示す。SIPプロキシPRは、認証局CA4が発行した秘密鍵SK30と、公開鍵証明書PK30を使用しており、サーバSV1、SV2、SV3を認証するために、これらのサーバが使用する公開鍵証明書の発行元認証局(CA1、CA2、CA3)と対応した複数のroot証明書RT1、RT2、RT3を予め所持している。 FIG. 3 shows an example of an authentication system to which the above-described SIP proxy is applied. Here, PR indicates a SIP proxy connected to a plurality of clients CL1, CL2, CL3 and a plurality of servers SV1, SV2, SV3. The SIP proxy PR uses the private key SK30 issued by the certificate authority CA4 and the public key certificate PK30, and the public key certificate used by these servers to authenticate the servers SV1, SV2, and SV3. A plurality of root certificates RT1, RT2, RT3 corresponding to the issuing certificate authorities (CA1, CA2, CA3) are possessed in advance.
SIPプロキシを適用した認証システムでは、各サーバとクライアントは、図3に示すように、通信相手を認証するためのroot証明書として、SIPプロキシPRが使用する公開鍵証明書PK30の発行元認証局と対応したroot証明書RT4のみを所持すればよい。また、各クライアントは、SIPプロキシPRを介して1つのサーバと通信した後、接続先を別のサーバに変更する場合、SIPプロキシとの間では既に構築済みの暗号通信路を使用して通信できるため、新たな通信相手との間で暗号化パラメータを交換するだけで、暗号化通信を開始することが可能となる。つまり、SIPプロキシを適用した認証システムでは、各クライアントにとって、接続先サーバの変更の都度、新たに認証処理を行う必要がないという利点がある。 In the authentication system to which the SIP proxy is applied, each server and client, as shown in FIG. 3, issuer certificate authorities of public key certificates PK30 used by the SIP proxy PR as a root certificate for authenticating a communication partner. It is only necessary to have a root certificate RT4 corresponding to. Each client can communicate with the SIP proxy using the already established encryption communication path when changing the connection destination to another server after communicating with one server via the SIP proxy PR. Therefore, encrypted communication can be started only by exchanging encryption parameters with a new communication partner. That is, the authentication system to which the SIP proxy is applied has an advantage that each client does not need to perform a new authentication process every time the connection destination server is changed.
然るに、SIPのフレームワークにおいては、セッション管理サーバ(SIPプロキシ)は、AOR(Address-of-Record)と呼ばれる「ユーザ名@ドメイン名」 形式をもつ識別子(SIP−URI)によって、受信SIPメッセージの転送先を決定している。従って、上述したSIPプロキシのようなセッション管理サーバ経由のセッション設定を前提としたネットワークシステムでは、クライアント上で実行されるアプリケーションは、接続先サーバを指定するための識別子として、サーバの所属ドメインを特定可能なSIP−URI(Uniform Resource Identifier)を使用する必要がある。 However, in the SIP framework, the session management server (SIP proxy) uses the identifier (SIP-URI) having the “user name @ domain name” format called AOR (Address-of-Record) to identify the received SIP message. The forwarding destination has been determined. Therefore, in a network system that assumes session setting via a session management server such as the SIP proxy described above, the application executed on the client specifies the domain to which the server belongs as an identifier for specifying the connection destination server. It is necessary to use possible SIP-URI (Uniform Resource Identifier).
更に詳述すると、SIPのフレームワークにおいては、クライアント側では、スタートラインに含まれるRequest−URIとして、接続先サーバを指定するAOR形式のSIP−URIを記述した接続要求SIPメッセージを生成し、該SIPメッセージをペイロードに含むIPパケットをクライアントの所属ドメインに位置するSIPプロキシ宛に送信する。上記IPパケットを受信したSIPプロキシは、Request−URIとして記述されたAORが示すドメイン名に基づいて、例えば、DNS(Domain Name System)のNAPTR Record検索とSRV Record検索を行うことにより、受信メッセージの転送先サーバが所属する他のドメインに位置したSIPプロキシ(転送先SIPプロキシ)のIPアドレスあるいはFQDN(Full Qualified Domain Name)を特定する。SRV Record検索の結果がFQDNを示した場合は、DNSのA Record検索を実行することによって、転送先SIPプロキシのIPアドレスを取得できる。尚、ドメイン名から転送先SIPプロキシのIPアドレスを取得する手順については、RFC3263(非特許文献6)に記述されている。 More specifically, in the SIP framework, the client side generates a connection request SIP message in which an AOR-format SIP-URI that specifies a connection destination server is described as a Request-URI included in the start line. An IP packet including the SIP message in the payload is transmitted to the SIP proxy located in the domain to which the client belongs. The SIP proxy that received the IP packet performs, for example, DNS (Domain Name System) NAPTR Record search and SRV Record search based on the domain name indicated by the AOR described as Request-URI. The IP address or FQDN (Full Qualified Domain Name) of a SIP proxy (transfer destination SIP proxy) located in another domain to which the transfer destination server belongs is specified. When the SRV Record search result indicates FQDN, the IP address of the transfer destination SIP proxy can be acquired by executing the DNS A Record search. The procedure for acquiring the IP address of the transfer destination SIP proxy from the domain name is described in RFC 3263 (Non-patent Document 6).
ここで、接続先サーバの所属ドメインが、SIPメッセージを受信したSIPプロキシの所属ドメインと同一であった場合、SIPプロキシは、受信メッセージのRequest−URIに記述されたSIP−URIを検索キーとして、ロケーションサービスDB(データベース)から接続先サーバのIPアドレス(またはFQDN)を取得し、このIPアドレスをIPパケットの宛先アドレスとして、SIPメッセージを接続先サーバに転送する。接続先サーバの所属ドメインがSIPプロキシ(または送信元クライアント)の所属ドメインと異なった場合は、SIPメッセージは、接続先サーバの所属ドメインに位置した別のSIPプロキシに転送され、転送先のSIPプロキシが、ロケーションサービスDBから接続先サーバのIPアドレスまたはFQDNを取得して、SIPメッセージを接続先サーバに転送する。 Here, when the domain to which the connection destination server belongs is the same as the domain to which the SIP proxy that received the SIP message belongs, the SIP proxy uses the SIP-URI described in the Request-URI of the received message as a search key. The IP address (or FQDN) of the connection destination server is acquired from the location service DB (database), and the SIP message is transferred to the connection destination server using this IP address as the destination address of the IP packet. If the domain to which the connection destination server belongs is different from the domain to which the SIP proxy (or source client) belongs, the SIP message is forwarded to another SIP proxy located in the domain to which the connection destination server belongs, and the SIP proxy of the transfer destination Acquires the IP address or FQDN of the connection destination server from the location service DB, and transfers the SIP message to the connection destination server.
上述したように、セッション管理サーバ(SIPプロキシ)経由のセッション設定を前提とするネットワークでは、セッション管理サーバが、受信したSIPメッセージに含まれる要求リソース識別子(SIP−URL)から、接続先サーバが所属するドメインを判定し、受信メッセージを接続先サーバあるいは接続先セッション管理サーバに転送するようになっている。しかしながら、IP網に接続されるクライアント端末上で実行される一般のアプリケーションプログラムは、接続先サーバの指定に、上述したAOR形式のSIP−URIのようにドメイン名を含む識別子ではなく、IPアドレスのように接続先サーバのみを示す識別子を使用している。 As described above, in a network premised on session setting via a session management server (SIP proxy), the session management server belongs to the connection destination server from the request resource identifier (SIP-URL) included in the received SIP message. The received domain is transferred to the connection destination server or connection destination session management server. However, a general application program executed on a client terminal connected to an IP network is not an identifier including a domain name, as in the above-described AOR-format SIP-URI, for specifying a connection destination server. Thus, an identifier indicating only the connection destination server is used.
アプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをIPアドレスで指定してサーバとの接続要求を発行し、クライアントが、接続先サーバをIPアドレスで指定した形で接続要求SIPメッセージを送信した場合、セッション管理サーバ(SIPプロキシ)は、受信した接続要求メッセージの転送先ドメインを特定することができない。この場合、クライアントが図3に示した認証システムの利点を享受できないという問題がある。 When the application program or encrypted communication software issues a connection request with the server specifying the connection destination server with the IP address, and the client sends a connection request SIP message with the connection destination server specified with the IP address The session management server (SIP proxy) cannot specify the transfer destination domain of the received connection request message. In this case, there is a problem that the client cannot enjoy the advantages of the authentication system shown in FIG.
本発明の目的は、接続先サーバをIPアドレスで指定したセッション制御メッセージをセッション管理サーバ経由で接続先サーバに転送可能にしたデータ通信方法およびシステムを提供することにある。
本発明の他の目的は、クライアントが発生する接続先サーバをIPアドレスで指定した接続要求をセッション管理サーバ経由で接続先サーバに転送可能にしたデータ通信方法およびシステムを提供することにある。
本発明の更に他の目的は、クライアントとサーバとの間の暗号化データ通信を可能にし、且つ、暗号化データ通信に先立って必要となるクライアントとサーバとの間の認証手順を容易にしたデータ通信方法およびシステムを提供することにある。
An object of the present invention is to provide a data communication method and system that can transfer a session control message in which a connection destination server is specified by an IP address to the connection destination server via a session management server.
Another object of the present invention is to provide a data communication method and system in which a connection request in which a connection destination server generated by a client is specified by an IP address can be transferred to the connection destination server via a session management server.
Still another object of the present invention is to enable encrypted data communication between a client and a server and to facilitate an authentication procedure between a client and a server which is necessary prior to the encrypted data communication. It is to provide a communication method and system.
上記目的を達成するため、本発明では、クライアントのアプリケーションプログラムまたは暗号化通信ソフトが、接続先サーバをIPアドレスで指定した形で接続要求を発行した時、クライアントまたはセッション管理サーバで、上記IPアドレスをドメイン識別可能な所望のリソース識別子に自動的に変換することを特徴とする。 In order to achieve the above object, according to the present invention, when the client application program or the encrypted communication software issues a connection request in a form in which the connection destination server is designated by the IP address, the client or session management server uses the IP address. Is automatically converted into a desired resource identifier capable of domain identification.
本発明によるクライアントとサーバとの間のデータ通信方法は、クライアントからセッション管理サーバに、接続先サーバのIPアドレスを指定して、該接続先サーバに割り当てられた所属ドメイン名を含むリソース識別子を問い合わせる第1ステップと、上記セッション管理サーバが、IPアドレスとリソース識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバのIPアドレスと対応するリソース識別子を取得し、上記クライアントに通知する第2ステップと、上記クライアントから上記セッション管理サーバに、要求リソースを上記接続先サーバのリソース識別子で指定した接続要求メッセージを送信する第3ステップと、上記セッション管理サーバが、受信した接続要求メッセージに記述された上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第4ステップとからなることを特徴とする。 In the data communication method between the client and the server according to the present invention, the client specifies the IP address of the connection destination server to the session management server, and inquires the resource identifier including the domain name assigned to the connection destination server. The first step and the session management server obtains the resource identifier corresponding to the IP address of the connection destination server from the location table managing the correspondence between the IP address and the resource identifier, and notifies the client of the resource identifier. A second step, a third step of transmitting a connection request message in which the request resource is specified by a resource identifier of the connection destination server from the client to the session management server, and the session management server receiving the connection request message The above described litho A fourth step of determining a transfer destination of the received message based on the domain name included in the service identifier and transferring the received message to the connection destination server or another session management server that manages the domain to which the connection destination server belongs. It is characterized by that.
本発明によるデータ通信方法の別の実施例は、クライアントからセッション管理サーバに、要求リソースを接続先サーバのIPアドレスで指定した接続要求メッセージを送信する第1ステップと、上記接続要求メッセージを受信したセッション管理サーバが、IPアドレスとリソース識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバのIPアドレスと対応するリソース識別子を取得する第2ステップと、上記セッション管理サーバが、受信メッセージに要求リソースとして記述されたIPアドレスを上記ロケーションテーブルから取得したリソース識別子に書き換える第3ステップと、上記セッション管理サーバが、上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第4ステップとからなることを特徴とする。 According to another embodiment of the data communication method of the present invention, a first step of transmitting a connection request message in which a request resource is designated by an IP address of a connection destination server from a client to the session management server, and the connection request message is received. A second step in which the session management server acquires a resource identifier corresponding to the IP address of the connection destination server from a location table in which the correspondence relationship between the IP address and the resource identifier is managed; A third step of rewriting the IP address described as the request resource in the message with the resource identifier acquired from the location table; and the session management server determines the forwarding destination of the received message based on the domain name included in the resource identifier And receive Characterized in that comprising the fourth step of transferring the message to another session management server that manages the destination server or belonging domain of the destination server.
本発明によるデータ通信方法の更に他の実施例は、クライアントから接続先となるサーバに、該サーバに割り当てられた所属ドメイン名を含むリソース識別子を問い合わせる第1ステップと、上記サーバから上記クライアントに、問い合わせリソース識別子を通知する第2ステップと、上記クライアントからセッション管理サーバに、要求リソースを上記接続先サーバのリソース識別子で指定した接続要求メッセージを送信する第3ステップと、上記セッション管理サーバが、受信した接続要求メッセージに記述された上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送する第4ステップとからなることを特徴とする。 According to still another embodiment of the data communication method of the present invention, a first step of inquiring a resource identifier including a domain name assigned to a server to a connection destination server from the client, the server to the client, A second step of notifying the inquiry resource identifier, a third step of transmitting a connection request message in which the request resource is specified by the resource identifier of the connection destination server from the client to the session management server, and the session management server receiving Another session management server that determines the transfer destination of the received message based on the domain name included in the resource identifier described in the connection request message, and manages the received message on the connection destination server or the domain to which the connection destination server belongs The fourth step to transfer to And wherein the Ranaru.
更に詳述すると、本発明のデータ通信方法は、接続要求メッセージの受信に応答して、接続先サーバからセッション管理サーバを介して要求元クライアントに、暗号化通信に必要となるパラメータ情報を含む接続応答メッセージを返送する第5ステップと、上記クライアントと接続先サーバとの間で、上記接続応答メッセージで指定されたパラメータ情報に従って暗号化されたメッセージを含むパケットを通信する第6ステップを含む。 More specifically, in the data communication method of the present invention, in response to reception of a connection request message, a connection including parameter information necessary for encrypted communication from the connection destination server to the request source client via the session management server. A fifth step of returning a response message and a sixth step of communicating a packet including a message encrypted according to the parameter information specified in the connection response message between the client and the connection destination server.
上記セッション管理サーバは、例えば、SIP(Session Initiation Protocol)サーバからなる。この場合、クライアントとセッション管理サーバとの間の通信メッセージは、例えば、RFC3261に規定されたTLS(Transport Layer Security)によって暗号化され、クライアントと接続先サーバとの間の通信データは、例えば、RFC2401に規定されたIPsec(Internet Protocol Security)によって暗号化される。 The session management server includes, for example, a SIP (Session Initiation Protocol) server. In this case, the communication message between the client and the session management server is encrypted by, for example, TLS (Transport Layer Security) defined in RFC3261, and the communication data between the client and the connection destination server is, for example, RFC2401. Encrypted by IPsec (Internet Protocol Security).
本発明によって提供されるセッション管理サーバは、クライアントから、要求リソースを接続先サーバのIPアドレスで指定した接続要求メッセージを受信した時、IPアドレスとリソース識別子との対応関係を管理しているロケーションテーブルから、上記接続先サーバのIPアドレスと対応するリソース識別子を取得し、受信メッセージに記述された要求リソースをIPアドレスから上記リソース識別子に書き換えるための手段と、上記リソース識別子に含まれるドメイン名に基づいて受信メッセージの転送先を判定し、受信メッセージを接続先サーバまたは該接続先サーバの所属ドメインを管理する別のセッション管理サーバに転送するための手段とを備えたことを特徴とする。 The session management server provided by the present invention manages a correspondence relationship between an IP address and a resource identifier when a connection request message in which a requested resource is specified by an IP address of a connection destination server is received from a client. Based on the domain name included in the resource identifier and means for acquiring the resource identifier corresponding to the IP address of the connection destination server from the IP address and rewriting the requested resource described in the received message from the IP address to the resource identifier And a means for determining a transfer destination of the received message and transferring the received message to the connection destination server or another session management server that manages the domain to which the connection destination server belongs.
上記セッション管理サーバは、具体的には、通信ネットワークに接続されたネットワークインタフェース部と、セッション制御メッセージを処理するメッセージ処理部と、上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するためのセキュリティ部とを有し、上記メッセージ処理部が、上述した要求リソースの書き換え手段と受信メッセージの転送手段を備える。 Specifically, the session management server includes a network interface unit connected to a communication network, a message processing unit that processes a session control message, and a message processing unit that decrypts an encrypted message received from the network interface unit. A security unit for encrypting the session control message output from the message processing unit and outputting it to the network interface unit, wherein the message processing unit includes the request resource rewriting means described above. A receiving message transfer means is provided.
本発明によって提供されるクライアント端末は、通信ネットワークに接続されたネットワークインタフェース部と、セッション制御メッセージを処理するメッセージ処理部と、アプリケーションプログラムが発生する接続先サーバ宛の送信メッセージを暗号化して上記ネットワークインタフェース部に出力すると共に、上記ネットワークインタフェース部から受信した暗号化メッセージを復号化して上記アプリケーションプログラムに渡すための第1セキュリティ部と、上記セキュリティ部から、接続先サーバとの暗号化パラメータの交換要求が発生した時、接続先サーバをIPアドレスで指定した接続要求メッセージを上記メッセージ処理部に出力し、上記メッセージ処理部から接続応答メッセージを受信した時、該受信メッセージから抽出した暗号化パラメータを上記第1セキュリティ部に渡すセキュリティ情報制御部とからなり、
上記メッセージ処理部が、上記セキュリティ情報制御部から接続要求メッセージを受信した時、上記IPアドレスに基づいて上記セッション管理サーバまたは接続先サーバから接続先サーバのリソース識別子を取得し、該リソース識別子で要求リソースを指定した形で、上記接続要求メッセージを上記セッション管理サーバに送信することを特徴とする。
A client terminal provided by the present invention includes a network interface unit connected to a communication network, a message processing unit that processes a session control message, and a transmission message addressed to a connection destination server generated by an application program to encrypt the network. A request for exchanging encryption parameters with the connection destination server from the first security unit for outputting to the interface unit and decrypting the encrypted message received from the network interface unit and passing it to the application program When a connection request message is output to the message processing unit and a connection response message is received from the message processing unit, it is extracted from the received message. Becomes the encryption parameters from the security information control unit to pass to the first security unit above,
When the message processing unit receives a connection request message from the security information control unit, obtains the resource identifier of the connection destination server from the session management server or the connection destination server based on the IP address, and requests with the resource identifier The connection request message is transmitted to the session management server in a form in which resources are specified.
実際の応用では、本発明のクライアント端末は、上記ネットワークインタフェース部から受信した暗号化されたセッション制御メッセージを復号化して上記メッセージ処理部に渡すと共に、上記メッセージ処理部から出力されたセッション制御メッセージを暗号化して上記ネットワークインタフェース部に出力するための第2セキュリティ部を有し、
接続先サーバとの通信データが上記第1セキュリティ部によって暗号化され、セッション管理サーバと通信メッセージが上記第2セキュリティ部によって暗号化される。
In actual application, the client terminal of the present invention decrypts the encrypted session control message received from the network interface unit and passes the decrypted session control message to the message processing unit, and also receives the session control message output from the message processing unit. A second security unit for encrypting and outputting to the network interface unit;
Communication data with the connection destination server is encrypted by the first security unit, and the session management server and communication message are encrypted by the second security unit.
本発明によれば、クライアントのアプリケーションプログラムまたは暗号化通信ソフトから、要求リソース(接続先サーバ)をIPアドレスで指定した形で接続要求が発行された場合でも、接続要求メッセージの要求リソースをIPアドレスからドメイン識別可能なリソース識別子に自動的に変換できる。従って、接続要求メッセージを転送制御するセッション管理サーバにおいて、受信メッセージのリソース識別子から転送先ドメインを判定し、受信メッセージを接続先サーバ、または接続先サーバの所属ドメインに位置した別のセッション管理サーバに転送することが可能となる。
本発明によれば、一般のアプリケーションプログラムを実行するクライアントでも、セッション管理サーバによる認証機能を利用することによって、接続先サーバとの間で容易に暗号化通信を実現できる。
According to the present invention, even when a connection request is issued from a client application program or encrypted communication software with a request resource (connection destination server) specified by an IP address, the request resource of the connection request message is set to the IP address. Can be automatically converted to a domain-identifiable resource identifier. Therefore, in the session management server that controls transfer of connection request messages, the transfer destination domain is determined from the resource identifier of the received message, and the received message is sent to the connection destination server or another session management server located in the domain to which the connection destination server belongs. It becomes possible to transfer.
According to the present invention, even a client executing a general application program can easily realize encrypted communication with a connection destination server by using an authentication function by a session management server.
以下、本発明の実施例について図面を参照して説明する。
図4は、本発明が適用されるネットワーク構成の1例を示す。
ここに示したネットワークは、SIPサーバSIPaが管理する第1ドメインを形成する第1のネットワークNW1と、SIPサーバSIPbが管理する第2ドメインを形成する第2のネットワークNW2と、ロケーションサーバLSVと、DNS(Domain Name System)とからなる。
Embodiments of the present invention will be described below with reference to the drawings.
FIG. 4 shows an example of a network configuration to which the present invention is applied.
The network shown here includes a first network NW1 forming a first domain managed by the SIP server SIPa, a second network NW2 forming a second domain managed by the SIP server SIPb, a location server LSV, It consists of DNS (Domain Name System).
第1のネットワークNW1には、クライアントCL1a、CL2aと、サーバSV1a、SV2aが接続され、第2のネットワークNW2には、クライアントCL1b、CL2bと、サーバSV1b、SV2bが接続されている。また、SIPサーバSIPaは、SIPプロキシPRaとレジストラPGaとからなり、SIPサーバSIPbは、SIPプロキシPRbレジストラPGbとからなっている。 Clients CL1a and CL2a and servers SV1a and SV2a are connected to the first network NW1, and clients CL1b and CL2b and servers SV1b and SV2b are connected to the second network NW2. The SIP server SIPa is composed of a SIP proxy PRa and a registrar PGa, and the SIP server SIPb is composed of a SIP proxy PRb registrar PGb.
ここで、各クライアントおよびサーバに付随して括弧内に示した文字列は、SIPメッセージの転送先識別子(リソース識別子)となるAOR(Address-of-Record)形式のSIP−URIの値を示している。第1ネットワークNW1に接続されたクライアントとサーバには、SIPサーバSIPaのドメイン識別子「aaa.com」を含むAORが割り当てられ、第2ネットワークNW2に接続されたクライアントとサーバには、SIPサーバSIPbのドメイン識別子「bbb.com」を含むAORが割り当てられている。 Here, the character strings shown in parentheses accompanying each client and server indicate the value of SIP-URI in the AOR (Address-of-Record) format that becomes the transfer destination identifier (resource identifier) of the SIP message. Yes. AOR including the domain identifier “aaa.com” of the SIP server SIPa is assigned to the client and server connected to the first network NW1, and the client and server connected to the second network NW2 are assigned to the SIP server SIPb. An AOR including the domain identifier “bbb.com” is assigned.
本発明のSIPサーバSIPa、SIPbは、それぞれの管轄下にあるクライアントから、接続先サーバをIPアドレスで指定したSIPメッセージを受信した時、ロケーションサーバLSVに、上記接続先IPアドレスと対応するAOR(リソース識別子)の検索(ロケーションデータ検索)を要求する。また、SIPサーバSIPa、SIPbは、それぞれ他のSIPサーバから、接続先サーバをAORで指定したSIPメッセージを受信した時、ロケーションサーバLSVに、上記接続先AORと対応するIPアドレスの検索を要求する。 When the SIP servers SIPa and SIPb of the present invention receive a SIP message designating a connection destination server by an IP address from a client under their jurisdiction, the SIP servers SIPa and SIPb send to the location server LSV an AOR (corresponding to the connection destination IP address). (Resource identifier) search (location data search) is requested. Further, when the SIP servers SIPa and SIPb each receive a SIP message specifying the connection destination server by AOR from another SIP server, the SIP servers SIPa and SIPb request the location server LSV to search for an IP address corresponding to the connection destination AOR. .
ロケーションサーバLSVは、ロケーションサービス・データベース(DB)に、例えば、図5に示すように、SIPサーバSIPa、SIPbの管轄下にあるクライアントおよびサーバと対応した複数のエントリEN−1、EN−2,・・・からなり、各エントリが、クライアントまたはサーバのAOR61とIPアドレス62との対応関係を示すロケーションサービステーブル60を備えている。ロケーションサーバLSVは、SIPサーバからのロケーションデータ検索要求に応答して、上記ロケーションサービステーブル60から、検索キーとして指定されたIPアドレス(またはAOR)と対応するAOR(またはIPアドレス)を検索し、検索結果を要求元SIPサーバに返送する。
The location server LSV stores, in the location service database (DB), for example, a plurality of entries EN-1, EN-2, corresponding to clients and servers under the jurisdiction of the SIP servers SIPa and SIPb, as shown in FIG. .., And each entry has a location service table 60 indicating the correspondence between the
図6は、SIPプロキシPRaのハードウェア構成を示す。
SIPプロキシPRaは、プロセッサ(CPU)11と、プロセッサが実行する各種ソフトウェアとデータを記憶するためのメモリ12およびハードディスク13と、ネットワークNW1(NW2)に接続するためのネットワークインタフェース14と、入出力装置15とからなり、これらの要素は内部バス16によって相互接続されている。SIPプロキシPRb、レジストラRGa、RGb、クライアントCL1a〜CL2b、サーバSV1a〜SV2bも、基本的には、図6に示したSIPプロキシPRaと同様の構成要素からなる。
FIG. 6 shows a hardware configuration of the SIP proxy PRa.
The SIP proxy PRa includes a processor (CPU) 11, a
以下、図4に示した第1ドメインに所属するクライアントCL1aが、第2ドメインに所属するサーバSV1bと暗号化データ通信する場合の通信手順を例にして、本発明の第1の実施例について説明する。
図7は、クライアントCL1aの基本的なソフトウェア構造を示す。他のクライアントCL1b〜CL2bも、これと同様のソフトウェア構造となっている。
In the following, the first embodiment of the present invention will be described by taking as an example a communication procedure when the client CL1a belonging to the first domain shown in FIG. 4 performs encrypted data communication with the server SV1b belonging to the second domain. To do.
FIG. 7 shows a basic software structure of the client CL1a. The other clients CL1b to CL2b have the same software structure.
クライアントCL1aのソフトウェアは、ネットワークインタフェースカード部(NIC)20Cと、IPsec暗号化/復号化機能を備えたIPsecエンジン31Cを含むTCP/IPレイヤ部30Cと、アプリケーションプログラム40Cと、鍵管理プロセス部50Cとからなる。第1実施例では、鍵管理プロセス部50Cが、SP/SA(Security Policy/ Security Association)制御部51Cと、TLS(Transport Layer Security)部52Cと、SIPメッセージ処理部53Cとを備えたことを特徴としている。
The software of the client CL1a includes a network interface card unit (NIC) 20C, a TCP /
図8は、サーバSV1bの基本的なソフトウェア構造を示す。他のサーバSV1a、SV2a、SV2bも、これと同様のソフトウェア構造となっている。
サーバSV1bのソフトウェアは、ネットワークインタフェースカード部(NIC)20Sと、IPsec暗号化/復号化機能を備えたIPsecエンジン31Sを含むTCP/IPレイヤ部30Sと、アプリケーションプログラム40Sと、鍵管理プロセス部50Sとからなり、鍵管理プロセス部50Sが、SP/SA制御部51Sと、TLS部52Sと、SIPメッセージ処理部53Sとを備えている。
FIG. 8 shows a basic software structure of the server SV1b. The other servers SV1a, SV2a, SV2b have the same software structure.
The software of the server SV1b includes a network interface card unit (NIC) 20S, a TCP /
クライアントCL1aのアプリケーションプログラム40CとサーバSV1bのアプリケーションプログラム40Sは、それぞれが備えるIPsecエンジン31C、31SのIPsec暗号化/復号化機能を利用して、暗号化データを通信する。一方、クライアントCL1aのSIPメッセージ処理部53Cは、後述するSIPサーバSIPa(SIPプロキシPRa、レジストラRGa)のSIPメッセージ処理部との間で、それぞれが備えるTLS部のメッセージ暗号化/復号化機能を利用して、暗号化されたSIPメッセージを通信する。同様に、サーバSV1bのSIPメッセージ処理部53Sも、SIPサーバSIPa(SIPプロキシPRa、レジストラRGa)のSIPメッセージ処理部との間で、それぞれが備えるTLS部のメッセージ暗号化/復号化機能を利用して、暗号化されたSIPメッセージを通信する。
The
図9は、SIPプロキシPRaの基本的なソフトウェア構造を示す。SIPプロキシPRbも、これと同様のソフトウェア構造となっている。
SIPプロキシPRaのソフトウェアは、ネットワークインタフェースカード部(NIC)20Pと、TCP/IPレイヤ部30Pと、鍵管理プロセス部50Pとからなり、鍵管理プロセス部50Pが、TLS部52Pと、SIPメッセージ処理部53Pとを備えている。SIPメッセージ処理部53Pは、後述するSIP−URL(AOR)検索機能54を備えている。SIPプロキシPRaのSIPメッセージ処理部53Pは、TLS部52Pのメッセージ暗号化/復号化機能を利用して、管理下にあるドメインに所属したクライアント、サーバ、および他のドメインを管理する他のSIPプロキシ、例えばPRbと暗号化メッセージを通信する。
FIG. 9 shows a basic software structure of the SIP proxy PRa. The SIP proxy PRb has a similar software structure.
The software of the SIP proxy PRa includes a network interface card unit (NIC) 20P, a TCP /
図10は、レジストラRGaの基本的なソフトウェア構造を示す。レジストラRGbも、これと同様のソフトウェア構造となっている。
レジストラRGaのソフトウェアは、ネットワークインタフェースカード部(NIC)20Rと、TCP/IPレイヤ部30Rと、メッセージの暗号化/復号化機能を備えたTLS部52Rと、SIPメッセージ処理部53Rと、レジストラ処理部60Rとからなっている。SIPメッセージ処理部53Rは、クライアントが発行したAOR取得要求、またはSIPプロキシPRaが発行したAOR取得要求を受信すると、レジストラ処理部60Rにロケーションデータの検索を要求する。レジストラ処理部60Rは、SIPメッセージ処理部53Rからの要求に応答して、ロケーションサーバLSVが備えるロケーションサービスDBをアクセスする。尚、レジストラRGaとSIPプロキシPRaとの間の通信には、暗号化は適用されない。
FIG. 10 shows the basic software structure of the registrar RGa. The registrar RGb has a similar software structure.
The registrar RGa software includes a network interface card unit (NIC) 20R, a TCP /
図11と図12は、本発明による暗号化データ通信の第1の実施例を示すシーケンス図を示している。第1の実施例では、クライアントCL1aがAOR取得要求を発行する。
本実施例において、クライアントCL1aからの接続要求先となる第2ネットワークに接続されたサーバSV1bは、クライアントCL1aからの接続要求に先立って、SIPサーバSIPbのレジストラRGbとの間で、サーバSV1bの認証と暗号化通信用のパラメータ設定のためのTLSネゴシェーション(S1)を実行した後、レジストラRGbにロケーション登録要求メッセージ(SIPメッセージ:REGISTER)M1を送信する。
11 and 12 are sequence diagrams showing a first embodiment of encrypted data communication according to the present invention. In the first embodiment, the client CL1a issues an AOR acquisition request.
In this embodiment, the server SV1b connected to the second network, which is the connection request destination from the client CL1a, authenticates the server SV1b with the registrar RGb of the SIP server SIPb prior to the connection request from the client CL1a. After executing TLS negotiation (S1) for setting parameters for encrypted communication, a location registration request message (SIP message: REGISTER) M1 is transmitted to the registrar RGb.
ロケーション登録要求メッセージM1は、例えば、図13に示すように、IPヘッダH1と、UDP/TCPヘッダH2とを付したIPパケット形式で送信される。IPヘッダH1は、宛先アドレスとしてレジストラRGb(SIPサーバSIPa)のIPアドレス、送信元アドレスとしてサーバSV1bのIPアドレスを含む。 For example, as shown in FIG. 13, the location registration request message M1 is transmitted in an IP packet format with an IP header H1 and a UDP / TCP header H2. The IP header H1 includes the IP address of the registrar RGb (SIP server SIPa) as the destination address and the IP address of the server SV1b as the source address.
SIPメッセージは、SIPメッセージの種類(Request-Method)を示すスタートラインと、要求または応答内容を記述したヘッダ部と、必要に応じてセッション内容を記述したメッセージボディ部とからなる。メッセージの種類によっては、上記スタートラインに、該メッセージの宛先を示すリソース識別子(Request-URI)が記述される。また、メッセージボディ部におけるセッション内容の記述には、RFC3266で仕様化されたSDP(Session Description Protocol)が適用される。 The SIP message includes a start line indicating the type (Request-Method) of the SIP message, a header portion describing the request or response content, and a message body portion describing the session content as necessary. Depending on the type of message, a resource identifier (Request-URI) indicating the destination of the message is described in the start line. In addition, SDP (Session Description Protocol) specified in RFC3266 is applied to the description of session contents in the message body part.
サーバSV2bが発行するロケーション登録要求メッセージM1の場合、スタートラインには、SIPメッセージの種類として「REGISTER」、メッセージ宛先を示すリソース識別子として、レジストラRGbのSIP−URIである「registrar.bbb.com」が含まれる。また、スタートラインに続くヘッダ部には、SIPメッセージの経路を示すViaヘッダ、メッセージの宛先を示すToヘッダ、メッセージの送信元を示すFromヘッダ、送信元で指定したセッション識別子を示すCall−IDヘッダ、要求メソッドを示すCSecヘッダ、ロケーションサービステーブルに登録すべきサーバSV1bのIPアドレス「sv1@192.0.2.4」を含むContactヘッダ、メッセージの有効時間を示すExpiresヘッダ、後続するメッセージボディ部の長さを示すContent−Lengthヘッダ、その他のヘッダ情報が含まれる。ロケーション登録要求メッセージM1の場合、メッセージボディ部は省略されるため、Content−Lengthヘッダには値「0」が設定され、ToヘッダとFromヘッダには、要求元サーバSV1bのURIの値「sv1@bbb.com」が設定されている。 In the case of the location registration request message M1 issued by the server SV2b, the start line includes “REGISTER” as the SIP message type, and “registrar.bbb.com” which is the SIP-URI of the registrar RGb as the resource identifier indicating the message destination. Is included. The header part following the start line includes a Via header indicating the route of the SIP message, a To header indicating the destination of the message, a From header indicating the source of the message, and a Call-ID header indicating a session identifier specified by the source. , The CSec header indicating the request method, the Contact header including the IP address “[email protected]” of the server SV1b to be registered in the location service table, the Expires header indicating the valid time of the message, and the length of the subsequent message body part A Content-Length header to be shown and other header information are included. In the case of the location registration request message M1, since the message body part is omitted, the value “0” is set in the Content-Length header, and the URI value “sv1 @ of the request source server SV1b is set in the To header and From header. bbb.com "is set.
レジストラRGbは、上記ロケーション登録要求メッセージM1を受信すると、ロケーションサービスDBのロケーションサービステーブル60に、受信メッセージのFromヘッダが示す要求元URI「sv1@bbb.com」とContactヘッダが示す要求元IPアドレス「sv1@192.0.2.4」との関係を示すロケーションデータを登録し(S2)、ロケーションデータの登録が完了すると(S3)、要求元サーバSV2bに、図14に示すロケーション登録応答メッセージM2を送信する。ロケーション登録応答メッセージM2のスタートラインは、SIPメッセージの種類として、応答メッセージであることを示す「200 OK」を含み、ヘッダ部には、ロケーション登録要求メッセージM1と略同一内容のヘッダ情報が設定される。 When the registrar RGb receives the location registration request message M1, the request source IP address indicated by the request source URI “[email protected]” indicated by the From header of the received message and the Contact header is stored in the location service table 60 of the location service DB. Location data indicating the relationship with “[email protected]” is registered (S2). When the location data registration is completed (S3), a location registration response message M2 shown in FIG. 14 is transmitted to the requesting server SV2b. . The start line of the location registration response message M2 includes “200 OK” indicating that it is a response message as the type of SIP message, and header information having substantially the same contents as the location registration request message M1 is set in the header portion. The
この状態で、クライアントCL1aのユーザが、アプリケーションプログラムを立ち上げ、サーバSV1bのIPアドレス宛にパケットを送信する操作を行った場合、本発明の第1の実施例では、クライアントCL1aが、SIPサーバSIPa(レジストラRGa)との間で、クライアントの認証と暗号化通信用のパラメータ設定のためのTLSネゴシェーション(S4)を実行した後、SIPサーバSIPa(レジストラRGa)にAOR(Address-of-Record)取得要求メッセージ(SIPメッセージ:GET AOR)M3を送信する。 In this state, when the user of the client CL1a starts up an application program and performs an operation of transmitting a packet addressed to the IP address of the server SV1b, in the first embodiment of the present invention, the client CL1a is connected to the SIP server SIPa. After executing TLS negotiation (S4) for client authentication and parameter setting for encrypted communication with (registrar RGa), the SIP server SIPa (registrar RGa) receives an AOR (Address-of-Record). ) Send an acquisition request message (SIP message: GET AOR) M3.
上記AOR取得要求メッセージM3は、例えば、図15に示すように、スタートラインに、SIPメッセージ種類を示す「GET AOR」と、レジストラRGaのURIである「registrar.aaa.com」を含み、Viaヘッダは、クライアントCL1aのSA/SP処理部51Cの識別子となるURIの値を示している。また、Toヘッダには、クライアントCL1aの接続相手となるサーバSV1bのIPアドレス「192.0.2.4」が設定され、Fromヘッダには、クライアントCL1aのURI「cl1@aaa.com」が設定されている。 For example, as shown in FIG. 15, the AOR acquisition request message M3 includes “GET AOR” indicating the SIP message type and “registrar.aaa.com” which is the URI of the registrar RGa in the start line, and a Via header. Indicates a URI value serving as an identifier of the SA / SP processing unit 51C of the client CL1a. The To header is set with the IP address “192.0.2.4” of the server SV1b that is the connection partner of the client CL1a, and the URI “[email protected]” of the client CL1a is set in the From header.
レジストラRGaは、AOR取得要求メッセージM3を受信すると、ロケーションサービスDBのロケーションサービステーブル60から、受信メッセージのToヘッダが示すIPアドレス「192.0.2.4」と対応するAOR(サーバSV1bのURI)の値を検索し(S5)、ロケーションデータAORの検索が完了すると(S6)、要求元クライアントCL1aにAOR取得応答メッセージM4を送信する。 When the registrar RGa receives the AOR acquisition request message M3, the registrar RGa obtains the value of the AOR (URI of the server SV1b) corresponding to the IP address “192.0.2.4” indicated by the To header of the received message from the location service table 60 of the location service DB. When the search is performed (S5) and the search for the location data AOR is completed (S6), an AOR acquisition response message M4 is transmitted to the requesting client CL1a.
AOR取得応答メッセージM4は、図16に示すように、スタートラインに、メッセージ種類が応答メッセージであることを示す「200 OK」を含み、ヘッダ部には、AOR取得要求メッセージM3と略同一内容のヘッダ情報と、ロケーションサービステーブル60から検索されたサーバSV1bのURIの値「sv1@bbb.com」を示すAORヘッダが記述されている。 As shown in FIG. 16, the AOR acquisition response message M4 includes “200 OK” indicating that the message type is a response message in the start line, and the header portion has substantially the same content as the AOR acquisition request message M3. The header information and the AOR header indicating the URI value “[email protected]” of the server SV1b retrieved from the location service table 60 are described.
上記AOR取得応答メッセージM4の受信によって接続先サーバSV1bのURLを取得したクライアントCL1aは、SIPサーバSIPaのSIPプロキシPRaとの間で、クライアントの認証と暗号化通信用のパラメータ設定のためのTLSネゴシェーション(S7)を実行した後、SIPプロキシPRaに対して、サーバSV1bへの接続要求メッセージM5を送信する。 The client CL1a that has acquired the URL of the connection destination server SV1b by receiving the AOR acquisition response message M4 makes a TLS negotiation for setting the parameters for client authentication and encryption communication with the SIP proxy PRa of the SIP server SIPa. After executing the shading (S7), a connection request message M5 to the server SV1b is transmitted to the SIP proxy PRa.
接続要求メッセージM5は、図17に示すように、接続要求メッセージのヘッダ部M5−1とボディ部M5−2とからなり、接続要求メッセージのヘッダ部M5−1は、スタートラインに、メッセージ種類「REGISTER」と、Request−URIとして、メッセージ宛先となるサーバSV1bのSIP−URI「sv1@bbb.com」を含む。また、ヘッダ情報として、クライアントCL1aにおけるSIPメッセージ処理部53CのSIP−URIを示すViaヘッダ、サーバSV1bのSIP−URI「sv1@bbb.com」を含むToヘッダ、クライアントCL1aのSIP−URI「cl1@aaa.com」を含むFromヘッダと、Content−Typeヘッダ、Content−Lengthヘッダ、その他の情報を含む。Content−Typeヘッダは、ボディ部M5−2が関係するアプリケーションプログラムを示し、Content−Lengthヘッダは、ボディ部M5−2の長さを示している。
As shown in FIG. 17, the connection request message M5 includes a header part M5-1 and a body part M5-2 of the connection request message. The header part M5-1 of the connection request message has a message type “ “REGISTER” and the request-URI include the SIP-URI “[email protected]” of the server SV1b as the message destination. Further, as header information, a Via header indicating the SIP-URI of the SIP
接続要求メッセージM5のボディ部M5−2は、例えば、図18に示すように、クライアントCL1aとサーバSV1bとの間での暗号化通信に適用するSA情報として、IKEにおける通常のIPsec用SA設定時と同様、暗号化プロトコルの識別情報を示すプロポーザルペイロード91と、トランスフォーム識別情報を示すトランスフォームペイロード92、鍵交換ペイロード93、要求元の識別情報を示す第1IDペイロード94と、接続先の識別情報を示す第2IDペイロード95を含んでいる。
The body part M5-2 of the connection request message M5 is, for example, as shown in FIG. 18, when the normal IPsec SA for IKE is set as SA information applied to encrypted communication between the client CL1a and the server SV1b. In the same manner as above, the
ここでは、クライアントCL1aが、2つのトランスフォームペイロード92−1、92−2で、トランスフォームIDとして「ESP-AES」と「ESP-3DES」を提案しており、そのうちの1つを接続先サーバSV1bが選択して、接続応答メッセージでクライアントに通知することになる。尚、第1IDペイロード94のIDデータは、要求元クライアントCL1aのIPアドレスを示し、第2IDペイロード95のIDデータは、接続先サーバSV1bのIPアドレスを示す。
Here, the client CL1a proposes “ESP-AES” and “ESP-3DES” as transform IDs with two transform payloads 92-1, 92-2, and one of them is a connection destination server. The SV 1b selects and notifies the client with a connection response message. The ID data of the
SIPプロキシPRaは、上記接続要求メッセージM5を受信すると、要求元クライアントCL1aにサーバSV1bと接続中であることを通知するために、図19に示す接続中メッセージM6を送信した後、接続先サーバSV1bが所属するドメインのSIPプロキシPRbとの間で、相互の認証と暗号化通信用のパラメータ設定のためのTLSネゴシェーション(S8)を実行する。接続中メッセージM6は、スタートラインに、メッセージ種類として、要求を実行中であることを示す「100 Trying」を含み、ヘッダ部に、接続要求メッセージM5から抽出されたVia、To、From、Call−ID、CSec等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。 Upon receiving the connection request message M5, the SIP proxy PRa transmits a connection message M6 shown in FIG. 19 to notify the requesting client CL1a that it is connected to the server SV1b, and then connects to the connection destination server SV1b. TLS negotiation (S8) for mutual authentication and parameter setting for encrypted communication is executed with the SIP proxy PRb of the domain to which the server belongs. The connection message M6 includes “100 Trying” indicating that the request is being executed as a message type in the start line, and Via, To, From, Call− extracted from the connection request message M5 in the header portion. It includes several items of header information such as ID and CSec, and the message body portion is omitted.
SIPプロキシPRaは、SIPプロキシPRbとの間のTLSネゴシェーションが終わると、クライアントから受信した接続要求メッセージM5に、自分のSIP−URI「proxy.aaa.com」を含む新たなViaヘッダと、接続要求がURI「proxy.aaa.com」を経由したことを示すRecord−Routeヘッダを追加し、図20に示す接続要求メッセージM7として、SIPプロキシPRbに送信する。 When the TLS negotiation with the SIP proxy PRb is completed, the SIP proxy PRa includes a new Via header including its own SIP-URI “proxy.aaa.com” in the connection request message M5 received from the client, A Record-Route header indicating that the connection request has passed through the URI “proxy.aaa.com” is added and transmitted to the SIP proxy PRb as a connection request message M7 shown in FIG.
SIPプロキシPRbは、上記接続要求メッセージM7を受信すると、受信メッセージのスタートラインから宛先URI「SV1@aaa.com」を抽出し、図12に示すように、ロケーションサーバLSVに対して、ロケーションサービスDBからの上記宛先URIと対応したIPアドレスの検索(ロケーションデータ検索)を要求する(S9)。SIPプロキシPRbは、ロケーションサービスDBの検索結果を示すロケーションデータ(IPアドレス「sv1@192.0.2.4」)を受信すると(S10)と、上記接続要求メッセージM7の要求元SIPプロキシPRaに対して、図21に示す接続中メッセージM8を送信した後、IPアドレス「sv1@192.0.2.4」で特定される接続先サーバSV1bとの間で、相互の認証と暗号化通信用のパラメータ設定のためのTLSネゴシェーション(S11)を実行する。 When the SIP proxy PRb receives the connection request message M7, the SIP proxy PRb extracts the destination URI “[email protected]” from the start line of the received message and, as shown in FIG. 12, the location service DB for the location server LSV. A search (location data search) for an IP address corresponding to the destination URI is requested (S9). When the SIP proxy PRb receives the location data (IP address “[email protected]”) indicating the search result of the location service DB (S10), the SIP proxy PRb sends a diagram to the requesting SIP proxy PRa of the connection request message M7. TLS negotiation for setting parameters for mutual authentication and encrypted communication with the connection destination server SV1b specified by the IP address “[email protected]” after transmitting the message M8 being connected shown in FIG. The shading (S11) is executed.
SIPプロキシPRbは、接続先サーバSV1bとの間のTLSネゴシェーションが終了すると、接続要求メッセージM7のRequest−URIをIPアドレス「sv1@192.0.2.4」に書き換え、自分のSIP−URI「proxy.bbb.com」を含む新たなViaヘッダと、接続要求がURI「proxy.bbb.com」を経由したことを示すRecord−Routeヘッダを追加し、図22に示す接続要求メッセージM9として接続先サーバSV1bに送信する。 When the TLS negotiation with the connection destination server SV1b ends, the SIP proxy PRb rewrites the Request-URI of the connection request message M7 to the IP address “[email protected]”, and the SIP proxy URI “proxy. A new Via header including “bbb.com” and a Record-Route header indicating that the connection request has passed through the URI “proxy.bbb.com” are added, and the connection destination server SV1b is displayed as the connection request message M9 illustrated in FIG. Send to.
接続先サーバSV1bは、上記接続要求メッセージM9に応答して、接続応答メッセージM10を返信する。接続応答メッセージM10は、図23に示すように、ヘッダ部M10−1とボディ部M10−2とからなり、ヘッダ部M10−1のスタートラインには、メッセージ種類として、応答メッセージであることを示す「200 OK」を含み、スタートラインに続いて、接続要求メッセージM9と同様の複数項目のヘッダ情報を含む。また、ボディ部M10−2は、例えば、図24に示すように、接続要求メッセージM10のボディ部M5−2で提案された2つのトランスフォームペイロード92−1、92−2のうち、サーバSV1bが選択した1つのトランスフォームペイロード(この例では、EPS-AES)を残している。 In response to the connection request message M9, the connection destination server SV1b returns a connection response message M10. As shown in FIG. 23, the connection response message M10 includes a header part M10-1 and a body part M10-2. The start line of the header part M10-1 indicates that the message is a response message as a message type. “200 OK” is included, and following the start line, the header information of a plurality of items similar to the connection request message M9 is included. For example, as shown in FIG. 24, the body part M10-2 includes the server SV1b among the two transform payloads 92-1 and 92-2 proposed in the body part M5-2 of the connection request message M10. One selected transform payload (in this example, EPS-AES) remains.
SIPプロキシPRbは、接続応答メッセージM10を受信すると、受信メッセージのヘッダ部から自URIを含むViaヘッダを除去し、図25に示す接続応答メッセージM11に変換して、SIPプロキシPRaに送信する。SIPプロキシPRaは、接続応答メッセージM11を受信すると、受信メッセージのヘッダ部から自URIを含むViaヘッダを除去し、図26に示す接続応答メッセージM12に変換して、要求元クライアントCL1aに送信する。 When receiving the connection response message M10, the SIP proxy PRb removes the Via header including its own URI from the header part of the received message, converts it to the connection response message M11 shown in FIG. 25, and transmits it to the SIP proxy PRa. When receiving the connection response message M11, the SIP proxy PRa removes the Via header including its own URI from the header part of the received message, converts it to the connection response message M12 shown in FIG. 26, and transmits it to the requesting client CL1a.
要求元クライアントCL1aは、接続応答メッセージM12を受信すると、受信メッセージのボディ部M10−2を解析して、接続先サーバSV1bとのIPsec通信に適用すべきSA情報を決定し、これをSADB33Cに登録した後、図27に示す接続確認メッセージM13をSIPプロキシPRaに送信する。接続確認メッセージM13は、スタートラインに、メッセージ種類「ACK」と、Request−URIとしてサーバSV1bのSIP−URIを含み、ヘッダ情報として、Via、To、From、Call−ID、CSec、Routeヘッダを含み、メッセージボディ部は省略されている。Routeヘッダには、接続応答メッセージM12のRecord−Routeヘッダから抽出されたURIの値が設定される。
Upon receiving the connection response message M12, the request source client CL1a analyzes the body part M10-2 of the received message, determines SA information to be applied to IPsec communication with the connection destination server SV1b, and registers this in the
上記接続確認メッセージM13は、SIPプロキシPRaで新たなViaヘッダを追加し、SIPプロキシPRaと対応するRouteヘッダを除去して、図28に示す接続確認メッセージM14としてSIPプロキシPRbに転送される。SIPプロキシPRbは、接続確認メッセージM14に新たなViaヘッダを追加し、SIPプロキシPRbと対応するRouteヘッダを除去し、図29に示す接続確認メッセージM15に変換して接続先サーバSV1bに転送する。 The connection confirmation message M13 adds a new Via header by the SIP proxy PRa, removes the Route header corresponding to the SIP proxy PRa, and is transferred to the SIP proxy PRb as the connection confirmation message M14 shown in FIG. The SIP proxy PRb adds a new Via header to the connection confirmation message M14, removes the Route header corresponding to the SIP proxy PRb, converts it to the connection confirmation message M15 shown in FIG. 29, and transfers it to the connection destination server SV1b.
サーバSV1bが上記接続確認メッセージM15を受信することによって、クライアントCL1aとサーバSV1bは、IPsec暗号化を適用したアプリケーション間のデータ通信(S20)が可能となる。すなわち、クライアントCL1aは、サーバSV1bへの送信データをSADB33Cに登録されているSA情報に従って暗号化し、これをIPパケット形式で送信する。サーバSV1bは、クライアントCL1aからの受信データをSADB33Vに登録されているSA情報に従って復号化し、クライアントCL1aへの送信データを上記SA情報に従って暗号化して、IPパケット形式で送信できる。
When the server SV1b receives the connection confirmation message M15, the client CL1a and the server SV1b can perform data communication (S20) between applications to which IPsec encryption is applied. That is, the client CL1a encrypts the transmission data to the server SV1b according to the SA information registered in the
クライアントCL1aは、サーバSV1bとの間でのデータ通信が終了すると、SIPプロキシPRaに対して、図30に示す切断要求メッセージM20を送信する。切断要求メッセージM20は、スタートラインに、メッセージ種類「BYE」とサーバSV1bのSIP−URIを含み、ヘッダ情報として、接続確認メッセージM13と同様、Via、To、From、Call−ID、CSec、Routeヘッダを含み、メッセージボディ部は省略される。 When the data communication with the server SV1b is completed, the client CL1a transmits a disconnection request message M20 shown in FIG. 30 to the SIP proxy PRa. The disconnection request message M20 includes the message type “BYE” and the SIP-URI of the server SV1b in the start line, and the header information is the Via, To, From, Call-ID, CSec, and Route headers as in the connection confirmation message M13. The message body part is omitted.
SIPプロキシPRaは、上記切断要求メッセージM20を受信すると、要求元のクライアントVL1aに対して、図31に示す切断中メッセージM21を送信した後、切断要求メッセージM20に新たなViaヘッダを追加し、SIPプロキシPRaと対応するRouteヘッダを除去し、図32に示す切断要求メッセージM22として、SIPプロキシPRbに送信する。切断中メッセージM21は、スタートラインに、メッセージ種類として、要求を実行中であることを示す「110 Trying」を含み、ヘッダ部に、切断要求メッセージM20から抽出されたVia、To、From、Call−ID、CSec等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。 Upon receiving the disconnect request message M20, the SIP proxy PRa transmits a disconnecting message M21 shown in FIG. 31 to the requesting client VL1a, and then adds a new Via header to the disconnect request message M20. The Route header corresponding to the proxy PRa is removed and transmitted to the SIP proxy PRb as a disconnection request message M22 shown in FIG. The disconnecting message M21 includes “110 Trying” indicating that the request is being executed as the message type in the start line, and Via, To, From, Call− extracted from the disconnection request message M20 in the header portion. It includes several items of header information such as ID and CSec, and the message body portion is omitted.
SIPプロキシPRbは、上記切断要求メッセージM22を受信すると、SIPプロキシPRaに対して、図33に示す切断中メッセージM23を送信した後、切断要求メッセージM22に新たなViaヘッダを追加し、SIPプロキシPRbと対応するRouteヘッダを除去し、図34に示す切断要求メッセージM24として、サーバSV1bに送信する。 When the SIP proxy PRb receives the disconnection request message M22, the SIP proxy PRb transmits a disconnecting message M23 shown in FIG. 33 to the SIP proxy PRa, and then adds a new Via header to the disconnection request message M22. The Route header corresponding to the message is removed and transmitted to the server SV1b as a disconnection request message M24 shown in FIG.
サーバSV1bは、切断要求メッセージM24を受信すると、図35に示す切断応答メッセージM25をSIPプロキシPRbに送信する。切断応答メッセージM25は、スタートラインに、メッセージ種類として、応答を示す「200 OK」を含み、ヘッダ部に、切断要求メッセージM24から抽出されたVia、To、From、Call−ID、CSec等の数項目のヘッダ情報を含み、メッセージボディ部は省略されている。 When the server SV1b receives the disconnection request message M24, the server SV1b transmits a disconnection response message M25 shown in FIG. 35 to the SIP proxy PRb. The disconnection response message M25 includes “200 OK” indicating a response as a message type in the start line, and the header portion includes the number of Via, To, From, Call-ID, CSec, etc. extracted from the disconnection request message M24. Including the header information of the item, the message body part is omitted.
SIPプロキシPRbは、切断応答メッセージM25を受信すると、受信メッセージのヘッダ部から自URIを含むViaヘッダを除去し、図36に示す切断応答メッセージM26に変換して、SIPプロキシPRaに送信する。SIPプロキシPRaは、切断応答メッセージM26を受信すると、受信メッセージのヘッダ部から自URIを含むViaヘッダを除去し、図37に示す切断応答メッセージM27に変換して、要求元クライアントCL1aに送信する。要求元クライアントCL1aは、上記切断応答メッセージM27を受信すると、IPsec暗号化/復号化を終了し、同一または別のアプリケーションによる新たなパケット送信要求を待つ。 When receiving the disconnection response message M25, the SIP proxy PRb removes the Via header including its own URI from the header part of the received message, converts it to the disconnection response message M26 shown in FIG. 36, and transmits it to the SIP proxy PRa. When receiving the disconnection response message M26, the SIP proxy PRa removes the Via header including its own URI from the header part of the received message, converts it to the disconnection response message M27 shown in FIG. 37, and transmits it to the request source client CL1a. Upon receiving the disconnection response message M27, the request source client CL1a ends IPsec encryption / decryption and waits for a new packet transmission request by the same or another application.
次に、図38〜図48を参照して、上述した本発明の第1実施例の暗号化データ通信を可能にするクライアントCL1a、SIPサーバSIPa(SIPプロキシPRa、レジストラRGa)、サーバSV2bの制御動作について説明する。
図38は、クライアントCL1aにおいて、IPsecエンジン31が発行する暗号鍵交換要求に応答してSP/SA制御部51Cが実行する制御動作のフローチャート100を示す。
Next, referring to FIGS. 38 to 48, control of the client CL1a, SIP server SIPa (SIP proxy PRa, registrar RGa), and server SV2b that enables the encrypted data communication of the first embodiment of the present invention described above. The operation will be described.
FIG. 38 shows a
クライアントCL1aのIPsecエンジン31Cは、アプリケーション40CからIPパケットの送信要求を検出すると、SPDB(Security Policy Data Base)32Cを参照して、上記IPパケットにIPsec暗号化の適用要否を判定する。IPsec暗号化を適用すべきと判断した場合、IPsecエンジン31Cは、SADB(Security Association Data Base)33Cから、上記IPパケットに適用すべき暗号鍵などのSA(Security Association)情報を検索する。ここで、SADBにIPパケットに適用すべきSA情報が未登録の場合、IPsecエンジン31Cは、鍵管理プロセス50Cに対して、通信相手との暗号化パラメータの交換(鍵交換)を要求する。
Upon detecting an IP packet transmission request from the
本実施例では、IPsecエンジン31Cからの上記鍵交換要求をSP/SA制御部51Cで処理する。SP/SA制御部51Cは、鍵交換要求を受信すると、鍵交換要求が示すTCP/IP通信パラメータと、SP/SA制御部51Cが管理している利用可能なSA情報とに基づいて、図18に例示した接続要求メッセージのボディ部M5−2を作成し(ステップ101)、該接続要求メッセージボディ部M5−2をSIPメッセージ処理部53Cに渡し(102)、SIPメッセージ処理部53Cからの接続応答メッセージボディ部の受信を待つ(103)。
In this embodiment, the SP / SA control unit 51C processes the key exchange request from the
SP/SA制御部51Cは、SIPメッセージ処理部53Cから、図24に例示した接続応答メッセージボディ部M10−2を受信すると、受信した接続応答メッセージボディ部を解析し、今回のIPsec通信に使用すべきSA情報を決定し(104)、IPsecエンジン31Cに、SADB33Cに設定すべきSA情報を通知する(105)。
Upon receiving the connection response message body M10-2 illustrated in FIG. 24 from the SIP
図39(図39A、39B)は、SP/SA制御部51Cから接続要求メッセージのボディ部を受信した時、SIPメッセージ処理部53Cが実行する制御動作のフローチャート110を示す。
SIPメッセージ処理部53Cは、SP/SA制御部51Cから接続要求メッセージのボディ部を受信すると、第2IDペイロードのIDデータが示す接続先サーバのIPアドレスと、SIPメッセージ処理部53Cが管理している通信制御パラメータとから、図15に例示したAOR取得要求メッセージM3を作成し(ステップ111)、該メッセージをTSL部52C、TCP/IP部30C、NIC部20Cを介して、クライアントCL1aと同一ドメインに位置するSIPサーバSIPa(レジストラRGa)宛に送信する(112)。このとき、TLS部52Cは、レジストラRGaとの間でTLSネゴシェーション(図11のS5)を実行した後、TLS暗号化されたAOR取得要求メッセージM3をTCP/IP部30C、NIC部20Cを介してレジストラRGaに送信する。上記AOR取得要求メッセージM3は、TCP/IP部30Cによって、SIPサーバSV1宛の宛先IPアドレスを含むIPヘッダH1とUDP/TCPヘッダH2とが付加され、IPパケット形式でネットワークNW1に送出される。
FIG. 39 (FIGS. 39A and 39B) shows a
When the SIP
SIPメッセージ処理部53Cは、レジストラRGaからのAOR取得応答メッセージを待っており(113)、AOR取得応答メッセージを受信すると、受信メッセージを解析し(114)、AORヘッダから接続先サーバに割り当てられたAOR形式のSIP−URIを抽出する(115)。この後、SIPメッセージ処理部53Cは、上記SIP−URIをスタートラインとToヘッダに適用して、ヘッダ部M5−1とSP/SA制御部51Cから受信したボディ部M5−2とからなる図17に例示した接続要求メッセージM5を作成する(116)。
The SIP
SIPメッセージ処理部53Cは、上記接続要求メッセージをTSL部52C、TCP/IP部30C、NIC部20Cを介して、SIPサーバSIPaのSIPプロキシPRa宛に送信し(117)、SIPプロキシPRaからの応答を待つ(118)。SIPプロキシPRaから接続中メッセージM6を受信した場合は、接続中メッセージ処理(119)を実行した後、SIPプロキシPRaからの次の応答を待つ。
The SIP
SIPメッセージ処理部53Cは、SIPプロキシPRaから接続応答メッセージM12を受信すると、受信メッセージを解析し(120)、受信メッセージから抽出した図24に例示した接続応答メッセージボディ部M12−2をSP/SA制御部51Cに渡す(121)。この後、SIPメッセージ処理部53Cは、図27に例示した接続確認メッセージM13を作成し、これをTSL部52C、TCP/IP部30C、NIC部20Cを介して、SIPプロキシPRa宛に送信し(122)、このルーチンを終了する。
Upon receiving the connection response message M12 from the SIP proxy PRa, the SIP
図40は、AOR取得要求メッセージM3を受信した時、レジストラRGaのSIPメッセージ処理部53Rが実行する制御動作のフローチャート200を示す。
レジストラRGaのSIPメッセージ処理部53Rは、受信したAOR取得要求メッセージM3を解析し(ステップ201)、Toヘッダが示す接続先サーバSV1bのIPアドレスを検索キーとして、ロケーションデータ検索クエリを作成し(202)、レジストラ処理部60Rを介して、上記検索クエリをロケーションサーバLSVに送信し(203)、ロケーションサーバからの応答を待つ(204)。
FIG. 40 shows a
The SIP
SIPメッセージ処理部53Rは、レジストラ処理部60Rを介して、ロケーションサーバLSVからロケーションデータを受信すると、受信データが示すSIP−URIをAORヘッダとして含む図16に例示したAOR取得応答メッセージM4を作成し(205)、該メッセージM4をTCP/IP部30R、NIC部20Rを介してAOR取得要求メッセージM3の送信元(この例では、クライアントCL1a)に送信し(206)、このルーチンを終了する。
When the SIP
図41(図41A〜図41D)は、クライアントCL1aから接続要求メッセージM5を受信した時、SIPプロキシPRaのSIPメッセージ処理部53Pが実行する制御動作のフローチャート300を示す。
SIPプロキシPRaのSIPメッセージ処理部53Pは、クライアントCL1aからの接続要求メッセージM5を受信すると、受信メッセージを解析し(ステップ301)、受信メッセージのスタートラインに記述されたRequest−URIをチェックして(302)、上記Request−URIが示すドメイン名から、受信メッセージの転送先を判定する(303)。
41 (FIGS. 41A to 41D) shows a
When the SIP
受信メッセージの転送先が他のドメインに所属していると判定された場合、SIPメッセージ処理部53Pは、DNS検索(NAPTR検索+SRV検索+A検索)等によって、受信メッセージの転送先ドメインのSIPサーバ(SIPプロキシ)を決定する(304)。図11で示した例では、DNS検索によって、接続要求メッセージM5の転送先が、SIPプロキシPRbであることが判明する。この場合、SIPメッセージ処理部53Pは、図19で例示した接続中メッセージM6をTLS部52P、TCP/IP部30P、NIC部20Pを介して、接続要求メッセージM5の送信元であるクライアントCL1aに送信(305)した後、接続要求メッセージM5に新たなViaヘッダを付加した形の接続要求メッセージM7をSIPプロキシPRbに転送して(306)、SIPプロキシPRbからの応答を待つ(307)。
When it is determined that the transfer destination of the received message belongs to another domain, the SIP
SIPメッセージ処理部53Pは、SIPプロキシPRbから接続中メッセージM8を受信すると、接続中メッセージ処理(308)を実行した後、SIPプロキシPRbからの次の応答を待つ。SIPメッセージ処理部53Pは、SIPプロキシPRbから接続応答メッセージM11を受信すると、受信メッセージを解析し(309)、受信メッセージから自SIP−URIを含むViaヘッダを除去し、接続応答メッセージM12として、接続要求元(クライアントCL1a)に転送する(310)。この後、SIPメッセージ処理部53Pは、接続要求元(クライアントCL1a)からの応答を待つ(311)。SIPメッセージ処理部53Pは、接続確認メッセージM13を受信すると、受信メッセージを解析し(312)、受信メッセージに自分のSIP−URIを含む新たなViaヘッダを付加し、接続確認メッセージM13として、SIPプロキシPRbに転送して(313)、このルーチンを終了する。
Upon receiving the connected message M8 from the SIP proxy PRb, the SIP
判定ステップ303で、クライアント端末CL1aから受信した接続要求メッセージの転送先が、例えば、サーバSV1a(またはSV2a)のように、SIPプロキシPRaと同一ドメインに所属していると判定された場合、SIPメッセージ処理部53Pは、受信メッセージのRequest−URIが示すSIP−URIを検索キーとするロケーションデータ(IPアドレス)検索クエリを作成し(315)、該ロケーションデータ検索クエリをロケーションサーバLSVに送信して(316)、ロケーションサービス応答を待つ(317)。
When it is determined in the
SIPメッセージ処理部53Pは、ロケーションサーバLSVからロケーションデータを受信すると、上記ロケーションデータが示す接続先サーバのIPアドレスを宛先IPアドレスに適用して、接続要求メッセージをIPパケット形式でネットワークNW1に送信し(318)、接続先サーバからの応答を待つ(319)。上記接続要求メッセージには、SIPプロキシPRaのSIP−URIを含む新たなViaヘッダが付加されている。
Upon receiving the location data from the location server LSV, the SIP
接続先サーバから接続応答メッセージを受信すると、SIPメッセージ処理部53Pは、受信メッセージを解析し(320)、自分と対応するViaヘッダを除去した形の接続応答メッセージを接続要求元に転送して(321)、接続要求元(クライアントCL1a)からの応答を待つ(322)。SIPメッセージ処理部53Pは、接続要求元から接続確認メッセージを受信すると、受信メッセージを解析し(323)、新たなViaヘッダを付加した形の接続確認メッセージを接続先サーバに転送して(324)、このルーチンを終了する。
Upon receiving the connection response message from the connection destination server, the SIP
図42(図42A、図42B)は、接続先サーバSV1bのSIPメッセージ処理部53Sが、SIPプロキシPRbから接続要求メッセージM9を受信した時に実行する制御動作のフローチャート400を示す。
SIPプロキシPRbから接続先サーバSV1bに送信された接続要求メッセージM9は、TLS部52Sで復号化した後、SIPメッセージ処理部53Sに入力される。SIPメッセージ処理部53Sは、接続要求メッセージM9を受信すると、受信メッセージを解析し(ステップ401)、受信メッセージから抽出した接続要求メッセージボディ部M5−2をSP/SA制御部51Sに渡し(402)、SP/SA制御部51Sからの応答を待つ(403)。
42 (FIGS. 42A and 42B) shows a
The connection request message M9 transmitted from the SIP proxy PRb to the connection destination server SV1b is decrypted by the
SIPメッセージ処理部53Sは、SP/SA制御部51Sから接続応答メッセージボディ部M10−2を受信すると、図25に例示した接続応答メッセージM11を作成する(404)。SIPメッセージ処理部53Sは、TLS部、TCP/IP部、NIC部を介して、上記接続応答メッセージM11をSIPプロキシPRbに転送し(405)、SIPプロキシPRbからの応答を待つ(406)。SIPメッセージ処理部53Sは、SIPプロキシPRbから、接続確認メッセージM15を受信すると、受信メッセージを解析し(407)、接続確認メッセージM15を受信したことをSP/SA制御部51Sに通知して(408)、このルーチンを終了する。
When the SIP
図43は、SIPメッセージ処理部53Sから接続要求メッセージボディ部M5−2を受信した時、サーバSV1bのSP/SA制御部51Sが実行する制御動作の示すフローチャート420を示す。
SP/SA制御部51Sは、SIPメッセージ処理部53Sから受信した接続要求メッセージボディ部M5−2を解析し(ステップ421)、接続要求メッセージボディ部M5−2に記述されたSA情報(図18の例では、トランスフォームペイロード92−1、92−2)から、クライアントとの暗号化通信に適用すべきSAを選択して、図24に例示した接続応答メッセージのボディ部M10−2を作成する(422)。SP/SA制御部51Sは、上記接続応答メッセージボディ部M10−2をSIPメッセージ処理部53Sに渡し(423)、SIPメッセージ処理部53Sからの応答を待つ(424)。SP/SA制御部51Sは、SIPメッセージ処理部53Sから接続確認メッセージの受信通知を受けると、IPsecエンジン31Sに対して、SADB33Sに設定すべきSA情報を通知して(425)、このルーチンを終了する。
FIG. 43 shows a
The SP / SA control unit 51S analyzes the connection request message body part M5-2 received from the SIP
図44は、クライアントCL1aにおいて、IPsecエンジン31Cが発行する暗号鍵消去要求に応答してSA/SP処理部51Cが実行する制御動作のフローチャート130を示す。
クライアントCL1aのユーザが、サーバSV1bと交信していたアプリケーションを終了すると、IPsecエンジン31CからSA/SP制御部51Cに、暗号鍵消去要求が発行される。SA/SP制御部51Cは、IPsecエンジン31Cから暗号鍵消去要求を受信すると、SIPメッセージ処理部53Cに、切断要求メッセージの発行を要求し(131)、SIPメッセージ処理部53Cからの応答を待つ(132)。SA/SP制御部51Cは、SIPメッセージ処理部53Cから切断応答メッセージの受信通知を受けると、IPsecエンジン31Cに対して、上記暗号鍵消去要求と対応するSADBの設定値消去を指示し(133)、このルーチンを終了する。
FIG. 44 shows a
When the user of the client CL1a terminates the application communicating with the server SV1b, an encryption key deletion request is issued from the
図45は、SA/SP制御部51Cから切断要求メッセージの発行要求を受信した時にSIPメッセージ処理部53Cが実行する制御動作のフローチャート140を示す。
SIPメッセージ処理部53Cは、SA/SP制御部51Cから切断要求メッセージの発行要求を受信すると、図30に例示した切断要求メッセージM20を作成し(ステップ141)、TLS部52C、TCP/IP部30CのIPsecエンジン31C、NIC部20Cを介して、上記切断要求メッセージM20のIPパケットをSIPサーバSIPa(SIPプロキシPRa)に送信する(142)。
FIG. 45 shows a
When the SIP
SIPメッセージ処理部53Cは、SIPプロキシPRaからの応答を待ち(143)、切断中メッセージM21を受信した場合は、切断中メッセージ処理(144)を実行した後、SIPプロキシPRaからの次の応答を待つ。SIPメッセージ処理部53Cは、SIPプロキシPRaから図37に例示した切断応答メッセージM27を受信すると、受信メッセージを解析し(145)、SP/SA制御部51Cに切断応答メッセージの受信を通知し(146)、このルーチンを終了する。
The SIP
図46(図46A、図46B)は、クライアントから切断要求メッセージM20を受信した時にSIPプロキシPRaのSIPメッセージ処理部53Pが実行する制御動作のフローチャート340を示す。
SIPメッセージ処理部53Pは、受信した切断要求メッセージM20を解析し(ステップ341)、受信メッセージのRequest−URIをチェックする(342)。SIPメッセージ処理部53Pは、Request−URIに記述されたドメイン名から、受信メッセージの転送先を判定し(343)、転送先が他のドメインに所属していると判定された場合、DNS検索(NAPTR検索+SRV検索+A検索)等によって、受信メッセージの転送先ドメインのSIPサーバ(SIPプロキシ)を決定する(344)。
46 (FIG. 46A, FIG. 46B) shows a
The SIP
図12で示した例では、上記DNS検索によって、切断要求メッセージM20の転送先が、SIPプロキシPRbであることが判明する。この場合、SIPメッセージ処理部53Pは、TLS部52P、TCP/IP部30P、NIC部20Pを介して、切断要求メッセージM20の送信元であるクライアントCL1aに、図31に例示した切断中メッセージM21を送信(345)した後、切断要求メッセージM20に新たなViaヘッダを付加し、SIPプロキシPRaに対応するRouteヘッダを除去した切断要求メッセージM22をSIPプロキシPRbに転送し(346)、SIPプロキシPRbからの応答を待つ(347)。
In the example shown in FIG. 12, the DNS search reveals that the transfer destination of the disconnection request message M20 is the SIP proxy PRb. In this case, the SIP
SIPメッセージ処理部53Pは、SIPプロキシPRbから切断中メッセージM23を受信すると、切断中メッセージ処理(348)を実行した後、SIPプロキシPRbからの次の応答を待つ。SIPメッセージ処理部53Pは、SIPプロキシPRbから切断応答メッセージM26を受信すると、受信メッセージを解析し(349)、受信メッセージから自SIP−URIを含むViaヘッダを除去し、切断応答メッセージM27として、切断要求元(クライアントCL1a)に転送し(350)、このルーチンを終了する。
When the SIP
尚、判定ステップ343で、もし、クライアント端末CL1aから受信した切断要求メッセージM20の転送先が、SIPプロキシPRaと同一ドメインに所属していると判定された場合、SIPメッセージ処理部53Pは、受信メッセージのRequest−URIが示すSIP−URIを検索キーとするロケーションデータ(IPアドレス)検索クエリを作成し(351)、該検索クエリをロケーションサーバLSVに送信して(352)、ロケーションサービス応答を待つ(353)。
In the
SIPメッセージ処理部53Pは、ロケーションサーバLSVからロケーションデータを受信すると、上記ロケーションデータが示すサーバIPアドレスを宛先IPアドレスに適用して、切断要求メッセージのIPパケットをネットワークNW1に送信し(354)、サーバからの応答を待つ(355)。尚、上記切断要求メッセージには、SIPプロキシPRaのSIP−URIを含む新たなViaヘッダが付加されている。
切断要求メッセージの宛先サーバから切断応答メッセージを受信すると、SIPメッセージ処理部53Pは、受信メッセージを解析し(356)、自分のViaヘッダを除去した形の切断応答メッセージを切断要求元に転送し(357)、このルーチンを終了する。
Upon receiving the location data from the location server LSV, the SIP
When receiving the disconnection response message from the destination server of the disconnection request message, the SIP
図47は、SIPプロキシから切断要求メッセージM24を受信した時、サーバSV1bのSIPメッセージ処理部53Sが実行する制御動作のフローチャート430を示す。
SIPメッセージ処理部53Sは、TLS部52Sを介して切断要求メッセージM24を受信すると、受信メッセージを解析し(ステップ431)、SP/SA制御部51Sに対して、切断すべき通信の識別情報(例えば、Call−ID)を指定して、切断要求の受信を通知し(432)、SP/SA制御部51Sからの応答を待つ(433)。SIPメッセージ処理部53Sは、SP/SA制御部51Sから切断応答を受信すると、図35に例示した切断応答メッセージM25を作成し(434)、TLS部、TCP/IP部、NIC部を介してSIPプロキシPRbに転送し(435)、このルーチンを終了する。
FIG. 47 shows a
When the SIP
図48は、SIPメッセージ処理部53Sから切断要求の発生を通知された時、SP/SA制御部51Sが実行する制御動作のフローチャート440を示す。
SP/SA制御部51Sは、通知された通信識別情報にもとづいて、SADB33Sから消去すべきSA情報を特定し(ステップ441)、IPsecエンジン31Sに上記SA情報の消去を指示し(442)、このルーチンを終了する。
FIG. 48 shows a
The SP / SA controller 51S specifies SA information to be deleted from the
次に、図49から図59を参照して、本発明による暗号化データ通信の第2の実施例について説明する。
上述した第1実施例では、接続先サーバをIPアドレスで指定した形でパケット送信要求が発生した時、クライアントのSIPメッセージ処理部53Cが、上記接続先IPアドレスと対応したSIP−URIを取得するためのAOR取得要求を発行し、レジストラから取得したSIP−URIを適用して、SIPプロキシ宛の接続要求メッセージを発行した。
Next, with reference to FIGS. 49 to 59, a second embodiment of the encrypted data communication according to the present invention will be described.
In the first embodiment described above, when a packet transmission request is generated with the destination server specified by the IP address, the SIP
本発明の第2実施例は、接続先サーバをIPアドレスで指定した形でパケット送信要求が発生した時、クライアントが、接続先サーバをIPアドレスで指定した形の接続要求メッセージを発行し、該接続要求メッセージを受信したSIPプロキシが、受信メッセージのスタートラインに記述されたRequest−URIの形式をチェックし、接続先がIPアドレスで指定されていた場合、これをSIP−URIに書き換えて、接続先サーバの所属ドメインに位置する他のSIPサーバに接続要求メッセージを転送するようにしたことを特徴とする。 In the second embodiment of the present invention, when a packet transmission request is generated in a form in which the connection destination server is specified by the IP address, the client issues a connection request message in a form in which the connection destination server is specified by the IP address, The SIP proxy that has received the connection request message checks the format of the Request-URI described in the start line of the received message, and if the connection destination is specified by the IP address, it is rewritten to the SIP-URI to connect The connection request message is transferred to another SIP server located in the domain to which the destination server belongs.
図49と図50は、本発明の第2実施例における暗号化通信シーケンス図を示す。図11、図12と同一符号で示された第1実施例で説明済みのステップとメッセージについては、できるだけ説明を省略する。
本発明の第2実施例では、クライアントCL1aは、接続先サーバをIPアドレスで指定した形でパケット送信要求が発生した時、SIPプロキシPRaとの間で、クライアントの認証と暗号化通信用パラメータ設定のためのTLSネゴシェーション(S7)を実行した後、SIPプロキシPRaに対して、直ちに接続要求メッセージM5xを送信する。ここで送信される接続要求メッセージM5xは、図51に示すように、スタートラインに記述されるRequest−URIと、ヘッダ部に記述されるToヘッダが、接続先サーバSV1bをIPアドレス「192.0.2.4」で指定している。ヘッダ部のその他のヘッダ情報と、接続要求メッセージボディ部M5−2の内容は、図17および図18に示した第1実施例の接続要求メッセージM5と同一である。
49 and 50 show encrypted communication sequence diagrams in the second embodiment of the present invention. Description of steps and messages described in the first embodiment indicated by the same reference numerals as those in FIGS. 11 and 12 is omitted as much as possible.
In the second embodiment of the present invention, the client CL1a, when a packet transmission request is generated in a form in which the connection destination server is specified by the IP address, performs client authentication and parameter setting for encrypted communication with the SIP proxy PRa. After executing the TLS negotiation for S7 (S7), the connection request message M5x is immediately transmitted to the SIP proxy PRa. As shown in FIG. 51, the connection request message M5x transmitted here includes the Request-URI described in the start line and the To header described in the header portion indicating the connection destination server SV1b with the IP address “192.0.2.4. "Is specified. The other header information of the header part and the contents of the connection request message body part M5-2 are the same as those of the connection request message M5 of the first embodiment shown in FIGS.
SIPプロキシPRaは、受信した接続要求メッセージM5xのRequest−URIが「SIP:IPアドレス」形式となっているため、ロケーションサービスDBのロケーションサービステーブル60から、上記IPアドレス「192.0.2.4」と対応するAOR(SIP−URI)を検索する(S5)。SIPプロキシPRaは、ロケーションサービステーブル60からAOR「sv1@bbb.com」を取得すると(S6)、要求元クライアントCL1aに、図52に示す接続中メッセージM6xを送信した後、接続先サーバSV1bが所属するドメインのSIPプロキシPRbとの間で、相互の認証と暗号化通信用のパラメータ設定のためにTLSネゴシェーション(S8)を実行する。接続中メッセージM6xの内容は、IPアドレス記述となっているToヘッダを除いて、図19に示した第1実施例の接続中メッセージM6と同一である。 The SIP proxy PRa corresponds to the IP address “192.0.2.4” from the location service table 60 of the location service DB because the Request-URI of the received connection request message M5x is in the “SIP: IP address” format. AOR (SIP-URI) is searched (S5). When the SIP proxy PRa obtains the AOR “[email protected]” from the location service table 60 (S6), the SIP proxy PRa transmits the message M6x being connected shown in FIG. 52 to the requesting client CL1a, and then the destination server SV1b belongs to it. TLS negotiation (S8) is executed for mutual authentication and parameter setting for encrypted communication with the SIP proxy PRb of the domain to be operated. The contents of the connected message M6x are the same as the connected message M6 of the first embodiment shown in FIG. 19 except for the To header which is an IP address description.
SIPプロキシPRaは、SIPプロキシPRbとの間のTLSネゴシェーションが終了すると、SIPプロキシPRbに対して、図53に示す接続要求メッセージM7xを送信する。接続要求メッセージM7xは、クライアントCL1aから受信した接続要求メッセージM5xに、SIPプロキシPRaのSIP−URIを含むViaヘッダを追加し、
スタートラインのRequest−URIをIPアドレス「192.0.2.4」からSIP−URI「sv1@bbb.com」に書き換えた内容となっている。以下、第1実施例の同様の通信シーケンスが実行され、アプリケーション間のデータ通信状態(S20)に至る。
When the TLS negotiation with the SIP proxy PRb is completed, the SIP proxy PRa transmits a connection request message M7x shown in FIG. 53 to the SIP proxy PRb. The connection request message M7x adds a Via header including the SIP-URI of the SIP proxy PRa to the connection request message M5x received from the client CL1a.
The request-URI of the start line is rewritten from the IP address “192.0.2.4” to the SIP-URI “[email protected]”. Thereafter, the same communication sequence of the first embodiment is executed, and the data communication state between applications (S20) is reached.
SIPプロキシPRbからSIPプロキシPRaに送信される接続中メッセージM8x、SIPプロキシPRbから接続先サーバSV1bに送信される接続要求メッセージM9x、サーバSV1bからSIPプロキシPRbに送信される接続応答メッセージM10x、SIPプロキシPRbからSIPプロキシPRaに送信される接続応答メッセージM11x、SIPプロキシPRaに要求元クライアントCL1aに送信される接続応答メッセージM12x、クライアントCL1aからSIPプロキシPRaに送信される接続確認メッセージM13x、SIPプロキシPRaからSIPプロキシPRbに送信される接続確認メッセージM14x、SIPプロキシPRbからサーバSV1bに送信される接続確認メッセージM15xは、IPアドレス記述となっているToヘッダを除いて、それぞれ第1実施例で例示したSIPメッセージM8〜M15と同一内容となる。 The connection message M8x transmitted from the SIP proxy PRb to the SIP proxy PRa, the connection request message M9x transmitted from the SIP proxy PRb to the connection destination server SV1b, the connection response message M10x transmitted from the server SV1b to the SIP proxy PRb, and the SIP proxy A connection response message M11x transmitted from the PRb to the SIP proxy PRa, a connection response message M12x transmitted to the requesting client CL1a to the SIP proxy PRa, a connection confirmation message M13x transmitted from the client CL1a to the SIP proxy PRa, and the SIP proxy PRa The connection confirmation message M14x transmitted to the SIP proxy PRb and the connection confirmation message M15x transmitted from the SIP proxy PRb to the server SV1b are IP addresses. Except for the To header that has become less description, made with SIP messages M8~M15 exemplified in the first embodiment respectively same contents.
クライアントCL1aは、サーバSV1bとの間でのアプリケーションデータ通信が終了すると、SIPプロキシPRaに対して、図54に示す切断要求メッセージM20xを送信する。切断要求メッセージM20xは、スタートラインのRequest−URIとToヘッダが、サーバSV1bをIPアドレス「sv1@192.0.2.4」で指定している。ヘッダ部のその他のヘッダ情報は、図17および図18に示した第1実施例の接続要求メッセージM5と同一である。 When the application data communication with the server SV1b is completed, the client CL1a transmits a disconnection request message M20x shown in FIG. 54 to the SIP proxy PRa. In the disconnection request message M20x, the request-URI and To header of the start line specify the server SV1b with the IP address “[email protected]”. The other header information of the header part is the same as the connection request message M5 of the first embodiment shown in FIGS.
SIPプロキシPRaは、上記切断要求メッセージM20xを受信すると、要求元のクライアントVL1aに対して、切断中メッセージM21xを送信した後、切断要求メッセージM20xを図55に示す切断要求メッセージM22xに変換して、SIPプロキシPRbに送信する。切断中メッセージM21xは、IPアドレス記述となっているToヘッダを除いて、図31に示した第1実施例の切断中メッセージM21と同一の内容となっている。切断要求メッセージM22xは、クライアントCL1aから受信した切断要求メッセージM20xに、SIPプロキシPRaのSIP−URIを含むViaヘッダを追加し、SIPプロキシPRaと対応するRouteヘッダを除去し、スタートラインのRequest−URIをIPアドレスからSIP−URIに書き換えた内容となっている。 Upon receiving the disconnection request message M20x, the SIP proxy PRa transmits a disconnecting message M21x to the requesting client VL1a, and then converts the disconnection request message M20x into a disconnection request message M22x shown in FIG. Send to SIP proxy PRb. The disconnecting message M21x has the same contents as the disconnecting message M21 of the first embodiment shown in FIG. 31 except for the To header which is an IP address description. The disconnection request message M22x adds a Via header including the SIP-URI of the SIP proxy PRa to the disconnection request message M20x received from the client CL1a, removes a Route header corresponding to the SIP proxy PRa, and requests-URI of the start line. Is rewritten from the IP address to the SIP-URI.
SIPプロキシPRbは、上記切断要求メッセージM22を受信すると、SIPプロキシPRaに対して、切断中メッセージM23xを送信した後、切断要求メッセージM22xに新たなViaヘッダを追加し、SIPプロキシPRbと対応するRouteヘッダを除去し、スタートラインのRequest−URIをSIP−URIからIPアドレスに書き換え、切断要求メッセージM24xとしてサーバSV1bに送信する。切断中メッセージM23xと切断要求メッセージM24xは、IPアドレス記述となっているToヘッダを除いて、図33、図34に示した第1実施例のSIPメッセージと同一内容となっている。 When the SIP proxy PRb receives the disconnection request message M22, the SIP proxy PRb transmits a disconnecting message M23x to the SIP proxy PRa, and then adds a new Via header to the disconnection request message M22x, and the Route corresponding to the SIP proxy PRb. The header is removed, the Request-URI of the start line is rewritten from the SIP-URI to the IP address, and is transmitted to the server SV1b as a disconnection request message M24x. The disconnecting message M23x and the disconnection request message M24x have the same contents as the SIP messages of the first embodiment shown in FIGS. 33 and 34, except for the To header which is an IP address description.
サーバSV1bは、切断要求メッセージM24xを受信すると、SIPプロキシPRbに切断応答メッセージM25xを送信する。切断応答メッセージM25xは、IPアドレス記述となっているToヘッダを除いて、図35に示した第1実施例のSIPメッセージと同一内容となっている。上記切断応答メッセージM25xは、SIPプロキシPRbとSIPプロキシPRaで、第1実施例と同様の変換処理を受け、最終的に切断応答メッセージM27xとして、要求元クライアントCL1aに送信される。要求元クライアントCL1aは、上記切断応答メッセージM27xを受信すると、IPsec暗号化/復号化を終了し、同一または別のアプリケーションによる新たなパケット送信要求を待つ。 When the server SV1b receives the disconnection request message M24x, the server SV1b transmits a disconnection response message M25x to the SIP proxy PRb. The disconnection response message M25x has the same content as the SIP message of the first embodiment shown in FIG. 35 except for the To header which is an IP address description. The disconnection response message M25x is subjected to the same conversion processing as in the first embodiment by the SIP proxy PRb and the SIP proxy PRa, and is finally transmitted to the request source client CL1a as a disconnection response message M27x. Upon receiving the disconnection response message M27x, the request source client CL1a ends IPsec encryption / decryption and waits for a new packet transmission request by the same or another application.
次に、図56〜図59を参照して、本発明の第2実施例の暗号化通信を可能にするクライアントCL1aと、SIPサーバSIPa(SIPプロキシPRa、レジストラRGa)の特徴的な動作について説明する。
第2実施例において、クライアントCL1aのIPsecエンジン31CとSA/SP制御部51Cは、第1実施例と同様の機能をもつ。図56は、第2実施例において、SA/SP制御部51Cから接続要求メッセージのボディ部受信した時、クライアントCL1aのSIPメッセージ処理部53Cが実行する制御動作のフローチャート110xを示している。
Next, with reference to FIGS. 56 to 59, characteristic operations of the client CL1a and the SIP server SIPa (SIP proxy PRa, registrar RGa) that enable encrypted communication according to the second embodiment of the present invention will be described. To do.
In the second embodiment, the
SIPメッセージ処理部53Cは、SP/SA制御部51Cから接続要求メッセージのボディ部M5−2を受信すると、第2IDペイロードのIDデータが示す接続先サーバのIPアドレスをスタートラインのRequest−URIとToヘッダに適用して、ヘッダ部M5x−1と、SP/SA制御部51Cから受信したボディ部M5−2とからなる図51に例示した接続要求メッセージM5xを作成する(111x)。
When the SIP
SIPメッセージ処理部53Cは、上記接続要求メッセージをTSL部52C、TCP/IP部30C、NIC部20Cを介して、SIPサーバSIPaのSIPプロキシPRa宛に送信し(117)、SIPプロキシPRaからの応答を待ち(118)、SIPプロキシPRaから接続中メッセージM6を受信した場合は、接続中メッセージ処理(119)を実行した後、更にSIPプロキシPRaからの応答を待つ。
The SIP
SIPメッセージ処理部53Cは、SIPプロキシPRaから接続応答メッセージM12xを受信すると、受信メッセージを解析し(120)、受信メッセージから抽出した図24に例示した接続応答メッセージボディ部M12−2をSP/SA制御部51Cに渡す(121)。この後、SIPメッセージ処理部53Cは、接続確認メッセージM13xを作成し、該メッセージをTSL部52C、TCP/IP部30C、NIC部20Cを介して、SIPプロキシPRa宛に送信し(122)、このルーチンを終了する。
Upon receiving the connection response message M12x from the SIP proxy PRa, the SIP
図57は、クライアントCL1aから接続要求メッセージM5xを受信した時、SIPプロキシPRaのSIPメッセージ処理部53Pが実行する制御動作のフローチャート300xの特徴部分を示す。
SIPプロキシPRaのSIPメッセージ処理部53Pは、クライアントCL1aからの接続要求メッセージM5xを受信すると、受信メッセージを解析し(ステップ301)、受信メッセージのスタートラインに記述されたRequest−URIをチェックし(302)、Request−URIがドメイン名を含むか否かを判定する(330)。
Request−URIがドメイン名を含む場合、すなわち、「sips:ユーザ名@ドメイン名」形式の記述となっていた場合は、ステップ303で、Request−URIのドメイン名から接続要求メッセージの転送先を判定する。
FIG. 57 shows a characteristic part of a
When the SIP
If the Request-URI includes a domain name, that is, if it is described in the format of “sips: user name @ domain name”, in
Request−URIがドメイン名を含まない、すなわち、「sips:IPアドレス」形式の記述となっていた場合は、上記Request−URIが示す接続先サーバSV1bのIPアドレスを検索キーとして、ロケーションデータ検索クエリを作成し(331)、該検索クエリをロケーションサーバLSVに送信して(332)、ロケーションサーバからの応答を待つ(333)。SIPメッセージ処理部53Rは、ロケーションサーバLSVから、ロケーションデータとして接続先サーバSV1bのSIP−URIを受信すると、該SIP−URIを適用して、クライアントCL1aから受信した接続要求メッセージM5xのRequest−URIをIPアドレスからSIP−URIに書き換え、自分のSIP−URIを含むViaヘッダとRecord−Routeを追加して(334)、ステップ303で、Request−URIのドメイン名から接続要求メッセージの転送先を判定する。ステップ303以降の動作は、図41(図41A〜図41D)で説明した第1実施例と同様である。
If the Request-URI does not include a domain name, that is, it is described in the “sips: IP address” format, the location data search query using the IP address of the connection destination server SV1b indicated by the Request-URI as a search key (331), the search query is transmitted to the location server LSV (332), and a response from the location server is awaited (333). When the SIP
図58は、クライアントCL1aにおいて、SA/SP制御部51Cから切断要求メッセージの発行要求を受信した時にSIPメッセージ処理部53Cが実行する制御動作のフローチャート140xを示す。
SIPメッセージ処理部53Cは、SA/SP制御部51Cから切断要求メッセージの発行要求を受信すると、スタートラインのRequest−URIとToヘッダに現在通信中のサーバSV1bのIPアドレス「sv1@192.0.2.4」を適用して、図54に例示した切断要求メッセージM20xを作成し(ステップ141x)、TLS部52C、TCP/IP部30CのIPsecエンジン31C、NIC部20Cを介して、SIPサーバSIPa(SIPプロキシPRa)に送信する(142)。
FIG. 58 shows a
When the SIP
SIPメッセージ処理部53Cは、SIPプロキシPRaからの応答を待ち(143)、切断中メッセージM21xを受信した場合は、切断中メッセージ処理(144)を実行した後、SIPプロキシPRaからの次の応答を待つ。SIPメッセージ処理部53Cは、SIPプロキシPRaから切断応答メッセージM27xを受信すると、受信メッセージを解析し(145)、SP/SA制御部51Cに対して、切断応答メッセージの受信を通知し(146)、このルーチンを終了する。
The SIP
図59は、クライアントから切断要求メッセージM20xを受信した時にSIPプロキシPRaのSIPメッセージ処理部53Pが実行する制御動作のフローチャート340xを示す。
SIPメッセージ処理部53Pは、受信した切断要求メッセージM20xを解析し(ステップ341)、受信メッセージのRequest−URIをチェックして(342)、Request−URIがドメイン名を含むか否かを判定する(360)。Request−URIがドメイン名を含む場合は、ドメイン名から、受信メッセージの転送先を判定する(343)。Request−URIがドメイン名を含まない、すなわち、「sips:IPアドレス」形式の記述となっていた場合は、接続要求メッセージの受信時に図57のステップ331〜333で取得しておいた接続先サーバのSIP−URIを適用して、上記切断要求メッセージM20xのRequest−URIを書き換え(361)、該Request−URIが示すドメイン名から、受信メッセージの転送先を判定する(343)。ステップ343以降の動作は、図46(図46A〜図41C)で説明した第1実施例と同様である。
FIG. 59 shows a
The SIP
以上の如く、第2実施例のSIPプロキシPRaは、SIPメッセージ処理部53Pが、図9に示したように、受信SIPメッセージのRequest−URIが示すIPアドレスをSIP−URIに変換するためのSIP−URI(AOR)検索機能54を備えたことを特徴としている。
As described above, in the SIP proxy PRa of the second embodiment, the SIP
次に、図60〜図67を参照して、本発明による暗号化データ通信の第3の実施例について説明する。
第3実施例は、接続先サーバをIPアドレスで指定した形でパケット送信要求が発生した時、クライアントCl1aのSIPメッセージ処理部53Cが、上記IPアドレスを使用して接続先サーバにSIP−URIを問い合わせ、接続先サーバから取得したSIP−URIをRequest−URIに記述することによって、SIPプロキシ側で受信メッセージから接続先ドメインを判定可能な形の接続要求メッセージを発行するようにしたことを特徴としている。
Next, the third embodiment of the encrypted data communication according to the present invention will be described with reference to FIGS.
In the third embodiment, when a packet transmission request is generated with the destination server specified by the IP address, the SIP
図60は、第3実施例のクライアントCL1aが備える基本的なソフトウェア構造を示し、図61は、接続先サーバSV1bが備える基本的なソフトウェア構造を示している。
図7、図8と比較すると、クライアントCL1aのSIPメッセージ処理部53Cと、サーバSV1bのSIPメッセージ処理部53Sとが、それぞれSIP−URI要求/応答メッセージを交信するためのAOR解決機能55C、55Sを備え、サーバSV1bのSIPメッセージ処理部53Sが、AOR解決機能55Sが参照するロケーションテーブル70を備えた点が相違している。上記ロケーションテーブル70は、図62に示すように、サーバSV1bのAOR(SIP−URI)71と、IPアドレス72との対応関係を示している。
FIG. 60 shows a basic software structure provided in the client CL1a of the third embodiment, and FIG. 61 shows a basic software structure provided in the connection destination server SV1b.
Compared with FIGS. 7 and 8, the SIP
図63は、第3実施例の暗号化データ通信のシーケンス図を示す。
ここでは、クライアントCL1aからの接続要求の発行に先立って、クライアントCL1aの所属ドメインを管理するSIPプロキシPRaと、接続先サーバSV1bの所属ドメインを管理するSIPプロキシPRbとの間で、相互の認証と暗号化通信のパラメータ設定のためのTLSネゴシェーション(ステップS0)が実行済みで、接続先サーバSV1bとレジストラRGbとの間で、TLSネゴシェーション(S1)とロケーションの登録手順が実行済みとなっているものとする。但し、SIPプロキシ間のTLSネゴシェーション(S0)は、第1、第2実施例のステップS8で示したように、クライアントCL1aからの接続要求が発生した時点で、必要に応じて実行するようにしても構わない。
FIG. 63 shows a sequence diagram of encrypted data communication of the third embodiment.
Here, prior to issuing a connection request from the client CL1a, mutual authentication between the SIP proxy PRa that manages the domain to which the client CL1a belongs and the SIP proxy PRb that manages the domain to which the connection destination server SV1b belongs. The TLS negotiation (step S0) for parameter setting of encrypted communication has been executed, and the registration procedure of the TLS negotiation (S1) and the location has been executed between the connection destination server SV1b and the registrar RGb. Suppose that However, the TLS negotiation (S0) between SIP proxies is executed as necessary when a connection request from the client CL1a is generated, as shown in step S8 of the first and second embodiments. It doesn't matter.
本実施例では、クライアントCL1aにおいて、サーバSV1bをIPアドレスで指定した接続発生した時、SIPメッセージ処理部53Cが、サーバSV1b宛にダイレクトに、AOR解決要求メッセージM30を送信し、サーバSV1bのSIPメッセージ処理部53Sが、上記AOR解決要求メッセージM30の受信に応答して、サーバSV1bのSIP−URI[sv1@bbb.com]を示すAOR解決応答メッセージM40を返送する。
In this embodiment, when a connection occurs in the client CL1a with the server SV1b specified by the IP address, the SIP
AOR解決要求メッセージM30は、例えば、図64に示すように、スタートラインに、メッセージ種類として「GETAOR」、Request−URIとして、サーバSV1bのIPアドレス「1922.0.2.4」が記述されている。また、スタートラインに続くヘッダ情報として、クライアントCL1a(SIPメッセージ処理部53C)の識別情報を含むViaヘッダ、サーバSV1bのIPアドレスを含むToヘッダ、クライアントCL1a(SIPメッセージ処理部53C)のSIP−URIを含むFromヘッダと、Call−IDヘッダ、CSeqヘッダ、Content−Lengthヘッダを含む。AOR解決要求メッセージM30にはボディ部がなく、Content−Lengthは0となっている。
For example, as shown in FIG. 64, the AOR resolution request message M30 describes “GETAOR” as the message type and the IP address “1922.0.2.4” of the server SV1b as the Request-URI in the start line. Further, as header information following the start line, a Via header including identification information of the client CL1a (SIP
AOR解決応答メッセージM40は、図65に示すように、スタートラインに、応答メッセージを示すメッセージ種類「200 OK」を含む。また、ヘッダ情報として、AOR解決要求メッセージM30と同一内容のViaヘッダ、Toヘッダ、Fromヘッダ、CSeqを含み、AORヘッダによって、目的AORであるサーバSV1bのSIP−URIの値「sv1@bbb.com」が示されている。 As shown in FIG. 65, the AOR resolution response message M40 includes a message type “200 OK” indicating the response message in the start line. The header information includes a Via header, a To header, a From header, and a CSeq having the same contents as the AOR resolution request message M30. The value of the SIP-URI “[email protected]” of the server SV1b that is the target AOR is included in the AOR header. "It is shown.
クライアントCL1aのSIPメッセージ処理部53Cは、上記AOR解決応答メッセージM40を受信すると、Request−URIにサーバSV1bのSIP−URIを適用した接続要求メッセージM5を作成し、TLS部52C、IPsecエンジン30C、NIC部20Cを介して、SIPプロキシPRaに送出する。このとき、TLS部52Cは、SIPプロキシPRaとの間でTLSネゴシェーション(S7)を実行した後、接続要求メッセージM5を暗号化して、SIPプロキシPRaに送信する。
When the SIP
SIPプロキシPRaは、接続要求メッセージM5を受信すると、第1実施例と同様、要求元クライアントCL1aに接続中メッセージM6を送信した後、SIPプロキシPRb宛に、接続要求メッセージM7を送信する。以降の手順は、図12で説明した第1実施例と同様である。 When receiving the connection request message M5, the SIP proxy PRa transmits a connection request message M7 to the SIP proxy PRb after transmitting a connection in progress message M6 to the requesting client CL1a as in the first embodiment. The subsequent procedure is the same as that of the first embodiment described in FIG.
図66は、第3実施例のクライアントCL1aにおいて、SP/SA制御部51Cから接続要求メッセージのボディ部を受信した時、SIPメッセージ処理部53Cが実行する制御動作のフローチャート110yを示す。
SIPメッセージ処理部53Cは、SP/SA制御部51Cから接続要求メッセージのボディ部を受信すると、第2IDペイロードのIDデータが示す接続先サーバV1bのIPアドレスと、SIPメッセージ処理部53Cが管理している通信制御パラメータとから、図64に例示したAOR取得要求メッセージM30を作成し(ステップ111y)、該メッセージをTCP/IP部30C、NIC部20Cを介して、サーバSV1bに送信する(112y)。この場合、AOR取得要求メッセージM30は、TLS部52Cを経由しないため、サーバSV1bとの間でのTLSネゴシェーションは実行されず、AOR取得メッセージM30は暗号化されない平文メッセージとして宛先サーバSV1bに送信さされる。
FIG. 66 shows a
When the SIP
SIPメッセージ処理部53Cは、サーバSV1bからのAOR取得応答メッセージを待っており(113y)、AOR取得応答メッセージM40を受信すると、受信メッセージを解析し(114)、AORヘッダから接続先サーバに割り当てられたSIP−URIを抽出する(115)。この後、SIPメッセージ処理部53Cは、上記SIP−URIをスタートラインとToヘッダに適用して、ヘッダ部M5−1と、SP/SA制御部51Cから受信したボディ部M5−2とからなる図17に例示した接続要求メッセージM5を作成する(116)。以降の処理手順は、図39で説明した第1実施例と同様である。
The SIP
図67は、クライアントからAOR取得要求メッセージM30を受信した時、サーバSV1bのSIPメッセージ処理部53Sが実行する制御動作のフローチャート450を示す。
サーバSV1bのSIPメッセージ処理部53Sは、AOR取得要求メッセージM30を受信すると、受信メッセージを解析し(ステップ451)、ロケーションテーブル70から、受信メッセージのToヘッダが示すIPアドレスと対応するAOR値(SIP−URI)を取得する(452)。SIPメッセージ処理部53Sは、取得したAOR値をAORヘッダに設定して、AOR取得応答メッセージM40を作成し(453)、これをAOR取得要求メッセージM30の送信元であるクライアントに送信し(454)、このルーチンを終了する。
FIG. 67 shows a
When the SIP
以上の実施例では、暗号化データ通信が終了した時、クライアントCL1a側から切断要求を発行した場合の通信シーケンスについて説明したが、サーバSV1bが所属するSIPプロキシPRbも、クライアント側のSIPプロキシPRaと同様の機能を備えているため、サーバSV1bから切断要求が発行された場合でも、メッセージの送信方向が逆になるだけで、結果的には実施例と同様の手順が実行されることになる。 In the above embodiment, the communication sequence in the case where the disconnection request is issued from the client CL1a side when the encrypted data communication is completed has been described. However, the SIP proxy PRb to which the server SV1b belongs is also different from the SIP proxy PRa on the client side. Since the same function is provided, even when a disconnection request is issued from the server SV1b, only the message transmission direction is reversed, and as a result, the same procedure as in the embodiment is executed.
また、実施例では、第1ドメインに所属するクライアントCL1aから、第2ドメインに所属するサーバSV1bに接続要求を発行した場合の通信シーケンスについて説明したが、第1実施例において、クライアントCL1aが、サーバSV1bとの通信を終了した後、別のサーバ、例えば、サーバSV2b(またはサーバSV1a)と通信するアプリケーションを起動した場合、クライアントCL1aとレジストラRGaとの間、およびクライアントCL1aとSIPプロキシPRaとの間では、既に暗号化通信のための条件設定が完了した状態にある。従って、アプリケーションプログラムからデータの送信要求が発生した時、TLS部52Cは、SIPサーバSIPaとの間でのTLSネゴシェーションを省略して、SIPメッセージ処理部53Cから受信したAOR取得要求メッセージ、または接続要求メッセージを直ちに暗号化して、ネットワークNW1に送信することが可能となる。
In the embodiment, the communication sequence when the connection request is issued from the client CL1a belonging to the first domain to the server SV1b belonging to the second domain has been described. In the first embodiment, the client CL1a After ending communication with SV1b, when an application that communicates with another server, for example, server SV2b (or server SV1a) is started, between client CL1a and registrar RGa, and between client CL1a and SIP proxy PRa Then, the condition setting for encrypted communication has already been completed. Therefore, when a data transmission request is generated from the application program, the
尚、実施例では、SIPメッセージのRequest−URIやToヘッダにIPアドレスを適用する時、例えば、図15や図51の「sips:192.0.2.4」のように記述した。この場合、SIPメッセージを受信したSIPプロキシ、レジストラまたはサーバ側では、着目フィールドにおける「sips:」に続く文字列が、3桁以下の数字をドットで区切ったIPアドレス表記となっているか否かによって、SIP−URI記述かIPアドレス記述かを判定できる。SIP−URI記述かIPアドレス記述かを判定を確実にするためは、例えば、「sips:192.0.2.4;id=ipv4」のように、URIパラメータを使用して、AOR解決を必要とするSIP−URIであることを明示するようにしてもよい。また、例えば、「ipv4:192.0.2.4」のように、着目フィールドでIPv4(またはIPv6)というスキームを検出した場合は、その後にIPアドレスが記述されているものと約束してもよい。 In the embodiment, when the IP address is applied to the Request-URI or To header of the SIP message, for example, “sips: 192.0.2.4” in FIGS. 15 and 51 is described. In this case, on the SIP proxy, registrar, or server side that received the SIP message, whether or not the character string following “sips:” in the field of interest is represented by an IP address that is a three-digit number separated by dots. It can be determined whether the description is an SIP-URI description or an IP address description. In order to ensure the determination of the SIP-URI description or the IP address description, for example, SIP- that requires AOR resolution using a URI parameter, such as “sips: 192.0.2.4; id = ipv4”. You may make it show clearly that it is URI. Further, for example, when a scheme called IPv4 (or IPv6) is detected in the field of interest, such as “ipv4: 192.0.2.4”, it may be promised that an IP address is described thereafter.
CL1a〜CL2b:クライアント、SV1a〜SV2b:サーバ、
SIPa、SIPb:SIPサーバ、PRa、PRb:SIPプロキシ、
RGa、RGb:レジストラ、LSV:ロケーションサーバ、
20:ネットワークインタフェースカード部、30:TCP/IPレイヤ部、
31:IPsecエンジン、40:アプリケーションソフト、50:鍵管理プロセス、
51:SP/SA制御部、52:TLS部、53:SIPメッセージ処理部、
60:レジストラ処理部。
CL1a to CL2b: client, SV1a to SV2b: server,
SIPa, SIPb: SIP server, PRa, PRb: SIP proxy,
RGa, RGb: registrar, LSV: location server,
20: Network interface card part, 30: TCP / IP layer part,
31: IPsec engine, 40: Application software, 50: Key management process,
51: SP / SA control unit, 52: TLS unit, 53: SIP message processing unit,
60: Registrar processing unit.
Claims (21)
上記第1の通信装置が、上記第2の通信装置をIPアドレスで指定して、上記セッション管理サーバに上記第2の通信装置の特定識別子を問い合わせ、
上記セッション管理サーバが、上記問い合わせに用いられたIPアドレスに対応する上記第2の通信装置の特定識別子を上記第1の通信装置に通知し、
上記第1の通信装置が、上記セッション管理サーバから通知された上記特定識別子で上記第2の通信装置を指定して、上記セッション管理サーバに上記第2の通信装置とのセッションの設定を要求し、当該セッションの設定後、上記第2の通信装置をIPアドレスで指定して、該第2の通信装置と通信することを特徴とする通信システム。 In a communication system in which a session management server manages a session between a first communication device and a second communication device in accordance with a session management protocol that designates the communication device with a specific identifier.
The first communication device designates the second communication device by an IP address, inquires the session management server for a specific identifier of the second communication device,
The session management server notifies the first communication device of the specific identifier of the second communication device corresponding to the IP address used for the inquiry,
The first communication device designates the second communication device with the specific identifier notified from the session management server, and requests the session management server to set a session with the second communication device. A communication system, wherein after the session is set, the second communication device is designated by an IP address and communicated with the second communication device.
前記プロトコルがSIP(Session Initiation Protocol)、前記特定識別子がSIP−URI(Uniform Resource Identifier)であることを特徴とする通信システム。 The communication system according to claim 1,
A communication system, wherein the protocol is SIP (Session Initiation Protocol) and the specific identifier is SIP-URI (Uniform Resource Identifier).
前記第1の通信装置が、メッセージ種類がSIP−URIの要求メッセージであることを示す情報を設定したSIPメッセージを送信することによって、前記セッション管理サーバに前記第2の通信装置のSIP−URIを問い合わせ、
上記セッション管理サーバが、SIP−URIの要求メッセージである上記SIPメッセージを受信すると、受信メッセージから問い合わせに用いられたIPアドレスを抽出し、該IPアドレスに対応するSIP−URIを含むSIPメッセージを前記第1の通信装置に返信することを特徴とする通信システム。 The communication system according to claim 2,
The first communication device transmits an SIP message in which information indicating that the message type is a request message of the SIP-URI is set, and thereby the SIP-URI of the second communication device is transmitted to the session management server. Inquiry,
When the session management server receives the SIP message which is a SIP-URI request message, the session management server extracts the IP address used for the inquiry from the received message, and sends the SIP message including the SIP-URI corresponding to the IP address to the SIP message. A communication system characterized in that a reply is made to the first communication device.
セッションの設定後、前記第1の通信装置と前記第2の通信装置が、前記セッション管理サーバを介さずに通信することを特徴とする通信システム。 The communication system according to claim 1,
A communication system, wherein after the session is set, the first communication device and the second communication device communicate without going through the session management server.
前記第1の通信装置が、前記セッション管理サーバを介して前記セッションの設定を行うことによって、前記第2の通信装置と暗号化通信するためのパラメータ情報を交換し、セッションの設定後、上記パラメータ情報に基づいて、前記第2の通信装置へ送信する情報を暗号化することを特徴とする通信システム。 The communication system according to claim 1,
The first communication device exchanges parameter information for encrypted communication with the second communication device by setting the session via the session management server. After setting the session, the parameter A communication system, wherein information to be transmitted to the second communication device is encrypted based on the information.
前記パラメータ情報には、暗号化通信に適用する暗号化方式や暗号鍵の情報が含まれることを特徴とする通信システム。 The communication system according to claim 5, wherein
The communication system characterized in that the parameter information includes information on an encryption method and an encryption key applied to encrypted communication.
前記第1の通信装置が、IPsec(Internet Protocol Security)に従って、前記第2の通信装置への送信情報を暗号化することを特徴とする通信システム。 The communication system according to claim 5, wherein
A communication system, wherein the first communication device encrypts transmission information to the second communication device in accordance with IPsec (Internet Protocol Security).
前記第1の通信装置と前記セッション管理サーバが、TLS(Transport Layer Security)によって、セッション設定のために相互に送信する情報を暗号化することを特徴とする通信システム。 The communication system according to claim 5, wherein
A communication system, wherein the first communication device and the session management server encrypt information transmitted to each other for session setting by TLS (Transport Layer Security).
通信装置のIPアドレスとSIP−URIとの対応関係を記憶したロケーションサーバを有し、
前記セッション管理サーバが、上記ロケーションサーバに、前記第1の通信装置からの問い合わせに用いられたIPアドレスでSIP−URIを問い合わせることによって、前記第2の通信装置のSIP−URIを取得し、該SIP−URIを前記第1の通信装置に通知することを特徴とする通信システム。 The communication system according to claim 2,
A location server storing the correspondence between the IP address of the communication device and the SIP-URI;
The session management server obtains the SIP-URI of the second communication device by inquiring the location server of the SIP-URI with the IP address used for the inquiry from the first communication device, A communication system, wherein a SIP-URI is notified to the first communication device.
上記第1の通信装置が、上記第2の通信装置をIPアドレスで指定して、上記セッション管理サーバに上記第2の通信装置とのセッションの設定を要求し、
上記セッション管理サーバが、上記設定要求で指定されたIPアドレスに対応する上記第2の通信装置の特定識別子を取得し、該特定識別子で上記第2の通信装置を指定した形で、上記セッションの設定要求を上記第2の通信装置に向けて送信し、
当該セッションの設定後、上記第1の通信装置が、上記第2の通信装置をIPアドレスで指定して、上記第2の通信装置と通信することを特徴とする通信システム。 In a communication system having a session management server for managing a session between a first communication device and a second communication device in accordance with a session management protocol for designating a communication device with a specific identifier,
The first communication device designates the second communication device by an IP address, requests the session management server to set a session with the second communication device,
The session management server acquires the specific identifier of the second communication device corresponding to the IP address specified in the setting request, and specifies the second communication device with the specific identifier, Send a setting request to the second communication device,
A communication system, wherein after the session is set, the first communication device designates the second communication device by an IP address and communicates with the second communication device.
前記プロトコルがSIP(Session Initiation Protocol)、前記特定識別子がSIP−URI(Uniform Resource Identifier)であることを特徴とする通信システム。 The communication system according to claim 10, wherein
A communication system, wherein the protocol is SIP (Session Initiation Protocol) and the specific identifier is SIP-URI (Uniform Resource Identifier).
前記第1の通信装置が、SIPのINVITEメッセージによって前記第2の通信装置とのセッションの設定を要求し、
前記セッション管理サーバが、上記第1の通信装置から受信したINVITEメッセージの中で通信相手を指定する部分に、IPアドレスとSIP−URIのいずれが設定されているかを確認し、IPアドレスが設定されていた場合、当該IPアドレスに対応するSIP−URIを取得することを特徴とする通信システム。 The communication system according to claim 11,
The first communication device requests setting of a session with the second communication device by a SIP INVITE message,
The session management server confirms whether an IP address or a SIP-URI is set in the portion for specifying the communication partner in the INVITE message received from the first communication device, and the IP address is set. If it is, a communication system characterized by obtaining a SIP-URI corresponding to the IP address.
前記第1の通信装置が、前記INVITEメッセージのRequest−URIにIPアドレスを設定して前記第2の通信装置とのセッションの設定を要求し、
前記セッション管理サーバが、前記INVITEメッセージのRequest−URIに設定されたIPアドレスを前記第2の通信装置のSIP−URIに置き換えることを特徴とする通信システム。 The communication system according to claim 12,
The first communication device sets an IP address in the Request-URI of the INVITE message, and requests setting of a session with the second communication device;
The communication system, wherein the session management server replaces the IP address set in the Request-URI of the INVITE message with the SIP-URI of the second communication device.
通信装置のIPアドレスとSIP−URIの対応関係を記憶するロケーションサーバを有し、
前記セッション管理サーバが、前記第1の通信装置からのセッション設定要求で指定されたIPアドレスで上記ロケーションサーバにSIP−URIを問い合わせることによって、前記第2の通信装置のSIP−URIを取得することを特徴とする通信システム。 The communication system according to claim 11,
A location server that stores the correspondence between the IP address of the communication device and the SIP-URI;
The session management server obtains the SIP-URI of the second communication device by inquiring of the location server for the SIP-URI with the IP address specified in the session setting request from the first communication device. A communication system characterized by the above.
前記第1の通信装置が、前記第2の通信装置との通信終了時に、上記第2の通信装置をIPアドレスで指定して前記セッション管理サーバに前記第2の通信装置とのセッションの終了を要求し、
前記セッション管理サーバが、上記終了要求で指定されたIPアドレスに対応する特定識別子で上記第2の通信装置を指定して、上記セッションの終了要求を上記第2の通信装置に向けて送信することを特徴とする通信システム。 The communication system according to claim 10, wherein
When the first communication device ends communication with the second communication device, the second communication device is designated by an IP address, and the session management server terminates the session with the second communication device. Request,
The session management server designates the second communication device with a specific identifier corresponding to the IP address designated in the termination request, and transmits the session termination request to the second communication device. A communication system characterized by the above.
前記第1の通信装置が、SIPのBYEメッセージにより前記第2の通信装置とのセッションの終了を要求し、
前記セッション管理サーバが、上記第1の通信装置から受信したBYEメッセージの中で通信相手を指定する部分に、IPアドレスとSIP−URIのいずれが設定されているかを確認し、IPアドレスが設定されていた場合、該IPアドレスに対応するSIP−URIで上記第2の通信装置を指定することを特徴とする通信システム。 The communication system according to claim 11,
The first communication device requests termination of a session with the second communication device by a SIP BYE message,
The session management server confirms whether the IP address or SIP-URI is set in the part that specifies the communication partner in the BYE message received from the first communication device, and the IP address is set. If so, the second communication device is designated by a SIP-URI corresponding to the IP address.
前記BYEメッセージの中で通信相手を指定する部分が、Request−URIであり、
前記セッション管理サーバが、上記BYEメッセージのRequest−URIに設定されたIPアドレスを前記第2の通信装置のSIP−URIに置き換えることを特徴とする通信システム。 The communication system according to claim 16,
The part that specifies the communication partner in the BYE message is a Request-URI,
The session management server replaces the IP address set in the Request-URI of the BYE message with the SIP-URI of the second communication device.
上記第1の通信装置が、上記第2の通信装置をIPアドレスで指定して、上記第2の通信装置に特定識別子を問い合わせ、
上記第2の通信装置が、上記問い合わせに応答して自装置の特定識別子を上記第1の通信装置に通知し、
上記第1の通信装置が、上記第2の通信装置から通知された上記特定識別子で該第2の通信装置を指定して、上記セッション管理サーバに上記第2の通信装置とのセッションの設定を要求し、
セッションの設定後、上記第1の通信装置が、上記第2の通信装置をIPアドレスで指定して、上記第2の通信装置と通信することを特徴とする通信システム。 In a communication system having a session management server for managing a session between a first communication device and a second communication device in accordance with a session management protocol for designating a communication device with a specific identifier,
The first communication device designates the second communication device by an IP address, inquires the second communication device for a specific identifier,
The second communication device notifies the first communication device of the specific identifier of the own device in response to the inquiry,
The first communication device designates the second communication device by the specific identifier notified from the second communication device, and sets a session with the second communication device to the session management server. Request,
A communication system, wherein after the session is set, the first communication device designates the second communication device by an IP address and communicates with the second communication device.
前記プロトコルがSIP(Session Initiation Protocol)、前記特定識別子がSIP−URI(Uniform Resource Identifier)であることを特徴とする通信システム。 The communication system according to claim 18,
A communication system, wherein the protocol is SIP (Session Initiation Protocol) and the specific identifier is SIP-URI (Uniform Resource Identifier).
前記第1の通信装置が、メッセージ種類がSIP−URIを要求するメッセージであることを示す情報を設定したSIPメッセージを前記第2の通信装置へ送信することによって、該第2の通信装置にSIP−URIを問い合わせ、
上記第2の通信装置が、SIP−URIの要求メッセージである上記SIPメッセージの受信に応答して、自装置のSIP−URIを含むSIPメッセージを上記第1の通信装置に返信することを特徴とする通信システム。 The communication system according to claim 19,
The first communication device transmits a SIP message in which information indicating that the message type is a message requesting SIP-URI is set to the second communication device. -Query the URI,
The second communication device returns a SIP message including its own SIP-URI to the first communication device in response to reception of the SIP message, which is a SIP-URI request message. Communication system.
前記第1の通信装置が、前記SIP−URIを要求するSIPメッセージのRequest−URIに前記第2の通信装置のIPアドレスを設定して、該第2の通信装置にSIP−URIを問い合わせることを特徴とする通信システム。
The communication system according to claim 20,
The first communication device sets the IP address of the second communication device in the Request-URI of the SIP message requesting the SIP-URI, and makes an inquiry about the SIP-URI to the second communication device. A featured communication system.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006214395A JP3914959B2 (en) | 2006-08-07 | 2006-08-07 | Data communication method and system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2006214395A JP3914959B2 (en) | 2006-08-07 | 2006-08-07 | Data communication method and system |
Related Parent Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2004310455A Division JP3859667B2 (en) | 2004-10-26 | 2004-10-26 | Data communication method and system |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006278500A Division JP4551381B2 (en) | 2006-10-12 | 2006-10-12 | Data communication method and system |
Publications (2)
Publication Number | Publication Date |
---|---|
JP2006311618A JP2006311618A (en) | 2006-11-09 |
JP3914959B2 true JP3914959B2 (en) | 2007-05-16 |
Family
ID=37477827
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2006214395A Expired - Fee Related JP3914959B2 (en) | 2006-08-07 | 2006-08-07 | Data communication method and system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP3914959B2 (en) |
-
2006
- 2006-08-07 JP JP2006214395A patent/JP3914959B2/en not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2006311618A (en) | 2006-11-09 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP3859667B2 (en) | Data communication method and system | |
JP4635855B2 (en) | Data communication method and system | |
JP4561671B2 (en) | Data communication method and system | |
JP4101839B2 (en) | Session control server and communication system | |
JP4959750B2 (en) | Dynamic connection to multiple origin servers with transcoding proxy | |
JP4047303B2 (en) | Providing device, providing program, and providing method | |
JP4656536B2 (en) | Relay server and relay communication system | |
JP4722478B2 (en) | Integration of security parameters for related streaming protocols | |
EP1758324A1 (en) | The session initial protocol identification method | |
US20100138660A1 (en) | Secure communication session setup | |
JP2002082907A (en) | Security function substitution method in data communication and its system, and recording medium | |
JP5012173B2 (en) | Encryption communication processing method and encryption communication processing apparatus | |
JP2005160005A (en) | Building method of encryption communication channel between terminals, device for it, and program | |
JP2005295038A (en) | Providing apparatus, providing method, communication apparatus, communication method, and program | |
JP2005236728A (en) | Server apparatus, request issuing the apparatus, request accepting apparatus, communications system and communication method | |
JP4551381B2 (en) | Data communication method and system | |
JP3914959B2 (en) | Data communication method and system | |
JP2006019824A (en) | Secure communication system, management apparatus, and communication terminal | |
Camarillo | Combining the Session Initiation Protocol (SIP) and the Host Identity Protocol (HIP) | |
JP4789980B2 (en) | Tunnel communication system and control device | |
KR20070017329A (en) | Method and system for proxy-based secure end-to-end tcp/ip communications | |
JP2005229435A (en) | Terminal with resolver separately from application, and resolver program | |
JP2005303784A (en) | Server device, request issuing equipment, request accepting equipment, communication system, communication method, and program | |
JP2008136248A (en) | Session control server, transmission device, communication system and method, program and recording medium | |
Jiang | Secure SIP between IPv4 endpoints and IPv6 endpoints |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20060807 |
|
A871 | Explanation of circumstances concerning accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A871 Effective date: 20060807 |
|
A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060829 |
|
A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20061012 |
|
A975 | Report on accelerated examination |
Free format text: JAPANESE INTERMEDIATE CODE: A971005 Effective date: 20060823 |
|
TRDD | Decision of grant or rejection written | ||
A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20070116 |
|
A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20070205 |
|
R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100209 Year of fee payment: 3 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110209 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110209 Year of fee payment: 4 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120209 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120209 Year of fee payment: 5 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130209 Year of fee payment: 6 |
|
FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130209 Year of fee payment: 6 |
|
LAPS | Cancellation because of no payment of annual fees |