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

From: Mark Duffy <[email-masked]>
Date: Tue, 12 Aug 2003 13:04:37 -0400

Hi Paul and thank you for all your comments.
I am responding here only to the comments on sect. 8.
Thanks, Mark

At 10:53 AM 7/30/2003 -0700, Paul Hoffman / VPNC wrote:
>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.

done

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

The reference here is to confidentiality protection in the sense of keeping 
the data secret.  Although I find it hard to conceive of anyone providing 
this in a PPVPN through a means other than cryptography, I think it is 
improper to dictate the means here.  I will clarify the service this is 
calling for.  This item is implicitly linked to the confidentiality 
requirement stated in sect. 6.3 (which currently calls for cryptographic 
means, but we have been asked to change that because, likewise, the means 
to the end should not be part of the requirement).

---

From: Mark Duffy <[email-masked]>
Date: Tue, 12 Aug 2003 23:37:39 -0400

Hi Paul, and thanks.  Here are responses to your comments on sect. 3.
--Mark

At 10:53 AM 7/30/2003 -0700, Paul Hoffman / VPNC wrote:
>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".

ok

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

ok.  although i still make no claim that the list is ordered by likelihood.

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

I reworded this slightly but I stick by the original point.  I think it is 
one thing (actually, a DOS attack) to inject packets that will be forwarded 
to their destination and then dropped, and another to inject packets 
containing bogus data and having them be taken for legitimate by the 
receiver.  I'm not sure what you mean by "In a PPVPN, all packets are 
always considered to be legitimate." unless you are referring to any system 
without data origin authentication or data integrity protection, that just 
accepts all data received.

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

I split apart observation, modification, deletion, etc, and also removed 
the statement about where they might occur.  (Several other people made 
similar comments.)

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

removed.

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Wed, 13 Aug 2003 08:49:25 -0700

At 11:37 PM -0400 8/12/03, Mark Duffy wrote:
>>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.
>
>I reworded this slightly but I stick by the original point.  I think 
>it is one thing (actually, a DOS attack) to inject packets that will 
>be forwarded to their destination and then dropped, and another to 
>inject packets containing bogus data and having them be taken for 
>legitimate by the receiver.  I'm not sure what you mean by "In a 
>PPVPN, all packets are always considered to be legitimate." unless 
>you are referring to any system without data origin authentication 
>or data integrity protection, that just accepts all data received.

That's *exactly* what I am referring to, and it is an important 
property of any VPN. If a VPN customer wasn't using internal 
firewalls (as compared to a firewall at the border to the Internet), 
using a VPN should not make them think that they might need them now. 
It is the responsibility of the VPN to only pass traffic that would 
have been passed if this had been a real local network.

--Paul Hoffman, Director
--VPN Consortium

---

From: Mark Duffy <[email-masked]>
Date: Fri, 15 Aug 2003 13:32:14 -0400

At 08:49 AM 8/13/2003 -0700, Paul Hoffman / VPNC wrote:
>>>considered to be legitimate. I would remove it to make the first 
>>>sentence shorter and more to the point.
>>
>>I reworded this slightly but I stick by the original point.  I think it 
>>is one thing (actually, a DOS attack) to inject packets that will be 
>>forwarded to their destination and then dropped, and another to inject 
>>packets containing bogus data and having them be taken for legitimate by 
>>the receiver.  I'm not sure what you mean by "In a PPVPN, all packets are 
>>always considered to be legitimate." unless you are referring to any 
>>system without data origin authentication or data integrity protection, 
>>that just accepts all data received.
>
>That's *exactly* what I am referring to, and it is an important property 
>of any VPN. If a VPN customer wasn't using internal firewalls (as compared 
>to a firewall at the border to the Internet), using a VPN should not make 
>them think that they might need them now. It is the responsibility of the 
>VPN to only pass traffic that would have been passed if this had been a 
>real local network.
>
>--Paul Hoffman, Director
>--VPN Consortium

OK, I believe I understand your point -- that the PPVPN service should 
protect against this spoofing.  And I agree.  Bear in mind though that this 
is *not* the section of the document that says what PPVPNs should 
do/offer.  This *is* the section that explains potential threats.  From 
that perspective, do you feel the following text is inappropriate?

Insertion of Non-Authentic Data Traffic ... This refers to the insertion 
(or "spoofing") into the VPN of packets that do not belong there, with the 
objective of having them accepted by the recipient as legitimate.

Thanks, Mark

---

From: Paul Hoffman / VPNC <[email-masked]>
Date: Fri, 15 Aug 2003 10:56:09 -0700

At 1:32 PM -0400 8/15/03, Mark Duffy wrote:
>>>I reworded this slightly but I stick by the original point.  I 
>>>think it is one thing (actually, a DOS attack) to inject packets 
>>>that will be forwarded to their destination and then dropped, and 
>>>another to inject packets containing bogus data and having them be 
>>>taken for legitimate by the receiver.  I'm not sure what you mean 
>>>by "In a PPVPN, all packets are always considered to be 
>>>legitimate." unless you are referring to any system without data 
>>>origin authentication or data integrity protection, that just 
>>firewalls (as compared to a firewall at the border to the 
>>Internet), using a VPN should not make them think that they might 
>>need them now. It is the responsibility of the VPN to only pass 
>>traffic that would have been passed if this had been a real local 
>>network.
>>
>>--Paul Hoffman, Director
>>--VPN Consortium
>
>OK, I believe I understand your point -- that the PPVPN service 
>should protect against this spoofing.  And I agree.  Bear in mind 
>though that this is *not* the section of the document that says what 
>PPVPNs should do/offer.  This *is* the section that explains 
>potential threats.  From that perspective, do you feel the following 
>text is inappropriate?
>
>Insertion of Non-Authentic Data Traffic ... This refers to the 
>insertion (or "spoofing") into the VPN of packets that do not belong 
>there, with the objective of having them accepted by the recipient 
>as legitimate.

Ah, I see the disconnect. Yup, that is fine.

--Paul Hoffman, Director
--VPN Consortium