included in profiles as part of the security management system.
6.9.2. Authentication Services
A service provider MUST provide authentication services in support of
temporary user access requirements, as described in section 5.11.2.
Furthermore, traffic exchanged within the scope of VPN MAY involve
several categories of equipment that must cooperate to provide the
service [Y.1311.1]. These network elements can be CE, PE, firewalls,
backbone routers, servers, management stations, etc. These network
elements learn about each other’s identity, either via manual
configuration or via discovery protocols, as described in section
6.4. When network elements must cooperate, these network elements
SHALL authenticate peers before providing the requested service.
This authentication function MAY also be used to control access to
network resources.
The peer identification and authentication function described above
applies only to network elements participating in the VPN. Examples
include:
- traffic between a CE and a PE,
- traffic between CEs belonging to the same VPN,
- CE or PE routers dealing with route announcements for a VPN,
- policy decision point [RFC3198] and a network element, and
- management station and an SNMP agent.
For a peer authentication function, each L3VPN solution SHOULD
describe where necessary, how it shall be implemented, how secure it
must be, and the way to deploy and maintain identification and
authentication information necessary to operate the service.
6.9.3. Resource Protection
Recall from the definitions in section 3.3 that a site can be part of
an intranet with sites from the only same organization, can be part
of an extranet involving sites from other organizations, can have
access to the Internet, or can have any combination of these scopes
of communication. Within these contexts, a site might be subject to
various attacks coming from different sources. Potential sources of
attack include:
- users connected to the supporting public IP backbone,
- users from the Internet, and
- users from temporary sites belonging to the intranet and/or
extranet VPN the site is part of.
Security threats and risks that a site may encounter include the
following:
- Denial of service, for example mail spamming, access connection
congestion, TCP SYN attacks, and ping attacks
- Intrusion attempts, which may eventually lead to denial of service
(e.g., a Trojan horse attack).
Additional threat scenarios are defined in [VPNSEC]. An L3VPN
solution MUST state how it addresses each potential threat scenario.
The devices in the L3VPN network must provide some means of reporting
intrusion attempts to the service provider resources.
6.10. Inter-AS (SP)VPNs
The scenario for VPNs spanning multiple Autonomous Systems (AS) or
Service Providers (SP) requires standard solutions. The scenario
where multiple ASes are involved is the most general case and is
therefore the one described here. The scenarios of concern are the
CE-based and PE-based L3VPNs defined in section 3.
In each scenario, all applicable SP requirements, such as traffic and
routing isolation, SLAs, management, security, and provisioning.
MUST be preserved across adjacent ASes. The solutions MUST describe
the inter-SP network interface, encapsulation method(s), routing
protocol(s), and all applicable parameters [VPNIW].
An essential pre-condition for an inter-AS VPN is an agreement
between the ASes involved that spells out at least trust, economic,
and management responsibilities.
The overall scalability of the VPN service MUST allow the L3VPN
service to be offered across potentially hundreds of SPs, with the
overall scaling parameters per SP given in [RFC3809].
6.10.1. Routing Protocols
If the link between ASes is not trusted, routing protocols running
between those ASes MUST support some form of authentication. For
example, the TCP option for carrying an MD5 digest may be used to
enhance security for BGP [RFC2385].
BGP MUST be supported as the standard inter-AS routing protocol to
control the path taken by L3VPN traffic.
6.10.2. Management
The general requirements for managing a single AS apply to a
concatenation of ASes. A minimum subset of such capabilities as
follows:
- Diagnostic tools (e.g., ping, traceroute)
- Secured access to one AS management system by another
- Configuration request and status query tools
- Fault notification and trouble-tracking tools
6.10.3. Bandwidth and QoS Brokering
When a VPN spans multiple ASes, a brokering mechanism is desired that
requests certain SLA parameters, such as bandwidth and QoS, from the
other domains and/or networks involved in transferring traffic to
various sites. Although bandwidth and QoS brokering across multiple
ASes is not common in today’s networks, these may be desirable for
maintaining SLAs in inter-AS VPNs. This section describes
requirements for features that would facilitate these mechanisms.
The objective is that a solution SHOULD be able to determine whether
a set of ASes can establish and guarantee uniform QoS in support of
an L3VPN.
The brokering mechanism can be a manual one, for example, in which
one provider requests from another a specific set of bandwidth and
QoS parameters for traffic going to and from a specific set of sites.
The mechanism could also be an automated one where a device
dynamically requests and receives certain bandwidth and SLA/QoS
parameters. For instance, in the case of an L3VPN over MPLS, a PE
may negotiate the label for different traffic classes to reach a PE
residing in a neighboring AS. Or, it might be a combination of both.
For additional detailed requirements on the automated approach, see
[TE-INTERAS].
Brokering on a per VPN basis is not desirable as this approach would
not scale. A solution MUST provide some means to aggregate QoS and
bandwidth brokering requests between ASes. One method could be for
SPs to make an agreement specifying the maximum amount of bandwidth
for specific QoS parameters for all VPN customers using the SP
network. Alternatively, such aggregation might be on a per
hierarchical tunnel basis between PE routers in different ASes
supporting an L3VPN service [TE-INTERAS].
6.10.4. Security Considerations
If a tunnel traverses multiple SP networks and passes through an
unsecured SP, POP, NAP, or IX, then security mechanisms MUST be
employed. These security mechanisms include encryption,
authentication, and resource protection, as described in section 6.9,
and security management, as covered in section 7.5. For example, a
provider should consider using both authentication and encryption for
a tunnel used as part of an L3VPN that traverses another service
provider’s network.
6.11. L3VPN Wholesale
The architecture MUST support the possibility of one service provider
offering VPN service to another service provider. Another example is
when one service provider sells L3VPN service at wholesale to another
service provider, who then resells that VPN service to his or her
customers.
The wholesaler’s VPN MUST be transparent to the addressing and
routing used by the reseller.
Support for additional levels of hierarchy (for example, three levels
at which a reseller can again resell the VPN service to yet another
VPN provider) SHOULD be provided.
The Carrier’s Carrier scenario is the term used in this document for
this category of L3VPN wholesale (although some scenarios of Inter-
AS/Inter-Provider VPN could possibly fall in this L3VPN wholesale
category, too). Various carrier’s carrier scenarios should be
supported, such as when
- the customer carriers do not operate L3VPN services for their
clients;
- the customer carriers operate L3VPN services for their clients,
but these services are not linked with the L3VPN service offered
by the Carrier’s Carrier and
- the customer carriers operate L3VPN services for their clients,
and these services are linked with the L3VPN service offered by
the Carrier’s Carrier ("Hierarchical VPNs" scenario).
6.12. Tunneling Requirements
Connectivity between CE sites or PE devices in the backbone SHOULD
use a range of tunneling technologies, such as L2TP, IPSEC, GRE, IP-
in-IP, and MPLS.
To set up tunnels between routers, every router MUST support static
configuration for tunneling and MAY support a tunnel setup protocol.
If employed, a tunnel establishment protocol SHOULD be capable of
conveying information such as the following:
- Relevant identifiers
- QoS/SLA parameters
- Restoration parameters
- Multiplexing identifiers
- Security parameters
There MUST be a means to monitor the following aspects of tunnels:
- Statistics, such as amount of time spent in the up and down state.
- Count of transitions between the up and down state.
- Events, such as transitions between the up and down states.
The tunneling technology used by the VPN Service Provider and its
associated mechanisms for tunnel establishment, multiplexing, and
maintenance MUST meet the requirements on scaling, isolation,
security, QoS, manageability, etc.
6.13. Support for Access and Backbone Technologies
This section describes requirements for aspects of access and
backbone network technologies from an SP point of view.
Some SPs MAY desire that a single network infrastructure suffices for
all services, public IP, VPNs, traffic engineering, and
differentiated services [L2VPN].
6.13.1. Dedicated Access Networks
Ideally, the L3VPN service SHOULD be independent of physical, link
layer, or even network technology of the access network. However,
the characteristics of access networks MUST be accounted for when the
QoS aspects of SLAs for VPN service offerings are specified.
6.13.2. On-Demand Access Networks
Service providers SHOULD be able to support temporary user access, as
described in section 5.11.2, by using dedicated or dial-in access
network technology.
L3VPN solutions MUST support the case where a VPN user directly
accesses the VPN service through an access network connected to the
service provider. They MUST also describe how they can support the
case where one or more other service provider networks are used for
access to the service provider supporting the L3VPN service.
Ideally, all information necessary to identify and authenticate users
for an intranet SHOULD be stored and maintained by the customer. In
an extranet, one customer SHOULD be able to maintain the
authentication server, or the customers involved in the extranet MAY
choose to outsource the function to a service provider.
Identification and authentication information could be made available
to the service provider for controlling access, or the service
provider may query a customer maintained server. Furthermore, one SP
may act as access for the SP providing the VPN service. If the
access SP performs identification and authentication on behalf of the
VPN SP, an agreement MUST be reached on a common specification.
Support for at least the following authentication protocols SHALL be
supported: PAP, CHAP, and EAP, as they are currently used in a wide
range of equipment and services.
6.13.3. Backbone Networks
Ideally, the backbone interconnecting SP, PE, and P devices SHOULD be
independent of physical and link layer technology. Nevertheless, the
characteristics of backbone technology MUST be taken into account
when specifying the QoS aspects of SLAs for VPN service offerings.
6.14. Protection, Restoration
When primary and secondary access connections are available, an L3VPN
solution MUST provide restoration of access connectivity whenever the
primary access link from a CE site to a PE fails. This capability
SHOULD be as automatic as possible, that is, the traffic should be
directed over the secondary link soon after failure of the primary
access link is detected. Furthermore, reversion to the primary link
SHOULD be dynamic, if configured to do so [VPN-NEEDS].
As mentioned in section 5.11.4, in the case of multi-homing, the load
balancing capability MAY be used to achieve a degree of redundancy in
the network. In the case of failure of one or more (but not all) of
the multi-homed links, the load balancing parameters MAY be
dynamically adjusted to redirect the traffic rapidly from the failed
link(s) to the surviving links. Once the failed link(s) is (are)
restored, the original provisioned load balancing ratio SHOULD be
restored to its value prior to the failure.
An SP SHOULD be able to deploy protection and restoration mechanisms
within his or her backbone infrastructure to increase reliability and
fault tolerance of the VPN service offering. These techniques SHOULD
be scalable, and therefore should strive not to perform such function
in the backbone on a per-VPN basis.
Appropriate measurements and alarms that indicate how well network
protection and restoration mechanisms are performing MUST be
supported.
6.15. Interoperability
Service providers are interested in interoperability in at least the
following scenarios:
- Facilitating use of PE and managed CE devices within a single SP
network.
- Implementing L3VPN services across two or more interconnected SP
networks.
- Achieving interworking or interconnection between customer sites
using different L3VPN approaches or different implementations of
the same approach.
Each approach MUST describe whether any of the above objectives can
be met. If an objective can be met, the approach MUST describe how
such interoperability could be achieved. In particular, the approach
MUST describe the inter-solution network interface, encapsulation
method(s), routing protocol(s), security, isolation, management, and
all other applicable aspects of the overall VPN solution provided
[VPNIW].
6.16. Migration Support
Service providers MUST have a graceful means to migrate a customer
with minimal service disruption on a site-by-site basis to an L3VPN
approach.
If L3VPN approaches can interwork or interconnect, then service
providers MUST have a graceful means to migrate a customer with
minimal service disruption on a site-by-site basis whenever
interworking or interconnection is changed.
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.