AG Port issues (was Re: [AG-TECH] Access Grid 3.0 beta1 available !)

Tue Jan 31 12:58:52 CST 2006

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 <csp at 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" <judson at 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. * rodgers at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/octet-stream
Size: 16384 bytes
Desc: ag-port-usage.xls
URL: <http://lists.mcs.anl.gov/pipermail/ag-tech/attachments/20060131/1b58fa68/attachment.obj>