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 customers 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]