described in [VPN-SEC] SHOULD be used as far as it is applicable to
the given type of PPVPN service.
The PE device has a lot of functionality required for the successful
operation of the VPN service. The PE device is frequently also part
of the backbone providing Internet services, and is therefore
susceptible to security and denial of service attacks. The PE
control plane CPU is vulnerable from this point of view, and it may
impact not only VPN services but also general Internet services if
not adequately protected. In addition to VPN configuration, if
mechanisms such as QoS are provisioned on the PE, it is possible for
attackers to recognize the highest priority traffic or customers and
launch directed attacks. Care SHOULD be taken to prevent such
attacks whenever any value added services such as QoS are offered.
When a service such as "Dynamic Bandwidth Management" as described in
Section 5.2.1 is provided, it allows customers to dynamically request
for changes to their bandwidth allocation. The provider MUST take
care to authenticate such requests and detect and prevent possible
Denial-of-Service attacks. These DoS attacks are possible when a
customer maliciously or accidentally may cause a change in bandwidth
allocation that may impact the bandwidth allocated to other VPN
customers or Internet users.
Different choices of VPN technology have different assurance levels
of the privacy of a customer’s network. For example, CE-based
solutions may enjoy more privacy than PE-based VPNs by virtue of
tunnels extending from CE to CE, even if the tunnels are not
encrypted. In a PE-based VPN, a PE has many more sites than those
attached to a CE in a CE-based VPN. A large number of these sites
may use [RFC1918] addresses. Provisioning mistakes and PE software
bugs may make traffic more prone to being misdirected as opposed to a
CE-based VPN. Care MUST be taken to prevent misconfiguration in all
kinds of PPVPNs, but more care MUST be taken in the case of PE-based
VPNs, as this could impact other customers and Internet services.
Similarly, there SHOULD be mechanisms to prevent the flooding of
Internet routing tables whenever there is a misconfiguration or
failure of PPVPN control mechanisms that use Internet routing
protocols for relay of VPN-specific information.
Different deployment scenarios also dictate the level of security
that may be needed for a VPN. For example, it is easier to control
security in a single provider, single AS VPN and therefore, expensive
encryption techniques may not be used in this case, as long as VPN
traffic is isolated from the Internet. There is a reasonable amount
of control possible in the single provider, multi AS case, although
care SHOULD be taken to ensure the constrained distribution of VPN
route information across the ASes. Security is more of a challenge
in the multi-provider case, where it may be necessary to adopt
encryption techniques in order to provide the highest level of
security.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
8.2. Informative References
[TERMINOLOGY] Andersson, L., Madsen, T., "Terminology for Provider
Provisioned Virtual Private Networks", Work in
Progress.
[L3FRAMEWORK] Callon, R., Suzuki, M., et al. "A Framework for Layer 3
Provider Provisioned Virtual Private Networks", Work in
Progress, March 2003.
[L2FRAMEWORK] Andersson, L., et al. "Framework for Layer 2 Virtual
Private Networks (L2VPNs)", Work in Progress, March
2004.
[L3REQTS] Carugi, M., McDysan, D. et al., "Service Requirements
for Layer 3 Provider Provisioned Virtual Private
Networks", Work in Progress, April 2003.
[L2REQTS] Augustyn, W., Serbest, Y., et al., "Service
Requirements for Layer 2 Provider Provisioned Virtual
Private Networks", Work in Progress, April 2003.
[Y.1241] "IP Transfer Capability for the support of IP based
Services", Y.1241 ITU-T Draft Recommendation, March
2000.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G. and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC3198] Westerinen, A., Schnizlein, J., Strassner, J.,
Scherling, M., Quinn, B., Herzog, S., Huynh, A.,
Carlson, M., Perry, J. and S. Waldbusser, "Terminology
for Policy-Based Management", RFC 3198, November 2001.
[VPN-SEC] Fang, L., et al., "Security Framework for Provider
Provisioned Virtual Private Networks", Work in
Progress, February 2004.
[FRF.13] Frame Relay Forum, "Service Level Definitions
Implementation Agreement", August 1998.
[Y.1541] "Network Performance Objectives for IP-based Services",
Y.1541, ITU-T Recommendation.
9. Acknowledgements
This work was done in consultation with the entire design team for
PPVPN requirements. A lot of the text was adapted from the Layer 3
requirements document produced by the Layer 3 requirements design
team. The authors would also like to acknowledge the constructive
feedback from Scott Bradner, Alex Zinin, Steve Bellovin, Thomas
Narten and other IESG members, and the detailed comments from Ross
Callon.
10. Editor’s Address
Ananth Nagarajan
Juniper Networks
EMail: ananth@juniper.net
11. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.