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.
