Subject: RE: [midcom] pre-midcom candidates - the Davies Critique

From: "Christopher A. Martin" <[email-masked]>
Date: Thu, 01 Nov 2001 10:39:22 -0600

Anything intended to keep a "pinhole" open is actually pretty inefficient in
behavoir...the Davies proposal is actually on an as needed basis which is
more efficient. Also the ablity to maintain "control" by the IT managers is
inherent to the Davies design, IMHO, since the enforcement is maintained
both at the AP(where policy can be enforced), the firewall(s), and the SIP
proxies (in the case of SIP signaling). I need to continue researcing the
Davies proposal, but these were my initial opinions on the draft.

The other proposals place enforcement at the clients, as they are
maintaining the pinholes through the firewall, not a place that many IT
managers typically allow enforcement to placed (except for possibly the
SOHO).

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Christian Huitema
> Sent: Wednesday, October 31, 2001 4:26 PM
> To: Steve Davies; midcom
> Cc: Melinda Shore; Jonathan Rosenberg
> Subject: RE: [midcom] pre-midcom candidates - the Davies Critique
>
>
> Steve,
>
> Your point regarding "Stun and firewalls" is mistaken. The STUN
> requirement is that if there is a firewall, it let a response
> come in to
> a packet sent from an internal port. This is the default behavior of
> most "residential NAT/firewall", and it is also an optional
> behavior in
> many enterprise firewalls. Whether such a policy is deemed
> acceptable by
> the local IT manager is debatable -- there are pros and cons.
>
> -- Christian Huitema
>
> -----Original Message-----
> From: Steve Davies [mailto:[email-masked]]
> Sent: Wednesday, October 31, 2001 12:57 PM
> To: 'midcom'
> Cc: 'Melinda Shore'; 'Jonathan Rosenberg'
> Subject: RE: [midcom] pre-midcom candidates - the Davies Critique
>
> (Apologies if you get this twice. The first attempt was too
> long for the
> mailing list so I've deleted the history.)....
> Naturally, I don't entirely agree with Jonathan's analysis. Here is
> mine:
> The Sen Proposal:
> -----------------
> I don't see the Sen proposal as an adequate near-term/pre-midcom
> solution for two main reasons:
> (a) it requires changes to the protocol:
> ----------------------------------------
> In order to make the Sen proposal work we are told that a new service
> tag must be incorporated in the SIP Register request and a
> new SIP Ping
> (keep-alive) method must be incorporated. Not only will this take time
> to implement in SIP but presumably we'll also need corresponding
> protocol changes for Megaco, MGCP, H.323, etc. Or is Midcom
> SIP-specific?
> (b) it requires behavioural changes to the client:
> --------------------------------------------------
> It requires symmetric RTP and the continual transmission of
> RTP and RTCP
> packets to keep the NAT bindings open. While symmetric RTP
> may be a good
> thing, that doesn't imply all applications have constant
> bi-directional
> streams - think of 'broadcast' type applications. Also why should
> terminals be expected to turn off silence suppression? How
> are endpoints
> to know when and when not to make this behavioural change?
> Other weaknesses of the proposal include a requirement on terminals to
> signal to the SIP proxy when they are behind a NAT. It is not
> explained
> how they are supposed to know whether or not they are.
> Additionally, the
> use of random ports on the RTP Proxy makes it difficult to
> protect such
> a device with a regular filtering firewall. Such
> configurations would be
> required for an enterprise do-it-yourself solution(the
> enterprise is its
> own provider) and by service providers wanting to protect
> their networks
> and service from DoS attacks.
> Note that correction of all these shortcomings results in the same
> architecture and method outlined in the Davies proposal.
> The Rosenberg/STUN Proposal:
> ----------------------------
> Whilst I acknowledge the STUN proposal provides a method to determine
> the type of NAT a terminal may be behind, I view the proposal as
> incomplete and potentially impractical candidate as a
> near-term/pre-midcom solution.
> a) Firewalls are everywhere:
> ----------------------------
> Whenever a firewall is deployed in conjunction with a NAT,
> irrespective
> of the type of NAT, the net result is equivalent to what the
> STUN method
> describes as a Symmetric NAT. In the case of symmetric NATs, the
> Rosenberg proposal acknowledges that a media
> intermediary/relay (or RTP
> Proxy) is required. However, the STUN proposal doesn't inform us what
> the architecture and method are for making calls in this
> case, although
> Jonathan acknowledges in his email that there are three
> solutions - the
> Davies proposal, the Sen proposal and an unpublished STUN proposal.
> Firewalls are a fact of life in all enterprises connected to the
> internet. An ever-increasing number of users are installing
> firewalls in
> their homes as well. The majority of calls will require a media
> intermediary/RTP Proxy. In other words, VoIP providers will have to
> install media intermediaries from Day One of any service. Can you
> imagine the subscription scenario if they don't:
> Customer: 'Please may I subscribe to your service'
> Provider: 'Is your terminal behind a firewall?'
> Customer: 'Yes'
> Provider: 'Sorry our service won't work for you' or 'Yes, but please
> place your terminal outside the firewall' or 'Yes, but you
> can only call
> other people not behind a firewall or symmetric NAT'.
> This is not what the VoIP industry needs right now!
> b) Too early to optimise:
> -------------------------
> The STUN proposal boils down to a port saving technique for VoIP
> providers. But in a nascent market its impractical to start
> with a port
> saving technique particularly when its unquantifiable how many ports a
> provider may save. What providers need is a solution that is
> deployable
> in all cases - that implies a media intermediary solution. Trying to
> combine a port saving technique in conjunction with a media
> intermediary
> solution will add complexity that will delay and stall the
> VoIP market.
> From a provider's perspective, this delay and additional testing could
> far outweigh any savings gained by requiring fewer media intermediary
> ports.
> c) Unproven:
> ------------
> i) TIMEOUTS. When a user is behind a firewall or symmetric
> NAT, to avoid
> use of a media intermediary the terminal must invoke the STUN protocol
> on a call by call basis. The STUN protocol requires potentially
> significant timeouts to expire in order to determine whether media may
> go direct. What will this do to call setup times?
> ii) NETWORK BASED NATS. There may be cases where the terminal
> determines
> that the media may go direct, but in fact the media passes through
> network based NATs and the call will fail. This would typically happen
> at the provider boundary, because the provider uses some internal
> addressing scheme or when passing from IPv4 to IPv6 networks. The
> solution would be to place the STUN server on the remote side of those
> network based NATs, but this would have the consequence of tromboning
> the media via those network based NATs for 'provider-internal' calls,
> defeating the reason for STUN. Alternatively, multiple STUN servers
> would need to be deployed - one for each different NAT location, but
> that then poses the question of how a terminal would know which STUN
> server to use on a call-by-call basis.
> Davies proposal:
> ----------------
> The Davies proposal is very midcom-like. The Proxy Extension
> Agent (PEA)
> is like a MIDDLEBOX and the Application Proxy (AP) is like a MIDCOM
> AGENT. The AP is responsible for getting publicly reachable transport
> addresses on the PEA for external calls and publishing those addresses
> in the protocol messages.
> The Davies proposal simplifies the security policy problem being
> grappled with by MIDCOM to a very simple static policy
> administered and
> controlled by the IT manager and implemented on existing
> firewalls. Just
> three static pinholes are required to be configured in the firewall.
> Furthermore, these pinholes are outbound pinholes(i.e. out from the
> enterprise).
> Jonathan writes that in the Davies draft there are issues to do with
> consistency with enterprise firewall policy, but this is
> unsubstantiated. When details of these issues are provided, we will be
> happy to discuss them. The Davies method is entirely consistent with
> enterprise firewall policy - it is similar to, but actually far more
> restrictive than the firewall policy that allows web browsing for
> example. The Davies proposal's policy has been vetted by service
> providers and is already in commercial deployments - we can
> only assume
> enterprises find it acceptable.
> As well as being midcom-like, the Davies method has many other
> significant advantages:
> * It provides a 100% solution. It will work anywhere no
> matter how many
> and what type and combination of firewalls and NATs there are.
> * No change is required to any of the protocols. It is not even
> necessary for endpoints to implement symmetric RTP.
> * The implementation can be made transparent to the endpoints or be
> implemented by them.
> * Enterprise or Service Provider deployments are possible. The PEA may
> be deployed within a service provider's network or within the
> DMZ of an
> enterprise's own service centre.
> * Passing through a media intermediary is seen as enhancing
> security and
> saving IP addresses. Hiding an enterprise IP address from the remote
> party (only the transport addresses of the PEA are published in
> messages) is seen as a benefit and enables the enterprise to use the
> same IP address used for other Internet traffic.
> * Service Providers see a benefit in handling the media
> through PEA for
> several reasons. It enables them to hide the transport addresses of
> their other service equipment. It provides them with a
> suitable point to
> implement wire-tapping (e.g.CALEA) - ITSPs in many countries are bound
> to provide such capabilities. It also provides them with a media QOS
> execution point and it provides suitable IPv4/IPv6 migration boundary
> points.
> Jonathan seeks to belittle the Davies proposal by likening it to RSIP.
> I'm not sure what the point is here. It is true that we have borrowed
> and learnt from many of the principles and techniques used within the
> Internet. That's why we have well known ports, outbound initiated
> connections, and TCP multiplexing, so it's not surprising the
> method is
> recognisable and architecturally looks similar to other
> protocols. What
> is unique, is the way in which this method combines the different
> Internet techniques together with the transport of real-time
> UDP streams
> without any tunneling overhead.
> In fact, the single disadvantage of the Davies proposal is that it
> requires media intermediaries, but no-one has devised a non-media
> intermediary solution that solves all of today's firewall and NAT
> deployments. In any case, media intermediaries are not of much concern
> to service providers because they will co-locate those intermediaries
> with their access equipment in their POPs. In due course, those
> intermediaries may even be implemented in the access routers or Midcom
> will obviate them.
> Pre-Midcom Recommendation:
> --------------------------
> Jonathan writes that he wants to tackle the harder stuff,
> i.e. firewalls
> and symmetric NATs, later. The fact of the matter is that the Davies
> proposal has solved the harder stuff already. It is the
> Davies proposal
> that is the low-hanging fruit because it addresses 100% of deployments
> and it has working examples. Surely this is where a
> pre-midcom solution
> must start. A VoIP provider needs it from Day One because it is very
> likely some/many customers will have a firewall or symmetric
> NAT. If in
> time, providers are seeking more efficient deployments or are
> seeking to
> reduce costs, then the Davies solution is easily extended to
> incorporate
> a STUN-like method. But before embarking on this effort it
> would be wise
> to judge the market need and determine when MIDCOM will kick in.
> Steve Davies
>
> _______________________________________________
> midcom mailing list
> [email-masked]
> http://www1.ietf.org/mailman/listinfo/midcom
>

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

---

From: "Bob Penfield" <[email-masked]>
Date: Thu, 1 Nov 2001 12:45:30 -0500

----- Original Message -----
From: "Christopher A. Martin" <[email-masked]>
To: "'Christian Huitema'" <[email-masked]>; "'Steve Davies'"
<[email-masked]>; "'midcom'" <[email-masked]>
Cc: "'Melinda Shore'" <[email-masked]>; "'Jonathan Rosenberg'"
<[email-masked]>
Sent: Thursday, November 01, 2001 11:39 AM
Subject: RE: [midcom] pre-midcom candidates - the Davies Critique

> managers typically allow enforcement to placed (except for possibly the

You are assuming that IT manager have "control" over the Application Proxy.
I don't think that will be the case. If the APs are built into end-points,
the enforcement is still at the client. Both the Davies and the STUN
proposals involve poking UDP holes thru the NAT/FW for RTP by devices that
are "clients" as far as an IT manager is concerned. Davies just adds the
tunnel for the signalling.