diff options
Diffstat (limited to 'doc/rfc/rfc4365.txt')
| -rw-r--r-- | doc/rfc/rfc4365.txt | 1795 |
1 files changed, 1795 insertions, 0 deletions
diff --git a/doc/rfc/rfc4365.txt b/doc/rfc/rfc4365.txt new file mode 100644 index 0000000..51fe433 --- /dev/null +++ b/doc/rfc/rfc4365.txt @@ -0,0 +1,1795 @@ + + + + + + +Network Working Group E. Rosen +Request for Comments: 4365 Cisco Systems, Inc. +Category: Informational February 2006 + + + Applicability Statement for BGP/MPLS IP + Virtual Private Networks (VPNs) + +Status of This Memo + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2006). + +Abstract + + This document provides an Applicability Statement for the Virtual + Private Network (VPN) solution described in RFC 4364 and other + documents listed in the References section. + +Table of Contents + + 1. Introduction ....................................................2 + 2. SP Provisioning Model ...........................................4 + 3. Supported Topologies and Traffic Types ..........................6 + 4. Isolated Exchange of Data and Routing Information ...............7 + 5. Access Control and Authentication ...............................9 + 6. Security Considerations .........................................9 + 6.1. Protection of User Data ....................................9 + 6.2. SP Security Measures ......................................10 + 6.3. Security Framework Template ...............................12 + 7. Addressing .....................................................18 + 8. Interoperability and Interworking ..............................19 + 9. Network Access .................................................19 + 9.1. Physical/Link Layer Topology ..............................19 + 9.2. Temporary Access ..........................................19 + 9.3. Access Connectivity .......................................20 + 10. Service Access ................................................21 + 10.1. Internet Access ..........................................21 + 10.2. Other Services ...........................................21 + 11. SP Routing ....................................................22 + 12. Migration Impact ..............................................22 + 13. Scalability ...................................................23 + 14. QoS, SLA ......................................................26 + + + +Rosen Informational [Page 1] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + 15. Management ....................................................27 + 15.1. Management by the Provider ...............................27 + 15.2. Management by the Customer ...............................28 + 16. Acknowledgements ..............................................28 + 17. Normative References ..........................................29 + 18. Informative References ........................................29 + +1. Introduction + + This document provides an Applicability Statement for the Virtual + Private Network (VPN) solution described in [BGP-MPLS-IP-VPN] and + other documents listed in the References section. We refer to these + as "BGP/MPLS IP VPNs", because Border Gateway Protocol (BGP) is used + to distribute the routes, and Multiprotocol Label Switching (MPLS) is + used to indicate that particular packets need to follow particular + routes. The characteristics of BGP/MPLS IP VPNs are compared with + the requirements specified in [L3VPN-REQS]. + + A VPN service is provided by a Service Provider (SP) to a customer + (sometimes referred to as an enterprise). BGP/MPLS IP VPNs are + intended for the situation in which: + + - The customer: + + * uses the VPN only for carrying IP packets. + + * does not want to manage a routed backbone; the customer may + be using routing within his sites, but wishes to outsource + the inter-site routing to the SP. + + * wants the SP to make the backbone and its routing completely + transparent to the customer's own routing. + + If the customer has a routed infrastructure at his sites, he + does not want his site routing algorithms to need to be aware + of any part of the SP backbone network, other than the + Provider Edge (PE) routers to which the sites are attached. + In particular, the customer does not want his routers to need + to be aware of either the native structure of the SP backbone + or an overlay topology of tunnels through the SP backbone. + + - The Service Provider: + + * has an IP backbone, with MPLS-enabled edge routers, and + possibly (though not necessarily) with MPLS-enabled core + routers. + + + + + +Rosen Informational [Page 2] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + * wants to provide a service that meets the customer + requirements above. + + * does not want to maintain a distinct overlay topology of + tunnels for each customer. + + The basic principle is to model each VPN as a self-contained + "internet", where each site makes one or more access connections to + an SP, sends the SP its routing information, and then relies on the + SP to distribute routing information to and from the other sites in + that same VPN. The service differs from Internet service, however, + in that the SP strictly controls the distribution of this routing + information so that routes from within a VPN are not sent outside the + VPN, unless that is explicitly authorized by the customer. In fact, + even within the VPN, the distribution of routes may be controlled by + the SP so as to meet some policy of the customer. + + The routers at a given customer site need not be routing peers of the + routers at other customer sites, and indeed need not know anything + about the internal structure of other customer sites. In fact, + different routing protocols may run at the different sites, with each + site using whatever protocol is most appropriate for that particular + site. + + If EBGP (the BGP procedures used between BGP speakers from different + Autonomous Systems) is used on the access links that connect a + Provider Edge router (PE router) to a Customer Edge router (CE + router), then the SP and the customer do NOT peer in any Interior + Gateway Protocol (IGP), i.e., intra-domain routing algorithm). + + BGP/MPLS IP VPNs are optimized for the situation in which a customer + (an enterprise) expects a service provider to operate and maintain + the customer's "backbone" (i.e., the customer's inter-site routing). + As such, the service provider becomes a "business partner" of the + enterprise. The technical mechanisms accommodate the case in which a + number of closely cooperating SPs can jointly offer the VPN service + to a customer, in that the BGP-based route distribution mechanisms + can operate between different SPs. If a set of SPs has sufficient + agreements with respect to Quality of Service (QoS), Service Level + Agreement (SLA), etc., then the customer's VPN could have sites + attached to different SPs from that set. + + [BGP-MPLS-IP-VPN] specifies the inter-AS (Autonomous System) + mechanisms that allow a single VPN to have sites attached to + different SPs. However, the design center is not an environment + where a given VPN is spread among a very large number (e.g., + hundreds) of SPs. + + + + +Rosen Informational [Page 3] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + In cases where remote offices, individual telecommuters, etc., must + use the public Internet to access the VPN, it is possible to "tunnel" + the remote traffic to a PE router, and the PE router will treat the + traffic as if it had arrived over an interface connected to the PE. + Remote Point-to-Point Protocol (PPP) connections can be tunneled via + Layer 2 Tunneling Protocol (L2TP) to a PE router; IPsec tunnels can + also be used to tunnel traffic to a PE router across the public + Internet. Of course, when the public Internet is used, issues such + as QoS and SLAs must be carefully considered. + + Some customers want to connect their sites over the public Internet, + creating a VPN "virtual backbone", purchasing connectivity for a + given site from whatever Internet Service Provider (ISP) offers the + best price for connecting that site. A BGP/MPLS IP VPN is not an + appropriate solution for such customers; they instead need to + consider solutions (either customer-managed or provider-managed) that + interconnect their sites via an overlay of secure tunnels across the + Internet. (See, for example, [IPSEC-VPN].) + + Some customers who do not want to connect their sites via secure + site-to-site tunnels across the Internet may nevertheless want to + maintain complete control over the routing in their VPN backbone. + These customers will not want a "managed routing service" such as is + provided by BGP/MPLS IP VPNs, since that hides all details of the + backbone routing and topology from the customer. Rather, they may + prefer a "virtual router" service, in which the tunnels through the + SP networks are visible as links to the customer's routing algorithm. + (See, for example, [VR-VPN].) + +2. SP Provisioning Model + + If a particular VPN attaches to a particular PE router, the SP must + configure that PE router with a VPN Routing and Forwarding table + (VRF), a routing table that is specific to the specified VPN. (This + is known as a VPN Forwarding Instance (VFI) in the language of + [L3VPN-REQS] and [L3VPN-FRMWRK].) Each interface or sub-interface at + that PE that attaches to a site in the specified VPN (i.e., each + local access link of that VPN) must be configured so as to be + associated with that VRF. Each such interface may be unnumbered or + may be assigned an address that is unique within the VPN's address + space. In general, a routing algorithm needs to be run on each of + these links (though static routing can be used instead). The routing + algorithm can be EBGP, or an IGP such as Routing Information Protocol + (RIP) or Open Shortest Path First (OSPF). (IF OSPF is used, the + procedures of [VPN-OSPF] MUST be implemented.) If an IGP is run on + the access links, the IGP MUST be a separate IGP instance, different + + + + + +Rosen Informational [Page 4] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + than the IGP instance running among the backbone routers, and + different than the IGP instance running on the access links of any + other VPN. Static routing is also allowed. + + The VRF is populated automatically with routes distributed from + locally attached CE routers via whatever routing algorithm is run on + the PE/CE links. It is also populated automatically with routes + distributed from other VRFs via BGP. Standard routing decision + processes are used to automatically select the proper routes. Static + configuration of routes in the VRF is optional. + + Each PE router must run BGP, and must be pre-configured with the + identities of a small set of BGP Route Reflectors, with which it is + to peer via IBGP. ("IBGP" refers to the BGP procedures used between + BGP speakers from the same Autonomous System.) + + In lieu of using Route Reflectors, one could configure each PE with + the identities of all the other PEs, and set up a full mesh of IBGP + connections. While this might be adequate for small networks, it + would not scale well to large networks; the use of Route Reflectors + is necessary to achieve scalability. See section 4.3.3 of + [BGP-MPLS-IP-VPN] for a more complete discussion of the use of Route + Reflectors, and related scalability mechanisms such as Outbound Route + Filtering. + + Each VRF must be configured with three parameters: + + - A Route Distinguisher. This is a globally unique 8-byte value. + Each VRF may have a unique Route Distinguisher (RD), or there may + be a single unique RD for an entire VPN. When BGP is used to + distribute VPN routing information across the SP backbone, this + value is prepended to the VPN's IPv4 address prefixes, creating a + new address family, the VPN-IPv4 address family. Thus, even when + two VPNs have overlapping IPv4 address spaces, they have unique + VPN-IPv4 address spaces. + + - One or more Export Route Targets. A Route Target (RT) is a + globally unique 8-byte value that BGP carries, as the Extended + Communities Route Target attribute, along with routes that are + exported form the VRF. + + - One or more Import Route Targets. This RT is used to select + routes to be imported from other VRFs into this VRF. + + In the simplest cases and most common cases, the Export RT, Import + RT, and RD can be identical, and all VRFs in the same VPN will + distribute routes to each other (a typical intranet). In more + complex cases, they can be set differently, allowing a very fine + + + +Rosen Informational [Page 5] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + degree of control over the distribution of routes among VRFs. This + can be used to create extranets or to enforce various customer + policies. In complicated cases, particular Export RTs can be + assigned to particular routes using router management mechanisms. + One advantage to not requiring the RD to be the same as any RT is + that this may allow an RD value to be automatically determined for + each VRF; RT values, on the other hand, must always be configured. + + Adding a new site to a VPN is a matter of attaching the site's CE + router to a PE router, configuring the interface, and, if a VRF for + that VPN already exists in the PE router, associating that interface + with the VRF. If a VRF for that VPN does not already exist in the + PE, then one must be configured as specified above. Changes to the + configuration of a PE are automatically reflected via BGP to the + other PEs. + + The RTs and RDs are made unique by being structured as an SP + identifier followed by a number which is assigned by the identified + SP. SPs may be identified by their AS numbers, or by a registered IP + address owned by that SP. + + Although RTs are encoded as BGP Extended Communities, the encoding + itself distinguishes them from any other kind of BGP Extended + Community. + +3. Supported Topologies and Traffic Types + + The scheme is optimized for full inter-site connectivity, in the + sense that this is what the simplest configurations provide. + + However, the SP has full control, through the mechanism of Route + Targets, of the distribution of routing information among the set of + VRFs. This enables the SP to provide hub-and-spoke or partial mesh + connectivity as well as full mesh connectivity. + + Note that, strictly speaking, the scheme does not create a topology, + as it does not create layer 2 connections among the sites. It does, + however, allow for control over the IP connectivity among the sites. + It is also possible to constrain the distribution of routing in + arbitrary ways, e.g., so that data from site A to site B must travel + through a third site C. (In fact, if it is desired to do so, this + level of control can be specified at the granularity of a single + route.) + + It is possible for some of the routes from a particular customer site + A to be distributed to one set of remote sites, while other routes + from site A are distributed to a different set of remote sites. This + is done with the Route Target mechanism previously described. + + + +Rosen Informational [Page 6] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + Unicast IP traffic is fully supported. Customer IP packets are + passed transparently. + + Multicast IP traffic is optionally supported, if the SP provides the + optional mechanisms of [BGP-MPLS-MCAST-VPN]. There are, however, + scaling implications to the use of these mechanisms. Discussion of + these implications is deferred. + + Non-IP traffic is not supported. If support for non-IP traffic is + necessary, either the SP must additionally provide a layer 2 + tunneling service or the customer must use IP tunneling. + + In general, customer routers at different sites do not become routing + peers. However, a customer may, if he so desires, allow routers at + different sites to be routing peers over a link that is NOT part of + the VPN service. Such peering relationships are known as "IGP + backdoors". To ensure the proper operation of routing when IGP + backdoors are present, each VPN route that is distributed by the SP + is distributed along with a corresponding routing metric. This + enables the customer's IGP to compare the "backdoor routes" properly + with the routes that use the SP backbone. In the particular case + where a customer running OSPF within his sites wishes to have IGP + backdoors, he should run OSPF on the PE/CE link, and the PEs should + run the procedures of [VPN-OSPF]. (The CEs do NOT require any + special OSPF procedures.) + +4. Isolated Exchange of Data and Routing Information + + The Route Target mechanism is used to control the distribution of + routing information, so that routes from one VPN do not get sent to + another. VPN routes are treated by BGP as a different address family + than general Internet routes. Routes from a VRF do not get leaked to + the Internet unless the VRF has been explicitly configured to allow + it (and this is NOT the default). + + The way in which a particular VPN is divided into sites, or the + topology of any particular VPN site, is hidden from the Internet and + from other VPNs. (Of course, if a particular site can receive + Internet traffic, and if it responds to traceroute probes from the + Internet, then any user of the Internet can learn something about the + site topology. The fact that the site is in a VPN does not make this + any easier or any harder.) + + Similarly, Internet routes do not get leaked into the VPN, unless a + VRF of that VPN is explicitly configured to import the Internet + routes. + + + + + +Rosen Informational [Page 7] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + Proper configuration is essential to maintaining the isolation. In + particular, each access link must be associated with the proper VRF + for that access link, and each VRF must be configured with the proper + set of RTs. + + A number of means for exchanging reachability information between the + PE and CE devices are supported: static routing, EBGP, and RIP are + supported by the procedures of [BGP-MPLS-IP-VPN]. If the procedures + of [VPN-OSPF] and [OSPF-2547-DNBIT] are implemented, OSPF may be + used. If OSPF is used between two VPN sites that are in the same + OSPF area, and if it is desired for routes over the VPN backbone to + be preferred to the OSPF intra-site routes, then the "sham link" + procedures of [VPN-OSPF] must be used. + + The routing protocols used among the customer routers are not in any + way restricted by the VPN scheme, as whatever IGP is used within the + VPN, the PE/CE access links may run EBGP, or may otherwise be in a + different routing domain than the site's internal links. + + BGP is used for passing routing information among SPs. BGP may be + authenticated by use of the TCP MD5 option, or by operating through + an IPsec tunnel. + + Data traveling between two customer sites is encapsulated while in + transit through the backbone. The encapsulation contains sufficient + information to ensure that the packet is sent to the proper PE + router, and then, in conjunction with the VRF and related information + at that PE, to the proper CE routers. + + If two VPNs attach to the same PE, there is strict separation of + forwarding at that PE, as well as strict separation of the routing + information. + + Isolation of traffic is similar to that provided by classical L2 VPNs + which are based on Frame Relay or Asynchronous Transfer Mode (ATM). + As in classical L2 VPNs, the customer must rely on the SP to properly + configure the backbone network to ensure proper isolation and to + maintain the security of his communications gear. + + + + + + + + + + + + + +Rosen Informational [Page 8] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + +5. Access Control and Authentication + + No particular means of PE/CE authentication is specified for BGP/MPLS + IP VPNs. PE/CE mutual authentication may be done via any mechanism + supported by the routing protocol in which the CE and PE are peers + (e.g., use of the TCP MD5 authentication when the PE/CE protocol is + BGP), or by any other mechanism that may be desired. With such + mechanisms in place, a CE may not join a VPN until the CE + authenticates itself to the Service Provider. + + There is, however, no standardized method that requires a CE to + authenticate itself to the customer network (rather than to the SP) + before the CE is allowed to join the VPN. This is for further study. + + No particular means is specified for controlling which user data + packets can be forwarded by BGP/MPLS IP VPNs. BGP/MPLS IP VPNs are + compatible with Access Control Lists (ACLs) and any other filtering + features that are supported on the PE routers. Routing can be set up + so that extranet traffic is directly through a firewall, if that is + desired. + + It is possible for various sorts of "tunnel interfaces" to be + associated with a VRF. In this case, whatever authentication is + natively used in the establishment of the tunnel interface may be + used. For example, an IPsec tunnel can be used as an "access link" + to attach a remote user or site to a VRF. The authentication + procedure in this case is part of IPsec, not part of the VPN scheme. + + Where L2TP is used, each PPP session carried in an L2TP tunnel can be + associated with a VRF. The SP's Authentication, Authorization, and + Accounting (AAA) server can be used to determine the VPN to which the + PPP session belongs, and then the customer's AAA server can be given + the opportunity to authenticate that session as well. + +6. Security Considerations + +6.1. Protection of User Data + + No particular means of ensuring user data security is specified for + BGP/MPLS IP VPNs. + + The optional procedures of [MPLS/BGP-IPsec] may be used to provide + authentication and/or encryption of user data as it travels from the + ingress PE to the egress PE. However, the data is exposed at those + two PEs, as well as on the PE/CE access links. + + + + + + +Rosen Informational [Page 9] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + The customer may provide his own user data security by using IPsec + tunnels that terminate within the customer sites. Such tunnels are + transparent to the VPN scheme. Schemes that discover the remote + tunnel endpoints automatically and then set up the tunnels + automatically as needed are the best fit with this VPN technology. + Note that there is no requirement in general that IPsec tunnels + between customer sites terminate at CE routers. + + The use of end-to-end transport mode IPsec by the customer is also + transparent to the VPN scheme. In fact, the VPN scheme is compatible + with any use of security by the customer, as long as a cleartext IP + header is passed from CE to PE. + + When data must cross the Internet to reach the ingress PE router, + IPsec tunnels between the end user and the PE router can be used; the + PE router must then associate each IPsec tunnel with the proper VRF. + This association would have to be based on user-specific information + provided by the Internet Key Exchange (IKE) protocol, such as a VPN- + id. + + If data is going from one SP network to another, and must cross the + public Internet to get between those two networks, IPsec tunnels can + be used to secure the data. This would require bilateral agreement + between the two SPs. BGP connections can also be passed through an + IPsec tunnel if this is deemed necessary, in order to protect user + data, by a pair of SPs. QoS/SLA factors would have to be carefully + considered in this case. + +6.2. SP Security Measures + + The SP is responsible for preventing illegitimate traffic from + entering a VPN. VPN traffic is always encapsulated while traveling + on the backbone, so preventing illegitimate traffic is a matter of + ensuring that the PE routers to the encapsulation/decapsulation + correctly and that encapsulations have not been "spoofed", i.e., that + the encapsulated packets were actually encapsulated by PE routers. + + This requires the SP to take various security measures. The PE and P + routers must themselves be secure against break-ins (either from + someone physically present or from the Internet), and neither P nor + PE routers should form routing adjacencies to other P or PE routers + without benefit of some kind of security. This may be authentication + in the IGP, or physical security. + + + + + + + + +Rosen Informational [Page 10] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + The PE/CE access link should be secured in some manner, though the + provider may make it the responsibility of the customer to ensure + that the CE is secure from compromise. If the PE/CE access link is a + tunnel over the Internet, then of course some sort of authentication + protocol should always be used. + + Label Distribution Protocol (LDP) sessions and BGP sessions between + PE and/or P routers should be authenticated. This can be done via + the TCP MD5 option or by use of IPsec. + + If the SP is providing the VPN service over an MPLS backbone, it + should not accept MPLS packets from its external interfaces (i.e., + interfaces to CE devices or to other providers' networks) unless the + top label of the packet was legitimately distributed to the system + from which the packet is being received. If the packet's incoming + interface leads to a different SP (rather than to a customer), an + appropriate trust relationship must also be present, including the + trust that the other SP also provides appropriate security measures. + + If the SP is providing the VPN service by using an IP (rather than an + MPLS) encapsulation, or if it accepts IP-encapsulated VPN packets + from other SPs, it should apply filtering at its borders so that it + does not accept from other SPs or from customers any IP packets that + are addressed to the PE routers, unless appropriate trust + relationships are in place. + + Cryptographic authentication of the encapsulated data packets is + certainly advantageous when there are multiple SPs providing a single + VPN. + + When a dynamic routing protocol is run on the link between a CE + router and a PE router, routing instability in the private network + may have an effect on the PE router. For example, an unusually large + number of routing updates could be sent from the CE router to the PE + router, placing an unusually large processing load on the PE router. + This can potentially be used as a Denial-of-Service (DoS) attack on + the PE router. + + This issue can be mitigated via resource partitioning in the PE, in + order to limit the amount of resources (e.g., CPU and memory) that + any one VPN is permitted to use in PE routers. Also, rate limits may + be applied to the routing traffic sent from the CE to the PE. + Alternately, when this problem is detected, the CE-to-PE interface + may be shut down. + + Network management traffic from the CE to the PE may be rate limited + (for example, to prevent network management traffic from CE to PE to + be used in a DoS attack). + + + +Rosen Informational [Page 11] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + +6.3. Security Framework Template + + Section 9 of [L2VPN-SEC-FRMWRK] provides "a brief template that may + be used to evaluate and summarize how a given PPVPN [Provider- + Provisioned Virtual Private Network] approach (solution) measures up + against the PPVPN Security Framework". It further states "an + evaluation using this template should appear in the applicability + statement for each PPVPN approach". The purpose of this subsection + is to provide the information in the form required by this template. + Security requirements that are relevant only to L2VPNs are not + applicable and are not further discussed. + + - Does the approach provides complete IP address space separation + for each L3VPN? + + Yes. + + The IP address prefixes from a particular VPN appear in their + native form only in routing tables that are specific to the + particular VPN. They are distributed in their native form only + by routing instances that are specific to the particular VPN. + When address prefixes from different VPNs are combined into a + common table, or distributed by a common mechanism, the address + prefixes are first prepended with a Route Distinguisher (RD). + The RD is a 64-bit quantity, structured so that globally unique + RD values can easily be created by an SP. As long as no two VPNs + are assigned the same RD value, complete IP address space + separation is provided. It is however possible for an SP to + misconfigure the RD assignments. + + - Does the approach provide complete IP route separation for each + L3VPN? + + Yes. + + The distribution of routes is controlled by assigning import and + export Route Targets (RTs). A route that is exported from a VRF + carries an RT specified by the SP as an export RT for that VRF. + The route can be imported into other VRFs only if the RT that it + carries has been configured by the SP as an import RT for those + other VRFS. Thus, the SP has complete control over the set of + VRFs to which a route will be distributed. It is of course + possible for the SP to misconfigure the RT assignments. + + + + + + + + +Rosen Informational [Page 12] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + - Does the approach provide a means to prevent improper cross- + connection of sites in separate VPNs? + + This requirement is addressed in a way that is beyond the scope + of the VPN mechanisms. + + In BGP/MPLS IP VPNs, an SP makes a particular site part of a + particular VPN by configuring the PE router's interface to that + site to be associated with a particular VRF in that PE. The VRF + is configured with import and export RTs, and it is the way in + which VRFs are configured with RTs in the various PEs that + results in a particular set of sites being connected as a VPN. + + Connecting the sites properly in this way is regarded as a + network management function, and the VPN scheme itself does not + provide a means to prevent misconfiguration. + + The VPN scheme does not provide any particular method for + ensuring that a given interface from a PE leads to the CE that is + expected to be there. If a routing algorithm is run on a + particular PE/CE interface, any security procedures that the + routing algorithm provides (e.g., MD5 authentication of BGP + sessions) can be used; this is outside the scope of the VPN + scheme. Also, a CE can attach to a PE via an IPsec tunnel, if + this is desired, for a greater degree of security. + + - Does the approach provide a means to detect improper cross- + connection of sites in separate VPNs? + + The base specifications for BGP/MPLS IP VPNs do not provide a + means for detecting that a site has been connected to the wrong + VPN. However, the optional procedure specified in [CE-VERIF] + does provide such a means. Basically, each PE obtains, via + protocol, a secret from each CE to which it is directly attached. + When the routes from a given CE are distributed, the secret from + that CE is attached as an attribute of the route. This secret + will ultimately be distributed to any other CE that receives any + route from the given CE. A CE that is not supposed to be part of + a given VPN will not know the right secret, and if it is + connected to the given VPN the other CEs in that VPN will realize + that a CE that doesn't know the proper secret has been connected + to the VPN. + + - Does the approach protect against the introduction of + unauthorized packets into each VPN? + + We must look separately at the various points at which one might + attempt to introduce unauthorized packets. + + + +Rosen Informational [Page 13] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + * Packets arriving at a PE over a PE/CE interface + + If a given PE is directly connected to a given CE, the PE + will accept any packets that the CE sends it. The VPN scheme + has no special procedures for determining that these packets + actually came from the CE. However, various means of + securing the PE/CE connection can be used (for instance, the + PE and CE can be connected by an IPsec tunnel) if desired. + That is, this aspect of the requirement can be addressed by + means that are outside the scope of the VPN specification. + + Once a packet has been accepted from a CE by a PE, the packet + is routed according to the VRF associated with that PE's + interface to that CE. Such packets can only be sent along + routes that are in that VRF. There is no way a packet from a + CE can be routed to an arbitrary VPN. In particular, there + is nothing a VPN user can do to cause any particular packet + to be sent to the wrong VPN. So this aspect of the + requirement is fully addressed. + + * Packets arriving at a PE over an interface from the backbone + + The optional procedures of [MPLS/BGP-IPsec] can be used to + ensure that a packet that is received by a PE from the + backbone will not be recognized as a VPN packet unless it + actually is one. Those procedures also ensure that a + received VPN packet came from a particular PE and that it + carries the MPLS label that that PE put on it. These + procedures protect the packet from ingress PE to egress PE, + but do not protect the PE/CE interfaces. + + If the optional procedures of [MPLS/BGP-IPsec] are not used, + then the following considerations apply. + + Undetected corruption of the routing information carried in a + packet's VPN encapsulation can result in misdelivery of the + packet, possibly to the wrong VPN. + + If a packet enters an SP's network on an interface other than + a PE/CE interface, the SP should ensure that the packet + either does not look like a VPN packet or else is not routed + to a PE router. This can be done in a variety of ways that + are outside the scope of the VPN scheme. For example, IP + packets addressed to the PE routers can be filtered, MPLS + packets (or, e.g., MPLS-in-IP) from outside the SP network + can be refused, etc. + + + + + +Rosen Informational [Page 14] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + In the case of a multi-provider L3VPN backbone, the SP will + have to know which interfaces lead to SPs that are VPN + partners, so that VPN packets can be allowed to flow on those + interfaces. + + If the public Internet is used as the L3VPN backbone, + protection against unauthorized packets cannot be achieved by + the above measures. IPsec tunnels should always be used to + carry VPN traffic across the public Internet. + + - Does the approach provide confidentiality (secrecy) protection, + sender authentication, integrity protection, or protection + against replay attacks for PPVPN user data? + + If these are desired, they must be provided by mechanisms that + are outside the scope of the VPN mechanisms. For instance, the + users can use secure protocols on an end-to-end basis, e.g., + IPsec, Secure Shell (SSH), Secure Sockets Layer (SSL), etc. + + - Does the approach provide protection against unauthorized traffic + pattern analysis for PPVPN user data? + + Preventing an observer from obtaining traffic pattern analysis + from the SP network is beyond the scope of the VPN mechanisms. + + - Do the control protocol(s) used for each of the following + functions provide for message integrity and peer authentication? + + * VPN membership discovery + + This requirement is fully satisfied. Membership discovery is + done by means of BGP. Control message integrity and peer + authentication in BGP may be achieved by use of the TCP MD5 + option. + + * Tunnel establishment + + The answer to this question depends of course on the tunnel + protocol and tunnel establishment protocol; a variety of + different tunneling schemes can be used in BGP/MPLS IP VPNs. + Thus, this question is out of scope. + + In the common case where the tunnels are MPLS Label Switching + Routers (LSRs) established by LDP, then control message + integrity and peer authentication may be achieved by use of + the TCP MD5 option. + + + + + +Rosen Informational [Page 15] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + * VPN topology and reachability advertisement + + With respect to PE-PE interactions, the relevant control + protocol is BGP, so control message integrity and peer + authentication can be achieved by use of the TCP MD5 option. + + With respect to CE-PE interactions, the answer depends on the + protocol used for exchanging information between PE and CE, + as the security mechanisms (if any) of those protocols would + need to be used. In the common case where the PE/CE protocol + is BGP, the TCP MD5 option can be used. + + * VPN provisioning and management + + The protocols procedures for provisioning VPNs and managing + the PE routers are outside the scope of the VPN scheme. + + * VPN monitoring and attack detection and reporting + + The protocols and procedures for monitoring the VPNs are + outside the scope of the VPN scheme. + + - What protection does the approach provide against PPVPN-specific + DoS attacks (i.e., inter-trusted-zone DoS attacks)? + + * 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. + + The PE/CE interfaces of a given VPN will generally be + addressable from within that VPN. Apart from that, a user + within an L3VPN has no more access to the service provider + infrastructure than does any user of the Internet. + Therefore, we will focus in this section on possible DoS + attacks against a PE router that may occur when traffic from + within a VPN is addressed to a PE router. + + A user within the VPN may address traffic to a PE router and + may attempt to send an excessive amount of traffic to it. + Presumably, the PE routers will not accept unauthorized TCP + connections or Simple Network Management Protocol (SNMP) + commands, so such traffic will be thrown away; the danger is + that the PE may need to use a significant proportion of its + capacity to discard such traffic. However, this case is no + different than the case of any SP access router that attaches + to subscriber equipment. The presence of the VPN mechanisms + does not make the PE any more or less vulnerable to DoS + attacks from arbitrary end users. + + + +Rosen Informational [Page 16] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + * Protection of the service provider infrastructure against + Data Plane or Control Plane DoS attacks originated in the + Internet and aimed at PPVPN mechanisms. + + DoS attacks of this sort can be prevented if the PE routers + are not addressable from the Internet. Alternatively, an SP + can apply address filtering at its boundaries so that packets + from the Internet are filtered if they are addressed to a PE + router. + + * 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. + + Mechanisms already discussed prevent users in a VPN from + receiving packets from the Internet, unless this is + specifically allowed. In the case where it is specifically + allowed, it is no different than any other situation in which + a network is connected to the Internet, and there is no + special vulnerability to DoS attacks due to the L3VPN + mechanisms. + + There is nothing to prevent a user in a VPN from mounting a + DoS attack against other users in the VPN. However, the + L3VPN mechanisms make this neither more nor less likely. + + - Does the approach provide protection against unstable or + malicious operation of a PPVPN user network? + + * Protection against high levels of, or malicious design of, + routing traffic from PPVPN user networks to the service + provider network. + + If a dynamic routing algorithm is running on the PE/CE + interface, it can be used to mount an attack on the PE + router, by having the CE present the PE with an excessive + number of routing events. If an end user within a VPN + successfully attacks the routing algorithm of the VPN, that + might also result in an excessive number of routing events + being seen by the PE router. This sort of attack can be + ameliorated by having the PE limit the amount of its + resources that can be expended processing routing events from + a particular VPN. If the PE/CE routing algorithm is BGP, + then such mechanisms as route flap damping may be appropriate + as well. + + + + + + +Rosen Informational [Page 17] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + * Protection against high levels of, or malicious design of, + network management traffic from PPVPN user networks to the + service provider network. + + A user in a BGP/MPLS IP VPN has no more ability than any + Internet user to send management traffic to the service + provider network. + + * Protection against worms and probes originated in the PPVPN + user networks, sent towards the service provider network. + + A user in a BGP/MPLS IP VPN has no more ability than any + Internet user to send worms or probes to the service provider + network. + +7. Addressing + + Overlapping customer addresses are supported. There is no + requirement that such addresses be in conformance with [RFC1918]. + There is no requirement that customer VPN addresses be distinct from + addresses in the SP network. + + Any set of addresses used in the VPN can be supported, irrespective + of how they are assigned, how well they aggregate, and whether they + are public or private. However, the set of addresses that are + reachable from a given site must be unique. + + Network address translation for packets leaving/entering a VPN is + possible and is transparent to the VPN scheme. + + There is nothing in the architecture to preclude the mechanisms from + being extended to support IPv6, provided that the appropriate IPv6- + capable routing algorithms are in place. That is, PE/CE routing must + support IPv6, and the PE-PE BGP must support the labeled IPv6 address + family. The latter has not been specified, but its specification is + obvious from the specification of the labeled IPv4 address family. + The IGP used in the SP backbone need not be IPv6 capable in order to + support customer IPv6 networks. + + In theory, the same could be said of other network layers, but in + practice a customer who has non-IP traffic to carry must expect to + carry it either in site-to-site IP tunnels or using some additional + service (such as a layer 2 service) from the SP. + + Layer 2 addresses and identifiers are never carried across the SP + backbone. + + + + + +Rosen Informational [Page 18] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + No restrictions are placed on the customer's addressing schemes or + policies. Note though that the SP may place restrictions on the + number of routes from a given customer site, or may charge + differentially depending on the number of such routes, and such + restrictions may have implications for the customer's addressing + scheme. In particular, addressing schemes that facilitate route + aggregation on a per-site basis will result in the most efficient use + of the SP's resources, and this may be reflected in SP charging + policies. + +8. Interoperability and Interworking + + Interoperability should be ensured by proper implementation of the + published standards. + + Direct PE-PE interworking over the SP backbone with other VPN + solutions is not supported. + + As all the different types of L3VPNs are IP networks, they can of + course interwork in the same way that any two IP networks can + interwork. For example, a single site can contain a CE router of one + VPN scheme and a CE router of another VPN scheme, and these CE + routers could be IGP peers, or they might even be the same CE router. + This would result in the redistribution of routes from one type of + VPN to the other, providing the necessary interworking. + +9. Network Access + +9.1. Physical/Link Layer Topology + + The architecture and protocols do not restrict the link layer or the + physical layer in any manner. + +9.2. Temporary Access + + Temporary access via PPP is possible, using industry standard PPP- + based authentication mechanisms. For example: + + - A dial-up user (or other PPP user) is authenticated by the PE, + using the SP's AAA server, based on a login string or on the + number dialed. + + - The SP's AAA server returns a VPN-id to PE. + + - The PE assigns the user to a VRF, based on that VPN-id. + + + + + + +Rosen Informational [Page 19] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + - The user is then authenticated by a AAA server within the VPN + (i.e., managed by the customer rather than by the SP). This AAA + server would typically be addressed through the VRF (i.e., may be + in VPN's private address space). + + - The user gets disconnected if either authentication step is + unsuccessful. + + IPsec access to a VRF is also possible. In this case, the security + association is between the end user and the SP. + + In these ways, a user can access a BGP/MPLS IP VPN via the public + Internet. + + There is no explicit support for mobility, other than what is stated + above. + +9.3. Access Connectivity + + Homing of a CE to two or more PEs is fully supported, whether or not + the PEs are on the same SP network. + + If a CE is connected to two or more PEs, all its PE/CE links can be + used to carry traffic in both directions. In particular, traffic + from different ingress PEs to a particular CE may arrive at that CE + over different PE/CE links. This depends on the backbone network + routing between the CE and the various ingress PEs. + + If a VRF on a particular ingress PE contains several routes to a + particular destination, then traffic from that ingress PE can be + split among these routes. If these routes end with different PE/CE + links, then traffic from that ingress PE will be split among those + links. + + BGP contains a multitude of knobs that allow an SP to control the + traffic sent on one PE/CE link as opposed to the other. One can also + make use of the Link Bandwidth extended community [BGP-EXT-COMM] to + control how traffic is distributed among multiple egress PE/CE links. + + The VPN scheme is of course compatible with the use of traffic + engineering techniques, Resource Reservation Protocol - Traffic + Engineering (RSVP-TE) based or otherwise, in the backbone network. + + + + + + + + + +Rosen Informational [Page 20] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + +10. Service Access + +10.1. Internet Access + + Internet access and VPN access are possible from the same site. This + is even possible over the same interface, as long as the VPN's + internal addresses are distinct from the addresses of the systems + that must be reached via the Internet. This requires only that + Internet routes as well as VPN routes be imported into the VRF + associated with that interface. This may be as simple as putting a + default route to the Internet into that VRF. + + The "route to the Internet" that is in a particular VRF need not lead + directly to the Internet; it may lead to a firewall or other security + device at another site of the VPN. The VPN customer can cause this + to happen simply by exporting a default route from the site with the + firewall. Generally, a site with a firewall will use a different + virtual interface for Internet access than for VPN access, since the + firewall needs to distinguish the "clean interface" from the "dirty + interface". + + In such a configuration, the customer would export his routes to the + Internet via the firewall's dirty interface, but would export the + same routes to the VPN via the clean interface. Thus, all traffic + from the Internet would come through the dirty interface, then + through the firewall, and possibly go to another VPN site though the + clean interface. This also allows any necessary Network Address + Translation (NAT) functionality to be done in the firewall. + +10.2. Other Services + + Any externally provided service can be accessed from the VPN, + provided that it can be addressed with an address that is not + otherwise in use within the VPN. Access can be firewalled or non- + firewalled. If the client accessing the service does not have a + globally unique IP address, and a single server provides a service to + multiple VPNs, NAT will have to be applied to the client's packets + before they reach the server. This can be done at a customer site, + or by a VRF-specific NAT function in a PE router. + + + + + + + + + + + + +Rosen Informational [Page 21] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + +11. SP Routing + + Routing through the backbone is independent of the VPN scheme and is + unaffected by the presence or absence of VPNs. The only impact is + that the backbone routing must carry routes to the PE routers. + + The VPN routes themselves are carried in BGP as a distinct address + family, different than the address family that is used to carry + "ordinary" IP routes. These routes are passed from PE router to + Route Reflector to PE router, and are never seen by the P routers. + The Route Reflectors that carry the VPN routes can be entirely + separate from the Route Reflectors that carry the "ordinary" IP + routes. + + The fact that two PE routers support a common VPN does not require + those PE routers to form an IGP routing adjacency between themselves. + The number of adjacencies in the backbone IGP is independent of and + unrelated to the number of VPNs supported by any set of PE routers. + + No VPN-specific protection and restoration mechanisms are needed; + these are general routing considerations, and the VPN scheme is + compatible with any protection and restoration mechanisms that may be + available. + + The SP does not manage the customer's IGP in any way, and routes are + never leaked between the SP's IGP and any customer's IGP. + + If the PE/CE protocol is EBGP, the SP and the customer do not ever + participate in a common IGP. + +12. Migration Impact + + Generally, this means replacement of an existing legacy backbone with + VPN backbone. The general migration mechanism would be to hook up + the sites one at a time to the VPN backbone, and to start giving the + routes via the VPN backbone preference to routes via the legacy + backbone. Details depend on the legacy backbone's IGP. In general, + one would have to manipulate the IGP metrics to provide the proper + route preference. + + If the legacy backbone routing protocol is OSPF, then migration is + best done with OSPF as the PE/CE protocol and the PE supporting the + [VPN-OSPF] procedures, OR with BGP as the PE/CE protocol, and the CE + supporting the BGP/OSPF interaction specified in [VPN-OSPF]. + + With other legacy backbone routing protocols, the proper metrics must + be set at the point (PE or CE) where the BGP routes from the SP + network are being redistributed into the legacy IGP. + + + +Rosen Informational [Page 22] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + +13. Scalability + + There is no upper limit on the number of VPNs per SP network, as + there is no one box in the SP network that needs to know of all VPNs. + Knowledge of a particular VPN is confined to the PE routers that + attach to sites in that VPN, and to the BGP Route Reflectors that + receive routing data from those PEs; other systems maintain no state + at all for the VPN. Note though that there is no need for any one + Route Reflector to know of all VPNs. + + If the SP is providing the VPN service over an MPLS backbone, then + the backbone IGP must carry a host route for every Label Switched + Path (LSP) egress node within the routing domain. Every PE router in + the routing domain is an LSP egress node. If there are VPNs attached + to PE routers that are within the routing domain, as well as PE + routers that are in some second routing domain, then the border + routers leading towards the second routing domain will also be LSP + egress nodes. Thus, the sum of the number of PE routers plus number + of border routers within a routing domain is limited by the number of + routes that can be carried within the domain's IGP. This does not + seem to create any practical scalability issue. + + There is no upper limit on the number of site interfaces per VPN, as + state for a particular interface is maintained only at the PE router + to which that interface attaches. The number of site interfaces per + VPN at a given PE router is limited only by the number of interfaces + that that PE router can support. + + The number of routes per VPN is constrained only by the number of + routes that can be supported in BGP, the number of routes that can be + maintained in the PEs that attach to that VPN, and the number of + routes that can be maintained in the BGP Route Reflectors that hold + the routes of that VPN. + + The major constraint in considering scalability is the number of + routes that a given PE can support. In general, a given PE can + support as many VPNs as it has interfaces (including virtual + interfaces or "sub-interfaces", not just physical interfaces), but it + is constrained in the total number of routes it can handle. The + number of routes a given PE must handle depends on the particular set + of VPNs it attaches to, and the number of routes in each such VPN, + and the number of "non-VPN" Internet routes (if any) that it must + also handle. + + The SP may need to engage in significant planning to ensure that + these limits are not often reached. If these limits are reached, it + may be necessary either to replace the PE with one of larger capacity + or to reorganize the way in which access links lead from CEs to PEs, + + + +Rosen Informational [Page 23] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + in order to better concentrate the set of access links from sites + that are in the same VPN. Rehoming a site to a different PE may not + involve actual rewiring; if the access technology is switched, this + is a matter of provisioning, but may still be a significant + undertaking. If it is necessary to have downtime while performing + the rehoming, the customer is impacted as well. Rehoming can also be + done "virtually", by creating a layer 2 tunnel from a CE's "old" PE + to its "new" PE. + + An important consideration to remember is that one may have any + number of INDEPENDENT BGP systems carrying VPN routes. This is + unlike the case of the Internet, where the Internet BGP system must + carry all the Internet routes. The difference stems from the fact + that all Internet addresses must be reachable from each other, but a + given VPN address is only supposed to be reachable from other + addresses in the same VPN. + + Scalability is also affected by the rate of changes in the + reachability advertisements from CE to PE, as changes reported by a + CE to its attached PE may be propagated to the other PEs. BGP + mechanisms to control the rate of reported changes should be used by + the SP. + + Another constraint on the number of VPNs that can be supported by a + particular PE router is based on the number of routing instances that + the PE router can support. If the PE/CE routing is static, or is + done by BGP, the number of routing protocol instances in a PE device + does not depend on the number of CEs supported by the PE device. In + the case of BGP, a single BGP protocol instance can support all CEs + that exchange routing information using BGP. If the PE/CE router is + done via RIP or OSPF, then the PE must maintain one RIP or OSPF + instance per VRF. Note that the number of routing instances that can + be supported may be different for different routing protocols. + + Inter-AS scenarios constructed according to option (b) of section 10 + of [BGP-MPLS-IP-VPN] require BGP "border routers" to hold the routes + for a set of VPNs. If two SPs share in a small number of VPNs, a + single border router between them provides adequate capacity. As the + number of shared VPNs increases, additional border routers may be + needed to handle the increased number of routes. Again, no single + border router would handle all the routes from all the VPNs, so an + increase in the number of VPNs can always be supported by adding more + border routers. + + Inter-AS scenarios constructed according to option (c) of section 10 + of [BGP-MPLS-IP-VPN] eliminate the need for border routers to contain + VPN routes (thus improving scalability in that dimension), but at the + cost of requiring that each AS have a route to the PEs in the others. + + + +Rosen Informational [Page 24] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + (Inter-AS scenarios constructed according to option (a) of section 10 + of [BGP-MPLS-IP-VPN] do not scale well.) + + The solution of [BGP-MPLS-IP-VPN] is intended to simplify CE and site + operations, by hiding the structure of the rest of the VPN from a + site, and by hiding the structure of the backbone. Thus, CEs need + have only a single sub-interface to the backbone, CEs at one site + need not even be aware of the existence of CEs at another, and CEs at + one site need not be routing peers of CEs at another. CEs are never + routing peers of P routers. These factors help to scale the + customer's network, but limiting the number of adjacencies each CE + must see, and by limiting the total number of links that the + customer's IGP must handle. + + The solution of [BGP-MPLS-IP-VPN] is also intended to simplify the + SP's VPN provisioning, so that potentially the SP will have to do + little more than say which sites belong to which VPNs. However, as + the system scales up, planning is needed to determine which PEs + should home which VPNs, and which BGP RRs should take which VPNs' + routing information. + + P routers maintain NO per-VPN state at all; the only requirement on + them is to maintain routes to the PE routers. When MPLS is used, a P + router must also maintain one multipoint-to-point LSP for each such + route. + + However, certain VPN multicast schemes require per-multicast-group + state in the P routers, summed over all VPNs. Others require only no + state in the P routers at all, but will result in sending more + unnecessary traffic. The complete set of tradeoffs for multicast is + not that well understood yet. + + Note that as the scaling of a particular PE is primarily a matter of + the total number of routes that it must maintain, scalability is + facilitated if the addresses are assigned in a way that permits them + to be aggregated (i.e., if the customers have a sensible addressing + plan). + + When a dynamic routing protocol is run on the link between a CE + router and a PE router, routing instability in the private network + may have an effect on the PE router. For example, an unusually large + number of routing updates could be sent from the CE router to the PE + router, placing an unusually large processing load on the PE router. + + This issue can be mitigated via resource partitioning in the PE, in + order to limit the amount of resources (e.g., CPU and memory) that + any one VPN is permitted to use in PE routers. Also, rate limits may + be applied to the routing traffic sent from the CE to the PE. + + + +Rosen Informational [Page 25] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + Alternately, when this problem is detected, the CE-to-PE interface + may be shut down. + +14. QoS, SLA + + The provision of appropriate QoS capabilities may require any + combination of the following: + + - QoS in the access network. + + - Admission control (policing) by the PE router on the ingress + access links. + + - Traffic conditioning (shaping) by the PE router on the ingress + access links. + + - Traffic engineering in the backbone. + + - Intserv/diffserv classification by the PE, for traffic arriving + from the CE. Once the PE classifies the user packets, this + classification needs to be preserved in the encapsulation (MPLS + or IP) used to send the packet across the backbone. + + - Differentiated Services Codepoint (DSCP) mapping. + + - DSCP transparency. + + - Random Early Discard in the backbone. + + None of these features are VPN-specific. The ability to support them + depends on whether the features are available on the edge and core + platforms, rather than on any particular VPN scheme. + + MPLS support for differentiated services is detailed in RFC 3270 + [MPLS-DIFFSERV]. DSCP mapping and transparency are covered in + section 2.6 of that document. + + It is possible to use traffic engineering to provide, e.g., + guaranteed bandwidth between two PEs for the traffic of a given VPN. + The VRF entries for that VPN in each PE need to be modified so that + the traffic to the other PE is directed onto the traffic-engineered + path. How this is done is a local matter. + + BGP/MPLS IP VPNs can support both the "hose model" and the "pipe + model" of QoS. In the "pipe model", a particular quality of service + (e.g., a guaranteed amount of bandwidth) would be applied to all or + some of the packets traveling between a given pair of CEs. In the + "hose model", a particular quality of service (e.g., a guaranteed + + + +Rosen Informational [Page 26] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + amount of bandwidth) would be applied to all traffic to or from a + particular CE, irrespective of which other CE the traffic is going to + or coming from. Since BGP/MPLS IP VPNs do not usually make use of + CE-CE tunnels, the hose model is the more natural fit. Providing the + pipe model would require the use of traffic engineering to explicitly + create the necessary tunnels. + + Many of the requirements specified in [L3VPN-REQS] stipulate that the + Network Monitoring System (NMS) should support SLA monitoring and + verification between the SP and the various customers by measurement + of the indicators defined within the context of the SLA. The + measurement of these indicators (i.e., counters) can be achieved when + BGP/MPLS IP VPNs are used by employing a combination of the + Management Information Base (MIB) module designed for BGP/MPLS IP + VPNs [L3VPN-MIB] as well as other standard MIB modules such as the + IF-MIB [IF-MIB]. Devices supporting these MIB modules can calculate + SLAs based on real-time performance measurements using indicators and + threshold crossing alerts. Devices can make these thresholds + configurable either via a management interface such as SNMP. + +15. Management + + The L3VPN Requirements document [L3VPN-REQS] stipulates that the term + "Provider Provisioned VPN" refers to VPNs for which the service + provider participates in management and provisioning of the VPN. RFC + BGP/MPLS IP VPNs can be provisioned and managed to meet these + requirements. The following subsections will outline how devices + supporting BGP/MPLS IP VPNs can satisfy these requirements. + +15.1. Management by the Provider + + The SP manages all the VPN-specific information in the PE device. + This can be done using the MIB designed for BGP/MPLS IP VPNs + [L3VPN-MIB], in combination with other standard MIB modules such as + IF-MIB [IF-MIB], and other MPLS MIB modules [LSRMIB], [LDPMIB], + [TEMIB], [FTNMIB]. + + Devices supporting BGP/MPLS IP VPNs that employ the management + interface characteristics described above will also support the ITU-T + Telecommunications Management Network Model "FCAPS" functionalities + as required in the L3VPN Requirements document. These include Fault, + Configuration, Accounting, Provisioning, and Security. + + In BGP/MPLS IP VPNs, the SP is not required to manage the CE devices. + However, if it is desired for the SP to do so, the SP may manage CE + devices from a central site, provided that a route to the central + site is exported into the CE's VPN, and the central site is in a VPN + into which the routes to the managed CE devices have been imported. + + + +Rosen Informational [Page 27] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + This is a form of extranet. + + If the central site is managing CE devices from several VPNs, those + CE devices must have mutually unique addresses. Note that this does + not enable the CE devices from different VPNs to reach each other. + + The CE devices have no VPN-specific information in them. Hence the + fact that they are connected together into a VPN does not require + them to have any VPN-specific management MIB modules or capabilities. + +15.2. Management by the Customer + + CE devices may be managed from within the VPN, transparently to the + SP. The CE devices have no VPN-specific information in them, and the + fact that they are tied together into a VPN does not impact the + customer's management of them. + + Customer access to a PE device is totally at the discretion of the + SP, but is not required by the solution. The PE device is a routing + peer of a CE device, and can be pinged, etc. + + If a customer is permitted to access the PE router for management + purposes, the functions available to any particular customer need to + be strictly controlled, and the use of resource partitioning may be + appropriate. + + Network management traffic from the CE to the PE may be rate limited + (for example, to prevent network management traffic from CE to PE to + be used in a DoS attack). + +16. Acknowledgements + + Many thanks to Jeremy De Clercq, Luyuan Fang, Dave McDysan, Ananth + Nagarajan, Yakov Rekhter, and Muneyoshi Suzuki, for their comments, + criticisms, and help in preparing this document. Thanks also to + Thomas Nadeau for his help with the section on management, to + Francois LeFaucheur for his help with the section on QoS, and to Ross + Callon for his review of the document. + + + + + + + + + + + + + +Rosen Informational [Page 28] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + +17. Normative References + + [BGP-EXT-COMM] Sangli, S., Tappan, D., and Y. Rekhter, "BGP + Extended Communities Attribute", RFC 4360, + February 2006. + + [BGP-MPLS-IP-VPN] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual + Private Networks (VPNs)", RFC 4364, February + 2006. + + [L3VPN-FRMWRK] Callon, R. and M. Suzuki, "A Framework for Layer + 3 Provider-Provisioned Virtual Private Networks + (PPVPNs)", RFC 4110, July 2005. + + [L3VPN-REQS] Carugi, M. and D. McDysan, "Service Requirements + for Layer 3 Provider Provisioned Virtual Private + Networks (PPVPNs)", RFC 4031, April 2005. + + [L2VPN-SEC-FRMWRK] Fang, L., "Security Framework for Provider- + Provisioned Virtual Private Networks (PPVPNs)", + RFC 4111, July 2005. + +18. Informative References + + [VPN-OSPF] Rosen, E., Psenak, P., and P. Pillay-Esnault, + "OSPF as the PE/CE Protocol in BGP/MPLS VPNs", + Work in Progress, February 2004. + + [OSPF-2547-DNBIT] Rosen, E., Psenak, P., and P. Pillay-Esnault, + "Using an LSA Options Bit to Prevent Looping in + BGP/MPLS IP VPNs", Work in Progress, March 2004. + + [MPLS/BGP-IPsec] Rosen, E., De Clercq, J., Paridaens, O., + T'Joens, Y., and C. Sargor, "Architecture for + the Use of PE-PE IPsec Tunnels in BGP/MPLS IP + VPNs", Work in Progress, March 2004. + + [BGP-MPLS-MCAST-VPN] Rosen, E., Cai, Y., and IJ. Wijsnands, + "Multicast in MPLS/BGP VPNs", Work in Progress, + May 2004. + + [CE-VERIF] Bonica, R., Rekhter, Y., Raszuk, R., Rosen, E., + and D. Tappan, "CE-to-CE Member Verification for + Layer 3 VPNs", Work in Progress, September 2003. + + + + + + + +Rosen Informational [Page 29] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + [FTNMIB] Nadeau, T., Srinivasan, C., and A. Viswanathan, + "Multiprotocol Label Switching (MPLS) Forwarding + Equivalence Class To Next Hop Label Forwarding + Entry (FEC-To-NHLFE) Management Information Base + (MIB)", RFC 3814, June 2004. + + [IPSEC-VPN] De Clercq, J., Paridaens, O., Krywaniuk, A., and + C. Wang, "An Architecture for Provider + Provisioned CE-based Virtual Private Networks + using IPsec", Work in Progress, February 2004. + + [LDPMIB] Cucchiara, J., Sjostrand, H., and J. Luciani, + "Definitions of Managed Objects for the + Multiprotocol Label Switching (MPLS), Label + Distribution Protocol (LDP)", RFC 3815, June + 2004. + + [LSRMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Label + Switching Router (LSR) Management Information + Base (MIB)", RFC 3813, June 2004. + + [MPLS-DIFFSERV] 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. + + [L3VPN-MIB] Nadeau, T. and H. Van Der Linde, "MPLS/BGP + Virtual Private Network Management Information + Base Using SMIv2", Work in Progress, August + 2004. + + [IF-MIB] McCloghrie, K. and F. Kastenholz, "The + Interfaces Group MIB", RFC 2863, June 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. + + [TEMIB] Srinivasan, C., Viswanathan, A., and T. Nadeau, + "Multiprotocol Label Switching (MPLS) Traffic + Engineering (TE) Management Information Base + (MIB)", RFC 3812, June 2004. + + + + + + +Rosen Informational [Page 30] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + + [VR-VPN] Knight, P., Ould-Brahim, H., and B. Gleeson, + "Network Based IP VPN Architecture using Virtual + Routers", Work in Progress, April 2004. + +Author's Address + + Eric C. Rosen + Cisco Systems, Inc. + 1414 Massachusetts Avenue + Boxborough, MA 01719 + + EMail: erosen@cisco.com + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Rosen Informational [Page 31] + +RFC 4365 Applicability Statement for BGP/MPLS IP VPNs February 2006 + + +Full Copyright Statement + + Copyright (C) The Internet Society (2006). + + 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 provided by the IETF + Administrative Support Activity (IASA). + + + + + + + +Rosen Informational [Page 32] + |