RE: Comments on draft-fang-ppvpn-security-framework-01

["Paul Knight" <[e-mail]>]

Hi Paul,

Thanks for your suggestions.  (Also thanks to private comments on your
comments, from Michael Behringer.) Below are responses related mostly to
section 4:

> -----Original Message-----
> From: Paul Hoffman / VPNC [mailto:[e-mail]] 
> Sent: Wednesday, July 30, 2003 1:53 PM
> To: [e-mail]
> Subject: Comments on draft-fang-ppvpn-security-framework-01
> 
> 
> [[ l3vpn: These are the comments that I sent to the draft's editor 
> last week. Comments on my comments from this list are of course 
> welcome. --Paul Hoffman ]]
> 
> 
> Section 4. Maybe change the section title to "Defensive Techniques 
> for Service Providers". This makes it clearer that the users are not 
> expected to use any of these techniques in order to make the VPN 
> secure.

Yes, I think that fits.
> 
> Section 4.1, last paragraph. I believe that this paragraph should be 
> removed because if the end user has any control over the keys, it is 
> no longer provider-provisioned: the VPN has mixed provisioning and 
> the security of the VPN becomes much less clear. This might be 
> controversial, so you might even want to take it to the mailing 
> lists. To me, an IPsec VPN where the ISP controls the IPsec devices 
> but the user can mess things up by using weak keys is just a bad idea.

It might simplify things to take the paragraph out, but the intersection of
the provider and user security domains is a key point of the framework, and
I think it needs to be addressed.

The concern is not really about weak keys or weak encryption with IPsec now.
With most implementations, it's pretty straightforward to correctly
configure the type of encryption, and the keys are essentially known only to
the IPsec devices unless someone with management access extracts them. The
issue being considered is not keying or encryption themselves, but access to
the keys and/or ultimately to the unencrypted data. Why even bother with
keys when a rogue provider can configure the device to send data in the
clear?

Is there a model for managing the CE which can give the user some confidence
that the data is secure from the provider (and others), while leaving most
of the CE device provisioning in the hands of the provider? 

I think there is.  An imperfect analogy is a real-estate agent's lock-box,
which holds a key to the door of a home being offered for sale. The
homeowner can see when the key is out of the lock-box and being used to open
the house, and when the key is itself locked up. 

I'll definitely revise the existing text, however. It's obviously not clear
enough.

At this point, I am rewriting (and expanding) the last paragraph of 4.1. The
current version:
*****
The trust model among the PPVPN user, the PPVPN provider, and other parts of
the network is a key element in determining the applicability of encryption
for any specific PPVPN implementation. In particular, it determines where
encryption should be applied:
- If the data path between the user's site and the provider's PE is not
trusted, then encryption may be used on the PE-CE link. 
- If the backbone network is not trusted, particularly in implementations
where traffic may travel across the Internet or multiple provider networks,
then the PE-PE traffic may encrypted. 
- If the PPVPN user does not trust any zone outside of its premises, it may
require end-to-end or CE-CE encryption service. This service fits within the
scope of this PPVPN security framework when the CE is provisioned by the
PPVPN provider.

Although CE-CE encryption provides privacy against third-party interception,
if the PPVPN provider has complete management control over the CE
(encryption) devices, then it may be possible for the provider to gain
access to the user's VPN traffic or internal network. Encryption devices can
potentially be configured to use null encryption, bypass encryption
processing altogether, or provide some means of sniffing or diverting
unencrypted traffic. Thus a PPVPN implementation using CE-CE encryption
needs to consider the trust relationship between the PPVPN user and
provider. PPVPN users and providers may wish to negotiate a service level
agreement (SLA) for CE-CE encryption which will provide an acceptable
demarcation of responsibilities for management of encryption on the CE
devices. The demarcation may also be affected by the capabilities of the CE
devices. For example, the CE might support some partitioning of management,
a configuration lock-down ability, or allow both parties to verify the
configuration. 

> 
> Section 4.1.2, first paragraph. I think IPsec for management of the 
> devices is incredibly rare. Maybe remove the second sentence, and add 
> a bullet at the bottom of the list that says "- IPsec is sometimes 
> used, but much less often than TLS."
> 
Yes, IPsec is mostly used just for in-band management of IPsec devices.  It
will be just one of the options listed.
[...]
> I hope this helps!

Yes, thanks!
> 
> --Paul Hoffman, Director
> --VPN Consortium
> 
Regards,
Paul Knight
 
IP-VPN Standards Advisor, Nortel Networks 
Advanced Technology - Strategic Protocols & Standards
[phone]       ESN 248-6414 

"With sufficient thrust, pigs fly just fine. However, this is not
necessarily a good idea."  - RFC 1925