On this page... (hide)
The Grid offers significant opportunities for performing wide area distributed computing, with heavy reliance on internetworking across multiple institutions, usually across the Internet. However, the Internet becoming largely unsafe has made firewalls necessary and, for years now, typical. Unfortunately, this often diminishes the level of collaboration that is possible. There is a common conflict between firewalls and Grid middleware or applications. Must we customize firewalls to allow Grid transactions across, or customize the Grid with the ability to deal with firewalls?
These are not necessarily the only options.
Grid applications in particular need not be affected. Even Grid middleware should be shielded from such problems, primarily because the environment in one case may wildly vary from that in another. REMUS provides an architectural solution that unobtrusively facilitates firewall traversal with the following principles:
- Security policies must not be compromised. This means that firewalls need not be reprogrammed by hand, and traversal techniques will only use means that are authorized. For example, SSH is a typically authorized service for authorized personnel. The figure above shows a red oval indicating perhaps the SSH port (22/tcp) as the only open port on the network to the right. This means that SSH traffic is allowed by the firewall, and only users with SSH access will thus be able to use that mechanism. A working solution is therefore to use SSH to create the tunnel (the large light-blue arrow across sites) that facilitates Grid transactions (in thinner blue arrows).
- Grid middleware and applications should not be reprogrammed as much as possible. The figure above shows rerouters that intercept TCP connections from components and diverts them accordingly to use the link between rerouters. A practical implementation of the rerouters is that of a SOCKS wrapper at the initiating side and a SOCKS proxy on the other side.
- An auxiliary principle in building REMUS is the use of standard traversal methods using mature and readily available protocols such as SSH and SOCKS.
The environment that requires such a solution is assumed to have a firewall that is heavily restrictive. The trade-off between connectivity and performance is thus assumed to be inevitable. In our studies, performance degradation comes up to about 25%.
The originating paper for this work is:
Tan, J, Abramson, D. and Enticott, C. “Bridging Organizational Network Boundaries on the Grid”, IEEE Grid 2005, Seattle, Nov 2005.
The research crosses over to some other areas of Message Lab research such as handling of Legacy applications (GriddLes project). See
Kommineni, J., Abramson, D. and Tan, J. “Communication over a Secured Heterogeneous Grid with the GriddLeS runtime environment”, 2nd IEEE International Conference on e-Science and Grid Computing. Dec. 4- 6, 2006, Amsterdam, Netherlands.
- An authorized channel must open.
- We can tunnel through whichever channels exist.
- We can use off-the-shelf means.
- We should be able to hide the complexity.
- Reprogramming of grid applications or firewalls is avoided
We currently have a prototypical solution that involves the use of SOCKS wrappers and SOCKS proxies via openssh. Grid applications are wrapped inside SOCKS wrappers which reroute Grid transactions in both directions as long as all participating Grid components are wrapped properly. We use the openssh implementation of SOCKS proxies, known as dynamic port forwarding, to enable the proxy connections.
Further development is needed to deliver a Remus solution conveniently. A smart deployment package should be able to analyze the environment and suggest configurations as well as to set paths to binaries that Remus needs. The configuration should reside in a simple config file that can also be customized by users. Finally, rerouter scripts should be developed that would erect the tunnels and proxy servers using a simple command-line interface.
Remus Presentation 2005 (.ppt)