Subject: [midcom] FANTOM comments

From: "Cedric Aoun" <[email-masked]>
Date: Fri, 30 Nov 2001 16:52:48 -0000

Hi Steve,
I have some comments on the FANTOM draft, I'm still way behind my mails so
sorry if my comments have already been posted.

-The FANTOM solution requires 2 devices (the AP and the PEA) one in the
private network and another one in the Service Provider (or DMZ of the
enterprise depending on the nature of the service).The AP hosts an
application proxy, a media proxy and the FANTOM client, the PEA hosts a
media proxy as well as a FANTOM server. Just by looking at the media proxy
role, it requires that the host machine has a forwarding rate to meet VoIP's
periodicity, assume 10 ms packetisation rate is used you have 100 pps in and
a 100 out, in total you will need to relay 200 pps for every single call.
This type of platform doesn't come for free if you have a hundred or more
calls, we are not talking of a standard workstation. 
In addition the PEA will require much more processing since it will need to
handle calls from other private networks. 
I'm assuming that you have a sort of architecture where the FANTOM server
could be used by several FANTOM clients (I'm talking about channel ids or
tunnel ids that you might need to use combined with association ids...). I
understand that you have used the AP to avoid modifying the end host but at
what cost. 
Since the end host has already an application client, why don't use the
application with certain extension to get the binds and refresh them as well
as workaround the problem where the signaling is sent to an address included
in the signaling message?

-One thing that I found weird is the usage of tunneling by using tcp
multiplexing, it's a VPN reinvention type of thing. What is the gain? I
understand that the driver was to reduce the number of pinholes to be opened
to allow the signaling to path through the packet filter. BUT this gain is
really small compared to the number of pinholes required for the media
flows, therefore I do not see the point for the tunneling. I'm sure that you
are aware of the risks of tunneling, the firewall doesn't have the
capability to snif in the payload of the TCP segments to determine the type
of protocols that are transported in the multiplexed channels.
THIS is a BIG HOLE in the corporate security

-The protocol between the AP and the PEA looks really complex and will need
at lot of work to get standardized, personally I would prefer building a
much simpler solution with existing protocols.

-I think that the transition solution to move towards Midcom should be based
on a mix of using reflectors (such as defined in STUN) in residential and
SMEs where full cone NATs are predominant, a media intermediary (instead of
2 in your solution) could be used to solve the symmetric NATs that are
mostly deployed in corporate and in service provider networks.

Hope I understood your solution.
Cedric

Cedric Aoun
Nortel Networks
France
mailto:[email-masked]