TCP communication scheme

Abstract

A TCP communication scheme which ensures safe communication up to the communication path near a terminal and eliminates direct attacks from hackers, etc. A terminal (A) and terminal (B) are connected to a relay apparatus (X) and relay apparatus (Y), where the terminal (A) and the terminal (B) are the endpoint terminals positioned at the two ends of a TCP communication connection. The relay apparatuses (X, Y) are each connected to a network (NET). The relay apparatuses (X and Y) are provided so as to be between the terminals (A and B) which had been performing conventional TCP communication, and neither of the relay apparatuses (X and Y) have IP addresses. The relay apparatuses (X and Y) take over the TCP connection between the terminal (A) and the terminal (B), divide the connection into three TCP connections, and establish TCP communication.

Claims

1. A transmission control protocol (TCP) communication method, comprising: providing first and second terminals that are connected by TCP to each other through a network; providing each of the first and second terminals with TCP software provided with a function of catching a TCP synchronize (SYN) packet sent at beginning of connection, and obtaining connection target information, and establishing TCP connection while behaving as an opposite terminal based on the connection target information; and adding a specific function to TCP communication through the TCP connection, wherein, establishing the TCP connection comprises: (a) catching a SYN packet in a promiscuous mode by a network driver; (b) obtaining a sender IP address, a sender port number, a target IP address and a target port number from the caught SYN packet by the network driver; (c) notifying an application of the information obtained by the network driver; (d) using the notified information to perform procedures of creating, binding and accepting a socket by the application; (e) passing the SYN packet to a TCP stack by the network driver; and (f) establishing, by the TCP stack, the TCP connection by a normal procedure to complete connection of the socket.

2. The TCP communication method as claimed in claim 1, wherein the specific function includes: an encrypted communication function implementing a means for encryption and decryption; an anti-virus function implementing a procedure for interrupting unauthorized TCP communication; a load distributing function implementing a procedure for distributing transmission depending on load condition; a bandwidth control function implementing a procedure for congestion control and bandwidth control; and a gateway function implementing a procedure for relay for a special line.

3. A transmission control protocol (TCP) communication system, comprising: first communication means and second communication means that are connected by TCP to each other through a network, wherein: each of the first communication means and the second communication means has relay means for catching a TCP synchronize (SYN) packet sent at beginning of connection, and obtaining connection target information, and establishing TCP connection while behaving as an opposite terminal based on the connection target information; and specific means is added to TCP communication through the TCP connection; wherein the relay means is configured to: (a) catch a SYN packet in a promiscuous mode by a network driver; (b) obtain a sender IP address, a sender port number, a target IP address and a target port number from the caught SYN packet by the network driver; (c) notify an application of the information obtained by the network driver; (d) use the notified information to perform procedures of creating, binding and accepting a socket by the application; (e) pass the SYN packet to a TCP stack by the network driver; and (f) establish, by the TCP stack, the TCP connection by a normal procedure to complete connection of the socket.

4. The TCP communication system as claimed in claim 3, wherein the specific means includes: means for encryption and decryption; anti-virus means for implementing a procedure for interrupting unauthorized TCP communication; load distributing means for implementing a procedure for distributing transmission depending on load condition; bandwidth control means for implementing a procedure for congestion control and bandwidth control; and gateway means for implementing a procedure for relay for a special line.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

(1) FIG. 1 is a network configuration diagram showing a TCP communication scheme according to an embodiment 1:

(2) FIG. 2 shows the frame format of Ethernet (registered trademark);

(3) FIGS. 3A and 3B are diagrams showing divisional TCP connections;

(4) FIG. 4 is a block configuration diagram showing an encrypted communication device according to an application example 1;

(5) FIG. 5 is a block configuration diagram showing an anti-virus device according to an application example 2;

(6) FIG. 6 is a block configuration diagram showing a load distributing device according to an application example 3;

(7) FIG. 7 is a block configuration diagram showing a bandwidth control device according to an application example 4;

(8) FIG. 8 is a block configuration diagram showing a gateway device according to an application example 5;

(9) FIG. 9 is a diagram showing a LAN-to-LAN-connecting VPN;

(10) FIG. 10 is a diagram showing a remote access VPN;

(11) FIG. 11 is a diagram showing TCP option fields of types 06 and 07 in standard mode of use;

(12) FIG. 12 is a diagram showing a sequence for acknowledgement in cases where a relay device Y exists;

(13) FIG. 13 is a diagram showing a sequence for acknowledgement in cases where no relay device Y exists and a terminal B is compatible with type 6;

(14) FIG. 14 is a diagram showing a sequence for acknowledgement in cases where no relay device Y exists and terminal B is incompatible with type 6;

(15) FIG. 15 is a diagram showing a TCP option field of type 19 in standard mode of use;

(16) FIG. 16 is a diagram showing a sequence for acknowledgement in cases where relay device Y exists;

(17) FIG. 17 is a diagram showing a sequence for acknowledgement in cases where no relay device Y exists and terminal B is incompatible with type 19; and

(18) FIG. 18 is a diagram showing a procedure of operation according to an application example 6.

MODE(S) FOR CARRYING OUT THE INVENTION

(19) The following describes embodiments of the present invention in detail with reference to the drawings.

Embodiment 1

(20) FIG. 1 is a network configuration diagram showing a TCP communication scheme according to an embodiment 1. In FIG. 1, terminals A, B are endpoint terminals located on opposite ends of TCP communication. Terminals A, B are connected to relay devices X, Y through transmission lines 11, 14, respectively. Relay devices X, Y are connected to a network NET through transmission lines 12, 13, respectively.

(21) Relay devices X, Y are provided and inserted in a section between terminals A, B between which communication has been made previously. Relay devices X, Y are allocated with no IP addresses. For ease of explanation, terminals A, B are henceforth referred to as active side and passive side of TCP connection, respectively.

(22) Relay devices X, Y intercept TCP connection between terminals A, B, and divide same into three TCP connections, and establish TCP communication.

(23) The following describes operations of active-side and passive-side relay devices X, Y.

(24) (1) Operation of Active-Side Relay Device X (a) Relay device X waits in promiscuous mode. Promiscuous mode is one of operation modes of LAN card. In contrast to normal mode in which relay device X receives only packets whose target addresses indicate relay device X, relay device X receives packets having any target addresses in promiscuous mode. (b) Relay device X catches a SYN (synchronize) packet that is a packet sent from terminal A for beginning TCP connection. (c) Relay device X obtains from information of the SYN packet a sender IP address (obtained from the IP header), a sender port number (obtained from the TCP header), a target IP address (obtained from the IP header), and a target IP port (obtained from the TCP header). (d) Relay device X begins TCP connection to the obtained target address while behaving as terminal A. (e) At this time, the SYN packet is added with an identifier indicative of relay device X. The following describes this identifier with reference to the frame format of Ethernet (registered trademark) shown in FIG. 2. TCP option fields (henceforth referred to as TCP options) contained in the TCP header are used. The active-side uses a TCP option of type code 06, and the passive-side uses a TCP option of type code 07. The digits “06” following the type code “06” or “07” indicate the data length of the TCP option. The following digits “04 . . . 0400100” or “C0 . . . C00100” indicate an identifying code (identifier) which is defined originally. Values of the identifying code can be defined to indicate different meanings so that the identifying code can be used for various usages. (f) When a reply packet (SYN+ACK (Acknowledge)) from passive-side relay device Y is added with a similar identifier, relay device X recognizes that there is a counterpart relay device on the opposite side, and continues this procedure. For example, the procedure includes sending an ACK packet back to passive-side relay device Y. (g) At the time when TCP connection with relay device Y is completed, TCP connection with terminal A is completed. By this connection, relay device X performs an operation of sending a (SYN+ACK) packet back to terminal A, and an operation of awaiting an ACK packet from terminal A.

(25) The foregoing explanation is illustrated in FIG. 3A that is a diagram showing divisional TCP connections.

(26) (2) Operation of Passive-Side Relay Device Y (a) Relay device Y waits in promiscuous mode. (b) Relay device Y catches the SYN packet sent from relay device X. (c) Relay device Y obtains from information of the SYN packet the sender IP address, sender port number, target IP address, and target port number. (d) Relay device Y begins TCP connection to terminal B while behaving as terminal A. (e) When receiving a reply packet of (SYN+ACK) from terminal B, relay device Y adds the “identifier” to the TCP option in (SYN+ACK), and sends the reply packet of (SYN+ACK) to relay device X while behaving as terminal B. (f) At the time when TCP connection with relay device X is completed. TCP connection with terminal B is completed.

(27) The foregoing explanation is illustrated by FIG. 3A.

(28) (3) Establishment of Divided TCP Connections

(29) When the operations (1), (2) are completed, the original single TCP connection between terminal A and terminal B is divided into three TCP connections between terminal A and relay device X, between relay device X and relay device Y, and between relay device Y and terminal B.

(30) Accordingly, payload data on TCP is relayed and transmitted through the three TCP connections between the terminals, where existence of the relay devices is unrecognizable, namely, the relay devices are invisible to the terminals.

(31) Regarding the TCP connection between relay devices, payload data may be processed arbitrarily depending on agreement between the relay devices. This can be used to add the divisional TCP communication with a specific function.

(32) The foregoing explanation is silent about data transmission. Data is transmitted simply between terminal A and terminal B. The data is processed in some way between relay device X and relay device Y, and is transmitted.

(33) FIG. 3A shows a case where relay devices X, Y exist. On the other hand. FIG. 3B shows a case where only relay device X or only relay device Y exists. FIG. 3B is a diagram showing division for a case where only relay device X exists, and is applied to an application example 2, an application example 3, and an application example 5.

(34) In this case, relay device X confirms that the reply packet (SYN+ACK) from terminal B is added with no identifier in the TCP option of type code 07, and thereafter sends an ACK packet back to terminal B, and sends a (SYN+ACK) packet to terminal A.

Embodiment 2

(35) An embodiment 2 employs the TCP options of type codes 06, 07. Type code 06 is “Echo (obsoleted by option 8) RFC1072”. Type code 07 is “Echo Reply (obsoleted by option 8) RFC1072”.

(36) FIG. 11 is a diagram showing a sequence in standard mode of use of the TCP options of type codes 06 and 07. By definition, the TCP options of code types 06 and 07 are used for measuring a reply period in TCP congestion control. For example, when the sender device (relay device X) shown in FIG. 2 sends to the opposite target device (relay device Y) a packet in which an arbitrary number is set in type code 06, then the target device which has received the packet sends back to the sender device a packet in which the arbitrary number is set in type code 07. The sender device measures time when the packet in which the same number is set is reached, and uses it in congestion control.

(37) Proactive information exchange is implemented by mutually sending an arbitrary number (packet) provided with a specific meaning, by using the function of the TCP options described above. The following describes a case in which relay device Y which has a comparable function as relay device X exists on the opposite side, and confirmation (authorization) is implemented by the method described above.

(38) (1) Case Where Similar Relay Device Y Exists

(39) In case where a similar relay device Y exists on the opposite side of relay device X, relay device X confirms the existence of relay device Y by the following procedure.

(40) The following describes a confirmation sequence shown in FIG. 12.

(41) (a) Relay device X adds type code 06 containing a specific identifier A (for example, 0x4040404040, etc.) to the TCP option of a SYN packet for TCP three-way handshake, and sends same.

(42) (b) When having received the identifier A, relay device Y confirms that similar relay device X exists on the opposite side, and relay device Y adds type code 07 containing a specific identifier B (for example, 0xC0C0C0C0C0, etc.) to the TCP option of a SYN+ACK packet, and sends same.

(43) (c) When having received the identifier B, relay device X confirms that similar relay device Y exists on the opposite side, and returns ACK to complete three-way handshake, and thereby establish connection.

(44) (2) Case where Device Compatible with TCP Options of Type Codes 06 and 07 Exists

(45) In cases where no similar relay device Y exists on the opposite side of relay device X, but only a device only compatible with the TCP options of type codes 06 and 07 exists, relay device X confirms by the following procedure that no similar relay device Y exists.

(46) The following describes a confirmation sequence shown in FIG. 13.

(47) (a) Relay device X adds type code 06 containing a specific identifier A (for example, 0x4040404040, etc.) to the TCP option of a SYN packet for TCP three-way handshake, and sends same.

(48) (b) When having received the identifier A, relay device Y adds type code 07 containing the received identifier A to the TCP option of a SYN+ACK packet, and sends back same, according to the standard regulation.

(49) (c) When having received the identifier A, relay device X confirms that no similar relay device Y exists on the opposite side, and establishes connection by three-way handshake by returning ACK, or cancels the opening of connection by terminating the three-way handshake by returning RST (Reset).

(50) (3) Case where Device Incompatible with TCP Options of Type Codes 06 and 07 Exists

(51) In cases where no similar relay device Y exists on the opposite side of relay device X, but a device incompatible with the TCP options of type codes 06 and 07 exists, relay device X confirms by the following procedure that no similar relay device Y exists.

(52) The following describes a confirmation sequence shown in FIG. 14.

(53) (a) Relay device X adds type code 06 containing a specific identifier A (for example, 0x4040404040, etc.) to the TCP option of a SYN packet for TCP three-way handshake, and sends same.

(54) (b) Relay device Y returns a SYN+ACK packet with no TCP option added.

(55) (c) When having received the identifier A, relay device X confirms that no similar relay device Y exists on the opposite side, and establishes connection by three-way handshake by returning ACK, or cancels the opening of connection by terminating the three-way handshake by returning RST (Reset).

Embodiment 3

(56) An embodiment 3 employs the TCP option of type 19. Type 19 is “MD5 Signature Option RF2385”.

(57) FIG. 15 is a diagram showing a sequence in standard mode of use of the TCP option of type 19. By definition, type 19 is an option intended for BGP (Border Gateway Protocol), which is used for signature based on MD5 hash value of the TCP segment. Every TCP segment flowing over a BGP session is added with this option for protecting the BGP session.

(58) Embodiment 3 implements proactive information exchange by mutually sending an arbitrary number provided with a specific meaning, by using the function of the TCP option shown in FIG. 15. However, this scheme cannot be used over BGP sessions, because this scheme is in conflict with the standard usage over BGP sessions. Accordingly, this scheme is limited to sessions except BGP sessions. The following describes a case in which relay device X confirms or authorizes by the above method that relay device Y having a similar function exists on the opposite side.

(59) (1) Case where Similar Relay Device Y Exists

(60) FIG. 16 is a diagram showing a confirmation sequence for cases where similar relay device Y exists on the opposite side. In FIG. 16, relay device X confirms the existence of relay device Y by the following procedure. If the target TCP port number is BGP (179), no confirmation is performed.

(61) (a) Relay device X adds type code 19 containing a specific identifier A (for example, 0x4040404040, etc.) to the TCP option of a SYN packet for TCP three-way handshake, and sends same.

(62) (b) When having received the identifier A, relay device Y confirms that similar relay device X exists on the opposite side, and relay device Y adds type code 19 containing a specific identifier 13 (for example, 0xC0C0C0C0C0, etc.) to the TCP option of a SYN+ACK packet, and sends same.

(63) (c) When having received the identifier B, relay device X confirms that similar relay device Y exists on the opposite side, and returns ACK to complete three-way handshake, and thereby establish connection.

(64) (2) Case where Device Incompatible with TCP Option of Type Code 19 Exists

(65) In cases where no similar relay device Y exists on the opposite side of relay device X, relay device X confirms by the following procedure that no similar relay device Y exists. If the target TCP port number is BGP (179), no confirmation is performed.

(66) The following describes a confirmation sequence shown in FIG. 17.

(67) (a) Relay device X adds type code 19 containing a specific identifier A (for example, 0x4040404040, etc.) to the TCP option of a SYN packet for TCP three-way handshake, and sends same.

(68) (b) Relay device Y returns a SYN+ACK packet with no TCP option added.

(69) (c) With reference to the condition that relay device X has failed to receive the TCP option of type code 19, relay device X confirms that no similar relay device Y exists on the opposite side, and establishes connection by three-way handshake by returning ACK, or cancels the opening of connection by terminating the three-way handshake by returning RST (Reset).

(70) In embodiment 3 described above, no special packet is used. This serves to eliminate the necessity of changing path-through setting of a firewall, etc., and allow to implement extended functions by defining a plurality of identifiers.

INDUSTRIAL APPLICABILITY

(71) The present invention in the form of embodiment 1 is applicable to application examples described below.

Application Example 1

(72) FIG. 4 shows an encrypted communication device according to this application example. The encrypted communication device is composed of a terminal A-a device X-a device Y-a terminal B. Device X is composed of an internal TCP connection handling section X1, an encryption handling section X2, external TCP connection handling sections X3, X4, and a decryption handling section X5. Device Y is composed of an internal TCP connection handling section Y1, an encryption handling section Y2, external TCP connection handling sections Y3, Y4, and a decryption handling section Y5.

(73) In application example 1 configured as described above, data transmission from terminal A to terminal B is implemented by processing data from terminal A at internal TCP connection handling section X1 of device X, and then encrypting the data at encryption handling section X2, and inputting the data through external TCP connection handling section X3 to external TCP connection handling section Y4 of device Y, and then decrypting the data at decryption handling section Y5, and sending the data through internal TCP connection handling section Y1 to terminal B.

(74) On the other hand, data transmission from terminal B to terminal A is implemented conversely by processing data at internal TCP connection handling section Y1 of device Y, and encrypting the data at encryption handling section Y2, and inputting the data through external TCP connection handling section Y3 to external TCP connection handling section X4 of device X, and then decrypting the data at decryption handling section X5, and sending through internal TCP connection handling section X1 to terminal A.

(75) By allowing the encrypted communication device to function as described above, it is possible to achieve encrypted communication in the communication line from terminal A to terminal B or from terminal B to terminal A. For example, it is possible to achieve a function of proactive key exchange for encrypted communication by exchanging key information proactively.

Application Example 2

(76) FIG. 5 shows an anti-virus device according to this application example 2. The anti-virus device is composed of a terminal A-a device X-terminals B, C, D. Device X is composed of an external TCP connection handling section 41, a virus inspection handling section 42, and an internal TCP connection handling section 43. The thus-configured device X performs virus inspection at virus inspection handling section 42 during a process of relay of TCP communication, and interrupts TCP communication failed in the inspection. For example, this prevents unauthorized accesses from terminal A to terminals B, C, D, or unauthorized accesses from terminals B, C, D to terminal A.

Application Example 3

(77) FIG. 6 shows a load distributing device according to this application example. The load distributing device is composed of terminals A, B, C, a router R, a device X, and a plurality of servers 1-N. Device X is composed of an external TCP connection handling section 51, a load distribution handling section 52, and an internal TCP connection handling section 53. In the thus-configured load distributing device, device X on the front side of servers 1-N can achieve load distribution by distributing transmission to suitable servers 1-N depending on load condition.

(78) For example, terminals A, B, C connect to a public IP address. At this instant, device X selects one of servers 1-N depending on load conditions of servers 1-N, and relays TCP connection. Accordingly, terminals A-C seem to be connected by TCP to the public IP address. On the other hand, servers 1-N seem to be connected by their respective different IP addresses to an IP address of an external terminal.

Application Example 4

(79) FIG. 7 shows a bandwidth control device according to this application example. The bandwidth control device is composed of a terminal A-a device X-a device Y-a terminal B. Device X is composed of an internal TCP connection handling section 61x, a congestion control and bandwidth control handling section 62x, and a special-purpose protocol handling section 63x. Device Y is composed of an internal TCP connection handling section 61y, a congestion control and bandwidth control handling section 62y, and a special-purpose protocol handling section 63y.

(80) In the thus-configured arrangement of terminal A-device X-device Y-terminal B, precise congestion control and bandwidth control is performed with a special-purpose protocol between device X and device Y, thereby making it possible to achieve a bandwidth control suitable for a line which cannot be handled with general TCP.

Application Example 5

(81) FIG. 8 shows a gateway device according to this application example. The gateway device is composed of a terminal A-a device X-a terminal B. Device X is composed of an external TCP connection handling section 71, a gateway handling section 72, and an internal TCP connection handling section 73.

(82) In the thus-configured device, terminal B operates based on a special protocol or special data. Terminal A requires a gateway device as a device for conversion for communication based on a normal protocol or normal data. Accordingly, device X is provided immediately on the front side of terminal B so as to allow conversion processing of protocol or data. Generally, a gateway device is provided with an IP address, and communications are made between terminal A and device X and between device X and terminal B. In contrast, it seems in this application example that device X does not exist.

Application Example 6

(83) Application example 6 is configured to make it possible to incorporate all of the functions of embodiment 1 and application examples 1-5 into TCP protocol stack software in terminals, and thereby implement the functions by software without using an external hardware device.

(84) In usual cases in which waiting for connection is performed by a TCP protocol stack, a socket is created proactively, and a port number for connection is assigned (Bind), and waiting for connection is performed (Accept).

(85) However, in the case of relay device X in embodiment 1, the sender IP address, target IP address, sender port number, and target port number cannot be known beforehand. Accordingly, a SYN TCP packet which is sent first for connection is caught in promiscuous mode, and connection target information is obtained, and a socket for accepting connection is prepared, and procedures of binding and acceptance are performed proactively, and the TCP protocol stack is made to handle the packet. By these operations, it is possible to complete TCP connection while behaving as the opposite terminal B.

(86) The following describes an operation procedure for the case described above with reference to the diagram of FIG. 18.

(87) (a) First, a SYN packet is caught in promiscuous mode. (Network Driver)

(88) (b) A target IP address and a target port number are obtained from the caught SYN packet. (Network Driver)

(89) (c) An application is notified of the obtained target information. (Network Driver)

(90) (d) Procedures of socket creation, binding, and acceptance are performed using the notified information. (Application)

(91) (e) The SYN packet is passed to a TCP protocol stack. (Network Driver)

(92) (f) TCP connection is established by a normal procedure, to complete connection of the socket. (TCP Protocol Stack)

DESCRIPTION OF REFERENCE SIGNS

(93) A, B . . . Terminals X, Y . . . Relay Devices NET . . . Network 11-14 . . . Transmission Lines