Network Working Group Internet Draft Document: draft-luciani-ppvpn-vpn-discovery-01.txt James Luciani Matt Squire Crescent Networks Hatteras Networks Marty Borden Cedell Alexander Atrica Olen Stokes Extreme Networks Pierre Lin Yipes Juha Heinanen Telia Loa Andersson Utfors Ryan Brooks Time Warner Telecom Giles Heron PacketExchange Ltd. September 2001 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 service offered by service providers. There are many technologies over which to implement a VPN service, ranging from IPSec to GRE to MPLS. A common requirement of the VPN methodologies 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 means for site discovery that is independent of any signaling protocol. [Page 1] draft-many-ppvpn-VPN-discovery-00.txt September 2001 1 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. There are a variety of data encapsulations 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. Other 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 equipment (CE) is located at each customer site and potentially operated independently from the service provider equipment, and may be operated by the customer. The CE equipment is connected to provider edge equipment (PE) that sits at the boundary of the provider network. The PE equipment surrounds a core provider equipment (P). This 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 Each PE supporting a particular VPN must be in a multi-access network with all other PEs supporting that same VPN. There is a concept called Pseudo Wires (PW), where L2 data packets are carried in a point-to-point fashion transparently across a network [pwe3]. There is also the concept of a Virtual Private LAN Service [TLS] wherein an Ethernet virtual 802.1d bridge is simulated for a given set of users. A VPLS delivers a layer 2 broadcast domain that is fully capable of learning and forwarding on Ethernet MAC addresses, and is closed to a given set of users. All of these services would benefit from a common set of mechanisms and functions [Page 2] draft-many-ppvpn-VPN-discovery-00.txt September 2001 in order to promote interoperability and co-existence. In this document the term ôVPNö is used to address L2 and L3 VPNs, as well as the PWs and VPLS. 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 can be and are implemented in many and various ways. To date, proposals for discovery have focused on piggy-backing VPN information on 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, as this information must be propagated across the network via the routing protocol. Signaling between PE equipment is required to identify which tunnels are used for which VPNs, 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. 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 is MPLS. 1.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. [Page 3] draft-many-ppvpn-VPN-discovery-00.txt September 2001 2 Heirarchical VPN Identifiers It is highly desirable to use hierarchical identifiers to identify VPN specific information. Hierarchical identifiers permit each organization to guide the use of its 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 (e.g., bobsVpn.serviceProvider.net versus ). 3 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}, 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. [HEINVC] and [HEINETH] describe directory/DNS based approaches which, in conjunction with LDP, enable PE discovery and label distribution for unidirectional VC based VPNs and Ethernet based VPNs respectively. 4 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 identifiers used in signaling matches the identifier used in discovery. Without signaling enhancements, the VPN DNS name must be mapped to the VPN identifier via manual configuration. Note that this is still preferable to no discovery at all as using DNS names still provides a mechanism to add and delete customer sites to particular VPNs. The 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: [Page 4] draft-many-ppvpn-VPN-discovery-00.txt September 2001 1. Resolvers SHOULD refresh VPN DNS names resolved for VPN purposes before their TTL expires. It may be desirable to set the TTL=0 in the A record in order to guarantee an authorative up to the minute response to a DNS query. 2. A PE MUST use the address as identified in the A record of the DNS entry as its source address when signaling other PE equipment in the VPN. 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 client interactions with a DNS server SHOULD attempt to use UDP initially. If the DNS response comes back with the TC bits set then the client MUST attempt to use TCP in order to obtain the entire list of A records. As a potential modification to the above approach, it might be preferable to design a new resource record type which is explicitly designed to apply to the semantics of DNS based VPN discovery. This is for further study. As a general note on doing name resolution across providers, concerns about ownership of the namespace should be somewhat allayed by the fact that even if a VPN spans multiple providers and ASes, it tends to be "owned" by one organization. That may be one of the service providers or the customer himself. 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 are used simply to identify the two unidirectional components of a logical bi-directional 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 5] draft-many-ppvpn-VPN-discovery-00.txt September 2001 Unfortunately, the VC ID and group ID are not hierarchical, and thus if when crossing administrative boundaries its conceivable that matching numbers are not available in all domains. Thus the short flat VC ID space is very limited. Coordination among the domains managing the edge devices is required. When generalizing [MARTINI] to a full mesh topology, 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 IDs. 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, or RSVP-TE is used for signaling (rather than routing protocols as discussed in earlier sections). 6 Security Considerations A Virtual private network, by its very nature implements a policy, as agreed upon between the customer and provider, that hides information about the customerÆs VPN from others. It is reasonable to assume that this policy would require restricting anyone other than the customer from deriving that customerÆs sites using mechanisms of the provider. An even more important security requirement is that a customer not be able to manipulate the site information about another customer. (It is possible that 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 [Page 6] draft-many-ppvpn-VPN-discovery-00.txt September 2001 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 conceivably be used to provide PE equipment with the ability to register itself with the DNS server upon configuration into a particular VPN. These possibilities are recognized but not investigated within this draft. 7 Issues We list some issues that are not resolved or discussed in this draft that will be considered in future revisions of the draft. * Specific recommendations for TLV formats for LDP, RSVP-TE, and CR-LDP and inter-working with current Martini proposal. * Discuss issues of scale (how many PE sites can be supported)? 8 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. [TLS] Lasserre, Marc, et al., " Transparent VLAN Services over MPLS", draft-lasserre-tls-mpls-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. [HEINVC] Heinanen, J., "Directory/LDP Based Unidirectional Virtual Circuit VPNs", draft-heinanen-dirldp-uni-vc-vpns-01.txt, Work in Progress. [HEINETH] Heinanen, J., "Directory/LDP Based Ethernet VPNs", draft- heinanen-dirldp-eth-vpns-00.txt, Work in Progress. 9 Acknowledgments 10 Author's Addresses Matt Squire Hatteras Networks 639 Davis Drive Research Triangle Park, NC 27709 Email: msquire@hatterasnetworks.com James V. Luciani [Page 7] draft-many-ppvpn-VPN-discovery-00.txt September 2001 Crescent Networks 900 Chelmsford Lowell, MA 01851 Email: jluciani@crescentnetworks.com Marty Borden Atrica, Inc. Email: mborden@acm.org Cedell Alexander Olen Stokes Extreme Networks Research Triangle Park, NC 27709 Email: calexander@extremenetworks.com, ostokes@extremenetworks.com Pierre Lin Yipes Communications, Inc. Email: plin@yipes.com Juha Heinanen Telia Finland Email: jh@telia.fi Loa Andersson Utfors Research, Architecture and Future Lab (URAX) Utfors AB R…sundav„gen 12 Box 525, 169 29 Solna, Sweden Office: +46 8 5270 2000 Email: loa.andersson@utfors.se Ryan K. Brooks Time Warner Telecom, Inc. 3235 Intertech Drive Brookfield, WI 53045 Email: ryan@twtelecom.net Giles Heron PacketExchange Ltd. The Truman Brewery 91 Brick Lane LONDON E1 6QL United Kingdom Tel.: +44 7880 506185 Email: giles@packetexchange.net [Page 8]