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

From: Steve Davies <[email-masked]>
Date: Wed, 31 Oct 2001 20:56:42 -0000

(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

---

From: "Christian Huitema" <[email-masked]>
Date: Wed, 31 Oct 2001 14:26:28 -0800

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