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 it will
improve the security of the core. If the core is dedicated to VPN
services and there are no interconnects to third parties, then it
may reduce the requirement for authentication of the core control
plane.
- Elements protection
Here we discuss means to hide the provider’s infrastructure nodes.
A PPVPN provider may make the infrastructure routers (P and PE
routers) unreachable by outside users and unauthorized internal
users. For example, separate address space may be used for the
infrastructure loopbacks.
Normal TTL propagation may be altered to make the backbone look
like one hop from the outside, but caution should be taken for
loop prevention. This prevents the backbone addresses from being
exposed through trace route; however, it must also be assessed
against operational requirements for end-to-end fault tracing.
An Internet backbone core may be re-engineered to make Internet
routing an edge function, for example, by using MPLS label
switching for all traffic within the core and possibly by making
the Internet a VPN within the PPVPN core itself. This helps
detach Internet access from PPVPN services.
PE devices may implement separate control plane, data plane, and
management plane functionality in terms of hardware and software,
to improve security. This may help limit the problems when one
particular area is attacked, and it may allow each plane to
implement additional security measurement separately.
PEs are often more vulnerable to attack than P routers, since, by
their very nature, PEs cannot be made unreachable to outside
users. Access to core trunk resources can be controlled on a
per-user basis by the application of inbound rate-
limiting/shaping. This can be further enhanced on a per-Class of
Service basis (see section 8.2.3).
In the PE, using separate routing processes for Internet and PPVPN
service may help improve the PPVPN security and better protect VPN
customers. Furthermore, if the resources, such as CPU and memory,
may be further separated based on applications, or even on
individual VPNs, it may help provide improved security and
reliability to individual VPN customers.
Many of these were not particular issues when an IP core was
designed to support Internet services only. Providing PPVPN
services introduces new security requirements for VPN services.
Similar consideration apply to L2 VPN services.
8.1.2. Data Plane Protection
PPVPN using IPsec technologies provides VPN users with encryption of
secure user data.
In today’s MPLS, ATM, and Frame Relay networks, encryption is not
provided as a basic feature. Mechanisms can be used to secure the
MPLS data plane and to secure the data carried over the MPLS core.
Additionally, if the core is dedicated to VPN services and there are
no external interconnects to third party networks, then there is no
obvious need for encryption of the user data plane.
Inter-working IPsec/L3 PPVPN technologies or IPsec/L2 PPVPN
technologies may be used to provide PPVPN users with end-to-end PPVPN
services.
8.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 an inter-provider
connection, authentication/encryption mechanisms between ASes, such
as IPsec, may be used.
WAN link address space separation for VPN and non-VPN users may be
implemented to improve security in order to protect VPN customers if
multiple services are provided on the same PE platform.
Firewall/Filtering: Access control mechanisms can be used to filter
out any packets destined for the service provider’s infrastructure
prefix or to eliminate routes identified as illegitimate.
Rate limiting may be applied to the user interface/logical interfaces
against DDoS bandwidth attack. This is very helpful when the PE
device is supporting both VPN services and Internet services,
especially when it supports VPN and Internet services on the same
physical interfaces through different logical interfaces.
8.2.1. Link Authentication
Authentication mechanisms can be employed to validate site access to
the PPVPN network via fixed or logical (e.g., L2TP, IPsec)
connections. When the user wishes to hold the ’secret’ associated to
acceptance of the access and site into the VPN, then PPVPN based
solutions require the flexibility for either direct authentication by
the PE itself or interaction with a customer PPVPN authentication
server. Mechanisms are required in the latter case to ensure that
the interaction between the PE and the customer authentication server
is controlled, for example, by limiting it simply to an exchange in
relation to the authentication phase and with other attributes (e.g.,
optional filtering of RADIUS).
8.2.2. Access Routing
Mechanisms may be used to provide control at a routing protocol level
(e.g., RIP, OSPF, BGP) between the CE and PE. Per-neighbor and per-
VPN routing policies may be established to enhance security and
reduce the impact of a malicious or non-malicious attack on the PE,
in particular, the following mechanisms should be considered:
- Limiting the number of prefixes that may be advertised into the PE
on a per-access basis . Appropriate action may be taken should a
limit be exceeded; for example, the PE might shut down the peer
session to the CE.
- Applying route dampening at the PE on received routing updates.
- Definition of a per-VPN prefix limit, after which additional
prefixes will not be added to the VPN routing table.
In the case of inter-provider connection, access protection, link
authentication, and routing policies as described above may be
applied. Both inbound and outbound firewall/filtering mechanism may
be applied between ASes. Proper security procedures must be
implemented in inter-provider VPN interconnection to protect the
providers’ network infrastructure and their customer VPNs. This may
be custom designed for each inter-Provider VPN peering connection,
and both providers must agree on it.
8.2.3. Access QoS
PPVPN providers offering QoS-enabled services require mechanisms to
ensure that individual accesses are validated against their
subscribed QOS profile and are granted access to core resources that
match their service profile. Mechanisms such as per-Class of Service
rate limiting/traffic shaping on ingress to the PPVPN core are one
option in providing this level of control. Such mechanisms may
require the per-Class of Service profile to be enforced by marking,
remarking, or discarding traffic that is outside of the profile.
8.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 both to validate the incoming
user and to limit the views available to that particular user’s VPN.
Mechanisms should also be considered to ensure that such access
cannot be used to create a DoS attack (either malicious or
accidental) on the PE itself. This could be accomplished either
through separation of these resources within the PE itself or via the
capability to rate-limit such traffic on a per-VPN basis.
8.3. General Requirements for PPVPN Providers
The PPVPN providers must support the users’ security requirements as
listed in Section 7. Depending on the technologies used, these
requirements may include the following.
- User control plane separation: Routing isolation.
- User address space separation: Supporting overlapping addresses
from different VPNs.
- User data plane separation: One VPN traffic cannot be intercepted
by other VPNs or any other users.
- Protection against intrusion, DoS attacks and spoofing.
- Access Authentication.
- Techniques highlighted through this document identify
methodologies for the protection of PPVPN resources and
infrastructure.
Hardware or software bugs in equipment that lead to security breaches
are outside the scope of this document.
9. Security Evaluation of PPVPN Technologies
This section presents a brief template that may be used to evaluate
and summarize how a given PPVPN approach (solution) measures up
against the PPVPN Security Framework. An evaluation using this
template should appear in the applicability statement for each PPVPN
approach.
9.1. Evaluating the Template
The first part of the template is in the form of a list of security
assertions. For each assertion the approach is assessed and one or
more of the following ratings is assigned:
- The requirement is not applicable to the VPN approach because ...
(fill in reason).
- The base VPN approach completely addresses the requirement by ...
(fill in technique).
- The base VPN approach partially addresses the requirement by ...
(fill in technique and extent to which it addresses the
requirement).
- An optional extension to the VPN approach completely addresses the
requirement by ... (fill in technique).
- An optional extension to the VPN approach partially addresses the
requirement by ... (fill in technique and extent to which it
addresses the requirement).
- The requirement is addressed in a way that is beyond the scope of
the VPN approach. (Explain.) (One example of this would be a VPN
approach in which some aspect, such as membership discovery, is
done via configuration. The protection afforded to the
configuration would be beyond the scope of the VPN approach.).
- The VPN approach does not meet the requirement.
9.2. Template
The following assertions solicit responses of the types listed in the
previous section.
1. The approach provides complete IP address space separation for
each L3 VPN.
2. The approach provides complete L2 address space separation for
each L2 VPN.
3. The approach provides complete VLAN ID space separation for each
L2 VPN.
4. The approach provides complete IP route separation for each L3
VPN.
5. The approach provides complete L2 forwarding separation for each
L2 VPN.
6. The approach provides a means to prevent improper cross-
connection of sites in separate VPNs.
7. The approach provides a means to detect improper cross-connection
of sites in separate VPNs.
8. The approach protects against the introduction of unauthorized
packets into each VPN
a. in the CE-PE link,
b. in a single- or multi-provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
9. The approach provides confidentiality (secrecy) protection for
PPVPN user data
a. in the CE-PE link,
b. in a single- or multi-provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
10. The approach provides sender authentication for PPVPN user data.
a. in the CE-PE link,
b. in a single- or multi-provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
11. The approach provides integrity protection for PPVPN user data
a. in the CE-PE link,
b. in a single- or multi- provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
12. The approach provides protection against replay attacks for PPVPN
user data
a. in the CE-PE link,
b. in a single- or multi-provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
13. The approach provides protection against unauthorized traffic
pattern analysis for PPVPN user data
a. in the CE-PE link,
b. in a single- or multi-provider PPVPN backbone, or
c. in the Internet used as PPVPN backbone.
14. The control protocol(s) used for each of the following functions
provides message integrity and peer authentication
a. VPN membership discovery.
b. Tunnel establishment.
c. VPN topology and reachability advertisement:
i. PE-PE.
ii. PE-CE.
d. VPN provisioning and management.
e. VPN monitoring, attack detection, and reporting.
f. Other VPN-specific control protocols, if any (list).
The following questions solicit free-form answers.
15. Describe the protection, if any, the approach provides against
PPVPN-specific DoS attacks (i.e., inter-trusted-zone DoS
attacks):
a. Protection of the service provider infrastructure against
Data Plane or Control Plane DoS attacks originated in a
private (PPVPN user) network and aimed at PPVPN mechanisms.
b. Protection of the service provider infrastructure against
Data Plane or Control Plane DoS attacks originated in the
Internet and aimed at PPVPN mechanisms.
c. Protection of PPVPN users against Data Plane or Control
Plane DoS attacks originated from the Internet or from other
PPVPN users and aimed at PPVPN mechanisms.
16. Describe the protection, if any, the approach provides against
unstable or malicious operation of a PPVPN user network
a. Protection against high levels of, or malicious design of,
routing traffic from PPVPN user networks to the service
provider network.
b. Protection against high levels of, or malicious design of,
network management traffic from PPVPN user networks to the
service provider network.
c. Protection against worms and probes originated in the PPVPN
user networks, sent toward the service provider network.
17. Is the approach subject to any approach-specific vulnerabilities
not specifically addressed by this template? If so, describe the
defense or mitigation, if any, that the approach provides for
each.
10. Security Considerations
Security considerations constitute the sole subject of this memo and
hence are discussed throughout. Here we recap what has been
presented and explain at a very high level the role of each type of
consideration in an overall secure PPVPN system. The document
describes a number of potential security threats. Some of these
threats have already been observed occurring in running networks;
others are largely theoretical at this time.
DoS attacks and intrusion attacks from the Internet against service
provider infrastructure have been seen. DoS "attacks" (typically not
malicious) have also been seen in which CE equipment overwhelms PE
equipment with high quantities or rates of packet traffic or routing
information. Operational/provisioning errors are cited by service
providers as one of their prime concerns.
The document describes a variety of defensive techniques that may be
used to counter the suspected threats. All of the techniques
presented involve mature and widely implemented technologies that are
practical to implement.
The document describes the importance of detecting, monitoring, and
reporting both successful and unsuccessful attacks. These activities
are essential for "understanding one’s enemy", mobilizing new
defenses, and obtaining metrics about how secure the PPVPN service
is. As such, they are vital components of any complete PPVPN
security system.
The document evaluates PPVPN security requirements from a customer
perspective and from a service provider perspective. These sections
re-evaluate the identified threats from the perspectives of the
various stakeholders and are meant to assist equipment vendors and
service providers, who must ultimately decide what threats to protect
against in any given equipment or service offering.
Finally, the document includes a template for use by authors of PPVPN
technical solutions for evaluating how those solutions measure up
against the security considerations presented in this memo.
11. Contributors
The following people made major contributions to writing this
document: Michael Behringer, Ross Callon, Fabio Chiussi, Jeremy De
Clerque, Paul Hitchen, and Paul Knignt.
Michael Behringer
Cisco
Village d’Entreprises Green Side, Phone: +33.49723-2652
400, Avenue Roumanille, Bat. T 3 EMail: mbehring@cisco.com
06410 Biot, Sophia Antipolis
France
Ross Callon
Juniper Networks
10 Technology Park Drive Phone: 978-692-6724
Westford, MA 01886 EMail: rcallon@juniper.net
Fabio Chiussi Phone: 1 978 367-8965
Airvana EMail: fabio@airvananet.com
19 Alpha Road
Chelmsford, Massachusetts 01824
Jeremy De Clercq
Alcatel
Fr. Wellesplein 1, 2018 Antwerpen EMail: jeremy.de_clercq@alcatel.be
Belgium
Mark Duffy
Sonus Networks
250 Apollo Drive Phone: 1 978-614-8748
Chelmsford, MA 01824 EMail: mduffy@sonusnet.com
Paul Hitchen
BT
BT Adastral Park
Martlesham Heath Phone: 44-1473-606-344
Ipswich IP53RE EMail: paul.hitchen@bt.com
UK
Paul Knight
Nortel
600 Technology Park Drive Phone: 978-288-6414
Billerica, MA 01821 EMail: paul.knight@nortel.com
12. Acknowledgement
The author and contributors would also like to acknowledge the
helpful comments and suggestions from Paul Hoffman, Eric Gray, Ron
Bonica, Chris Chase, Jerry Ash, and Stewart Bryant.
13. Normative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC2246] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
RFC 2246, January 1999.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2407] Piper, D., "The Internet IP Security Domain of
Interpretation for ISAKMP", RFC 2407, November 1998.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[RFC3588] Calhoun, P., Loughney, J., Guttman, E., Zorn, G., and J.
Arkko, "Diameter Base Protocol", RFC 3588, September
2003.
[RFC3602] Frankel, S., Glenn, R., and S. Kelly, "The AES-CBC
Cipher Algorithm and Its Use with IPsec", RFC 3602,
September 2003.
[STD62] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC
3411, December 2002.
Case, J., Harrington, D., Presuhn, R., and B. Wijnen,
"Message Processing and Dispatching for the Simple
Network Management Protocol (SNMP)", STD 62, RFC 3412,
December 2002.
Levi, D., Meyer, P., and B. Stewart, "Simple Network
Management Protocol (SNMP) Applications", STD 62, RFC
3413, December 2002.
Blumenthal, U. and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management
Protocol (SNMPv3)", STD 62, RFC 3414, December 2002.
Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3415, December
2002.
Presuhn, R., "Version 2 of the Protocol Operations for
the Simple Network Management Protocol (SNMP)", STD 62,
RFC 3416, December 2002.
Presuhn, R., "Transport Mappings for the Simple Network
Management Protocol (SNMP)", STD 62, RFC 3417, December
2002.
Presuhn, R., "Management Information Base (MIB) for the
Simple Network Management Protocol (SNMP)", STD 62, RFC
3418, December 2002.
[STD8] Postel, J. and J. Reynolds, "Telnet Protocol
Specification", STD 8, RFC 854, May 1983.
14. Informative References
[RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC:
Keyed-Hashing for Message Authentication", RFC 2104,
February 1997.
[RFC2411] Thayer, R., Doraswamy, N., and R. Glenn, "IP Security
Document Roadmap", RFC 2411, November 1998.
[RFC3174] Eastlake 3rd, D. and P. Jones, "US Secure Hash Algorithm
1 (SHA1)", RFC 3174, September 2001.
[RFC3631] Bellovin, S., Schiller, J., and C. Kaufman, "Security
Mechanisms for the Internet", RFC 3631, December 2003.
[RFC3889] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to
Routing Protocols", RFC 3889, October 2004.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
[RFC4031] Carugi, M. and D. McDysan, Eds., "Service Requirements
for Layer 3 Provider Provisioned Virtual Private