idnits 2.17.1 draft-hardie-rm-rr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (March 5, 2012) is 4434 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 272, but not defined == Unused Reference: 'RFC3986' is defined on line 313, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5395 (Obsoleted by RFC 6195) == Outdated reference: A later version (-14) exists of draft-faltstrom-uri-06 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group T. Hardie 2 Internet-Draft Google 3 Intended status: Informational March 5, 2012 4 Expires: September 5, 2012 6 The Reachability Method (RM) DNS Resource Record 7 draft-hardie-rm-rr-00 9 Abstract 11 This draft proposes a DNS resource record for providing adjunct 12 reachability methods for network hosts or resources which are only 13 accessible within limited reachability domains. 15 Status of this Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on September 2, 2012. 32 Copyright Notice 34 Copyright (c) 2012 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 50 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 51 2. Applicability Statement . . . . . . . . . . . . . . . . . . . . 4 52 3. DNS Consideration . . . . . . . . . . . . . . . . . . . . . . . 4 53 4. The format of the RM RR . . . . . . . . . . . . . . . . . . . . 4 54 4.1. Ownername, class, and type . . . . . . . . . . . . . . . . 4 55 4.2. Priority . . . . . . . . . . . . . . . . . . . . . . . . . 5 56 4.3. Weight . . . . . . . . . . . . . . . . . . . . . . . . . . 5 57 4.4. Target . . . . . . . . . . . . . . . . . . . . . . . . . . 5 58 5. RM RDATA Wire Format . . . . . . . . . . . . . . . . . . . . . 5 59 6. Example Use . . . . . . . . . . . . . . . . . . . . . . . . . . 6 60 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 61 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 62 9. Security Considerations . . . . . . . . . . . . . . . . . . . . 7 63 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 64 10.1. Normative References . . . . . . . . . . . . . . . . . . . 8 65 10.2. Informative References . . . . . . . . . . . . . . . . . . 8 66 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 8 68 1. Introduction 70 For the purposes of this document, a limited reachability domain 71 (LRD) is a network segment, overlay network, or bounded network whose 72 nodes are not generally reachable outside an administratively 73 controlled domain. Enterprise networks are common examples. Many 74 limited reachability domains use private address space or unrouted 75 space. 77 A reachability method in this context is a mechanism that provides 78 access to a limited reachability domain from outside the usual 79 administrative boundary. This document expresses reachability 80 methods by designating the host, port, and protocol used for access, 81 using a URI. Note that few reacahability methods currently have 82 registered URI schemes, so effective deployment may be gated by the 83 development of an effective set of interoperable designations of 84 these schemes. 86 A common method for providing access to limited reachability domain 87 is the point-to-multipoint virtual private network. VPNs in 88 enterprise contexts commonly provide a single tunnel end point per 89 client, configured at set-up. Once the tunnel has successfully 90 connected, the client gets access to the internal network's full 91 resources, including the internal view of any split DNS. Though 92 effective, this method generally either limits the granularity of 93 security (to what is often called a "crunchy on the outside, soft in 94 the middle" approach) or requires additional configuration by the 95 network operations team to limit reachability further after the 96 clients have traversed the tunnel. Even in the cases where such 97 additional configuration is completed (by assigning different VPN 98 users to different VLANs, for example), it is generally per client or 99 user rather than by application. 101 An alternative approach would be to provide different limited 102 reachability domains for different internal resources. In that 103 approach, a client would be connected to an LRD specific to the 104 resource required. Because each of those LRDs could use different 105 access methods and be available via different ingress points, it 106 would be valuable to have a general mechanism for distributing the 107 reachablity method needed for each resource. This draft proposes a 108 DNS Resource Record for this purpose, with the assumption that it 109 would be made available on the public side of any split DNS. 111 1.1. Requirements Language 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 115 document are to be interpreted as described in RFC 2119 [RFC2119]. 117 2. Applicability Statement 119 Reachability Method (RM) records can be queried directly, but it is 120 expected that they will commonly be returned as additional data by 121 servers relating information about hosts that are located within a 122 limited reachability domain (e.g. with queries for the A or AAAA 123 record associated with a host within an enterprise network). While 124 it is possible to associate an RM RR with a service name such as 125 those used by SRV or URI RRs, this is not generally recommended, 126 since the reachability information may vary for each target. It 127 would also be possible to associate a reachability method with a 128 wildcard target (like *.internal.example.net), but this would limit 129 the advantage over straight configuration to load-balancing entry 130 points according to the weight and priority of the targets given in 131 the RM RRs. 133 3. DNS Consideration 135 If the reachability method varies over time, the TTL of the RM RR 136 will need to be managed to match and coordinated with the TTL of the 137 resource to be reached. If the reachability method varies according 138 to other characteristics, something akin to split DNS must be 139 managed, with the usual conflicts with the DNS's core loose 140 consistency model. 142 4. The format of the RM RR 144 This is the presentation format of the RM RR: 146 Ownername TTL Class RM Priority Weight Target 148 The RM RR does not cause any kind of Additional Section processing. 150 4.1. Ownername, class, and type 152 The type number for the RM record is TBD (to be assigned by IANA). 154 The RM resource record owner name has no special considerations. 156 The RM resource record is class independent. 158 The RM resource record has no special TTL processing requirements, 159 though the considerations on coordiation stated above apply. 161 4.2. Priority 163 The priority of the target Reachability Method in this RR. Its range 164 is 0-65535. A client MUST attempt to contact the URI with the 165 lowest-numbered priority it can reach; RMs with the same priority 166 SHOULD be tried in the order defined by the weight field. 168 4.3. Weight 170 A server selection mechanism. The weight field specifies a relative 171 weight for entries with the same priority. Larger weights SHOULD be 172 given a proportionately higher probability of being selected. The 173 range of this number is 0-65535. 175 4.4. Target 177 The target is a URI, enclosed in double-quote characters ('"'). 178 Resolution of the URI is according to the definitions for the Scheme 179 of the URI. The URI is encoded as one or more RFC 180 1035 section 3.3 [RFC1035]. 182 5. RM RDATA Wire Format 184 The RDATA for a RM RR consists of a 2 octet Priority field, a two 185 octet Weight field, and a variable length target field. 187 Priority and Weight are unsigned integers in network byte order. 189 The Target field contains the URI of the Reachability Method (without 190 the enclosing double- quote characters used in the presentation 191 format), encoded as a sequence of one or more (as 192 specified in section 3.3 of RFC 1035, where all but the last 193 are filled up to the maximum length of 255 octets. 195 The Target field can also contain an IRI, but with the additional 196 requirements that it is in UTF-8 RFC 3629 [RFC3629] and possible to 197 convert to a URI according to section 3.1 of RFC 3987 [RFC3987] and 198 back again to an IRI according to section 3.2. Other character sets 199 than UTF-8 are not allowed. The domain name part of the IRI can be 200 either an U-LABEL or an A-LABEL as defined in RFC 5890 [RFC5890]. 202 1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3 203 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 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Priority | Weight | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 / / 208 / Target / 209 / / 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 6. Example Use 214 Probably the easiest way to understand how this RR might be used is 215 by contrasting it with happens with a user without it. Imagine a 216 user is trying to use a financial application client from a home or 217 hotspot network. The server for that client resides within the 218 user's enterprise network. If invoked, the client will attempt to 219 resolve the hostname "accounting.corp.example.com". In the currently 220 common scenario, that hostname would not be visible from a home or 221 hotspot because of split DNS. To use it, the user must recognize 222 that the required host was within a corporate domain and initiate a 223 VPN in order to succeed at the DNS request. It is likely that once 224 that VPN was up, the point-to-multipoint nature of the VPN would 225 allow the user to connect to accounting.corp.example.com with the 226 financial application client. Once the VPN is up, however, other 227 resources within corp.example.com's network are likely to be 228 reachable to processes on the user's device. 230 The simplest implementation of the alternate method described here 231 would be a wrapper script for the financial application client. The 232 wrapper script looks up the hostname accounting.corp.example.com and 233 gets an RM record along with the A or AAAA record. The script then 234 creates the tunnel using the method defined in the RM method, which 235 would be something like: 237 finance.example.com IN RM 10 1 "ssh://financetunnel.example.com:/" 239 prompting the user for authentication credentials appropriate to the 240 target if need be. The script then bind the application to the 241 tunnel interface when it starts, so that it can only reach that 242 portion of the network accessible from financetunnel.example.com. 244 Real deployments based on wrapper scripts seem unlikley, given the 245 need to manage authentication credentials and DNSSEC validation of 246 the records returned, but the basic series of steps would be the 247 same: get the reachability method associated with a resource; use it 248 to create an overlay network or tunnel; associate the calling 249 application with the limited reachability domain made available via 250 the tunnel or overlay. 252 7. Acknowledgements 254 The work on which this is based was co-authored with Tom Keitel. The 255 text for describing both the presentation and wire formats of the 256 priority field and the weight field of this RR are lifted wholesale 257 from the URI RR internet-draft submitted by Patrik Faltstrom and Olaf 258 Kolkman URI-RR [I-D.faltstrom-uri]. This document's overall 259 organization and IANA considerations are also largely derived from 260 that draft. Harald Alvestrand kindly provided early feedback on this 261 draft, despite his overall impression of its wisdom.. 263 8. IANA Considerations 265 This memo asks IANA to register a new Resource Record Type, adding 266 the line below, suitably amended, to the registry named Resource 267 Record (RR) TYPEs and QTYPEs as defined in BCP 42RFC 5395 [RFC5395] 268 and located at http://www.iana.org/assignments/dns-parameters. 270 TYPE Value and meaning Reference 271 ----------- --------------------------------------------- --------- 272 RM TBD a URI for a service (per the owner name) [RFCXXXX] 274 9. Security Considerations 276 The overall goal of the RM RR is to standardize a way to nominate a 277 monkey-in-the-middle, so using it without a DNSSEC-based assurance 278 that the data you have received is the data placed there by the zone 279 administrator would be deeply unwise. Placing information about the 280 approved monkey-in-the-middle into the public DNS also makes it a 281 potential target of attack, both for denial of service and for 282 infiltration 284 Why, then, would you take this approach? If you have a series of 285 services which need to be reachable to users but which cannot 286 themselves be safely be made accessible to the public Internet, you 287 can use this approach to segment the reachability to each, using 288 unique authentication or authorization decisions for the individual 289 overlay networks. The authentication methods for the bastion hosts 290 can also vary and be made arbitrarily strong, something which may not 291 be possible for services which are being used but may not be 292 maintained by their creators. 294 The choice of the URI format for the target is also somewhat 295 problematic, as few candidate reachability methods have registered 296 URI schemes. If the registered schemes are not available, it will be 297 tempting to mint new or local schemes which may miss critical fetures 298 of the actual reachability methods. 300 10. References 302 10.1. Normative References 304 [RFC1035] Mockapetris, P., "Domain names - implementation and 305 specification", STD 13, RFC 1035, November 1987. 307 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 308 Requirement Levels", BCP 14, RFC 2119, March 1997. 310 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 311 10646", STD 63, RFC 3629, November 2003. 313 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 314 Resource Identifier (URI): Generic Syntax", STD 66, 315 RFC 3986, January 2005. 317 [RFC3987] Duerst, M. and M. Suignard, "Internationalized Resource 318 Identifiers (IRIs)", RFC 3987, January 2005. 320 [RFC5395] Eastlake, D., "Domain Name System (DNS) IANA 321 Considerations", RFC 5395, November 2008. 323 [RFC5890] Klensin, J., "Internationalized Domain Names for 324 Applications (IDNA): Definitions and Document Framework", 325 RFC 5890, August 2010. 327 10.2. Informative References 329 [I-D.faltstrom-uri] 330 Faltstrom, P. and O. Kolkman, "The Uniform Resource 331 Identifier (URI) DNS Resource Record", 332 draft-faltstrom-uri-06 (work in progress), October 2010. 334 Author's Address 336 Ted Hardie 337 Google 338 1600 Amphitheatre Parkway 339 Mountain View, CA 94043 340 US 342 Email: hardie@google.com