US20090106830A1 - Secure Network Communication System and Method - Google Patents

Abstract

A secure network communication system and method for secure data exchange using transmission control protocol are disclosed. The system provides for data exchange using between a client and a server, by way of an agent and a broker interconnected to exchange data over an unsecured network link. Upon receipt of a control packet from the client, the broker forwards a modified control packet to the agent using a secure protocol. The agent then inspects the modified control packet and forwards it to the server. Upon receipt of a response packet from the server, the agent forwards the response packet to the broker using a secure protocol and upon receipt of the response packet, the agent modifies the response packet and forwards it to the client. In the case that the exchange of control packets indicates establishment of a TCP session, the agent and the broker establish a data channel between themselves to create a transparent TCP channel between the client and the server.

Description

• This invention relates to a secure network communication system and method. In particular, it relates a communication system and method to enable secure clients to obtain secure and transparent access to a remote server over an insecure network.
• It is widely recognised that connecting a computer to communicate with an insecure network such as the Internet represents a security risk. In order to perform useful tasks, such a computer must necessarily react to data that is received from remote servers over the network. Malicious attackers can exploit deficiencies in the computer's operating system and applications to react in such a way as to perform functions that might compromise the security or serviceability of the computer. Accordingly, it is normal for a private computer or network of computers is not connected directly to a public network. Rather, a connection is made to the network through some restrictive interface that controls the nature of the data that can be exchanged between the private computers and the unsecured network. The typical configuration of the hosts and networks is that client hosts are “inside” or trusted, while servers are “outside” or untrusted.
• Two existing methods for enabling secure transparent gateway access between networks are by means of a proxy (for example, as disclosed in U.S. Pat. No. 5,623,601 and U.S. Pat. No. 5,781,550) and by network address translation (NAT) (for example, as disclosed in U.S. Pat. No. 5,793,763). In many cases, these arrangements provide an adequate service to “inside” users and computers. However, the service provided it is not the same as a direct network connection. In the case of a proxy, normally only connection to a configurable range of well-known ports on remote server are allowed. This can allow a network administrator to restrict the types of service a user of the network can access, and the client machines are hidden from the outside servers.
• These known systems allow a network user to access outside services such as the Worldwide Web, Internet e-mail, and so forth, and so are selectively transparent to OSI application layer (Layer 7) protocols. However, they do not provide transparent connections to lower-level network protocols. In particular, at the OSI transport layer (Layer 4), at which the Transport Control Protocol (TCP) is commonly used and at the OSI network layer (Layer 3), at which the Internet Protocol (IP) is commonly used, these systems lack transparency. This can be a source of problems when the network is not operating normally, as, for example, when a TCP establishment fails.
• The known implementation of a transparent proxy gateway is not fully transparent, particularly in regard to the TCP/IP control packets. For example, consider the case that a client completes the establishment of the connection between itself and a proxy before the proxy attempts to establish a connection to the destination host. If the proxy connection fails, then the established connection to the host is disconnected. The client sees therefore an incorrect view of the network, which for service discovery by clients of server services is of material importance. In this example, the client perceives the service port as open, which is not the case.
• More recent developments in remote access have produced what are sometimes described as reverse proxies or gateways, where clients “outside” the network are authenticated and provided secure access to “inside” servers. However, the gateways are not transparent, requiring instead client-deployed software, which negotiates connections with the reverse proxy.
• An aim of this invention is to provide increased transparency, as compared with known systems, while maintaining security for the client systems. It is a particular aim of preferred embodiments of the invention to provide full TCP transparency at the client to permit automatic discovery of network resources.
• From a first aspect, this invention provides a network gateway through which a client can communicate with a remote host using transport control protocol (TCP), in which data transmission system for secure data exchange using transmission control protocol between a client and a server, comprising an agent and a broker connected to exchange data over an unsecured network link, in which: upon receipt of a control packet from the client, the broker forwards a modified control packet to the agent using a secure protocol; the broker inspects the modified control packet and forwards it to the server; upon receipt of a response packet from the server, the agent forwards the response packet to the broker using a secure protocol; and upon receipt of the response packet, the broker modifies the response packet and forwards it to the client; wherein in the case that the exchange of control packets indicates establishment of a TCP session, the broker and the agent establish a data channel between themselves to create a transparent TCP channel between the client and the server.
• Typically, the server is connected to the broker for exchange of data over a secured network—that is, an “inside” network. To protect the inside network, the secured network is typically connected to the unsecured network by one or more of a firewall, a proxy or a network address translation (NAT) device.
• The secure protocol may employ a transport layer security (TLS) protocol. The TLS protocol may be used to carry secure hypertext transport protocol (HTTPS). This has the advantage that port443, the port used for HTTPS, is typically left open on network firewalls and proxies. Alternatively, the HTTP CONNECT protocol may be used.
• The control packets handled by the system include TCP SYN packets and TCP ACK packets. The response packets include TCP SYN ACK and TCP RST ACK packets. These are the packets principally involved in setting up a TCP session. The control packet and the response packet may be Internet Control Message Protocol packets. Such packets are typically involved in automatic discovery of network resources.
• By suitable modification of the source and destination addresses within these packets, the data exchanged by the client and the server is similar to that which would be exchanged if the client and server were in direct communication.
• In order to control the services and servers that a user can access, the broker applies rules to determine whether or not the control packet is forwarded to the agent. The rules may depend upon one or more of the originator of the packet, the target address of the packet, and the target port number of the packet.
• Embodiments of the invention may be operative to service multiple virtual networks through a client access network. In such embodiments, the client access network is typically responsible for managing client access. The client access network may use one or both of standard AAA (Authorisation, Authentication and Accounting) and VPN services.
• From a second aspect, the invention provides a data transmission system for secure data exchange using transmission control protocol between a client and a server, comprising an agent and a broker connected to exchange data over an unsecured network link, in which: upon receipt of a control packet from the client, the broker forwards a modified control packet to the agent using a secure protocol; the broker inspects the modified control packet and forwards it to the server; upon receipt of a response packet from the server, the agent forwards the response packet to the broker using a secure protocol; and upon receipt of the response packet, the broker modifies the response packet and forwards it to the client; wherein in the case that the exchange of control packets indicates establishment of a TCP session, the broker and the agent establish a data channel between themselves to create a transparent TCP channel between the client and the server.
• An embodiment of the invention will now be described in detail, by way of example, with reference to the accompanying drawings, in which:
• FIG. 1 is a diagram that illustrates communication between a client and a server in a system embodying the invention;
• FIG. 2 is a block diagram of a broker being a component of a system embodying the invention; and
• FIG. 3 is a block diagram of an agent being a component of a system embodying the invention.
• With reference first toFIG. 1, aclient10 operating inside a secure network connects to an outsideremote server12 by way of abroker14 and anagent16. Thebroker14 andagent16 communicate over aninsecure network18, most usually including an Internet link.
• In the system ofFIG. 1, theclient10 is attempting to establish communication with theserver12. Thebroker14 serves as an intervening Internet gateway, which “spoofs” theserver12. Thebroker14 co-ordinates with theremote agent16, using a secure application layer protocol. Theagent16 connects to theserver12 and acts as a client to the broker, and so must follow the broker's protocols, the nature of which will become apparent from the following description. Data from theclient10 to theserver12 therefore flows in connections from theclient10 to thebroker14, where they are routed and securely transported to theagent16, where the data is carried in onward connections from theagent16 to theserver12. Theagents16 connect to thebroker14 using a secure transport, such as TLS, in a manner that facilitates the traversal of intervening firewalls, proxies and NAT devices. The preferred approach is to use port443, typically allowed for HTTPS traffic to secure Internet web servers.
• The method used by thebroker14 andagent16 to establish a transparent connection at the transport layer using TCP between theclient10 and theserver12 will now be described. In this embodiment (as is most typical) the transport layer protocol is the Transport Control Protocol (TCP).
• As is well-known to those skilled in networking technology, a TCP session between aclient10 and aserver12 is set up by a client sending a synchronisation SYN packet to theserver12 and waiting for an acknowledgement ACK packet in return from theserver12. When theclient10 receives the ACK packet, it sends an ACK packet in response to theserver12. The method by which thebroker14 of this embodiment operates works by capturing TCP SYN packets at the IP layer and holding them while routing and policy decisions are made. If an agent-route for the TCP connection is found, the connection is offered to thatagent16, which can then attempt to make the connection, by generating its own TCP SYN packet. Theagent16 will get in response from the server one of: TCP SYN ACK, meaning that the connection is established; TCP RST ACK, meaning that the connection is refused; or ICMP packet, meaning that the network, host or port is unreachable.
• If the connection succeeds, theagent16 establishes a data session for the connection traffic to be transferred between broker and agent, and the agent then informs thebroker14 to accept the TCP connection requested by theclient10. Thebroker14 then releases the original TCP SYN packet, where the system employs a conventional transparent proxy to terminate the TCP connection at the broker. All data from theclient10 is passed to theagent16 through the agent-established data session, where theagent16 passes the data to the other side of the proxy, towards the server. A similar process operates in the reverse path.
• If the connection fails, then theagent16 informs thebroker14 as to the type of failure. The broker consumes the original TCP SYN packet and generates a new IP packet to be sent to theclient10. Thenew packet10 is so constructed that it is a replica of the condition detected by the agent16: that is, TCP RST ACK, or an ICMP packet. Correct information relating to the connection failure is therefore returned to theclient10. In the case of a TCP RST ACK packet, the packet is addressed so that it appears to theclient10 to have originated from the destination host. In the case of an ICMP packet, the packet is addressed so that it appears to theclient10 to have originated from the gateway address of thebroker14 and carries the first 64 bytes of the original TCP SYN packet, as required by the ICMP protocol defined in RFC 792. In this manner, the brokered gateway is completely transparent to theclient10 at TCP level.
• The method used by thebroker14 andagent16 to establish a transparent connection at the network layer for Internet Control Message Protocol (ICMP) between theclient10 and theserver12 will now be described.
• ICMP is a mandatory requirement for gateway devices. The embodiment supports ICMP by consuming ICMP packets, interpreting them at the application layer, and if necessary creating an application layer protocol message exchange from thebroker14 to anagent16.
• For example, assume that theclient10 wishes to ping theserver12. It does this by sending an ICMP echo request message, with payload, from theclient10 to theserver12. The ICMP message is consumed by thebroker14, where it is parsed to determine its type. In this case, it will be identified as a PING request. The destination address (the server12) is looked up and a routing decision is made to generate a PING message to theagent16, over the secure transport layer protocol. Theagent16, on receipt of the PING message completes the request by generating an ICMP echo request message from itself to theserver12. On receipt of an ICMP echo reply, theagent16 responds with an “OK” response to the PING. At thebroker14, the application layer response to the PING message determines the ICMP response to the original ICMP request message: ICMP echo reply (server12 to client10); or ICMP unreachable (broker12 to client10). An ICMP echo request to the gateway address is handled by thebroker14, without the need to route to anagent16. Other ICMP messages are handled in a similar fashion, so making the embodiment ICMP transparent.
• The method used by thebroker14 andagent16 to establish a transparent connection at the network layer for the User Datagram Protocol (UDP) between theclient10 and theserver12 will now be described.
• UDP, the User Datagram Protocol, is a very simple protocol that allows a packet of data, known as a datagram, to be sent from one host to another. The embodiment supports UDP by consuming defragmented UDP packets at thebroker14, and routing appropriately toagents16.
• Assume that theclient10 sends a UDP datagram to theserver12. Thebroker14 consumes the datagram and relays the datagram to theagent16, from where the datagram is relayed to theserver12, having the address of theagent16 as its source address and an agent-selected source relay port. Datagram replies follow the reverse path from theserver12 to the agent-selected relay port on theagent16. Theagent16 receives the reply and transports the datagram to thebroker14 using the secure transport. The datagram reply is sent to theclient10 having as its source address that of theserver12.
• When a broker identifies which agent to which a datagram should be routed, it requests the establishment of a datagram relay. To establish a datagram relay, an agent first establishes a named datagram session between itself and the serving broker. The agent, if it accepts the relay request, responds with the name of the datagram session allocated to the datagram relay. The broker then sends the datagram, as a full IP packet, over the named datagram session, and stores the relay details (protocol=UDP, source address, source port, destination address, destination port). The agent sends the datagram to the final destination server using the established datagram relay.
• An established datagram relay supports replies in the return direction, where the agent receives the reply and sends the datagram, as a complete IP packet, over the named datagram session. The broker is responsible for packet fragmentation and raw transmission of the datagram to the host.
• The datagram session between broker and agent is a bi-direction secure pipe. The pipe is reliable. Datagram transports however should by definition be unreliable. Therefore, within the embodiment, strategies are employed on the datagram sessions to mimic unreliability. A flow-control protocol is implemented over the datagram session to provide end-to-end information on the number of outstanding bytes between the datagram session peers. If, for any reason, there is congestion in the datagram sessions, the peers will drop datagrams. If an underlying datagram session disconnects, pending datagrams are dropped. Other known traffic management strategies can be implemented at the broker and agent. For example, the embodiment may implement “ageing” of datagrams: that is, datagrams are dropped if the length of time they have been queued exceeds a configurable threshold.
• While the embodiment described above supports UDP, the principle of operation is easily extensible to any datagram-based service.
• The embodiment supports the ability for multiple virtual networks to be serviced by a brokered network gateway through a client access network. The client access network is responsible for managing client access, for example through a combination of standard AAA (Authorisation, Authentication and Accounting) services such as RADIUS, and VPN services such as IPSec or MPLS.
• Each virtual network consists of a number ofclients10,agents14 and a virtual gateway IP address. The broker restricts client access to within the client's virtual network. The client's identity is determined by IP source address (non-overlapping client-side IP address range). Each virtual network operates on an overlapped server-side IP address range as communication between clients and servers are within the context of the virtual network. Client trust relationships to a virtual network can be established dynamically through existing AAA services, using either static or dynamic IP address assignment.
• The structure of thebroker14 will now be described with reference toFIG. 2.
• Thebroker14 is currently implemented on a server computer running the Linux operating system.
• Agents16 establish and maintain a control session over a secure transport (TLS over TCP, in this embodiment) and a number of dynamic data sessions. Asecure transport module30 is responsible for providing a secure transport, interacting with theTCP module32 of the Linux kernel, which in turn receives and transmits IP packets via “IP INPUT” and “IP OUTPUT” respectively.
• On a serving broker, control sessions are maintained by acontrol module34. Data sessions are of two forms, STREAM sessions and DGRAM sessions. On an operational broker, STREAM sessions are maintained by aSTREAM manager module36 and DGRAM sessions are maintained by aDGRAM manager module38. Agents are responsible for the establishment of all sessions, therefore enabling traversal of intervening firewalls and proxies. Data sessions can be established on demand or pre-connected.
• All IP traffic passes through the kernel; inward IP traffic passes through anIP INPUT module40, where it is passed to an IP Filter (PREROUTING)module42. Using iptables, the Linux kernel packet filtering module, rules are established to queue packets to the application layer module calledPacket DeMux44.
• Themodule Packet DeMux44, based on information maintained by a servingbroker database module46 is used to determine how to process each packet passing though the broker, based on the IP protocol, the originating client, destination server and depending on protocol the source and destination protocol ports.
• ThePacket DeMux module44 also implements an application-layer, configurable packet filter (firewall) based on Access Control List (ACL) rules stored in the servingbroker database46. The present embodiment supports per-client defined ACLs and per-network ACLs.
• When the broker is handling TCP packets, only SYN packets are queued on the input of thePacket DeMux module44. If a TCP SYN packet represents a valid new TCP connection for a valid client (as defined by the contents of the serving broker database 46), a SYN message, with the details of the packet, are passed to thecontrol module34. Thecontrol module34 locates a valid agent control session, and offers the new TCP connection through the established control session. If no agent route is found, then thecontrol module34 generates a raw ICMP Unreachable packet for transmission to the originator of the TCP request through anIP output module48.
• If an agent's response to a new TCP connection is “OK”, then the assigned STREAM session is located in the servingbroker database44 and set to be in a “parked” state, saving the TCP connection details. A message is then sent to thePacket DeMux module44 to instruct it to respond to the original TCP SYN packet with an “ACCEPT”, allowing the TCP SYN packet to reach thekernel TCP module32. The IP Filter (PREROUTING)module42 module is configured to operate as a transparently proxy, using destination NAT, to a transparent proxy port, on which thestream manager module36 listens. Thestream manager module36 accepts the new TCP connection and asks the IP Filter (PREROUTING)42 module what the original destination address of the connection was. Based on the source and the destination addresses and ports, the parked STREAM session is located and unparked. The established proxy is sent to astream proxy50 to manage until the connection is finished.
• If the agent's response to a new TCP connection is “REFUSE”, then thecontrol module34 sends a message to thePacket DeMux module44 to refuse the TCP connection. In this case, the original TCP SYN packet is modified into a TCP RST packet and the source and destination are swapped to reflect the packet to the client. The original packet is then consumed (DROP) and the modified packet is sent to theIP OUTPUT module48.
• If the agent's response to a new TCP connection is “UNREACHABLE”, then thecontrol module34 sends a message to thePacket DeMux module44 to respond to the TCP SYN with an ICMP UNREACH packet. In this case the original TCP SYN packet is modified into an ICMP UNREACH packet and the source and destination are swapped to reflect the packet to the client. The first 64 bytes of the original TCP SYN packet are copied into the modified ICMP UNREACH packet according to the ICMP specification. The original packet is then consumed (DROP) and the modified packet is sent to theIP OUTPUT module48.
• Handling of ICMP will now be described. ICMP packets are queued by the IP Filter (PREROUTING)module42 to thePacket DeMux module44. In the case of an ICMP Echo Request, a “PING” message is sent to thecontrol module34, where a “PING” message is sent, through an established CONTROL session to a selected (routed) agent, based on information in the servingbroker database46. The original ICMP Echo Request is dropped.
• Depending on the agent's response to the PING, a new ICMP message is created and sent to the client as a raw IP packet through theIP OUTPUT module48.
• Handling of UDP will now be described. UDP packets are queued by the IP Filter (PREROUTING)module42 to thePacket DeMux module44. The “IP Filter (PREROUTING)module44 defragments the UDP packets. However, an alternative implementation could allow defragmentation to occur in thePacket DeMux module44. The information in the IP and UDP headers of the UDP datagram are used to select/lookup an established datagram association (DA) in the servingbroker database46. If a DA is found, then information in the DA determines either that the datagram should be discarded, or forwarded directly to an assignedDGRAM RELAY52. If no DA is found, then a new DA is created, and the datagram packet is forward to thecontrol module34. Thecontrol module34, using information in the servingbroker database46 determines which agent to request the establishment of a new datagram relay.
• If the agent responds with “OK”, then the DGRAM session assigned is located in the servingbroker database46 and the DA is bound aDGRAM RELAY52. The original packet is then forwarded to theDGRAM RELAY52.
• If the agent responds with “REFUSE”, then the datagram packet is discarded and the DA is marked “discard”. The “discard” condition is timer managed, causing the DA to be automatically destroyed after a configurable period of time.
• TheDGRAM RELAY52 is responsible for managing traffic over DGRAM sessions. EachDGRAM RELAY52 implements flow-control, DA maintenance, and traffic management strategies. Any IP datagram can be transported over a DGRAM session. Datagrams in the reverse path (agent to client) are received by aDGRAM RELAY52 and transmitted, after fragmentation, via theIP OUTPUT module48.
• Virtual networks are assigned to one of a number of deployed serving brokers. Agents can use a registration service to discover the serving broker assigned as a gateway to the agent's virtual network. In this way an embodiment of the invention can be scaled to support a large number of clients, agents and virtual networks. In the preferred embodiment, the registration service is implemented using secure web-service (using HTTPS methods).
• The agent can be implemented on any platform that provides a TCP/IP network stack, for example, a computer running Windows®, Linux®, Unix®, Apple® Operating System or a Java® virtual machine. The generic structure of an agent is shown in theFIG. 3. The platform must provide interfaces to TCP/IP. InFIG. 3,TCP interface60,UDP interface62 andICMP interface64 of the native TCP/IP stack are shown separately for clarity.
• All traffic between theagent16 and servingbroker14 is established as outbound (agent to serving broker) secure connections using theSECURE TRANSPORT module66, which provides TLS over TCP in the preferred embodiment. Since agents are responsible for traversing intervening proxies between theagent16 and servingbroker14, an agent must include proxy connection functionality, the functionality for which can be included in theSECURE TRANSPORT module66, or as an alternative be included in a separate proxy module. An agent should implement HTTP CONNECT proxy functionality as a minimum.
• On anagent16, control sessions are maintained by aCONTROL module68. Data sessions are of two forms, STREAM sessions, managed by aSTREAM MANAGER module70, and DGARM sessions, managed by aDGRAM MANAGER72.
• TheCONTROL module68 of theagent16 establishes and maintains a single secure control session via theSECURE TRANSPORT module66. TheCONTROL module68 listens for control messages from thebroker14 over the control session. TheCONTROL module68 should be capable of handling multiple serving broker messages concurrently.
• If a servingbroker14 sends a PING message, then theCONTROL module68 will initiate an ICMP ping from theagent16 to the destination through the TCP/IP ICMP interface60. Someone proficient in the technical field will realise that an ICMP ping is typically only allowed by processes with elevated or administrator rights. As a result, anagent16 must typically run in a context with elevated or administrator rights. The response to the ICMP will be related back to the servingbroker14 in a response message.
• If a servingbroker14 sends a TCP CONNECT message to theagent16, then theCONTROL module68 requests a TCP connection by way of theSTREAM manager module70. TheSTREAM MANAGER module70 must first attempt to connect to the specified destination. If the connection succeeds, then theSTREAM MANAGER module70 will connect a STREAM session to the servingbroker14 and notify theCONTROL module68 of the success and the STREAM session that is responsible for the TCP connection. TheSTREAM MANAGER module70 then creates aSTREAM PROXY74 to shunt data back-and-forth between the STREAM session andlocal TCP connection78. If however the TCP connection fails, then theSTREAM MANAGER module70 notifies theCONTROL module68, which sends the appropriate error response message. Alternatively, anagent16STREAM MANAGER module70 can pre-connect STREAM sessions to the servingbroker16 and allocate pre-connected STREAM sessions when needed, in this manner TCP connection establishment times can be improved.
• If a servingbroker14 sends a UDP CONNECT message to theagent16 then theCONTROL module68 requests a UDP Datagram Association (DA) via theDGRAM manager72. TheDGRAM MANAGER72 assigns the DA to aDGRAM RELAY76. If theDGRAM RELAY76 does not already have a DGRAM session to the servingbroker14, then it is established now. ADGRAM RELAY76 is capable of managing multiple DAs. TheDGRAM MANAGER72 sends a response message to the servingbroker14 identifying the DGRAM session to which to bind the DA of the servingbroker14.
• TheDGRAM RELAY76 of theagent16 preferably implements a timer function to monitor DAs that are alive and unbind DAs that are no longer being used. When a DA is unbound, theDGRAM RELAY76 of theagent16 sends theDGRAM RELAY52 of the serving broker14 a message to that effect. After the DA has been unbound, any traffic for the unbound DA is discarded.
• In practice, most UDP protocols are one-shot command-response style protocols. With this in mind, an agent could implement a very short idle time-out initially, for example 30 seconds, and then if there are multiple datagrams exchanged, extend the idle timeout. For example, after two response datagrams, theagent16 may extend the idle timeout for that DA to 15 minutes.
• Bothbrokers16 andagents14 are, in this embodiment, identified and mutually authenticated using X.509 digital certificates. Routing in the system may be based on a destination address or network service.

Claims (30)

1. A data transmission system for secure data exchange using transmission control protocol between a client and a server, the system comprising an agent and a broker connected to exchange data over an unsecured network link, in which:

upon receipt of a TCP control packet from the client over a secure network, the broker is operative to forward a modified TCP control packet to the agent using a secure protocol;

the agent is operative to inspect a modified control packet received from the broker and to forward it to the server;

upon receipt of a TCP response packet from the server, the agent is operative to forward the response packet to the broker using a secure protocol; and

upon receipt of a TCP response packet from the agent, the broker is operative to modify the response packet and to forward it to the client;

wherein in the case that an exchange of TCP control packets indicates establishment of a TCP session, the broker and the agent are operative to establish a data channel between themselves to create a transparent TCP channel between the client and the server.

2. A data transmission system according toclaim 1 in which the client is connected to the broker for exchange of data over a secured network.

3. A data transmission system according toclaim 2 in which the secured network is connected to the unsecured network by one or more of a firewall, a proxy or a network address translation (NAT) device.

4. A data transmission system according toclaim 1 in which the secure protocol is a transport layer security (TLS) protocol having a connection made over the TCP port443.

5. (canceled)

6. A data transmission system according toclaim 4 in which the TLS connection is made over a local proxy.

7. A data transmission system according toclaim 6 in which the local proxy uses the HTTP CONNECT protocol.

8. A data transmission system according toclaim 1 in which the control packet is a TCP SYN packet or a TCP ACK packet and the response packet is a TCP SYN ACK or a TCP RST ACK packet.

9. (canceled)

10. A data transmission system according toclaim 1 in which the control packet and the response packet are Internet control message protocol packets.

11. A data transmission system according toclaim 1 in which the broker is operative to apply rules to determine whether or not a TCP control packet is forwarded to the agent.

12. A data transmission system according toclaim 11 in which the rules specify whether a TCP control packet should be forwarded based upon one or more of the originator of the packet, the target address of the packet, and the target port number of the packet.

13. A data transmission system according toclaim 1 operative to service multiple virtual networks through a client access network that is responsible for managing client access.

14. (canceled)

15. A data transmission system according toclaim 13 in which the client access network uses one or both of standard AAA (Authorisation, Authentication and Accounting) and VPN services.

16. A data transmission method for secure data exchange using transmission control protocol between a client and a server, using a broker and an agent connected to exchange data over an unsecured network link, in which:

upon receipt of a TCP control packet from the client, the broker forwards a modified control packet to the agent using a secure protocol;

the agent inspects the modified TCP control packet and forwards it to the server;

upon receipt of a TCP response packet from the server, the agent forwards the TCP response packet to the broker using a secure protocol; and

upon receipt of the TCP response packet, the broker modifies the TCP response packet and forwards it to the client;

wherein in the case that the exchange of TCP control packets indicates establishment of a TCP session, the agent and the broker establish a data channel between themselves to create a transparent TCP channel between the client and the server.

17. A data transmission method according toclaim 16 in which the client is connected to the broker for exchange of data over a secured network.

18. A data transmission method according toclaim 17 in which the secured network is connected to the unsecured network by one or more of a firewall, a proxy or a network address translation (NAT) device.

19. A data transmission method according toclaim 16 in which the secure protocol is a transport layer security (TLS) protocol having a connection made over the TCP port443.

20. (canceled)

21. A data transmission method according toclaim 19 in which the TLS connection is made over a local proxy.

22. A data transmission method according toclaim 21 in which the local proxy uses the HTTP CONNECT protocol.

23. A data transmission method according toclaim 16 in which the TCP control packet is a TCP SYN packet or a TCP ACK packet and the TCP response packet is a TCP SYN ACK or a TCP RST ACK packet.

24. (canceled)

25. A data transmission method according toclaim 16 in which the TCP control packet and the response packet are Internet control message protocol packets.

26. A data transmission method according toclaim 16 in which the broker applies rules to determine whether or not the TCP control packet is forwarded to the agent.

27. A data transmission method according toclaim 26 in which the rules specify whether a the TCP control packet should be forwarded based upon one or more of the originator of the packet, the target address of the packet, and the target port number of the packet.

28. A data transmission method according toclaim 16 operative to service multiple virtual networks through a client access network.

29. A data transmission method according toclaim 28 in which the client access network is responsible for managing client access.

30. A data transmission method according toclaim 29 in which the client access network uses one or both of standard AAA (Authorisation, Authentication and Accounting) and VPN (virtual private networking) services.

Images