Subject: [midcom] pre-midcom solutions != VPN

From: Barry Scott <[email-masked]>
Date: Tue, 20 Nov 2001 17:27:25 -0000

We see VPNs as different from the technology that pre-midcom solutions will
require. 

Pre-midcom goal: the pre-midcom solution allows users in a private network
to use voice and video IP terminals to communicate with users outside their
private network. It has to allow private to public network transition
without compromising security.

VPN goal: a VPN allows users at remote locations to use resources within a
private network as if they are locally connected. The VPN extends the
boundary of the private network to that remote location, but it remains a
private network. Tunneling happens to be the technique used to make that
extension. No crossing of the boundary from the private network to the
public network occurs. VPN technology often incorporates firewall technology
to ensure the private boundary remains protected through the extension to
the remote location. 

A VPN is a good choice when you wish to allow a trusted remote user or
remote site to be added to your network from outside. Examples: a home
worker, a branch office.

There may be superficial similarities between VPN and pre-midcom technology,
but fundamentally the functionality is diametrically opposed.

	BArry

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

---

From: "Saqib Jang" <[email-masked]>
Date: Tue, 20 Nov 2001 10:16:20 -0800

IPsec is a IETF standard protocol that can and is being used
to create secure communication channels between protected enterprise
networks and public networks for specific (e.g. voice, video, storage)
or all protocols, which is clearly the goal behind pre-midcom
work (i.e. how can media protocols securely traverse
private/public network boundries of existing networks). IPsec
end-points support crypto-based authentication and optional
encryption allowing for the security of the IPsec-based channels
to be beyond the capabilities of the proposed drafts.

While IPsec has been used for site-to-site and remote access
VPN deployment, its use is not limited to VPNs. For example,
IP storage folks view IPsec as a critical enabler for use of iSCSI
over metro or long-haul networks.

I'm not convinced that that there are clear-cut technical advantages
of the proposed drafts over tunnel-mode IPsec. Plus, IPR issues are
another reason why it would be preferable to look to an existing standard.

Saqib

Saqib Jang
Margalla Communications, Inc.
3301 El Camino Real, Suite 220
Atherton, CA 94027
Ph: 650 298 8462
Fax: 650 368 8198
www.margallacomm.com

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Barry Scott
Sent: Tuesday, November 20, 2001 9:27 AM
To: [email-masked]
Subject: [midcom] pre-midcom solutions != VPN

	BArry

---

From: Kuniaki Kondo <[email-masked]>
Date: Wed, 21 Nov 2001 14:02:11 +0900

Hi,

> but fundamentally the functionality is diametrically opposed.

 I agree with you.
 VPN solution might need for enterprise user or some branch office.
 However, I think that VPN solution is very complex solution for end-users
 such as home user.
 
 I think that end-user needs more simple solution. For example, 
 end-user want to communicate between private network to private network
 without changing applications or OSes.
 (Private network means that hosts are placed the network behind NAT.)
 And, End users need a solution as soon as possible, I think.

 I mean that enterprise user and home user(end-user) have different requirements
 for communicating through NATs/FWs.
 Do we consider to separate those situation?

--
Kuniaki Kondo
[email-masked]