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

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 30 Jul 2003 10:53:17 -0700

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

Hi again. As we discussed, here are my comments. Overall, I'm very 
excited about the document and am glad you have put so much time into 
it.

Overall: There are some non-ASCII characters in different parts of 
the document. You need to do a sweep to catch them all.

Title page: The RFC Editor has a rule against listing more than five 
authors. I suggest that only you be listed as the editor, and that 
you add an author's list section before the conventions section.

Section 2, second paragraph. The second sentence talks about "one or 
more PPVPN service providers" but inter-AS issues are not discussed 
in the document. There is a whole new category of security issues 
with inter-AS VPNs, such as competitive attacks, QoS failures at the 
inter-AS boundary, and general finger-pointing. You can either add a 
new section, or simply change this sentence to say "...control of a a 
PPVPN service provider".

Section 3, second list. "Persons within an organization that is a 
separate PPVPN of the same service provider" is unclear. I suggest 
changing it to "Users of a different PPVPN that is managed by the 
same PPVPN service provider". Also, I think that this is what most 
users consider to be the most likely source of attack; you might 
consider moving this item to the top of the list.

Section 3.1.1. The phrase "with the objective of having them accepted 
as legitimate" is a bit misleading here. In a PPVPN, all packets are 
always considered to be legitimate. I would remove it to make the 
first sentence shorter and more to the point.

Section 3.1.3. Modification and deletion of traffic is quite 
different that observation. I suggest grouping insertion, 
modification, and deletion in one section, and cover observation in a 
different section. Also, I think you should remove the second 
sentence; there is very little good evidence about where observation 
happens.

Section 3.1.5. This section should be removed; it is no different 
than the combination of insertion and observation (and sometimes 
observation isn't even needed).

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.

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.

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

Section 6.1.1, first paragraph. The second sentence makes it sound 
like it is OK to use a NAT to achieve address separation. That's 
technically true, but it wipes out many of the basic features of the 
protected network. I suggest simply removing that sentence, since it 
is unrelated to the correct way of creating VPNs.

Section 6.7. Non-repudiation is rat-hole. It inherently relies on 
legal and social definitions, not technical ones. I cannot imagine 
how non-repudiation could be asserted in a VPN, since the entire VPN 
is a single administrative entity. You should probably just remove 
this section.

Section 7.1.1, first paragraph. I thought that TCP MD5 could only be 
used as an integrity check, not for authentication. That is, it only 
verifies that the packet was not accidentally changed in transit, not 
authenticating its source or preventing an attacker from replacing 
the whole packet with a new MD5.

Section 7.2, first paragraph. Same issue as in section 7.1.1 with 
respect to BCP MD5.

Section 8.2, step 8. Remove the "[Editor's note..."; otherwise, 
everyone will just repeat it in their document. You have made it 
clear that non-VPN DoS attacks are out of scope.

Section 8.2, step 11. It is not clear what kind of confidentiality 
you are referring to. I suggest changing this to "The approach 
provides cryptographic confidentiality protection...".

I hope this helps!

--Paul Hoffman, Director
--VPN Consortium