Subject: RE: [midcom] pre-midcom candidates

From: "James Ho" <[email-masked]>
Date: Fri, 02 Nov 2001 12:08:40 -0800

Two points. First, other then performance/latency issues
(which I'd like to learn more about), I can't understand
what is different about protocols targeted by midcom vs.
protocols that have been and are securely supported by IPsec
for firewall traversal. The whole pt of having standards
such as Ipsec is that ITs confidence in allowing such protocols
to be securely used is enhanced due to their standard status. I'm not
sure defining new standards and/or proliferation of new
protocols (especially for the focused purpose of firewall traversal
of a specific set of media protocols) is going to enhance IT confidence
or making security policy-setting easier.

Finally, regarding performance, as I said earlier, the IP
storage folks have standardized on IPsec as a mandatory
component for authentication and integrity checking for iSCSI,
FCIP, and iFCP protocols. These protocols have very stringent
*round-trip* latency requirements, so it would behoove this
group to carefully look at if the performance requirements of
H.323/SIP are significantly different so as to justify
standardizing on a new protocol.

james

>From: Jonathan Rosenberg <[email-masked]>
>To: "[email-masked]'" <[email-masked]>,   
>"'James Ho'" <[email-masked]>, [email-masked],   
>[email-masked], [email-masked]
>Subject: RE: [midcom] pre-midcom candidates
>Date: Fri, 2 Nov 2001 02:35:21 -0500
>
>
>
>
>
> > -----Original Message-----
> > From: Christopher A. Martin [mailto:[email-masked]]
> > Sent: Thursday, November 01, 2001 1:46 PM
> > To: 'James Ho'; [email-masked]; [email-masked];
> > [email-masked]
> > Subject: RE: [midcom] pre-midcom candidates
> >
> >
> > This would work well for an isolated network (intranet or
> > extranet) but when
> > it is desired to allow anyone (Internet) access it would be
> > infeasible to
> > provide security associations to the world
>
>Well, one need not do it to the world. Presumably, the VoIP provider would
>offer this service to its customers. Then, it only need worry about 
>offering
>ip addresses to the customers it has actively online.
>
>
> > Also, IPSec doesnt provide security policy enforcement, as a firewall
> > typically would on non-IPSec encapsulated packets, merely
> > privacy. When you
> > tunnel IPSec through a firewall from endpoints, unless the security
> > associations are setup to be granular, the firewall cannot act on the
> > packets inside the tunnel.
>
>No, they can't. Thats why it works. But thats also the problem shared by 
>all
>the vpn and tunneling solutions; they ultimately work since they help 
>bypass
>enterprise firewall policies that might exist.
>
>Stun doesn't do tunneling; if the firewall disallows outbound UDP then you
>can't send outbound UDP. It therefore insures that enterprise firewall
>policy continues to be obeyed.
>
> > Also not all firewalls allow IPSec (IP 50 and 51) the ability to pass
> > through them.
>
>Pick your favorite vpn. Others get through and work. My favorite remains
>RFC3093, which will traverse almost all firewalls and nats.
>
>-Jonathan R.
>
>---
>Jonathan D. Rosenberg, Ph.D.                72 Eagle Rock Ave.
>Chief Scientist                             First Floor
>dynamicsoft                                 East Hanover, NJ 07936
>[email-masked]                     FAX:   (973) 952-5050
>http://www.jdrosen.net                      PHONE: (973) 952-5000
>http://www.dynamicsoft.com
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

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

---

From: Melinda Shore <[email-masked]>
Date: Fri, 02 Nov 2001 15:38:25 -0500

At 12:08 PM 11/2/01 -0800, James Ho wrote:
>The whole pt of having standards

If we must have this discussion (and I'd really rather we
didn't - the working group was chartered some time ago under
considerable scrutiny and we've nearly finished our work), we
should start with the understanding that nobody is saying "never
tunnel" and that we're not trying to supplant mechanisms that
work.  Midcom is a response to well-understood situations in which
tunneling will *not* work or will work badly.

Melinda