VPLS. It does not even ensure loop freedom among the PE bridge
modules. It ensures only that when a frame is sent on the Emulated
LAN, the frame will not loop endlessly before (or instead of) leaving
the Emulated LAN.
Improper configuration of the customer LAN or PE bridge modules may
cause frames to loop, and frames that fall into such loops may
transit the overlay topology multiple times. Procedures that enable
the PE to detect and/or prevent such loops may be advisable.
3.4.2. Provisioning and Auto-Discovery
Each VPLS must be assigned a globally unique identifier. This can be
thought of as a VPN-id.
The ACs attaching the CEs to the PEs must be provisioned on both the
PEs and the CEs. A VSI for that VPLS must be provisioned on the PE,
and the local ACs of that VPLS must be associated with that VSI. The
VSI must be provisioned with the identifier of the VPLS to which it
belongs.
An auto-discovery scheme may be used by a PE to map a VPLS identifier
into the set of remote PEs that have VSIs in that VPLS. Once this
set is determined, the PE can use pseudowire signaling to set up a PW
to each of those VSIs. The VPLS identifier would serve as the
signaling protocol’s Forwarder Selector. This would result in a full
mesh of PWs among the VSIs in a particular VPLS.
If a single VPLS contains multiple VLANs, then it may be desirable to
limit connectivity so that two VSIs are connected only if they have a
VLAN in common.
In this case, each VSI would need to be provisioned with one or more
VLAN ids, and the auto-discovery scheme would need to map a VPLS
identifier into pairs of <PE, VLAN id>.
If a fully meshed topology of VSIs is not desired, then each VSI
needs to be provisioned with additional information specifying its
placement in the topology. This information would also need to be
provided by the auto-discovery scheme.
Alternatively, the single-sided provisioning method discussed in
Section 3.3.1.2 could be used. As this is more complicated, it would
only be used if it were necessary to associate individual PWs with
individual characteristics. For example, if different guaranteed
bandwidths were needed between different pairs of sites within a
VPLS, the PWs would have to be provisioned individually.
3.4.3. Distributed PE
Often, when a VPLS type of service is provided, the CE devices attach
to a provider-managed CPE device. This provider-managed CPE device
may attach to CEs of multiple customers, especially if, for example,
there are multiple customers occupying the same building. However,
this device is really part of the SP’s network, hence may be
considered a PE device.
In some scenarios in which a VPLS type of service is provided, the CE
devices attach to a provider-managed intermediary device. This
provider-managed device may attach to CEs of multiple customers.
This may arise if there are multiple customers occupying the same
building. This device is really part of the SP’s network and may for
that reason be considered to be a PE device; however, in the simplest
case, it is performing only aggregation and none of the function
associated with a VPLS.
Relative to the VPLS there are three different possibilities for
allocate functions to a device in such a position in the provider
network:
- it can perform aggregation and pure Layer2 service only, in
which case it does not really play the role of a PE device in a
VPLS service. In this case the intermediary system must connect
to devices that perform VPLS PE functionality; the intermediary
device itself is not part of the VPLS architecture and has hence
not been named in this architecture.
- it can perform all the PE functions relevant for a VPLS. In
such a case, the device is called VPLS-PE, see [RFC4026]. This
type of device will be connected to the core (P) routers.
The PE functionality for a VPLS may be distributed between two
devices, one "low-end" closer to the customer that performs, for
example, the MAC-address learning and forwarding decisions, and
one "high-end" that performs the control functions; e.g.,
establishing tunnels, PWs, and VCs. We call the low-end device
the User-Facing PE (U-PE) and the high-end device the Network-
Facing PE (N-PE).
It is conceivable that the U-PE may be placed very close to the
customer; e.g., in a building with more than one customer. The
N-PE will presumably be placed on the SP’s premises.
The distributed case is potentially of interest for a number of
possible reasons:
- The N-PE may be a device that cannot easily implement the VSI
functionality described above. For example, perhaps the N-PE is
a router that cannot perform the high speed MAC learning that is
needed in order to implement a VSI forwarder. At the same time,
the U-PE may need to be a low-cost device that also cannot
implement the full set of VPLS functions.
This leads one to investigate further if there are sensible ways
to split the VPLS PE functionality between the U-PE and the N-
PE.
- Generally, in the L2VPN architecture, the PEs are expected to
participate as peers in the backbone routing protocol. Since
the number of U-PEs is potentially very large relative to the
number of N-PEs, this may be undesirable as a matter of scaling
the backbone routing protocol.
- The U-PE may be a relatively inexpensive device that is unable
to participate in the full range of signaling and/or auto-
discovery procedures that are needed in order to provide the
VPLS service.
The VPLS functionality can be distributed between U-PE and N-PE in a
number of different ways, and a number of different proposals have
been made. They all presume that the U-PE will maintain a VSI
forwarder, connected by PWs to the remote VSIs; the N-PE thus does
not need to perform the VSI forwarding function. The proposals tend
to differ with respect to the following questions:
- Should the U-PEs perform full PW signaling to set up the PWs to
remote VSIs, or should the N-PEs do this signaling?
Since the U-PEs need to be able to send packets on PWs to remote
VSIs and receive packets on PWs from remote VSIs, if the PW
signaling is done by the N-PE, there would have to be some form
of "lightweight" (presumably) signaling between N-PE and U-PE
that allows the PWs to be extended from N-PE to U-PE.
- Should the U-PEs do their own auto-discovery, or should this be
done by the N-PEs?
In the latter case, the U-PEs may need to have some means of
telling the N-PEs which VPLSes they are interested in, and the
N-PEs must have some means of passing the results of the auto-
discovery process to the U-PE.
Whether it makes sense to split auto-discovery in this manner
may depend on the particular auto-discovery protocol used. One
would not expect the U-PEs to participate in, if for example, a
BGP-based auto-discovery scheme, but perhaps they would be
expected to participate in a RADIUS-based auto-discovery scheme.
- If a U-PE does not participate in routing but is redundantly
connected to two different N-PEs, can the U-PE still make an
intelligent choice of the best N-PE to use as the "next hop" for
traffic destined to a particular remote VSI? If not, can this
choice be made as the result of some other sort of interaction
between N-PE and U-PE, or does this choice need to be
established by provisioning?
- If a U-PE does not participate in routing but does participate
in full PW signaling, and if MPLS is being used, how can an N-PE
send a U-PE the labels that the U-PE needs in order to be able
to send traffic to its signaling peers? (If the U-PE did
participate in routing, this would happen automatically.)
- When a frame must be multicast, should the replication be done
by the N-PE or the U-PE?
These questions are not all independent; the way one answers
some of them may influence the way one answers others.
3.4.4. Scaling Issues in VPLS Deployment
In general, the PSN supports a VPLS solution with a tunnel from each
VPLS-PE to every other VPLS-PE participating in the same VPLS
instance. Strictly, VPLS-PEs with more than one VPLS instance in
common only need one tunnel, but for resource allocation reasons it
might be necessary to establish several tunnels. For each VPLS
service on a given VPLS-PE, it needs to establish one pseudowire to
every other VPLS-PE participating in that VPLS service. In total
n*(n-1) pseudowires must be setup between the VPLS-PE routers. In
large scale deployment this obviously creates scaling problems. One
way to address the scaling problems is to use hierarchy.
3.5. IP-Only LAN-Like Service (IPLS)
If, instead of providing a general VPLS service, one wishes to
provide a VPLS that is used only to connect IP routers or hosts
(i.e., the CE devices are all assumed to be IP routers or hosts),
then it is possible to make certain simplifications.
In this environment, all Ethernet frames sent from a particular CE to
a particular PE on a particular Attachment Circuit will have the same
MAC Source Address. Thus, rather than use address learning in the
data plane to learn the MAC addresses, the PE can use the control
plane to learn the MAC address. This allows the PE to be implemented
on devices that are not capable of doing MAC address learning in the
data plane.
To eliminate the need for MAC address learning on the PWs as well as
on the ACs, the pseudowire signaling protocol would have to carry the
MAC address from one pseudowire endpoint to the other. In the case
of IPv4, Each PE would perform proxy ARP to its directly attached
CEs. In the case of IPv6, each PE would send proxy Neighbor and/or
Router Advertisements.
Eliminating the need to do MAC address learning on the PWs eliminates
the need for the PWs to be point-to-point. Multipoint-to-point PWs
could be used instead.
Unlike a VPLS, all the ACs in an IPLS would not necessarily have to
carry Ethernet frames; only the IP packets would need to be passed
across the network, not their Layer 2 wrappers. However, if there
are protocols that are specific to the Layer 2, but that provide, for
example, address resolution services for Layer 3, it may then be
necessary to "translate" (or otherwise interwork) one of these Layer
2 protocols to the other. For example, if an IPLS instance has an
ethernet AC and a Frame Relay AC, and IPv4 is running on both,
interworking between ARP and Inverse ARP might be required.
The set of routing protocols that could be carried across the IPLS
might also be restricted.
An IPLS instance must have a particular IPLS-wide MTU; if there are
different kinds of AC in an IPLS instance, and those different kinds
of AC support different MTUs, all ACS must enforce the IPLS-wide MTU;
an AC that cannot do this must not be allowed to join the IPLS
instance.
4. Security Considerations
The security considerations section of the L2VPN requirements
document [RFC4665] addresses a number of areas that are potentially
insecure aspects of the L2VPN. These relate to both control plane
and data plane security issues that may arise in the following areas:
- issues fully contained in the provider network
- issues fully contained in the customer network
- issues in the customer-provider interface network
These three areas are addressed below.
4.1. Provider Network Security Issues
This section discusses security issues that only impact the SP’s
equipment.
There are security issues having to do with the control connections
that are used on a PE-PE basis for setting up and maintaining the
pseudowires.
A PE should not engage with another PE in a control connection unless
it has some confidence that the peer is really a PE to which it
should be setting up PWs. Otherwise, L2PVN traffic may go to the
wrong place. If control packets are maliciously and undetectably
altered while in flight, denial of service, or alteration of the
expected quality of service, may result.
If peers discover each other dynamically (via some auto-discovery
procedure), this presupposes that the auto-discovery procedures are
themselves adequately trusted.
PEs should not accept control connections from arbitrary entities; a
PE either should be configured with its peers or should learn them
from a trusted auto-configuration procedure. If the peer is required
to be within the same SP’s network, then access control filters at
the borders of that network can be used to prevent spoofing of the
peer’s source address. If the peer is from another SP’s network,
then setting up such filters may be difficult or even impossible,
depending on the way in which the two SPs are connected. Even if the
access filters can be set up, the level of assurance that they
provide will be lower.
Thus, for inter-SP control connections, it is advisable to use some
sort of cryptographic authentication procedure. Control protocols
which used TCP may use the TCP MD5 option to provide a measure of
PE-PE authentication; this requires at least one shared secret
between SPs. The use of IPsec between PEs is also possible and
provides a greater degree of assurance, though at a greater cost.
Any other security considerations that apply to the control protocol
in general will also apply when the control protocol is used for
setting up PWs. If the control protocol uses UDP messages, it may be
advisable to have some protection against spoofed UDP messages that
appear to be from a valid peer; this requires further study.
To limit the effect of Denial of Service attacks on a PE, some means
of limiting the rate of processing of control plane traffic may be
desirable.
Unlike authentication and integrity, privacy of the signaling
messages is not usually considered very important. If it is needed,
the signaling messages can be sent through an IPsec connection.
If the PE cannot efficiently handle high volumes of multicast traffic
for sustained periods, then it may be possible to launch a denial of
service attack on a VPLS service by sending a PE a large number of
frames that have either a multicast address or an unknown MAC address
in their MAC Destination Address fields. A similar denial of service
attack can be mounted by sending a PE a large number of frames with
bogus MAC Source Address fields. The bogus addresses can fill the
MAC address tables in the PEs, with the result that frames destined
to the real MAC addresses always get flooded (i.e., multicast). Note
that this flooding can remove the (weak) confidentiality property of
this or any other bridged network.
4.2. Provider-Customer Network Security Issues
There are a number of security issues related to the access network
between the provider and the customer. This is also traditionally a
network that is hard to protect physically.
Typical security issues on the provider-customer interface include
the following:
- Ensuring that the correct customer interface is configured
- Preventing unauthorized access to the PE
- Preventing unauthorized access to a specific PE port
- Ensuring correct service delimiting fields (VLAN, DLCI, etc.)
As the access network for an L2VPN service is necessarily a Layer 2
network, it is preferable to use authentication mechanisms that do
not presuppose any IP capabilities on the CE device.
There are existing Layer 2 protocols and best current practices to
guard against these security issues. For example, IEEE 802.1x
defines authentication at the link level for access through an
ethernet bridge; the Frame Relay Forum defines LMI extensions for
authentication (FRF.17).
4.3. Customer Network Security Issues
Even if all CE devices are properly authorized to attach to their PE
devices, misconfiguration of the PE may interconnect CEs that are not
supposed to be in the same L2VPN.
In a VPWS, the CEs may run IPsec to authenticate each other. Other
Layer 3 or Layer 4 protocols may have their own authentication
methods.
In a VPLS, CE-to-CE IPsec is even more problematic, as IPsec does not
well support the multipoint configuration that is provided by the
VPLS service.
There may be alternative methods for achieving a degree of CE-to-CE
authentication, if the L2VPN signaling protocol can carry opaque
objects between the CEs, either inband (over the L2VPN) or out-of-
band, through the participation of the signaling protocol. This is
for further study.
The L2VPN procedures do not provide authentication, integrity, or
privacy for the customer’s traffic; if this is needed, it becomes the
responsibility of the customer. For customers who really need these
features or who do not trust their service providers to provide the
level of security that they need, the L2VPN framework discussed in
this document may not be satisfactory. Such customers may consider
alternative L2VPN schemes that are based not on an overlay of PWs,
but on an overlay of IPsec tunnels whose endpoints are at the
customer sites; however, such alternatives are not discussed in this
document.
If there is CE-to-CE control traffic (e.g., BPDUs) on whose integrity
the customer’s own Layer 2 network depends, it may be advisable to
send the control traffic using some more secure mechanism than is
used for the data traffic.
In general, any means of mounting a denial of service attack on
bridged networks generally can also be used to mount a denial of
service attack on the VPLS service for a particular customer. We
have discussed here only those attacks that rely on features of the
VPLS service that are not shared by bridged networks in general.
5. Acknowledgements
This document is the outcome of discussions within a Layer 2 VPN
design team, all of whose members could be considered co-authors.
Specifically, the co-authors are Loa Andersson, Waldemar Augustyn,
Marty Borden, Hamid Ould-Brahim, Juha Heinanen, Kireeti Kompella,
Vach Kompella, Marc Lasserre, Pascal Menezes, Vasile Radoaca, Eric
Rosen, and Tissa Senevirathne.
The authors would like to thank Marco Carugi for cooperation in
setting up context, working directions, and taking time for
discussions in this space; Tove Madsen and Pekka Savola for valuable
input and reviews; and Norm Finn, Matt Squires, and Ali Sajassi for
valuable discussion of the VPLS issues.
6. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3985] Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
Edge (PWE3) Architecture", RFC 3985, March 2005.
[RFC4026] Andersson, L. and T. Madsen, "Provider Provisioned
Virtual Private Network (VPN) Terminology", RFC 4026,
March 2005.
[RFC4665] Augustyn, W., Ed. and Y. Serbest, Ed., "Service
Requirements for Layer 2 Provider-Provisioned Virtual
Private Networks (L2VPNs)", RFC 4665, September 2006.
7. Informative References
[IEEE8021D] IEEE 802.1D-2003, "IEEE Standard for Local and
Metropolitan Area Networks: Media Access Control (MAC)
Bridges"
[IEEE8021Q] IEEE 802.1Q-1998, "IEEE Standards for Local and
Metropolitan Area Networks: Virtual Bridged Local Area
Networks"
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol
"L2TP"", RFC 2661, August 1999.
[RFC2796] Bates, T., Chandra, R., and E. Chen, "BGP Route
Reflection - An Alternative to Full Mesh IBGP", RFC
2796, April 2000.
[RFC3036] Andersson, L., Doolan, P., Feldman, N., Fredette, A.,
and B. Thomas, "LDP Specification", RFC 3036, January
2001.
Authors’ Addresses
Loa Andersson
Acreo AB
EMail: loa@pi.se
Eric C. Rosen
Cisco Systems, Inc.
1414 Massachusetts Avenue
Boxborough, MA 01719
EMail: erosen@cisco.com
Waldemar Augustyn
EMail: waldemar@wdmsys.com
Marty Borden
EMail: mborden@acm.org
Juha Heinanen
Song Networks, Inc.
Hallituskatu 16
33200 Tampere, Finland
EMail: jh@song.fi
Kireeti Kompella
Juniper Networks, Inc.
1194 N. Mathilda Ave
Sunnyvale, CA 94089
EMail: kireeti@juniper.net
Vach Kompella
TiMetra Networks
274 Ferguson Dr.
Mountain View, CA 94043
EMail: vach.kompella@alcatel.com
Marc Lasserre
Riverstone Networks
5200 Great America Pkwy
Santa Clara, CA 95054
EMail: mlasserre@lucent.com
Pascal Menezies
EMail: pascalm1@yahoo.com
Hamid Ould-Brahim
Nortel Networks
P O Box 3511 Station C
Ottawa, ON K1Y 4H7, Canada
EMail: hbrahim@nortelnetworks.com
Vasile Radoaca
Nortel Networks
600 Technology Park
Billerica, MA 01821
EMail: radoaca@hotmail.com
Tissa Senevirathne
1567 Belleville Way
Sunnyvale CA 94087
EMail: tsenevir@hotmail.com
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.