JP4555311B2 - Tunnel communication system, control device, and tunnel communication device - Google Patents

Description

  The present invention relates to a tunnel communication system, a control device, and a tunnel communication device.

  A carrier-scale network that assumes millions and tens of millions of subscribers has been established for the purpose of providing public services by communication carriers using IP (Internet Protocol) technology that has been used for data communications. It is going to be done. In such a carrier scale network (hereinafter referred to as “wide area IP network”), it is considered necessary to control resources on the network to which packets are transferred (hereinafter referred to as “transfer resource control”). It is done.

  Specifically, for example, in a network, not only text data and file data are transferred, but also data that requires real-time communication such as a telephone is transferred. Therefore, it is considered that “bandwidth control” according to communication characteristics is required. In other words, for the transfer of packets containing the data, band allocation to allocate bandwidth according to communication characteristics, transfer priority setting to set packet transfer priority according to communication characteristics, etc. Is required.

  Also, for example, in a network, a device or service system must be protected from unauthorized access such as a DOS attack (Denial of Service attack, an attack in which a device sends a large number of requests to another device). As one of the transfer resource controls, it is considered that “filtering control” that blocks unnecessary packets from being transferred is necessary. That is, it is necessary to set the continuity of the packet filter so that only packets related to legitimate communication are transferred.

  Further, for example, in a wide area IP network, the number of subscribers is assumed to reach tens of millions, but the IP address is limited (for example, in the case of an IPv4 address, the space size of the class A address is The number of IP addresses that can be actually allocated will be further reduced when considering that the IPv4 address is divided into a plurality of subnets for operation, and it is necessary to avoid a situation where the IP address is insufficient. Therefore, as one of the transfer resource controls, it is considered that “IP address control” is required so as not to run out of IP addresses.

  Here, for example, Non-Patent Document 1 and Non-Patent Document 7 disclose a method of performing “bandwidth control” and “filtering control”, which are one of transfer resource controls, in units of sessions. More specifically, in the technique disclosed in Non-Patent Document 1, first, before a device starts communication (establishing a session) between devices, a message required for establishing a session is displayed. Send to the network. Then, the communication control device in the network performs “bandwidth control” and “filtering control” based on the contents described in the message. As a method for specifying data belonging to a session by a control device, a method for specifying by a combination of a source IP address and a destination IP address, a TCP / UDP (Transmission Control Protocol / User Datagram Protocol) protocol type, There is a method of specifying by a combination of parameters such as source port number and destination port number. In addition, in this invention, the state in which the transfer resource necessary for packet transfer between the devices that perform communication is set is regarded as the state in which a virtual path is generated between the communication devices, and the transfer resource is set. This is expressed as generation of a virtual path.

  Further, for example, Non-Patent Document 2 discloses a technique of performing “IP address control”, which is one of transfer resource controls, using a technique called NAPT (Network Address Port Translation). NAPT is a technique aimed at avoiding a situation where public IP addresses (IP addresses that are unique in the Internet space) are insufficient on the Internet.

  Hereinafter, NAPT applied to the Internet will be described in detail. In the method disclosed in Non-Patent Document 2, a plurality of devices on a LAN (Local Area Network) share one public IP address, Communicate with other devices on the Internet. FIG. 27 is a diagram for explaining NAPT. For example, as shown in FIG. 27, it is assumed that a gateway device that relays IP packets between a LAN and the Internet is installed between the LAN and the Internet and is assigned a public IP address “Ig”. Also, devices A and B are installed on the LAN, and are assigned private IP addresses (IP addresses that can be kept unique only in a private IP network space) “Ia” and “Ib”, respectively. And Furthermore, it is assumed that the server C and the server D are installed on the Internet, and public IP addresses “Ic” and “Id” are respectively assigned.

  In such a configuration, when the device A communicates with the server C using the port number “Pa”, the device A, as shown in FIG. 27, has the source IP address “Ia” and the source port number “Pa”. , A packet with the destination IP address “Ic” is sent out. The gateway device relays this packet to the Internet. At this time, the IP address “Ia” and the port number “Px” corresponding to the port number “Pa” are selected, and the source IP address of the packet is set to “Ig”. Rewrite, rewrite the source port number to “Px”, and transfer to server C. Conversely, when the gateway device receives a packet with the destination IP address “Ig” and the port number “Px”, the gateway device rewrites the destination IP address of the packet to “Ia” and sets the destination port number to “Pa”. ] And transferred to the device A.

  Similarly, when the device B communicates with the server D using the port number “Pb”, the device B, as shown in FIG. 27, has the source IP address “Ib”, the source port number “Pb”, the destination IP address “ The packet “Id” is transmitted. The gateway device relays this packet to the Internet. At this time, the IP address “Ib” and the port number “Py” corresponding to the port number “Pb” are selected, and the source IP address of the packet is set to “Ig”. Rewrite, rewrite the source port number to “Py”, and transfer to server D. On the other hand, when the gateway device receives a packet having the destination IP address “Ig” and the port number “Py”, the gateway device rewrites the destination IP address of the packet to “Ib” and sets the destination port number to “Pb”. ] And transferred to the device B.

  By such NAPT, “difference in IP address” in different devices on the LAN is mapped to “difference in port number” on the Internet, so the number of necessary public IP addresses is set to one, and the public IP address is It will avoid the shortage. Since the packet is specified by a port number, IP communication to which NAPT can be applied is layer 4 communication such as TCP / IP and UDP / IP.

  Up to this point, transfer resource control that is considered to be necessary in a network has been described. On the other hand, conventionally, a subscriber who uses a network has an IP network (such as a corporate intranet or a general user) that is managed by the subscriber. Tunnel communication to connect to other private IP networks (including networks of other bases in the same private IP network) from the home LAN etc. There is a request to do. In this tunnel communication, a connection is made from a private IP network or a device outside the home to another private IP network, so in the network, IP communication based on a private IP address must be relayed.

  Here, for example, Non-Patent Document 3 discloses a method of performing tunneling communication using a technique called “IPsec ESP tunnel mode”. However, since the IP packet of the “IPsec ESP tunnel mode” does not have a port number, it does not support relaying by NAPT. For this reason, usually, a technique of performing tunneling communication using a technique called “IPsec UDP capsule method” is used (see Non-Patent Documents 4 and 5). Specifically, in the methods disclosed in Non-Patent Documents 4 and 5, first, an IP packet is encrypted in accordance with the rules of “IPsec ESP tunnel mode”, and then the encrypted IP packet is converted to UDP. / It is written in the payload of the IP packet and transferred. Of course, even in the “IPsec UDP capsule method”, a public IP address must be assigned to a destination tunnel communication device serving as an incoming side of tunnel communication (that is, a private IP address can be assigned by tunnel communication). Only the originating tunnel communication device that is the originator of the

  The destination tunnel communication apparatus must be assigned a public IP address, but “Dynamic DNS” (see Non-Patent Document 6) is disclosed as a technique that does not require a fixed public IP address. Yes.

“SIP: Session Initiation Protocol”, [online], [searched on January 17, 2007], Internet <http://www.ietf.org/rfc/rfc3261.txt> “IP Network Address Translator (NAT) Terminology and Considerations”, [online], [searched on January 17, 2007], Internet <http://www.ietf.org/rfc/rfc2663.txt> “IP Encapsulating Security Payload (ESP)”, [online], [searched January 17, 2007], Internet <http://www.ietf.org/rfc/rfc4303.txt> “Negotiation of NAT-Traversal in the IKE”, [online], [searched on January 17, 2007], Internet <http://www.ietf.org/rfc/rfc3947.txt> “UDP Encapsulation of IPsec ESP Packets”, [online], [searched on January 17, 2007], Internet <http://www.ietf.org/rfc/rfc3948.txt> "Dynamic Updates in the Domain Name System (DNS UPDATE)", [online], [searched on January 17, 2007], Internet <http://www.ietf.org/rfc/rfc2136.txt> “Megaco Protocol Version 1.0”, [online], [searched on January 19, 2007], Internet <http://www.ietf.org/rfc/rfc3015.txt>

  By the way, in the conventional technology described above, as described below, tunnel communication cannot be realized in a network such as a wide area IP network while controlling transfer resources and preventing path hijacking. There was a problem.

  That is, if tunnel communication is performed using the techniques disclosed in Non-Patent Documents 3 to 6, transfer resources such as “bandwidth control”, “filtering control”, and “IP address control” cannot be controlled. Then, when realizing tunnel communication, for example, for resources to which packets are transferred, bandwidth cannot be allocated according to communication characteristics, and packet transfer priority can be set according to communication characteristics. However, there is a problem that necessary packet continuity cannot be ensured on the network in which the packet filter is set, and the situation where the IP address is insufficient cannot be avoided.

  If tunnel communication is performed on the virtual path as described above, it is necessary to consider path hijacking. In other words, unlike conventional telephone networks and ISDN (Integrated Services of Digital Network), it is easy to forge or intercept IP addresses that identify devices in IP networks, so it is necessary to consider the threat of path hijacking. Become. The hijacking of a path means that after a path is generated between the first communication device and the second communication device, another third communication device is connected to the first communication device or the second communication device. This is to use the path instead of the communication device. For example, if the third communication device stops the first communication device by some means and uses the IP address assigned to the first communication device, path hijacking becomes possible. .

  In consideration of security and appropriate charges for communication usage charges, it is necessary to prevent such hijacking of paths. For example, even if the other device is identified at the time of path generation and the restriction is set so that tunnel communication is performed only with a specific communication device, an unauthorized device can break this restriction by hijacking the path. Because it becomes. In addition, if a device generates a path to execute tunnel communication with an ISP (Internet Services Provider) network, and another device hijacks this path, the Internet can be used for payment of communication charges by others. This is because it becomes possible.

  Note that the techniques disclosed in Non-Patent Documents 1 and 7 do not realize tunnel communication. The technique disclosed in Non-Patent Document 2 is intended to avoid a situation where public IP addresses are insufficient on the Internet. It is not intended to avoid a situation where there is a shortage of IP addresses).

  Therefore, the present invention has been made to solve the above-described problems of the prior art. In a network such as a wide area IP network, tunnel communication is performed while controlling transfer resources and preventing path hijacking. An object of the present invention is to provide a tunnel communication system, a control device, and a tunnel communication device capable of realizing the above.

  In order to solve the above-described problems and achieve the object, the invention according to claim 1 is performed with the originating side tunnel communication device and the terminating side tunnel communication device respectively connected to the network performing IP communication as communication partners. A tunnel communication system in which a control device controls a virtual path used for data transfer when tunnel communication is applied to data transfer, wherein the control device uniquely identifies the destination tunnel communication device on the network. A path generation request receiving means for receiving, from the calling side tunnel communication apparatus, a path generation request for requesting generation of the virtual path to and from the destination side tunnel communication apparatus, and the path generation When the path generation request is received by the request receiving means, data between the originating tunnel communication device and the terminating tunnel communication device is received. Path generation means for generating the virtual path by setting transfer resources necessary for transfer, and path generation notification for notifying generation of a virtual path to be generated by the path generation means, A path generation notification transmitting means for transmitting to each of the communication apparatus and the destination tunnel communication apparatus, the calling side tunnel communication apparatus, the path generation request of the virtual path to be generated by the path generation means, A path generation request transmission unit configured to transmit to the control device, wherein the originating tunnel communication device and the destination tunnel communication device receive the path generation notification transmitted by the path generation notification transmission unit from the control device; Mutually authenticate between the path generation notification receiving means that performs communication and the tunnel communication partner apparatus that is the communication partner in the tunnel communication. Mutual authentication information exchange means for exchanging mutual authentication information used for mutual authentication with the tunnel communication counterpart apparatus using the virtual path generated by the path generation means, and the mutual authentication information exchange means from the tunnel communication counterpart apparatus. Based on the acquired mutual authentication information, determine whether to establish or reject tunnel communication with the tunnel communication counterpart device, tunnel communication establishment rejection means for rejecting the establishment of the tunnel communication when it is determined to reject, A virtual path generated by the path generation means by generating tunnel communication data from original data which is data to be transmitted to the tunnel communication partner apparatus when the tunnel communication establishment rejection means determines to establish the tunnel communication. The tunnel communication data is sent to the tunnel communication partner device using The tunnel communication data using the virtual path generated by the path generation means from the tunnel communication counterpart device when it is determined to establish the tunnel communication by the tunnel communication establishment rejection means And tunnel data receiving means for extracting original data from the tunnel communication data.

  Further, in the invention according to claim 2, in the above invention, when the control device generates a virtual path by the path generation means, the communication partner of each of the originating side tunnel communication device and the destination side tunnel communication device Path generation partner verification information, which is information for verifying each other's virtual path counterpart device, to the destination tunnel communication device or the destination tunnel communication device and the source side A path generation partner verification information transmission unit for transmitting to the tunnel communication device, wherein the source side tunnel communication device and the destination side tunnel communication device transmit the path generation partner verification information by the path generation request transmission unit; Extracting the identifier from the path generation request or the path transmitted by the path generation partner verification information transmitting means It further comprises path generation partner verification information acquisition means for receiving the partner verification information from the control device, wherein the tunnel communication establishment rejection means is the path generation partner acquired by the path generation partner verification information acquisition means. Based on the verification information and the mutual authentication information acquired from the tunnel communication counterpart device by the mutual authentication information exchanging means, it is determined whether the tunnel communication counterpart device is the same as the virtual path counterpart device. When it is determined that the tunnel communication counterpart device is not the same as the virtual path counterpart device, it is determined that tunnel communication is rejected.

  The invention according to claim 3 is the above invention, wherein the network is a combination of a non-disclosure IP address and a non-disclosure port number that are not disclosed on the network and a disclosure IP address and a disclosure port disclosed on the network. Provided with a NAPT function for conversion between a combination of numbers, the originating side tunnel communication device is assigned an originating side undisclosed IP address and an originating side undisclosed port number, and the terminating side tunnel communication device is The destination-side non-disclosure IP address and the destination-side non-disclosure port number are assigned, and the path generation means is associated with the combination of the calling-side non-disclosure IP address and the calling-side non-disclosure port number. The selected combination of the originating side disclosure IP address and the originating side disclosure port number is used as the destination tunnel communication device. Transmitting, and transmitting the combination of the called party disclosed IP address and the called party disclosed port number selected in association with the combination of the called party undisclosed IP address and the called party undisclosed port number to the originating tunnel communication apparatus. And the conversion between the combination of the calling party non-disclosure IP address and the calling party non-disclosure port number and the combination of the calling party disclosure IP address and the calling party disclosure port number is set in the NAPT function, By setting the conversion between the combination of the destination-side non-disclosure IP address and the destination-side non-disclosure port number and the combination of the destination-side disclosure IP address and the destination-side disclosure port number in the NAPT function, The virtual path is generated by setting the transfer resource, and the mutual authentication information exchanging means The mutual authentication information using the combination of the originating side disclosed IP address and the originating side disclosed port number transmitted from the control device by the path generation means, or the combination of the called side disclosed IP address and the called side disclosed port number The tunnel data transmitting means is a combination of the originating side disclosed IP address and the originating side disclosed port number transmitted from the control device by the path generating means, or the destination side disclosed IP address and the destination side disclosed. The tunnel communication data is transmitted using a combination of port numbers, and the tunnel data receiving means is a combination of the originating side disclosure IP address and the originating side disclosure port number, or the destination side disclosure IP address and the destination side disclosure port. The tunnel communication data transmitted using a combination of numbers. Receiving the data.

  According to a fourth aspect of the present invention, in the above invention, the path generation unit sets the transfer resource as a setting related to a band to be applied to the data transfer and / or a data to be applied to the data transfer. The virtual path is generated by performing setting related to priority.

  The invention according to claim 5 is the above invention, wherein the network includes a packet filter function for determining whether or not to conduct a packet based on a setting set in the packet filter, The path generation unit generates the virtual path by setting the packet filter so that a packet related to the data transfer is conducted as the transfer resource setting.

  According to a sixth aspect of the present invention, there is provided a case where tunnel communication is applied to data transfer performed by using the originating side tunnel communication device and the destination side tunnel communication device respectively connected to a network performing IP communication as communication partners. The control device in the tunnel communication system in which the control device controls the virtual path used for the data transfer, the identifier including the identifier for uniquely identifying the destination tunnel communication device on the network. The path generation request is received by the path generation request receiving unit that receives the path generation request for generating the virtual path from the source side tunnel communication apparatus, and the path generation request receiving unit receives the path generation request. And setting of transfer resources necessary for data transfer between the originating side tunnel communication device and the destination side tunnel communication device A path generation unit that generates the virtual path by performing a path generation notification for notifying generation of a virtual path that is to be generated by the path generation unit, the outgoing side tunnel communication device and the incoming side tunnel communication device Path generation notification transmission means for transmitting to each of them and causing the calling side tunnel communication apparatus and the called side tunnel communication apparatus to exchange mutual authentication information to determine whether to establish or reject the tunnel communication. It is characterized by that.

  The invention according to claim 7 is the case where tunnel communication is applied to data transfer performed by using the originating side tunnel communication device and the destination side tunnel communication device respectively connected to the network performing IP communication as communication partners. A tunnel communication device as the originating side tunnel communication device in a tunnel communication system in which a control device controls a virtual path used for the data transfer, wherein the originating side tunnel communication device and the destination side tunnel communication are connected to the control device. Including an identifier for uniquely identifying the destination tunnel communication device on the network so that the virtual path is generated by setting transfer resources necessary for data transfer with the device. A path generation request is sent to the control device for generating a path request for generating the virtual path with the communication device. A request transmission unit, a path generation notification receiving unit for receiving a path generation notification for notifying generation of the virtual path to be generated in the control device, and a tunnel to be a communication partner in the tunnel communication Mutual authentication information exchanging means for exchanging mutual authentication information used for mutual authentication to mutually authenticate with a communication counterpart device using the virtual path generated in the control device, with the tunnel communication counterpart device, Based on the mutual authentication information acquired from the tunnel communication partner device by the mutual authentication information exchanging means, it is determined whether to establish or reject tunnel communication with the tunnel communication partner device. Tunnel communication establishment rejection means for rejecting establishment of the tunnel communication, and the tunnel communication establishment rejection means Tunnel communication data is generated from original data that is data to be transmitted to the tunnel communication partner device when it is determined to establish the communication, and the tunnel communication partner device is generated using the virtual path generated in the control device The virtual path generated in the control device from the tunnel communication partner device when it is determined that the tunnel communication is established by the tunnel data transmission means for transmitting the tunnel communication data to the tunnel communication establishment rejection means And tunnel data receiving means for extracting original data from the tunnel communication data when the tunnel communication data is received.

  Further, the invention according to claim 8 is applied to a case where tunnel communication is applied to data transfer performed by using the originating side tunnel communication device and the destination side tunnel communication device respectively connected to a network performing IP communication as communication partners. A tunnel communication device as the destination tunnel communication device in a tunnel communication system in which a control device controls a virtual path used for the data transfer, wherein the control device is connected to the source side tunnel communication device and the destination side tunnel communication. Path generation that receives from the control device a path generation notification that notifies the generation of the virtual path that is to be generated in the control device by setting transfer resources necessary for data transfer with the device Mutual authentication is performed between the notification receiving means and the tunnel communication partner device that is the communication partner in the tunnel communication. Mutual authentication information exchange means for exchanging mutual authentication information used for mutual authentication with the tunnel communication counterpart apparatus using the virtual path generated in the control apparatus, and from the tunnel communication counterpart apparatus by the mutual authentication information exchange means Based on the acquired mutual authentication information, it is determined whether to establish or reject tunnel communication with the tunnel communication partner device, tunnel communication establishment rejection means for rejecting establishment of the tunnel communication when it is determined to reject, The virtual path generated in the control device by generating tunnel communication data from original data which is data to be transmitted to the tunnel communication partner device when the tunnel communication establishment refusal means determines to establish the tunnel communication The tunnel communication data to the tunnel communication partner device using The tunnel communication data using the virtual path generated in the control device from the tunnel communication counterpart device when it is determined that the tunnel communication is established by the tunnel data transmission means and the tunnel communication establishment rejection means And tunnel data receiving means for extracting original data from the tunnel communication data.

  Further, the invention according to claim 9 is the virtual path partner apparatus which is a communication partner of each of the originating side tunnel communication apparatus and the destination side tunnel communication apparatus when a virtual path is generated in the control apparatus in the above invention The path generation partner verification information, which is information for verifying each other's virtual path counterpart device, by extracting the identifier from the path generation request transmitted by the path generation request transmission means, or the path generation partner A path generation partner verification information acquisition unit that acquires the path generation partner verification information transmitted by the verification information transmission unit by receiving from the control device; and the tunnel communication establishment rejection unit includes the path generation partner verification information. The path generation partner verification information acquired by the acquisition unit, and the mutual authentication information exchange unit Based on the mutual authentication information acquired from the tunnel communication counterpart device, it is determined whether the tunnel communication counterpart device is the same as the virtual path counterpart device, and the tunnel communication counterpart device is the virtual path counterpart device. When it is determined that the tunnel communication is not the same, it is determined that tunnel communication is rejected.

  The invention according to claim 10 is characterized in that, in the above invention, an identifier for uniquely identifying the communication partner on the network, and a shared key which is key information shared in advance with the communication partner. The path generation partner verification information acquisition unit further includes a shared key storage unit that stores the path generation partner verification information as an identifier for uniquely identifying the virtual path partner device on the network. The identifier is extracted from the path generation request transmitted by the generation request transmitting means or obtained by receiving from the control device, and the mutual authentication information exchanging means is shared by the shared key holding means Select a shared key associated with the identifier acquired by the path generation partner verification information acquisition means from the keys, and Is exchanged with the tunnel communication partner device as the mutual authentication information, and the tunnel communication establishment rejection means verifies the mutual authentication information acquired from the tunnel communication partner device using the shared key. When the verification result is unsuccessful, it is determined that the tunnel communication partner device is not the same as the virtual path partner device and it is determined that the establishment of the tunnel communication is rejected.

  According to an eleventh aspect of the present invention, in the above invention, the path generation partner verification information acquisition unit is required to generate a shared key used when generating the mutual authentication information as the path generation partner verification information. The mutual authentication information exchanging means generates the shared key using the parameter acquired by the path generation partner verification information acquisition means, and receives the shared parameter from the control device. The information generated using the key is exchanged with the tunnel communication partner device as the mutual authentication information, and the tunnel communication establishment rejection unit uses the shared key to acquire the mutual authentication information acquired from the tunnel communication partner device. Verify that if the verification result is unsuccessful, the tunnel communication partner device is not the same as the virtual path partner device Wherein the determining to reject the establishment of the tunnel communication Te.

  The invention according to claim 12 is the above invention, wherein the path generation request transmission unit transmits the path generation request to the control unit and / or the path generation partner collation information acquisition unit transmits the path generation request from the control unit. In the acquisition of the path generation partner verification information, a control device authentication means for authenticating the control device is further provided.

  Further, in the invention according to claim 13, in the above invention, the path generation partner collation information acquisition means uses an identifier for uniquely identifying the virtual path partner apparatus on the network as the path generation partner collation information. The identifier is extracted from the path generation request transmitted by the path generation request transmitting means or obtained by receiving from the control device, and the mutual authentication information exchanging means uniquely identifies its own device on the network. Information including its own device identifier to be exchanged with the tunnel communication partner device as the mutual authentication information, and the tunnel communication establishment rejection means includes the identifier acquired by the path generation partner verification information acquisition means, and the tunnel The self-device identification of the tunnel communication partner device included in the mutual authentication information acquired from the communication partner device. If the the child not uniquely possible association, the tunnel communication partner apparatus is characterized in that determining to reject the establishment of the virtual path remote device the tunnel communication is determined not to be identical.

  Further, the invention according to claim 14 is the above described invention, wherein, when a virtual path is generated in the control device, a virtual path partner that is a communication partner of each of the originating tunnel communication device and the terminating tunnel communication device Based on the identifier received by the virtual path partner apparatus identifier receiving means and the virtual path partner apparatus identifier receiving means for receiving an identifier uniquely identifying the apparatus on the network from the control apparatus, the identifier is identified by the identifier. Judgment means for judging whether to establish or reject tunnel communication with the virtual path partner apparatus is further provided.

  The invention according to claim 15 is characterized in that, in the above invention, the control device according to claim 6 is realized by a computer.

  The invention according to claim 16 is characterized in that, in the above-mentioned invention, the tunnel communication device according to any one of claims 7 to 14 is realized by a computer.

  According to the first, sixth to eighth, fifteenth, or sixteenth aspects of the present invention, a tunnel is used for data transfer that is performed with the originating side tunnel communication device and the destination side tunnel communication device respectively connected to the network performing IP communication as communication partners. A tunnel communication system in which a control device controls a virtual path used for data transfer when communication is applied, and the control device includes an identifier that uniquely identifies the destination tunnel communication device on the network. A path generation request for generating a virtual path with the tunnel communication apparatus is received from the originating tunnel communication apparatus, and when the path generation request is received, the calling tunnel communication apparatus and the destination tunnel communication apparatus A virtual path is generated by setting the transfer resources necessary for data transfer between the two, and a path generation notification for notifying the generation of the virtual path is sent to the originating tunnel The originating tunnel communication device transmits a virtual path path generation request to the control device, and the originating tunnel communication device and the terminating tunnel communication device notify the path generation notification. Exchange the mutual authentication information used for mutual authentication to mutually authenticate with the tunnel communication partner device that is a communication partner in the tunnel communication using the virtual path, Based on the mutual authentication information acquired from the tunnel communication partner device, it is determined whether to establish or reject the tunnel communication with the tunnel communication partner device. Then, the tunnel communication data is generated from the original data that is the data to be transmitted to the tunnel communication partner device when it is determined to be The tunnel communication data is transmitted to the tunnel communication partner device using the virtual path and the tunnel communication data is received using the virtual path from the tunnel communication partner device when it is determined to establish the tunnel communication. Therefore, the tunnel communication apparatus can realize tunnel communication in a network such as a wide area IP network by controlling transfer resources and preventing path hijacking.

  Further, according to the invention of claim 2 or 9, the control device, with respect to the virtual path partner device that becomes the communication partner of each of the originating side tunnel communication device and the destination side tunnel communication device when the virtual path is generated, Path generation partner verification information, which is information for verifying the virtual path partner device, is transmitted to the destination tunnel communication device or to the destination tunnel communication device and the source tunnel communication device, and the source tunnel communication device and the destination tunnel communication device are transmitted. The side tunnel communication device acquires the path generation partner verification information by extracting the identifier from the transmitted path generation request or by receiving the path generation partner verification information from the control device. And the mutual authentication information acquired from the tunnel communication partner device, it is determined whether or not the tunnel communication partner device is the same as the virtual path partner device. If it is determined that the tunnel communication partner device is not the same as the virtual path partner device, it is determined that the tunnel communication is rejected. Therefore, the information for collating the communication partner in the path generation procedure and the mutual information acquired from the communication partner in the tunnel communication are determined. Based on the authentication information, it is possible to verify the coincidence between the communication partner in the path generation procedure and the communication partner in the tunnel communication. Therefore, an unauthorized device that hijacks the path is the destination tunnel communication device. Even in a case where mutual authentication with the (or originating side tunnel communication device) is possible, tunnel communication can be realized while preventing path hijacking.

  According to the invention of claim 3, the network is between a combination of a non-disclosure IP address and a non-disclosure port number not disclosed on the network and a combination of a disclosure IP address and a disclosure port number disclosed on the network. A NAPT function for conversion is provided, and the originating side tunnel communication device is given an originating side undisclosed IP address and an originating side undisclosed port number. A combination of a calling party disclosure IP address and a calling party disclosure port number selected in association with a combination of a calling party nondisclosure IP address and a calling party nondisclosure port number. Of the destination side non-disclosure IP address and destination side non-disclosure port number Transmitting the combination of the called party-side disclosed IP address and the called party-side disclosed port number selected in association with each other to the calling-side tunnel communication apparatus, and the combination of the calling-side undisclosed IP address and the calling-side undisclosed port number The conversion between the combination of the calling party disclosed IP address and the calling party disclosed port number is set in the NAPT function, the combination of the called party undisclosed IP address and the called party undisclosed port number and the called party disclosed IP address and the called party. By setting the NAPT function to convert between the combination of the side disclosure port numbers and the side, the virtual resource is generated by setting the transfer resource in the network, and the source side disclosure IP address and the source side transmitted from the control device Combination of disclosure port numbers, or combination of destination disclosure IP address and destination disclosure port number Is used to exchange mutual authentication information, and the tunnel data using the combination of the caller-side disclosed IP address and the caller-side disclosed port number transmitted from the control device, or the combination of the callee-side disclosed IP address and the callee-side disclosed port number And the tunnel data transmitted using the combination of the caller-side disclosure IP address and the caller-side disclosure port number or the combination of the callee-side disclosure IP address and the callee-side disclosure port number is received. It is also possible to perform IP address control. Further, when the tunnel communication system according to the present invention performs IP address control (NAPT coupling) as control of transfer resources, the IP address of the destination tunnel communication apparatus can also be converted by NAPT. Therefore, it becomes unnecessary to assign a wide area IP address to the destination tunnel communication apparatus, and it is possible to appropriately avoid a situation where the wide area IP address is insufficient in the wide area IP network.

  According to the invention of claim 4, the virtual path is generated by performing the setting relating to the bandwidth to be applied to the data transfer and / or the setting relating to the priority of the data to be applied to the data transfer as the setting of the transfer resource. Therefore, bandwidth control can be performed as transfer resource control.

  According to the invention of claim 5, the network is provided with a packet filter function for determining whether or not to conduct a packet based on the setting set in the packet filter. Since the virtual path is generated by setting the packet filter so that the packet related to data transfer is conducted, filtering control can be performed as transfer resource control.

  According to the invention of claim 10, an identifier for uniquely identifying a communication partner on the network and a shared key, which is key information shared in advance with the communication partner, are stored in association with each other. As the generation partner verification information, an identifier that uniquely identifies the virtual path partner device on the network is obtained by extracting the identifier from the transmitted path generation request or receiving it from the control device, and is held. The mutual authentication information acquired from the tunnel communication partner device is selected by selecting the shared key associated with the acquired identifier, exchanging information generated using the shared key as mutual authentication information with the tunnel communication partner device. If the verification result is unsuccessful, it is determined that the tunnel communication partner device is not the same as the virtual path partner device, and tunnel communication is established. Since it is judged to be rejected, tunnel communication on the path can be protected (for example, message authentication, data encryption, etc.) using a pre-set shared key, and an intermediate on the path It is also possible to prevent attacks. Also, since the identifier of the communication partner is acquired in the path generation procedure and mutual authentication is performed using the shared key held in association with the acquired identifier, the communication partner in the path generation procedure and the communication partner in the tunnel communication Therefore, even when an unauthorized device that hijacks the path is in a relationship that can be mutually authenticated with the terminating tunnel communication device (or the originating tunnel communication device), It becomes possible to prevent the jack.

  According to the eleventh aspect of the present invention, the parameter necessary for generating the shared key used when generating the mutual authentication information is acquired as the path generation partner verification information by receiving it from the control device. A shared key is generated by using the parameter, and the information generated by using the shared key is exchanged with the tunnel communication partner device as mutual authentication information, and the mutual authentication information acquired from the tunnel communication partner device is used by using the shared key. When the verification result is unsuccessful, it is determined that the tunnel communication partner device is not the same as the virtual path partner device and the tunnel communication establishment is rejected, so a pre-set shared key is used. Regardless of the method, it is possible to protect the tunnel communication on the path by using the shared key generated in the path generation procedure (for example, the tunnel communication is consistent). Can be applied to the case) performed between the relationship and is a communication partner. In addition, since mutual authentication is performed using the shared key generated in the path generation procedure, the matching relationship between the communication partner in the path generation procedure and the communication partner in the tunnel communication can be verified. It is possible to prevent hijacking of the path even when an unauthorized device to be jacked has a mutual authentication relationship with the called-side tunnel communication device (or the originating-side tunnel communication device).

  According to the twelfth aspect of the invention, since the control device is authenticated in the transmission of the path generation request to the control device and / or the acquisition of the path generation partner collation information from the control device, the man-in-the-middle attack in the path generation procedure is also performed. As a result that can be prevented (for example, a result of avoiding a situation in which the tunnel communication device transmits and receives a message with a fake control device that attempts a man-in-the-middle attack), it is possible to ensure that legitimate path generation partner verification information is received. Thereby, hijacking of the above path can be prevented more safely.

  According to the thirteenth aspect of the present invention, as the path generation partner verification information, an identifier for uniquely identifying the virtual path partner apparatus on the network is extracted from the transmitted path generation request or received from the control apparatus. The information including the own device identifier that uniquely identifies the device on the network is exchanged with the tunnel communication partner device as mutual authentication information, and the acquired identifier and the tunnel communication partner device are acquired. If it is determined that the tunnel communication partner device is not the same as the virtual path partner device and the tunnel communication partner device is refused to establish the tunnel communication when the self device identifier of the tunnel communication partner device included in the mutual authentication information cannot be uniquely associated Therefore, the communication partner identifier acquired in the path generation procedure and the communication partner identifier acquired in the mutual authentication procedure Because it is possible to verify the coincidence between the communication partner in the path generation procedure and the communication partner in the tunnel communication by determining whether or not the child (which also performs authentication in the mutual authentication procedure) can be uniquely associated. Even when an unauthorized device that hijacks a path has a mutual authentication relationship with the called-side tunnel communication device (or the originating-side tunnel communication device), it is possible to prevent path hijacking. For example, X. When mutual authentication is performed by a method using a 509 certificate, an unauthorized device is connected to the incoming side tunnel communication device (or the outgoing side tunnel communication device) and the X.509 certificate. It is possible to prevent path hijacking even when a mutual authentication is possible using the 509 certificate.

  According to the fourteenth aspect of the present invention, when a virtual path is generated in the control device, a virtual path partner device serving as a communication partner of each of the originating side tunnel communication device and the destination side tunnel communication device is uniquely identified on the network. Since the identifier to be identified is received from the control device, and based on the received identifier, it is determined whether to establish or reject tunnel communication with the virtual path partner device identified by the identifier. It is possible to realize authorization for establishing a tunnel only with the tunnel communication device. For example, it becomes possible for the called-side tunnel communication device to realize authorization for establishing a tunnel only with a specific originating-side tunnel communication device.

  Exemplary embodiments of a tunnel communication system, a control device, and a tunnel communication device according to the present invention will be described below in detail with reference to the accompanying drawings. In the following, the main terms used in the embodiment, the outline and features of the tunnel communication system according to the first embodiment, the configuration of the tunnel communication system according to the first embodiment, the processing procedure by the tunnel communication system according to the first embodiment, The effects of the first embodiment will be described in order, and then other embodiments will be described.

[Explanation of terms]
First, main terms used in the following examples will be described. “Tunnel communication” used in the following embodiments is, for example, a device in which a user who normally uses a corporate intranet (private IP network) is installed in a user's own local area network (LAN) (local area network). A network that is connected directly to a company's intranet from a personal computer (such as a personal computer) via a network such as a wide-area IP (Internet Protocol) network and is directly connected to a device on the intranet (such as a broadband router). It is to communicate as if there is.

  In such "tunnel communication", "origin side tunnel communication device" that requests tunnel communication and "destination side tunnel communication device" that performs tunnel communication in response to the request are connected to the wide area IP network. The “origin side tunnel communication apparatus” and the “destination side tunnel communication apparatus” are used as communication partners. In the above example, the personal computer installed in the home LAN corresponds to the “outgoing side tunnel communication device”, and the broadband router on the intranet corresponds to the “incoming side tunnel communication device”. In the first embodiment, a case is assumed in which tunnel communication is performed with a personal computer installed in a home LAN and a broadband router on an intranet as communication partners, but the present invention is not limited to this. It is not something that can be done. For example, assuming that the source tunnel communication device and the destination tunnel communication device are personal digital assistants (PDAs), network home appliances, or mobile phone terminals, or intranets as communication partners The present invention can be similarly applied to a case where a configuration of tunnel communication performed, a configuration of tunnel communication performed using a device outside the home and an intranet as communication partners, or the like is assumed.

  “Tunnel communication” in the first embodiment corresponds to “path control device” (“control device” described in claims) in addition to “origin side tunnel communication device” and “destination side tunnel communication device”. Is realized by controlling. That is, the “tunnel communication” in the first embodiment is performed by the “path control device” installed in the wide area IP network for data transmitted / received between the “origin side tunnel communication device” and the “destination side tunnel communication device”. , Generate a “virtual path” that is the route through which the data is transferred, and use the “virtual path” generated by the “path control device” by the “originating tunnel communication device” and the “destination tunnel communication device”. Send and receive data. Here, the “virtual path” will be described. A state in which a transfer resource necessary for data transfer between two communication devices is allocated to a certain two communication devices is assumed to be virtual between the two communication devices. It is assumed that a simple path has been generated, and this is expressed as a “virtual path”. Also, assigning a transfer resource is expressed as “generating a virtual path”. In other words, the “path control device” generates a “virtual path” when the “path control device” is a transfer resource necessary for data transfer between the “origin side tunnel communication device” and the “destination side tunnel communication device”. Is to assign.

  In the first embodiment, a case where a general-purpose server computer having a TCP / IP (Transmission Control Protocol / Internet Protocol) communication function is assumed as the “path control device” will be described, but the present invention is not limited thereto. For example, when the “path control device” is a part of a network device, the present invention can be similarly applied to a case where another device is assumed as the “path control device”.

  By the way, in a carrier scale network such as a wide area IP network, it is considered that “transfer resource control” such as “bandwidth control”, “filtering control”, or “IP address control” is required. At the same time, when “tunnel communication” is performed on the “virtual path”, it is considered necessary to prevent path hijacking. For this reason, in the following embodiment, the “tunnel communication system” composed of the “originating tunnel communication device”, the “destination tunnel communication device”, and the “path control device” It is important to implement “tunnel communication” while controlling and preventing path hijacking.

[Outline and Features of Tunnel Communication System According to Embodiment 1]
Next, the outline and features of the tunnel communication system according to the first embodiment will be described with reference to FIG. FIG. 1 is a diagram for explaining the outline and features of the tunnel communication system according to the first embodiment. In the following first embodiment, a path control device is provided for each local IP network constituting the wide area IP network, and the originating side tunnel communication device and the destination side tunnel communication device are accommodated in different path control devices. However, the present invention is not limited to this, and one path control device is provided in the wide area IP network, and the source side tunnel communication device and the destination side tunnel communication device are the same. The present invention can be similarly applied to the cases accommodated in the case. In the first embodiment, a tunnel communication system including a device having a function of originating side tunnel communication and a device having a function of terminating side tunnel communication will be described. However, the present invention is not limited to this. In addition, the present invention can be similarly applied to a tunnel communication system configured by a device having both the functions of the outgoing side tunnel communication and the incoming side tunnel communication.

  In the first embodiment, an example in which IP address control is performed as transfer resource control will be described. However, the present invention is not limited to this, and examples of performing bandwidth control and filtering control as transfer resource control. In addition, the present invention can be similarly applied. These cases will be described in detail in the fifth embodiment.

  By the way, how the tunnel communication system according to the present invention avoids a situation where a wide area IP address is insufficient in a wide area IP network will be described. The purpose is to avoid a situation where a public IP address is insufficient in the Internet. Is applied to a wide area IP network, it is possible to avoid a situation where a wide area IP address is insufficient.

  Specifically, the wide area IP network is configured by a plurality of local IP networks and a relay device that relays between the local IP networks, and for subscriber apparatuses used by subscribers of the wide area IP network, A local IP address (an IP address whose uniqueness is guaranteed only in the local IP network to which the subscriber apparatus belongs) is assigned. In other words, the same IP address is assigned to subscriber devices belonging to different local IP networks.

  At this time, even if a certain subscriber device acquires the IP address of another subscriber device as a communication partner using a mechanism such as DNS (Domain Name System) and transmits a packet to this IP address. When the communication partner subscriber device belongs to a different local IP network, the packet is not transferred to the communication partner subscriber device. Therefore, in order to realize communication between subscriber devices belonging to different local IP networks, the relay device is provided with a NAPT function, and the relay device executes the NAPT function.

  Even if such NAPT is combined with the “IPsec UDP capsule method” which is a conventional tunnel communication technology, a wide-area IP address must be assigned to the destination tunnel communication device. In this case, even if “Dynamic DNS” is used, only the number of wide-area IP addresses required for the number of tunnel communication devices in operation (excluding the exclusive use of the originating tunnel communication device) is required. If the scale reaches tens of millions, a situation where a wide area IP address is insufficient will eventually occur. The tunnel communication system according to the present invention also solves this point.

  In the tunnel communication system according to the first embodiment, as described above, the tunnel communication is performed in the data transfer performed with the originating side tunnel communication device and the destination side tunnel communication device respectively connected to the network performing IP communication as communication partners. When applied, the outline is that the path control device controls the virtual path used for data transfer. In a network such as a wide area IP network, the transfer resource is controlled and path hijacking is prevented. The main feature is to realize tunnel communication. In the first embodiment, an identifier (electrical communication number) of a communication partner is acquired in the path generation procedure, and mutual authentication is performed using a shared key held in association with the acquired identifier, so that communication in the path generation procedure is performed. In this embodiment, the matching relationship between the partner and the communication partner in tunnel communication is verified to prevent path hijacking.

  This main feature will be briefly described. First, although not shown, the originating side tunnel communication device and the destination side tunnel communication device in the first embodiment are electrically connected to each other on the wide area IP network. A communication number and a shared key, which is key information shared in advance between communication partners, are stored in association with each other. That is, the originating side tunnel communication apparatus holds the telecommunications number ("Incoming-ID" in FIG. 1) of the destination side tunnel communication apparatus and the shared key in association with each other. It is assumed that the telecommunication number of the communication device (“calling-ID” in FIG. 1) and the shared key are held in association with each other.

  Under such a configuration, the tunnel communication system according to the first embodiment, as shown in FIG. 1, first, the originating side tunnel communication device includes a path generation request (including the telecommunications number of the destination side tunnel communication device, A message requesting to generate a virtual path with the destination tunnel communication apparatus) is transmitted to the path control apparatus (see (1) in FIG. 1). For example, the calling side tunnel communication device uses the SIP (Session Initiation Protocol) INVITE to indicate the telecommunications number of the called side tunnel communication device, the calling side undisclosed IP address and the calling side undisclosed port number that are not disclosed on the wide area IP network. It is transmitted to the path control device in a form added to the message.

  Then, the path control device receives a path generation request from the originating tunnel communication device (see (2) in FIG. 1), and then transfers data between the originating tunnel communication device and the terminating tunnel communication device. The virtual path is generated by setting the transfer resource necessary for (see (3) in FIG. 1). For example, the path control device receives the calling party non-disclosure IP address and the calling party non-disclosure port number included in the path generation request, and the combination of the received calling party non-disclosure IP address and calling party non-disclosure port number, The conversion between the combination of the originating side disclosed IP address and the originating side disclosed port number (disclosed on the wide area IP network) selected in association with is set in a network device such as a gate router having a NAPT function. Set the transfer resource by doing so to generate a virtual path.

  After that, the path control device uses the virtual path partner device as a communication partner of each of the originating side tunnel communication device and the destination side tunnel communication device when the virtual path is generated, information for checking each other's virtual path partner device. 1 is transmitted to each of the originating tunnel communication device and the terminating tunnel communication device (see (4) in FIG. 1). For example, the path control device transmits, as path generation partner verification information, a telecommunication number (“source-ID” or “destination-ID” in FIG. 1) that uniquely identifies the virtual path partner device on the wide area IP network. . The path control apparatus according to the first embodiment transmits the path generation partner verification information, and transmits the originating side disclosed IP address and the originating side disclosed port number to the terminating side tunnel communication apparatus. The side non-disclosure port number is transmitted to the originating side tunnel communication apparatus. In the first embodiment, the method of transmitting the identifier of the virtual path partner device as the path generation partner verification information has been described. However, the path generation partner verification, such as the method of transmitting the key exchange information generated by the virtual path partner device, etc. Any information may be exchanged as information.

  Then, the originating side tunnel communication device and the destination side tunnel communication device receive the path generation partner verification information from the path control device (see (5) in FIG. 1). For example, the calling-side tunnel communication apparatus receives “Called-ID” as the path generation partner verification information, and the called-side tunnel communication apparatus receives “Called-ID” as the path generation partner verification information. Then, a session is established between the originating side tunnel communication device and the destination side tunnel communication device. In the originating side tunnel communication device, the identifier (electric communication number) of the destination side tunnel communication device added by the own device to the path generation request may be used as the path generation partner verification information.

  Subsequently, the originating side tunnel communication device and the terminating side tunnel communication device have generated mutual authentication information used for mutual authentication (reciprocal authentication with the tunnel communication partner device that is the communication counterpart in tunnel communication). The virtual path is used to exchange with the tunnel communication partner apparatus (see (6) in FIG. 1). For example, the calling-side tunnel communication device transmits information generated using a shared key held in advance in association with “Called-ID” to the called-side tunnel communication device as mutual authentication information. Transmits the information generated using the shared key held in advance in association with the “originating-ID” as mutual authentication information to the originating tunnel communication device.

  Then, the originating tunnel communication device and the terminating tunnel communication device are configured so that the tunnel communication partner device is based on the telecommunication number included in the path generation request or the telecommunication number received from the path control device and the mutual authentication information. It is determined whether it is the same as the pass partner device (see (7) in FIG. 1). For example, the calling side tunnel communication apparatus verifies the mutual authentication information ("Called-Mutual Authentication" in FIG. 1) acquired from the called side tunnel communication apparatus using a shared key, and the called side tunnel communication apparatus The mutual authentication information acquired from the side tunnel communication device (“source-mutual authentication” in FIG. 1) is verified using the shared key.

  As a result, if the originating tunnel communication device or the terminating tunnel communication device determines that the tunnel communication partner device is not the same as the virtual path partner device, it determines that the tunnel communication establishment is rejected and does not establish the tunnel communication. Reject (see (8) in FIG. 1). For example, if the result of verifying the mutual authentication information using the shared key is a failure, the originating tunnel communication device and the terminating tunnel communication device determine that they are not the same, reject the establishment of the tunnel communication, Prevent hijacking.

  On the other hand, when determining that the tunnel communication partner device is the same as the virtual path partner device, the source tunnel communication device and the destination tunnel communication device determine that the tunnel communication is to be established, and transmit / receive tunnel communication data ( (See (9) in FIG. 1). For example, the originating tunnel communication device generates tunnel communication data from original data that is data to be transmitted to the destination tunnel communication device, and transmits the tunnel communication data to the destination tunnel communication device using a virtual path, When tunnel communication data is received from the destination tunnel communication device using the virtual path, the original data is extracted from the tunnel communication data.

  In this manner, the tunnel communication system according to the first embodiment can realize tunnel communication in a network such as a wide area IP network while controlling transfer resources and preventing path hijacking. .

[Configuration of Tunnel Communication System According to Embodiment 1]
Next, the configuration of the tunnel communication system according to the first embodiment will be described with reference to FIGS. FIG. 2 is a block diagram illustrating a configuration of the tunnel communication system according to the first embodiment, FIG. 3 is a diagram for explaining an address storage unit, and FIG. 4 is a diagram for explaining a number table unit. 5 is a diagram for explaining the server address table unit, FIG. 6 is a diagram for explaining the device address table unit, and FIG. 7 is a diagram for explaining the signal unit. FIG. 8 is a diagram for explaining the PSK table section.

  First, the configuration of the tunnel communication system according to the first embodiment will be described with reference to FIG. First, as shown in FIG. 2, the originating side tunnel communication device 20 and the destination side tunnel communication device 10 are each connected to a wide area IP network via an access line. Here, the originating side tunnel communication device 20 and the destination side tunnel communication device 10 are assigned telecommunications numbers as wide area identifiers (identifiers assigned to each apparatus so that the uniqueness is maintained throughout the wide area IP network). It has been. This wide area identifier is assigned by the tunnel communication apparatus to designate the communication partner in the session establishment procedure (path generation procedure) in which the tunnel communication apparatus establishes a session with the communication partner. Further, a local IP address (an IP address whose uniqueness is guaranteed only in the local IP network to which the tunnel communication device belongs) is assigned to the originating side tunnel communication device 20 and the destination side tunnel communication device 10 by a wide area IP network operator. It has been. In the following, the telecommunications number of the originating tunnel communication device 20 is represented as “N202”, the local IP address is represented as “LA202”, the telecommunications number of the terminating tunnel communication device 10 is “N102”, and the local IP address is “LA102”. ”.

  In the first embodiment, a method for assigning a telecommunication number as a wide area identifier will be described. However, the present invention is not limited to this. For example, a character string format such as an Internet host name is used. As long as the identifier is assigned to each device so that uniqueness is maintained in the entire wide area IP network, any specific form of identifier may be used.

  Further, “PA20” is assigned to the originating tunnel communication device 20 by the user and “PA10” is assigned to the destination tunnel communication device 10 by the user as the IP address of the private IP network managed by the user. “PA20” and “PA10” are IP addresses managed by the user, regardless of whether they are public IP addresses or private IP addresses in the Internet address operation rules. In the following embodiments, such an IP address is called a user IP address.

  Next, the wide area IP network will be described. The wide area IP network in the first embodiment includes a local IP network 200, a relay device 300, and a local IP network 100 as shown in FIG. A local router 230 is provided in the local IP network 200, and a local router 130 is provided in the local IP network 100, and performs IP routing based on the local IP address and IP routing based on the wide area IP address. The local router 230 and the local router 130 can be realized by a commercially available IP router or the like.

  The relay device 300 includes a core router 310, a gate router 220, and a gate router 120. The relay device 300 performs IP routing based on the wide area IP address. The gate router 220 and the gate router 120 have a NAPT function. The gate router 220 relays with the local IP network 200 while performing a NAPT process between the local IP address of the local IP network 200 and the wide area IP network address. Packets are transferred to and from the device 300. The gate router 120 transfers a packet between the local IP network 100 and the relay device 300 while performing a NAPT process between the local IP address of the local IP network 100 and the wide area IP network address. The gate router 220 and the gate router 120 have NAPT wide-area IP addresses set in advance. For example, the wide address “WA200” is set in the gate router 220, and the wide address “WA100” is set in the gate router 120. The core router 310, the gate router 220, and the gate router 120 can be realized by a commercially available IP router or the like.

  Incidentally, in the tunnel communication system according to the first embodiment, as shown in FIG. 2, the path control device 210, the path control device 110, the gate router 220, the gate router 120, the local router 230, and the local router 130 are provided. The core router 310, the originating side tunnel communication device 20, and the destination side tunnel communication device 10 are provided. In the following description, among these devices, the path control is particularly relevant to the present invention. The device 210, the path control device 110, the gate router 220, the gate router 120, the originating side tunnel communication device 20, and the destination side tunnel communication device 10 will be described.

[Path control device 210 and path control device 110]
The path control device 210 according to the first embodiment is a device that controls a virtual path used for data transfer when tunnel communication is applied to data transfer, and particularly as closely related to the present invention, FIG. As shown in FIG. 5, a signal unit 211, an address storage unit 212, and a path control unit 213 are provided. The path control device 210 can be realized by installing programs corresponding to these units in a general-purpose server computer having a TCP / IP communication function. The signal unit 211 has a function as a “path generation request receiving unit” or a “path generation partner collation information transmitting unit” described in the claims, and the path control unit 213 is described in the claims. A function as “path generation means” is provided.

  The signal unit 211 includes a general library for SIP communication, and transmits and receives signals and the like necessary for establishing a session with the originating side tunnel communication device 20 and the destination side tunnel communication device 10. is there.

  The address storage unit 212 is a unit that stores in advance various information used by the path control device 210. In particular, as shown in FIG. 3, the number table unit 212a and the server are closely related to the present invention. An address table unit 212b and a device address table unit 212c are provided. In the first embodiment, a method in which the path control device 210 includes the address storage unit 212 will be described. However, the present invention is not limited to this, and the address storage unit 212 is provided independently of the path control device 210. The present invention can be similarly applied to the technique.

  The number table unit 212a is a unit that stores in advance the correspondence between the range of telecommunication numbers and the path control device. For example, the number table unit 212a stores a telecommunication number and a path control device in association with each other as shown in FIG. Referring to the example of FIG. 4, the tunnel communication device whose upper two digits of the telecommunication number is “03” or “04” is accommodated in the path control device 110, and the upper two digits of the telecommunication number is “06”. This indicates that the path communication device 120 accommodates the tunnel communication device.

  The server address table unit 212b is a unit that stores in advance the wide area IP address of another path control device. For example, as shown in FIG. 5, the server address table unit 212b stores a path control device and a wide area IP address in association with each other. Referring to the example of FIG. 5, FIG. 5A shows an example of the server address table unit 212b of the path control device 210, and shows that the wide area IP address of the path control device 110 is “WA101”. ing.

  The device address table unit 212c is a unit that stores in advance a correspondence relationship between a telecommunication number of a device accommodated in the path control device 210 and a local IP address. For example, as shown in FIG. 6, the device address table unit 212 c stores a device telecommunication number and a local IP address in association with each other. Referring to the example of FIG. 6, FIG. 6A is an example of the device address table unit 212c of the path control device 210, but is a device with the telecommunication number “N202” and is accommodated in the path control device 210. This indicates that the local IP address of the device is “LA202”.

  Returning to FIG. 2, the path control unit 213 is a unit that generates a virtual path that is a route through which data is transferred. Specifically, when the path control unit 213 receives a path generation request from the originating tunnel communication device 20, the path control unit 213 sets transfer resources necessary for data transfer between the originating tunnel communication device 20 and the terminating tunnel communication device 10. A virtual path is generated by setting. The specific processing by the path control unit 213 will be described in detail later when the processing procedure by the tunnel communication apparatus according to the first embodiment is described.

  Incidentally, the path control device 110 according to the first embodiment is also a device that controls a virtual path used for data transfer when tunnel communication is applied to data transfer, as with the path control device 210. The same part is provided. Therefore, only the address storage unit 112 of the path control device 110 will be briefly described.

  Similar to the address storage unit 212, the address storage unit 112 is a unit that stores in advance various information used by the path control device 110. As shown in FIG. A number table unit 112a, a server address table unit 112b, and a device address table unit 112c are provided.

  Similar to the number table unit 212a, the number table unit 112a is a unit that previously stores a correspondence relationship between the range of telecommunication numbers and the path control device. Similarly to the server address table unit 212b, the server address table unit 112b is a unit that stores a wide-area IP address of another path control device. In the example of FIG. 5, FIG. 110 is an example of the server address table unit 112b, which indicates that the wide area IP address of the path control device 210 is “WA201”.

  Similar to the device address table unit 212c, the device address table unit 112c is a unit that stores in advance the correspondence between the telecommunication number of the device accommodated in the path control device 110 and the local IP address, and will be described with reference to the example of FIG. 6B is an example of the device address table unit 112c of the path control device 110. The local IP address of the device having the telecommunication number “N102” and accommodated in the path control device 110 is shown in FIG. Indicates “LA102”.

[Gate Router 220 and Gate Router 120]
The gate router 220 according to the first embodiment is an apparatus that transfers data between the local IP network 200 and the relay apparatus 300 while performing a NAPT process between the local IP address of the local IP network 200 and the wide area IP network address. In particular, as closely related to the present invention, as shown in FIG. 2, a transfer resource setting unit 221, a transfer control unit 222, and a transfer unit 223 are provided. The gate router 220 can be realized by a commercially available IP router or the like, and needs to have a NAPT function and an interface (I / F) for receiving a NAPT generation process from an external device.

  The transfer resource setting unit 221 is a unit that sets, in the transfer control unit 222, transfer resources necessary for tunnel communication that is performed with the originating side tunnel communication device 20 and the destination side tunnel communication device 10 as communication partners. The transfer control unit 222 is a unit that controls the transfer unit 223 so as to transfer data according to the settings set by the transfer resource setting unit 221. In the first embodiment, the transfer control unit 222 has a NAPT function. However, when other control such as bandwidth control or filtering control is performed as transfer resource control, the transfer control unit 222 has other than the NAPT function. Functions (such as functions corresponding to bandwidth control and filtering control) are provided. The transfer unit 223 is a unit that transfers data under the control of the transfer control unit 222. The specific processing by the gate router 220 will be described in detail later when the processing procedure by the tunnel communication apparatus according to the first embodiment is described.

  By the way, the gate router 120 in the first embodiment also performs the NAPT processing between the local IP address of the local IP network 100 and the wide-area IP network address, similarly to the gate router 220, while the local IP network 100 and the relay device 300. , And the same unit as that of the gate router 220. Therefore, the description of the gate router 120 will be omitted.

[Originating tunnel communication device 20]
The originating side tunnel communication device 20 according to the first embodiment is a device that performs tunnel communication using the destination side tunnel communication device 10 as a communication partner, and particularly as closely related to the present invention, as shown in FIG. Unit 21, tunnel communication unit 22, packet transmission / reception unit 23, PSK table unit 24, and mutual authentication unit 25. Such calling-side tunnel communication device 20 can be realized by installing programs corresponding to these units in a personal computer or the like. The tunnel communication unit 22 has a function as a “tunnel data transmitting unit” or “tunnel data receiving unit” described in the claims, and the mutual authentication unit 25 includes the “mutual authentication” described in the claims. It has a function as “information exchange means” and a function as “tunnel communication establishment rejection means”.

  The signal unit 21 includes a general library for SIP communication, and is a unit that transmits and receives signals and the like necessary for establishing a session with the path control device 210. The signal unit 21 stores in advance the wide area IP address of the path control device of the accommodated IP network. For example, the signal unit 21 stores the wide area IP address “WA201” of the path control device 210 as shown in FIG.

  The tunnel communication unit 22 is a unit that generates a packet for tunnel communication. The packet transmitting / receiving unit 23 includes a general library for IP communication, and a packet generated by the tunnel communication unit 22 for tunnel communication (for example, a packet encapsulated in a UDP / IP packet) is transferred to the local router 230. It is a part which transmits / receives between them.

  The PSK table unit 24 is a unit that stores in advance a correspondence relationship between the telecommunication number of another tunnel communication device and the shared key. For example, as shown in FIG. 8, the PSK table unit 24 stores a telecommunication number and a shared key in association with each other. Referring to the example of FIG. 8, FIG. 8A is an example of the PSK table unit 24 of the originating side tunnel communication apparatus 20, and is identified from the originating side tunnel communication apparatus 20 by the electric communication number “N102”. This indicates that the shared key shared with the called-side tunnel communication device 10 is “K”.

  The mutual authentication unit 25 is a unit that performs mutual authentication between the calling-side tunnel communication device 20 and the called-side tunnel communication device 10. By the way, a keyed hash function algorithm used for mutual authentication by the mutual authentication unit 25, a Diffie-Helman algorithm for calculating a session key, and an encryption algorithm for protecting a tunnel communication packet are preliminarily used in a wide area IP network. It shall be specified. However, these algorithms may be dynamically determined by a path generation procedure, message exchange at the start of tunnel communication, or the like. Note that specific processing by these units will be described in detail later when the processing procedure by the tunnel communication apparatus according to the first embodiment is described.

[Destination Tunnel Communication Device 10]
The destination-side tunnel communication device 10 according to the first embodiment is a device that performs tunnel communication using the originating-side tunnel communication device 20 as a communication partner, and particularly as closely related to the present invention, as shown in FIG. Unit 11, tunnel communication unit 12, transfer unit 13, PSK table unit 14, and mutual authentication unit 15. The destination tunnel communication device 10 can be realized by installing programs corresponding to these units in a broadband router or the like. Since the incoming side tunnel communication device 10 includes the same units as the outgoing side tunnel communication device 20, only the signal unit 11 and the PSK table unit 14 will be described briefly.

  Similar to the signal unit 21, the signal unit 11 includes a general library for SIP communication, and is a unit that transmits and receives signals and the like necessary for establishing a session with the path control device 110. As shown in FIG. 7B, the wide area IP address “WA101” of the path control device 110 is stored.

  Similar to the PSK table unit 24, the PSK table unit 14 is a unit that stores in advance the correspondence relationship between the telecommunication numbers of other tunnel communication devices and the shared key. ) Is an example of the PSK table unit 14 of the destination side tunnel communication device 10, but is shared between the destination side tunnel communication device 10 and the source side tunnel communication device 20 identified by the electric communication number “N202”. This indicates that the shared key is “K”. Note that specific processing performed by the units included in the destination-side tunnel communication device 10 will be described in detail later when a processing procedure performed by the tunnel communication device according to the first embodiment is described.

[Processing Procedure by Tunnel Communication System According to Embodiment 1]
Next, a processing procedure by the tunnel communication system according to the first embodiment will be described with reference to FIGS. FIG. 9 is a sequence diagram illustrating a processing procedure performed by the tunnel communication system according to the first embodiment, and FIGS. 10 and 11 are diagrams for explaining transfer resource control (NAPT coupling). 16 is a diagram for explaining mutual authentication, FIGS. 17 and 18 are diagrams for explaining tunnel communication, and FIG. 19 is a diagram for explaining an embodiment in which the tunnel communication device is an application GW. It is a figure for doing.

  In the present invention, as shown in FIG. 9, a session is established after a session establishment procedure (path generation procedure), which is a procedure for establishing a session between the originating tunnel communication device 20 and the terminating tunnel communication device 10. Then, a mutual authentication procedure for performing mutual authentication between the originating side tunnel communication device 20 and the destination side tunnel communication device 10 continues, and then tunnel communication is started.

  Here, the necessity of mutual authentication performed between the originating side tunnel communication apparatus 20 and the terminating side tunnel communication apparatus 10 will be briefly described. Mutual authentication is for mutual authentication with a communication partner for the purpose of ensuring security when tunnel communication is realized. That is, even if the tunnel communication system generates a path by the path generation procedure, an unauthorized device that intercepts the generation of the path stops the valid device by some attack, and then uses the IP address of this device This is because threats such as an attack that uses a path on behalf of a device (path hijacking) and a man-in-the-middle attack that eavesdrops and tampers with a packet transferred on the path by some means are still considered to exist. A specific method of mutual authentication is defined by IKE (Internet Key Exchange) (see IETF RFC-2409) or the like, and “a method using a preset shared key” or “a public key certificate is used”. Scheme (PKI: Public Key Infrastructure) ". In the following first embodiment, a “method using a preset shared key” is adopted.

  In the normal “method using a pre-set shared key”, each tunnel communication apparatus associates the IP address of the tunnel communication apparatus with the shared key for each tunnel communication apparatus that can be a communication partner. Each of the tunnel communication devices is stored in advance and selects a shared key based on the IP address of the communication partner during mutual authentication. However, as in the first embodiment, when NAPT is executed in the wide area IP network, since the IP address of the communication partner is dynamically assigned, a method for storing in advance the correspondence between the IP address and the shared key Can not cope. The tunnel communication system according to the first embodiment also solves this point.

  The processing procedure of the tunnel communication system according to the first embodiment will be specifically described below. First, the originating side tunnel communication device 20 activates the tunnel communication unit 22 when the user using the originating side tunnel communication device 20 designates the electrical communication number “N102” of the destination side tunnel communication device 10. When the originating side tunnel communication device 20 stores the telecommunication number of the destination side tunnel communication device 10 in advance, the originating side tunnel communication device 20 does not specify the telecommunication number, and the originating side tunnel communication device 20 The communication unit 22 is activated (that is, the user may not need to input the telecommunication number).

  Next, the originating side tunnel communication device 20 generates a path generation request including the telecommunication number “N102” of the destination side tunnel communication device 10, and transmits this path generation request to the path control device 210 (step S210). .

  For example, the originating tunnel communication device 20 generates a message including the telecommunication number “N102” of the called tunnel communication device 10 in the To field of the SIP INVITE message as a path generation request.

  The originating side tunnel communication device 20 uses SIP SDP data for the purpose of indicating that the communication to be executed is tunnel communication and uses “4500 / UDP” as the local IP port number for tunnel communication. The line “m = application 4500 udp x-ngn-dial-up” is described. If it is clear in advance that the communication to be executed is a tunnel communication and that “4500 / UDP” is used as the local IP port number, it is not necessary to describe this m line. .

  Further, the originating side tunnel communication device 20 describes the line “LA202” in the c line as SDP data for the purpose of indicating that “LA202” is used as the local IP address for tunnel communication. If it is clear in advance that “LA202” will be used as the local IP address by a previous procedure, or if the path control device 210 can acquire the local IP address by another means, this c line is described. You don't have to. For example, the path control device 210 refers to the device address table unit 212c and acquires the local IP address corresponding to the telecommunication number in the FROM header of the INVITE, or the same value as the originating IP address of the SIP message. A method that is considered to be considered.

  In addition, the originating tunnel communication device 20 may describe a telephone value as the SDP value. In this case, on the wide area IP network side, a communication path is established using this communication as an IP telephone call. However, the outgoing side tunnel communication device 20 and the incoming side tunnel communication device 10 use tunnel communication data in the payload of the UDP / IP packet. Will be described.

  Then, the originating tunnel communication device 20 determines that the generated path generation request (INVITE message) is UDP / IP, assuming that the UDP port number for path control is “5060” and the destination IP address is “WA201”. A packet is transmitted to the path control device 210.

  Next, the path control apparatus 210 that has received the path generation request performs path generation. Specifically, the path control apparatus 210 acquires the local IP address “LA202” for tunnel communication of the originating tunnel communication apparatus 20 from the SDP data c line of the INVITE message, and the local port number “LP2021” is m lines. ("4500 / UDP" is obtained).

  Then, the path control device 210 requests the gate router 220 to generate a NAPT binding for tunnel communication (NAPT binding) using the local IP address “LA202” and the local port number “LP2021” as arguments (step S211).

  Then, the gate router 220 selects an unused UDP port number “WP2021” for the NAPT wide area IP address “WA200” and sets this as the requested wide area port number of the NAPT coupling. Then, the gate router 220 registers (LA202: LP2021, WA200: WP2021) as NAPT coupling. Here, in the first embodiment, NAPT coupling is expressed in the format of (LA: LP, WA: WP). For example, in this notation example, when the gate router 220 receives an L4 packet (a packet that can be identified by a port number, a layer 4 packet) having a source IP address “LA” and a source port number “LP”, the destination address Is rewritten to “LA” and the destination port number is rewritten to “LP” for transfer.

  Subsequently, the gate router 220 transmits the wide area IP address “WA200” and the wide area port number “WP2021” to the path control device 210 as a response to the NAPT coupling generation request (step S212).

  Then, the path control device 210 rewrites the port number in the m-th line of the INVITE message to “WP2021”, and rewrites the IP address in the c-line to “WA200”. Then, the path control device 210 refers to the number table unit 212a based on the telecommunication number “N102” of the called-side tunnel communication device 10 indicated by the To header in the INVITE message, and the path control device 110 that is the transfer destination of the INVITE message. To decide. Thereafter, the path control device 210 refers to the IP address of the transfer destination path control device (path control device 110) from the server address table unit 212b, and transmits an INVITE message to the acquired IP address “WA101” (step S220). ).

  Subsequently, the path control device 110 extracts the telecommunication number “N102” of the destination tunnel communication device 10 from the To field of the INVITE message, and uses the local IP address corresponding to this telecommunication number “N102” as the device address. The INVITE message is transmitted to the acquired IP address “LA102” referring to the table unit 112c (step S230).

  Then, the receiving side tunnel communication apparatus 10 that has received the INVITE message first acquires from the m line of the INVITE message that this SIP communication is for tunnel communication, and activates the tunnel communication unit 12. That is, the destination side tunnel communication device 10 extracts the electrical communication number “N202” of the source side tunnel communication device 20 from the From header or P-Asserted-Identity header of the INVITE message (at this time, the destination side tunnel communication device 10 Can be said to have received the path generation partner verification information from the path control device 110), and extract the calling party disclosure port number “WP2021” from the m-th line of the SDP and extract the calling party disclosure IP address “WA200” from the c line. . Furthermore, the destination-side tunnel communication device 10 selects “LP1021” as the tunnel communication UDP port number of the destination-side tunnel communication device 10. As this selection algorithm, there may be a method of selecting a fixed value (such as “4500”), a method of selecting an unused port number, or the like. Then, the incoming side tunnel communication device 10 activates the tunnel communication unit 12 using these parameters as arguments.

  Then, the incoming side tunnel communication device 10 transmits a response message in response to the INVITE message to the path control device 110 (step S240). That is, the destination side tunnel communication apparatus 10 describes the UDP port number “LP1021” for tunnel communication of the destination side tunnel communication apparatus 10 in the m line as SDP data of the response message, and the destination side tunnel communication apparatus 10 in the c line. The IP address “LA102” is described.

  Next, the path control device 110 extracts the local IP address “LA102” and the local port number “LP1021” for tunnel communication of the destination tunnel communication device 10 from the SDP data of the received response message. If the path control device 110 has another means for acquiring the local IP address and local port number of the destination tunnel communication device 10, description of the c and m lines in the response message may be omitted. it can. For example, there may be a method of fixing the local port number to “4500”. As for the local IP address, there may be a method in which the path control device 110 uses the source IP address of the response message or a method of acquiring from the device address table unit 112c.

  Next, the path control apparatus 110 that has received the path generation response performs path generation. Specifically, the path control device 110 acquires the local IP address “LA102” for tunnel communication of the destination tunnel communication device 10 from the SDP data c line of the INVITE response message, and sets the local port number “LP1021” to m. Obtain from the line ("4500 / UDP" is obtained).

  Then, the path control device 110 requests the gate router 120 to generate a tunnel communication NAPT connection using the local IP address “LA102” and the local port number “LP1021” as arguments (step S241).

  Then, the gate router 120 selects an unused UDP port number “WP1021” for the NAPT wide area IP address “WA100”, and sets this as the wide area port number of the requested NAPT coupling. Then, the gate router 120 registers (LA102: LP1021, WA100: WP1021) as NAPT coupling.

  Subsequently, the gate router 120 transmits the wide area IP address “WA100” and the wide area port number “WP1021” to the path control device 110 as a response to the NAPT coupling generation request (step S242).

  Then, the path control device 110 rewrites the port number in the m-th line of the INVITE response message to “WP1021”, and rewrites the IP address in the c-line to “WA100”. Then, the path control device 110 refers to the number table unit 112a based on the telecommunication number “N202” of the originating tunnel communication device 20 indicated by the To header in the INVIT response message, and performs path control as a transfer destination of the INVITE response message. Device 210 is determined. After that, the path control device 110 refers to the IP address of the transfer destination path control device (path control device 210) from the server address table unit 112b, and transmits an INVITE response message to the acquired IP address “WA201” (step). S250).

  Subsequently, the path control device 210 extracts the telecommunication number “N202” of the originating tunnel communication device 20 from the To field of the INVITE response message, and sets the local IP address corresponding to this telecommunication number “N202” to the device. The INVITE response message is transmitted to the acquired IP address “LA202” by referring to the address table unit 212c (step S260). Thus, a session is established between the originating side tunnel communication device 20 and the destination side tunnel communication device 10.

  That is, as shown in FIG. 9, in the first embodiment, the procedure from step S210 to step S260 is a session establishment procedure and is a path generation procedure. In other words, in the tunnel communication system according to the first embodiment, the path control device 210 and the path control device 110 are established in step S260 between the originating side tunnel communication device 20 and the destination side tunnel communication device 10. A path generation request for generating a virtual path is received from the originating tunnel communication device 20, and setting of transfer resources necessary for data transfer between the originating tunnel communication device 20 and the terminating tunnel communication device 10 is performed. This is characterized in that a virtual path is generated (in the first embodiment, NAPT connection setting registration is performed).

  Accordingly, when the procedure for setting and registering the NAPT connection is confirmed again, it becomes as shown in FIG. 10 and FIG. That is, as shown in FIG. 10, the originating side tunnel communication device 20 is assigned “LA202” as the originating side undisclosed IP address (local IP address) that is not disclosed on the wide area IP network, and the originating side undisclosed port “LP2021” is assigned as the number (local port number) (see (1) in FIG. 10).

  The originating side tunnel communication device 20 transmits the originating side undisclosed IP address “LA202” and the originating side undisclosed port number “LP2021” to the path control device 210 in the form of adding to the INVITE message ((2 in FIG. 10). )).

  Then, the path control device 210 transmits the originating side non-disclosure IP address “LA202” and the originating side nondisclosure port number “LP2021” to the gate router 220 (see (3) in FIG. 10). By performing NAPT binding (see (4) in FIG. 10), the originating side disclosed on the network so as to correspond to the originating side undisclosed IP address “LA202” and the originating side undisclosed port number “LP2021”. The disclosed IP address “WA200” and the originating side disclosed port number “WP2021” are acquired (see (5) in FIG. 10).

  Subsequently, the path control device 210 rewrites the originating side non-disclosure IP address “LA202” in the INVITE message with the originating side disclosure IP address “WA200”, and changes the originating side nondisclosure port number “LP2021” to the originating side disclosure port number “LP2021”. WP2021 ”(see (6) in FIG. 10) and transmitted to the path control device 110 (see (7) in FIG. 10), and the path control device 110 transfers to the destination tunnel communication device 10 (see FIG. 10). (See (8) in FIG. 10).

  Similarly, as shown in FIG. 11, the called-side tunnel communication apparatus 10 is given “LA102” as a called-side undisclosed IP address (local IP address) that is not disclosed on the wide-area IP network. “LP1021” is assigned as a port number (local port number) (see (1) in FIG. 11).

  The destination-side tunnel communication device 10 transmits the destination-side non-disclosure IP address “LA102” and the destination-side non-disclosure port number “LP1021” to the path control device 110 in a form that is added to the INVITE response message ((( See 2)).

  Then, the path control device 110 transmits the called side non-disclosure IP address “LA102” and the called side non-disclosure port number “LP1021” to the gate router 120 (see (3) in FIG. 11). With NAPT binding (see (4) in FIG. 11), the called side disclosed on the network so as to correspond to the called side non-disclosure IP address “LA102” and the called side non-disclosure port number “LP1021”. The disclosed IP address “WA100” and the called party disclosed port number “WP1021” are acquired (see (5) in FIG. 11).

  Subsequently, the path control device 110 rewrites the called party undisclosed IP address “LA102” in the INVITE response message to the called party disclosed IP address “WA100”, and changes the called party undisclosed port number “LP1021” to the called party disclosed port number. It is rewritten to “WP1021” (see (6) in FIG. 11), transmitted to the path control device 210 (see (7) in FIG. 11), and the path control device 210 transfers it to the originating tunnel communication device 20 (See (8) in FIG. 11).

  Next, returning to FIG. 9, the mutual authentication procedure will be described. Upon receiving the INVITE response message, the originating side tunnel communication device 20 acquires the called side disclosure IP address “WA100” from the c line of the response message, and from the m line. The called party disclosure port number “WP1021” is acquired. Also, the tunnel communication unit 22 is activated using these parameters “WA100” and “WP1021” and the electrical communication number “N102” of the destination tunnel communication device 10 specified in step S210 as arguments. In the first embodiment, a method has been described in which the originating tunnel communication device 20 activates the tunnel communication unit 22 using the telecommunication number “N102” of the terminating tunnel communication device 10 specified in step S210 as an argument. However, the present invention is not limited to this, and the telecommunication number “N102” of the called side tunnel communication device 10 included in the path generation response in step S260 (the called side received as the path generation partner verification information from the path control device 210). The present invention can be similarly applied to a method of starting the tunnel communication unit 22 using the telecommunication number “N102”) of the tunnel communication device 10 as an argument.

  The tunnel communication unit 22 of the originating side tunnel communication device 20 first acquires the shared key “K” corresponding to the telecommunication number “N102” from the PSK table unit 24. Then, the originating side tunnel communication device 20 generates a tunnel communication start request. Specifically, as shown in (1) of FIG. 12, the originating tunnel communication device 20 generates DH public information “DHP202” for generating a shared key (session key) for protecting a tunnel packet, and a DH secret. Information “DHS202” is generated. Then, as shown in (2) of FIG. 12, the originating tunnel communication device 20 uses the DH public information “DHP202” as the main body, and the signature data “SIGN202” for the main body is keyed with the shared key “K”. Obtained by hash function. Then, as shown in (3) of FIG. 12, the calling-side tunnel communication device 20 sends a tunnel communication start request including this main body and signature data “SIGN 202” as a UDP / IP packet to the called-side tunnel communication device. 10 (step S310). The source IP address of the UDP / IP packet is “LA202”, the source port number is “LP2021”, the destination IP address is “WA100”, and the destination port number is “WP1021”.

  It should be noted that other parameters such as the telecommunication number “N202”, the current time value, the random number value, and the tunnel session ID for identifying the tunnel communication may be further included in the main body.

  The UDP packet transmitted in step S310 is received by the destination tunnel communication device 10 via the router on the route. In this process, the gate router 220 rewrites the source IP address to “WA200” and rewrites the source port number to “WP2021”.

  The tunnel communication unit 12 of the destination-side tunnel communication device 10 acquires the shared key “K” corresponding to the telecommunication number “N202” input as an argument at the time of activation from the PSK table unit 14. Then, the destination side tunnel communication device 10 extracts the main body and the signature “SIGN 202” of the source side tunnel communication device 10 from the received tunnel communication start request, and verifies the validity of “SIGN 202” with the shared key “K”. To do. Specifically, as shown in (4) of FIG. 12, the receiving-side tunnel communication device 10 receives the main body and signature data “SIGN 202” from the originating-side tunnel communication device 20, and (5) of FIG. As shown, the signature data “SIGN202. exp ”is obtained by a keyed hash function using the shared key“ K ”, and“ SIGN 202 ”and“ SIGN 202. The validity of “SIGN 202” is verified depending on whether or not “exp” matches. “SIGN202” and “SIGN202. If “exp” does not match and verification fails, the terminating tunnel communication device 10 transmits an error response. At this time, the destination tunnel communication device 10 determines that the tunnel communication partner device that is the communication partner in the tunnel communication is not the same as the virtual path partner device that was the communication partner when the virtual path is generated. It is determined that the establishment of communication is rejected, and the establishment of tunnel communication is rejected. The transmission of this error response corresponds to the operation of rejecting the establishment of tunnel communication.

  “SIGN202” and “SIGN202. exp "matches and it is verified that the signature data" SIGN 202 "is valid, the called-side tunnel communication device 10 uses the shared key for protecting the tunnel packet as shown in (2) of FIG. DH public information “DHP102” and DH secret information “DHS102” for generating the DH public information “DHP202” extracted from the tunnel communication start request as shown in FIG. From the DH secret information “DHS102” generated by the side tunnel communication device 10, the session key KS is obtained by the Diffie-Helman key exchange algorithm.

  Next, the destination tunnel communication device 10 generates a tunnel communication start response. Specifically, the incoming side tunnel communication device 10 generates a response code “RESP-OK” indicating a normal response. Then, as shown in (1) of FIG. 14, the called-side tunnel communication device 10 has already generated DH public information “DHP102” and DH secret information “DHS102” for generating a shared key for protecting tunnel packets. Therefore, as shown in (2) of FIG. 14, DH public information “DHP102” is used as a main body, and signature data “SIGN102” for this main body is obtained by a keyed hash function using a shared key “K”. Then, as shown in FIG. 14 (3), the destination side tunnel communication device 10 sends a tunnel communication start response including this main body and signature data “SIGN 102” with a UDP / IP packet as the source side tunnel communication device. 20 (step S320). The source IP address of the UDP / IP packet is “LA102”, the source port number is “LP1021”, the destination IP address is “WA200”, and the destination port number is “WP2021”. The destination-side tunnel communication device 10 may acquire the destination IP address and the destination port number from an argument when the tunnel communication unit 12 is activated, or may acquire it from the source IP address and source port number of the tunnel start request. Good. If the signature data “SIGN 202” is invalid, the response code “RESP-ERR-AUTH” indicating an authentication error is set in step S320, and the response code “RESP-ERR-AUTH” is displayed in the main body. Will be included.

  The UDP packet transmitted in step S320 is received by the originating tunnel communication device 20 via a router on the route. In this process, the gate router 120 rewrites the source IP address to “WA100” and rewrites the source port number to “WP1021”.

  The originating side tunnel communication device 20 extracts the main body and the signature “SIGN102” of the destination side tunnel communication device 10 from the received tunnel communication start response, and verifies the validity of “SIGN102” with the shared key “K”. Specifically, as shown in (4) of FIG. 14, when the originating side tunnel communication device 20 receives the main body and the signature data “SIGN 102” from the destination side tunnel communication device 10, (5) of FIG. As shown in FIG. 2, the signature data “SIGN102. exp ”is obtained by a keyed hash function using the shared key“ K ”, and“ SIGN 102 ”and“ SIGN 102. The validity of “SIGN102” is verified depending on whether or not “exp” matches. “SIGN102” and “SIGN102. When “exp” does not match and verification fails, the originating tunnel communication device 20 transmits an error response. At this time, the originating tunnel communication device 20 determines that the tunnel communication partner device that is the communication partner in tunnel communication is not the same as the virtual path partner device that was the communication partner when the virtual path is generated. It is determined that the establishment of communication is rejected, and the establishment of tunnel communication is rejected. The transmission of this error response corresponds to the operation of rejecting the establishment of tunnel communication.

  “SIGN102” and “SIGN102. When “exp” matches and it is verified that the signature data “SIGN102” is valid, the originating tunnel communication device 20 extracts it from the tunnel communication start response as shown in (3) of FIG. The session key “KS” is obtained from the DH public information “DHP102” and the DH secret information “DHS202” generated by the originating tunnel communication device 20 by the Diffie-Helman key exchange algorithm.

  Then, the originating side tunnel communication device 20 transmits a tunnel communication start response confirmation including a response code “RESP-OK” indicating a normal response to the destination side tunnel communication device 10 (step S330). At this stage, the mutual authentication is completed between the originating tunnel communication device 20 and the terminating tunnel communication device 10, and the session key “KS” is shared.

  Here, when the mutual authentication performed between the originating tunnel communication device 20 and the terminating tunnel communication device 10 is confirmed again, the mutual authentication in the first embodiment is performed as shown in FIG. It can be seen that the destination tunnel communication apparatus 10 and the destination side tunnel communication apparatus 10 hold a shared key set in advance, and only public information and signature data are distributed on the path.

  Thus, the originating side tunnel communication device 20 and the destination side tunnel communication device 10 start tunnel communication (steps S410 and S420). First, as shown in FIG. 17, the originating side tunnel communication device 20 encrypts the IP packet (original data) to be tunneled with the session key “KS”, and includes the encrypted IP packet in the payload of the UDP packet. Do not send. Here, FIG. 17 illustrates a case where the originating tunnel communication device 20 transmits, so that the source IP address is “LA202”, the source port number is “LP2021”, the destination IP address is “WA100”, the destination The port number is “WP1021”.

  Then, as shown in FIG. 17, the gate router 220 rewrites the source IP address to “WA200”, rewrites the source port number to “WP2021”, and the gate router 120 rewrites the destination IP address to “LA102”. The port number is rewritten to “LP1021” and transmitted to the destination tunnel communication device 10. Thereafter, as shown in FIG. 17, the destination tunnel communication device 10 decrypts the payload of the UDP packet with the session key KS to restore the IP packet.

  On the other hand, as shown in FIG. 18, the destination tunnel communication device 10 also encrypts the IP packet (original data) to be tunneled with the session key “KS”, and includes the encrypted IP packet in the payload of the UDP packet. Do not send. Here, FIG. 18 illustrates the case where the destination tunnel communication device 10 transmits, so that the source IP address is “LA102”, the source port number is “LP1021”, the destination IP address is “WA200”, the destination The port number is “WP2021”.

  Then, as shown in FIG. 18, the gate router 120 rewrites the source IP address to “WA100”, rewrites the source port number to “WP1021”, the gate router 220 rewrites the destination IP address to “LA202”, The port number is rewritten to “LP2021” and transmitted to the originating tunnel communication device 20. Thereafter, as shown in FIG. 18, the originating side tunnel communication device 20 decrypts the payload of the UDP packet with the session key KS and restores the IP packet.

  The procedure for mutual authentication and session key generation after step S310 in FIG. 9 is not limited to the above-described method. For example, an IP address and port number determination method based on a method defined by IETF RFC-3947. As described above, the PSK selection method in the IKE phase 1 may be any method such as the method in which the key corresponding to the telecommunication number is acquired from the PSK table unit as described above. Also, the UDP / IP payload format in the tunnel transfer is not limited to the above, and may be a format defined by IETF RFC-3948.

  Also, the user IP address used by the tunnel communication device may be dynamically assigned without being fixed. For example, when step S330 is completed, the originating side tunnel communication device 20 transmits an address assignment request to the terminating side tunnel communication device 10, and the terminating side tunnel communication device 10 transmits the assigned address to the originating side tunnel communication device 20. . At this time, a net mask value and a default gateway address may be transmitted at the same time.

  Further, tunnel communication for establishing a PPP link by a method defined in IETF RFC-1661 may be performed by regarding the path generated in the path generation procedure as the data link layer. At this time, the user IP address used by any of the tunnel communication apparatuses may be “unnumbered” (not assigned).

  In the first embodiment, the path is realized by UDP / IP, but may be realized by TCP / IP. In this case, each of the above port numbers is treated as a TCP port number, and immediately before step S310, the source side tunnel communication apparatus 20 uses the source IP address “LA202” and the port number “LP2021” as the destination IP address. A request to generate a TCP connection is issued to “WA200” and destination port number “WP2021”. This TCP connection generation request arrives at the port number “LP1021” of the destination side tunnel communication apparatus 10, and the destination side tunnel communication apparatus 10 accepts the request and establishes the TCP connection. The message exchange and tunnel transfer after step S310 are executed over the TCP connection.

  In addition, in step S210, the originating side tunnel connection device 20 may describe “m = audio LP2021 RTP / AVP 0” indicating IP phone as the SDP value. In this case, the wide area IP network establishes a communication path using this communication as an IP telephone call. However, the originating side tunnel communication device 20 and the destination side tunnel communication device 10 regard the data for tunnel communication in the UDP / IP payload. Described as RTP data.

  Further, in the first embodiment, the tunnel communication apparatus has described a method in which the tunnel communication apparatus encrypts the entire IP packet and transmits it to the virtual path, but the present invention is not limited to this, and the tunnel communication apparatus The present invention can be similarly applied to a method of relaying communication as an application GW. FIG. 19 shows an example. For example, when the originating side is an HTTP client and tunnel communication with an HTTP server existing on the terminating side LAN is realized, the originating side tunnel communication apparatus has an HTTP proxy function. The destination tunnel communication apparatus is provided with an HTTP reverse proxy function. When the HTTP client transmits an HTTP request (see (1) in FIG. 19), the originating tunnel communication apparatus receives the HTTP request, encrypts the HTTP request, and transmits it to the virtual path (in FIG. 19). (See (2)). The destination tunnel communication device decrypts the HTTP request received via the virtual path (see (3) in FIG. 19), and relays the restored HTTP request to the HTTP server by the HTTP reverse proxy function ((( See 4)). The HTTP response that is the response to the HTTP request is relayed through the reverse route. That is, the HTTP response sent by the HTTP server is received by the HTTP reverse proxy function of the destination tunnel communication device (see (5) in FIG. 19), encrypted, and sent to the virtual path ((6) in FIG. 19). reference). This HTTP response is received and decrypted by the HTTP proxy function of the originating tunnel communication device (see (7) in FIG. 19), and the restored HTTP response is transmitted to the HTTP client ((8) in FIG. 19). See).

[Effect of Example 1]
As described above, according to the first embodiment, tunnel communication is applied to data transfer performed by using the originating side tunnel communication device and the destination side tunnel communication device respectively connected to the network performing IP communication as communication partners. A tunnel communication system in which a control device controls a virtual path used for data transfer, the control device including an identifier that uniquely identifies the destination tunnel communication device on the network; When a path generation request for generating a virtual path is received from the originating tunnel communication device and a path generation request is received, data transfer between the originating tunnel communication device and the destination tunnel communication device is performed. A virtual path is generated by setting the transfer resources required for the path, and a path generation notification for notifying the generation of the virtual path is sent to the originating tunnel communication device. The originating tunnel communication device transmits a virtual path path generation request to the control device, and the originating tunnel communication device and the terminating tunnel communication device send a path generation notification, Mutual authentication information received from the control device and used for mutual authentication that mutually authenticates with the tunnel communication partner device that is the communication partner in tunnel communication is exchanged with the tunnel communication partner device using the virtual path, and tunnel communication is performed. Based on the mutual authentication information acquired from the partner device, it is determined whether to establish or reject tunnel communication with the partner device for tunnel communication. If it is determined to be rejected, the tunnel communication is rejected and tunnel communication is determined to be established. The tunnel communication data is generated from the original data that is the data to be transmitted to the tunnel communication partner device. When the tunnel communication data is transmitted to the tunnel communication partner device using the path and the tunnel communication data is received from the tunnel communication partner device when it is determined to establish the tunnel communication, the original data is received from the tunnel communication data. Therefore, the tunnel communication device can realize tunnel communication in a network such as a wide area IP network by controlling transfer resources and preventing path hijacking.

  In addition, according to the first embodiment, the control device, with respect to the virtual path partner device that is the communication partner of each of the originating tunnel communication device and the destination tunnel communication device when the virtual path is generated, The path generation partner verification information, which is information for verifying the destination, is transmitted to the destination side tunnel communication device or to the destination side tunnel communication device and the source side tunnel communication device, and the source side tunnel communication device and the destination side tunnel communication device are transmitted. The path generation partner verification information is acquired by extracting an identifier from the transmitted path generation request or receiving the path generation partner verification information from the control device, and the acquired path generation partner verification information and the tunnel communication Based on the mutual authentication information acquired from the counterpart device, it is determined whether the tunnel communication counterpart device is the same as the virtual path counterpart device, and the tunnel When it is determined that the counterpart device is not the same as the virtual path counterpart device, it is determined that the tunnel communication is rejected. Therefore, information for checking the communication partner in the path generation procedure, mutual authentication information acquired from the communication partner in the tunnel communication, and Therefore, it is possible to verify the coincidence between the communication partner in the path generation procedure and the communication partner in the tunnel communication, so that the unauthorized device that hijacks the path is called the destination tunnel communication device (or the originating communication device). Even in a case where mutual authentication is possible with the side tunnel communication device), tunnel communication can be realized while preventing path hijacking.

  Further, according to the first embodiment, the network converts between a combination of a non-disclosure IP address and a non-disclosure port number that are not disclosed on the network and a combination of a disclosure IP address and a disclosure port number disclosed on the network. It has a NAPT function, and the calling side tunnel communication device is assigned a calling side non-disclosure IP address and a calling side non-disclosure port number. A combination of the originating side disclosed IP address and the originating side disclosed port number selected in association with the combination of the originating side undisclosed IP address and the originating side undisclosed port number is attached. Combination of destination side non-disclosure IP address and destination side non-disclosure port number Sending the combination of the destination-side disclosed IP address and the destination-side disclosed port number selected in association to the calling-side tunnel communication device, and the combination of the calling-side undisclosed IP address and the calling-side undisclosed port number and the calling side The conversion between the combination of the disclosed IP address and the caller-side disclosed port number is set in the NAPT function, the combination of the callee-side undisclosed IP address and the callee-side undisclosed port number, the callee-side disclosed IP address, and the callee-side disclosed By setting the NAPT function to convert between the combination of port numbers, the virtual resource is generated by setting the transfer resource in the network, and the originating side disclosure IP address and the originating side disclosure sent from the control device A combination of port numbers, or a combination of called party disclosure IP address and called party disclosure port number Exchange the mutual authentication information and send the tunnel communication data using the combination of the calling party disclosure IP address and the calling party disclosure port number transmitted from the control device or the combination of the called party disclosure IP address and the called party disclosure port number. Since the tunnel communication data transmitted and received using the combination of the calling party disclosure IP address and the calling party disclosure port number or the combination of the called party disclosure IP address and the called party disclosure port number is received, the transfer resource control It is also possible to perform IP address control. Further, when the tunnel communication system according to the present invention performs IP address control (NAPT coupling) as control of transfer resources, the IP address of the destination tunnel communication apparatus can also be converted by NAPT. Therefore, it becomes unnecessary to assign a wide area IP address to the destination tunnel communication apparatus, and it is possible to appropriately avoid a situation where the wide area IP address is insufficient in the wide area IP network.

  Further, according to the first embodiment, an identifier for uniquely identifying a communication partner on the network and a shared key that is key information shared in advance with the communication partner are stored in association with each other, and a path generation partner As verification information, an identifier that uniquely identifies the virtual path partner device on the network is acquired by extracting the identifier from the transmitted path generation request or receiving it from the control device, and among the held shared keys Select the shared key associated with the acquired identifier, exchange the information generated using the shared key as mutual authentication information with the tunnel communication partner device, and share the mutual authentication information acquired from the tunnel communication partner device Verify using the key, and if the verification result is unsuccessful, determine that the tunnel communication partner device is not the same as the virtual path partner device, and refuse to establish tunnel communication Therefore, tunnel communication on the path can be protected (for example, message authentication, data encryption, etc.) using a pre-set shared key, and man-in-the-middle attacks on the path Can also be prevented. Also, since the identifier of the communication partner is acquired in the path generation procedure and mutual authentication is performed using the shared key held in association with the acquired identifier, the communication partner in the path generation procedure and the communication partner in the tunnel communication Therefore, even when an unauthorized device that hijacks the path is in a relationship that can be mutually authenticated with the terminating tunnel communication device (or the originating tunnel communication device), It becomes possible to prevent the jack.

  By the way, as Example 1 so far, mutual authentication performed between the originating tunnel communication device and the terminating tunnel communication device has been performed with the communication partner using a “method using a preset shared key”. I have explained the cases that are. Certainly, this method in the first embodiment can solve the problem that “a shared key stored in association with an IP address cannot be selected when NAPT is executed in a wide area IP network”. In addition, since tunnel communication on the path can be protected, man-in-the-middle attacks can be prevented, and path hijacking can be prevented, this is an effective technique. However, in a case where tunnel communication is performed with a communication partner having a temporary relationship, it is difficult for each of the tunnel communication devices to share a preset shared key with the communication partner. There is also a risk. Therefore, in the following, as a second embodiment according to the present invention, a “method using a shared key generated by a path generation procedure” for the purpose of dealing with such a case will be described.

  Here, the background of a case where tunnel communication is performed with a communication partner having a temporary relationship will be briefly described. Conventional tunnel communication has been applied when the relationship between a connectable device and a connection destination LAN is long-term, such as when tunnel communication is performed between a company employee's device and a company LAN. . In the future, for example, when a home appliance manufacturer's maintenance company connects to a consumer's LAN for fault diagnosis of network home appliances, the relationship between the connectable device and the connection destination LAN is temporary. It is hoped that However, in such a temporary relationship, it may be difficult to apply the “method using a preset shared key” for mutual authentication. In addition, mutual authentication can be realized by “Public Key Infrastructure (PKI)”, but it is necessary to install a CA station and distribute certificate revocation information. Compared with the “method using a preset shared key”, the cost becomes high. For this reason, in the second embodiment according to the present invention, it is proposed to realize mutual authentication by a “method using a shared key generated by a path generation procedure”.

  However, if the mutual authentication is realized by the “method using the shared key generated by the path generation procedure”, there is a possibility that a new problem that it is vulnerable to a man-in-the-middle attack in the path generation procedure may occur. For this reason, in Example 2 below, for the purpose of responding to the man-in-the-middle attack in the path generation procedure, the tunnel communication device authenticates the path control device in the path generation procedure, and thereby attempts to perform a man-in-the-middle attack. It avoids sending and receiving messages to and from the control device.

[Outline and Features of Tunnel Communication System According to Embodiment 2]
The outline and characteristics of the tunnel communication system according to the second embodiment will be described with reference to FIG. FIG. 20 is a diagram for explaining the outline and features of the tunnel communication system according to the second embodiment.

  In the tunnel communication system according to the second embodiment, as in the first embodiment, the tunnel communication is performed for data transfer performed by using the originating side tunnel communication device and the destination side tunnel communication device respectively connected to the network performing IP communication as communication partners. Is applied, the path control device controls the virtual path used for data transfer, and the shared key generated in the path generation procedure is used regardless of the method using the preset shared key. The main feature of this method is to protect tunnel communication on the path and prevent hijacking of the path (for example, it is also applicable to cases where tunnel communication is performed with a communication partner with a temporary relationship) it can). In the second embodiment, in the path generation procedure, a parameter (for example, each DH public information) necessary for generating a shared key used when generating mutual authentication information is acquired and generated from the acquired parameter. In this embodiment, mutual authentication is performed using the shared key to verify the coincidence between the communication partner in the path generation procedure and the communication partner in the tunnel communication, thereby preventing path hijacking.

  The main feature will be described. First, in the second embodiment, the PSK table unit 14 is not required in each tunnel communication device. Although not shown, each tunnel communication device and the path control device set a shared key in advance.

  With this configuration, in the tunnel communication system according to the second embodiment, as in the first embodiment, the originating tunnel communication apparatus transmits a path generation request to the path control apparatus (see (1) in FIG. 20). The path control device receives a path generation request from the originating tunnel communication device (see (2) in FIG. 20), and is necessary for data transfer between the originating tunnel communication device and the terminating tunnel communication device. A virtual path is generated by setting a transfer resource (see (3) in FIG. 20).

  However, in the tunnel communication system according to the second embodiment, unlike the first embodiment, when the originating tunnel communication device transmits a path generation request to the path control device, or when the originating tunnel communication device passes the path generation partner verification information In the path generation procedure, such as when receiving from the control device, the originating tunnel communication device performs mutual authentication with the path control device. For example, mutual authentication (IETF RFC-2617 or the like) by digest authentication is applied between the originating tunnel communication device and the path control device. Then, for example, the path control device transfers the path generation request only when authentication of the transmission source device (originating side tunnel communication device) of the path generation request is successful. Further, the originating tunnel communication device authenticates the path control device, thereby confirming that the path control device is not a fake path control device, and prevents man-in-the-middle attacks.

  From the viewpoint of security, the embodiment in which mutual authentication is performed between the originating tunnel communication device and the path control device is considered to be the most desirable embodiment, but the present invention is not limited to this. The present invention can be similarly applied to an embodiment in which either the authentication of the path control device by the originating tunnel communication device or the authentication of the originating tunnel communication device by the path control device is omitted. Also, with respect to mutual authentication (or authentication) between the destination tunnel communication device and the path control device, an embodiment in which mutual authentication is performed between the destination tunnel communication device and the path control device, or the destination tunnel communication device The present invention can be similarly applied to an embodiment that omits either the authentication of the path control device by the authentication or the authentication of the destination tunnel communication device by the path control device. From the viewpoint of security, it is desirable to select an embodiment suitable for operation.

  Further, unlike the first embodiment, the originating side tunnel communication apparatus in the second embodiment generates parameters necessary for generating a shared key with the destination side tunnel communication apparatus, and uses the generated parameters as a path generation request. And transmitted to the path control device (see (1) in FIG. 20). For example, the originating tunnel communication device generates DH public information and DH secret information as parameters, and transmits only the DH public information among the generated parameters by adding it to the path generation request. On the other hand, unlike the first embodiment, the called-side tunnel communication apparatus in the second embodiment also generates parameters necessary for generating a shared key with the originating-side tunnel communication apparatus, and uses the generated parameters as a path generation response. It is transmitted to the path control device by adding it to For example, the called-side tunnel communication device generates DH public information and DH secret information as parameters, and transmits only the DH public information among the generated parameters by adding it to the path generation response.

  Then, the path control device transmits the path generation partner verification information to each of the originating side tunnel communication device and the destination side tunnel communication device as in the first embodiment, but unlike the first embodiment, as the path generation partner verification information, The DH public information generated in each other's virtual path partner device is transmitted (see (4) in FIG. 20).

  Then, the originating side tunnel communication device and the terminating side tunnel communication device receive the path generation partner verification information from the path control device as in the first embodiment, but unlike the first embodiment, as the path generation partner verification information, DH public information generated in the virtual path partner device is received (see (5) in FIG. 20). Then, a session is established between the originating side tunnel communication device and the destination side tunnel communication device.

  Subsequently, the originating tunnel communication device and the terminating tunnel communication device exchange mutual authentication information used for mutual authentication with the tunnel communication counterpart device using the generated virtual path, as in the first embodiment. Unlike Example 1, first, a shared key is generated from the DH secret information generated by the own device and the DH public information received from the path control device as the path generation partner verification information (see (6) in FIG. 20). Then, the information generated using the generated shared key is transmitted as mutual authentication information (see (7) in FIG. 20) to the tunnel communication partner apparatus (see (8) in FIG. 20).

  Then, as in the first embodiment, the originating tunnel communication device and the terminating tunnel communication device are configured so that the tunnel communication counterpart device is based on the path generation partner verification information received from the path control device and the mutual authentication information. It is determined whether or not the device is the same as the device, but unlike the first embodiment, the originating side tunnel communication device obtains the mutual authentication information acquired from the destination side tunnel communication device (“arrival-mutual authentication” in FIG. 20). Is verified using the shared key generated in (6) of FIG. 20, and the called-side tunnel communication device acquires the mutual authentication information (“outgoing-mutual authentication” in FIG. 20) acquired from the calling-side tunnel communication device. Is verified using the shared key generated in (6) of FIG. 20 (see (9) of FIG. 20).

  As a result, if the originating tunnel communication device and the terminating tunnel communication device determine that the tunnel communication counterpart device is not the same as the virtual path counterpart device, the decision is to reject the establishment of tunnel communication, as in the first embodiment. Then, establishment of tunnel communication is rejected (see (10) in FIG. 20). That is, when the result of verifying the mutual authentication information using the shared key is a failure, the originating tunnel communication device and the terminating tunnel communication device determine that they are not the same, and refuse to establish tunnel communication, Prevent path hijacking.

  On the other hand, when the originating tunnel communication device and the terminating tunnel communication device determine that the tunnel communication counterpart device is the same as the virtual path counterpart device, the tunnel communication is established and the tunnel communication data is transmitted and received, as in the first embodiment. (See (11) in FIG. 20). That is, the originating tunnel communication device generates tunnel communication data from original data that is data to be transmitted to the destination tunnel communication device, and transmits the tunnel communication data to the destination tunnel communication device using a virtual path. When tunnel communication data is received from the destination tunnel communication device using the virtual path, the original data is extracted from the tunnel communication data.

[Procedure for Processing by Tunnel Communication System According to Second Embodiment]
Next, a procedure of processing performed by the tunnel communication system according to the second embodiment will be described with reference to FIG. FIG. 21 is a sequence diagram illustrating a processing procedure performed by the tunnel communication system according to the second embodiment. In the following description, among the processing procedures performed by the tunnel communication system according to the second embodiment, the description of the steps performed in substantially the same manner as the processing procedures performed by the tunnel communication system according to the first embodiment is omitted. I will explain only.

  First, the originating tunnel communication device 20 generates DH public information “DHP202p” and DH secret information “DHS202p” as parameters necessary for generating a shared key before transmitting a path generation request in step S210. (Step S200).

  Then, the originating side tunnel communication device 20 includes the DH public information “DHP202p” in the path generation request transmitted in step S210. For example, the originating tunnel communication device 20 writes the DH public information “DHP202p” in the SDP in a format defined in IETF RFC-4567. Then, the DH public information “DHP202p” is transmitted to the destination tunnel communication device 10 in step S220, step S230, and the like. In FIG. 21, the originating tunnel communication device 20 shows a procedure for performing mutual authentication with the path control device 210 in step S210, but the present invention is not limited to this. Any of the processing procedures for performing mutual authentication at other timings may be used.

  Similarly, the destination tunnel communication device 10 generates DH public information “DHP102p” and DH secret information “DHS102p” before transmitting a path generation response in step S240 (step S231).

  Then, the destination tunnel communication device 10 includes the DH public information “DHP102p” in the path generation response transmitted in step S240. For example, the destination-side tunnel communication apparatus 10 enters the DH public information “DHP102p” in the SDP in a format defined in IETF RFC-4567. Then, the DH public information “DHP102p” is transmitted to the originating tunnel communication device 20 in step S250, step S260, and the like. FIG. 21 shows a procedure of processing in which the incoming side tunnel communication device 10 performs mutual authentication with the path control device 110 in step S240, but the present invention is not limited to this. Any of the processing procedures for performing mutual authentication at other timings may be used.

  In addition, the destination side tunnel communication device 10 extracts the DH public information “DHP202p” from the path generation request, and from the DH public information “DHP202p” and the DH secret information “DHS102p” generated by the own device, the Diffie-Helman A shared key “K” is generated by the key exchange algorithm (step S271). In FIG. 21, the procedure of the process in which the destination tunnel communication device 10 generates the shared key “K” in step S271 is shown, but the present invention is not limited to this, and the notification information in step S231. Any of the procedures for generating the shared key immediately after generating the password may be used.

  Similarly, the originating tunnel communication device 20 extracts the DH public information “DHP102p” from the path generation response, and from the DH public information “DHP102p” and the DH secret information “DHS202p” generated by the own device, Diffie− A shared key “K” is generated by the Helman key exchange algorithm (step S272).

  The tunnel communication system according to the second embodiment uses the shared key “K” generated in this way as a shared key in the procedure after step S310.

[Effect of Example 2]
As described above, according to the second embodiment, the parameter necessary for generating the shared key used when generating the mutual authentication information is acquired from the control device as the path generation partner verification information. , Generate a shared key using the acquired parameters, exchange the information generated using the shared key as mutual authentication information with the tunnel communication partner device, and exchange the mutual authentication information acquired from the tunnel communication partner device with the shared key. When the verification result is unsuccessful, it is determined that the tunnel communication partner device is not the same as the virtual path partner device and the tunnel communication establishment is rejected. It is possible to protect tunnel communication on a path by using a shared key generated in the path generation procedure (for example, tunnel communication). There can also be applied to the case performed between the communication partners is a temporary relationship). In addition, since mutual authentication is performed using the shared key generated in the path generation procedure, the matching relationship between the communication partner in the path generation procedure and the communication partner in the tunnel communication can be verified. It is possible to prevent hijacking of the path even when an unauthorized device to be jacked has a mutual authentication relationship with the called-side tunnel communication device (or the originating-side tunnel communication device).

  Further, according to the second embodiment, since the control device is authenticated in the transmission of the path generation request to the control device and / or the acquisition of the path generation partner collation information from the control device, it is possible to prevent man-in-the-middle attacks in the path generation procedure. As a result (for example, a result of avoiding a situation where the tunnel communication device sends / receives a message to / from a fake control device that attempts a man-in-the-middle attack), it is possible to ensure that legitimate path generation partner verification information is received. Thus, hijacking of the above path can be prevented more safely.

  By the way, as a second embodiment so far, for the purpose of dealing with a case where tunnel communication is performed with a communication partner having a temporary relationship, a “shared key generated by a path generation procedure is used for mutual authentication. The method using the “method” has been described. Certainly, this method in the second embodiment can be said to be an effective method for a case of accepting a connection from an arbitrary tunnel communication device. However, depending on the mode of operation, there may be a case where it is not desired to accept a connection from an arbitrary tunnel communication device in consideration of safety. It is conceivable to deal with such a case, for example, by a method of adding an authorization list. In other words, the tunnel communication device only adds or deletes the authorization list as appropriate. For example, connections from tunnel communication devices that are frequently permitted are permitted, but connections from tunnel communication devices that are not registered in the authorization list are not permitted. It becomes possible to operate. Therefore, hereinafter, a “method using an authorization list” for the purpose of dealing with such a case will be described as a third embodiment according to the present invention.

[Outline and Features of Tunnel Communication System According to Embodiment 3]
The outline and characteristics of the tunnel communication system according to the third embodiment will be described with reference to FIG. FIG. 22 is a diagram for explaining the outline and features of the tunnel communication system according to the third embodiment.

  The main characteristics of the tunnel communication system according to the third embodiment will be described. In the third embodiment, as shown in FIG. 22, the called-side tunnel communication apparatus holds an authorization list in advance. For example, the authorization list is a list of telecommunication numbers of tunnel communication devices that authorize connection. In the third embodiment, a method in which the destination tunnel communication device holds the authorization list will be described. However, the present invention is not limited to this. For example, the telecommunications number of the tunnel communication device that does not authorize connection is used. As long as it is information that can determine whether or not to perform tunnel communication based on the received identifier, such as holding a list, any form of specific information may be used.

  Under such a configuration, the originating tunnel communication device according to the third embodiment transmits the telecommunication number “N202” as an identifier for uniquely identifying the own device in the wide area IP network to the path control device, and passes this to the path control device. The control device transmits to the destination tunnel communication device (see (1) in FIG. 22).

  Then, the destination side tunnel communication apparatus receives the telecommunication number “N202” from the path control apparatus (see (2) in FIG. 22), and based on the received telecommunication number “N202”, the calling side tunnel communication apparatus Whether or not to establish tunnel communication with each other (see (3) in FIG. 22).

[Processing Procedure by Tunnel Communication System According to Embodiment 3]
Next, a procedure of processing performed by the tunnel communication system according to the third embodiment will be described with reference to FIG. FIG. 23 is a sequence diagram illustrating processing procedures performed by the tunnel communication system according to the third embodiment. In the following description, among the processing procedures performed by the tunnel communication system according to the third embodiment, the description of the steps performed in substantially the same manner as the processing procedures performed by the tunnel communication system according to the second embodiment will be omitted. I will explain only.

  First, after receiving the path generation request from the path control apparatus 110 in step S230, the destination side tunnel communication apparatus 10 receives the telecommunications number of the calling side tunnel communication apparatus from the From header or P-Asserted-Identity header of the path generation request. “N202” is extracted, and using the authorization list, it is determined whether or not to establish the tunnel communication with the originating tunnel communication device (step S231). If this telecommunication number is not included in the authorization list, the destination tunnel communication device 10 sends a response rejecting the connection to the source tunnel communication device 20 in step S240. Send to.

  In the third embodiment, the technique in which the destination tunnel communication device 20 holds the authorization list has been described. However, the present invention is not limited to this, and for example, the path control device 110 holds the authorization list. In step S220, when the path control device 110 receives the path generation request, the telecommunications number “N202” of the originating tunnel communication device is extracted from the From header or P-Asserted-Identity header of the path generation request. Then, using the authorization list, it may be determined whether or not to perform tunnel communication between the originating side tunnel communication device 20 and the destination side tunnel communication device 10.

  Also, when the destination tunnel communication device 10 receives the path generation request, the user is presented with the wide-area identifier of the calling side tunnel communication device 20 in the same manner as the telephone number display, and the connection possibility from the user is input. It is also possible to authorize such as obtaining a judgment.

[Effect of Example 3]
As described above, according to the third embodiment, when a virtual path is generated in the control device, the virtual path partner device serving as the communication partner of each of the originating tunnel communication device and the terminating tunnel communication device is set on the network. An identifier that is uniquely identified is received from the control device, and based on the received identifier, it is determined whether to establish or reject tunnel communication with the virtual path partner device identified by the identifier. It is possible to realize authorization for establishing a tunnel only with a specific tunnel communication device. For example, it becomes possible for the called-side tunnel communication apparatus to realize authorization for establishing a tunnel only with a specific calling-side tunnel communication apparatus.

  Further, according to the third embodiment, the identifier (for example, the telecommunication number) is not secret information. For example, in the case where the tunnel communication is performed with a communication partner having a temporary relationship, the originating side Since the user of the tunnel communication device only needs to register the public information of the called side tunnel communication device in its own device, it is compared with the method of secretly contacting the shared key and setting the shared key in the device. This is a much simpler method.

  By the way, as the first to third embodiments, the mutual authentication performed between the originating side tunnel communication device and the destination side tunnel communication device is “a method using a preset shared key” or “path generation procedure”. We have explained the case of “method using generated shared key”. However, the present invention is not limited to this, and the present invention can be similarly applied to a case where mutual authentication is performed by a “method using a public key certificate”. Therefore, in the following, as a fourth embodiment according to the present invention, a case where mutual authentication is performed by a “method using a public key certificate” will be described.

[Outline and Features of Tunnel Communication System According to Embodiment 4]
The outline and features of the tunnel communication system according to the fourth embodiment will be described with reference to FIG. FIG. 24 is a diagram for explaining the outline and features of the tunnel communication system according to the fourth embodiment.

  In the tunnel communication system according to the fourth embodiment, as in the first embodiment, the tunnel communication is performed for data transfer performed by using the originating side tunnel communication device and the destination side tunnel communication device respectively connected to the network that performs IP communication as communication partners. In general, the path control device controls the virtual path used for data transfer when the is applied, and the path hijacking is prevented when mutual authentication is performed by a method using a public key certificate. Is the main feature. In the fourth embodiment, the identifier (telecommunications number) of the communication partner acquired in the path generation procedure is uniquely associated with the identifier of the communication partner acquired in the mutual authentication procedure (authentication is also performed in the mutual authentication procedure). In this embodiment, it is determined whether or not it is possible to verify the coincidence between the communication partner in the path generation procedure and the communication partner in the tunnel communication to prevent path hijacking.

  This main feature will be explained. First, in the tunnel communication system according to the fourth embodiment, as in the first embodiment, the originating tunnel communication device transmits a path generation request to the path control device (see (1) in FIG. 24). The path control device receives a path generation request from the originating tunnel communication device (see (2) in FIG. 24), and is necessary for data transfer between the originating tunnel communication device and the terminating tunnel communication device. By setting the appropriate transfer resource, a virtual path is generated (see (3) in FIG. 24), and path generation partner verification information is transmitted to each of the originating tunnel communication device and the terminating tunnel communication device (see FIG. 24). (See 24 (4)).

  Then, the originating tunnel communication device and the terminating tunnel communication device receive the path generation partner verification information from the path control device as in the first embodiment (see (5) in FIG. 24). Then, a session is established between the originating side tunnel communication device and the destination side tunnel communication device.

  Subsequently, the originating tunnel communication device and the terminating tunnel communication device exchange mutual authentication information used for mutual authentication with the tunnel communication counterpart device using the generated virtual path, as in the first embodiment. Unlike Example 1, information including its own device identifier for uniquely identifying its own device on the wide area IP network is transmitted as mutual authentication information to the tunnel communication partner device (see (6) in FIG. 24).

  Then, as in the first embodiment, the originating tunnel communication device and the terminating tunnel communication device are configured so that the tunnel communication counterpart device is based on the path generation partner verification information received from the path control device and the mutual authentication information. It is determined whether or not it is the same as the device, but unlike the first embodiment, the originating side tunnel communication device includes mutual authentication information ("Incoming-ID" in FIG. 24) acquired from the destination side tunnel communication device. Next, the identifier received as the path generation partner verification information (“arrival-ID”) and the own device included in the mutual authentication information are authenticated. It is determined whether or not an identifier (“Chaku-ID”) can be uniquely associated (see (8) in FIG. 24). Similarly, the called-side tunnel communication device authenticates the mutual authentication information (“outgoing-mutual authentication” including “outgoing-ID” in FIG. 24) acquired from the calling-side tunnel communication device ((7 in FIG. 24). Next, the identifier (“originating-ID”) received as the path generation partner verification information can be uniquely associated with the own device identifier (“originating-ID”) included in the mutual authentication information. It is determined whether or not there is (see (8) in FIG. 24). Note that the order of (7) and (8) in FIG. 24 may be any first.

  As a result, when the originating tunnel communication device and the terminating tunnel communication device determine that the tunnel communication counterpart device is not the same as the virtual path counterpart device, as in the first embodiment, the establishment of the tunnel communication is rejected. Unlike 1, when the identifier received as the path generation partner verification information and the own device identifier included in the mutual authentication information cannot be uniquely associated, it is determined that they are not the same, and the establishment of tunnel communication is rejected. To prevent hijacking of the path (see (9) of FIG. 24).

  On the other hand, when the originating tunnel communication device and the terminating tunnel communication device determine that the tunnel communication counterpart device is the same as the virtual path counterpart device, the tunnel communication is established and the tunnel communication data is transmitted and received, as in the first embodiment. (See (10) in FIG. 24). That is, the originating tunnel communication device generates tunnel communication data from original data that is data to be transmitted to the destination tunnel communication device, and transmits the tunnel communication data to the destination tunnel communication device using a virtual path. When tunnel communication data is received from the destination tunnel communication device using the virtual path, the original data is extracted from the tunnel communication data.

[Procedure for Processing by Tunnel Communication System According to Embodiment 4]
Next, a procedure of processing performed by the tunnel communication system according to the fourth embodiment will be described with reference to FIGS. 25 and 26. FIG. 25 is a sequence diagram illustrating a processing procedure performed by the tunnel communication system according to the fourth embodiment. FIG. 26 is a diagram for explaining mutual authentication. In the following description, among the processing procedures performed by the tunnel communication system according to the fourth embodiment, the description of the steps performed in substantially the same manner as the processing procedures performed by the tunnel communication system according to the first embodiment is omitted. I will explain only.

  First, as a premise, the originating side tunnel communication device 20 has the CA station public key, the public key PK202 and private key SK202 pair of the originating side tunnel communication device 20, and the CA key signature added to the public key PK202. The public key certificate CERT 202 is held. Similarly, the destination-side tunnel communication device 10 includes the public key of the CA station, a pair of the public key PK102 and the private key SK102 of the destination-side tunnel communication device 10, and the public key with the signature of the CA station added to the public key PK102. Certificate CERT102. The CERT 202 describes the telecommunications number “N202” of the originating side tunnel communication device 20, and the CERT 102 describes the telecommunications number “N102” of the destination side tunnel communication device 10. Further, the PSK table part of each tunnel communication device is not required, and the selection of the shared key “K” is also unnecessary.

  25. In step S310 of FIG. 25, the originating tunnel communication device 20 includes the public key certificate “CERT202” of its own device in the main body, and uses “SIGN 202” as its public key cipher “SK202”. (See (2) in FIG. 26).

  The destination tunnel communication apparatus 10 extracts the public key certificate “CERT202” from the tunnel communication start request in step S311 of FIG. 25 (see (4) of FIG. 26).

  The incoming side tunnel communication device 10 first starts with the telecommunications number “N. It is checked whether or not “exp” and the telecommunication number “N202” extracted from the path generation request can be uniquely associated (see (5) in FIG. 26). Is an authentication error. At this time, the destination tunnel communication device 10 determines that the tunnel communication partner device that is the communication partner in the tunnel communication is not the same as the virtual path partner device that was the communication partner when the virtual path is generated. It is an authentication error for the purpose of rejecting establishment of communication and preventing hijacking of the path. If it can be uniquely associated, the destination tunnel communication device 10 extracts “PK202” from “CERT202” and verifies “SIGN202” extracted from the tunnel communication start request with “PK202” (FIG. 26). (See (6)).

  Similarly, in step S320 of FIG. 25, the destination tunnel communication device 10 includes its own public key certificate “CERT102” in the main body, and uses “SIGN102” using its own device private key “SK102”. Generated by an electronic signature algorithm using public key cryptography.

  In step S321 in FIG. 25, the originating side tunnel communication device 20 extracts the public key certificate “CERT102” from the tunnel communication start response.

  Then, the originating side tunnel communication device 20 firstly sets the telecommunications number “N. It is confirmed whether or not “exp” and the telecommunication number “N102” extracted from the path generation request can be uniquely associated. At this time, the originating tunnel communication device 20 determines that the tunnel communication partner device that is the communication partner in tunnel communication is not the same as the virtual path partner device that was the communication partner when the virtual path is generated. It is determined that the establishment of communication is rejected and the establishment of tunnel communication is rejected, and this authentication error corresponds to an operation of rejecting the establishment of tunnel communication. If uniquely associated, the originating tunnel communication device 20 extracts “PK102” from “CERT102” and verifies “SIGN102” extracted from the tunnel communication start response with “PK102”.

  The CA station may be operated in any form such as a form operated by an operator of a wide area IP network or a form operated by a third operator.

  Here, as can be seen by checking FIG. 26 again, even if mutual authentication is performed between the originating side tunnel communication device 20 and the destination side tunnel communication device 10 by the “method using a public key certificate”, For example, as a result of the verification by (6) in FIG. 26, the destination side tunnel communication apparatus 10 side has confirmed that the contents of the public key certificate have not been falsified, and that the public key certificate has been issued by the CA station. In addition, it can only verify that the “device that sent the public key certificate” does not deny that the public key certificate has been sent.

  That is, it is not verified whether the “device that sent the public key certificate” is a path generation partner device that is a communication partner in the path generation procedure. Then, when the path is hijacked by the third device that belongs to the same CA station as the destination tunnel communication device 10 and holds the public key certificate issued by the CA station, the destination tunnel communication device 10 Just verifying the certificate may not realize that the path is hijacked. For this reason, in the tunnel communication system according to the fourth embodiment, an identifier is included in the public key certificate, and the identifier acquired in the path generation procedure can be uniquely associated with the own device identifier acquired in the mutual authentication procedure. It is confirmed that the “device that sent the public key certificate” is the originating tunnel communication device that is the communication partner that generated the path.

  In the fourth embodiment, the telecommunication number is received as the path generation partner verification information, the telecommunication number is received as the own device identifier of the mutual authentication information, and the telecommunication number and the telecommunication number can be uniquely associated. However, the present invention is not limited to this, and for example, a telecommunications number such as “0422-12-3456” is received as path generation partner verification information, X. of mutual authentication information. 509 receives a host name such as “example.xxx.co.jp” as its own device identifier, and “0422-12-3456” and “example.xxx.co.jp” can be uniquely associated with each other. The present invention can be similarly applied to a method for determining whether or not. In this method, either a tunnel communication device or a server on the net holds a correspondence table between host names and telecommunication numbers, and the tunnel communication device refers to this correspondence table to generate a path. Check the correspondence between partner verification information and mutual authentication information (whether it can be uniquely associated).

  In the fourth embodiment, it is determined whether the identifier of the communication partner acquired in the path generation procedure and the identifier of the communication partner included in the public key certificate acquired in the mutual authentication procedure can be uniquely associated. Thus, although the method for verifying the coincidence between the communication partner in the path generation procedure and the communication partner in the tunnel communication has been described, the present invention is not limited to this. The present invention is similarly applied to a method in which tunnel communication is established only by authenticating the public key certificate acquired in the mutual authentication procedure and the matching relationship between the communication partner in the path generation procedure and the communication partner in the tunnel communication is not verified. can do. According to the latter method, for example, an unauthorized device is connected to the incoming side tunnel communication device (or the outgoing side tunnel communication device) and the X. In a special case such as a case where a mutual authentication is possible using a 509 certificate, it is not possible to prevent path hijacking. However, the latter method is also disclosed in X. 509 certificates are used for mutual authentication, and tunnel communication is established only when the mutual authentication is successful. It is guaranteed that the partner device is not an unauthorized device with a certain probability. It can be prevented.

[Effect of Example 4]
As described above, according to the fourth embodiment, as the path generation partner verification information, an identifier for uniquely identifying the virtual path partner apparatus on the network is extracted from the transmitted path generation request or the control apparatus. The information including the own device identifier that uniquely identifies the device on the network is exchanged with the tunnel communication partner device as mutual authentication information, and the acquired identifier and the tunnel communication partner device When the own device identifier of the tunnel communication partner device included in the acquired mutual authentication information cannot be uniquely associated, it is determined that the tunnel communication partner device is not the same as the virtual path partner device and tunnel communication is established. Because it is determined to be rejected, the communication partner identifier acquired in the path generation procedure and the communication phase acquired in the mutual authentication procedure It is possible to verify the coincidence between the communication partner in the path generation procedure and the communication partner in the tunnel communication by determining whether or not the identifier (which also performs authentication in the mutual authentication procedure) can be uniquely associated. Therefore, even when an unauthorized device that hijacks the path is in a relationship that allows mutual authentication with the called-side tunnel communication device (or the originating-side tunnel communication device), it is possible to prevent path hijacking. . For example, X. When mutual authentication is performed by a method using a 509 certificate, an unauthorized device is connected to the incoming side tunnel communication device (or the outgoing side tunnel communication device) and the X.509 certificate. It is possible to prevent path hijacking even when a mutual authentication is possible using the 509 certificate.

[Other embodiments]
Although the embodiments of the present invention have been described so far, the present invention may be implemented in various different forms other than the above-described embodiments. Therefore, different embodiments will be described below as the tunnel communication system according to the fifth embodiment.

  In the first to fourth embodiments, “IP address control” (specifically, NAPT coupling or the like) is assumed as transfer resource control, and the control apparatus implements tunnel communication after performing “IP address control”. As described above, the case of generating a path has been described. However, the present invention is not limited to this, and “bandwidth control” (specifically, bandwidth allocation, transfer priority setting, etc.) or “filtering control” is used as transfer resource control. (Specifically, packet continuity settings, etc.) and the case where the control device generates a path so as to realize tunnel communication after performing “bandwidth control” and “filtering control”. The invention can be applied as well.

  In the following, these cases where NAPT binding is not performed will be briefly described. In this example, it is assumed that the originating tunnel communication device 20 is assigned a wide area IP address “WA202” and the destination tunnel communication apparatus 10 is assigned a wide area IP address “WA102”. Accordingly, in step S210 of FIG. 9, the originating side tunnel communication device 20 enters “WA202” instead of “LA202” in the SDP as its own IP address. In step S240, the terminating side tunnel communication device 10 enters "WA102" in the SDP instead of "LA102" as the IP address of its own device.

  In step S241, the path control device 110 allocates and transfers bandwidth for L4 communication between the IP address “WA202” and the port number “LP2021” and the IP address “WA102” and the port number “LP1021”. Perform priority setting or packet continuity setting.

  In this example, since NAPT is not executed, “LP2021” is notified instead of “WP2021” as the port number of the originating side tunnel communication apparatus 20 in step S230, and the port of the destination side tunnel communication apparatus 10 As a number, “LP1021” is notified instead of “WP1021”. As a result, in step S310 and thereafter, the originating tunnel communication device 20 uses the IP address “WA102” and the port number “LP1021”, and the terminating tunnel communication device 10 uses the IP address “WA202” and the port number “LP2021”. Will be used.

[System configuration, etc.]
In addition, among the processes described in this embodiment, all or part of the processes described as being performed automatically can be performed manually, or the processes described as being performed manually can be performed. All or a part can be automatically performed by a known method. In addition, the processing procedure, control procedure, specific name, and information including various data and parameters shown in the above-mentioned document and drawings can be arbitrarily changed unless otherwise specified.

  Each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated (for example, FIG. 2). In other words, the specific form of distribution / integration of each device is not limited to that shown in the figure, and all or a part thereof may be functionally or physically distributed or arbitrarily distributed in arbitrary units according to various loads or usage conditions. Can be integrated and configured. Further, all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.

  The tunnel communication method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation. This program can be distributed via a network such as the Internet. The program can also be executed by being recorded on a computer-readable recording medium such as a hard disk, a flexible disk (FD), a CD-ROM, an MO, and a DVD and being read from the recording medium by the computer.

  As described above, the tunnel communication system, the control apparatus, and the tunnel communication apparatus according to the present invention are performed using the originating side tunnel communication apparatus and the destination side tunnel communication apparatus respectively connected to the network performing IP communication as communication partners. The control apparatus is useful for controlling tunnel communication, and is particularly suitable for realizing tunnel communication while controlling transfer resources in a network such as a wide area IP network.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram for explaining an overview and characteristics of a tunnel communication system according to a first embodiment. 1 is a block diagram illustrating a configuration of a tunnel communication system according to a first embodiment. It is a figure for demonstrating an address memory | storage part. It is a figure for demonstrating a number table part. It is a figure for demonstrating a server address table part. It is a figure for demonstrating a device address table part. It is a figure for demonstrating a signal part. It is a figure for demonstrating a PSK table part. It is a sequence diagram which shows the procedure of the process by the tunnel communication system which concerns on Example 1. FIG. It is a figure for demonstrating transfer resource control (NAPT coupling | bonding). It is a figure for demonstrating transfer resource control (NAPT coupling | bonding). It is a figure for demonstrating mutual authentication. It is a figure for demonstrating mutual authentication. It is a figure for demonstrating mutual authentication. It is a figure for demonstrating mutual authentication. It is a figure for demonstrating mutual authentication. It is a figure for demonstrating tunnel communication. It is a figure for demonstrating tunnel communication. It is a figure for demonstrating the Example when a tunnel communication apparatus is application GW. It is a figure for demonstrating the outline | summary and the characteristic of the tunnel communication system which concern on Example 2. FIG. It is a sequence diagram which shows the procedure of the process by the tunnel communication system which concerns on Example 2. FIG. It is a figure for demonstrating the outline | summary and the characteristic of the tunnel communication system which concern on Example 3. FIG. FIG. 10 is a sequence diagram illustrating a processing procedure by the tunnel communication system according to the third embodiment. It is a figure for demonstrating the outline | summary and the characteristic of the tunnel communication system which concern on Example 4. FIG. FIG. 10 is a sequence diagram illustrating a processing procedure performed by the tunnel communication system according to the fourth embodiment. It is a figure for demonstrating mutual authentication. It is a figure for demonstrating NAPT.

Explanation of symbols

DESCRIPTION OF SYMBOLS 10 Termination side tunnel communication apparatus 11 Signal part 12 Tunnel communication part 13 Transfer part 14 PSK table part 15 Mutual authentication part 16 LAN switch 20 Origination side tunnel communication apparatus 21 Signal part 22 Tunnel communication part 23 Packet transmission / reception part 24 PSK table part 25 Mutual Authentication unit 100 Local IP network 110 Path control device 111 Signal unit 112 Address storage unit 113 Path control unit 120 Gate router 121 Transfer resource setting unit 122 Transfer control unit 123 Transfer unit 130 Local router 200 Local IP network 210 Path control device 211 Signal unit 212 Address storage unit 213 Path control unit 220 Gate router 221 Transfer resource setting unit 222 Transfer control unit 223 Transfer unit 230 Local router 300 Relay device 310 Core router

Claims (16)

When tunnel communication is applied to data transfer performed by using the originating side tunnel communication device and the destination side tunnel communication device respectively connected to the network performing IP communication as communication partners, the virtual path used for the data transfer is A tunnel communication system controlled by a control device,
The controller is
A path generation request including an identifier for uniquely identifying the destination tunnel communication apparatus on the network and requesting generation of the virtual path with the destination tunnel communication apparatus is transmitted from the source tunnel communication apparatus. A path generation request receiving means for receiving;
When the path generation request is received by the path generation request receiving means, the virtual path is set by setting a transfer resource necessary for data transfer between the source side tunnel communication apparatus and the destination side tunnel communication apparatus. Path generation means for generating
A path generation notification transmitting means for transmitting a path generation notification for notifying generation of a virtual path to be generated by the path generation means to each of the originating tunnel communication device and the terminating tunnel communication device;
The originating tunnel communication device is:
Path generation request transmission means for transmitting the path generation request of the virtual path to be generated by the path generation means to the control device;
The originating tunnel communication device and the terminating tunnel communication device are:
Path generation notification receiving means for receiving the path generation notification transmitted by the path generation notification transmitting means from the control device;
Exchange mutual authentication information used for mutual authentication that mutually authenticates with a tunnel communication partner device that is a communication partner in the tunnel communication, using the virtual path generated by the path generation means, with the tunnel communication partner device Mutual authentication information exchange means
Based on the mutual authentication information acquired from the tunnel communication partner apparatus by the mutual authentication information exchanging means, it is determined whether to establish or reject tunnel communication with the tunnel communication partner apparatus. Tunnel communication establishment rejection means for rejecting communication establishment;
A virtual path generated by the path generation means by generating tunnel communication data from original data which is data to be transmitted to the tunnel communication partner apparatus when the tunnel communication establishment rejection means determines to establish the tunnel communication. Tunnel data transmission means for transmitting the tunnel communication data to the tunnel communication counterpart device using
When the tunnel communication data is received using the virtual path generated by the path generation unit from the tunnel communication counterpart device when the tunnel communication establishment rejection unit determines to establish the tunnel communication, the tunnel communication data Tunnel data receiving means for extracting original data from,
A tunnel communication system comprising: The controller is
For verifying each other virtual path partner device with respect to a virtual path partner device serving as a communication partner of each of the originating tunnel communication device and the destination tunnel communication device when a virtual path is generated by the path generation means Path generation partner verification information transmitting means for transmitting the path generation partner verification information that is information to the destination tunnel communication device or to the destination tunnel communication device and the source tunnel communication device;
The originating tunnel communication device and the terminating tunnel communication device are:
The path generation partner verification information is extracted from the path generation request transmitted by the path generation request transmission means, or the path generation partner verification information transmitted by the path generation partner verification information transmission means is It further comprises path generation partner collation information acquisition means to be acquired by receiving from the control device,
The tunnel communication establishment rejection means includes the path generation partner verification information acquired by the path generation partner verification information acquisition means and the mutual authentication information acquired from the tunnel communication partner apparatus by the mutual authentication information exchange means. Based on whether or not the tunnel communication partner device is the same as the virtual path partner device, and if it is determined that the tunnel communication partner device is not the same as the virtual path partner device The tunnel communication system according to claim 1, wherein the determination is made. The network has a NAPT function for converting between a combination of a non-disclosure IP address and a non-disclosure port number that is not disclosed on the network and a combination of a disclosure IP address and a disclosure port number disclosed on the network. The calling-side tunnel communication device is assigned a calling-side non-disclosure IP address and a calling-side non-disclosure port number, and the called-side tunnel communication device has a called-side non-disclosure IP address and a called-side non-disclosure port number. Which has been granted
The path generation means uses the combination of the originating side disclosed IP address and the originating side disclosed port number selected in association with the combination of the originating side undisclosed IP address and the originating side undisclosed port number as the terminating side tunnel communication apparatus. And a combination of the called party disclosed IP address and the called party disclosed port number selected in association with the combination of the called party undisclosed IP address and the called party undisclosed port number is transmitted to the calling side tunnel communication apparatus. And the conversion between the combination of the calling party non-disclosure IP address and the calling party non-disclosure port number and the combination of the calling party disclosure IP address and the calling party disclosure port number is set in the NAPT function. A combination of the destination non-disclosure IP address and the destination non-disclosure port number and the destination side disclosure IP address. By setting the conversion between the combination of the fine callee disclosed port number to the NAPT function, to generate the virtual path by performing the setting of the transfer resources to the network,
The mutual authentication information exchanging means includes a combination of the originating side disclosed IP address and the originating side disclosed port number transmitted from the control device by the path generating means, or the destination side disclosed IP address and the destination side disclosed port number. Exchange the mutual authentication information using a combination;
The tunnel data transmitting means includes a combination of the originating side disclosed IP address and the originating side disclosed port number transmitted from the control device by the path generating means, or a combination of the called side disclosed IP address and the called side disclosed port number. The tunnel communication data is transmitted using
The tunnel data receiving means receives the tunnel communication data transmitted using a combination of the originating side disclosed IP address and the originating side disclosed port number, or a combination of the called side disclosed IP address and the called side disclosed port number. The tunnel communication system according to claim 1 or 2, characterized in that:   The path generation means generates the virtual path by setting the bandwidth to be applied to the data transfer and / or the priority of the data to be applied to the data transfer as the transfer resource setting. The tunnel communication system according to claim 1 or 2. The network includes a packet filter function for determining whether to conduct a packet based on a setting set in a packet filter,
The said path generation means produces | generates the said virtual path by setting to the said packet filter so that the packet regarding the said data transfer may be conducted as a setting of the said transfer resource, The said virtual path is produced | generated. Tunnel communication system. When tunnel communication is applied to data transfer performed by using the originating side tunnel communication device and the destination side tunnel communication device respectively connected to the network performing IP communication as communication partners, the virtual path used for the data transfer is The control device in the tunnel communication system controlled by the control device,
A path generation request including an identifier for uniquely identifying the destination tunnel communication apparatus on the network and requesting generation of the virtual path with the destination tunnel communication apparatus is transmitted from the source tunnel communication apparatus. A path generation request receiving means for receiving;
When the path generation request is received by the path generation request receiving means, the virtual path is set by setting a transfer resource necessary for data transfer between the source side tunnel communication apparatus and the destination side tunnel communication apparatus. Path generation means for generating
By transmitting a path generation notification for notifying generation of a virtual path to be generated by the path generation means to each of the calling side tunnel communication apparatus and the called side tunnel communication apparatus, the calling side tunnel communication apparatus and Path generation notification transmission means for causing the called-side tunnel communication device to exchange mutual authentication information to determine whether to establish or reject the tunnel communication;
A control device comprising: When tunnel communication is applied to data transfer performed by using the originating side tunnel communication device and the destination side tunnel communication device respectively connected to the network performing IP communication as communication partners, the virtual path used for the data transfer is A tunnel communication device as the originating side tunnel communication device in a tunnel communication system controlled by a control device,
The destination tunnel communication device so as to generate the virtual path by causing the control device to set transfer resources necessary for data transfer between the source tunnel communication device and the destination tunnel communication device. A path generation request transmitting means for transmitting a path generation request to the control apparatus for requesting generation of the virtual path with the destination tunnel communication apparatus, including an identifier for uniquely identifying the network on the network;
Path generation notification receiving means for receiving from the control device a path generation notification for notifying generation of the virtual path to be generated in the control device;
Exchange mutual authentication information used for mutual authentication that mutually authenticates with a tunnel communication partner device that is a communication partner in the tunnel communication, using the virtual path generated in the control device. Mutual authentication information exchange means
Based on the mutual authentication information acquired from the tunnel communication partner device by the mutual authentication information exchanging means, it is determined whether to establish or reject tunnel communication with the tunnel communication partner device. Tunnel communication establishment rejection means for rejecting communication establishment;
The virtual path generated in the control device by generating tunnel communication data from original data that is data to be transmitted to the tunnel communication partner device when the tunnel communication establishment rejection means determines to establish the tunnel communication Tunnel data transmission means for transmitting the tunnel communication data to the tunnel communication counterpart device using
When the tunnel communication data is received from the tunnel communication partner apparatus when the tunnel communication establishment rejection unit determines to establish the tunnel communication using the virtual path generated in the control apparatus, the tunnel communication data Tunnel data receiving means for extracting original data from,
A tunnel communication device comprising: When tunnel communication is applied to data transfer performed by using the originating side tunnel communication device and the destination side tunnel communication device respectively connected to the network performing IP communication as communication partners, the virtual path used for the data transfer is A tunnel communication device as the destination tunnel communication device in a tunnel communication system controlled by a control device,
Generation of the virtual path to be generated in the control device by causing the control device to set transfer resources necessary for data transfer between the originating tunnel communication device and the destination tunnel communication device A path generation notification receiving means for receiving a path generation notification for notifying from the control device;
Exchange mutual authentication information used for mutual authentication that mutually authenticates with a tunnel communication partner device that is a communication partner in the tunnel communication, using the virtual path generated in the control device. Mutual authentication information exchange means
Based on the mutual authentication information acquired from the tunnel communication partner device by the mutual authentication information exchanging means, it is determined whether to establish or reject tunnel communication with the tunnel communication partner device. Tunnel communication establishment rejection means for rejecting communication establishment;
The virtual path generated in the control device by generating tunnel communication data from original data that is data to be transmitted to the tunnel communication partner device when the tunnel communication establishment rejection means determines to establish the tunnel communication Tunnel data transmission means for transmitting the tunnel communication data to the tunnel communication counterpart device using
When the tunnel communication data is received from the tunnel communication partner apparatus when the tunnel communication establishment rejection unit determines to establish the tunnel communication using the virtual path generated in the control apparatus, the tunnel communication data Tunnel data receiving means for extracting original data from,
A tunnel communication device comprising: Information for collating each virtual path partner device with respect to the virtual path partner device that is the communication partner of each of the originating tunnel communication device and the terminating tunnel communication device when a virtual path is generated in the control device The path generation partner verification information is extracted from the path generation request transmitted by the path generation request transmission means, or the path generation partner verification information transmitted by the path generation partner verification information transmission means is It further comprises a path generation partner collation information acquisition means that is acquired by receiving from the control device,
The tunnel communication establishment rejection means includes the path generation partner verification information acquired by the path generation partner verification information acquisition means and the mutual authentication information acquired from the tunnel communication partner apparatus by the mutual authentication information exchange means. Based on whether or not the tunnel communication partner device is the same as the virtual path partner device, and if it is determined that the tunnel communication partner device is not the same as the virtual path partner device The tunnel communication device according to claim 7 or 8, wherein the determination is made. A shared key holding unit that holds an identifier that uniquely identifies the communication partner on the network and a shared key that is key information shared in advance with the communication partner,
The path generation partner verification information acquisition means uses, as the path generation partner verification information, an identifier for uniquely identifying the virtual path partner apparatus on the network from the path generation request transmitted by the path generation request transmission means. Obtaining the identifier by extracting or receiving it from the control device;
The mutual authentication information exchanging means selects a shared key associated with the identifier acquired by the path generation partner verification information acquisition means from among the shared keys held by the shared key holding means, and Exchange the information generated using the key as the mutual authentication information with the tunnel communication partner device,
The tunnel communication establishment rejection unit verifies the mutual authentication information acquired from the tunnel communication partner apparatus using the shared key, and when the verification result is unsuccessful, the tunnel communication partner apparatus 10. The tunnel communication apparatus according to claim 9, wherein the tunnel communication apparatus determines that the establishment of the tunnel communication is rejected by determining that it is not the same as the path partner apparatus. The path generation partner verification information acquisition means acquires the path generation partner verification information by receiving, from the control device, parameters necessary for generating a shared key used when generating the mutual authentication information. ,
The mutual authentication information exchanging means generates the shared key using the parameters acquired by the path generation partner verification information acquisition means, and uses the information generated using the shared key as the mutual authentication information as the tunnel communication. Replace with the other device,
The tunnel communication establishment rejection unit verifies the mutual authentication information acquired from the tunnel communication partner apparatus using the shared key, and when the verification result is unsuccessful, the tunnel communication partner apparatus 10. The tunnel communication apparatus according to claim 9, wherein the tunnel communication apparatus determines that the establishment of the tunnel communication is rejected by determining that it is not the same as the path partner apparatus.   In the transmission of the path generation request to the control device by the path generation request transmission unit and / or the acquisition of the path generation partner verification information from the control device by the path generation partner verification information acquisition unit, the control device is authenticated. 12. The tunnel communication device according to claim 11, further comprising a control device authentication unit. The path generation partner verification information acquisition means uses, as the path generation partner verification information, an identifier for uniquely identifying the virtual path partner apparatus on the network from the path generation request transmitted by the path generation request transmission means. Obtaining the identifier by extracting or receiving it from the control device;
The mutual authentication information exchanging means exchanges information including the own device identifier for uniquely identifying its own device on the network as the mutual authentication information with the tunnel communication counterpart device,
The tunnel communication establishment rejection unit includes the identifier acquired by the path generation partner verification information acquisition unit, and the own device identifier of the tunnel communication partner device included in the mutual authentication information acquired from the tunnel communication partner device. 10. The method according to claim 9, further comprising: determining that the tunnel communication counterpart device is not the same as the virtual path counterpart device and rejecting establishment of the tunnel communication when the tunnel communication counterpart device is not identical to the virtual path counterpart device. Tunnel communication device. When a virtual path is generated in the control device, an identifier for uniquely identifying a virtual path partner device serving as a communication partner of each of the originating side tunnel communication device and the destination side tunnel communication device on the network. Virtual path partner device identifier receiving means for receiving from,
Determining means for determining whether to establish or reject tunnel communication with the virtual path partner apparatus identified by the identifier based on the identifier received by the virtual path partner apparatus identifier receiving means;
The tunnel communication device according to claim 8, further comprising:   The program for control apparatuses which makes a computer implement | achieve the control apparatus of Claim 6.   The program for tunnel communication apparatuses which makes a computer implement | achieve the tunnel communication apparatus as described in any one of Claims 7-14.

Images