[AG-TECH] Access Grid 3.0 beta1 available !

[Piers O'Hanlon]

Frank Sweetser wrote:

>On Mon, Jan 30, 2006 at 06:21:02PM +0000, Piers O'Hanlon wrote:
>  
>
>>- Secondly the firewall interaction then depends on which platform AG
>>    
>>
>
>Actually, that only covers the firewall running on the local machine.  Far,
>*far* more problematic are external firewalls running on routers, typically in
>a completely different sphere of control than the machine running AG.  These
>tend to be run by people who respond to a request of "Could you please open up
>these 5,000 ports to all addresses?" with derisive laughter.  Dealing with
>these external firewalls becomes much easier when the AG is restricted to a
>small, tightly defined set of ports.
>
>  
>
Sure the external Firewall is another decoupled issue - Most other
applications don't talk to the external firewall so AG probably wouldn't
be expected to do so either. However other applications usually have
better defined network requirements so they're typically easier to
firewall, though such systems like H.323 or SIP can also cause problems
with external firewall.

There are a few approaches one could take;

I guess firstly the narrowing of the application requirements would be a
good start though it may possibly to impare application performance -
under this approach one could attempt to minise the port range usage at
a server, though this doesn't help if clients are connecting to outside
servers (which maight employ alternative port ranges). This area might
be mildly alleviated by more tightly controlling source port allocations
within the media tools (noting Andrew's comments), though unidirection
firewall rules are usually sufficient to control such traffic -  seeing
as alot of other application  firewalling is done that way (e.g. A
firewall rules for SSH may allow incoming traffic to certain machines on
destination port 22 regardless of source port).

As Tom suggested another approach could be to use STUN, ICE or whatever
to traverse the firewall - probably ok for unicast, but not really
suited to multicast.

Another simpler approach would be to use unicast tunnelling - i.e. with
(smart) bridges which operate on predefined port ranges. There are a few
such bridges around such as the standard quickbridge, rcBridge, RUM
(cesnet) etc.

We have talked about application level multicast (with the SUMOVER
project) as regards deployment directly within the tools (actually in
common lib), which could provide benefits - as it is more efficient than
bridging, yet more deployable than multicast, and probably easier to
firewall. We will be looking into this option. There are a quite number
of schemes out there - including Orta (glasgow), End System Multicast,
ALMI (PSU), Aspen (Berkeley) etc...

Another possible approach is active communication with the firewall -
though I can't see this being used in large setups where network admins
wouldn't want it. But for smaller deployments protocols such as UPnP can
be used to control certain firewalls/port-forwarding (e.g. as used now
by AOL messenger etc). Or some other thing like Realm Specific IP.

There are some firewalls out there that can parse certain protocols
(.e.g. H.323 and SIP) and build appropriate firewall rules, however I
doubt there's anything out there with AG support.

THere's always Skype of course ;) - But then we'd be limited to 5 way
audio - and 2 way video....

Piers.