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

From: Stewart Bryant <[email-masked]>
Date: Wed, 30 Jul 2003 18:00:13 +0100

This is a good analysis of the PPVPN security issues. Of necessity
it overlaps with the detailed security analysis that we need (but
have not yet written) for PWE3. The overlap is not complete
in that there is obviously some material here that we do not need,
and there is other material that is not addressed (i.e. timing
attacks on TDM PWs). It would be good if we could find a way to
share this work rather than start from scratch.

I have a number of detailed comments below.

Regards

Stewart

SB> Number of authors exceeds current limit 

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.

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?

    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/
SB> Also shouldn't it now be l3vpn? Although there is some overlap
SB> with l2vpn, there are important differences in the vulnerabilities.

    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.

     - 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

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.

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.

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.

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.

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.

    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.

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.

4.1.    Cryptographic techniques

    Packet lengths are typically increased when the packets are
    encrypted, increasing the network traffic load and adding to the
    likelihood of packet fragmentation with its increased overhead.

SB> Do you want to talk about MTU here?

4.1.3.  Cryptographic techniques in Layer 2 PPVPNs

    Layer 2 PPVPNs will generally not be able to use IPsec to provide
    encryption throughout the entire network.  They may be able to use
    IPsec for PE-PE traffic where it is encapsulated in IP packets,

SB> Does this mean that we need an MPLSsec work item?

4.3.    Access Control techniques

SB> Should you you call out the use of internal only addresses for
SB> the VPN infrastructure? This is called up later - perhaps a
SB> forward reference?

4.4.    Use of Isolated Infrastructure

    One way to protect the infrastructure used for support of VPNs is to
    separate the resources for support of VPNs from the resources used
    for other purposes (such as support of Internet services). In some
    cases this may make use of a physically separate equipment for VPN
    services, or even a physically separate network.

    For example, PE-based L3 VPNs may be run on a separate backbone not
    connected to the Internet, or may make use of separate edge routers
    from those used to support Internet service.

SB> This is where local (to the provider) addresses help.

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

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.

7. Provider Security Requirements

    The PPVPN service provider requirements defined here are the
    requirements for the PPVPN core in the reference model.  The core
    network can be implemented with different types of network
    technologies, and each core network may use different technologies
    to provide the PPVPN services to users with different levels of
    offered security. Therefore, a PPVPN service provider may fulfill
    any number of the security requirements listed in this section. This
    ^^^^^^^^^^
SB> Surely the necessary number?

    These requirements are focused on: 1) how to protect the PPVPN core
    from various attacks outside the core including PPVPN users and non-

SB> attacks originating from ...?
SB> Some of this is out of scope

    Note that a PPVPN core is
    not more vulnerable against attacks than a core that does not
    provide PPVPNs.

SB> That depends. There are for example more potential methods of
SB> disguising an originator, and there are likely to be tunnel
SB> endpoints that might be put to use.
SB>
SB> Your contrasting point is correct, but I am not sure that the
SB> previous point adds value.

    With the cost of authentication coming down rapidly, the application
    of control plane authentication may not increase the cost of
    implementation for providers significantly, and will help to improve
    the security of the core. If the core is dedicated to VPN services 
                             rd   and without any interconnects to 3  parties 
then this may reduce the
    requirement for authentication of the core control plane.

SB> layout problem that appears in the HTML that I cut this from. Missing
SB> LF?

    Normal TTL propagation may be altered to make the backbone look like
    one hop from the outside, but caution needs to be taken for loop
    prevention.

SB> I thought that this was the default in a tunnel?

    This prevents the backbone addresses to be exposed
    through trace route, however this must also be assessed against
    operational requirements for end to end fault tracing.

SB> Addresses? Surely hop count? I don't see how you propagate the
SB> trace route packets between the user and the provider network.
SB> A secure VPN infrastructure is surely a VPN wrt the user VPN, and
SB> hence traffic mixing cannot occur?

    Many of these were not particular issues when an IP core was
    designed to support Internet services only. When providing PPVPN
    services, new requirements are introduced to satisfy the security
    needs for VPN services. Similar consideration apply to L2 VPN
    services.

SB> This needs to be fleshed out. An example perhaps?

7.1.2.  Data Plane Protection

    PPVPN using IPSec technologies provide VPN users with encryption of
    secure user data.

    In todayÆs MPLS, ATM, or Frame Relay networks, encryption is not
    provided as a basic feature. Mechanisms can be used to secure the
    MPLS data plane to secure the data carried over MPLS core.

SB> But a private MPLS core switching a PW is just as secure (or insecure)
SB> as the ATM or FR network that it is replacing.

    Additionally, if the core is dedicated to VPN services and without 
                         rd   any external interconnects to 3  party networks 
then there is no
    obvious need for encryption of the user data plane.

SB> layout?

7.2.    Protection on the User Access Link

    Peer / Neighbor protocol authentication may be used to enhance
    security. For example, BGP MD5 authentication may be used to enhance
    security on PE-CE links using eBGP. In the case of Inter-provider
    connection, authentication / encryption mechanisms between ASes,
    such as IPSec, may be used.

SB> Is this a special to PPVPN problem?

    7.2.4 Customer VPN monitoring tools

    End users requiring visibility of VPN specific statistics on the
    core e.g. routing table, interface status, QoS statistics, impose
    requirements for mechanisms at the PE to both validate the incoming
    user and limit the views available to that particular users VPN.

SB> It is not clear to me that the customer has any right to these,
SB> surely the customer just has the right to test the SLA from their
SB> own side of the fence?

7.3.    General Requirements for PPVPN Providers

SB> I am not sure this section adds much value given that the reader
SB> has read this far.

8.2.    Template

SB> I am not sure that this section adds much value

9. Security Considerations

    There are no further security considerations in addition to what
    discussed in the previous sections.

SB> A Catch-22 problem if ever I saw one :)

SB> It might be worth noting somewhere that most existing "physical"
SB> networks are actually virtual (TDM, ATM, FR etc), and so the
SB> comparision is not zero risk to PPVPN risk, but SOME risk to
SB> PPVPN risk.