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

From: Steve Davies <[email-masked]>
Date: Tue, 20 Nov 2001 18:38:03 -0000

Of course tunnels can be used between trusted parties. But a
pre-midcom/midcom solution must support open communications - the ability
for anyone to call anyone else. VPN technology or tunnel-mode IPSEC (they're
equivalent in this context) cannot be used to construct a pre-midcom/midcom
solution. Any attempt will leave gaping holes in the private/public network
boundary. Plugging the hole requires firewalls and NATs that require a
pre-midcom/midcom solution - catch-22! 

The catch goes something like this:

To use VPN technology for inter-enterprise communication, a service provider
or communications broker would be required to connect to every VPN. An
application-aware NAT function is required that can map all private IP
addresses to unique IP addresses in a shared address space, otherwise
inter-enterprise calls will fail. This requires a signalling proxy to NAT
the signalling, and an RTP Proxy to NAT the media.  For security reasons,
the service provider or enterprise must also provide a firewall on every VPN
to prevent malicious attacks and unauthorized access from other enterprises
or from the public network. These firewalls will have the same problems as
enterprise firewalls that wish to allow through voice over IP protocols,
without allowing through other undesired protocols.

Which brings us back to the firewall/NAT problem and the need for
pre-midcom/midcom solution! 

Steve

-----Original Message-----
From: Saqib Jang [mailto:[email-masked]]
Sent: 20 November 2001 18:16
To: Barry Scott; [email-masked]
Subject: RE: [midcom] pre-midcom solutions != VPN

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

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

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

---

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

RE: [midcom] pre-midcom solutions != VPNThe focus of the thread is on
pre-midcom work (i.e. secure
media traversal of *existing* firewalls/NATs that may or may not
have media intelligence) not on the midcom framework, so I think
it would be helpful to not lump both aspects together.

1. Implementing IPsec across firewalls should not/does not leave 'gaping
holes' within firewalls. From my standpoint, implement a tunnelling
protocol  that is a widespread standard and one that has strong
security capabilities makes for much more simplified enterprise security
policy management.

2. I don't see a problem with providers having the choice of deploying
application-aware firewall and NAT services within the 'cloud'. Is
it a pre-midcom goal to prevent SPs from from doing this? As I
understood it, the goal of the pre-midcom work was to remove the
compatibility issues that installed *enterprise* firewalls have with media
protocols.

Saqib

  -----Original Message-----
  From: [email-masked] [mailto:[email-masked]]On Behalf Of
Steve Davies
  Sent: Tuesday, November 20, 2001 10:38 AM
  To: [email-masked]'; [email-masked]
  Cc: Barry Scott
  Subject: RE: [midcom] pre-midcom solutions != VPN

  To use VPN technology for inter-enterprise communication, a service
provider or communications broker would be required to connect to every VPN.
An application-aware NAT function is required that can map all private IP
addresses to unique IP addresses in a shared address space, otherwise
inter-enterprise calls will fail. This requires a signalling proxy to NAT
the signalling, and an RTP Proxy to NAT the media.  For security reasons,
the service provider or enterprise must also provide a firewall on every VPN
to prevent malicious attacks and unauthorized access from other enterprises
or from the public network. These firewalls will have the same problems as
enterprise firewalls that wish to allow through voice over IP protocols,
without allowing through other undesired protocols.

  Steve

  -----Original Message-----
  From: Saqib Jang [mailto:[email-masked]]
  Sent: 20 November 2001 18:16
  To: Barry Scott; [email-masked]
  Subject: RE: [midcom] pre-midcom solutions != VPN

  Saqib

  Saqib Jang

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

  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.

  public network occurs. VPN technology often incorporates firewall
technology

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

          BArry