interface. Available tunneling mechanisms include (but are not
limited to): GRE, IP-in-IP, IP over ATM, IP over FR, IPsec, and MPLS.
o GRE
The tunnels at interworking interface may be provided by GRE
[RFC2784] with key and sequence number extensions [RFC2890].
o IP-in-IP
The tunnels at interworking interface may be provided by IP-in-IP
[RFC2003] [RFC2473].
o IP over ATM AAL5
The tunnels at interworking interface may be provided by IP over
ATM AAL5 [RFC2684] [RFC2685].
o IP over FR
The tunnels at interworking interface may be provided by IP over
FR.
o IPsec
The tunnels at interworking interface may be provided by IPsec
[RFC2401] [RFC2402].
o MPLS
The tunnels at interworking interface may be provided by MPLS
[RFC3031] [RFC3035].
5.3. Support of Additional Services
This subsection describes additional usages for supporting QoS/SLA,
customer visible routing, and customer visible multicast routing, as
services of layer 3 PE-based VPNs spanning multiple SP networks.
o QoS/SLA
QoS/SLA management mechanisms for GRE, IP-in-IP, IPsec, and MPLS
tunnels were discussed in sections 4.3.6 and 4.5. See these
sections for details. FR and ATM are capable of QoS guarantee.
Thus, QoS/SLA may also be supported at the interworking interface.
o Customer visible routing
As described in section 3.3, customer visible routing enables the
exchange of unicast routing information between customer sites
using a routing protocol such as OSPF, IS-IS, RIP, and BGP-4. On
the interworking interface, routing packets, such as OSPF packets,
are transmitted through a tunnel associated with a layer 3 PE-based
VPN in the same manner as that for user data packets within the
VPN.
o Customer visible multicast routing
Customer visible multicast routing enables the exchange of
multicast routing information between customer sites using a
routing protocol such as DVMRP and PIM. On the interworking
interface, multicast routing packets are transmitted through a
tunnel associated with a layer 3 PE-based VPN in the same manner as
that for user data packets within the VPN. This enables a
multicast tree construction within the layer 3 PE-based VPN.
5.4. Scalability Discussion
This subsection discusses scalability aspect of the interworking
scenario.
o Number of routing protocol instances
In the interworking scenario discussed in this section, the number
of routing protocol instances and that of layer 3 PE-based VPNs are
the same. However, the number of layer 3 PE-based VPNs in a PE
device is limited due to resource amount and performance of the PE
device. Furthermore, each tunnel is expected to require some
bandwidth, but total of the bandwidth is limited by the capacity of
a PE device; thus, the number of the tunnels is limited by the
capabilities of the PE. This limit is not a critical drawback.
o Performance of packet transmission
The interworking scenario discussed in this section does not place
any additional burden on tunneling technologies used at
interworking interface. Since performance of packet transmission
depends on a tunneling technology applied, it should be carefully
selected when provisioning interworking. For example, IPsec places
computational requirements for encryption/decryption.
6. Security Considerations
Security is one of the key requirements concerning VPNs. In network
environments, the term security currently covers many different
aspects of which the most important from a networking perspective are
shortly discussed hereafter.
Note that the Provider-Provisioned VPN requirements document explains
the different security requirements for Provider-Provisioned VPNs in
more detail.
6.1. System Security
Like in every network environment, system security is the most
important security aspect that must be enforced. Care must be taken
that no unauthorized party can gain access to the network elements
that control the VPN functionality (e.g., PE and CE devices).
As the VPN customers are making use of the shared SP’s backbone, the
SP must ensure the system security of its network elements and
management systems.
6.2. Access Control
When a network or parts of a network are private, one of the
requirements is that access to that network (part) must be restricted
to a limited number of well-defined customers. To accomplish this
requirement, the responsible authority must control every possible
access to the network.
In the context of PE-based VPNs, the access points to a VPN must be
limited to the interfaces that are known by the SP.
6.3. Endpoint Authentication
When one receives data from a certain entity, one would like to be
sure of the identity of the sending party. One would like to be sure
that the sending entity is indeed whom he or she claims to be, and
that the sending entity is authorized to reach a particular
destination.
In the context of layer 3 PE-based VPNs, both the data received by
the PEs from the customer sites via the SP network and destined for a
customer site should be authenticated.
Note that different methods for authentication exist. In certain
circumstances, identifying incoming packets with specific customer
interfaces might be sufficient. In other circumstances, (e.g., in
temporary access (dial-in) scenarios), a preliminary authentication
phase might be requested. For example, when PPP is used. Or
alternatively, an authentication process might need to be present in
every data packet transmitted (e.g., in remote access via IPsec).
For layer 3 PE-based VPNs, VPN traffic is tunneled from PE to PE and
the VPN tunnel endpoint will check the origin of the transmitted
packet. When MPLS is used for VPN tunneling, the tunnel endpoint
checks whether the correct labels are used. When IPsec is used for
VPN tunneling, the tunnel endpoint can make use of the IPsec
authentication mechanisms.
In the context of layer 3 provider-provisioned CE-based VPNs, the
endpoint authentication is enforced by the CE devices.
6.4. Data Integrity
When information is exchanged over a certain part of a network, one
would like to be sure that the information that is received by the
receiving party of the exchange is identical to the information that
was sent by the sending party of the exchange.
In the context of layer 3 PE-based VPNs, the SP assures the data
integrity by ensuring the system security of every network element.
Alternatively, explicit mechanisms may be implemented in the used
tunneling technique (e.g., IPsec).
In the context of layer 3 provider-provisioned CE-based VPNs, the
underlying network that will tunnel the encapsulated packets will not
always be of a trusted nature, and the CE devices that are
responsible for the tunneling will also ensure the data integrity,
e.g., by making use of the IPsec architecture.
6.5. Confidentiality
One would like that the information that is being sent from one party
to another is not received and not readable by other parties. With
traffic flow confidentiality one would like that even the
characteristics of the information sent is hidden from third parties.
Data privacy is the confidentiality of the user data.
In the context of PPVPNs, confidentiality is often seen as the basic
service offered, as the functionalities of a private network are
offered over a shared infrastructure.
In the context of layer 3 PE-based VPNs, as the SP network (and more
precisely the PE devices) participates in the routing and forwarding
of the customer VPN data, it is the SP’s responsibility to ensure
confidentiality. The technique used in PE-based VPN solutions is the
ensuring of PE to PE data separation. By implementing VFI’s in the
PE devices and by tunneling VPN packets through the shared network
infrastructure between PE devices, the VPN data is always kept in a
separate context and thus separated from the other data.
In some situations, this data separation might not be sufficient.
Circumstances where the VPN tunnel traverses other than only trusted
and SP controlled network parts require stronger confidentiality
measures such as cryptographic data encryption. This is the case in
certain inter-SP VPN scenarios or when the considered SP is on itself
a client of a third party network provider.
For layer 3 provider-provisioned CE-based VPNs, the SP network does
not bare responsibility for confidentiality assurance, as the SP just
offers IP connectivity. The confidentiality will then be enforced at
the CE and will lie in the tunneling (data separation) or in the
cryptographic encryption (e.g., using IPsec) by the CE device.
Note that for very sensitive user data (e.g., used in banking
operations) the VPN customer may not outsource his data privacy
enforcement to a trusted SP. In those situations, PE-to-PE
confidentiality will not be sufficient and end-to-end cryptographic
encryption will be implemented by the VPN customer on its own private
equipment (e.g., using CE-based VPN technologies or cryptographic
encryption over the provided VPN connectivity).
6.6. User Data and Control Data
An important remark is the fact that both the user data and the VPN
control data must be protected.
Previous subsections were focused on the protection of the user data,
but all the control data (e.g., used to set up the VPN tunnels, used
to configure the VFI’s or the CE devices (in the context of layer 3
provider-provisioned CE-based VPNs)) will also be secured by the SP
to prevent deliberate misconfiguration of provider-provisioned VPNs.
6.7. Security Considerations for Inter-SP VPNs
In certain scenarios, a single VPN will need to cross multiple SPs.
The fact that the edge-to-edge part of the data path does not fall
under the control of the same entity can have security implications,
for example with regards to endpoint authentication.
Another point is that the SPs involved must closely interact to avoid
conflicting configuration information on VPN network elements (such
as VFIs, PEs, CE devices) connected to the different SPs.
Appendix A: Optimizations for Tunnel Forwarding
A.1. Header Lookups in the VFIs
If layer 3 PE-based VPNs are implemented in the most straightforward
manner, then it may be necessary for PE devices to perform multiple
header lookups in order to forward a single data packet. This
section discusses an example of how multiple lookups might be needed
with the most straightforward implementation. Optimizations which
might optionally be used to reduce the number of lookups are
discussed in the following sections.
As an example, in many cases a tunnel may be set up between VFIs
within PEs for support of a given VPN. When a packet arrives at the
egress PE, the PE may need to do a lookup on the outer header to
determine which VFI the packet belongs to. The PE may then need to
do a second lookup on the packet that was encapsulated across the VPN
tunnel, using the forwarding table specific to that VPN, before
forwarding the packet.
For scaling reasons it may be desired in some cases to set up VPN
tunnels, and then multiplex multiple VPN-specific tunnels within the
VPN tunnels.
This implies that in the most straightforward implementation three
header lookups might be necessary in a single PE device: One lookup
may identify that this is the end of the VPN tunnel (implying the
need to strip off the associated header). A second lookup may
identify that this is the end of the VPN-specific tunnel. This
lookup will result in stripping off the second encapsulating header,
and will identify the VFI context for the final lookup. The last
lookup will make use of the IP address space associated with the VPN,
and will result in the packet being forwarded to the correct CE
within the correct VPN.
A.2. Penultimate Hop Popping for MPLS
Penultimate hop popping is an optimization which is described in the
MPLS architecture document [RFC3031].
Consider the egress node of any MPLS LSP. The node looks at the
label, and discovers that it is the last node. It then strips off
the label header, and looks at the next header in the packet (which
may be an IP header, or which may have another MPLS header in the
case that hierarchical nesting of LSPs is used). For the last node
on the LSP, the outer MPLS header doesn’t actually convey any useful
information (except for one situation discussed below).
For this reason, the MPLS standards allow the egress node to request
that the penultimate node strip the MPLS header. If requested, this
implies that the penultimate node does not have a valid label for the
LSP, and must strip the MPLS header. In this case, the egress node
receives the packet with the corresponding MPLS header already
stripped, and can forward the packet properly without needing to
strip the header for the LSP which ends at that egress node.
There is one case in which the MPLS header conveys useful
information: This is in the case of a VPN-specific LSP terminating at
a PE device. In this case, the value of the label tells the PE which
LSP the packet is arriving on, which in turn is used to determine
which VFI is used for the packet (i.e., which VPN-specific forwarding
table needs to be used to forward the packet).
However, consider the case where multiple VPN-specific LSPs are
multiplexed inside one PE-to-PE LSP. Also, let’s suppose that in
this case the egress PE has chosen all incoming labels (for all LSPs)
to be unique in the context of that PE. This implies that the label
associated with the PE-to-PE LSP is not needed by the egress node.
Rather, it can determine which VFI to use based on the VPN-specific
LSP. In this case, the egress PE can request that the penultimate
LSR performs penultimate label popping for the PE-to-PE LSP. This
eliminates one header lookup in the egress LSR.
Note that penultimate node label popping is only applicable for VPN
standards which use multiple levels of LSPs. Even in this case
penultimate node label popping is only done when the egress node
specifically requests it from the penultimate node.
A.3. Demultiplexing to Eliminate the Tunnel Egress VFI Lookup
Consider a VPN standard which makes use of MPLS as the tunneling
mechanism. Any standard for encapsulating VPN traffic inside LSPs
needs to specify what degree of granularity is available in terms of
the manner in which user data traffic is assigned to LSPs. In other
words, for any given LSP, the ingress or egress PE device needs to
know which LSPs need to be set up, and the ingress PE needs to know
which set of VPN packets are allowed to be mapped to any particular
LSP.
Suppose that a VPN standard allows some flexibility in terms of the
mapping of packets to LSPs, and suppose that the standard allows the
egress node to determine the granularity. In this case the egress
node would need to have some way to indicate the granularity to the
ingress node, so that the ingress node will know which packets can be
mapped to each LSP.
In this case, the egress node might decide to have packets mapped to
LSPs in a manner which simplifies the header lookup function at the
egress node. For example, the egress node could determine which set
of packets it will forward to a particular neighbor CE device. The
egress node can then specify that the set of IP packets which are to
use a particular LSP correspond to that specific set of packets. For
packets which arrive on the specified LSP, the egress node does not
need to do a header lookup on the VPN’s customer address space: It
can just pop the MPLS header and forward the packet to the
appropriate CE device. If all LSPs are set up accordingly, then the
egress node does not need to do any lookup for VPN traffic which
arrives on LSPs from other PEs (in other words, the PE device will
not need to do a second lookup in its role as an egress node).
Note that PE devices will most likely also be an ingress routers for
traffic going in the other direction. The PE device will need to do
an address lookup in the customer network’s address space in its role
as an ingress node. However, in this direction the PE still needs to
do only a single header lookup.
When used with MPLS tunnels, this optional optimization reduces the
need for header lookups, at the cost of possibly increasing the
number of label values which need to be assigned (since one label
would need to be assigned for each next-hop CE device, rather than
just one label for every VFI).
The same approach is also possible when other encapsulations are
used, such as GRE [RFC2784] [RFC2890], IP-in-IP [RFC2003] [RFC2473],
or IPsec [RFC2401] [RFC2402]. This requires that distinct values are
used for the multiplexing field in the tunneling protocol. See
section 4.3.2 for detail.
Acknowledgments
This document is output of the framework document design team of the
PPVPN WG. The members of the design team are listed in the
"contributors" and "author’s addresses" sections below.
However, sources of this document are based on various inputs from
colleagues of authors and contributors. We would like to thank
Junichi Sumimoto, Kosei Suzuki, Hiroshi Kurakami, Takafumi Hamano,
Naoto Makinae, Kenichi Kitami, Rajesh Balay, Anoop Ghanwani, Harpreet
Chadha, Samir Jain, Lianghwa Jou, Vijay Srinivasan, and Abbie
Matthews.
We would also like to thank Yakov Rekhter, Scott Bradner, Dave
McDysan, Marco Carugi, Pascal Menezes, Thomas Nadeau, and Alex Zinin
for their valuable comments and suggestions.
Normative References
[PPVPN-REQ] Nagarajan, A., Ed., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC
3809, June 2004.
[L3VPN-REQ] Carugi, M., Ed. and D. McDysan, Ed., "Service
Requirements for Layer 3 Provider Provisioned Virtual
Private Networks (PPVPNs)", RFC 4031, April 2005.
Informative References
[BGP-COM] Sangli, S., et al., "BGP Extended Communities
Attribute", Work In Progress, February 2005.
[MPLS-DIFF-TE] Le Faucheur, F., Ed., "Protocol extensions for support
of Differentiated-Service-aware MPLS Traffic
Engineering", Work In Progress, December 2004.
[VPN-2547BIS] Rosen, E., et al., "BGP/MPLS VPNs", Work In Progress.
[VPN-BGP-OSPF] Rosen, E., et al., "OSPF as the Provider/Customer Edge
Protocol for BGP/MPLS IP VPNs", Work In Progress, May
2005.
[VPN-CE] De Clercq, J., et al., "An Architecture for Provider
Provisioned CE-based Virtual Private Networks using
IPsec", Work In Progress.
[VPN-DISC] Ould-Brahim, H., et al., "Using BGP as an Auto-
Discovery Mechanism for Layer-3 and Layer-2 VPNs,"
Work In Progress.
[VPN-L2] Andersson, L. and E. Rosen, Eds., "Framework for Layer
2 Virtual Private Networks (L2VPNs)", Work In
Progress.
[VPN-VR] Knight, P., et al., "Network based IP VPN Architecture
Using Virtual Routers", Work In Progress, July 2002.
[RFC1195] Callon, R., "Use of OSI IS-IS for Routing in TCP/IP
and Dual Environments", RFC 1195, December 1990.
[RFC1771] Rekhter, Y. and T. Li, "A Border Gateway Protocol 4
(BGP-4)", RFC 1771, March 1995.
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot,
G., and E. Lear, "Address Allocation for Private
Internets", BCP 5, RFC 1918, February 1996.
[RFC1966] Bates, T., "BGP Route Reflection: An alternative to
full mesh IBGP", RFC 1966, June 1996.
[RFC1997] Chandra, R., Traina, P., and T. Li, "BGP Communities
Attribute", RFC 1997, February 2001.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2205] Braden, R., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) --
Version 1 Functional Specification", RFC 2205,
September 1997.
[RFC2208] Mankin, A., Ed., Baker, F., Braden, B., Bradner, S.,
O’Dell, M., Romanow, A., Weinrib, A., and L. Zhang,
"Resource ReSerVation Protocol (RSVP) Version 1
Applicability Statement Some Guidelines on
Deployment", RFC 2208, September 1997.
[RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated
Services", RFC 2210, September 1997.
[RFC2211] Wroclawski, J., "Specification of the Controlled-Load
Network Element Service", RFC 2211, September 1997.
[RFC2212] Shenker, S., Partridge, C., and R. Guerin,
"Specification of Guaranteed Quality of Service", RFC
2212, September 1997.
[RFC2207] Berger, L. and T. O’Malley, "RSVP Extensions for IPSEC
Data Flows", RFC 2207, September 1997.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April
1998.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for
the Internet Protocol", RFC 2401, November 1998.
[RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header",
RFC 2402, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange
(IKE)", RFC 2409, November 1998.
[RFC2453] Malkin, G., "RIP Version 2", STD 56, RFC 2453,
November 1994.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474,
December 1998.
[RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang,
Z., and W. Weiss, "An architecture for Differentiated
Services", RFC 2475, December 1998.
[RFC2597] Heinanen, J., Baker, F., Weiss, W., and J. Wroclawski,
"Assured Forwarding PHB Group", RFC 2597, June 1999.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G.,
Zorn, G., and B. Palter, "Layer Two Tunneling Protocol