Firewall document
Ivan R. Judson
judson at mcs.anl.gov
Mon Dec 8 20:43:24 CST 2003
Sorry, the other point I addressed (silently) was:
> the beacon server doesn't use odd ports on its multicast?
The new beacon does, since it's using RTP to send data. So it has the
standard RTP/RTCP pair, plus the TCP back channel.
--Ivan
> might be interesting to bounce this off caren or bill.
>
>
>
> >
> > * I think there should be two tables: one for "minimal ports
> > necessary to make things work", and one for optional ports.
> >
> >
> > In the table under the text "These services make no /wide area/
> > network
> > connections, but do require any firewall on the local machine be
> > configured appropriately"
> >
> > * "Services" should say that they use dynamically
> assigned ports.
> >
> >
> >
> >
> >
> >
> >
> > Ivan R. Judson wrote:
> >
> > >Here's what I have; if there's nothing more to add, this should be
> > >sufficient for the APS folks.
> > >
> > >I'd like Bob and Tom to read it over and verify there's nothing
> > >missing. The APS folks are waiting for this document and
> I'd like it
> > >out the door today.
> > >
> > >--Ivan
> > >
> > >
> > >
> > >
> --------------------------------------------------------------------
> > > ----
> > >
> > >
> > > Firewall Configuration Information for AGTk 2.0
> > >
> > > Author: Ivan R. Judson
> > > Status: Draft
> > > Contact: ag-info at mcs.anl.gov <mailto:ag-info at mcs.anl.gov>
> > > Copyright: University of Chicago, 2003
> > > Date: 04-12-2003
> > >
> > >
> > > Abstract
> > >
> > > This document specifies what firewall configuration
> options need to
> > > be
> > > considered to use the Access Grid in a firewalled network
> environment.
> > > Specific firewall solutions are not addressed in this document.
> > >
> > >
> > > Copyright
> > >
> > > This document falls under the AGTkPL.
> > >
> > >
> > > Discussion
> > >
> > > The Access Grid Toolkit provides distributed collaboration system
> > > with
> > > parts that communicate over both the local area and wide
> area network.
> > > In order to function properly the various parts of the
> system need to
> > > be able to initiate and use network connections in
> various directions
> > > (both incoming and outgoing). When the term connection is
> used it is
> > > meant to mean a GSI Secured TCP Socket.
> > >
> > > For the streaming media, which is carried via RTP, two ports are
> > > required. The first (even numbered) port is the data
> port, the next
> > > odd port (first port + 1) is used for RTP Control data.
> > >
> > > In the current version of the toolkit, the network interfaces are
> > > served via SOAP. These interfaces are exposed on:
> > >
> > > Service Default Port(s)
> > > Services dynamically assigned
> > > Service Manager 11000
> > > Node Service 12000 and 1 dynamically assigned
> > > Venue Client ^* <#id3> /optional/ 1 dynamically assigned
> > > Venue Server 8000, 8002, 8004, 8006
> > > Bridge Server Each stream is statically configured or
> dynamically
> > > assigned
> > > Beacon Server (233.4.200.21, 10002/10004),
> beacon.dast.nlanr.net:10004
> > >
> > > The following services need special configuration to operate
> > > correctly.
> > >
> > > Service Default Port(s)
> > > Venue Client /optional/ 1 dynamically assigned
> > > Venue Server 8000, 8002, 8004, 8006
> > > Bridge Server Each stream is statically configured or
> dynamically
> > > assigned
> > > Beacon Server (233.4.200.21, 10002/10004),
> beacon.dast.nlanr.net:10004
> > >
> > > These services make no /wide area/ network connections, but do
> > > require
> > > any firewall on the local machine be configured
> appropriately ^+ <#id4>.
> > >
> > > Service Default Port(s)
> > > Services none
> > > Service Manager 11000
> > > Node Service 12000 and 1 dynamically assigned
> > >
> > > [*] <#id1> Disabling incoming connections to the
> Venue Client is
> > > possible and doesn't significantly hinder collaboration. Personal
> > > data
> > > sharing is not possible if incoming connections are not allowed.
> > >
> > > [+] <#id2> Host based firewalls like Microsofts XP
> Firewall will
> > > interfere not only with local area connectivity but it will also
> > > stop
> > > multicast from working properly. Currently, the best
> advice is to turn
> > > the firewall off.
> > >
> > >
> > > Service Details
> > >
> > > *
> > >
> > > Venue Server (defaults to port 8000, 8002, 8004, 8006)
> > >
> > > The venue server listens for incoming connections
> on four ports,
> > > which are configurable. These ports are for
> incoming connections
> > > only, there are no outbound connections from the
> venue server.
> > >
> > > *
> > >
> > > Bridge Server (multiple ports used)
> > >
> > > The bridge server can use either statically
> assigned ports for
> > > the media bridges it starts, or it can dynamically
> assign the
> > > ports for media bridges.
> > >
> > > *
> > >
> > > Beacon Server (one group, one outgoing connection)
> > >
> > > The beacon server uses one multicast group and one outbound
> > > connection to a reporting server. These are both
> configurable,
> > > but the defaults are the correct configuration to
> be a part of
> > > the Access Grid Multicast Beacon infrastructure.
> > >
> > >
> > > Multicast
> > >
> > > In order for audio and video to flow among users
> multicast needs to
> > > be
> > > able to be allowed through the firewall. There is
> currently no set of
> > > static configurations that are used for multicast
> (although they could
> > > be used, if needed), so ideally the firewall would allow
> data from any
> > > group /that is subscribed to from inside/ the firewall to
> come through
> > > the firewall from the outside.
> > >
> > > The media tools we use have two different behaviors for how they
> > > send
> > > data. For audio the source port for the data is identical to the
> > > destination port for the data. For video, the source port
> for the data
> > > is selected randomly.
> > >
> > >
> > > Example of a Secured Static Environment
> > >
> > > This is an example of a small installation configured for
> a paranoid
> > > network configuration. The configuration has only three
> venues to keep
> > > the example simple.
> > >
> > > To keep this example even more simple, the bridge, data and venue
> > > server are all running on the same machine, /host.domain/.
> > >
> > >
> > > Meeting Room Venue
> > >
> > > Media Multicast Groups Bridge Ports
> > > static video 224.1.2.3/[1234/1235] 9000/9001
> > > static audio 224.1.2.3/[1236/1237] 9002/9003
> > >
> > >
> > > Laboratory #1 Venue
> > >
> > > Media Multicast Groups Bridge Ports
> > > static video 224.1.2.4/[1234/1235] 9004/9005
> > > static audio 224.1.2.4/[1236/1237] 9006/9007
> > >
> > >
> > > Laboratory #2 Venue
> > >
> > > Media Multicast Groups Bridge Ports
> > > static video 224.1.2.5/[1234/1235] 9008/9009
> > > static audio 224.1.2.5/[1236/1237] 9010/9011
> > >
> > >
> > > Venue Server
> > >
> > > * running on host.domain
> > > * ports: 8000, 8002, 8004, 8006
> > >
> > > *If the firewall is configured to allow multicast through*, then
> > >
> > >
> > > Bridge Server
> > >
> > > * running on host.domain
> > > * ports: 9000-9011
> > >
> > > *otherwise*,
> > >
> > >
> > > Bridge Server
> > >
> > > * running on some host with working multicast
> > > * ports: 9000-9011
> > >
> > >
> > > Beacon Service
> > >
> > > * running on host.domain
> > > * Multicast Group: (233.4.200.21, 10002/10004)
> > > * Outbound TCP: beacon.dast.nlanr.net:10004
> > >
> > >
> > > Summary Configuration
> > >
> > > Incoming *to host.domain* from the rest of the world:
> > >
> > > * /Ports:/ 8000, 8002, 8004, 8006
> > > * If Bridge Server is *inside the firewall*: 9000-9011
> > >
> > > Outgoing Conduits *from host.domain* to the rest of the world:
> > >
> > > * beacon.dast.nlanr.net:10004
> > > * If Bridge Server is *outside the firewall*:
> > > bridgehost.domain:9000-9011
> > >
> > > Multicast Group Conduits:
> > >
> > > All hosts on the local network should be able to send and receive
> > > traffic via these multicast groups.
> > >
> > > * (224.1.2.3,1234)
> > > * (224.1.2.3,1235)
> > > * (224.1.2.3,1236)
> > > * (224.1.2.3,1237)
> > > * (224.1.2.4,1234)
> > > * (224.1.2.4,1235)
> > > * (224.1.2.4,1236)
> > > * (224.1.2.4,1237)
> > > * (224.1.2.5,1234)
> > > * (224.1.2.5,1235)
> > > * (224.1.2.5,1236)
> > > * (224.1.2.5,1237)
> > > * (233.4.200.21, 10002)
> > > * (233.4.200.21, 10004)
> > >
> > >
> > > Conclusion
> > >
> > > This document describes the firewall requirements for the AGTk 2.0
> > > software, for both clients and services. For more
> information please see:
> > >
> > > * The AGTk Home Page
> <http://www.mcs.anl.gov/fl/research/accessgrid> >
> > > * The
> Access Grid Project Home Page
> <http://www.accessgrid.org/>
> > > * The Access Grid Documentation Project Home Page
> > > <http://www.accessgrid.org/agdp>
> > >
> >
>
More information about the ag-dev
mailing list