One document matched: draft-luciani-ppvpn-vpn-discovery-03.txt
Differences from draft-luciani-ppvpn-vpn-discovery-02.txt
Network Working Group
Internet Draft
draft-luciani-ppvpn-vpn-discovery-03.txt
Matt Squire, Editor Jim Luciani
Hatteras Networks
Juha Heinanen Cedell Alexander
Song Networks AMCC
Pierre Lin Olen Stokes
Yipes Extreme Networks
Loa Andersson Marty Borden
Giles Heron Ryan Brooks
PacketExchange Ltd. Time Warner Telecom
October 2002
Expires: April 2003
Using DNS for VPN Discovery
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
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.
Abstract
Virtual private networks are becoming a common offering of many
service providers. There are many technologies with which to
implement a VPN service, ranging from MPLS to GRE to IPSEC. A
common requirement of all VPN technologies is the need to discover
all of the sites, or at least all the provider equipment associated
with the sites, that are in a particular VPN. DNS provides a
simple and commonly available mechanism for site discovery that is
independent of any signaling or tunneling protocol. This draft
proposes the use of DNS as a discovery mechanism for VPN maintenance
and control.
[Page 1]
draft-luciani-ppvpn-vpn-discovery-03.txt October 2002
1 Specification of Requirements
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL
NOT","SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC 2119.
2 Introduction
Virtual networking services are being offered by more and more
service providers. There are many flavors of VPNs available in the
market today, depending on the customer requirements and provider
abilities. Multiple data encapsulations can be used to transport
data between customer sites. VPNs may be offered as Layer 2 or
Layer 3 services. VPNs may be based on an overlay model or a
virtual router model. Many variations are possible.
A VPN consists of a set of customer sites interconnected by one or
more provider networks, providing the semblance of private
connectivity between the sites over either a private or public
backbone network. The following terminology will be used
throughout. Customer edge (CE) equipment is located at each customer
site and is potentially operated independently from the service
provider equipment. CE equipment may be operated by the customer.
The CE equipment is connected to provider edge (PE) equipment that
sits at the boundary of the provider network. The PE equipment
surrounds a core provider equipment (P). This situation is depicted
in Figure 1.
A---|------| |-----| |------|---A
| PE |-------| P |--------| PE |
A---|------| |-----| |------|---B
| |
| |
| Service Provider |
| Backbone Network |
| |
| |------| |
|----------| PE |------------|
|------|
| | |
| | |
A A B
A: Company A Virtual Network
B: Company B Virtual Network
Figure 1. Virtual Network Model
[Page 2]
draft-luciani-ppvpn-vpn-discovery-03.txt October 2002
All PE equipment supporting a particular VPN must be in a multi
access network with all other PE equipment supporting that same VPN.
There are multiple strategies for interconnecting PE equipment to
form a VPN. A pseudo-wire (PW) provides a point-to-point tunnel to
carry layer two traffic transparently across a network [PWE3]. A
Virtual Private LAN Service [TERM] simulates a multi-access Ethernet
LAN segment for a given set of users. A VPLS delivers a layer 2
broadcast domain that is fully closed to a given set of users.
All of these services would benefit from a common set of mechanisms
and functions to promote interoperability and co-existence. In this
document, the term “VPN” is used to address L2 and L3 VPNs, as well
as PWs and VPLSs.
Certain base functions are common to many of the technologies used
to build VPNs. Two such functions are Discovery and Signaling:
* Discovery. An optional but incredibly beneficial function where
a PE device involved in a particular VPN discovers the other PE
equipment in that VPN.
* Signaling. In many cases, a signaling protocol is required
between PE equipment so that particular data flows can be
identified and correlated with the VPN.
These functions have been implemented in many and various ways.
To date, proposals for VPN discovery have focused on including VPN
information in BGP and IGP routing protocols. This method has the
unfortunate effect of increasing the size of routing tables within
the set of affected provider domains, even for those devices that
are not involved in the VPN. This increase in size may be quite
significant in some cases.
There are other disadvantages to linking discovery and signaling to
each other, and to an existing routing protocol. Routing changes or
recalculations could interfere with the discovery and signaling
functions of VPNs. When PE equipment is connected with explicitly
routed LSPs, for example, such interference is completely
unwarranted. Likewise, VPN changes (adding or deleting VPN support)
impact routing tables with unnecessary updates, as this information
must be propagated across the network via the routing protocol.
Signaling between PE equipment is required for several reasons:
* to identify which tunnels are used for which VPNs,
* to exchange "additional" information that is beyond the IP
address of the remote PE (for example, the MTU size),
* to correlate two unidirectional tunnels together to form a
bi-directional virtual link, and
* to give some indication on how to mux/demux traffic from
multiple VPNs onto a single tunnel.
[Page 3]
draft-luciani-ppvpn-vpn-discovery-03.txt October 2002
VPN signaling enhancements have been proposed for LDP, RSVP-TE, CR
LDP, BGP, and OSPF. Note that correlating two unidirectional
tunnels is only applicable when the underlying data transport
technology uses unidirectional tunneling (such as MPLS).
3 Hierarchical VPN Identifiers
It is highly desirable to use hierarchical identifiers to identify
VPN membership. Hierarchical identifiers permit independent
organizations to guide the use of their own identifier space. DNS
names satisfy a hierarchical naming scheme, and they have an
advantage over numeric schemes in that the user can often infer
semantics from the identifier. For example, an identifier such as
bobsVpn.serviceProvider.net conveys much more information than an
identifier such as <AS 10, ID 64>.
4 Using DNS for Discovery
DNS provides mechanisms to resolve a DNS name into a set of IP
addresses. Normally, these addresses are interpreted as an
"anycast" identifier, i.e., any of the addresses can be used to
provide connectivity to the named service. When using DNS for VPN
resolution, *all* of the addresses are used, and are taken to
identify the set of PE equipment that supports the named VPN. Thus,
when a PE 10.1.1.1 resolves bobsVpn.serviceProvider.net into
{10.1.1.1, 10.2.1.1, 10.5.1.1} via a DNS query, that PE has the IP
addresses of the other PEs serving customer sites in
bobsVpn.serviceProvider.net. The PE can then initiate signaling to
these other addresses in order to establish the bi-directional
tunnel for data transfers.
Using DNS for discovery necessitates the use of a signaling protocol
whenever there is need to determine information in addition to the
IP address of other PE equipment. For example, when using MPLS as
the tunneling technology, signaling is required to determine the
MPLS label with which to encapsulate traffic for the VPN to each
other PE.
5 Examples
[MARTINI] provide mechanisms for forming a point-to-point L2 VPN
between two sites. In the proposal, each side must be configured
with the address of the other endpoint of the tunnel, a VC ID, and a
group ID. The VC ID and group ID have no semantics; they simply
identify the two unidirectional components of a logical
bidirectional link. The group ID has additional function in the
wildcard removals of associations, but that function is not
applicable to this discussion. At the PE equipment, a particular
VPN (VLAN, DLCI, etc.) is associated with the tunnel definition
(endpoint, VC ID, group ID) via configuration.
[Page 4]
draft-luciani-ppvpn-vpn-discovery-03.txt October 2002
Unfortunately, the VC ID and group ID are not hierarchical, and when
crossing administrative boundaries it is conceivable that matching
numbers are not available in all domains. Thus, the flat VC ID
space is very limiting. Coordination among the domains managing the
edge devices is required.
When generalizing [MARTINI] to a full mesh topology as in VPLS
[TERM], the problem of configuring the peers becomes more
problematic as each peer must be configured with the address of
every other. Additionally, the configuration of more PEs must be
correlated in the group and VC ID parameters.
It would be simpler if the PEs could simply be configured with the
VPN DNS name, the associated VPN (VLAN, DLCI, etc.), and the group
ID. The peers could then be discovered via DNS resolution, and the
VPN DNS name could be used in signaling (instead of the VC ID) to
determine the data channels for this VPN.
Although this section discussed DNS based discovery based on the
[MARTINI] techniques, the discovery mechanism is generally
applicable to any environment where LDP, CR-LDP, RSVP-TE, or L2TP is
used for signaling (rather than routing protocols as discussed in
earlier sections).
6 Interactions with Signaling
Current signaling proposals use some variation of a VPN identifier
to indicate the VPN that will be used on that specific data channel.
These VPN identifiers are of fixed length and potentially with some
semantic interpretation. In LDP, this VPN identifier (the VC ID) is
unique to a pair of PE devices, not globally unique, and not unique
to a single PE. Thus coordination of the VC IDs is required.
Although DNS discovery can be used without modifications to
signaling, configuration is reduced if the identifier used in
signaling matches the identifier used in discovery. Without
signaling enhancements, the VPN DNS name used in discovery must be
mapped to the VPN identifier used in signaling via manual
configuration. Note that this is still preferable to no discovery
at all as using DNS names provides a mechanism to add and delete
customer sites to particular VPNs. The <vpn name, vpnid> mapping
issue might also be resolved by including the VPNID (route
distinguisher) in the name, e.g., 64.10.vpn.isp.fi.
Some guidelines when using DNS with an explicit signaling protocol
are:
1. Resolvers SHOULD refresh VPN DNS names resolved for VPN
purposes before their TTL expires, or within a configured
timeout period if the TTL of the A record is zero.
2. A PE MUST use its address as identified in the A record of the
DNS entry as its source address when signaling other PE
equipment in the VPN.
[Page 5]
draft-luciani-ppvpn-vpn-discovery-03.txt October 2002
3. If a PE receives a signaled request from a PE not currently in
the set of PE addresses associated with a VPN, the PE SHOULD
re-request the DNS information for the VPN DNS name. If the
requestor source IP address is still not in the list of A
records, the request SHOULD be rejected. If the requestor
source IP address is in the list of A records, the request
SHOULD be accepted.
4. When a refresh or new query results in any A records to which
the local PE is not currently connected to for this VPN, and
which is not one of its own IP addresses, the local PE
equipment SHOULD initiate signaling to those newly discovered
addresses.
5. When a signaled request to a PE device that was listed in the A
records for a VPN DNS name is rejected by the destination, the
request should be retried using exponential backoff.
6. All interactions with a DNS server SHOULD use TCP (instead of
UDP) to facilitate queries or responses with a large number of
A records.
When performing name resolution and VPN connectivity across multiple
providers, one organization (a provider, the customer, or a third
party) will generally own the namespace for that VPN. That
organization will be responsible for controlling the PE membership
in that VPN. In this case, the other organizations derive VPN
connectivity relationships from information provided by that
organization via DNS queries.
Alternatively, if a provider does not wish to relinquish control of
the discovery process, multiple providers could maintain their own
DNS entries. The entries would have to be synchronized via an
external process when membership changes occur. For example, one
service provider could use bobsVpn.serviceProvider1.net as the DNS
VPN name for the VPN equipment under its control, while another uses
someOtherVpn.serviceProvider2.net for the equipment under its
control.
7 DNS Zone Update Latency
In order to make addition and removal of VPN PEs as fast as
possible, it is important to minimize the latency of DNS zone
updates. This can be achieved by turning on DNS NOTIFY [NOTIFY] in
the master server for each VPN zone and/or by configuring the
refresh times of the zones small, e.g. zero.
8 DNS Message Size
Correct operation of VPNs requires that the IP addresses of all PE
routers of a VPN fit into a single DNS response. As described in
[DNS-CLARIFY], if a PE receives a response that has the truncated
header bit (TC bit) set, it must ignore that response, and query
again using TCP to permit larger replies.
[Page 6]
draft-luciani-ppvpn-vpn-discovery-03.txt October 2002
9 Security Considerations
A VPN, by its very nature, implements a policy that hides
information about a customer’s VPN from other customers. It is
reasonable to assume that this policy might include restricting
access to information about a customer's sites. An even more
important security requirement is that a customer not be able to
manipulate the site information of another customer. The provider
may wish to allow customers to manipulate their own site
information, although this would likely be done through an indirect
method.
As discovery is only the first step in establishing a VPN,
implementing security in discovery in no way secures a VPN.
Likewise, not having a secure discovery process does not imply that
the VPN is not secure. In the end, the provider must prevent
unauthorized access to the VPN data streams. Knowing which PEs
participate in a VPN has little impact on that security requirement.
For those providers that wish to secure the discovery process
itself, DNS includes many security enhancements. For example, DNS
implementations commonly provide access control lists (ACLs) that
could be used to prevent unauthorized sources from resolving
particular domains, thus preventing unauthorized sources from
obtaining information on DNS membership. Additionally, DNSSEC
provides methods to authenticate the validity of DNS information,
allowing a resolver to authenticate the information.
DNS also provides a dynamic update ability that could be used to
provide the ability for a PE to register itself with the DNS server
upon configuration into a particular VPN. These possibilities are
recognized but not investigated within this draft.
10 References
[RFC2026] Bradner, S., "The Internet Standards Process -- Revision
3", BCP 9, RFC 2026, October 1996.
[MARTINI] Martini, Luca, et al., "Transport of Layer 2 Frames Over
MPLS", draft-martini-l2circuit-trans-mpls-05.txt, Work in
Progress.
[TERM] Andersson, L., "PPVPN Terminology", draft-andersson-ppvpn
terminology-00.txt, Work in Progress.
[PWE3] Xiao, XiPeng, et al.,"Requirements for Pseudo-Wre Emulation
Edge-to-Edge (PWE3)",draft-ietf-pwe3-requirements-01.txt, Work in
Progress.
[NOTIFY] P. Vixie, "A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY)", RFC 1996, August 1996.
[Page 7]
draft-luciani-ppvpn-vpn-discovery-03.txt October 2002
[DNS-CLARIFY] Elz and Bush, "Clarifications to the DNS
specification", RFC 2181, July 1997.
11 Author's Addresses
Matt Squire Pierre Lin
Hatteras Networks Yipes Communications, Inc.
Email: msquire@hatterasnetworks.com plin@yipes.com
Marty Borden Jim Luciani
Email: mborden@acm.org james_luciani@mindspring.com
Cedell Alexander Olen Stokes
AMCC Extreme Networks
Email: calexander@amcc.com ostokes@extremenetworks.com
Loa Andersson Juha Heinanen
Email: loa@pi.se Song Networks
Email: jh@song.fi
Giles Heron Ryan K. Brooks
PacketExchange Ltd. Time Warner Telecom, Inc.
Email: giles@packetexchange.net ryan@twtelecom.net
[Page 8] | PAFTECH AB 2003-2026 | 2026-04-21 23:01:52 |