Subject: RE: WG Focus Item - draft-fang-ppvpn-security-framework-01.txt

From: "Eric W Gray" <[email-masked]>
Date: Fri, 1 Aug 2003 17:59:54 -0400

Draft Authors,

Overall, the draft provides lots of useful information, is 
well written and easy to read. I have some specific comments
and questions.

Introduction, second paragraph: in the statement "We consider 
   security issues deriving both from malicious behavior of 
   users and other parties and from negligent or incorrect 
   behavior of the providers", I assume it is not the intent
   to exclude from consideration any security issues that
   derive from negligent or incorrect behavior on the part of
   users and other parties - is that correct? Or is it implied
   that such user behavior either falls into the category of 
   "negligent or incorrect behavior of the providers" (if it
   is allowed to introduce a security issue) or out of scope
   (because it's what the user does to themselves)?

Introduction, third paragraph, last sentence: there is a part 
   of this that is redundant over the previous sentence - i.e.
   "make it secure so it can provide the PPVPN services." I
   think a separate provider requirement to protect their 
   network such that they can provide services in addition to 
   PPVPN.

Security Reference Model, second paragraph: a PPVPN service 
   over the Internet seems a non-sequitur except to the extent 
   that a provider is able to provision the Internet (the PP
   part of PPVPN). It seems to me that what is addressed here 
   is a set of zero or more PPVPN services connected by a VPN 
   service and I assume that VPN security in general is out of 
   scope in this document.

Security Reference Model, fifth paragraph: the discussion of 
   extranets seems to imply the need for tiered trust models
   instead of a simplistic trusted or not trusted model. At 
   the very least it is clear that different definitions may
   apply to what it means to be "trusted".

Security Reference Model, last paragraph: we may want to at
   least include the analysis for attacks from the Internet 
   to a server of a given PPVPN user that we use to conclude
   that provisioning methods cannot affect exposure.

Middle of page 6, second set of bullets (especially the 4th
   and 5th bullets) and following paragraph: these seem to
   imply a distinct separation of VPNs and the Internet. 
   Most VPNs would be connected to the Internet (either as
   part of the PPVPN service, or via another means) and a
   compromise of any VPN could make possible any compromise 
   from the Internet that would be possible from that VPN.
   In the case where Internet access is not via the same 
   PPVPN provider, avoidance of compromise from the Internet
   via the VPN itself is not within the purview of the PPVPN
   provider and - therefore - may not be a separable threat.
   This may be a problem in the first paragraph in section 
   4.5 on page 18 as well ("even if VPN services make use 
   of a separate network from Internet services"). A seeming
   separation of VPN and Internet services from the service
   provider's perspective may not actually exist.

Last few paragraphs on page 6: it would be clearer to use 
   "attacks" rather than "threats" with respect to occurrence
   and ease of mounting.

Attacks on the Data Plane, several points: 

   The specific classifications used lead to ambiguities 
   which may complicate the process of picking a solution. 
   For example, replay should involve both unauthorized 
   observation and insertion of illegitimate data traffic 
   (replay may actually involve authentic data - in so far 
   as authenticity can be determined using some forms of 
   authentication - even if replay traffic is illegitimate). 

   Unauthorized observation, modification and deletion are
   fundamentally different forms of attack, possibly making
   the grouping of them ambiguous.  

   We probably want to recognize that several of these attacks
   stem from unauthorized observation (modification does, but
   deletion may not, traffic pattern analysis is an attack
   only if it derives from unauthorized observation, replay
   can only occur if observation - presumably unauthorized -
   can occur, etc.).

   Impersonation is not necessarily an attack against the 
   data plane.

Attacks on the Control Plane: cross-connection of traffic
   between PPVPNs is not an attack against the control plane
   as much as it is a failure of the control plane (if you
   extend the concept to potentially include the operator)
   and an attack against the data plane (a combination of
   unauthorized observation and insertion of illegitimate
   traffic). A possible exception might be for any network
   element whose control plane may be tied up in attempting
   to correct the cross-connection - which seems unlikely
   to be a common case.

Attacks on Address Space Separation: it is not clear what
   is meant here. Clearly addresses may exist independently
   in more than one VPN (this is what is referred to as 
   Address Separation in section 6.1.1), so what is address 
   space in this context?

Defensive Techniques: in addition to discussion of inherent
   limitations of defense in general, it would help if this
   section also included at least a list of the techniques
   that would be discussed in its subsections - possibly 
   including a brief description of each technique.  This
   would be helpful, for example, when "other defensive
   techniques" are mentioned in "Cryptographic Techniques".

Cryptographic techniques - several points:

   What cryptographic techniques are referred to in this 
   section other than encryption (and - by implication -
   decryption)?  Is traffic separation considered a
   cryptographic technique? Is authentication? Perhaps 
   the section should be called "Encryption"?

   Yes, privacy is important in a VPN, but the very term
   VPN over-loads the meaning of privacy to include more
   than avoidance of unauthorized observation and noise. 
   Private, in the VPN sense also implies a perception of 
   some amount of being "alone" (in terms of availability
   of service).  This is implied in the list of threats
   that apply to a PPVPN service (which includes DoS as
   distinct from DoS applied to non-VPN services). Hence, 
   traffic separation and encryption are insufficient to 
   ensure privacy. Authentication may help but appears to
   be excluded as a cryptographic technique that might be
   used to secure privacy.

   I disagree with the conclusion of the paragraph at the
   top of page 11 - largely because of the first sentence
   in the very next paragraph. For trust reasons mentioned
   in the next paragraph, a user wishing to use encryption 
   to avoid unauthorized observation of their traffic is 
   unlikely to want it to be done by someone else, at that
   someone else's discretion and subject to that someone
   else's policies and regulatory restrictions. This will
   be true irrespective of some intrinsic value of the
   encryption service or any perceived ease with which a 
   service may be able to provide encryption as a feature. 
   Hence the ability of encryption to reduce exposure to
   certain threats is unlikely to directly motivate making 
   encryption a common service offering in PPVPN.  It seems
   more likely that a user who wants to employ encryption
   will do so themselves (using mechanisms under their own
   administrative control) and a user who does not will not
   necessarily be willing to pay for it even if it is done 
   by someone else, for relatively low cost.

Authentication: in this section (4.2), authentication is
   listed as a cryptographic technique yet authentication 
   receives minimal attention in the section addressing
   cryptographic techniques (4.1).  Perhaps a forward 
   reference might be made in section 4.1?

Cryptographic techniques for authenticating identity: the
   statement "Digital certificates using a hierarchical 
   Certificate Authority system are among the most useful 
   systems, but they require significant investment in 
   infrastructure, and have not been universally deployed"
   seems to contain at least one subjective valuation that
   does not add much to the document. Perhaps it should be
   replaced by a statement similar to the following -

   "Another approach is to use a hierarchical Certificate 
   Authority system to provide digital certificates."

Integrity (section 6.5): the user requirement here is - 
   "Data in transit must be secured such that it cannot 
   be altered." Cryptography may be one approach for
   meeting this requirement.

Anti-Replay (section 6.6): the user requirement here is - 
   "Data in transit must be secured such that it cannot 
   be recorded and replayed later." Cryptography may be 
   one approach for meeting this requirement.

Evaluating the Template (section 8.1): I do not understand
   the statement "In the VPN approach, the requirement is 
   addressed in a way that is beyond the scope of the VPN 
   approach." It seems to me that "addressed" and "out of
   scope" are mutually exclusive concepts.

Template (section 8.2): 1 and 2 might be clearer if they 
   were worded as -

"  1. The approach provides complete IP address separation 
      for each L3 VPN.
    
"  2. The approach provides complete L2 address separation 
      for each L2 VPN.

"  3. The approach provides complete VLAN ID separation 
      for each VPN. 
    
"  4. The approach provides complete IP route separation 
      for each VPN. 
    
"  5. The approach provides complete L2 forwarding
      separation for each VPN."

In particular, 4 and 5 should address what is separated
for each VPN (forwarding) as opposed to how it is separated
(separate tables as opposed to other approaches).

Template (section 9, a and b): should require precise values
(or state that it is operator definable) for "excessive".

Template (section 15): should read something like -

" 15. The approach provides protection against unauthorized
      traffic pattern analysis for PPVPN user data."

---

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

Hi Eric, and think you for your review and comments.  I'm responding here 
only to a few of them.  --Mark

>    scope" are mutually exclusive concepts.

At the time I wrote this I had something specific in mind, and I believe it 
was along the lines of "In the VPN approach, the requirement is addressed 
by some other mechanism that is always used together with the VPN 
approach."  That said, unless I remember the specific issue, I'll remove 
the text.

>       separation for each VPN."

agreed

>(or state that it is operator definable) for "excessive".

The point here was that the approach should provide protection against "too 
much" routing or management traffic, for any value of too much from "just a 
wee bit too much" to "arbitrarily much".  I will try to make the wording 
more clear.

>       traffic pattern analysis for PPVPN user data."

ok, I'll add the word "unauthorized".

---

From: "Eric W Gray" <[email-masked]>
Date: Tue, 12 Aug 2003 15:38:12 -0400

Mark,

	As long as "more clear" means more something that
can be determined (or measured) in some meaningful way,
that's fine.  Otherwise, I have to wonder what it means
to assign a rating (as defined in section 8.1) to these 
two items. 

--
Eric 

> ...
> ...

---

From: Mark Duffy <[email-masked]>
Date: Wed, 13 Aug 2003 13:29:40 -0400

Thanks Eric,
I've responded below to the comments re section 3, Security Threats.
--Mark

>    provider's perspective may not actually exist.

Agreed that there may be connectivity between a PPVPN and the 
Internet.  However, to the extent that attacks mounted from the Internet 
would be the same for a PPVPN as for an actual private network, they are 
out of scope for this doc.  We are addressing only the threats that arise 
because of the "PPVP" part -- provider provisioned and virtually private.

Also, whether a PPVPN is connected to the Internet or not, the avenues open 
to attacking it by another PPVPN user of the same SP will be a superset of 
the avenues open to persons on the Internet at large, so I think it is 
still a useful distinction to make.  As for an attacker from the Internet 
compromising  one VPN and therefore gaining an advantaged position to 
attack the other PPVPNs of the same SP, well that might or might not be the 
case.  "Compromising" a network is not necessarily equal to "having all the 
privileges of a legitimate user" of the network.  And in the case where 
they do compromise one PPVPN via another, they would have had to first 
surmount the  hurdle of greater or equal height, that of compromising the 
first PPVPN from the Internet.

So I'm not sure if that addresses your comment or not.  Were you suggesting 
a change in the text?  Given the explanation above, are you still?

>    "attacks" rather than "threats" with respect to occurrence

done.  (FWIW, I would consider the possibility of an "attack" occurring to 
be a "threat".)

>    can only occur if observation - presumably unauthorized -

I have split the observation, modification, deletion, insertion from each 
other, and indicated some relationships between them.

>    Impersonation is not necessarily an attack against the

The impersonation section has been removed, "by popular demand" :-)

>    to correct the cross-connection - which seems unlikely

I have clarified that cross-connection may be caused by malice or by error 
(i.e. by the operator).  I agree that this *affects* the data plane (many 
control plane attacks will) but with the document being organized as it is 
I need to categorize this as an attack on the control plane or an attack on 
the data plane.  I believe it is more correct to place this in the first 
category.

>    Address Separation in section 6.1.1), so what is address

This is talking about the same concept of address space separation.  6.1.1 
presents the requirement for that separation.  Here, it is pointing out 
that there is a threat of that separation being breached.  I will clarify 
the wording.

Thanks, Mark

---

From: "Eric W Gray" <[email-masked]>
Date: Fri, 15 Aug 2003 09:53:00 -0400

Mark,

	See below...

--
Eric

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Mark
> Duffy
> Sent: Wednesday, August 13, 2003 1:30 PM
> To: Eric W Gray; [email-masked]
> Subject: RE: WG Focus Item -
draft-fang-ppvpn-security-framework-01.txt
> a change in the text?  Given the explanation above, are you still?

With these clarifications, I understand your meaning well enough
from the existing text.  Yes, this does address my comment.

> the data plane.  I believe it is more correct to place this in the
first

I understand that the "possibility of" cross connection of
traffic between PPVPNs is a threat that exists within the
control plane, and if such an attack is carried out it will
subsequently affect the data plane.

However, a literal cross-connect between PPVPNs may exist
outside of the influence of the control plane and such a
cross-connect - once extant - is an attack against the
data plane.  I now understand that this is not the threat
that you're trying to identify (largely because you've
separately identified the constituents of such a threat
to the data plane), but this is not clear in your current 
text - even knowing what you most likely meant to say.

Your modified text may make this much clearer.

---

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

Eric, I agree that it does not make sense to respond to that item (or the 
preceding one) in the template using the specified yes/no/partial/etc. 
ratings.  I think a good solution is to pose those items as questions that 
require a narrative answer rather than the yes/no/partial/etc.

Mark

---

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

At 09:53 AM 8/15/2003 -0400, Eric W Gray wrote:
...
>Your modified text may make this much clearer.

Actually, I don't think it does.  Are you talking about a cross-connection 
that happens in the data plane *without* the control plane causing it?  I 
imagine that could happen e.g. by someone modifying mpls labels or GRE 
tunnel headers or the like on packets in flight.  Is that what you have in 
mind?  But even that I would argue is an attack on the control plane 
(viewing tunnels implementing the PPVPN as control plane 
constructs).   Even if you view that as a data plane attack I think that 
would be considered a case of "modification of data traffic" which we 
already cover as a data plane attack.  (Perhaps that's what you mean by 
saying I've identified the constituents of such a threat...)
Mark