Subject: RE: [midcom] pre-midcom candidates

From: "Christian Huitema" <[email-masked]>
Date: Thu, 1 Nov 2001 08:16:20 -0800

Barry,

This is exactly the same firewall requirement as STUN.

-----Original Message-----
From: Barry Scott [mailto:[email-masked]] 
Sent: Thursday, November 01, 2001 6:59 AM
To: 'James Ho'; [email-masked]
Subject: RE: [midcom] pre-midcom candidates

> The policy we need turns out to be the default for many 
> enterprises already. 
> Typical behavour is to prevent UDP from the outside 
> to get inside. But once a UDP packet from the inside 
> is sent to the outside the firewall will pinhole itself 
> to allow return traffic. After a period of inactivity 
> the firewall will close the pinhole, for example after 
> 45 seconds. 

Barry,

This is exactly the same requirement as STUN, with the difference that
STUN does not require an infrastructure in the middle of the network.

-- Christian Huitema

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

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 2 Nov 2001 02:30:35 -0500

> From: James Ho [mailto:[email-masked]]
> Sent: Thursday, November 01, 2001 12:25 PM
> To: [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [midcom] pre-midcom candidates
> 
> 
> Why could'nt tunnel-mode IPsec be used beween an IPsec end-point in
> the enterprise and another in the SP network to tunnel H.323/SIP
> traffic across firewalls? The auth/integrity checking within ESP
> with null encryption should allow for a secure tunnel improving
> enterprise IT confidence. Plus its a standard approach vs. the
> "proprietary' approaches proposed. To address NAT issues, the
> internal IPsec end-point could have a public IP address.

Indeed, it could. In fact, any number of alternate VPN solutions could be
used. I actually get through my nat at home by using a Microsoft VPN to my
corporate network where our proxies and stuff run. The Davies approach is
another form of vpn, if you think about it. 

All of these suffer from the problems of triangle routed media through the
service provider, resulting in the expense of double-erlang bandwidth
provisioning, and high latencies, that I have documented. The point I have
been making, and the point I made continuously during the informal get
together at IETF 51, was that if you are willing to accept these penalties,
there are many VPN solutions today. They have their own issues in terms of
compliance with enterprise firewall policy, but thats another issue I will
comment on separately.

What we need is a solution that does not suffer these problems, and that is
what stun is offering.

- Jonathan R.

---
Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

> 
> Saqib
> 
> >From: "Bob Penfield" <[email-masked]>
> >To: "Barry Scott" <[email-masked]>, "'James Ho'" 
> ><[email-masked]>, <[email-masked]>
> >Subject: Re: [midcom] pre-midcom candidates
> >Date: Thu, 1 Nov 2001 11:29:46 -0500
> >
> >What percentage of NAT/FW are symmetric as opposed to full-cone as 
> >described
> >in the STUN proposal? There is some debate whether or not the interim
> >solution needs to address the symmetric NAT problem. If the 
> great majority
> >of existing FW/NAT are symmetric, we probably need to include it now.
> >
> >(-:bob
> >
> >Robert F. Penfield
> >Chief Software Architect
> >Acme Packet, Inc.
> >130 New Boston Street
> >Woburn, MA 01801
> >[email-masked]
> >
> >----- Original Message -----
> >From: "Barry Scott" <[email-masked]>
> >To: "'James Ho'" <[email-masked]>; <[email-masked]>
> >Sent: Thursday, November 01, 2001 9:58 AM
> > > BArry
> > > From: James Ho [mailto:[email-masked]]
> > > Sent: 31 October 2001 22:20
> > > To: [email-masked]
> > > As I understand it, the Davies proposal requires an open
> > > UDP port on the firewall for media traversal. I can't think
> > > of many/any enterprises being willing to implement such a
> > > firewall policy. Or maybe my understanding is faulty??
> > >
> > > james
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at 
> >http://explorer.msn.com/intl.asp
> > >
> > >
> _________________________________________________________________
> Get your FREE download of MSN Explorer at 
http://explorer.msn.com/intl.asp

---

From: "Bob Penfield" <[email-masked]>
Date: Fri, 2 Nov 2001 10:14:12 -0500

Hi all,

I just want to throw my hat into the ring as a supporter of the STUN
proposal.

It is very simple and will be relatively easy to implement directly in
endpoints. It requires no state in the server side. It adheres to the
security policy of the firewall/NAT owner.

With STUN as a basic tool, more complex solutions can be developed. It could
even be used to implement much of the Davies proposal.

I do think we need to address the symmetric NAT problem soon.

The Sen proposal seems too narrow in its focus on SIP and RTP. It also
includes a midcom-like component in the protocol between the SIP element and
the RTP proxy. To standardize this approach we would need to standardize the
RTP proxy control protocol and we would virtually have midcom. The RTP proxy
is just a specialized NAT middlebox.

There are number of things I find troubling about the Davies proposal:

- The tunneling of the signaling through the firewall verges on subverting
the security policy of the firewall owner. As others have stated, existing
VPN methods can do this today. I also think that outbound TCP connections
for signaling can work in most cases.

- The protocol that would be required to implement this solution seems to be
too complex. I counted 12 methods. It seems to be as complex, if not more
so, than midcom will need to be. How long will it take to devise and
standardize it? Based on the claims of the draft, Ridgeway has devised this
protocol, but have they published the details? Given the complexity, it will
be more difficult and costly to develop endpoints that support it. Given
that, intermediate devices will be needed until all the endpoints support
it, which again increases the cost of deploying VOIP and other applications.

I think STUN is the best alternative for an easy, quick, and cost effective
solution for NAT/FW that will allow for wider deployment of VOIP and other
applications. It provides an interim solution until midcom is completed and
also is useful in the long term for scenarios where midcom is not
appropriate.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: "James Ho" <[email-masked]>
Date: Fri, 02 Nov 2001 15:50:43 -0800

My earlier e-mail was only regarding the pre-midcom drafts
(i.e. the requirements for the new midcom framework are clear while
I'm not clear on the need to come up with a new protocol standard
vs. use of an existing protocol standard for the pre-midcom work).
Sorry if I'm bringing up issues that may have been hashedout before.

Saqib

>From: Melinda Shore <[email-masked]>
>To: "James Ho" <[email-masked]>, [email-masked]
>Date: Fri, 02 Nov 2001 15:38:25 -0500
>
>At 12:08 PM 11/2/01 -0800, James Ho wrote:
> >The whole pt of having standards
> >such as Ipsec is that ITs confidence in allowing such protocols
> >to be securely used is enhanced due to their standard status. I'm not
> >sure defining new standards and/or proliferation of new
> >protocols (especially for the focused purpose of firewall traversal
> >of a specific set of media protocols) is going to enhance IT confidence
> >or making security policy-setting easier.
>
>If we must have this discussion (and I'd really rather we
>didn't - the working group was chartered some time ago under
>considerable scrutiny and we've nearly finished our work), we
>should start with the understanding that nobody is saying "never
>tunnel" and that we're not trying to supplant mechanisms that
>work.  Midcom is a response to well-understood situations in which
>tunneling will *not* work or will work badly.
>
>Melinda
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

---

From: "Sanjoy Sen" <[email-masked]>
Date: Mon, 5 Nov 2001 08:58:49 -0600

> From: Bob Penfield [mailto:[email-masked]]
> Sent: Friday, November 02, 2001 9:14 AM
> To: midcom
...
> is just a specialized NAT middlebox.

As far as standardization, the only requirement in the Sen proposal is the
option tag (indicating to the Proxy that the client is behind the NAT) for
the signaling path. For the RTP Proxy control, a device control protocol
such as Megaco or MGCP can be used as is, i.e. there's no standardization
effort required. For traditional Firewall/NAT control (Midcom), Megaco needs
to be extended as has been described in:
http://search.ietf.org/internet-drafts/draft-sct-midcom-megaco-00.txt
http://search.ietf.org/internet-drafts/draft-sct-midcom-megaco-pkg-00.txt

The Sen proposal is as close to Midcom as it gets & is the simplest of the
three proposals. The proposal primarily addresses the needs of different
(albeit, overlapping) market segments than STUN. STUN is useful for
residential and perhaps some small/medium Enterprise scenarios, where Cone
type of NAT's predominate. The Media Proxy is the ideal candidate for
medium/large Enterprise and Carrier service providers. Not only the
predominant FW/NAT configuration for medium/large Enterprises mimick the
symmetric NAT behavior, but the signaling/media Proxy combination provides
some key advantages in terms of route-pinning and service management (e.g.,
billing, legal intercept) for service providers, carriers.  

Thanks, 
Sanjoy

================================
Interactive Multimedia Server
Carrier VoIP
Nortel Networks
Ph: 972-685-8274, Fax: 972-685-3813
Mobile: 972-571-2062

---

From: Jonathan Rosenberg <[email-masked]>
Date: Tue, 6 Nov 2001 00:41:28 -0500

> Sent: Friday, November 02, 2001 6:51 PM
> To: [email-masked]; [email-masked]

THis is indeed a good question, and its the point I have been trying to
make. There are a variety of VPN solutions, and many of them allow
applications to traverse nat. There are drawbacks of the VPN solutions -
increased latency and increased data traffic to the provider. Any solution
which retains these drawbacks is just going to define yet-another VPN
approach, and its not clear what the value of that is. There IS immmediate
value in a solution that does not suffer these problems, and therefore does
something different from VPN will do. That is the point to the stun
proposal.

-Jonathan R.

---

---

From: Steve Davies <[email-masked]>
Date: Mon, 12 Nov 2001 14:28:51 -0000

Bob,

In my opinion there is an underlying confusion in this debate. I believe

* 'the discovery of the type of firewall/NAT combination a terminal is
behind' 

is different from

* 'the traversal of VoIP through any firewall/NAT combination'

And because they are different, they don't necessarily need the same
protocol. The reason we have lots of protocols is because they provide
different functions. Trying to extend a protocol to handle substantially
different tasks usually results in a cumbersome protocol that takes forever
to produce. By definition pre-midcom needs to avoid this.

The STUN protocol does the discovery piece very well. The Davies proposal
does no discovery - it assumes apriori it's behind a Symmetric NAT (which
includes a FW/NAT combination or just a FW.)

The Davies proposal does the VoIP traversal very well. The STUN proposal
does no traversal. Having discovered it is behind a Cone-type NAT, it
requires terminal behavioural change to get the media flowing direct. As has
already been noted, STUN does not help with Symmetric NAT or a firewall/NAT
combination. It has also been noted that the extension of STUN to cope with
Symmetric NAT would result in a method that would be very like the Davies
proposal.

Therefore for 100% deployment coverage, a pre-midcom solution would need
either:

1. Davies proposal - don't care about Cone NAT for the time being
or
2. Davies + STUN - some media may go direct

I propose starting with 1. because it is less work than 2. and it has not
been quantified whether it is worthwhile to adopt STUN for the percentage of
calls it would affect in a pre-midcom timeframe. 

Other comments in-line below:

Steve

-----Original Message-----
From: Bob Penfield [mailto:[email-masked]]
Sent: 02 November 2001 15:14
To: midcom
Subject: Re: [midcom] pre-midcom candidates

Hi all,

It is very simple and will be relatively easy to implement directly in
endpoints. It requires no state in the server side. It adheres to the
security policy of the firewall/NAT owner.
[SD] How can you say STUN adheres to the security policy of the firewall/NAT
owner? It has already been noted that STUN offers no VoIP traversal solution
through a firewall/NAT combination, so today it wouldn't be deployed in this
case. Or are you saying the STUN protocol itself (minus traversal) adheres
to the security policy? The Davies proposal also adheres very well to the
security policy. Actually the mechanism the Davies proposal uses for
traversal is very similar to the mechanism used to get the STUN protocol
itself through the firewall.

With STUN as a basic tool, more complex solutions can be developed. It could
even be used to implement much of the Davies proposal.
[SD] See my main point above. The discovery of the firewall/NAT combination
is a different task to the actual traversal. If you are saying that STUN can
be used to know when to use the Davies method then I agree, but that doesn't
imply it's an extension of STUN, just that they could co-exist. The reason
we have lots of protocols is because they all do different jobs. Extending
one protocol to do lots of different jobs usually leads to going down a
rat-hole.

I do think we need to address the symmetric NAT problem soon.
[SD] The Davies proposal has! 

- The tunneling of the signaling through the firewall verges on subverting
the security policy of the firewall owner. As others have stated, existing
VPN methods can do this today. I also think that outbound TCP connections
for signaling can work in most cases.
[SD] The Davies proposal has ALL connections as outgoing connections. The
firewall owner can choose to block the Davies protocol, if that is their
policy. However we expect that they will choose to use a pre-midcom solution
that fits their security policies, so there is no subversion.

- The protocol that would be required to implement this solution seems to be
too complex. I counted 12 methods. It seems to be as complex, if not more
so, than midcom will need to be. How long will it take to devise and
standardize it? Based on the claims of the draft, Ridgeway has devised this
protocol, but have they published the details? Given the complexity, it will
be more difficult and costly to develop endpoints that support it. Given
that, intermediate devices will be needed until all the endpoints support
it, which again increases the cost of deploying VOIP and other applications.
[SD] Ridgeway will publish the details if it is the chosen pre-midcom
candidate. The Davies proposal is more complex than STUN because it's
solving a more complex problem than STUN, but that does not imply it's more
complex than it needs to be. We can also infer that the Davies proposal is
less complex than Midcom because it doesn't need to do any of the pin-holing
that is required in Midcom. Cost of implementation generally decreases
inline with competition. Standardization will enable that competition. 

[SD] How can you make this claim when STUN doesn't solve the NAT/FW problem?

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

---

From: Melinda Shore <[email-masked]>
Date: Mon, 12 Nov 2001 12:03:58 -0500

At 04:49 PM 11/12/01 +0000, Steve Davies wrote:
>Are you moving the goal-posts? 

Not at all.  The goal was and remains to do something quickly
that does NOT supplant midcom.  If we spend months and
months haggling over this we will have failed.  If we develop
something that does more-or-less what midcom will do but is
even more ugly than midcom we will have failed.  Etc.  Remember,
it's "pre-midcom," not "instead-of-midcom."

Melinda

---

From: Steve Davies <[email-masked]>
Date: Mon, 12 Nov 2001 17:35:06 -0000

I think I agreed. I assumed and still assume that a pre-midcom solution is a
solution that enables FW/NAT traversal through legacy equipment. Once Midcom
is finished, gradually FW/NATs would be replaced by Midcom-aware devices
obviating the pre-midcom solution. Users would migrate from pre-midcom to
Midcom because Midcom would be better. In the case of the Davies proposal, a
media intermediary is required. Midcom is better because it dispenses with
that need. The need for a pre-midcom solution is clear. The market is
stalled waiting for Midcom. But to liberate the industry the pre-midcom
solution should address, I believe, all midcom-unaware middleboxes whether
they be just a FW, a FW/NAT combination or just a NAT. 

Is this correct?

Steve

-----Original Message-----
From: Melinda Shore [mailto:[email-masked]]
Sent: 12 November 2001 17:04
To: Steve Davies; 'midcom'
Subject: RE: [midcom] pre-midcom candidates

Melinda

---

From: "Meyer, Greg W" <[email-masked]>
Date: Tue, 13 Nov 2001 17:56:51 -0800

I agree with Pete; I would favor a solution that addresses both firewall and
NAT. The trade-offs Jonathan raise about the Davies approach are very
acceptable given pre-midcom is temporary (until midcom is deployed). Any
short-term solution that doesn't account for today's most deployed networks
simply defeats the purpose.

Greg Meyer
Intel Labs

-----Original Message-----
From: Pete Cordell [mailto:[email-masked]]
Sent: Monday, November 12, 2001 10:16 AM
To: Steve Davies; 'Bob Penfield'; 'midcom'; Melinda Shore
Subject: Re: [midcom] pre-midcom candidates

I'm just wondering if there is any point to developing a solution that does
not address the firewall.  Most enterprises will have firewalls, and the
percentage of residential firewalls can only go up.  (As has been said
elsewhere, the presence of a firewall effectively makes the NAT symmetric.
The consensus so far seems to be that such NATs need additional steps beyond
discovering what type they are to get the protocols through.)

Also, many dial-up residential cases do not have to contend with NAT at all.

My feeling is that if we don't address the firewall, we will have spent time
developing something that helps out only a very few cases, and really
doesn't move us any closer to where we want to be.

The result would be to delay real midcom with no gain.

Pete.

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

----- Original Message -----
From: Melinda Shore <[email-masked]>
To: Steve Davies <[email-masked]>; 'Bob Penfield'
<[email-masked]>; 'midcom' <[email-masked]>
Sent: 12 November 2001 16:04
Subject: RE: [midcom] pre-midcom candidates

> At 02:28 PM 11/12/01 +0000, Steve Davies wrote:
> I'd like to remind everybody that pre-midcom != midcom.  That
> is to say, the intent is to get a simple hack addressing the hard
> problem (NAT traversal) out quickly.  The work that's going to
> address NAT and firewall traversal and attempt to be thorough
> about it is midcom itself.  Please, let's not get carried away.
>
> Melinda
>
>

---

From: "James Ho" <[email-masked]>
Date: Thu, 15 Nov 2001 11:07:39 -0800

Two issues pertaining to the pre-midcom work that I still don't
have clarity around.

1. What are the specific latency/peformance issues associated with
tunnelling/VPN appraoches? While admitedly there is another device
in the picture, as I mentioned before, there are available/evolving
hw solutions for integrate wire-speed IPsec processing
enabling tunnel de/encapsulation at wire-speeds, so theoretically
this should not be an issue.

2. what is the benefit of developing new/additional approaches
for secure tunneling when there are existing standards in place
for this (e.g. IPsec)? From Jonathan's e-mail, it would seem that
the answer to this is 'no'. Is there a concensus around this
(I understand there is a philosophical debate underway on this but my
interest is in the technical issues)?

>From: Jonathan Rosenberg <[email-masked]>
>To: "'James Ho'" <[email-masked]>, [email-masked], [email-masked]
>Date: Tue, 6 Nov 2001 00:41:28 -0500
>
>
>
>
>