From: "Pete Cordell" <pete(_at_)tech-know-ware(_dot_)com>
To: <midcom(_at_)ietf(_dot_)org>, "Rohan Mahy" <rohan(_at_)cisco(_dot_)com>
Subject: Re: [midcom] client vs. proxy traversal
Date: Mon, 26 Nov 2001 22:21:42 -0000
X-Mailer: Microsoft Outlook Express 5.00.2314.1300
Sender: midcom-admin(_at_)ietf(_dot_)org
X-Mailman-Version: 1.0
List-Id: <midcom.ietf.org>
X-BeenThere: midcom(_at_)ietf(_dot_)org
Rohan,
comments in-line...
From: Rohan Mahy <rohan(_at_)cisco(_dot_)com>
>
> As Melinda stated, our focus for pre-midcom is NAT traversal, not firewall
> traversal. TURN takes advantantage of the "symmetric UDP" behavior of
NATs
> to allow one end to talk to another without *control* of an intermediary.
>
Surely the TURN server is an intermediary which is being controlled by the
TURN protocol!
And I still think we're wasting our time if we don't consider firewalls as
well!
> The fact that many firewalls also exhibit "symmetric UDP" behavior is just
> an added bonus.
>
> >What it does mean though is
> >that the firewall is able to allow packets to/from the application proxy
> >to pass through that it might not otherwise allow from clients.
>
> If the firewall administrator is willing to do this, it shouldn't be hard
> to allow symmetric UDP with a timeout.
>
That is the crux of the matter - what the administrator is prepared to
allow. There is a wide range of firewall policy around the place. Some
will not even allow web browsing, restrict it to certain times, or insist it
goes via a particular proxy. This is all part of the power that
administrators wield! A solution that does not allow an administrator to
wield their power over other protocols will not be as successul as one that
does.
Or put another way, the IETF should minimise the impact on the policies an
administrator can implement on their firewall when endorsing a solution in
this space.
It is therefore important to consider outbound as well as inbound
connections.
> >It can do this in
> >the knowledge that the Application Proxy is forwarding only one
> >particular protocol, and the Application Proxy can also do all sorts of
> >other
> >stateful inspection exercises in order to check that things are as they
> >should
> >be.
>
> I think the market will decide if they want this functionality vs. the
> complexity that it adds. Probably not a single market here.
>
I have a different take on the complexity issue which I shall address
elsewhere (since some Ben Campbell has kindly started up a suitable thread).
> >It's much like adding an ALG to the firewall and NAT, except that in
this
> >case it is located external to them. As such it complements the
firewall /
> >NAT functionality, but does not require the firewall / NAT itself to be
> >upgraded. Therefore it can be quickly deployed, and is an ideal
approach
> >for a pre-midcom solution.
> >
> >On the other hand, if you deploy TURN or FANTOM on the clients, the
> >administrator has no way of knowing what they will be used for. For a
> >number of environments this will not be acceptable, and won't lead to
the
> >deployment of desktop VoIP.
>
> I disagree. This is not new support that has to be added in most
> cases. Many firewalls are *already configured* to allow symmetric
> UDP. Users behind these firewalls take advantage of streaming content and
> other UDP applications today. Apparently this is OK with the
> administrators. I believe a TURN-style solution for peer-to-peer RTP
would
> be acceptable to them as well.
>
We might have to agree to disagree on that!!!
> thanks,
> -rohan
>
Pete.
=============================================
Pete Cordell
Tech-Know-Ware
pete(_at_)tech-know-ware(_dot_)com
+44 1473 635863
=============================================
_______________________________________________
midcom mailing list
midcom(_at_)ietf(_dot_)org
http://www1.ietf.org/mailman/listinfo/midcom
Michael W. Condry
Director, Network Edge Technology