All of these points are well made. I certainly subscribe to the "one port, one service" line of thought, but the underlying problem remains, that to actually deploy AG in most locations today, one has to deal with network administrators and the policies they are required to implement (and it's pointless to villify either), and we can not even hand these administrators a simple printed list of ports to open.
I made a stab at this some weeks back, starting with the document created by Javier Gomez Alonso of Manchester (see http://www.accessgrid.org/agdp/guide/ports.html). David E. Bernholdt of Oak Ridge National Laboratory then recast my ASCII table in the form of a Excel spreadsheet, which I attach, as I can not find my ASCII original now. There are glaring holes for rat anc vic, among others. We really, really, *really* need to create such a list, minimizing the number of ports as far as is possible, consistent with clean engineering and adequate functionality. Or, better yet, have three such lists with varying numbers of ports that are required to be opened, based on the level of functionality required. In any event, the list would have to be kept in synchrony with the development of AG. Having such a list is going to be an important as having AG software, if we want the community to grow. Best Regards, Rick Rodgers > From: Colin Perkins <c...@csperkins.org> > Subject: Re: [AG-TECH] Access Grid 3.0 beta1 available ! > Date: Tue, 31 Jan 2006 16:51:31 +0000 > To: "Ivan R.Judson" <jud...@mcs.anl.gov> > > On 31 Jan 2006, at 16:28, Ivan R. Judson wrote: > > I think the interesting question from a user perspective is: > > > > Would you rather open one port and we tunnel all traffic through it > > (and > > you'll never know about all the types or kinds of traffic) or make > > it easy > > to have one tunnel per type of data/connection that's easier to > > open/close > > and audit based on actual use? > > > > I *think* the future is in the latter, because you can easily see a > > manageable system being built that allows programmatic (with > > authentication > > obviously) access for dynamically opening and closing tunnels based on > > specific "contracts" about usage, data, src/destination, duration, > > etc. > > And, if you have well defined (narrow) port ranges for each media, > makes it easy to firewall off specific media, or to assign varying > QoS for each media. > > > I can't see any good way to justify "opaque aggregate tunnels" that > > hide the > > fact a break-in occurred in a mess of other data. > > Indeed. > > Colin -------------------------------------------------------------------------------- R. P. C. Rodgers, M.D. * rodg...@nlm.nih.gov * (301)435-3267 (voice, fax) OHPCC, LHNCBC, U.S. National Library of Medicine, NIH Bldg 38, Rm. B1N-30F2, 8600 Rockville Pike, Bethesda MD 20894 USA http://lhc.nlm.nih.gov/staff/rodgers/rodgers.html
ag-port-usage.xls
Description: ag-port-usage.xls
