Subject: RE: [midcom] new I-D on "symmetric STUN"

From: "Sanjoy Sen" <[email-masked]>
Date: Mon, 3 Dec 2001 12:10:30 -0600

Steve, Please find my comments inline.

-----Original Message-----
From: Steve Davies [mailto:[email-masked]]
Sent: Friday, November 30, 2001 8:50 AM
To: Sen, Sanjoy [NGB:B692:EXCH]; [email-masked]'
Subject: RE: [midcom] new I-D on "symmetric STUN"

[snip] 
  
> 1) Your App. Proxy is also an RTP Proxy. So for a simple two party call
where both are behind NAPT, 
> the media need to traverse at least 3 RTP proxies. Is this correct? 

Ans: The FANTOM client, like the TURN client, may be implemented on the UA,
in which case only the external RTP proxy is traversed, as in your proposal.
The FANTOM client may also be implemented as a standalone system or be
co-resident in an IP-PBX or IAD. In this case you are correct. Why? See 2
below.  

  [SS] I still don't see the benefits of your standalone system apart from
bringing in additional cost and complexity to the solution (see below).

> 2) Not sure what you gain by making the media go through the App. Proxy?
For example, in our proposal, 
> we have the terminal send the empty RTP packets (equivalent to your
probes) directly to the Media 
> intermediary in the SP network to establish the media binds. 

Ans: The reason FANTOM is specified in this way is because we felt a
pre-midcom solution should require ABSOLUTELY NO changes (protocol or
behavioural) to enterprise endpoints and should work with existing systems.

[SS] I question the effectiveness of the additional complexity and an
additional network entity when you can avoid them by making some simple
configurations on the client. This is a costly solution for a problem which
can be solved easily otherwise. And, if you make the clients run FANTOM,
then you're adding a whole bunch of signaling complexity in the client.

 FANTOM places NO pre-requisite for symmetric bi-directional, continual RTP.
The FANTOM client is responsible for making outbound UDP connection and the
NAT keep-alives, so the UA can implement uni-directional RTP or silence
suppression if it wishes.  

[SS] Both the Sen proposal (and I believe TURN) can work with unidirectional
RTP. In the Sen proposal, you just need the send and receive ports spit out
empty RTP packets to create two binds in the NAT and Media Proxy. But
there's a cost-complexity trade-off as noted above. And, as I noted before,
you don't have to turn off silence suppression - either use the comfort
noise packets generated by most existing codecs during silence period or use
empty RTP packets.

 A major benefit of the FANTOM client (whether co-resident or standalone) is
that we can minimise the pin-holes required in the firewall to just a few -
our optimal solution is just 3 - one TCP and 2 UDP.  

[SS] This means you're resorting to "tunneling" and the FW has no clue as to
what packets are getting sent across within the tunnel. This is something we
all want to avoid.

 With FANTOM, a FW admnistrator can restrict external UDP to just symmetric
UDP to/from the FANTOM server's 2 UDP ports. With your proposal, the
firewall administrator has to work on IP addresses of the RTP proxies, which
means that as the service scales, the administrator is continually adding
extra IP addresses to the FW access list. The more work the FW administrator
does the greater the chances of error. 

[SS]  This is not correct. All you need for the Sen proposal to work is for
the FW to turn on dynamic stateful packet filter policy (aka, UDP
conversation or transparent firewall) which allows UDP packets in the
Enterprise if its from the same address/port that a packet was sent to. This
is most commonly used Enterprise FW policy. The admin doesn't worry about
the RTP proxy port allocations.

Again, there're only two ways you can keep the UDP path open - either create
a permanently open bind/pinhole, or use refresh packets. The first method is
obviously not a good security policy. If you resort to the second method,
then the main difference between FANTOM and the other proposals is whether
to create new messages (RTP probes) or re-use something existing for this
purpose (e.g., silence packets). Again, we think that its lot cheaper to
leverage existing mechanisms.

The extra hops that FANTOM requires in the enterprise is insignificant in
latency and bandwidth particularly in a switched Ethernet configuration.

  [SS] When you've three Proxies in the path each handling signaling and
media for potentially thousands of simultaneous calls, its not obvious to me
how you claim that the performance will not suffer as you scale.

> 3) For SIP services, your AP and PEA both will house a SIP Proxy function,
RTP Proxy function, as well 
> as your control protocol+ RTP/RTCP probes. What is the implication of
putting all these functions in 
> one box from capacity, fault-tolerance and security p.o.v. ? 

Ans: Only the AP has a SIP or H.323 or MGCP (or...) proxy function. Those
who have attended any of my presentations (VON, SIP Summit etc.) will have
deduced that the functions readily break out and can reside on different
processors so that a distributed fault tolerant architecture can be
implemented if required.

  [SS] Its not just splitting the functions. How would you coordinate the
signaling and the media port allocation? Are you talking about a
multiprocessor implementation? Also if you split the functions in different
boxes, you now need 5 boxes for setting up an end to end call (when both
users are behind NAT). 

 > For example, the AP will be doing refreshes for all NAT binds for all RTP
sessions on behalf of all terminals.   

Ans: Yes FANTOM is tuned to the network infrastructure obviating the need
for applications to know about it. We have designed the FANTOM probe to be
very distinguishable from media making a silicon or efficient software
implementations possible. 

[SS] I question the scalability, fault-tolerance and implementation cost of
this approach. This is too heavy-weight compared to a more distributed
signaling and media approach that we've, that essentially serves the same
purpose. 

> 4) Are you planning on using a standard protocol as this control protocol?
In Sen proposal, we've used 
> an existing device control protocol. The sen proposal essentially needs no
new protocol development. 

Ans: Do you mean between the FANTOM client and the FANTOM server or between
the signalling proxy and the RTP proxy? FANTOM is the control protocol
between client and server. Like you, our philosophy is to use existing
methods where appropriate. But we don't based a solution on having to change
a protocol or terminal behaviour to make it work. That's too hard a sell.

   [SS] Between the FANTOM client and the server. This control protocol
essentially essentially serves the same purpose of the control protocol that
we've between the signaling proxy and the RTP (media) proxy, except for the
RTP probes. An existing device-control protocol can be used here. 

> 5) Your requirement for always allowing traffic from some "well-known"
address/port of PEA to the AP 
> in the private network is a big concern. This is typically NOT done in
traditional enterprise FW. 

Ans: On the contrary it is (a) common practice - that's what well know ports
are for,  ... 

  [SS] Don't agree on this one.

> Such a FW will typically close the pin-hole after sometime, hence the need
for signaling path refreshes 
> using PING or REGISTER) both in our scheme and Jonathan's. 

Ans: This is the reason we mux the signalling with the control channel. It
removes the need to do lots of refreshes for multiple paths. Again FANTOM
takes care of it on behalf of the terminal. 

[SS] But you resort to tunneling, something most of us want to avoid as
stated earlier.

Regards,

Sanjoy

Steve 
  
> Thanks, 
> Sanjoy