JP2008154103A - Communication relay device - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a communication relay device by which security communication is attained with security intensity higher than that of a tunnel mode IPsec, etc. between nodes whose security policies such as the IPsec can not be matched. <P>SOLUTION: The communication relay device for a network applying a prescribed security system is provided with a security policy judgment means for judging security policies of each of two communication modes to be relayed and a communication relay means for setting individual security policies with each of the communication nodes and relaying between the two nodes with different security policies. <P>COPYRIGHT: (C)2008,JPO&INPIT

Description

  The present invention relates to a communication relay device that relays communication between nodes corresponding to a security method such as IPsec (Internet Protocol for security).

  IPsec exists as a security method for a communication network using IP (Internet Protocol), which is a network layer protocol of an OSI (Open Systems Interconnection) reference model. This is a communication protocol group for performing secure packet exchange over IP. By securing security at the IP level, secure communication can be realized without being conscious of the higher level including the application layer. As a result, all applications running on the IP network can use secure communication. Since IPv6 (Internet Protocol version 6), which is a new version of IP, is implemented as a standard (optional in IPv4 (Internet Protocol version 4)), it is attracting attention as a means to ensure future network security. .

IPsec is a “communication protocol group” and is not a single communication protocol. IPsec is composed of the following protocols.
・ Authentication header (AH: Authentication Header)
It is a protocol that ensures the integrity of IP packets. It also has an authentication mechanism.
・ Cryptographic payload (ESP: Encapsulating Security Payload)
It is a protocol that ensures the confidentiality and integrity of IP packets. It also has an authentication mechanism.
・ IPComp (IP Payload Compression Protocol)
This is a protocol for compressing IP packets.
・ IKE (Internet Key Exchange)
This is a protocol for exchanging information such as algorithms and keys used in AH, ESP, and IPComp.

  Actually, IPComp and IKE are protocols independent of IPsec. However, since these are protocols that are often used when performing IPsec communication, they can be said to be one protocol of the IPsec protocol group.

  It can be said that IPsec is a technique for enhancing the security of communication by authenticating and encrypting packets sent between two nodes that communicate with each other using these protocols.

  Since two nodes communicating with IPsec need to authenticate and decrypt packets sent by the other party, the IPsec settings (IP address, protocol and port number of communication to be encrypted, and IPsec related protocol to be applied) , Encryption keys, etc.). This is called a security policy. Typical security policy items include each packet processing method (discarded for each packet, normal communication, IPsec communication, etc. set. Packets are grouped by a combination of source IP address, destination IP address, protocol, and destination port. Such items for selecting communication packets are collectively called “selector”), IPsec-related protocols to be used (AH, ESP, IPComp, etc.), authentication protocols (SHA-1, MD5, etc.) Encryption protocols (DES, 3DES, AES, etc.), modes (transport mode, tunnel mode), and the like.

  Unless this security policy is matched, IPsec communication cannot be performed between the two nodes. Therefore, when performing IPsec communication, the security policies of the two target nodes are matched manually or automatically (IKE is a protocol used for this automatic processing).

  FIG. 1 is a sequence diagram showing an IPsec policy negotiation process by IKE in general IPsec communication.

  In FIG. 1, when processing is started, security policy negotiation (negotiation for subsequent IKE Phase 2) is performed as processing of IKE Phase 1 between node N1 and node N2 (step S1), and then processing of IKE Phase 2 is performed. Then, security policy negotiation (negotiation for subsequent security communication) is performed (step S2), and security communication is performed upon successful negotiation (step S3).

  FIG. 2 is a flowchart showing negotiation of IPsec policy and subsequent security communication processing.

  In FIG. 2, the IKE Phase 1 process (Step S12) is performed in the IPsec policy negotiation (Step S11), and if the IKE Phase 1 negotiation is successful, the IKE Phase 2 process (Step S13) is performed.

  When the negotiation for IKE Phase 2 is successful, the standby state is established (step S15) when the IPsec preparation is complete (step S14), the decoding is performed when the packet arrives (step S16), and the standby state (step S15) when the decoding is completed. Return to. When there is a packet transmission request from the standby state (step S15), encryption is performed (step S17), and when the encryption is completed, packet transmission is performed (step S18), and the process returns to the standby state (step S15).

  On the other hand, Patent Document 1 discloses a “communication method, communication permission server, and printing method” for safely and easily realizing end-to-end communication by IPsec between computers inside and outside the firewall. .

Also, in Patent Document 2, it is possible to encrypt a packet from a node without a secure function by installing a relay device (secure router) between networks and having the router perform packet encryption processing. The “proxy secure router device and program” are disclosed.
JP 2006-20266 A JP 2006-33350 A

  As described above, when performing IPsec communication, the security policies of the two target nodes must be matched manually or automatically. However, the security policies should be matched between the two nodes that are to perform IPsec communication. If not, there was a problem that IPsec communication could not be performed. For example, when there is no match with the encryption algorithm owned by both nodes (including the case where one node does not have the encryption algorithm), IPsec communication is impossible. FIG. 3 is a diagram showing an example in which IPsec communication is impossible due to a mismatch of security policies. When the encryption algorithm owned by the node N1 is DES and the encryption algorithm owned by the node N2 is AES, both security policies are shown. Therefore, IPsec communication becomes impossible.

  Tunnel mode IPsec is one solution to this problem. In the tunnel mode, a communication relay device is installed on the communication path between the nodes, and this communication relay device is responsible for all of the IPsec processing of one node (two communication relay devices are installed and the IPsec processing of both nodes communicates. It can also be done by a relay device). Accordingly, if the node can perform normal communication, IPsec communication via the communication relay device is possible. However, the tunnel mode has a problem that the communication between the node and the communication relay device is normal communication (unsecured communication), and security in that section is not ensured. FIG. 4 is a diagram showing an example of tunnel mode IPsec, and communication between the communication relay device R and the node N2 is made IPsec because the communication relay device R takes charge of the IPsec processing of the node N1, but the node N1 And the communication relay device R are in normal communication.

  The present invention has been proposed in view of the above-described conventional problems, and the object of the present invention is to perform security communication with higher security strength than that of tunnel mode IPsec or the like between nodes where security policies such as IPsec cannot be matched. It is to provide a communication relay device capable of realizing the above.

  Although Patent Document 1 described above is abstractly similar to the present invention as a technique for realizing IPsec communication between nodes that normally cannot perform IPsec communication, Patent Document 1 discloses communication between nodes separated by FireWall. In contrast, IPsec communication is impossible due to the fact that, in the present invention, security communication is impossible due to the fact that it is impossible to match policies such as IPsec between nodes. The two are different technologies. Further, while Patent Document 1 dynamically modifies device settings related to communication, the present invention modifies communication data without changing the device settings, and the means for realizing it is also different.

  Patent Document 2 is abstractly similar to the present invention in that a relay device between nodes is responsible for encryption. However, while Patent Document 2 targets a node without a secure function, the present invention The difference is that a node having a secure function (IPsec or the like) is targeted. That is, Patent Document 2 is a technique for relaying an insecure network and a secure network (change between a normal packet and a secure packet), whereas the present invention relays secure networks (different secure packets are different). The technology is changed to a secure packet), and both are different technologies.

  In order to solve the above problems, according to the present invention, as described in claim 1, a network communication relay device to which a predetermined security method is applied, each of two communication nodes to be relayed A communication relay apparatus comprising: security policy determination means for determining a security policy; and communication relay means for setting an individual security policy between each of the communication nodes and relaying between two communication nodes having different security policies Is the gist.

  In addition, as described in claim 2, in the communication relay device according to claim 1, the communication relay means targets two encryption nodes with encryption schemes as security policy items and different encryption schemes. It is possible to have cryptographic conversion processing means for performing relaying between them.

  Further, as described in claim 3, in the communication relay device according to claim 1, the communication relay means targets an authentication method as a security policy item, and between two communication nodes having different authentication methods. Authentication conversion processing means for relaying may be included.

  In addition, as described in claim 4, in the communication relay device according to claim 1, the communication relay means targets a rekey method as a security policy item, and between two communication nodes having different rekey methods. Rekey conversion processing means for performing relaying can be provided.

  In addition, as described in claim 5, in the communication relay device according to any one of claims 1 to 4, the security policy determination unit can make the security policy between two communication nodes identical. If the security policy between the two communication nodes is the same, the communication relay means can set only one security policy between the nodes and perform only packet relay.

  Further, as described in claim 6, in the communication relay device according to any one of claims 1 to 5, when there are a plurality of set values of security policy items determined by the security policy determination means A security policy selection means for automatically selecting an item based on a predetermined criterion among set values that can be matched can be provided.

  Further, as described in claim 7, in the communication relay device according to any one of claims 1 to 5, the security policy selection unit is capable of manually selecting a security policy. Can do.

  In addition, as described in claim 8, in the communication relay device according to any one of claims 1 to 7, a communication node type for determining whether or not a communication node to be connected is the same type of communication relay device When the communication node to be connected is a communication relay device of the same type, the security policy determination unit is configured to perform security between the communication relay devices of the same type regardless of the security policy of another communication node to be relayed. A predetermined security policy can be set in the policy.

  Moreover, it can comprise as a communication relay control method as described in Claims 9-12.

  In the communication relay device of the present invention, security communication can be realized with higher security strength than nodes such as tunnel mode IPsec between nodes where security policies such as IPsec cannot be matched.

  Hereinafter, preferred embodiments of the present invention will be described. Although a case where IPsec is used as a security method will be described, it can also be applied to a security method other than IPsec.

<System configuration>
FIG. 5 is a diagram illustrating a configuration example of a communication relay device according to an embodiment of the present invention. Note that the communication relay device does not need to be specialized for relay, and includes devices that have a relay function according to the present invention in a device other than the relay application. Thereby, a more flexible network structure can be realized.

  In FIG. 5, the communication relay device 100 includes a communication hardware 110 that realizes communication by exchanging physical signals, a communication control unit 120 that controls communication relay through control of the communication hardware 110, and And a storage device 140 that records network information of the relay device itself such as an IP address and a subnet mask and setting information related to control. The communication control unit 120 is realized by communication control software (including software obtained by hardware for speeding up processing), and is implemented on hardware such as a CPU (Central Processing Unit) 131 and a memory 132. Works with.

  The communication control unit 120 performs various processes at the time of relaying packets according to the position of the device. For example, a packet filtering process is performed for a FireWall relay apparatus, and an address conversion process is performed for a NAT-use apparatus.

  FIG. 6 is a diagram illustrating a configuration example of the communication control unit 120.

  6, the communication control unit 120 includes a communication hardware driver 121 that directly controls the communication hardware 110 (FIG. 5), and a communication control processing unit that implements a communication control process while operating the communication hardware driver 121. 122.

  The communication control processing unit 122 includes an IPsec policy determination unit 123 that performs IPsec setting by negotiating an IPsec policy with two nodes to be relayed, and an IPsec relay unit 126 that performs data relay according to the IPsec setting. It has.

  The IPsec policy determination unit 123 includes an IPsec policy selection unit 124 that selects a policy by negotiation, a communication node determination unit 125 that determines whether the communication destination node is a general node, or a node having the relay function of the present invention. It has.

  The IPsec relay unit 126 includes an encryption conversion processing unit 127 that performs conversion processing for the encryption method, an authentication conversion processing unit 128 that performs conversion processing for the authentication method, and a rekey conversion processing that performs conversion processing for the rekey method. Part 129.

  Note that the configurations shown in FIGS. 5 and 6 are the minimum necessary components, and the communication relay device 100 with higher functionality can be configured by adding other devices and modules. For example, relay processing between a plurality of networks becomes possible by installing a large number of communication hardware. In addition, by incorporating a log acquisition module into the communication control unit 120, it is possible to record relayed packet information and obtain log output and statistical information.

<First operation pattern>
FIG. 7 is a diagram showing an outline of communication in the first operation pattern, which is a basic operation pattern.

  In FIG. 7, the communication relay device R creates different SAs (Security Associations) between the node N1 and the node N2, and performs a process of decrypting and re-encrypting the IPsec packet. Thus, even when the IPsec policy cannot be unified between the node N1 and the node N2, communication in which all the communication paths between the node N1 and the node N2 are made IPsec is possible. Each of the nodes N1 and N2 is only performing normal IPsec communication, and is not conscious of the IPsec communication being performed by the communication relay device R.

  In the case of the tunnel mode (FIG. 4), non-secure communication is performed between the communication relay device and one of the nodes. Therefore, the communication of this embodiment has a security strength higher than that of the tunnel mode.

  It is desirable that the communication relay device R has as many options as possible for each item of the IPsec policy so that various nodes can be used as communication targets. For example, if the communication relay device R has all algorithms as encryption algorithms, any node can be a communication target for the encryption algorithm.

  Since manual setting of the IPsec policy is difficult, usually automatic setting, particularly automatic setting using IKE is used. This embodiment also implements IPsec relay using IKE.

  FIG. 8 is a sequence diagram illustrating an example of IPsec policy negotiation processing by IKE in the communication relay apparatus 100, and sets different IPsec policies between two nodes. The negotiation process by IKE is performed with each node, so that the IPsec policy is unified with each node.

  In FIG. 8, when processing is started, security policy negotiation (negotiation for subsequent IKE Phase 2) is performed as processing of IKE Phase 1 between the node N1 and the communication relay device R (step S101). Security policy negotiation (negotiation for subsequent IKE Phase 2) is performed between the device R and the node N2 as processing of IKE Phase 1 (step S102).

  Subsequently, between the node N1 and the communication relay device R, a security policy negotiation (negotiation for subsequent security communication) is performed as processing of IKE Phase 2 (step S103). Similarly, the communication relay device R and the node N2 In the meantime, security policy negotiation (negotiation for subsequent security communication) is performed as processing of IKE Phase 2 (step S104).

  Then, when the negotiation is successful, security communication is performed between the node N1 and the node N2 via the communication relay device R (step S105).

  FIG. 9 is a flowchart illustrating an example of IPsec policy negotiation and subsequent security communication processing in the communication relay device 100.

  In FIG. 9, in the negotiation of the IPsec policy (step S111), as the IKE Phase 1 process (step S112), the IKE Phase 1 process (step S113) with the node N1 is performed. When the negotiation with the node N1 is successful, the node N2 The IKE Phase 1 process (step S114) is performed.

  If the IKE Phase 1 negotiation is successful, the IKE Phase 2 process (Step S 116) is performed as the IKE Phase 2 process (Step S 115). If the negotiation with the node N 1 is successful, the IKE Phase 2 process (Step S 116) Step S117) is performed.

  When the negotiation of IKE Phase 2 is successful, the standby state is established (step S119) upon completion of IPsec preparation (step S118), decryption is performed when a packet arrives (step S120), and encryption is performed when decryption is completed (step S120). S121) When the encryption is completed, packet transmission is performed (step S122), and the process returns to the standby state (step S119). Upon packet transmission, authentication processing other than decryption and re-encryption, ReKey processing, and the like are also performed.

  FIG. 10 is a diagram showing a more detailed processing example up to IPsec policy setting.

  In FIG. 10, when the security policy negotiation is started from the node N1 to the communication hardware driver 121 of the communication relay device R (step S131), the communication hardware driver 121 notifies the IPsec policy selection unit 124 of the policy negotiation packet information. (Step S132).

  The IPsec policy selection unit 124 requests the communication node determination unit 125 to perform node determination (step S133), and the communication node determination unit 125 requests the communication hardware driver 121 to transmit a node determination packet (step S134). 121 requests the node type notification to the destination node N2 (step S135).

  The node N2 notifies the communication hardware driver 121 of the node type (step S136), and the communication hardware driver 121 notifies the communication node determination unit 125 of the node determination response packet information (step S137). When the node N2 is a communication relay apparatus compatible with the present invention, the node type is notified. However, when the node N2 is a general node, the node type notification request is ignored and no response is returned.

  The communication node determination unit 125 determines a communication node from the node determination response packet information (step S138), and notifies the IPsec policy selection unit 124 of the node type (step S139). Note that the above node determination request (step S133) to node type notification (step S139) are mainly used in a sixth operation pattern described later, and can be omitted in other operation patterns.

  Next, the IPsec policy selection unit 124 requests the communication hardware driver 121 to transmit the policy investigation packet of the partner node (step S140), and the communication hardware driver 121 requests the node N2 to conduct the policy investigation (step S141).

  The node N2 notifies the policy information to the communication hardware driver 121 (step S142), and the communication hardware driver 121 notifies the policy information to the IPsec policy selection unit 124 (step S143).

  The IPsec policy selection unit 124 selects a policy from the policy information (step S144), sets a policy for the cryptographic conversion processing unit 127 only for the policy element that needs to be converted (step S145), and inputs the policy to the authentication conversion processing unit 128. Either policy setting (step S146), policy setting to the rekey conversion processing unit 129 (step S147), or a combination thereof is performed.

  Next, the IPsec policy selection unit 124 requests the communication hardware driver 121 to transmit a policy setting packet to the requesting node (step S148), and the communication hardware driver 121 sends a response to the negotiation to the node N1 (step S149).

  Next, the IPsec policy selection unit 124 requests the communication hardware driver 121 to transmit a policy setting packet to the requested node (step S150), and the communication hardware driver 121 requests the node N2 to set the policy (step S151).

  FIG. 11 is a diagram illustrating a more detailed processing example of the packet relay processing.

  In FIG. 11, when a communication packet arrives from the node N1 to the communication hardware driver 121 of the communication relay device R (step S161), the communication hardware driver 121 notifies the IPsec policy selection unit 124 of the received packet information (step S161). S162).

  The IPsec policy selection unit 124 starts packet relay processing (step S163), and requests only a policy element that needs to be converted, a conversion request to the cryptographic conversion processing unit 127 (step S164), and conversion to the authentication conversion processing unit 128. Either the request (step S165), the conversion request to the rekey conversion processing unit 129 (step S166), or a combination thereof is processed.

  When the conversion is completed, the communication hardware driver 121 is requested to send a packet (step S167), and the communication hardware driver 121 sends a communication packet to the destination node N2 (step S168).

<Second operation pattern>
In the second operation pattern, relay is performed by converting only predetermined items in the IPsec policy.

  12 to 14 are diagrams showing an outline of communication in the second operation pattern.

  FIG. 12 implements IPsec communication over all communication paths between nodes N1 and N2 that do not match the encryption algorithm that they own. For example, as illustrated, when the encryption algorithm owned by the node N1 is DES, the encryption algorithm owned by the node N2 is AES, and the encryption algorithm owned by the communication relay device R is DES, AES In addition, IPsec communication using DES as the encryption algorithm is performed between the node N1 and the communication relay device R, and IPsec communication using AES as the encryption algorithm is performed between the communication relay device R and the node N2.

  When unifying an IPsec policy using IKE, IKE confirms an encryption algorithm between nodes by a mechanism called a proposal, and selects and agrees on one. Therefore, in the first operation pattern processing (FIGS. 8 to 11) described above, the present embodiment can be realized by using only the encryption algorithm as the object of unification.

  In this embodiment, for the encryption method having the highest importance regarding the security strength of IPsec communication, the encryption method is converted and relayed between nodes having different encryption methods, so that only the encryption method with a low security strength can be used. It is possible to realize communication using an encryption method with higher security strength between nodes where policy cannot be set.

  FIG. 13 realizes IPsec communication of all communication paths between nodes N1 and N2 that do not match an authentication algorithm owned by them. For example, as illustrated, the authentication algorithm owned by the node N1 is MD5, the authentication algorithm owned by the node N2 is SHA-1, and the authentication algorithm owned by the communication relay device R is MD5 and SHA-1. In this case, IPsec communication using MD5 as the authentication algorithm is performed between the node N1 and the communication relay device R, and IPsec communication using SHA-1 as the authentication algorithm is performed between the communication relay device R and the node N2.

  When unifying an IPsec policy using IKE, IKE confirms an authentication algorithm between nodes by a mechanism called a proposal, and selects and agrees on one. Therefore, in the first operation pattern processing (FIGS. 8 to 11) described above, the present embodiment can be realized by using only the authentication algorithm as the object of unification.

  In this embodiment, for authentication methods that are used less frequently during IPsec communication than encryption methods, etc., the authentication method is converted and relayed between nodes with different authentication methods. It is possible to realize IPsec communication between nodes while reducing the number of relay processes that require a certain amount of processing time.

  FIG. 14 realizes IPsec communication of all communication paths between nodes that do not match the owned ReKey method. Here, ReKey is a mechanism for reconstructing the SA by exchanging keys again. The ReKey method is a method for determining the execution timing of ReKey, and there are a method for performing ReKey every fixed time and a method for performing ReKey every time a certain amount of packets are communicated. In FIG. 14, when the ReKey method owned by the node N1 is time, the ReKey method owned by the node N2 is the packet amount, and the ReKey method owned by the communication relay device R is the time and the packet amount, the node N1 Between the communication relay apparatuses R, IPsec communication using time in the ReKey system is performed, and between the communication relay apparatuses R and the node N2, IPsec communication using the packet amount is performed in the ReKey system.

  When unifying an IPsec policy using IKE, IKE confirms the ReKey method between nodes by a mechanism called a proposal, and selects and agrees on one. Therefore, in the first operation pattern processing (FIGS. 8 to 11) described above, the present embodiment can be realized by using only the ReKey method as an object of unification.

<Third operation pattern>
In the third operation pattern, the communication relay device automatically determines whether or not the same IPsec policy can be held between nodes at the time of IKE negotiation. Is. However, processing for packet relay purposes, such as changing the IP address, continues. Processing such as decryption and re-encryption of IPsec packets is heavy, but if direct IPsec communication is possible between nodes, this load can be allocated by direct communication.

  FIG. 15 is a diagram showing an outline of communication in the third operation pattern, in which the encryption algorithm owned by the node N1 is DES, the encryption algorithms owned by the node N2 are DES and AES, and the communication relay device R Are DES and AES, IPsec communication using DES is performed in all sections of the node N1, the communication relay device R, and the node N2.

  FIG. 16 is a sequence diagram showing an example of IPsec policy negotiation processing by the IKE in the communication relay device 100.

  In FIG. 16, when processing is started, security policy negotiation (negotiation for subsequent IKE Phase 2) is performed as processing of IKE Phase 1 between the node N1 and the communication relay device R (step S201). Security policy negotiation (negotiation for subsequent IKE Phase 2) is performed between the device R and the node N2 as IKE Phase 1 processing (step S202).

  Subsequently, between the node N1 and the communication relay apparatus R, a security policy negotiation (negotiation for subsequent security communication) is performed as a process of IKE Phase 2 (step S203). Similarly, between the communication relay apparatus R and the node N2 In the meantime, security policy negotiation (negotiation for subsequent security communication) is performed as processing of IKE Phase 2 (step S204). In the negotiation between the communication relay device R and the node N2, it is determined whether or not the same IPsec policy can be set between the nodes N1 and N2.

  Then, when the negotiation is successful and the same IPsec policy can be set between the nodes N1 and N2, security communication in which the IPsec relay processing is not performed between the node N1 and the node N2 via the communication relay device R. Is performed (step S205).

  FIG. 17 is a flowchart showing an example of IPsec policy negotiation and subsequent security communication processing in the communication relay device 100. Steps S211 to S222 are substantially the same as steps S111 to S122 of FIG. 9, but “Is it determined whether or not the same IPsec policy can be set between the nodes” in the process of IKE Phase 2 with the node N2 (step S217). If it is determined that the same IPsec policy can be set between nodes, the non-relay mode process (step S223) is performed without relaying the packet (just changing the IP address or the like on the packet) It does not re-encrypt))

  Note that the omission of relay processing can be performed by IKE Phase 2 communication and IPsec communication. However, since IKE Phase 2 is temporary communication for exchanging policies for IPsec communication, only the IPsec communication is targeted in this embodiment. It is said. As a different embodiment, the relay process may be omitted also in IKE Phase 2 to improve the efficiency of IKE Phase 2 negotiation.

<Fourth operation pattern>
In the fourth operation pattern, when there are a plurality of selection candidates in the items of the security policy between the communication relay device and the node, the most suitable one according to a predetermined standard is automatically selected.

  FIG. 18 is a diagram showing an outline of communication in the fourth operation pattern. A common DES is used as an encryption algorithm between the node N1 and the communication relay apparatus R, but the communication relay apparatus R and the node N2 are used. Since ADES can be selected from 3DES and AES, AES is selected according to the standard.

  FIG. 19 is a diagram showing an example of a setting file used for setting policy selection criteria. The encryption algorithm priority is set in the order of AES, 3DES, and DES, and the authentication algorithm priority (authentication) is set. algorithm priority) is set in the order of SHA-1 and MD5. The setting file is set by the user via the WEB setting screen interface or the like.

  When IKE is used to unify the IPsec policy, each item of the security policy between the nodes is selected by IKE and one is selected, and if there are multiple selection candidates at that time, IKE is the most dependent on the setting. Automatically select the appropriate one. Therefore, in the first operation pattern processing (FIGS. 8 to 11) described above, the priority order of each algorithm or the like is set (FIG. 19) in the setting file referred to at the time of automatic selection. An example can be realized.

<Fifth operation pattern>
The fifth operation pattern enables manual setting of the security policy between the communication relay device and the node. Although the automatic setting by the fourth operation pattern described above is convenient, there is a possibility that an undesired setting may be made by the automatic setting. Therefore, by providing the communication relay device with a function for manually setting the security policy setting for each node, all or arbitrary policy items can be explicitly specified as necessary.

  FIG. 20 is a diagram showing an example of a manual policy setting list image in the fifth operation pattern, and shows a state in which “IP (address)”, “port”, “encryption algorithm”, “authentication algorithm”, etc. are set. . The setting is performed by the user via a WEB setting screen interface or the like. The setting contents are recorded in the storage device 140 (FIG. 5) and can be reused.

  FIG. 21 is a flowchart illustrating an example of processing for setting an IPsec policy in the communication relay device 100 and subsequent security communication.

  In FIG. 21, the security policy is manually set between the communication relay device and the node in setting reading and security policy setting (step S301).

  When the setting of the security policy is completed, the standby state is set when IPsec preparation is complete (step S302) (step S303). When the packet arrives, decryption is performed (step S304), and when decryption is completed, encryption is performed (step S305). When the encryption is completed, packet transmission is performed (step S306), and the process returns to the standby state (step S303). Upon packet transmission, authentication processing other than decryption and re-encryption, ReKey processing, and the like are also performed.

  Since it is desirable to switch between automatic setting and manual setting, the processes in FIGS. 9 and 21 are switched according to the IPsec policy setting mode (automatic / manual).

<Sixth operation pattern>
The sixth operation pattern is such that a similar communication relay device can be handled as a relay target node. This makes it possible to change the IPsec policy between communication relay devices to the policy between communication relay devices and nodes, and enables communication that divides the communication path between nodes into sections and has an appropriate security policy for each section. It becomes. That is, as shown in FIG. 22, when there is one communication relay device R between the nodes N1 and N2, the choice of the IPsec policy between the communication relay device R and the nodes N1 and N2 depends on the node. If a node has only a weak encryption algorithm, it must be used. When this extends over the entire section, there is a security problem, but according to this embodiment, an appropriate security policy can be given to the section where safety should be improved.

  FIG. 23 is a diagram showing an outline of communication in the sixth operation pattern, in which the communication relay device R1 and the communication relay device R2 are arranged between the node N1 and the node N2. Here, the security policy A is between the node N1 and the communication relay device R1, and the security policy B is between the communication relay device R2 and the node N2. These security policies A and B are within a range that the nodes N1 and N2 can handle. However, the security policy C between the communication relay device R1 and the communication relay device R2 can be made sufficiently secure from many options.

  When unifying the IPsec policy using IKE, the result of the communication node type notification (S139 in FIG. 10) is the same communication relay device in the processing of the first operation pattern (FIGS. 8 to 11) described above. In this case, the present embodiment can be realized by unifying the IPsec policy between the communication relay apparatuses separately from the nodes at both ends.

<Summary>
As described above, the embodiment of the present invention has the following advantages.
(1) Since two communication paths having different IPsec policies are relayed, it is possible to make all communication paths IPsec communication between nodes whose IPsec policies cannot be matched. This is communication with higher security strength than tunnel mode IPsec.
(2) Since IPsec communication with each node is relayed between nodes whose IPsec policies cannot be matched because the encryption algorithms they own do not match, it is possible to make all communication paths IPsec communication between the nodes. it can. This is communication with higher security strength than tunnel mode IPsec.
(3) Since the IPsec communication with each node is relayed between nodes whose IPsec policies cannot be matched due to mismatching of the owned authentication algorithms, all communication paths can be communicated between the nodes. . This is communication with higher security strength than tunnel mode IPsec.
(4) Since IPsec communication with each node is relayed between nodes whose IPsec policies cannot be matched due to a mismatch in the owned rekey (ReKey) method, IPsec communication is performed on all communication paths between the nodes. be able to. This is communication with higher security strength than tunnel mode IPsec.
(5) It is automatically determined whether or not the IPsec policy can be unified between the two nodes to be relayed, and if it can be unified, the processing for stopping the IPsec relay processing is performed, thereby preventing a reduction in processing efficiency due to unnecessary relay processing. it can.
(6) When there are a plurality of candidates that can be set in the IPsec policy item to be set, the most appropriate one according to a predetermined standard is automatically selected. In addition to improving policy setting efficiency between nodes, it is possible to improve efficiency and safety.
(7) Since the IPsec policy set with the node can be manually set, it can be realized when the user wants to set the IPsec policy strictly.
(8) Since the setting of the IPsec policy can be changed according to the property of the portion of the communication path, it is possible to realize a communication path having a required security strength for each section.

  The present invention has been described above by the preferred embodiments of the present invention. While the invention has been described with reference to specific embodiments, various modifications and changes may be made to the embodiments without departing from the broad spirit and scope of the invention as defined in the claims. Obviously you can. In other words, the present invention should not be construed as being limited by the details of the specific examples and the accompanying drawings.

It is a sequence diagram which shows the negotiation process of the IPsec policy by IKE in general IPsec communication. It is a flowchart which shows the negotiation of IPsec policy, and the process of subsequent security communication. It is a figure which shows the example in which IPsec communication is impossible by the mismatch of a security policy. It is a figure which shows the example of tunnel mode IPsec. It is a figure which shows the structural example of the communication relay apparatus concerning one Embodiment of this invention. It is a figure which shows the structural example of a communication control part. It is a figure which shows the outline | summary of the communication in a 1st operation | movement pattern. It is a sequence diagram which shows the example of a process of the negotiation of the IPsec policy by IKE in a communication relay apparatus. It is a flowchart which shows the negotiation of the IPsec policy in a communication relay apparatus, and the process example of subsequent security communication. It is a figure which shows the example of a more detailed process until IPsec policy setting. It is a figure which shows the more detailed process example of a packet relay process. It is a figure (the 1) which shows the outline | summary of the communication in a 2nd operation | movement pattern. It is a figure (the 2) which shows the outline | summary of the communication in a 2nd operation | movement pattern. It is FIG. (3) which shows the outline | summary of the communication in a 2nd operation | movement pattern. It is a figure which shows the outline | summary of the communication in a 3rd operation pattern. It is a sequence diagram which shows the example of a process of the negotiation of the IPsec policy by IKE in a communication relay apparatus. It is a flowchart which shows the negotiation of the IPsec policy in a communication relay apparatus, and the process example of subsequent security communication. It is a figure which shows the outline | summary of the communication in a 4th operation pattern. It is a figure which shows the example of the setting file used for the setting of a policy selection reference | standard. It is a figure which shows the example of the list image of the manual policy setting in a 5th operation pattern. It is a flowchart which shows the example of a process of the setting of the IPsec policy in a communication relay apparatus, and subsequent security communication. It is a figure which shows the problem in case there is one communication relay apparatus. It is a figure which shows the outline | summary of the communication in a 6th operation pattern.

Explanation of symbols

N1, N2 Nodes R, R1, R2 Communication relay device 100 Communication relay device 110 Communication hardware 120 Communication control unit 121 Communication hardware driver 122 Communication control processing unit 123 IPsec policy determination unit 124 IPsec policy selection unit 125 Communication node determination unit 126 IPsec relay unit 127 Cryptographic conversion processing unit 128 Authentication conversion processing unit 129 Rekey conversion processing unit 131 CPU
132 memory 140 storage device

Claims (12)

A communication relay device for a network to which a predetermined security method is applied,
Security policy determination means for determining the security policy of each of the two communication nodes to be relayed;
A communication relay apparatus comprising: a communication relay unit that sets an individual security policy with each of the communication nodes and relays between two communication nodes having different security policies. The communication relay device according to claim 1,
The communication relay unit includes an encryption conversion processing unit that relays between two communication nodes having different encryption methods, with the encryption method as a security policy item. The communication relay device according to claim 1,
The communication relay unit includes an authentication conversion processing unit that targets an authentication method as a security policy item and relays between two communication nodes having different authentication methods. The communication relay device according to claim 1,
The communication relay unit includes a rekey conversion processing unit that performs a relay between two communication nodes having different rekey methods, targeting the rekey method as a security policy item. In the communication relay device according to any one of claims 1 to 4,
The security policy determination means determines whether the security policy between two communication nodes can be made identical,
The communication relay device, wherein when the security policies between two communication nodes are the same, the communication relay means sets only one security policy between the nodes and performs only packet relay. In the communication relay device according to any one of claims 1 to 5,
When there are a plurality of setting values of security policy items determined by the security policy determination means, security policy selection means is provided for automatically selecting an item based on a predetermined criterion among setting values that can be matched. Communication relay device to do. In the communication relay device according to any one of claims 1 to 5,
The communication relay apparatus according to claim 1, wherein the security policy selection means can manually select a security policy. The communication relay device according to any one of claims 1 to 7,
Comprising a communication node type determining means for determining whether or not a communication node to be connected is the same type of communication relay device;
When the communication node to be connected is the same type of communication relay device, the security policy determination means has a predetermined security in the security policy between the same type of communication relay devices regardless of the security policy of the other communication node to be relayed. A communication relay device that sets a policy. A communication relay control method in a network to which a predetermined security method is applied,
A security policy determination step for determining the security policy of each of the two communication nodes to be relayed;
A communication relay control method, comprising: a communication relay step of setting an individual security policy with each of the communication nodes and relaying between two communication nodes having different security policies. In the communication relay control method according to claim 9,
The security policy determination step determines whether or not the security policy between two communication nodes can be made the same,
When the security policy between two communication nodes is the same, the communication relay control method is characterized in that only one packet is relayed by setting one security policy between the nodes. In the communication relay control method according to any one of claims 9 and 10,
A security policy selection step of automatically selecting an item based on a predetermined criterion among set values that can be matched when there are a plurality of setting values of security policy items determined by the security policy determination step; Communication relay control method. The communication relay control method according to any one of claims 9 to 11,
A communication node type determination step for determining whether or not the communication node to be connected is the same type of communication relay device;
When the communication node to be connected is the same type of communication relay device, the security policy determination step includes a predetermined security in the security policy between the same type of communication relay devices regardless of the security policy of the other communication node to be relayed. A communication relay control method characterized by setting a policy.

Images