Internet DRAFT - draft-bose-secure-l3vpn
draft-bose-secure-l3vpn
Network Working Group P. Bose, Ed.
Internet-Draft Lockheed Martin
Expires: August 30, 2005 R. Bonica
Juniper Networks
R. White
Cisco Systems
February 26, 2005
Secure Layer 3 Virtual Private Networks
draft-bose-secure-l3vpn-00
Status of this Memo
By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 30, 2005.
Copyright Notice
Copyright (C) The Internet Society (2005).
Abstract
This document presents an framework for secure layer 3 Virtual
Private Networks (VPNs) for customer networks that exchange encrypted
information through a service provider network. It also describes
the necessary interactions between the various functions (e.g.
routing and encryption) at the VPN boundary to construct the secure
Bose, et al. Expires August 30, 2005 [Page 1]
Internet-Draft Secure L3VPN February 2005
VPN.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Key Requirements for Secure VPNs in the GIG . . . . . . . 3
2. Functional Architecture of a Secure L3 VPN . . . . . . . . . . 5
2.1. Proposed L3 VPN Architecture . . . . . . . . . . . . . . . 6
2.2. Functional components at the VPN boundary . . . . . . . . 7
2.3. Hierarchical Distribution of Reachability Information . . 8
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
4. Security Considerations . . . . . . . . . . . . . . . . . . . 11
5. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12
6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Intellectual Property and Copyright Statements . . . . . . . . . . 16
Bose, et al. Expires August 30, 2005 [Page 2]
Internet-Draft Secure L3VPN February 2005
1. Introduction
VPNs are typically constructed in one of two ways. One is that a
service provider offers the VPN, and provides an underlying circuit
network, often MPLS, that connects the underlying endpoints as
defined in a contract. These are referred to as "Provider-
Provisioned VPNs" [RFC3809]. The other, generally referred to as
"customer-provisioned", is that the edge routers themselves provide
tunnels over an underlying network using one of a variety of types of
IP tunnel technologies such as loose source routes as specified in
DVMRP [RFC1075], IP/IP [RFC2003], IPsec/ESP [RFC2401][RFC2406], L2TP
[RFC2661], GRE [RFC2784] and others.
In this context, a "Secure VPN" is an example of an IPsec or IPsec-
like VPN, and is therefore "customer-provisioned". Such networks
have in the past been a complex collection of tunnels, a star or a
multi-star network in which a large set of client sites maintain
static or semi-static tunnels with a much smaller set of service
sites. This document presents a Layer 3 VPN architecture for such
networks by taking into account the underlying network architecture
and requirements of a secure VPN where plaintext (red) enclaves
connect to remote plaintext enclaves through a ciphertext (black)
network.
1.1. Key Requirements for Secure VPNs in the GIG
Secure VPNs presents a unique set of requirements which include:
o Scalability of VPN sites up to a large number of routes and
prefixes: Each secure enclave may have hundreds or thousands of
reachable destinations, and there may be thousands of secure
enclaves. A solution proven to be able to map large number of
destinations to some indicator of the enclave those destinations
belong to, ideally a ciphertext (black) next hop address
representing the secure enclave. Two types of systems have these
scaling characteristics in today's global Internet, name
resolution systems, and interdomain routing systems.
o Mobility of customer and service provider networks: Secure
enclaves will tend to be mobile in most environments, and
reachable destinations will tend to be mobile between secure
enclaves themselves. This implies any solution must be able to
adjust to changes in enclave or reachable destinations within an
enclave very quickly, within the application requirements for the
network as a whole. In most large scale internetworks, the times
acceptable for reacting to changes in reachability or connectivity
is on the order of seconds to tens of seconds, rather than minutes
to hours. Interdomain routing systems deployed in the global
Bose, et al. Expires August 30, 2005 [Page 3]
Internet-Draft Secure L3VPN February 2005
Internet can meet these convergence time criteria.
o Secure routing and discovery of hosts, routers and gateways:
Destination reachability, in some environments, cannot become
known within the general routing table of all devices. This
implies not only authentication and authorization of reachability
information must be provided, but also that confidientality of
reachability information. Current interdomain routing protocols
can be used over secure point-to-point links, providing this type
of security. Further, authorization to advertise a specific set
of destinations must also be authorizable, in some fashion.
Interdomain routing protocols allow the validation of
authorization to advertise reachability, and this is an area of
current research and work for interdomain routing protocols.
o Minimal information transfer at the VPN boundary: Minimal amounts
of information may be passed between secure enclaves and the
internetwork through which these secure enclaves communicate.
Primarily, for this work, this includes reachability information,
as described above; reachability information cannot be passed from
the secure enclave into the insecure internetwork. Thus, there
must be some way to associate a public address with a set of
destinations within a secure enclave, without adding any
information to the insecure internetwork. Current interdomain
routing allows this attachment through the use of indirection; the
next hop towards a particular destination does not need to be the
transmitter of the routing information itself.
o Reachability policies are required: Because of the nature of the
routing information, the system used to advertise and discover
reachability information within secure enclaves must be able to
attach policy about where and how that routing information may be
shared to the routing information itself. Such policies are also
required to provide inter-enclave routing with information about
the best possible entry point into the secure enclave to reach any
specific destination within the enclave, as well as other
preferences. Current interdomain routing within the global
Internet has similar policy requirements, and thus the current
interdomain routing protocol supports such policy mechanisms.
o Dynamic on-demand discovery of reachability In some environments,
it may be more feasible to request routes on demand, rather than
learning all possible routes through a connection to a server or
other device. Current interdomain routing does not support this
mode of operation, but could be easily modified to provide this
type of service.
Bose, et al. Expires August 30, 2005 [Page 4]
Internet-Draft Secure L3VPN February 2005
2. Functional Architecture of a Secure L3 VPN
A simple representation of a secure VPN is shown in Figure 1.
Plaintext(PT)| Ciphertext(CT) | Plaintext(PT)
(Red) | (Black) | (Red)
| |
+-------+-------+ +-------+-------+
| | | | | |
| +----+---------------------------------+----+ |
| +----+---------------------------------+----+ |
| VPN|Router | Encrypted | VPN|Router |
+-------+-------+ Tunnel +-------+-------+
| |
| |
| |
| |
| |
Figure 1: Simple VPN
Each customer network has a plaintext (red) enclave which
participates in a virtual private network with other red enclaves.
This is accomplished via an encrypted tunnel which originates and
terminates in the red enclave and traverses through the intermediate
ciphertext (black) service provider network. The VPN Router
(depicted here as a single logical node) performs the following
functions:
o Intra-Domain Routing
o Encryption/Decryption
o Transfer of necessary control plane information between plaintext
and ciphertext domains (e.g. IP addresses)
o Inter-Domain Routing
o Data Forwarding
Each of these functions may be performed by the same or different
physical entity in the network. A description of the various
physical implementation alternatives of these functions is beyond the
scope of this document.
The simple view presented in Figure 1 can be expanded in terms of a
typical layer 3 framework as described in [RFC4110] and depicted in
Figure 2 below.
Bose, et al. Expires August 30, 2005 [Page 5]
Internet-Draft Secure L3VPN February 2005
Plaintext(PT) | Ciphertext(CT) | Plaintext(PT)
(Red) | (Black) | (Red)
| |
+-----+ + +-----+ +-----+ +-----+ + +-----+
IGP | CE | | | CE | | PE | | CE | | | CE |IGP
<==== | ================================================ |===>
Static | +------+---------------------------------+------+ |Static
| | | | | | | | | | | |
+-----+ + +-----+ +-----+ +-----+ + +-----+
|IGP IGP|
|<==> <==> BGP <==> <==>|
|Static Static|
| |
| IPsec |
<=======================================>
| |
| BGP(For PT to CT Nexthop) |
<==============================================>
Figure 2: Secure Layer 3 VPN Architecture
2.1. Proposed L3 VPN Architecture
The proposed Layer 3 VPN architecture as described in Figure 2
overlays a BGP VPN over IPsec tunnels. It is assumed for this
description that the two first hop routers at the VPN boundary form
the customer edge router which may or may not be the same device.
The red CE router learns and summarizes red prefixes using an IGP in
the red enclave such as OSPF. These prefixes are imported into the
inter-domain routing function at the red CE router and advertised to
a remote red enclave via BGP. BGP information exchange between
remote enclaves flows along with other data in the security
associations (e.g. IPsec). Any given red CE router learns the black
address of the remote enclave initially via configuration, a routing
service such as a BGP Route Reflector or a red-to-black address
translation scheme.
Data is forwarded into the appropriate security association as per
the virtual forwarding table constructed at the VPN boundary by BGP.
The black domain may use static, IGP or BGP routing as appropriate.
The figure above presents one possible routing model for the black
domain. The information exchange between the red and black domains
in this model is restricted to the knowledge in the red domain of the
black address to red address mapping of the remote enclave CE router.
The proposal is further explained by describing the different
functional components at the VPN boundary and the roles played by
them in the VPN as shown in Figure 3
Bose, et al. Expires August 30, 2005 [Page 6]
Internet-Draft Secure L3VPN February 2005
PLAINTEXT | CIPHERTEXT
(Red) | (Black)
|
+---------------+ |
PT Prefixes | Intra-Domain | |
R1,R2,R3 | Routing | |
+---------------| |
| |
| |
Route|Redistribute |
| |
| |
+-----------+ CT-PT +---------------+ CT IP |
| BGP Route |<---------->| Inter-Domain |<--------+ |
| Reflector | Routes | Routing | Addr | |
+-----------+ +---------------+ = | |
R1->B1.H1 | B1.H1 | |
R2->B1.H1 FIB | Table | |
R3->B1.H1 +---------------+ +-----+------+
| Forwarding |-----| Encryption |
+---------------+ +-----+------+
|CT IP Addr
|
Figure 3: Functional Components at Secure VPN Boundary
2.2. Functional components at the VPN boundary
The role of the various functions at the VPN boundary as depicted in
Figure 3 are:
o Intra-Domain Routing: This function advertises, withdraws, and
summarizes the routes in the red enclave. It maintains an
internal routing table for the red domain. This routing table is
provided to the Inter-Domain Routing function for advertisement to
remote enclaves.
o Encryption: This function encrypts and decrypts all data traffic
into IPsec security associations with peer enclaves. It
establishes these security associations with a peer encryptor
using the IP address provided by the Forwarding function. The
encryption function has an IP address on the black side (CT IP
Addr) and an IP address on the red side (PT IP Addr), which is
used for forwarding data in the respective domains.
o Inter-Domain Routing: This function imports the internal routing
table from the Intra-Domain Routing function. It also advertises
the CT IP Addr of the encryption as the next-hop for the internal
Bose, et al. Expires August 30, 2005 [Page 7]
Internet-Draft Secure L3VPN February 2005
red routes of the enclave. It provides this information to its
peer functions in the remote enclaves through a protocol such as
BGP. It also provides this information to a Route Reflector which
can be queried by remote enclaves to learn the CT IP Addr of the
encryption function for an internal red route. This function also
manages the information transfer of control plane information
between the red and black domains. In secure VPNs, the CT IP Addr
of the encryption function is accessed by the Inter-Domain Routing
function via manual configuration, SNMP, a simple routing protocol
such as RIP etc.
o Route Reflector: The route reflector function maintains the inter-
domain routing tables as provided the Inter-Domain Routing
function. It converses with other route reflectors to exchange
this routing information. A red enclave Inter-Domain Routing
function can query the route reflector to learn the next-hop
information for remote enclaves. Routes learnt from the Route
Reflector by the Inter-Domain routing function can be used to
populate the Security Policy Database of the encryption function
via manual configuration, SNMP etc.
o Forwarding: This function maintains the forwarding table which is
used to forward data to remote enclaves. It receives this
forwarding table from the Inter-Domain Routing function. The IP
addresses maintained in this forwarding table are used by the
encryption function to set up security associations to remote
enclaves.
These functions and the described interactions construct the proposed
virtual private network. Unicast routing between peer enclaves is
conducted via routing exchanges inside the security associations by
the peer Inter-Domain routing functions or by querying the
neighborhood route reflector.
2.3. Hierarchical Distribution of Reachability Information
In many cases, secure enclaves will not have the correct information
to directly connect and build BGP peering sessions; the correct set
of public internetwork addresses to connect to will be difficult to
discover on a large scale. To resolve this problem, a set of route
servers, or route reflectors [RFC2796], may be maintained for each
secure enclave attached to the insecure internetwork. The BGP
speaker contained within the secure enclave would have a manually
configured list of these route reflectors. Some form of anycast
addressing may be applicable to this situation, though this has not
been thoroughly investigated.
In some situations, it may be difficult to scale a single group of
Bose, et al. Expires August 30, 2005 [Page 8]
Internet-Draft Secure L3VPN February 2005
route reflectors or route servers large enough to support the number
of sites within an interconnected secure enclave. Hierarchical route
reflectors, or hierarchical eBGP route servers, may be used to scale
in these situations. This is common practice in the public Internet.
Bose, et al. Expires August 30, 2005 [Page 9]
Internet-Draft Secure L3VPN February 2005
3. IANA Considerations
This document makes no request of the IANA.
Note to RFC Editor: in the process assigning numbers and building
IANA registries prior to publication, this section will have served
its purpose. It may therefore be removed upon publication as an RFC.
Bose, et al. Expires August 30, 2005 [Page 10]
Internet-Draft Secure L3VPN February 2005
4. Security Considerations
One security concern addressed in this proposal is the transfer of CT
IP address information to the plaintext side. In the current
proposal this is achieved via an authorized manual/automated network
management function on the plaintext side which queries the
encryption function. Alternatively a simple routing protocol like
RIP is used on the plaintext enclave only to provide this
information.
The security policy database for the encryption function, denoted in
the proposal as the forwarding table is also populated with CT IP
address nexthop information for remote enclaves. This information is
again configured via an an authorized manual/automated network
management function on the plaintext side. Only ciphertext IP
addresses fronting remote VPN enclaves are therefore used within the
plaintext enclave for the purposes of routing. Since this
information is only available on the plaintext enclave, which due to
the VPN characteristics of these networks a more secure environment,
misuse of this information within the plaintext enclave is expected
to be minimal.
Bose, et al. Expires August 30, 2005 [Page 11]
Internet-Draft Secure L3VPN February 2005
5. Contributors
o Fred Baker (fred@cisco.com)
o Eric Fleischman (eric.fleischman@boeing.com)
o Julie Tarr (tarr@itd.nrl.navy.mil)
o Tony De Simone (antonio.desimone@jhuapl.edu)
Bose, et al. Expires August 30, 2005 [Page 12]
Internet-Draft Secure L3VPN February 2005
6. Acknowledgements
Initial introductory text is borrowed from [I-D.baker-nested-vpn-
routing] .
Bose, et al. Expires August 30, 2005 [Page 13]
Internet-Draft Secure L3VPN February 2005
7. References
7.1. Normative References
[I-D.baker-nested-vpn-routing]
Baker, F., "Routing across Nested VPNs",
draft-baker-nested-vpn-routing-01 (work in progress),
July 2005.
[RFC3809] Nagarajan, A., "Generic Requirements for Provider
Provisioned Virtual Private Networks (PPVPN)", RFC 3809,
June 2004.
7.2. Informative References
[RFC1075] Waitzman, D., Partridge, C., and S. Deering, "Distance
Vector Multicast Routing Protocol", RFC 1075,
November 1988.
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003,
October 1996.
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
Internet Protocol", RFC 2401, November 1998.
[RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security
Payload (ESP)", RFC 2406, November 1998.
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P.
Traina, "Generic Routing Encapsulation (GRE)", RFC 2784,
March 2000.
[RFC4110] Callon, R. and M. Suzuki, "A Framework for Layer 3
Provider-Provisioned Virtual Private Networks (PPVPNs)",
RFC 4110, July 2005.
Bose, et al. Expires August 30, 2005 [Page 14]
Internet-Draft Secure L3VPN February 2005
Authors' Addresses
Pratik Bose (editor)
Lockheed Martin
700 North Frederick Ave
Gaithersburg, Maryland 20876
USA
Phone: +1-240-462-9083
Fax: +1-301-428-5415
Email: pratik.bose@lmco.com
Ron Bonica
Juniper Networks
Virginia
USA
Phone:
Fax:
Email: rbonica@juniper.net
Russ White
Cisco Systems
North Carolina
USA
Phone:
Fax:
Email: riw@cisco.com
Bose, et al. Expires August 30, 2005 [Page 15]
Internet-Draft Secure L3VPN February 2005
Full Copyright Statement
Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Bose, et al. Expires August 30, 2005 [Page 16]
