Internet DRAFT - draft-hardie-rm-rr
draft-hardie-rm-rr
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 <character-string> 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 <character-string> (as
specified in section 3.3 of RFC 1035, where all but the last
<character-string> 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]
