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. Basis and Presentation Techniques of Management Information
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.