RFC 4031
Service Requirements for Layer 3 Provider Provisioned Virtual Private Networks (PPVPNs)
Pages: 50
Informational
Informational
Part 3 of 3 – Pages 36 to 50
7. Service Provider Management Requirements
A service provider MUST have a means to view the topology, operational state, order status, and other parameters associated with each customer's VPN. Furthermore, an SP MUST have a means to view the underlying logical and physical topology, operational state, provisioning status, and other parameters associated with the equipment providing the VPN service(s) to its customers. Currently, proprietary methods are often used to manage VPNs. The additional expense associated with operators using multiple proprietary management methods (e.g., command line interface (CLI) languages) to access such systems is undesirable. Therefore, devices SHOULD provide standards-based interfaces wherever feasible. The remainder of this section presents detailed SP management requirements for a Network Management System (NMS) in the traditional fault, configuration, accounting, performance, and security (FCAPS) management categories. Much of this text was adapted from ITU-T Y.1311.1.
7.1. Fault Management
Support for fault management includes: - indication of customers impacted by failure, - fault detection (incidents reports, alarms and failure visualization), - fault localization (analysis of alarms reports and diagnostics), - incident recording or logs (creation and follow-through of trouble tickets), and - corrective actions (traffic, routing, and resource allocation). As PE-based VPNs rely on a common network infrastructure, the NMS MUST provide a means to inform the provider of the VPN customers impacted by a failure in the infrastructure. The NMS SHOULD provide pointers to the related customer configuration information to aid in fault isolation and determining corrective action. Detecting faults caused by configuration errors is desirable, because these may cause VPN service failure or may disrupt other requirements (e.g., traffic and routing isolation). This is a likely case of compromised security [VPNSEC]. Detection of such errors is inherently difficult because the problem involves more than one node and may reach across a global perspective. One approach could be a protocol that systematically checks whether all constraints and consistency checks hold among tunnel configuration parameters at the various end points. A capability to verify L3 reachability within a VPN MUST be provided for diagnostic purposes. A capability to verify the parameter configuration of a device supporting an L3VPN MUST be provided for diagnostic purposes.7.2. Configuration Management
Overall, the NMS must support a configuration necessary to realize the desired L3-reachability of an L3VPN. Toward this end, an NMS MUST provide configuration management to provision at least the following L3VPN components: PE,CE, hierarchical tunnels, access connections, routing, and QoS, as detailed in this section. If shared access to the Internet is provided, then this option MUST also be configurable. As VPN configuration and topology are highly dependent on a customer's organization, provisioning systems MUST address a broad range of customer-specific requirements. The NMS MUST ensure that
these devices and protocols are provisioned consistently and correctly. Provisioning for adding or removing sites SHOULD be as localized and automated as possible. Configuration management for VPNs, according to service templates defined by the provider MUST be supported. A service template contains fields that, when used, yield a definite service requirement or policy. For example, a template for an IPSec tunnel would contain fields such as tunnel end points, authentication modes, encryption and authentication algorithms, pre-shared keys (if any), and traffic filters. An SLA template would contain fields such as delay, jitter, and throughput and packet loss thresholds, as well as end points over which the SLA has to be satisfied. In general, a customer's service order can be regarded as a set of instantiated service templates. This set can, in turn, be regarded as the logical service architecture of the customer's VPN. Service templates can also be used by the provider to define the service architecture of the provider's own network. For example, OSPF templates could contain fields such as the subnets that form a particular area, the area identifier, and the area type. BGP service template could contain fields that, when used, would yield a BGP policy, such as for expressing a preference about an exit router for a particular destination. The set of service templates SHOULD be comprehensive in that it can capture all service orders in some meaningful sense. The provider SHOULD provide means to translate service templates into device configurations so that associated services can be provisioned. Finally, the approach SHOULD provide means to check whether a service order is correctly provisioned. This would represent one method of diagnosing configuration errors. Configuration errors can arise due to a variety of reasons: manual configuration, intruder attacks, and conflicting service requirements.7.2.1. Configuration Management for PE-Based VPNs
Requirements for configuration management unique to a PE-based VPN are as follows: o The NMS MUST support configuration of at least the following aspects of L3 PE routers: intranet and extranet membership, CE routing protocol for each access connection, routing metrics, and tunnels.
o The NMS SHOULD use identifiers for SPs, L3VPNs, PEs, CEs,
hierarchical tunnels, and access connections, as described in
section 6.3.
o Tunnels MUST be configured between PE and P devices. This
requires coordination of identifiers of tunnels, hierarchical
tunnels, VPNs, and any associated service information, for
example, a QoS/SLA service.
o Routing protocols running between PE routers and CE devices MUST
be configured per VPN.
o For multicast service, multicast routing protocols MUST also be
configurable.
o Routing protocols running between PE routers and between PE and P
routers MUST also be configured.
o The configuration of a PE-based L3VPN MUST be coordinated with the
configuration of the underlying infrastructure, including Layer 1
and 2 networks interconnecting components of an L3VPN.
7.2.2. Configuration Management for CE-Based VPN
Requirements for configuration management unique to a CE-based VPN
are as follows:
o Tunnels MUST be configured between CE devices. This requires
coordination of identifiers of tunnels, VPNs, and any associated
service information, for example, a QoS/SLA service.
o Routing protocols running between PE routers and CE devices MUST
be configured. For multicast service, multicast routing protocols
MUST also be configurable.
7.2.3. Provisioning Routing
A means for a service provider to provision parameters for the IGP
for an L3VPN MUST be provided. This includes link level metrics,
capacity, QoS capability, and restoration parameters.
7.2.4. Provisioning Network Access
A service provider MUST have the means to provision network access
between SP-managed PE and CE, as well as the case where the customer
manages the CE.
7.2.5. Provisioning Security Services
When a security service is requested, an SP MUST have the means to provision the entities and associated parameters involved with the service. For example, for IPsec service, tunnels, options, keys, and other parameters must be provisioned at either the CE or the PE. In the case of an intrusion detection service, the filtering and detection rules must be provisioned on a VPN basis.7.2.6. Provisioning VPN Resource Parameters
A service provider MUST have a means to provision resources associated with VPN services dynamically. For example, in a PE-based service, the number and size of virtual switching and forwarding table instances must be provisionable. Dynamic VPN resource assignment is crucial for coping with the frequent change requests from customers (e.g., sites joining or leaving a VPN), as well as for achieving scalability. The PEs SHOULD be able to dynamically assign the VPN resources dynamically. This capability is especially important for dial and wireless VPN services. If an SP supports a "Dynamic Bandwidth management" service, then the provisioning system MUST be able to make requested changes within the ranges and bounds specified in the SLA. Examples of SLA parameters are response time and probability of being able to service such a request.7.2.7. Provisioning Value-Added Service Access
An L3VPN service provides controlled access between a set of sites over a common backbone. However, many service providers also offer a range of value-added services. (for example, Internet access, firewall services, intrusion protection, IP telephony and IP Centrex, application hosting, and backup). It is outside of the scope of this document to define whether and how these different services interact with the VPN to solve issues such as addressing, integrity, and security. However, the VPN service MUST be able to provide access to these various types of value-added services. A VPN service SHOULD allow the SP to supply the customer with different kinds of standard IP services, such as DNS, NTP, and RADIUS, that are needed for ordinary network operation and management. The provider SHOULD be able to provide IP services to multiple VPN customers.
A firewall function MAY be required to restrict access to the L3VPN from the Internet [Y.1311]. A managed firewall service MUST be carrier grade. For redundancy and failure recovery, a means for firewall fail-over should be provided. Managed firewall services that may be provided include dropping specified protocol types, intrusion protection, and traffic-rate limiting against malicious attacks. Managed firewalls MUST be supported on a per-VPN basis, although multiple VPNs may be supported by the same physical device (e.g., in a PE-based solution). Managed firewalls SHOULD be provided at the major access point(s) for the L3VPN. Managed firewall services may be embedded in CE or PE device or implemented in standalone devices. The NMS SHOULD allow a customer to outsource the management of an IP networking service to the SP providing the VPN or to a third party. The NMS SHOULD support collection of information necessary for optimal allocation of IP services in response to customer orders. Reachability to and from the Internet to sites within a VPN MUST be configurable by an SP. This could be controlled by configuring routing policy to control distribution of VPN routes advertised to the Internet.7.2.8. Provisioning Hybrid VPN Services
Configuration of interworking or interconnection between L3VPN solutions SHOULD be also supported. Ensuring that security and end-to-end QoS issues are provided consistently SHOULD be addressed.7.3. Accounting
Many service providers require collection of measurements regarding resource usage for accounting purposes. The NMS MAY need to correlate accounting information with performance and fault management information to produce billing that takes into account SLA provisions for periods of time when the SLS is not met. An L3VPN solution MUST describe how the following accounting functions can be provided: - Measurements of resource utilization. - collection of accounting information. - storage and administration of measurements.
Some providers may require near - real time reporting of measurement information and may offer this as part of a customer network management service. If an SP supports a "Dynamic Bandwidth management" service, then the dates, times, amounts, and interval required to perform requested bandwidth allocation change(s) MUST be traceable for monitoring and accounting purposes. Solutions should state compliance with accounting requirements, as described in section 1.7 of RFC 2975 [RFC2975].7.4. Performance Management
Performance management MUST support functions involved with monitoring and collecting performance data for devices, facilities, and services, as well as determining conformance to SLS, such as QoS and availability measurements. Performance management SHOULD also support analysis of important aspects of an L3VPN, such as bandwidth utilization, response time, availability, QoS statistics, and trends based on collected data.7.4.1. Performance Monitoring
The NMS MUST monitor device behavior to evaluate performance metrics associated with an SLA. Different measurement techniques may be necessary depending on the service for which an SLA is provided. Example services are QoS, security, multicast, and temporary access. These techniques MAY be either intrusive or non-intrusive depending on the parameters being monitored. The NMS MUST also monitor aspects of the VPN not directly associated with an SLA, such as resource utilization, state of devices, and transmission facilities, as well as control of monitoring resources such as probes and remote agents at network access points used by customers and mobile users.7.4.2. SLA and QoS Management Features
The NMS SHOULD support SLAs between an SP and the various VPN customers according to the corresponding SLSes by measurement of the indicators defined within the context of the SLA, on a regular basis. The NMS SHOULD use the QoS parameter measurement definitions, techniques, and methods as defined by the IETF IP Performance Metrics (IPPM) working group for delay, loss, and delay variation.
The NMS SHOULD support allocation and measurement of end-to-end QoS requirements to QoS parameters for one or more VPN network(s). Devices supporting L3VPN SLAs SHOULD have real-time performance measurements that have indicators and threshold crossing alerts. Such thresholds should be configurable.7.5. Security Management
The security management function of the NMS MUST include management features to guarantee the security of devices, access connections, and protocols within the L3VPN network(s), as well as the security of customer data and control as described in section 6.9.7.5.1. Resource Access Control
Resource access control determines the privileges that a user has to access particular applications and VPN network resources. Without such control, only the security of the data and control traffic is protected, leaving the devices providing the L3VPN network unprotected. Access control capabilities protect these devices to ensure that users have access only to the resources and applications they are authorized to use. In particular, access to the routing and switching resources managed by the SP MUST be tightly controlled to prevent and/or effectively mitigate a malicious attack. More detailed requirements in this area are described in [VPNSEC].7.5.2. Authentication
Authentication is the process of verifying that the sender is actually who he or she claims to be. The NMS MUST support standard methods for authenticating users attempting to access management services. Scalability is critical, as the number of nomadic/mobile clients is increasing rapidly. The authentication scheme implemented for such deployments MUST be manageable for large numbers of users and VPN access points. Strong authentication schemes SHALL be supported to ensure the security of both VPN access point-to-VPN access point (e.g., PE to PE in a PE-based case) and client-to-VPN access point (e.g., CE-to-PE in a PE-based case) communications. This is particularly important for preventing VPN access point spoofing, a situation where an attacker tries to convince a PE or CE that the attacker is the VPN access point. If an attacker can convince a PE or CE device of this,
then that device will send VPN traffic to the attacker (who could forward it to the true access point after compromising confidentiality or integrity). In other words, a non-authenticated VPN AP can be spoofed with a man-in-the-middle attack, because the endpoints never verify each other. A weakly authenticated VPN AP may be subject to such an attack. Strongly authenticated VPN APs are not subject to such attacks, because the man-in-the-middle cannot be authenticated as the real AP due to the strong authentication algorithms.7.6. Network Management Techniques
Each L3VPN solution approach MUST specify the management information bases (MIB) modules for the network elements involved in L3VPN services. This is an essential requirement in network provisioning. The approach SHOULD identify any information not contained in a standard MIB related to FCAPS that is necessary to meet a generic requirement. An IP VPN (Policy) Information model, when available, SHOULD reuse the policy information models being developed in parallel for specific IP network capabilities [IM-REQ]. This includes the QoS Policy Information Model [QPIM] and the IPSEC Configuration Policy Model [IPSECIM]. The IP VPN Information model SHOULD provide the OSS with adequate "hooks" to correlate service level specifications with traffic data collected from network elements. The use of policies includes rules that control corrective actions taken by OSS components responsible for monitoring the network and ensuring that it meets service requirements. Additional requirements on VPN information models are given in reference [IM-PPVPN]. In particular, an information model MUST allow an SP to change VPN network dimensions with minimal influence on provisioning issues. The adopted model SHOULD be applicable to both small/medium size and large-scale L3VPN scenarios. Some service providers MAY require systems that visually, audibly, or logically present FCAPS information to internal operators and/or customers.8. Security Considerations
Security considerations occur at several levels and dimensions within L3VPNs, as detailed within this document. This section provides a summary with references to detailed supporting information [L3VPN-SEC] [VPNSEC].
The requirements in this document separate traditional notions of security requirements, such as integrity, confidentiality, and authentication, from issues such as isolating (or separating) the exchange of VPN data and control traffic between specific sets of sites (as defined in sections 3.3 and 4.1). Further detail on security requirements is given from the customer and service provider perspectives in sections 5.9 and 6.9, respectively. Further detail on data and control traffic isolation requirements are given from the customer and service provider perspectives in sections 5.1 and 6.8, respectively. Furthermore, requirements regarding management of security from a service provider perspective are described in section 7.5.9. Acknowledgements
The authors of this document would like to acknowledge the contributions from the people who launched the work on VPN requirements inside ITU-T SG13 and the authors of the original IP VPN requirements and framework document [RFC2764], as well as Tom Worster, Ron Bonica, Sanjai Narain, Muneyoshi Suzuki, Tom Nadeau, Nail Akar, Derek Atkins, Bryan Gleeson, Greg Burns, and Frederic Le Garrec. The authors are also grateful to the helpful suggestions and direction provided by the technical advisors, Alex Zinin, Scott Bradner, Bert Wijnen, and Rob Coltun. Finally, the authors wish to acknowledge the insights and requirements gleaned from the many documents listed in the references section. Citations to these documents were made only where the authors believed that additional insight could be obtained from reading the source document.10. References
10.1. Normative References
[RFC3377] Hodges, J. and R. Morgan, "Lightweight Directory Access Protocol (v3): Technical Specification", RFC 3377, September 2002. [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, February 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification", RFC 2205, September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load Network Element Service", RFC 2211, September 1997. [RFC2212] Shenker, S., Partridge, C., and R. Guerin, "Specification of Guaranteed Quality of Service", RFC 2212, September 1997. [RFC2251] Wahl, M., Howes, T., and S. Kille, "Lightweight Directory Access Protocol (v3)", RFC 2251, December 1997. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski, "Assured Forwarding PHB Group", RFC 2597, June 1999. [RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn, G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"", RFC 2661, August 1999. [RFC2685] Fox, B. and B. Gleeson, "Virtual Private Networks Identifier", RFC 2685, September 1999. [RFC3246] Davie, B., Charny, A., Bennet, J.C., Benson, K., Le Boudec, J., Courtney, W., Davari, S., Firoiu, V., and D. Stiliadis, "An Expedited Forwarding PHB (Per-Hop Behavior)", RFC 3246, March 2002. [RFC3270] Le Faucheur, F., Wu, L., Davie, B., Davari, S., Vaananen, P., Krishnan, R., Cheval, P., and J. Heinanen, "Multi-Protocol Label Switching (MPLS) Support of Differentiated Services", RFC 3270, May 2002. [RFC3809] Nagarajan, A., "Generic Requirements for Provider Provisioned Virtual Private Networks (PPVPN)", RFC 3809, June 2004.10.2. Informative References
[2547bis] Rosen, E., Rekhter, Y. et al., "BGP/MPLS VPNs", Work in Progress. [IM-PPVPN] Lago, P., et al., "An Information Model for Provider Provisioned Virtual Private Networks", Work in Progress.
[IM-REQ] Iyer, M., et al., "Requirements for an IP VPN Policy Information Model", Work in Progress. [IPSECIM] Jason, J., "IPsec Configuration Policy Model", Work in Progress. [CE-PPVPN] De Clercq, J., Paridaens, O., Krywaniuk, A., Wang, C., "An Architecture for Provider Provisioned CE-based Virtual Private Networks using IPsec", Work in Progress. [IPSEC-PPVPN] Gleeson, B., "Uses of IPsec with Provider Provisioned VPNs", Work in Progress. [L2VPN] Rosen, E., et al., "An Architecture for L2VPNs", Work in Progress. [MPLSSEC] Behringer, M., "Analysis of the Security of the MPLS Architecture", Work in Progress. [PPVPN-TERM] Andersson, L., Madsen, T., "PPVPN Terminology", Work in Progress. [L3VPN-SEC] Fang, L., et al., "Security Framework for Provider Provisioned Virtual Private Networks", Work in Progress. [L3VPN-FR] Callon, R., Suzuki, M., et al. "A Framework for Layer 3 Provider Provisioned Virtual Private Networks", Work in Progress. [PPVPN-VR] Knight, P., Ould-Brahim, H., Gleeson, B., "Network based IP VPN Architecture using Virtual Routers", Work in Progress. [QPIM] Snir, Ramberg, Strassner, Cohen and Moore, "Policy QoS Information Model", Work in Progress. [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5 Signature Option", RFC 2385, August 1998. [RFC2764] Gleeson, B., Lin, A., Heinanen, J., Armitage, G., and A. Malis, "A Framework for IP Based Virtual Private Networks", RFC 2764, February 2000. [RFC2975] Aboba, B., Arkko, J., and D. Harrington, "Introduction to Accounting Management", RFC 2975, October 2000.
[RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [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. [TE-INTERAS] Zhang, R., Vasseur, J.P., "MPLS Inter-AS Traffic Engineering requirements", Work in Progress. [VPNDISC] Squire, M. et al., "VPN Discovery Discussions and Options", Work in Progress. [VPNIW] Kurakami, H., et al., "Provider-Provisioned VPNs Interworking", Work in Progress. [VPNSEC] De Clercq, J., et al., "Considerations about possible security extensions to BGP/MPLS VPN", Work in Progress. [VPNTUNNEL] Worster, T., et al., "A PPVPN Layer Separation: VPN Tunnels and Core Connectivity", Work in Progress. [VPN-CRIT] Yu, J., Jou, L., Matthews, A ., Srinivasan, V., "Criteria for Evaluating VPN Implementation Mechanisms", Work in Progress. [VPN-NEEDS] Jacquenet, C., "Functional needs for the deployment of an IP VPN service offering : a service provider perspective", Work in Progress. [Y.1311.1] Carugi, M. (editor), "Network Based IP VPN over MPLS architecture", Y.1311.1 ITU-T Recommendation, July 2001. [Y.1311] Knightson, K. (editor), "Network based VPNs - Generic Architecture and Service Requirements", Y.1311 ITU-T Recommendation, March 2002.
Authors' Addresses
Marco Carugi (co-editor) Nortel Networks Parc d'activites de Magny-Chateaufort Les Jeunes Bois - MS CTF 32B5 - Chateaufort 78928 YVELINES Cedex 9 - FRANCE EMail: marco.carugi@nortel.com Dave McDysan (co-editor) MCI 22001 Loudoun County Parkway Ashburn, VA 20147, USA EMail: dave.mcdysan@mci.com Luyuan Fang AT&T 200 Laurel Ave - Room C2-3B35 Middletown, NJ 07748 USA EMail: Luyuanfang@att.com Ananth Nagarajan Juniper Networks EMail: ananth@juniper.net Junichi Sumimoto NTT Communications Corporation 3-20-2 Nishi-Shinjuku, Shinjuku-ku, Tokyo 163-1421, Japan EMail: j.sumimoto@ntt.com Rick Wilder Alcatel EMail: rick.wilder@alcatel.com
Full Copyright Statement Copyright (C) The Internet Society (2005). 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.