JP3914959B2 - Data communication method and system - Google Patents

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.

  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.

  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.

  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.

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 engine 31 is equipped as part of TCP / IP layer software, and includes an SPDB (Security Policy Data Base) 32 that stores determination information (SP information) on whether or not to apply encryption to a transmission packet, and an encryption And a security association data base (SADB) 33 that stores information (SA information) such as an encryption method and an encryption key applied to encrypted communication.

  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.

  When detecting an IP packet transmission request issued by the application layer 40 program, the IPsec engine 31 verifies the header information of the IP packet with the SPDB 32 and determines whether IPsec should be applied to the IP packet. The IPsec engine 31 that has determined that IPsec is applied to the IP packet acquires SA (Security Association) information to be applied to the IP packet from the SADB 33. Here, if the SA information corresponding to the IP packet is not registered in SADB 33, the IPsec engine 31 communicates with the communication partner (connection destination server) with respect to the IKE (key management) process 50. The exchange of SA information including the encryption key is requested.

  The IKE process 50 exchanges SA information with a communication partner in accordance with ISAKMP (Internet Security Association and Key Management Protocol) described in RFC 2408 (Non-Patent Document 4). In ISAKMP, after forming an encrypted communication path with a communication partner, an authentication procedure for confirming whether the partner device is a genuine device permitted to communicate is executed. When the IKE process 50 confirms that the partner device is a genuine device that is permitted to perform encrypted communication by the above authentication procedure, the IKE process 50 starts exchanging SA information with the partner device via the communication path set by ISAKMP. To do. When the exchange of SA information with the communication partner is completed, the IKE process 50 notifies the IPsec engine 31 of SA information and corresponding SP (Security Policy) information.

  The IPsec engine 31 stores the SP information and SA information notified from the IKE process 50 in the SPDB 32 and SADB 33, respectively, and then encrypts the IP packet according to the SA information and transmits it to the communication partner. When receiving the encrypted IP packet, the server as the communication partner decrypts the received IP packet according to the SA information agreed by the IKE process, and notifies the server-side application layer of the reception of the IP packet.

  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 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.

RFC2401: Security Architecture for the Internet Protocol RFC2246: The TLS Protocol Version 1.0 RFC2409: The Internet Key Exchange (IKE) RFC2408: Internet Security Association and Key Management Protocol (ISAKMP) RFC3261: SIP: Session Initiation Protocol RFC3263: Session Initiation Protocol (SIP): Locating SIP Servers RFC2327: SDP: Session Description Protocol

  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.

  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.

  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).

  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).

  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.

  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.

  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.

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.

  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.

  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.

  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.

  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.

  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.

  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).

  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.

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.

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.

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.

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).

  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.

  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.

  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. .

  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 AOR 61 of the client or server and the IP address 62. In response to the location data search request from the SIP server, the location server LSV searches the location service table 60 for an AOR (or IP address) corresponding to the IP address (or AOR) designated as the search key, The search result is returned to the requesting SIP server.

FIG. 6 shows a hardware configuration of the SIP proxy PRa.
The SIP proxy PRa includes a processor (CPU) 11, a memory 12 and a hard disk 13 for storing various software and data executed by the processor, a network interface 14 for connection to a network NW1 (NW2), and an input / output device. These elements are interconnected by an internal bus 16. The SIP proxy PRb, registrar RGa, RGb, clients CL1a to CL2b, and servers SV1a to SV2b are basically composed of the same components as the SIP proxy PRa shown in FIG.

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.

  The software of the client CL1a includes a network interface card unit (NIC) 20C, a TCP / IP layer unit 30C including an IPsec engine 31C having an IPsec encryption / decryption function, an application program 40C, and a key management process unit 50C. Consists of. In the first embodiment, the key management process unit 50C includes an SP / SA (Security Policy / Security Association) control unit 51C, a TLS (Transport Layer Security) unit 52C, and a SIP message processing unit 53C. It is said.

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 / IP layer unit 30S including an IPsec engine 31S having an IPsec encryption / decryption function, an application program 40S, and a key management process unit 50S. The key management process unit 50S includes an SP / SA control unit 51S, a TLS unit 52S, and a SIP message processing unit 53S.

  The application program 40C of the client CL1a and the application program 40S of the server SV1b communicate encrypted data by using the IPsec encryption / decryption functions of the IPsec engines 31C and 31S provided respectively. On the other hand, the SIP message processing unit 53C of the client CL1a uses the message encryption / decryption function of the TLS unit included in each of the SIP message processing units of the SIP server SIPa (SIP proxy PRa, registrar RGa) described later. Then, the encrypted SIP message is communicated. Similarly, the SIP message processing unit 53S of the server SV1b also uses the message encryption / decryption function of the TLS unit included in each SIP message processing unit of the SIP server SIPa (SIP proxy PRa, registrar RGa). Then, the encrypted SIP message is communicated.

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 / IP layer unit 30P, and a key management process unit 50P. The key management process unit 50P includes the TLS unit 52P and the SIP message processing unit. 53P. The SIP message processing unit 53P has a SIP-URL (AOR) search function 54 described later. The SIP message processing unit 53P of the SIP proxy PRa uses the message encryption / decryption function of the TLS unit 52P to manage the clients, servers, and other SIP proxies that belong to the domain under management. For example, the encrypted message is communicated with PRb.

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 / IP layer unit 30R, a TLS unit 52R having a message encryption / decryption function, a SIP message processing unit 53R, and a registrar processing unit. It consists of 60R. Upon receiving the AOR acquisition request issued by the client or the AOR acquisition request issued by the SIP proxy PRa, the SIP message processing unit 53R requests the registrar processing unit 60R to search for location data. The registrar processing unit 60R accesses the location service DB provided in the location server LSV in response to a request from the SIP message processing unit 53R. Note that encryption is not applied to communication between the registrar RGa and the SIP proxy PRa.

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.

  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.

  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.

  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 “sv1@192.0.2.4” 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.

  When the registrar RGb receives the location registration request message M1, the request source IP address indicated by the request source URI “sv1@bbb.com” 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 “sv1@192.0.2.4” 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

  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.

  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 “cl1@aaa.com” of the client CL1a is set in the From header.

  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.

  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 “sv1@bbb.com” of the server SV1b retrieved from the location service table 60 are described.

  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.

  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 “sv1@bbb.com” of the server SV1b as the message destination. Further, as header information, a Via header indicating the SIP-URI of the SIP message processing unit 53C in the client CL1a, a To header including the SIP-URI “sv1@bbb.com” of the server SV1b, and a SIP-URI “cl1 @ of the client CL1a A From header including “aaa.com”, a Content-Type header, a Content-Length header, and other information. The Content-Type header indicates an application program related to the body part M5-2, and the Content-Length header indicates the length of the body part M5-2.

  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 proposal payload 91 indicating the identification information of the encryption protocol, the transform payload 92 indicating the transform identification information, the key exchange payload 93, the first ID payload 94 indicating the identification information of the request source, and the identification information of the connection destination Is included.

  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 first ID payload 94 indicates the IP address of the request source client CL1a, and the ID data of the second ID payload 95 indicates the IP address of the connection destination server SV1b.

  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.

  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.

  When the SIP proxy PRb receives the connection request message M7, the SIP proxy PRb extracts the destination URI “SV1@aaa.com” 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 “sv1@192.0.2.4”) 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 “sv1@192.0.2.4” after transmitting the message M8 being connected shown in FIG. The shading (S11) is executed.

  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 “sv1@192.0.2.4”, 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.

  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.

  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.

  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 SADB 33C. After that, a connection confirmation message M13 shown in FIG. 27 is transmitted to the SIP proxy PRa. The connection confirmation message M13 includes the message type “ACK” and the SIP-URI of the server SV1b as the request-URI on the start line, and includes the Via, To, From, Call-ID, CSec, and Route headers as header information. The message body part is omitted. In the Route header, a URI value extracted from the Record-Route header of the connection response message M12 is set.

  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.

  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 SADB 33C, and transmits this in the IP packet format. The server SV1b can decrypt the received data from the client CL1a according to the SA information registered in the SADB 33V, encrypt the transmission data to the client CL1a according to the SA information, and transmit it in the IP packet format.

  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.

  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.

  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.

  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.

  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.

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 flowchart 100 of a control operation executed by the SP / SA controller 51C in response to the encryption key exchange request issued by the IPsec engine 31 in the client CL1a.

  Upon detecting an IP packet transmission request from the application 40C, the IPsec engine 31C of the client CL1a refers to an SPDB (Security Policy Data Base) 32C to determine whether or not the IPsec encryption needs to be applied to the IP packet. When it is determined that IPsec encryption should be applied, the IPsec engine 31C searches SADB (Security Association Data Base) 33C for SA (Security Association) information such as an encryption key to be applied to the IP packet. Here, when the SA information to be applied to the IP packet is not registered in the SADB, the IPsec engine 31C requests the key management process 50C to exchange encryption parameters (key exchange) with the communication partner.

  In this embodiment, the SP / SA control unit 51C processes the key exchange request from the IPsec engine 31C. When the SP / SA control unit 51C receives the key exchange request, based on the TCP / IP communication parameter indicated by the key exchange request and the available SA information managed by the SP / SA control unit 51C, FIG. Is created (step 101), the connection request message body part M5-2 is passed to the SIP message processing unit 53C (102), and a connection response is received from the SIP message processing unit 53C. Waiting for reception of the message body part (103).

  Upon receiving the connection response message body M10-2 illustrated in FIG. 24 from the SIP message processing unit 53C, the SP / SA control unit 51C analyzes the received connection response message body and uses it for the current IPsec communication. SA information to be determined is determined (104), and the SA information to be set in the SADB 33C is notified to the IPsec engine 31C (105).

FIG. 39 (FIGS. 39A and 39B) shows a flowchart 110 of the control operation executed by the SIP message processing unit 53C when the body part of the connection request message is received from the SP / SA control unit 51C.
When the SIP message processing unit 53C receives the body part of the connection request message from the SP / SA control unit 51C, the SIP message processing unit 53C manages the IP address of the connection destination server indicated by the ID data of the second ID payload. The AOR acquisition request message M3 illustrated in FIG. 15 is created from the communication control parameters (step 111), and the message is sent to the same domain as the client CL1a via the TSL unit 52C, the TCP / IP unit 30C, and the NIC unit 20C. It is transmitted to the SIP server SIPa (Registrar RGa) located (112). At this time, the TLS unit 52C executes TLS negotiation (S5 in FIG. 11) with the registrar RGa, and then sends the TLS encrypted AOR acquisition request message M3 to the TCP / IP unit 30C and the NIC unit 20C. To the registrar RGa. The TCP / IP unit 30C adds the IP header H1 including the destination IP address addressed to the SIP server SV1 and the UDP / TCP header H2, and sends the AOR acquisition request message M3 to the network NW1 in the IP packet format.

  The SIP message processing unit 53C waits for an AOR acquisition response message from the registrar RGa (113). When receiving the AOR acquisition response message, the SIP message processing unit 53C analyzes the received message (114) and is assigned to the connection destination server from the AOR header. A SIP-URI in AOR format is extracted (115). Thereafter, the SIP message processing unit 53C applies the SIP-URI to the start line and the To header, and includes the header unit M5-1 and the body unit M5-2 received from the SP / SA control unit 51C. The connection request message M5 exemplified in (1) is created (116).

  The SIP message processing unit 53C transmits the connection request message to the SIP proxy PRa of the SIP server SIPa via the TSL unit 52C, the TCP / IP unit 30C, and the NIC unit 20C (117), and a response from the SIP proxy PRa (118). When the connected message M6 is received from the SIP proxy PRa, the connected message processing (119) is executed, and then the next response from the SIP proxy PRa is awaited.

  Upon receiving the connection response message M12 from the SIP proxy PRa, the SIP message processing unit 53C analyzes the received message (120), and converts the connection response message body M12-2 illustrated in FIG. 24 extracted from the received message into the SP / SA. It is passed to the control unit 51C (121). Thereafter, the SIP message processing unit 53C creates the connection confirmation message M13 illustrated in FIG. 27, and transmits it to the SIP proxy PRa via the TSL unit 52C, the TCP / IP unit 30C, and the NIC unit 20C ( 122) This routine is terminated.

FIG. 40 shows a flowchart 200 of a control operation executed by the SIP message processing unit 53R of the registrar RGa when the AOR acquisition request message M3 is received.
The SIP message processing unit 53R of the registrar RGa analyzes the received AOR acquisition request message M3 (step 201), and creates a location data search query using the IP address of the connection destination server SV1b indicated by the To header as a search key (202 The search query is transmitted to the location server LSV via the registrar processing unit 60R (203), and a response from the location server is waited (204).

  When the SIP message processing unit 53R receives the location data from the location server LSV via the registrar processing unit 60R, the SIP message processing unit 53R creates the AOR acquisition response message M4 illustrated in FIG. 16 including the SIP-URI indicated by the received data as an AOR header. (205) The message M4 is transmitted to the transmission source of the AOR acquisition request message M3 (in this example, the client CL1a) via the TCP / IP unit 30R and the NIC unit 20R (206), and this routine is terminated.

41 (FIGS. 41A to 41D) shows a flowchart 300 of a control operation executed by the SIP message processing unit 53P of the SIP proxy PRa when the connection request message M5 is received from the client CL1a.
When the SIP message processing unit 53P of the SIP proxy PRa receives the connection request message M5 from the client CL1a, it analyzes the received message (step 301), and checks the Request-URI described in the start line of the received message ( 302), the transfer destination of the received message is determined from the domain name indicated by the Request-URI (303).

  When it is determined that the transfer destination of the received message belongs to another domain, the SIP message processing unit 53P performs a DNS search (NAPTR search + SRV search + A search) or the like in the SIP server ( SIP proxy is determined (304). In the example shown in FIG. 11, the DNS search reveals that the transfer destination of the connection request message M5 is the SIP proxy PRb. In this case, the SIP message processing unit 53P transmits the connecting message M6 illustrated in FIG. 19 to the client CL1a that is the transmission source of the connection request message M5 via the TLS unit 52P, the TCP / IP unit 30P, and the NIC unit 20P. After (305), the connection request message M7 in which a new Via header is added to the connection request message M5 is transferred to the SIP proxy PRb (306), and a response from the SIP proxy PRb is waited (307).

  Upon receiving the connected message M8 from the SIP proxy PRb, the SIP message processing unit 53P waits for the next response from the SIP proxy PRb after executing the connected message processing (308). Upon receiving the connection response message M11 from the SIP proxy PRb, the SIP message processing unit 53P analyzes the received message (309), removes the Via header including its own SIP-URI from the received message, and connects as the connection response message M12. Transfer to the request source (client CL1a) (310). Thereafter, the SIP message processing unit 53P waits for a response from the connection request source (client CL1a) (311). Upon receiving the connection confirmation message M13, the SIP message processing unit 53P analyzes the received message (312), adds a new Via header including its own SIP-URI to the received message, and uses the SIP proxy as the connection confirmation message M13. The data is transferred to PRb (313), and this routine is terminated.

  When it is determined in the determination step 303 that the transfer destination of the connection request message received from the client terminal CL1a belongs to the same domain as the SIP proxy PRa, for example, the server SV1a (or SV2a), the SIP message The processing unit 53P creates a location data (IP address) search query using the SIP-URI indicated by the Request-URI of the received message as a search key (315), and transmits the location data search query to the location server LSV ( 316) and wait for location service response (317).

  Upon receiving the location data from the location server LSV, the SIP message processing unit 53P applies the IP address of the connection destination server indicated by the location data to the destination IP address, and transmits a connection request message to the network NW1 in the IP packet format. (318), and wait for a response from the connection destination server (319). A new Via header including the SIP-URI of the SIP proxy PRa is added to the connection request message.

  Upon receiving the connection response message from the connection destination server, the SIP message processing unit 53P analyzes the received message (320), and transfers the connection response message in a form from which the Via header corresponding to itself is removed to the connection request source ( 321), and waits for a response from the connection request source (client CL1a) (322). When the SIP message processing unit 53P receives the connection confirmation message from the connection request source, the SIP message processing unit 53P analyzes the received message (323), and transfers the connection confirmation message with a new Via header to the connection destination server (324). This routine is terminated.

42 (FIGS. 42A and 42B) shows a flowchart 400 of a control operation executed when the SIP message processing unit 53S of the connection destination server SV1b receives the connection request message M9 from the SIP proxy PRb.
The connection request message M9 transmitted from the SIP proxy PRb to the connection destination server SV1b is decrypted by the TLS unit 52S and then input to the SIP message processing unit 53S. Upon receiving the connection request message M9, the SIP message processing unit 53S analyzes the received message (step 401), and passes the connection request message body M5-2 extracted from the received message to the SP / SA control unit 51S (402). Then, it waits for a response from the SP / SA control unit 51S (403).

  When the SIP message processing unit 53S receives the connection response message body M10-2 from the SP / SA control unit 51S, the SIP message processing unit 53S creates the connection response message M11 illustrated in FIG. 25 (404). The SIP message processing unit 53S transfers the connection response message M11 to the SIP proxy PRb via the TLS unit, TCP / IP unit, and NIC unit (405), and waits for a response from the SIP proxy PRb (406). Upon receiving the connection confirmation message M15 from the SIP proxy PRb, the SIP message processing unit 53S analyzes the received message (407), and notifies the SP / SA control unit 51S that the connection confirmation message M15 has been received (408). ), This routine is terminated.

FIG. 43 shows a flowchart 420 showing a control operation executed by the SP / SA control unit 51S of the server SV1b when the connection request message body part M5-2 is received from the SIP message processing unit 53S.
The SP / SA control unit 51S analyzes the connection request message body part M5-2 received from the SIP message processing part 53S (step 421), and SA information described in the connection request message body part M5-2 (FIG. 18). In the example, the SA to be applied to the encrypted communication with the client is selected from the transform payloads 92-1, 92-2), and the body part M10-2 of the connection response message illustrated in FIG. 24 is created ( 422). The SP / SA control unit 51S passes the connection response message body M10-2 to the SIP message processing unit 53S (423), and waits for a response from the SIP message processing unit 53S (424). When the SP / SA control unit 51S receives the connection confirmation message reception notification from the SIP message processing unit 53S, the SP / SA control unit 51S notifies the IPsec engine 31S of SA information to be set in the SADB 33S (425), and ends this routine. To do.

FIG. 44 shows a flowchart 130 of a control operation executed by the SA / SP processing unit 51C in response to the encryption key deletion request issued by the IPsec engine 31C in the client CL1a.
When the user of the client CL1a terminates the application communicating with the server SV1b, an encryption key deletion request is issued from the IPsec engine 31C to the SA / SP control unit 51C. When receiving the encryption key deletion request from the IPsec engine 31C, the SA / SP control unit 51C requests the SIP message processing unit 53C to issue a disconnection request message (131), and waits for a response from the SIP message processing unit 53C ( 132). When the SA / SP control unit 51C receives the disconnection response message from the SIP message processing unit 53C, the SA / SP control unit 51C instructs the IPsec engine 31C to delete the set value of the SADB corresponding to the encryption key deletion request (133). This routine is terminated.

FIG. 45 shows a flowchart 140 of a control operation executed by the SIP message processing unit 53C when a disconnection request message issuance request is received from the SA / SP control unit 51C.
When the SIP message processing unit 53C receives the disconnection request message issuance request from the SA / SP control unit 51C, the SIP message processing unit 53C creates the disconnection request message M20 illustrated in FIG. 30 (step 141), and the TLS unit 52C and the TCP / IP unit 30C. The IP packet of the disconnection request message M20 is transmitted to the SIP server SIPa (SIP proxy PRa) via the IPsec engine 31C and the NIC unit 20C (142).

  The SIP message processing unit 53C waits for a response from the SIP proxy PRa (143). When the disconnecting message M21 is received, the SIP message processing unit 53C executes the disconnecting message processing (144), and then receives the next response from the SIP proxy PRa. wait. When the SIP message processing unit 53C receives the disconnection response message M27 illustrated in FIG. 37 from the SIP proxy PRa, the SIP message processing unit 53C analyzes the received message (145) and notifies the SP / SA control unit 51C of the reception of the disconnection response message (146). ), This routine is terminated.

46 (FIG. 46A, FIG. 46B) shows a flowchart 340 of the control operation executed by the SIP message processing unit 53P of the SIP proxy PRa when the disconnection request message M20 is received from the client.
The SIP message processing unit 53P analyzes the received disconnection request message M20 (step 341), and checks the request-URI of the received message (342). The SIP message processing unit 53P determines the transfer destination of the received message from the domain name described in the Request-URI (343), and when it is determined that the transfer destination belongs to another domain, the DNS search ( The SIP server (SIP proxy) of the transfer destination domain of the received message is determined by NAPTR search + SRV search + A search) (344).

  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 message processing unit 53P sends the disconnecting message M21 illustrated in FIG. 31 to the client CL1a that is the transmission source of the disconnection request message M20 via the TLS unit 52P, the TCP / IP unit 30P, and the NIC unit 20P. After transmission (345), a new Via header is added to the disconnection request message M20, and the disconnection request message M22 from which the Route header corresponding to the SIP proxy PRa is removed is transferred to the SIP proxy PRb (346). Is waited for (347).

  When the SIP message processing unit 53P receives the disconnecting message M23 from the SIP proxy PRb, it executes the disconnecting message processing (348) and then waits for the next response from the SIP proxy PRb. When the SIP message processing unit 53P receives the disconnection response message M26 from the SIP proxy PRb, the SIP message processing unit 53P analyzes the received message (349), removes the Via header including its own SIP-URI from the received message, and disconnects as the disconnection response message M27. The data is transferred to the request source (client CL1a) (350), and this routine is terminated.

  In the determination step 343, if it is determined that the transfer destination of the disconnection request message M20 received from the client terminal CL1a belongs to the same domain as the SIP proxy PRa, the SIP message processing unit 53P A location data (IP address) search query using the SIP-URI indicated by the Request-URI of the search key as a search key is created (351), the search query is transmitted to the location server LSV (352), and a location service response is awaited ( 353).

Upon receiving the location data from the location server LSV, the SIP message processing unit 53P applies the server IP address indicated by the location data to the destination IP address, and transmits the IP packet of the disconnection request message to the network NW1 (354). Wait for a response from the server (355). Note that a new Via header including the SIP-URI of the SIP proxy PRa is added to the disconnection request message.
When receiving the disconnection response message from the destination server of the disconnection request message, the SIP message processing unit 53P analyzes the received message (356), and forwards the disconnection response message with its Via header removed to the disconnection request source ( 357), this routine is terminated.

FIG. 47 shows a flowchart 430 of the control operation executed by the SIP message processing unit 53S of the server SV1b when the disconnection request message M24 is received from the SIP proxy.
When the SIP message processing unit 53S receives the disconnection request message M24 via the TLS unit 52S, the SIP message processing unit 53S analyzes the received message (step 431), and identifies to the SP / SA control unit 51S identification information (for example, communication to be disconnected). , Call-ID) is specified, reception of a disconnection request is notified (432), and a response from the SP / SA control unit 51S is waited (433). When the SIP message processing unit 53S receives the disconnection response from the SP / SA control unit 51S, the SIP message processing unit 53S creates a disconnection response message M25 illustrated in FIG. The data is transferred to the proxy PRb (435), and this routine is finished.

FIG. 48 shows a flowchart 440 of the control operation executed by the SP / SA control unit 51S when notified of the occurrence of a disconnection request from the SIP message processing unit 53S.
The SP / SA controller 51S specifies SA information to be deleted from the SADB 33S based on the notified communication identification information (step 441), and instructs the IPsec engine 31S to delete the SA information (442). End the routine.

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 message processing unit 53C of the client acquires the SIP-URI corresponding to the destination IP address. An AOR acquisition request is issued, and a SIP-URI acquired from the registrar is applied to issue a connection request message addressed to the SIP proxy.

  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 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.

  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 “sv1@bbb.com” 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.

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 “sv1@bbb.com”. Thereafter, the same communication sequence of the first embodiment is executed, and the data communication state between applications (S20) is reached.

  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.

  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 “sv1@192.0.2.4”. The other header information of the header part is the same as the connection request message M5 of the first embodiment shown in FIGS.

  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.

  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.

  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.

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 IPsec engine 31C and the SA / SP control unit 51C of the client CL1a have the same functions as in the first embodiment. FIG. 56 shows a flowchart 110x of a control operation executed by the SIP message processing unit 53C of the client CL1a when the body part of the connection request message is received from the SA / SP control unit 51C in the second embodiment.

  When the SIP message processing unit 53C receives the body part M5-2 of the connection request message from the SP / SA control unit 51C, the SIP message processing unit 53C sets the IP address of the connection destination server indicated by the ID data of the second ID payload to the Request-URI and To of the start line. Applying to the header, the connection request message M5x illustrated in FIG. 51 including the header part M5x-1 and the body part M5-2 received from the SP / SA control part 51C is created (111x).

  The SIP message processing unit 53C transmits the connection request message to the SIP proxy PRa of the SIP server SIPa via the TSL unit 52C, the TCP / IP unit 30C, and the NIC unit 20C (117), and a response from the SIP proxy PRa (118), and when the connected message M6 is received from the SIP proxy PRa, the connected message processing (119) is executed, and then a response from the SIP proxy PRa is further waited.

  Upon receiving the connection response message M12x from the SIP proxy PRa, the SIP message processing unit 53C analyzes the received message (120), and converts the connection response message body M12-2 illustrated in FIG. 24 extracted from the received message into the SP / SA. It is passed to the control unit 51C (121). Thereafter, the SIP message processing unit 53C creates a connection confirmation message M13x, and transmits the message to the SIP proxy PRa via the TSL unit 52C, the TCP / IP unit 30C, and the NIC unit 20C (122). End the routine.

FIG. 57 shows a characteristic part of a flowchart 300x of a control operation executed by the SIP message processing unit 53P of the SIP proxy PRa when the connection request message M5x is received from the client CL1a.
When the SIP message processing unit 53P of the SIP proxy PRa receives the connection request message M5x from the client CL1a, it analyzes the received message (step 301) and checks the Request-URI described in the start line of the received message (302) ), It is determined whether the Request-URI includes a domain name (330).
If the Request-URI includes a domain name, that is, if it is described in the format of “sips: user name @ domain name”, in step 303, the transfer destination of the connection request message is determined from the domain name of the Request-URI. To do.

  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 message processing unit 53R receives the SIP-URI of the connection destination server SV1b as the location data from the location server LSV, the SIP message processing unit 53R applies the SIP-URI and receives the Request-URI of the connection request message M5x received from the client CL1a. Rewrite IP address to SIP-URI, add Via header and Record-Route including own SIP-URI (334), and determine transfer destination of connection request message from request-URI domain name at step 303 . The operations after step 303 are the same as those in the first embodiment described with reference to FIG. 41 (FIGS. 41A to 41D).

FIG. 58 shows a flowchart 140x of a control operation executed by the SIP message processing unit 53C when the client CL1a receives a disconnection request message issuance request from the SA / SP control unit 51C.
When the SIP message processing unit 53C receives a disconnection request message issuance request from the SA / SP control unit 51C, the IP address “sv1@192.0.2.4” of the server SV1b that is currently communicating with the Request-URI and To header of the start line. 54 is generated (step 141x), and the SIP server SIPa (SIP proxy PRa is transmitted via the TLS unit 52C, the IPsec engine 31C of the TCP / IP unit 30C, and the NIC unit 20C. (142).

  The SIP message processing unit 53C waits for a response from the SIP proxy PRa (143). When the disconnecting message M21x is received, the SIP message processing unit 53C executes the disconnecting message processing (144), and then receives the next response from the SIP proxy PRa. wait. Upon receiving the disconnection response message M27x from the SIP proxy PRa, the SIP message processing unit 53C analyzes the received message (145), and notifies the SP / SA control unit 51C that the disconnection response message has been received (146). This routine ends.

FIG. 59 shows a flowchart 340x of a control operation executed by the SIP message processing unit 53P of the SIP proxy PRa when the disconnection request message M20x is received from the client.
The SIP message processing unit 53P analyzes the received disconnection request message M20x (step 341), checks the Request-URI of the received message (342), and determines whether the Request-URI includes a domain name ( 360). If the Request-URI includes a domain name, the transfer destination of the received message is determined from the domain name (343). If the Request-URI does not include a domain name, that is, is described in the “sips: IP address” format, the connection destination server acquired in steps 331 to 333 in FIG. 57 when the connection request message is received The request-URI of the disconnection request message M20x is rewritten (361), and the transfer destination of the received message is determined from the domain name indicated by the request-URI (343). The operations after step 343 are the same as those in the first embodiment described with reference to FIG. 46 (FIGS. 46A to 41C).

  As described above, in the SIP proxy PRa of the second embodiment, the SIP message processing unit 53P, as shown in FIG. 9, converts the IP address indicated by the Request-URI of the received SIP message into the SIP-URI. A feature is that a URI (AOR) search function 54 is provided.

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 message processing unit 53C of the client Cl1a uses the IP address to send a SIP-URI to the destination server. A feature is that a connection request message in a form in which the connection destination domain can be determined from the received message on the SIP proxy side is described by describing the SIP-URI acquired from the inquiry and connection destination server in the Request-URI. Yes.

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 message processing unit 53C of the client CL1a and the SIP message processing unit 53S of the server SV1b have AOR resolution functions 55C and 55S for exchanging SIP-URI request / response messages, respectively. Provided that the SIP message processing unit 53S of the server SV1b is provided with a location table 70 referred to by the AOR resolution function 55S. As shown in FIG. 62, the location table 70 shows the correspondence between the AOR (SIP-URI) 71 of the server SV1b and the IP address 72.

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.

  In this embodiment, when a connection occurs in the client CL1a with the server SV1b specified by the IP address, the SIP message processing unit 53C transmits the AOR resolution request message M30 directly to the server SV1b, and the SIP message of the server SV1b. In response to receiving the AOR resolution request message M30, the processing unit 53S returns an AOR resolution response message M40 indicating the SIP-URI [sv1@bbb.com] of the server SV1b.

  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 message processing unit 53C), a To header including the IP address of the server SV1b, and a SIP-URI of the client CL1a (SIP message processing unit 53C). A From-header including a Call-ID header, a CSeq header, and a Content-Length header. The AOR resolution request message M30 does not have a body part, and Content-Length is 0.

  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 “sv1@bbb.com” of the server SV1b that is the target AOR is included in the AOR header. "It is shown.

  When the SIP message processing unit 53C of the client CL1a receives the AOR resolution response message M40, the SIP message processing unit 53C creates a connection request message M5 in which the SIP-URI of the server SV1b is applied to the Request-URI, and the TLS unit 52C, IPsec engine 30C, NIC It is sent to the SIP proxy PRa via the unit 20C. At this time, after executing the TLS negotiation (S7) with the SIP proxy PRa, the TLS unit 52C encrypts the connection request message M5 and transmits it to the SIP proxy PRa.

  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.

FIG. 66 shows a flowchart 110y of a control operation executed by the SIP message processing unit 53C when the body portion of the connection request message is received from the SP / SA control unit 51C in the client CL1a of the third embodiment.
When the SIP message processing unit 53C receives the body part of the connection request message from the SP / SA control unit 51C, the SIP message processing unit 53C manages the IP address of the connection destination server V1b indicated by the ID data of the second ID payload. The AOR acquisition request message M30 illustrated in FIG. 64 is created from the communication control parameters (step 111y), and the message is transmitted to the server SV1b via the TCP / IP unit 30C and the NIC unit 20C (112y). In this case, since the AOR acquisition request message M30 does not pass through the TLS unit 52C, the TLS negotiation with the server SV1b is not executed, and the AOR acquisition message M30 is transmitted to the destination server SV1b as an unencrypted plaintext message. It is done.

  The SIP message processing unit 53C waits for an AOR acquisition response message from the server SV1b (113y), and upon receiving the AOR acquisition response message M40, analyzes the received message (114) and assigns it to the connection destination server from the AOR header. The SIP-URI is extracted (115). Thereafter, the SIP message processing unit 53C applies the SIP-URI to the start line and the To header, and includes a header unit M5-1 and a body unit M5-2 received from the SP / SA control unit 51C. The connection request message M5 illustrated in FIG. 17 is created (116). The subsequent processing procedure is the same as that of the first embodiment described with reference to FIG.

FIG. 67 shows a flowchart 450 of a control operation executed by the SIP message processing unit 53S of the server SV1b when the AOR acquisition request message M30 is received from the client.
When the SIP message processing unit 53S of the server SV1b receives the AOR acquisition request message M30, the SIP message processing unit 53S analyzes the received message (step 451), and from the location table 70, the AOR value (SIP) corresponding to the IP address indicated by the To header of the received message -URI) is acquired (452). The SIP message processing unit 53S sets the acquired AOR value in the AOR header, creates an AOR acquisition response message M40 (453), and transmits it to the client that is the transmission source of the AOR acquisition request message M30 (454). This routine is terminated.

  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.

  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 TLS unit 52C omits the TLS negotiation with the SIP server SIPa and receives the AOR acquisition request message received from the SIP message processing unit 53C, or The connection request message can be immediately encrypted and transmitted to the network NW1.

  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.

The figure for demonstrating the conventional authentication system in public key encryption communication. The figure which shows the basic block structure of the software with which the conventional client is provided in order to perform the encryption communication by IPsec. The figure for demonstrating the authentication system to which the SIP proxy relevant to this invention is applied. The figure which shows one example of the network structure containing the session management server (SIP server) of this invention. The figure which shows an example of the location service table with which the location server LSV shown in FIG. 4 is provided. The block diagram which shows the hardware constitutions of SIP proxy PRa shown in FIG. The figure which shows the basic software structure of the client CL1a shown in FIG. The figure which shows the basic software structure of server SV1b shown in FIG. The figure which shows the basic software structure of SIP proxy PRa shown in FIG. The figure which shows the basic software structure of the registrar RGa shown in FIG. A part of sequence diagram for explaining a first embodiment of encrypted communication according to the present invention. The remainder of the sequence diagram for demonstrating the 1st Example of the encryption communication by this invention. The figure which shows an example of the format of the location registration request message M1 in FIG. The figure which shows an example of the format of the location registration response message M2 in FIG. The figure which shows an example of the format of the location AOR acquisition request message M3 in FIG. The figure which shows an example of the format of the location AOR acquisition response message M4 in FIG. The figure which shows an example of the format of the connection request message M5 in FIG. The figure which shows an example of the format of the body part M5-2 of the connection request message M5. The figure which shows an example of the format of the message M6 in connection in FIG. The figure which shows an example of the format of the connection request message M7 in FIG. The figure which shows an example of the format of the message M8 in connection in FIG. The figure which shows an example of the format of the connection request message M9 in FIG. The figure which shows an example of the format of the connection response message M10 in FIG. The figure which shows an example of the format of the body part M10-2 of the connection response message M10. The figure which shows an example of the format of the connection response message M11 in FIG. The figure which shows an example of the format of the connection response message M12 in FIG. The figure which shows an example of the format of the connection confirmation message M13 in FIG. The figure which shows an example of the format of the connection confirmation message M14 in FIG. The figure which shows an example of the format of the connection confirmation message M15 in FIG. The figure which shows an example of the format of the cutting | disconnection request message M20 in FIG. The figure which shows an example of the format of the message M21 in cutting | disconnection in FIG. The figure which shows an example of the format of the cutting | disconnection request message M22 in FIG. The figure which shows an example of the format of the message M23 in cutting | disconnection in FIG. The figure which shows an example of the format of the cutting | disconnection request message M24 in FIG. The figure which shows an example of the format of the disconnection response message M25 in FIG. The figure which shows an example of the format of the disconnection response message M26 in FIG. The figure which shows an example of the format of the disconnection response message M27 in FIG. The flowchart which shows the control operation which SP / SA control part 51C of client CL1a performs, when a key exchange request | requirement is received. A part of flowchart which shows the control operation which SIP message processing part 53C of client CL1a performs when the body part of a connection request message is received. The remainder of the flowchart showing the control operation executed by the SIP message processing unit 53C of the client CL1a when the body part of the connection request message is received. The flowchart which shows the control operation which SIP message processing part 53R of registrar RGa performs when receiving an AOR acquisition request message. The 1st part of the flowchart which shows the control operation which SIP message processing part 53P of SIP proxy PRa performs, when a connection request message is received. The 2nd part of the flowchart which shows the control action which SIP message processing part 53P of SIP proxy PRa performs, when a connection request message is received. The third part of the flowchart showing the control operation executed by the SIP message processing unit 53P of the SIP proxy PRa when receiving the connection request message. The 4th part of the flowchart which shows the control operation which SIP message processing part 53P of SIP proxy PRa performs, when a connection request message is received. The flowchart which shows the control operation which the SIP message process part 53S of server SV1b performs, when a connection request message is received. The flowchart which shows the control operation which SP / SA control part 51S of server SV1b performs, when the body part of a connection request message is received. The flowchart which shows the control operation which SP / SA control part 51C of client CL1a performs, when a key deletion request | requirement is received. The flowchart which shows the control operation | movement which 53C of SIP message processing parts of client CL1a perform when the issuing request | requirement of a cutting | disconnection request message is received. A part of flowchart which shows the control operation which SIP message processing part 53P of SIP proxy PRa performs, when a cutting | disconnection request message is received. The remainder of the flowchart showing the control operation executed by the SIP message processing unit 53P of the SIP proxy PRa when receiving a disconnection request message. The flowchart which shows the control action which the SIP message process part 53S of server SV1b performs, when a disconnection request message is received. The flowchart which shows the control operation which SP / SA control part 51S of server SV1b performs when the notification of generation | occurrence | production of a cutting | disconnection request | requirement is received. A part of sequence diagram for explaining a second embodiment of the encrypted communication according to the present invention. The remainder of the sequence diagram for demonstrating the 2nd Example of the encryption communication by this invention. The figure which shows an example of the format of the connection request message M5x in FIG. The figure which shows an example of the format of the message M6x in connection in FIG. The figure which shows an example of the format of the connection request message M7x in FIG. The figure which shows an example of the format of the cutting | disconnection request message M20x in FIG. The figure which shows an example of the format of the cutting | disconnection request message M22x in FIG. A part of flowchart which shows control operation which SIP message processing part 53C of client CL1a of a 2nd example performs when a body part of a connection request message is received. A part of flowchart which shows the control operation which SIP message processing part 53P of SIP proxy PRa of 2nd Example performs, when a connection request message is received. The flowchart which shows the control operation | movement which 53C of SIP message processing parts of the client CL1a of 2nd Example perform when the issuing request | requirement of a cutting request message is received. A part of flowchart which shows the control operation which SIP message processing part 53P of SIP proxy PRa of 2nd Example performs, when a cutting | disconnection request message is received. The figure which shows the basic software structure with which client CL1a of 3rd Example of this invention is provided. The figure which shows the basic software structure with which server SV1b of 3rd Example of this invention is provided. The figure which shows the content of the location table with which server SV1b is provided. A part of sequence diagram for explaining a third embodiment of the encrypted communication according to the present invention. FIG. 64 is a diagram showing an example of a format of an AOR acquisition request message M30 in FIG. 63. FIG. 64 is a diagram showing an example of a format of an AOR acquisition response message M40 in FIG. 63. A part of flowchart which shows control operation which SIP message processing part 53C of client CL1a of a 3rd example performs when a body part of a connection request message is received. A flowchart showing a control operation executed by the SIP message processing unit 53S of the server SV1b of the third embodiment when an AOR acquisition request message is received.

Explanation of symbols

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)

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. 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). 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. 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. 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. 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). 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). 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. 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. 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). 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. 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. 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. 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. 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. 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. 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. 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). 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. 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.

Images