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

From: "Sanjoy Sen" <[email-masked]>
Date: Thu, 1 Nov 2001 15:24:27 -0600

Comments inline.

-----Original Message-----
From: Steve Davies [mailto:[email-masked]]
Sent: Wednesday, October 31, 2001 2: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:  

[SS] The solution is already in live deployment in some service provider
networks!

(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? 

[SS] The Proxy-Require option tag is only what is required. You need to
enable the Proxy distinguish between the cases when it should and should not
send messages to the source address/port of the received packet. The Ping
method is optional, Register refreshes can be used instead. The drawback of
the latter is that it hits the Registrar (at least once every minute)
unnecesarily. We tried that & ran into performance problems which made us
switch to a more lightweight mechanism. 

Yes, the signaling solution depicted in the draft is 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?  

[SS] The "Symmetric RTP" that we use is simply receive packets in the same
port that you send packets from. This is easily configurable in amost all
existing clients.  To keep the media path through the FW/NAT open, the
client is required to send out RTP/UDP packets voluntarily only when the
media stream is muted. These packets can be silence packets (which are
generated by many codecs for comfort noise) or empty UDP packets.

  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. 

[SS] This should not be a problem for the Enterprise-do-it-yourself ,
because they would typically have to trust packets coming from behind their
own firewall/NAT! In either case, the FW would only have to allow known
addresses/ports from the Enterprise side. 

Sanjoy

---

From: Steve Davies <[email-masked]>
Date: Tue, 6 Nov 2001 20:31:55 -0000

Christian, 

Are we talking at cross purposes? I understand that the STUN protocol itself
will go through the firewall in the manner you describe here, but I couldn't
find anything in your draft to say how STUN would help VoIP traverse a
firewalls/NAT combination or Symmetric NAT once it has discovered that the
terminal is behind such a configuration. Indeed, the Davies draft explains
how VoIP can successfully traverse this deployment configuration using the
technique you describe here - i.e 'let a response come in to a packet sent
from an internal port' using a policy that is (at least we have found)
acceptable to the local IT manager. 

Steve

-----Original Message-----
From: Christian Huitema [mailto:[email-masked]]
Sent: 31 October 2001 22:26
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