Subject: Re: draft-fang-ppvpn-security-framework-01.txt

From: "Michael H. Behringer" <[email-masked]>
Date: Fri, 08 Aug 2003 21:10:28 +0200

At 19:00 30/07/2003, Stewart Bryant wrote:
>[...]

>2. Security Reference Model
>
>    Also outside the scope are all aspects of network security which are
>    independent of whether a network is a PPVPN network or a
>    conventional network (for example, attacks from the Internet to a
>    server of a given PPVPN user will not be considered here, unless the
>    way to provision the PPVPN network could make a difference to the
>    security of this server).
>
>SB> This is the first time you use the term server, and I not sure I
>SB> understand what you mean. Presumably you refer to the equipment
>SB> that interfaces the VPN to the VPN core (and hence Internet). In
>SB> which case it is not just the provisioning mechanism that needs
>SB> to be considered.

No, I mean literally a "server", like a web server for example. What I'm 
trying to say is:
- A server can be attacked from the Internet.
   This is independent of whether this enterprise...
   -- has a private network with an Internet gateway, or
   -- has a PPVPN service.

For attack forms where this statement is NOT true, it's the job of the 
draft to highlight this. Where this IS true it's outside the scope.

I'll change the above sentence, I hope that makes it clearer.

>[...]

>6.4.    CE Authentication
>
>    It is not possible for an outsider to install a CE and pretend to
>    belong to a specific PPVPN, to which this CE does not belong in
>    reality.
>
>SB> I think that you need to restate this, to state that authentication
>SB> makes this impossible (well actually just difficult).

Not clear what you mean. The requirement is "authentication", and if this 
is present, the consequence is that "it is not possible ...". Same 
structure as in all other sections?!?? Please clarify...

>6.5.    Integrity
>
>    Data in transit must be cryptographically secured such that it
>    cannot be altered.
>
>6.6.    Anti-Replay
>
>    Data in transit must be cryptographically secured such that it
>    cannot be recorded and replayed later.
>
>SB> You may wish to expand the last two sections a little so that the
>SB> title is not integral to reading the sentence.

Hmmm, I like it short and crisp ;-)  But I'll reword it :-)

Thanks for your comments!
Michael

[rest deleted here]

---

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

Hi Stewart, thanks for your comments!
(I am addressing only a subset of them here.)
--Mark

At 06:00 PM 7/30/2003 +0100, Stewart Bryant wrote:
>3. Security Threats
>
>
>    A successful attack on a particular PPVPN or on a service provider's
>    PPVPN infrastructure would be expected to have effects of the
>    following unhappy sorts:
>  SB> unhappy :( ? I think that the sentence needs rewording?

they wouldn't make you unhappy?  ;-)
ok, i'll reword.

>   In the case of PPVPNs, some parties may be in more advantaged
>    positions that enable them to launch types of attacks not available
>    to others.  For example other PPVPN users of the same service
>SB> s/other PPVPN/PPVPN/

I will reword that to be more clear.

>SB> Also shouldn't it now be l3vpn? Although there is some overlap
>SB> with l2vpn, there are important differences in the vulnerabilities.

Hmm.  I'm not sure.  I'll discuss with my co-authors.  There is some L2VPN 
content in this doc.  Before the wg split it was intended to gover l2 and l3.

>    It is also useful to consider the likelihood of different sorts of
>    threats occurring.  There is at least a perceived difference in the
>    likelihood of most types of attacks being successfully mounted in
>    different environments, such as:
>
>     - In a TDM or ATM access network between a PPVPN user and the
>       service provider
>     - In an Ethernet access network
>SB> I am not sure that there issues are VPN specific, but we will see
>SB> what gets said later.

I agree.  I'll remove these.

>     - In a PPVPN contained within one service provider's network
>     - In a PPVPN transiting the public Internet
>SB> It may be dangerous to differentiate from because this may change
>SB> within the lifetime of a service - assuming PPVPN is succesfull

To the extent that these present different security situations, I think it 
is important that we recognize that and address it.

>3.1.3.  Unauthorized Observation/Modification/Deletion of Data Traffic
>
>    This refers to "sniffing" VPN packets and examining their contents.
>    It also includes modifying the contents of packets in flight, or
>    causing packets in flight to be discarded.  Such attacks would
>    typically occur on links in the network but might also occur in a
>    compromised node of the network.
>SB> I would have thought that modification or deletion was more likely
>SB> in a node.

Several people raised this point.  I will remove that statement.

>SB> Under dataplane you also need to consider DOS on the PE (from either
>SB> inside or outside the VPN) which I do dnot think that you cover.

The DOS sections have been reorganized somewhat.  Yes, this section 
includes attacks on the PE, but the PE is not called out specifically (but 
nor are any other components).

>3.2.    Attacks on the Control Plane
>
>    This category encompasses attacks on the control structures operated
>    by the PPVPN service provider.
>
>3.2.1.  Denial of Service Attacks on the Network Infrastructure
>
>    DOS attacks could be mounted specifically against the mechanisms the
>    service provider uses to provide PPVPNs e.g. IPsec, MPLS, etc., or
>    against the general infrastructure of the service provider e.g. core
>    routers.  (The latter case is within the scope of this document only
>    if the attack happens in relation with the VPN service, otherwise is
>    not a PPVPN-specific issue.)
>
>    Of special concern for PPVPNs is denial of service to one PPVPN user
>    caused by the otherwise-legitimate activities of another PPVPN user.
>    This can occur for example if one PPVPN user's activities are
>    allowed to consume excessive network resources of any sort that are
>    also needed to serve other PPVPN users.
>
>SB> This is a legitimate attack, but I don't think that it belongs under
>SB> control plane sub-heading. It is a dataplane attack.

I would contend that over-consumption of PPVPN resources can be a data 
plane or a control plane threat, depending on the type of resource being 
consumed.  Therefore, there is similar text in both sections.

>3.2.3.  Cross-connection of Traffic Between PPVPNs
>
>    This refers to the event where expected isolation between separate
>    PPVPNs is breached.  This includes cases such as:
>
>     - A site being connected into the "wrong" VPN
>     - Two or more VPNs being improperly merged together
>     - A point-to-point VPN connecting the wrong two points
>     - Any packet or frame being improperly delivered outside the VPN it
>       is sent in.
>
>    Mis-connection or cross-connection of VPNs has a high likelihood of
>    being the result of service provider or equipment vendor error
>    rather than malicious action.
>
>SB> A compomised router could do this.

I have clarified that cross-connection may be caused by malice or by error 
(i.e. by the operator).

>3.2.4.  Attacks Against PPVPN Routing Protocols
>
>    This encompasses attacks against routing protocols that are run by
>    the service provider.
>
>SB> This sentence needs a scope limiting rider.

done

>    In layer 3 VPNs with dynamic routing this
>    would typically relate to the distribution of per-VPN routes as well
>    as backbone routes.  In layer 2 VPNs this would typically relate
>    only to the distribution of backbone routes.  Specific attacks
>    against popular routing protocols have been widely studied and
>    described in [Beard].
>
>SB> Again I am worried about the scoping here.
>SB> Surely in L2 it is the distribution of VPN endpoints (or authentication
>SB> info that is the PPVPN specific concern, general route distribution is
>SB> surely out of scope.

agreed.  text corrected.

>3.2.7.  Other Attacks on PPVPN Control Traffic
>
>    Besides routing and management protocols (covered separately in the
>    previous sections) a number of other control protocols are used for
>    membership discovery and tunnel establishment in various PPVPN
>    approaches.  These include but may not be limited to:
>
>     - MPLS signaling (LDP, RSVP-TE)
>     - IPsec signaling (IKE)
>     - L2TP
>     - BGP-based membership discovery
>     - Database-based membership discovery (e.g. RADIUS-based)
>
>    Attacks might subvert or disrupt the activities of these protocols,
>    for example via impersonation or DOS attacks.
>
>SB> A network that has these vulnerabilities does not just have PPVPN
>SB> issues.

Agreed.  However, in this section we are only talking about the use of 
these protocols to deliver the PPVPN service.  I have made that more clear.

Thanks, Mark