Network Working Group T. Hardie Internet-Draft Google Intended status: Informational March 5, 2012 Expires: September 5, 2012 The Reachability Method (RM) DNS Resource Record draft-hardie-rm-rr-00 Abstract This draft proposes a DNS resource record for providing adjunct reachability methods for network hosts or resources which are only accessible within limited reachability domains. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on September 2, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Hardie Expires September 2, 2012 [Page 1] Internet-Draft The RM RR March 2012 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4 3. DNS Consideration . . . . . . . . . . . . . . . . . . . . . . . 4 4. The format of the RM RR . . . . . . . . . . . . . . . . . . . . 4 4.1. Ownername, class, and type . . . . . . . . . . . . . . . . 4 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5. RM RDATA Wire Format . . . . . . . . . . . . . . . . . . . . . 5 6. Example Use . . . . . . . . . . . . . . . . . . . . . . . . . . 6 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 Hardie Expires September 2, 2012 [Page 2] Internet-Draft The RM RR March 2012 1. Introduction For the purposes of this document, a limited reachability domain (LRD) is a network segment, overlay network, or bounded network whose nodes are not generally reachable outside an administratively controlled domain. Enterprise networks are common examples. Many limited reachability domains use private address space or unrouted space. A reachability method in this context is a mechanism that provides access to a limited reachability domain from outside the usual administrative boundary. This document expresses reachability methods by designating the host, port, and protocol used for access, using a URI. Note that few reacahability methods currently have registered URI schemes, so effective deployment may be gated by the development of an effective set of interoperable designations of these schemes. A common method for providing access to limited reachability domain is the point-to-multipoint virtual private network. VPNs in enterprise contexts commonly provide a single tunnel end point per client, configured at set-up. Once the tunnel has successfully connected, the client gets access to the internal network's full resources, including the internal view of any split DNS. Though effective, this method generally either limits the granularity of security (to what is often called a "crunchy on the outside, soft in the middle" approach) or requires additional configuration by the network operations team to limit reachability further after the clients have traversed the tunnel. Even in the cases where such additional configuration is completed (by assigning different VPN users to different VLANs, for example), it is generally per client or user rather than by application. An alternative approach would be to provide different limited reachability domains for different internal resources. In that approach, a client would be connected to an LRD specific to the resource required. Because each of those LRDs could use different access methods and be available via different ingress points, it would be valuable to have a general mechanism for distributing the reachablity method needed for each resource. This draft proposes a DNS Resource Record for this purpose, with the assumption that it would be made available on the public side of any split DNS. 1.1. Requirements Language 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 [RFC2119]. Hardie Expires September 2, 2012 [Page 3] Internet-Draft The RM RR March 2012 2. Applicability Statement Reachability Method (RM) records can be queried directly, but it is expected that they will commonly be returned as additional data by servers relating information about hosts that are located within a limited reachability domain (e.g. with queries for the A or AAAA record associated with a host within an enterprise network). While it is possible to associate an RM RR with a service name such as those used by SRV or URI RRs, this is not generally recommended, since the reachability information may vary for each target. It would also be possible to associate a reachability method with a wildcard target (like *.internal.example.net), but this would limit the advantage over straight configuration to load-balancing entry points according to the weight and priority of the targets given in the RM RRs. 3. DNS Consideration If the reachability method varies over time, the TTL of the RM RR will need to be managed to match and coordinated with the TTL of the resource to be reached. If the reachability method varies according to other characteristics, something akin to split DNS must be managed, with the usual conflicts with the DNS's core loose consistency model. 4. The format of the RM RR This is the presentation format of the RM RR: Ownername TTL Class RM Priority Weight Target The RM RR does not cause any kind of Additional Section processing. 4.1. Ownername, class, and type The type number for the RM record is TBD (to be assigned by IANA). The RM resource record owner name has no special considerations. The RM resource record is class independent. The RM resource record has no special TTL processing requirements, though the considerations on coordiation stated above apply. Hardie Expires September 2, 2012 [Page 4] Internet-Draft The RM RR March 2012 4.2. Priority The priority of the target Reachability Method in this RR. Its range is 0-65535. A client MUST attempt to contact the URI with the lowest-numbered priority it can reach; RMs with the same priority SHOULD be tried in the order defined by the weight field. 4.3. Weight A server selection mechanism. The weight field specifies a relative weight for entries with the same priority. Larger weights SHOULD be given a proportionately higher probability of being selected. The range of this number is 0-65535. 4.4. Target The target is a URI, enclosed in double-quote characters ('"'). Resolution of the URI is according to the definitions for the Scheme of the URI. The URI is encoded as one or more RFC 1035 section 3.3 [RFC1035]. 5. RM RDATA Wire Format The RDATA for a RM RR consists of a 2 octet Priority field, a two octet Weight field, and a variable length target field. Priority and Weight are unsigned integers in network byte order. The Target field contains the URI of the Reachability Method (without the enclosing double- quote characters used in the presentation format), encoded as a sequence of one or more (as specified in section 3.3 of RFC 1035, where all but the last are filled up to the maximum length of 255 octets. The Target field can also contain an IRI, but with the additional requirements that it is in UTF-8 RFC 3629 [RFC3629] and possible to convert to a URI according to section 3.1 of RFC 3987 [RFC3987] and back again to an IRI according to section 3.2. Other character sets than UTF-8 are not allowed. The domain name part of the IRI can be either an U-LABEL or an A-LABEL as defined in RFC 5890 [RFC5890]. Hardie Expires September 2, 2012 [Page 5] Internet-Draft The RM RR March 2012 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Priority | Weight | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ / / / Target / / / +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 6. Example Use Probably the easiest way to understand how this RR might be used is by contrasting it with happens with a user without it. Imagine a user is trying to use a financial application client from a home or hotspot network. The server for that client resides within the user's enterprise network. If invoked, the client will attempt to resolve the hostname "accounting.corp.example.com". In the currently common scenario, that hostname would not be visible from a home or hotspot because of split DNS. To use it, the user must recognize that the required host was within a corporate domain and initiate a VPN in order to succeed at the DNS request. It is likely that once that VPN was up, the point-to-multipoint nature of the VPN would allow the user to connect to accounting.corp.example.com with the financial application client. Once the VPN is up, however, other resources within corp.example.com's network are likely to be reachable to processes on the user's device. The simplest implementation of the alternate method described here would be a wrapper script for the financial application client. The wrapper script looks up the hostname accounting.corp.example.com and gets an RM record along with the A or AAAA record. The script then creates the tunnel using the method defined in the RM method, which would be something like: finance.example.com IN RM 10 1 "ssh://financetunnel.example.com:/" prompting the user for authentication credentials appropriate to the target if need be. The script then bind the application to the tunnel interface when it starts, so that it can only reach that portion of the network accessible from financetunnel.example.com. Real deployments based on wrapper scripts seem unlikley, given the need to manage authentication credentials and DNSSEC validation of the records returned, but the basic series of steps would be the same: get the reachability method associated with a resource; use it Hardie Expires September 2, 2012 [Page 6] Internet-Draft The RM RR March 2012 to create an overlay network or tunnel; associate the calling application with the limited reachability domain made available via the tunnel or overlay. 7. Acknowledgements The work on which this is based was co-authored with Tom Keitel. The text for describing both the presentation and wire formats of the priority field and the weight field of this RR are lifted wholesale from the URI RR internet-draft submitted by Patrik Faltstrom and Olaf Kolkman URI-RR [I-D.faltstrom-uri]. This document's overall organization and IANA considerations are also largely derived from that draft. Harald Alvestrand kindly provided early feedback on this draft, despite his overall impression of its wisdom.. 8. IANA Considerations This memo asks IANA to register a new Resource Record Type, adding the line below, suitably amended, to the registry named Resource Record (RR) TYPEs and QTYPEs as defined in BCP 42RFC 5395 [RFC5395] and located at http://www.iana.org/assignments/dns-parameters. TYPE Value and meaning Reference ----------- --------------------------------------------- --------- RM TBD a URI for a service (per the owner name) [RFCXXXX] 9. Security Considerations The overall goal of the RM RR is to standardize a way to nominate a monkey-in-the-middle, so using it without a DNSSEC-based assurance that the data you have received is the data placed there by the zone administrator would be deeply unwise. Placing information about the approved monkey-in-the-middle into the public DNS also makes it a potential target of attack, both for denial of service and for infiltration Why, then, would you take this approach? If you have a series of services which need to be reachable to users but which cannot themselves be safely be made accessible to the public Internet, you can use this approach to segment the reachability to each, using unique authentication or authorization decisions for the individual overlay networks. The authentication methods for the bastion hosts can also vary and be made arbitrarily strong, something which may not be possible for services which are being used but may not be Hardie Expires September 2, 2012 [Page 7] Internet-Draft The RM RR March 2012 maintained by their creators. The choice of the URI format for the target is also somewhat problematic, as few candidate reachability methods have registered URI schemes. If the registered schemes are not available, it will be tempting to mint new or local schemes which may miss critical fetures of the actual reachability methods. 10. References 10.1. Normative References [RFC1035] Mockapetris, P., "Domain names - implementation and specification", STD 13, RFC 1035, November 1987. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 10646", STD 63, RFC 3629, November 2003. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005. [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA Considerations", RFC 5395, November 2008. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, August 2010. 10.2. Informative References [I-D.faltstrom-uri] Faltstrom, P. and O. Kolkman, "The Uniform Resource Identifier (URI) DNS Resource Record", draft-faltstrom-uri-06 (work in progress), October 2010. Hardie Expires September 2, 2012 [Page 8] Internet-Draft The RM RR March 2012 Author's Address Ted Hardie Google 1600 Amphitheatre Parkway Mountain View, CA 94043 US Email: hardie@google.com Hardie Expires September 2, 2012 [Page 9]