Question - What is a VPN?

[TC Wolsey]

I will attempt to comment in-line, although my MUA makes this more difficult than it should be...:-)

>>> Kent Dallas <KDallas at Intelispan.com> 06/04/99 08:14PM >>>

[SNIP]
> control, your privacy still only extends to the weakest point in your
> implementation, but I  believe that assessing your own weaknesses can
> be much less of a chore than assessing those of your provider. 

Kent Dallas writes:
I agree with the "weakest link" argument, but disagree that a typical
customer is better at assessing their security solution than a service
provider SHOULD be.  And for a couple of reasons:

1)  The hardest mistake (or weakness) to find is the one that you have
created.  It is much easier to find fault in someone else's implementation
than your own.
2)  A typical customer is in some business other than information security.
They are not likely to have the on-staff talent necessary to perform a solid
security assessment.  Service providers SHOULD have the on-staff talent of
sufficient caliber to perform a solid security assessment.
3)  A typical customer does not have any past experience in performing such
an assessment.  Service Providers SHOULD have learned from past mistakes,
and can help a typical customer avoid common errors.

________> TC Wolsey
Yes, looking at my post now, I seemed to imply that an entity would be doing the assessment with their own resources. I agree with you regarding what _should_ be the case in terms of service providers, but if an entity can not properly assess their implementation, than how can they properly assess a service providers? The point that I was driving at is that a private entity can disclose all information relevant to the implementation to those folks that are doing the assessment. They may and probably will be non-employees in the case of most enterprises. Is it reasonable to get the same level of disclosure from a service provider? If so, how are the customers of a provider notified if a detail relevant to the implementation changes? How quickly must a provider respond in the event that a new vulnerability is exposed in an implementation that was previously thought secure? My point (I think there is one here someplace) is that outsourcing a VPN may turn out to require more manag!
ement without a significant security benefit. 

I am not steadfastly opposed to outsourced VPNs, I just fear that they will be marketed and implemented in the same fashion as connectivity services. This is reasonable from the providers standpoint, as they are (presumably) in business for profit, but could leave customers in a bad position. There are many metrics to assess the status of your outsourced connectivity (ie call completion, latency, uptime, so on, so on, ...) but not nearly so many to assess the ongoing status of a production VPN. Service providers can also hack solutions that improve protocols or designs that are inherently flawed, thereby improving their performance or extending their useful lifetime. I do not think VPNs can be addressed in this manner - if the design or implementation is flawed, the security suffers, and hacking together fixes is no way to address the problem. 
__________> TC Wolsey

> Three things that I like to see addressed in the privacy
> component of a VPN solution:

> Confidentiality - assurance that the information is not
> exposed to unauthorized parties
> Integrity - assurance that the information is not modified
> in transit b/w authorized parties
> Authentication - assurance that the information actually originated
> from authorized parties

Kent Dallas writes:
As I wrote in an earlier message on a different thread, "VPNs are not a
security solution.  But they can be a part of one."  I would expect each of
those components, plus three more, in any security solution.  But my VPN
does not have to provide all of them.  The other three are:

Access Control - the ability to control access to resources on a selective
basis
Non-reupidation - the sender cannot deny sending and the recipient cannot
deny recieving
Availability - critical systems are resistant to attacks which limit its
ability to perform

__________> TC Wolsey
Is non-repudiation necessary or practical when the VPN solution is deployed only b/w perimeter gateways? I like to see non-repudiation is some security designs, but not necessarily in a VPN solution. Availability is critical, and should have been part of my list. It will be next time :-)
__________> TC Wolsey

Access Control can also be described as Authorization, which was implied as
a requirement in each of the original three components, so perhaps these are
just two more.  And it is not surprising to that they are often omitted -
few VPN solutions address them.

IF your application could guarantee all of the above components, you
wouldn't need to rely on your network to do it.  There is certainly a market
for adding security features to a network - but the market only exists
because the appropriate security mechanisms are not in place where they
should be, IMHO... I agree with the posts of Suzette Szostwoski and Jay
Wack.

> From:	John Fulmer [john.d.fulmer at mail.sprint.com] 
> Sent:	Friday, June 04, 1999 9:27 AM
> Subject:	Re: Question (fwd)

> AFAIK, common terminology is that "Virtual Private Network" implies an
> encrypted, encapsulated conduit (which, granted often may be turned off
> in any given implementation.) and 'tunnel' implies only an encapsulated
> conduit. Or, in other words, a VPN is an encrypted tunnel.

________> TC Wolsey
Crypto and encapsulation do not necessarily have to go together. Schemes where the crypto keys are communicated out-of-band and the encrypted messages do not carry the overhead of encapsulation may be feasible in some cases.
________> TC Wolsey

> Is there something wrong with this definition?

No, as long as you understand that it is your own creation, and not
necessarily shared by everyone else.  I think it would certainly be safe to
state it the other way around: that an encrypted tunnel is a VPN.

If you believe otherwise, you are taking a position that encryption is the
only way to provide privacy (or confidentiality, whichever) - it isn't, and
that tunnels are the only way to provide a virtual network - they aren't.

Regards,
Kent Dallas

****************************************************************
TO POST A MESSAGE on this list, send it to vpn at listserv.secnetgroup.com 

The VPN FAQ (under construction) is available at
http://kubarb.phsx.ukans.edu/~tbird/FAQ.html 

We are currently experiencing "unsubscribe" difficulties.  If you
wish to unsubscribe, please send a message containing the single line
"unsubscribe vpn your-e-mail-address" to owner-vpn at listserv.secnetgroup.com 

****************************************************************

****************************************************************
TO POST A MESSAGE on this list, send it to vpn at listserv.secnetgroup.com

The VPN FAQ (under construction) is available at
http://kubarb.phsx.ukans.edu/~tbird/FAQ.html

We are currently experiencing "unsubscribe" difficulties.  If you
wish to unsubscribe, please send a message containing the single line
"unsubscribe vpn your-e-mail-address" to owner-vpn at listserv.secnetgroup.com

****************************************************************