Another deployment document
Howard C. Berkowitz
hcb at mail.clark.net
Mon Oct 18 17:59:58 EDT 1999
Internet Engineering Task Force Howard C. Berkowitz
INTERNET-DRAFT Gett Communications
<draft-berkowitz-vpn-tax-01.txt>
Expires August 1999
Requirements Taxonomy for Virtual Private Networks
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
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''.
To learn the current status of any Internet-Draft, please check the
``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe),
ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).
Abstract
Most useful networking ideas involve some level of abstraction.
Virtual private networks (VPN) map an abstraction of an user-defined
interface onto an infrastructure. Multihoming strategies are
virtualizations in the infrastructure [Berkowitz multihome]
that should be invisible to the VPN. Proprietary definitions of VPNs
proliferate in
the marketplace, to the confusion of end users. This memorandum
proposes a taxonomy which can describe a variety of VPN models.
It does not recommend any specific model, but suggests a consistent
way of describing specific VPNs. This document differs from some
other working papers that go more deeply into the VPN mechanisms.
In contrast, this document is focused on user requirments.
1. Introduction
Previous working papers [Gleeson, Muthukrishnan, Rosen] have dealt
with fairly specific models where specific underlying technologies are
considered at length. This document takes a different approach, trying
to focus on requirements rather than technology. It may very well be
appropriate to merge several of these proposals.
Any VPN will have a minimal set of core capabilities, which, alone,
are unlikely to satisfy any real-world user requirements. The taxonomy
here provides a systematic way for extending the core capabilities to
meet those requirements. It also provides a way of describing requirements
for the shared infrastructure over which the VPN runs.
A description of a specific VPN requirement will state the core capabilities
optional user services, and the administrative model. A response to this
requirement will state the infrastructure technologies and how the user
requirements will map to them.
The taxonomy consists of:
Core capabilities
Optional capabilities
Administrative model
Mapping of user services to different infrastructures
Infrastructures
For a VPN to work, it must be possible to map the user services to
corresponding capabilities in the infrastructure. Mechanisms for these
mappings are outside the scope of this taxonomy. A quality of service
user requirement, for example, could map to ATM QoS facilities, to RSVP
or differentiated services in an IP network, or to priorities in an 802.1p
LAN.
2. Core Capabilities
To define a VPN, it is necessary to be able to define an administrative
mechanism for designating membership in the VPN. A given host may belong
to one or more VPNs, as well as the global Internet.
Useful definitions of VPNs include several policy statements beyond the
administrative policies that define membership. An operational policy needs
to be specified, which defines the organizations, inside or outside the
enterprise, which are responsible for moves and changes, troubleshooting,
performance monitoring, audit, etc. There should be a security
policy and a QoS policy, even if these policy statements state there are no
specific security or QoS requirements.
If there are security requirements for the VPN, the owning enterprise
should define a security policy that states the allowable connectivity
over multiple VPNs and public networks.
The set of members of a VPN will have an identifier [Fox], although that
identifier might be null.
3. Optional Capabilities
VPNs of practical use will have one or more optional capabilities in
addition to the core set. Not all VPNs will need every capability.
3.1 Quality of Service
The VPN may provide quality of service support. It either may accept
QoS requests from end users signaled with RSVP, IP precedence bits, etc.,
or may internally assign quality of service requirements to be mapped
to the transmission infrastructure. For quality of service to be effective,
the infrastructure either must support explicit quality of service requests,
or there must be a high level of confidence that the infrastructure
consistently provides adequate QoS. Assumptions about QoS need to be
stated as part of any VPN design.
3.2 Security
User connectivity may be defined to include security using a variety
of security mechanisms, including IPsec, L2TP, etc. These various mechanisms
may provide other services, such as connectivity. L2TP can provide per-user
authentication, or may have no security functions. Security may be
requested on a discretionary basis by end user hosts, or the VPN may
enforce a mandatory security policy. Cryptographic protections may
be under the control of the enterprise, using host-to-host or host-to-
security gateway methods, or the infrastructure may be trusted to provide
encryption. The responsibilities for user authentication, device
authentication, encryption, logging, and audit must be specified as
part of the design of any practical VPN.
3.3 Addressing and load sharing
The VPN may provide address assignment, presumably with DHCP. It also
may provide network address translation (NAT), network address and port
translation (NAPT), and load-shared network address translation (LSNAT).
DNS services may be associated with the VPN, and operated by the enterprise
or the service provider.
While VPNs can appear as a single IP prefix (i.e., a single user domain),
single prefixes will not scale to large size. The provider may set up
multiple prefixes to serve user connectivity requirements. If there are
multiple prefixes, it needs to be specified if routing among them is
an enterprise or provider responsibility.
3.4 Frame Sequencing and MTU Support
There may be requirements to deliver frames or packets in sequence.
In addition, there may be a requirement to support, efficiently, larger
MTUs that the provider might normally handle.
3.5 Non-IP Protocol Support
While the emphasis of this taxonomy is on VPNs that support IP, the VPN may
provide mechanisms for encapsulating non-IP protocols for transmission over
an IP infrastructure. Techniques for doing so include NetBIOS over TCP
[RFC1001/1002], IPX over IP [RFC1234], GRE [RFC1702], etc.
3.6 Multicast Support
The IP VPN, as seen by end users, may support broadcast or multicast
addressing.
3.7 Availability
The enterprise may specify availability requirements for the infrastructure
and for VPN gateway services. If redundancy of links or components is
needed to provide the desired level of redundancy, these redundant
components may either be visible to, or hidden from, the using enterprise.
3.8 Dynamic Provisioning
The enterprise may need to be able to signal to the provider that new
sites and/or users (especially dial users) have been added to the VPN.
While it should generally be transparent to the VPN if new users are
added to VPNs at existing sites, security requirements may make it necessary
to inform the VPN, securely, that a new user has been added or an old user
deleted.
4. Operational Model
Several operational issues apply in VPN deployment: whether the
enterprise is responsible for any customer premises equipment (CPE) that
intelligently interoperates with components of the shared provider
infrastructure, whether a service
provider is contracted to operate the WAN infrastructure, and how any VPN
client software in user hosts is managed and operated. Some organizations
consider a VPN using all dial facilities, or other public facilities
operated by a service provider that is not aware of the VPN, to have a
customer-operated shared infrastructure.
A service provider may place service-provider operated equipment at a
customer site, and present a LAN or serial interface to the customer.
Anything beyond the provider device is contractually a provider
responsibility, but it cannot be directly controlled by the customer.
There are two basic models of the administration and management of VPNs,
although subcategories are perfectly viable. In the first category, the
end user organization designs and operates the VPN, often with end user
access through the public dial network. In the second, a service provider
has contractual responsibility for designing and operating the VPN in
response to specified user requirements.
Another aspect of the model is whether clients are aware of the VPN, and
if provider access components are aware of it. In principle, a client could
attach to a generic ISP, establish an encrypted tunnel to a destination
host, and operate transparently to the ISP. The VPN provider may be the
ISP. In such cases, the VPN provider responsibility is to provided logins
and connectivity. The login might specify a class of service to be used
in the provider network.
In an alternative model, the clients do not contain encryption software.
Clients connect natively to the provider's access device through an
administratively trusted link such as the dial telephone network. The
client authenticates with the access device, and the access device(s)
provide cryptographic services.
Yet another model is traffic driven. Routers at customer sites sense
when end user devices wish to send across the VPN, and either route
them to predefined tunnels over dedicated infrastructure, or create
appropriate dial calls to carry the traffic, encrypting if necessary.
5. Mapping to the Infrastructure
The specific means by which end user views of the VPN are mapped onto the
shared infrastructure generally involves tunneling, virtual circuit setup,
or the establishment of a set of labels.
When tunnels are used, they may provide no security (GRE), authentication
(L2TP, L2F, and PPTP), or a wide range of security services (IPsec).
Security services may also be provided by hosts, and a less secure tunnel
mechanism used to carry host-encrypted data.
Alternatively, the mapping of IP connectiviy may be to virtual circuits
using Frame Relay or ATM, or to real circuits with ISDN or analog dial.
When the VPN seen by the user appears to be multicast-capable, but the
infrastructure is connection-oriented, provisions need to be made for
supporting multicast. Techniques here might involve point-to-multipoint
circuits, or the use of multicast replication servers.
Details of these mappings will be in other, infrastructure-protocol-specific
documents.
Tunnel technologies need to be coordinated between the enterprise(s) and the
provider(s). There may be single tunnels between sites, or possibly
multiple
tunnels for loadsharing and increased availability (e.g., with multilink
PPP over IP).
6. Infrastructure Capabilities
When different kinds of infrastructure are proposed, the main requiremment
if for the infrastructure provider to take responsibility that all relevant
user capabilities have matching capabilities in the infrastructure. The
actual mappings are technology-specific and outside the scope of this
document.
This section does not attempt to define the specific infrastructure
technologies that can be used for VPNs. Rather, it examines the
capabilities that may be needed if a user capability is to be mapped
successfully into one or more infrastructures.
Specific VPNs may well be provisioned over one or more infrastructure
types. In such cases, the designer needs to ensure the user capabilities
map into each of the infrastructures.
6.1 Quality of Service
When the user or the enterprise can request explicit QoS, either the
infrastructure must be able to understand the explicit requests, or it
must consistently supply a QoS that meets the most stringent user
requirement.
6.2 Security
Users may be responsible for cryptographic security, transparently to
the provider. Alternatively, the VPN provider may offer encryption.
If the user operates firewalls, VPN tunnels typically will terminate
at the firewall. If the firewall is operated by the service provider,
or if the user has stringent security requirements requiring end-to-end
encryption, there may be compatibility issues of authenticated firewall
traversal.
6.3 Addressing
Providers can use registered or RFC1918 addresses internally in their
networks. These may or may not be visible to the enterprise. When they
are not, there should be a well-defined operational procedure that allows
the user to request traceroutes through IP infrastructures.
When the provider uses VPN identifiers to distinguish between routing
tables for different VPNs, the same addresses, especially from the
private address space, may be reused. Provider engineers should take
care that
6.4 Non-IP Protocol Support
Comnmonly, the enterprise will provide the tunneling necessary to carry
non-IP protocols over the enterprise. When the VPN is offered as a service,
however, the provider may offer appropriate encapsulation services. If
the infrastructure is layer 2 and supports a protocol type field, it may
be appropriate for the provider to encapsulate non-IP traffic with explicit
protocol identification.
6.5 Availability
When a specific availability requirement is defined for the enterprise VPN,
it is a provider responsibility to ensure the infrastructure has the
component reliability, diversity, etc., to meet these needs. It can be
useful to distinguish between availability in the access part of a VPN,
such as modem pools, and the backbone which carries the tunnels over the
long-haul shared infrastructure.
When the provider uses multihoming techniques inside the infrastructure
to provide the availability agreed to by the providers, those multihomed
services are not
part of the VPN. When the enterprise uses application or transport layer
multihoming to provide the availability required by the enterprise, and
the VPN simply provides connectivity among the multihomed hosts, such
multihoming is outside the scope of the VPN.
6.6 Interprovider Connectivity
It may be necessary to provision the VPN infrastructure through multiple
service providers. In such cases, the providers will need inter-provider
provisioning and VPN identification.
Much as a BGP confederation presents a single AS number to the outside
but contains multiple internal ASNs, a multiprovider VPN identifier may
map to a set of publicly visible ASNs. While BGP may be
used to convey VPN reachability information among providers, the actual
destinations may be prefixed with VPN IDs, and carried using the BGP-4
Multiprotocol Extensions. When VPN IDs are used in this manner, the
routes carried need not be visible on the global Internet, but simply
used to exchange information between ISPs with bilateral agreements.
References
[Berkowitz] Berkowitz, H. "To be Multihomed" Work in Progress, IETF,
1999.
[Gleeson] Gleeson, Heinanen, Lin, Armitage, "A Framework for IP Based
Virtual
Private Networks", draft-gleeson-vpn-framework-00.txt.
[Muthukrishnan] Muthukrishnan, Malis, "Core IP VPN Architecture",
draft-muthukrishnan-corevpn-arch-00.txt.
[RFC1001] Protocol standard for a NetBIOS service on a TCP/UDP
transport:
Concepts and methods. NetBIOS Working Group. Defense Advanced
Research Projects Agency, Internet Activities Board, End-to-End
Services Task Force. Mar-01-1987.
[RFC1234] Tunneling IPX traffic through IP networks. D. Provan.
Jun-01-1991
[RFC1702] Hanks, S., et al "Generic Routing Encapsulation over Ipv4
Networks", RFC 1702
Author Information
Howard C. Berkowitz
Gett Communications
PO Box 6897
Arlington VA 22206
phone: +1-703-998-5819
email: hcb at clark.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 17474 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/clew/attachments/19991018/e673042b/attachment.bin>
More information about the Clew
mailing list