idnits 2.17.1 draft-ietf-weirds-redirects-02.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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) == There are 5 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 15, 2013) is 3937 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-18) exists of draft-ietf-weirds-rdap-query-02 == Outdated reference: A later version (-15) exists of draft-ietf-weirds-using-http-01 -- Obsolete informational reference (is this intentional?): RFC 2616 (Obsoleted by RFC 7230, RFC 7231, RFC 7232, RFC 7233, RFC 7234, RFC 7235) Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C. Martinez, Ed. 3 Internet-Draft A. Servin, Ed. 4 Intended status: Informational LACNIC 5 Expires: January 16, 2014 L. Zhou, Ed. 6 CNNIC 7 D. Gomez 8 G. Rada 9 LACNIC 10 July 15, 2013 12 Redirection Service for Registration Data Access Protocol 13 draft-ietf-weirds-redirects-02 15 Abstract 17 The traditional WHOIS protocol has several important shortcomings, 18 and over the past few years several approaches to a better 19 Registration Data Access Protocol (RDAP) have been discussed and 20 proposed. 22 It is worth noting that the term WHOIS is sometimes used 23 interchangeably to mean either (a) the registration data itself or 24 (b) the protocol used to access registration data 26 Among these shortcomings, different registries operate different 27 WHOIS services. For users this means that several WHOIS queries to 28 different registries may be necessary in order to obtain data for a 29 given resource. 31 This document describes a redirection service for RDAP queries. This 32 service allows clients to query a single RDAP service and expect 33 either an authoritative answer or a redirection hint pointing to 34 another, possibly authoritative, RDAP server. 36 The solution implemented proposed here applies to Regional Internet 37 Registries(RIRs) and Domain Name Registries(DNRs). 39 Status of this Memo 41 This Internet-Draft is submitted in full conformance with the 42 provisions of BCP 78 and BCP 79. 44 Internet-Drafts are working documents of the Internet Engineering 45 Task Force (IETF). Note that other groups may also distribute 46 working documents as Internet-Drafts. The list of current Internet- 47 Drafts is at http://datatracker.ietf.org/drafts/current/. 49 Internet-Drafts are draft documents valid for a maximum of six months 50 and may be updated, replaced, or obsoleted by other documents at any 51 time. It is inappropriate to use Internet-Drafts as reference 52 material or to cite them other than as "work in progress." 54 This Internet-Draft will expire on January 16, 2014. 56 Copyright Notice 58 Copyright (c) 2013 IETF Trust and the persons identified as the 59 document authors. All rights reserved. 61 This document is subject to BCP 78 and the IETF Trust's Legal 62 Provisions Relating to IETF Documents 63 (http://trustee.ietf.org/license-info) in effect on the date of 64 publication of this document. Please review these documents 65 carefully, as they describe your rights and restrictions with respect 66 to this document. Code Components extracted from this document must 67 include Simplified BSD License text as described in Section 4.e of 68 the Trust Legal Provisions and are provided without warranty as 69 described in the Simplified BSD License. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 75 2. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . . 4 76 2.1. The REST Approach to Web Services . . . . . . . . . . . . . 4 77 2.2. Query Redirection for RDAP Queries . . . . . . . . . . . . 4 78 2.3. A Joint RDAP Tree through HTTP Redirection . . . . . . . . 5 79 2.4. The Redirection Table. The Bootstrap Problem. . . . . . . . 7 80 2.5. Loops in Redirection . . . . . . . . . . . . . . . . . . . 8 81 3. Service Discovery . . . . . . . . . . . . . . . . . . . . . . . 8 82 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8 83 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8 85 5.2. Informative References . . . . . . . . . . . . . . . . . . 8 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 88 1. Introduction 90 A user interested in obtaining registration information for a given 91 number or domain resource normally uses the WHOIS service provided by 92 the RIRs and DNRs. 94 In order to avoid having to query several databases until obtaining 95 an answer, some approaches have been discussed and implemented in the 96 past, most notably the Joint WHOIS [lacnic-joint-whois] initiative. 97 However, among other shortcomings, Joint WHOIS is implemented using 98 proxies and server-side referrals. 100 The RDAP protocol (draft-ietf-weirds-using-http 101 [I-D.ietf-weirds-using-http]) makes it comparatively easy to 102 implement client-side redirects based on normal HTTP 1.1 semantics 103 and behavior. 105 The goal of this I-D is to describe an implementation of an RDAP 106 redirection service and to encourage discussion on the topic of 107 redirects in this problem domain. 109 1.1. Requirements Language 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 115 2. Proposed Approach 117 2.1. The REST Approach to Web Services 119 While a full introduction to REST and RESTful 120 interfaces is out of the scope of this document it is important to 121 note that these interfaces employ the verbs defined in HTTP (GET, 122 POST, HEAD, DELETE) and HTTP response codes to signal the semantics 123 and outcomes of an operation. 125 As WHOIS is a read-only service only the GET and HEAD verbS are 126 usually implemented. 128 HTTP status codes provide signaling for errors and other conditions, 129 including the concept of "client-side redirection" as outlined below. 131 2.2. Query Redirection for RDAP Queries 133 Each RDAP server should answer directly only those queries for which 134 it is authoritative. In this case, being authoritative equals 135 "having direct access to a given registry database". 137 For all other queries, a RDAP server could provide a 301 MOVED 138 PERMANENTLY redirect answer pointing to an URL hosted on a different 139 RDAP server. 141 As all requests are to be performed employing HTTP GETs, a user agent 142 can transparently follow the HTTP 30x redirection hints ([RFC2616]) 143 until obtaining a non-error answer (HTTP 20x) or an unrecoverable 144 error condition (HTTP 40x or 50x). 146 2.3. A Joint RDAP Tree through HTTP Redirection 148 When a registry does not have the authoritative answers to the user 149 agent's query, user agent's query can be redirected to a redirection- 150 only RDAP server which could provide the authoritative RDAP server 151 address. 153 The redirect server is responsible for tracking and returning the 154 authoritative sources for IP, AS, domain name, name server or entity 155 queries. All the query format are described in the 156 draft-ietf-weirds-rdap-query [I-D.ietf-weirds-rdap-query]. We will 157 call this redirect server "the redirector". 159 The redirect server needs access to data sources that, given a 160 queried resource, provide a pointer to the authoritative RDAP server. 161 For lack of a better name, we will call this data source the 162 "redirection table". 164 Assuming the redirector has access to a redirection table, the 165 following pseudo code describes its expected behaviour: 167 while(true) { 168 query = read_query_from_network() 169 auth_rdap_svr = redirect_table_lookup (query.resource) 170 if (auth_rdap_svr != null) { 171 write_http_301(auth_rdap_svr) 172 } else { 173 write_http_404("resource not in redirect table") 174 } 175 } 177 Redirector state machine 179 Figure 1 181 Figure 2 shows the general scheme of a single RDAP Redirection 182 Service serving three different RIRs standalone RDAPs while providing 183 a seamless query interface to clients. 185 ...................... 186 | | 187 | RDAP REDIRECTOR | 188 | | 189 `....................' 190 _, | ._ 191 ,,' | `. 192 ,-' | `-. 193 ,-' | `._ 194 _,-' | `. 195 .' | `-. 196 +-----------Y +-------------. ,------------b 197 | LACNIC | | RIPE-NCC | | ARIN | 198 | | | | | | 199 '`''''''''''' '`'''''''''''' '`'''''''''''' 201 RDAP Joint WHOIS Tree. 203 Figure 2 205 Figure 3 shows how HTTP 301 redirection hints guide a client looking 206 for registration data for the IPv4 address 23.1.1.1 (administered by 207 ARIN) from LACNIC's WHOIS, the redirector and finally ARIN's WHOIS. 209 LACNIC REDIRECTOR ARIN 210 RDAP RDAP RDAP 211 . . . 212 Q: 23.1.1.1? ----> | | | 213 | | | 214 <-- HTTP 301 --- | | | 215 ('Try Redirector') | | | 216 | | | 217 | | | 218 Q: 23.1.1.1? -----------------> | | 219 | | 220 <---------- HTTP 301 --------| | 221 ('Try ARIN RDAP') | | 222 | | 223 | 224 Q: 23.1.1.1? -------------------------------> | 225 | 226 <---------- HTTP 200 --------------------- | 227 (WHOIS response is returned) | 228 | 229 | 230 . 232 Querying WHOIS data for 23.1.1.1 234 Figure 3 236 2.4. The Redirection Table. The Bootstrap Problem. 238 For the redirection table lookup function, the redirector can either 239 have pre-populated local table or have access to a service provided 240 by some form of directory service. How either this local table or 241 directory service is fed is known as the "bootstrapping problem". 243 The bootstrapping problem was initially declared out of scope of the 244 WEIRDS WG. However, the problem has been discussed and several 245 proposals have been presented (**insert references to Marc's docs**). 246 Some of these solutions contemplate using the DNS tree as directory 247 service while others, for the specific case of number resources, 248 contemplate using IANA's XML registry files as seed files for a local 249 redirection table. 251 The bootstrapping problem needs to be addressed differently for names 252 and numbers. Not only the coount of potential authoritative RDAP 253 servers for names (huge) is vastly different from the count for 254 numbers (currently 5), but also the relationships between the RIRs 255 and name registries and registrars are very different. 257 For the number resources case, parsing IANA's XML registries for 258 IPv4, IPv6 and Autonomous System Numbers (**insert refs**) allows a 259 simple way for building a redirection table. 261 2.5. Loops in Redirection 263 When redirection is used there is always the risk that bogus user- 264 agents and applications or malicious user can create loops that in 265 turn may become Denial of Service attacks. 267 Commonly used user agents (including HTTP libraries) have loop 268 detection features that are deemed sufficient for breaking loops in 269 RDAP. 271 3. Service Discovery 273 TBD 275 4. Security Considerations 277 While security practices are outside the scope of this document, the 278 authors believe it is important to identify such problematic use 279 cases to any DNR or RIR that may implement the redirection WHOIS 280 service. 282 5. References 284 5.1. Normative References 286 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 287 Requirement Levels", BCP 14, RFC 2119, March 1997. 289 5.2. Informative References 291 [I-D.ietf-weirds-rdap-query] 292 Newton, A. and S. Hollenbeck, "Registration Data Access 293 Protocol Query Format", draft-ietf-weirds-rdap-query-02 294 (work in progress), December 2012. 296 [I-D.ietf-weirds-using-http] 297 Newton, A., Ellacott, B., and N. Kong, "Using the 298 Registration Data Access Protocol (RDAP) with HTTP", 299 draft-ietf-weirds-using-http-01 (work in progress), 300 December 2012. 302 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 303 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 304 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 306 [lacnic-joint-whois] 307 LACNIC, "Joint WHOIS", 2005, . 311 Authors' Addresses 313 Carlos M. Martinez (editor) 314 LACNIC 315 Rambla Mexico 6125 316 Montevideo, 11400 317 Uruguay 319 Phone: +598-2604-2222 320 Email: carlos@lacnic.net 322 Arturo L. Servin (editor) 323 LACNIC 324 Rambla Mexico 6125 325 Montevideo, 11400 326 Uruguay 328 Phone: +598-2604-2222 329 Email: aservin@lacnic.net 331 Linlin Zhou (editor) 332 CNNIC 333 No. 4, South 4th Steet, Zhongguancun 334 Beijing, 100190 335 China 337 Phone: +8610-5881-2677 338 Email: zhoulinlin@cnnic.cn 339 Dario Gomez 340 LACNIC 341 Rambla Mexico 6125 342 Montevideo, 11400 343 Uruguay 345 Phone: +598-2604-2222 346 Email: dario@lacnic.net 348 Gerardo Rada 349 LACNIC 350 Rambla Mexico 6125 351 Montevideo, 11400 352 Uruguay 354 Phone: +598-2604-2222 355 Email: gerardo@lacnic.net