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

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

Note that the Sen proposal will be henceforth called MINT (MIdcom-unaware
firewall/Nat Traversal).
 
Comments inline.

-----Original Message-----
From: Steve Davies [mailto:[email-masked]] 
 
<snipped>
 
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. 

 <snipped>

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.  

[SS] Agree on this one as 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  

[SS] The solution is exemplified in the draft with a SIP example. The basic
concept of providing a hint to the Signaling Proxy that the client is behind
a NAT is NOTHING SIP specific. In the example given, the proposed tag in
Proxy-Require header is for providing hint to the Signaling Proxy to route
subsequent messages to NAT address bind. This issue is orthogonal to the
proposal and will be applicable to any application which has similar
requirement. 

That's all we need.

 also requiring bi-directional passive RTP and client and proxy 
behavioral changes that are obsoleted by Midcom.  

[SS] The fundamental reason why we use symmetric RTP is that it reduces the
number of pinholes/binds that need to be opened/maintained in the FW/NAT. I
don't see why it won't be useful to reduce this number, even if Midcom is
present. As I had said in one of the earlier email, this can be done at the
expense of additional overhead - this is equally applicable to all three
proposals.

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

[SS] It actually meets all your requirements:

2)  See above

6) The existing clients are totally unaware of the existence of the Media
Portal or the interactions between the signaling and media proxies to get
the bind.

8) MINT needs the MINIMAL protocol development work among the three
proposals & NO new protocol development. There is a clear evolutionary path
from MINT to Midocom (replace the Media Proxy with a Middlebox!!) 

Goal a : The solution is deployed today. How "more rapid" do you want this
to be ??!!

Goal b: MINT is CLOSEST to Midcom among the 3 proposals. The control
protocol between the signaling & media proxies need to be extended slightly
to satisfy all the requirements currently proposed by the working group.
There is a very clear and efficient evolutionary path from MINT to Midcom.

 <snipped> 

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.

[SS]  Any policy which allows UDP packets from a set of IP address/port
(which are not in response to packets send out to that address) to enter
through a FW is a deviation from standard policy and WILL BE prone to
security attacks. MINT DOES NOT require the media intermediary's IP address
to be pre-specified for the purpose of firewall adminitration, as claimed
above. Another benefit of MINT from the security p.o.v is that the port
binds are allocated at the Intermediary (Media proxy) at the request of the
signaling proxy only (which assumes a trusted relationship between the
signaling proxy and the intermediary, which is what Midcom is driving at).
This again shows the proximity of MINT to Midcom.
 
Sanjoy

---

From: "Paul Francis" <[email-masked]>
Date: Sun, 16 Dec 2001 12:28:02 -0800

RE: [midcom] pre-midcom requirements and goalsI wasn't around Thursday
night, so am wondering what the IAB had to say about pre-midcom stuff?

PF

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

---

From: Melinda Shore <[email-masked]>
Date: Sun, 16 Dec 2001 16:19:07 -0500

>night, so am wondering what the IAB had to say about pre-midcom stuff?

It didn't come up explicitly, but I'd say that there were some
implications for us from the OPES considerations discussion.
You may want to take a look at Sally Floyd's slides from the
session:
http://www.aciri.org/floyd/talks/plenary.Dec13.ps
or
http://www.aciri.org/floyd/talks/plenary.Dec13.pdf

Melinda