Subject: Re: [midcom] FANTOM comments

From: "Pete Cordell" <[email-masked]>
Date: Wed, 5 Dec 2001 15:53:45 -0000

Cedric,

Please see comments in-line:

> From: Cedric Aoun
>
>
> 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.

Our experiments have shown that we are able to handle media forwarding at
wire speed on 100 Mb Ethernet using ordinary computing hardware.  As most
organisations only have a few T1 links to their ISP this is not a particular
burden, and a service provider can easily handle many enterprises with a
single box.  If they need more capacity they can simply add more boxes.
FANTOM is designed to scale very well in that respect.

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

Firstly, there is no reason that FANTOM can not be used on the client.  I
think using a separate AP gives a more secure solution for an enterprise
environment and that's why I've pushed it, but integrating the AP with the
client is also perfectly valid.

The extensions you are talking about are intimately coupled with the
internal workings of the SIP client.  SIP is complicated enough without
requiring extra layers of logic to implement NAT traversal.  I also don't
want to have to undo all those changes when migrating to midcom.

On the other hand, when integrated in the client FANTOM can be treated as an
alternative transport layer, and hence all the changes are localised.  This
represents good modular design principles.  I think this is an essential
quality for when pre-midcom is replaced by midcom.

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

No it's not - If you think about it, the problem is caused in part because
the firewall doesn't have the ability to sniff the data in the connections
in the first place.  If FANTOM is implemented in the client, this is no
different to any other TCP outbound connection.  Hopefully you'll agree that
there is no concern about data sent out.  For the data sent in, it is up to
the client how this is interpreted.  The format or content of the data
presents no more threat than any other TCP connection that might be
established.

If you implement the AP as a standalone proxy, then it can implement full
stateful inspection and only allow through what it is happy with.  In this
case the firewall and the AP work together to deliver a secure solution.
The firewall ensures that FANTOM only  comes from the authorised AP.
Authentication with the PEA is another check that the correct AP is being
used.  Various forms of spoofing are also subverted by this dual approach.
How does the administrator know that he/she can trust the AP?  Because
he/she put it there.  There is no less reason to trust a separate AP than
there is to trust an ALG in a firewall / NAT.  (That's why we view it as an
externalised ALG - let's call it an EALG!)

>
> -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 the key word here is 'looks'.  I think that a working solution based
on FANTOM is no more complex than a working solution based on TURN or the
Sen proposal.  Much of the difference is that the complexity of the TURN and
Sen proposals are hidden in the modifications needed to SIP.  I believe such
changes will be harder to manage, and harder to test.  Also, I feel that
implementors will be reluctant to make such changes if they will later have
to remove them in order to migrate to midcom.  The result will be that
pre-midcom doesn't achieve its objective of a quick time to market.

>
> -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.

If we could use a bunch of established protocols to achieve the result then
I would agree with you.  If we are going to have to invent stuff (e.g. STUN
/ TURN / Sen) then we might as well make a good job of it.  FANTOM is a
simple one-stop plug in solution to fix the problem.

>
> Hope I understood your solution.
> Cedric
> Cedric Aoun
> Nortel Networks
> France
> mailto:[email-masked]
>

Pete.

=============================================
Pete Cordell
Tech-Know-Ware
[email-masked]
+44 1473 635863
=============================================

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

---

From: "Paul Francis" <[email-masked]>
Date: Wed, 5 Dec 2001 18:07:00 -0800

Am I write in assuming that the STUN lifetime discovery won't work for
full-cone NATs when the client is sending any UDP packets (i.e. for some
application) through the NAT?

The reason being that if the client is using a UDP application, then those
packets will refresh the NAT state, so the binary discovery process won't
discover anything.  This means that you can't really run any applications
until you've finished the lifetime discovery process, yes?  (Maybe this is
not a huge deal ... I just want to make sure my understanding is correct.)

Another question.  Does anybody know if the lifetime in NAT boxes varies?
For instance, the NAT box could decrease the lifetime when it gets busy?

Or, what if the NAT box had a clever bit of software that does a hash on the
client IP address in order to try to assign the same port number even after
a previous assignment has timed out?  This would result in the lifetime
appearing to be variable.

I'm just generally wondering how much a client application can really depend
on lifetime discovery . . .

PF

---

From: Kuniaki Kondo <[email-masked]>
Date: Sun, 9 Dec 2001 08:43:12 +0900

>FANTOM is designed to scale very well in that respect.

  Enterprise user indeeded have a few T1 links. If the FANTOM is used
  for those situation, then I think that it will work.
  However, All ISP customer might not use FANTOM such as home user.
  Many ISPs have many thousands of home user or small scale enterprise
  user. In this situation, ISP should give FANTOM server, and
  ISP have to transfer enormous traffic through FANTOM server.
  It may be over some giga bps. How many servers does ISP put on
  their network? I don't think that this model is scalable.

--
Kuniaki Kondo
[email-masked]

---

From: "Christopher A. Martin" <[email-masked]>
Date: Mon, 10 Dec 2001 15:15:28 -0600

Since we are trying to resolve an enterprise issue right now, I thought, why
mention the home user?

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]On Behalf Of
> Kuniaki Kondo
> Sent: Saturday, December 08, 2001 5:43 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [midcom] FANTOM comments
>
>

---

From: Kuniaki Kondo <[email-masked]>
Date: Tue, 11 Dec 2001 08:22:47 +0900

In message <[email-masked]>
   "RE: [midcom] FANTOM comments"

>Since we are trying to resolve an enterprise issue right now, I thought, why

  Firstly, my wording was not better.
  Home user, I mean small scale network user who uses
  1 segment in their network. Thus, it includes
  "small enterprise user".
  Could you explain how size is enterprise network?

  I said in 2 or 3 previous mail that FANTOM,STUN or TURN
  might be good for enterprise network.
  It means that some enterprize might be able to buy a those 
  server and be able to put the server on thier network.
  
  However, ISP's traffic is more enourmous than enterprise one.
  In that situation, ISPs might abhor to put those servers,
  becasue those server collects enourmous traffic.

--
Kuniaki Kondo
[email-masked]