Subject: [midcom] client vs. proxy traversal

From: Rohan Mahy <[email-masked]>
Date: Mon, 26 Nov 2001 09:54:56 -0800

Hi,

I have a few comments inline...

 >    * To: "Bob Penfield" <[email-masked]>, <[email-masked]>
 >    * Subject: [midcom] Client Vs. Proxy Traversal
 >    * From: "Pete Cordell" <[email-masked]>
 >    * Date: Thu, 22 Nov 2001 16:08:55 -0000
 >    * List-Id: <midcom.ietf.org>
 >    * Sender: [email-masked]
 >
 >Bob,
 >
 >This thread brings out something else...
 >
 >Steve Davies wrote:
 >>> In this case the FANTOM client would have to handle
 >>> multiple simultaneous call setups and cleardowns. We judged a single
 >>> persistant tunnel for all call control from the FANTOM client to FANTOM
 >>> server was the most efficient use of resources.
 >
 >To which Bob replied:
 >> Isn't this really the same as putting a proxy in the exterprise and having
 >> it connect to the proxy in the public network over TCP? Why is FANTOM
 >> better than adding a proxy? If FANTOM is present in the terminal, you have
 >> a tunnel for every terminal. If you have a FANTOM client, then all the
 >terminals
 >> need to send signalling to the FANTOM client. Doesn't that make it a
 >proxy?
 >
 >
 >By mentioning a proxy you raise an interesting issue.  In the enterprise
 >case, FANTOM sits well where an ordinary proxy might sit, that is within the
 >boundary of the firewall installation (hence the name Application Proxy).
 >In this respect it is augmenting the functionality of the firewall
 >installation.
 >
 >This is not a pleasant thought if you only want end-to-end working.
 >However, the firewall has already broken that.

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.

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.

 >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.

 >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.

thanks,
-rohan

 >Pete.
 >
 >=============================================
 >Pete Cordell
 >Tech-Know-Ware
 >[email-masked]
 >+44 1473 635863
 >=============================================

_______________________________________________
midcom mailing list
[email-masked]
http://www1.ietf.org/mailman/listinfo/midcom

---

From: "Pete Cordell" <[email-masked]>
Date: Mon, 26 Nov 2001 22:21:42 -0000

Rohan,

comments in-line...

From: Rohan Mahy <[email-masked]>
> 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!

> 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.

> 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).

> be acceptable to them as well.

We might have to agree to disagree on that!!!

Pete.

---

From: Rohan Mahy <[email-masked]>
Date: Mon, 26 Nov 2001 16:14:31 -0800

>Surely the TURN server is an intermediary which is being controlled by the

My point is that the end systems are in control.  The TURN server does not 
control the endpoints.  Perhaps I should rephrase my previous sentence.

"... to allow one end to talk to another without control *BY* an intermediary."

>And I still think we're wasting our time if we don't consider firewalls as

Feel free to take this issue up with the Area Directors then.

>wield their power over other protocols will not be as successul as one that

IMO the level of complexity and control that you are describing, while a 
siutable candidate for a midcom-style protocol, is not the goal of the 
pre-midcom protocol.

thanks,
-rohan