Subject: RE: [midcom] pre-midcom requirements and goals

From: Steve Davies <[email-masked]>
Date: Mon, 10 Dec 2001 02:32:18 -0000

All,

Perhaps the reason we have not been making much progress on a pre-midcom
solution is
that we have not been discussuing how the candidates meet any underlying
requirements. 
In truth we have no explicit requirements, only goals. However, at an adhoc
meeting 
at the 51st IETF in London (in which 60+ people attended), there seemed to
be a consensus 
(at the time only 1 person voiced disagreement) that a pre-midcom solution
should address 
the following requirements:

1. enable VoIP and MoIP through already deployed firewalls and NATs - no
upgrades required
2. protocol agnostic solution - work for SIP, Megaco, H.323, MGCP etc.
3. must be secure in the firewall sense
4. must keep control with the FW/IT administrator (i.e. if he wants to block
VoIP, then so be it)
5. should work with any flavours of NAT
6. must allow existing clients/proxies to be unaware of the solution
7. must be compatible with real-time media transport requirements
8. a near term development without inhibiting long term solutions
(Midcom/IPV6)
9. not break end-to-end security

In addition, the following are stated pre-midcom goals:
a. rapid delivery
b. consistency with midcom
c. consistency with security

STUN/TURN:
----------
As specified TURN does not work for H.323. 

STUN/TURN require changes to SIP to make it work and therfore does not work
with existing clients and proxies 
The TURN solution requires all clients to implement bi-directional, passive
RTP, which entails new client behavior
to make STUN, TURN and passive RTP decisions. Client and proxy behavioral
changes are also required to implement 
TCP signaling.

The need for bi-directional passive RTP becomes obsolete in a Midcom
solution as do the client and proxy behavioral 
changes STUN/TURN entails. By promoting STUN/TURN as a pre-midcom solution
the group will be condemning terminal
manufacturers and the industry to a lot of churn that may inhibit Midcom
uptake.

The advantage of TURN over FANTOM and Sen proposals is that in the symmetric
NAT or FW/NAT case it can,
in theory, half the number of media intermediary hops that the FANTOM/Sen
solutions require. However, the saving 
is really only for inter-service provider calls when all end-points support
passive RTP, and only if service providers
have the right bi-lateral agreements. For intra-service provider calls, the
number of media intermediary hops 
for all solutions is identical, i.e. 1.

The price TURN pays for the media hop saving is that a TURN client must be
able to make an outbound UDP connections
to any public IP address, so the enterprise firewall must allow it. Many
firewall administrators will feel
uncomfortable with this sieve-like security policy. Sen and FANTOM can
restrict outbound UDP connections to 
designated intermediaries only. Furthermore, through TURN, an enterprises IP
address can easily be discovered 
through making a call to it. SEN and FANTOM hide enterprise IP addresses
which in many quarters is a perceived
benefit.

In summary, STUN/TURN does not meet requirements 2, 6 and 8 and is the
weakest on 3. It is also difficult to see
how it meets goals a and b.

SEN:
----
Like STUN/TURN, the Sen proposal is SIP specific also requiring
bi-directional passive RTP and client and proxy 
behavioral changes that are obsoleted by Midcom.

It does not meet requirements 2, 6 and 8, or goals a and b.

FANTOM:
-------
FANTOM is the only candidate that meets all these requirements.
Architecurally, FANTOM is a natural pre-decessor
to Midcom. It fits into the Midcom framework and aligns with many of the
Midcom principles. It could even share 
many of the Midcom protocol methods. 

FANTOM has been designed with ease of deployment in mind. It can be deployed
transparently to all endpoints. In the
case of an enterprise, once an AP and PEA are deployed its simply a matter
of configuration of firewalls, 
proxies and endpoints. No protocol changes to SIP,SDP, RTP, H.323 ... are
needed. This allows for quick, trouble-free
deployment of VoIP and MoIP - today.

Having deployed FANTOM, an administrator will have some insight into what is
involved in deploying Midcom and 
they should feel comfortable doing it. They would also perceive benefit
(less media hops) in making the migration 
from FANTOM to Midcom which would be seamless as the FANTOM AP becomes a
Midcom Agent. In this context TURN and Sen are 
radically different concepts and represent separate evolutionary paths.  As
such they do not prepare an enterprise 
for a midcom deployment.

FANTOM also lends itself to the most scalable secure implementation.
Firewall rules can restrict UDP traffic from/to 
a standalone FANTOM client and well known ports of the FANTOM server.
Conversely, if an administrator does not want all clients  to be able to
make UDP connections to any public host, TURN is not deployable and SEN
requires the media intermediary's IP addresses to be pre-specified, which
doesn't scale that well.

Does the list agree that this is the right sort of criterion by which to
compare the candidates, and is the corresponding analysis fair?

Steve 
www.ridgewaysystems.com

---

From: Kuniaki Kondo <[email-masked]>
Date: Mon, 10 Dec 2001 16:10:32 +0900

Hi,

This summary might rise up a nature of midcom.
I think that those consensus should reconfirm at
tomorrow meeting.

Incidentally, this summary did not compare with NATS proposal.
Then, I would like to add it.

In message <00533D13955AD411AF3800A0C9B42639E92661@ThisAddressDoesNotExist>
   "RE: [midcom] pre-midcom requirements and goals"

>1. enable VoIP and MoIP through already deployed firewalls and NATs - no

  What is the purpose of this issue?
  If the purpose is 'rapid delivery' then we should concern more about
  this. Because recent NAT/NAPT router can updates very easily by
  just firmware upgrade which is released by router vendors.
  Conversely, If a protocol needs to change already existing application
  then deployment might be late.

>2. protocol agnostic solution - work for SIP, Megaco, H.323, MGCP etc.

  NATS does not need to change application software.

>3. must be secure in the firewall sense

  NATS is same as NAT/NAPT about security issue.

>4. must keep control with the FW/IT administrator (i.e. if he wants to block

  NATS doesn't touch TCP/UDP layer.

>5. should work with any flavours of NAT

  I believe that NATS dose not have any problem about this.
  However, I need more concern.

>6. must allow existing clients/proxies to be unaware of the solution

  NATS meets this requirement.

>7. must be compatible with real-time media transport requirements

  NATS also meets this requirement.

>8. a near term development without inhibiting long term solutions

  NATS also meets this requirement.

>9. not break end-to-end security

  I don't understand what the purpose is.

>In addition, the following are stated pre-midcom goals:

  NATS already started implementation. Test code will 
  be released in January or February.

>c. consistency with security

  I need more concern about those issues.

Thank you.

--
Kuniaki Kondo
[email-masked]

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