idnits 2.17.1 draft-ietf-weirds-redirects-04.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 date (July 2014) is 3572 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-weirds-bootstrap' is defined on line 290, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-weirds-using-http' is defined on line 300, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-weirds-bootstrap-03 == 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 (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force C.M. Martinez, Ed. 3 Internet-Draft LACNIC 4 Intended status: Informational L. Zhou, Ed. 5 Expires: December 31, 2014 CNNIC 6 G. Rada 7 LACNIC 8 July 2014 10 Redirection Service for Registration Data Access Protocol 11 draft-ietf-weirds-redirects-04 13 Abstract 15 The traditional WHOIS protocol has several important shortcomings, 16 and over the past few years several approaches to a better 17 Registration Data Access Protocol (RDAP) have been discussed and 18 proposed. 20 It is worth noting that the term WHOIS is sometimes used 21 interchangeably to mean either (a) the registration data itself or 22 (b) the protocol used to access registration data 24 Among these shortcomings, different registries operate different 25 WHOIS services. For users this means that several WHOIS queries to 26 different registries may be necessary in order to obtain data for a 27 given resource. 29 This document describes a redirection service for RDAP queries. This 30 service allows clients to query a single RDAP service and expect 31 either an authoritative answer or a redirection hint pointing to 32 another, possibly authoritative, RDAP server. 34 The solution implemented proposed here applies to Regional Internet 35 Registries(RIRs) and Domain Name Registries(DNRs). 37 Status of this Memo 39 This Internet-Draft is submitted in full conformance with the 40 provisions of BCP 78 and BCP 79. 42 Internet-Drafts are working documents of the Internet Engineering 43 Task Force (IETF). Note that other groups may also distribute 44 working documents as Internet-Drafts. The list of current Internet- 45 Drafts is at http://datatracker.ietf.org/drafts/current/. 47 Internet-Drafts are draft documents valid for a maximum of six months 48 and may be updated, replaced, or obsoleted by other documents at any 49 time. It is inappropriate to use Internet-Drafts as reference 50 material or to cite them other than as "work in progress." 52 This Internet-Draft will expire on December 31, 2014. 54 Copyright Notice 56 Copyright (c) 2014 IETF Trust and the persons identified as the 57 document authors. All rights reserved. 59 This document is subject to BCP 78 and the IETF Trust's Legal 60 Provisions Relating to IETF Documents (http://trustee.ietf.org/ 61 license-info) in effect on the date of publication of this document. 62 Please review these documents carefully, as they describe your rights 63 and restrictions with respect to this document. Code Components 64 extracted from this document must include Simplified BSD License text 65 as described in Section 4.e of the Trust Legal Provisions and are 66 provided without warranty as described in the Simplified BSD License. 68 Table of Contents 70 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2 71 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 72 1.2. The REST Approach to Web Services . . . . . . . . . . . . 3 73 1.3. Request Redirection for RDAP Queries . . . . . . . . . . . 3 74 1.4. The Redirection Table. The Bootstrap Problem. . . . . . . 3 75 2. Architectural Use Cases of Redirects in RDAP . . . . . . . . . 3 76 2.1. A Joint RDAP Tree through HTTP Redirection . . . . . . . . 3 77 2.2. Helper Service for Constrained RDAP Clients . . . . . . . 5 78 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5 79 3.1. Loops in Redirection . . . . . . . . . . . . . . . . . . . 6 80 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 81 4.1. Normative References . . . . . . . . . . . . . . . . . . . 6 82 4.2. Informative References . . . . . . . . . . . . . . . . . . 6 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 85 1. Introduction 87 A user interested in obtaining registration information for a given 88 number or domain resource normally uses the WHOIS service provided by 89 the RIRs and DNRs. 91 In order to avoid having to query several databases until obtaining 92 an answer, some approaches have been discussed and implemented in the 93 past, most notably the Joint WHOIS [lacnic-joint-whois] initiative. 94 However, among other shortcomings, Joint WHOIS is implemented using 95 proxies and server-side referrals. 97 The RDAP protocol (draft-ietf-weirds-using-http [I-D.ietf-weirds- 98 using-http]) makes it comparatively easy to implement client-side 99 redirects based on normal HTTP 1.1 semantics and behavior. 101 The goal of this I-D is to describe an implementation of an RDAP 102 redirection service and to encourage discussion on the topic of 103 redirects in this problem domain. 105 1.1. Requirements Language 107 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 108 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 109 document are to be interpreted as described in RFC 2119 [RFC2119]. 111 1.2. The REST Approach to Web Services 113 While a full introduction to REST and RESTful interfaces is out of 114 the scope of this document it is important to note that these 115 interfaces employ the verbs defined in HTTP (GET, POST, HEAD, DELETE) 116 and HTTP response codes to signal the semantics and outcomes of an 117 operation. 119 As WHOIS is a read-only service only the GET and HEAD verbs are 120 usually implemented. 122 HTTP status codes provide signaling for errors and other conditions, 123 including the concept of "client-side redirection" as outlined below. 125 1.3. Request Redirection for RDAP Queries 127 Each RDAP server should answer directly only those queries for which 128 it is authoritative. In this case, being authoritative equals 129 "having direct access to a given registry database". 131 For all other queries, a RDAP server could provide a 301 MOVED 132 PERMANENTLY redirect answer pointing to an URL hosted on a different 133 RDAP server. 135 As all requests are to be performed employing HTTP GETs, a user agent 136 can transparently follow the HTTP 30x redirection hints ([RFC2616]) 137 until obtaining a non-error answer (HTTP 20x) or an unrecoverable 138 error condition (HTTP 40x or 50x). 140 1.4. The Redirection Table. The Bootstrap Problem. 142 For the redirection table lookup function, the redirector can either 143 have pre-populated local table or have access to a service provided 144 by some form of directory service. How either this local table or 145 directory service is fed is known as the "bootstrap problem". 147 RDAP Bootstrap is described in draft-ietf-weirds-bootstrap [I-D.ietf- 148 weirds-bootstrap] 150 2. Architectural Use Cases of Redirects in RDAP 152 2.1. A Joint RDAP Tree through HTTP Redirection 154 In an scenario where a client does not know which registry can 155 provide authoritative answers***TBC 156 When an RDAP server receives a query for which it does not have an 157 authoritative answer to provide, it MAY provide an HTTP 30x 158 redirection message pointing the client to a redirection-only RDAP 159 server, which in turn can provide further redirections guiding the 160 client to an authoritative server. 162 The redirect-only server is responsible for tracking and returning 163 the authoritative sources for IP, AS, domain name, name server or 164 entity queries. All the query format are described in the draft- 165 ietf-weirds-rdap-query [I-D.ietf-weirds-rdap-query]. We call this 166 redirect server "the redirector". 168 The redirect server needs access to data sources that, given a 169 queried resource, provide a pointer to the authoritative RDAP server. 170 For lack of a better name, we will call this data source the 171 "redirection table". 173 Assuming the redirector has access to a redirection table, the 174 following pseudo code describes its expected behaviour: 176 while(true) { 177 query = read_query_from_network() 178 auth_rdap_svr = redirect_table_lookup (query.resource) 179 if (auth_rdap_svr != null) { 180 write_http_301(auth_rdap_svr) 181 } else { 182 write_http_404("resource not in redirect table") 183 } 184 } 186 Redirector state machine 188 Figure 2 shows the general scheme of a single RDAP Redirection 189 Service serving three different RIRs standalone RDAPs while providing 190 a seamless query interface to clients. 192 ...................... 193 | | 194 | RDAP REDIRECTOR | 195 | | 196 `....................' 197 _, | ._ 198 ,,' | `. 199 ,-' | `-. 200 ,-' | `._ 201 _,-' | `. 202 .' | `-. 203 +-----------Y +-------------. ,------------b 204 | REGY1 | | REGY2 | | REGY3 | 205 | | | | | | 206 '`''''''''''' '`'''''''''''' '`'''''''''''' 208 RDAP Joint WHOIS Tree. 210 Figure 3 shows how HTTP 301 redirection hints guide a client looking 211 for registration data for the IPv4 address 23.1.1.1 (administered by 212 ARIN) from LACNIC's WHOIS, the redirector and finally ARIN's WHOIS. 214 LACNIC REDIRECTOR ARIN 215 RDAP RDAP RDAP 216 . . . 217 Q: 23.1.1.1? ----> | | | 218 | | | 219 <-- HTTP 301 --- | | | 220 ('Try Redirector') | | | 221 | | | 222 | | | 223 Q: 23.1.1.1? -----------------> | | 224 | | 225 <---------- HTTP 301 --------| | 226 ('Try ARIN RDAP') | | 227 | | 228 | 229 Q: 23.1.1.1? -------------------------------> | 230 | 231 <---------- HTTP 200 --------------------- | 232 (WHOIS response is returned) | 233 | 234 | 235 . 237 Querying WHOIS data for 23.1.1.1 239 2.2. Helper Service for Constrained RDAP Clients 241 It is expected that a significant portion of RDAP clients will be 242 written for and operate under constrained environments. For example, 243 simple Javascript clients written to run inside a web browser's 244 sandbox cannot perform arbitrary DNS queries nor open sockets, thus 245 limiting the ability of the client to actually access bootstrapping 246 data 248 TBD 250 3. Security Considerations 252 HTTP 30x-based redirection could offer an attack vector for a Man-in- 253 the-Middle type of attack, where the adversary modifies the 254 redirection URL offered by the server to the client. 256 For example, an attacker able to modify HTTP traffic could modify the 257 redirect URL from http://www.labs.lacnic.net/restwhois/rwhois_redir/ 258 ip/23.1.1.1 and change it into http://www.labs.somenic.net/restwhois/ 259 rwhois_redir/ip/23.1.1.1, where bogus information can be offered to 260 the client. 262 This particular type of attack can be prevented by usint HTTPS for 263 the RDAP connection. However, this certainly places a load burden 264 upon the servers. 266 While security practices are outside the scope of this document, the 267 authors believe it is important to identify such problematic use 268 cases to any DNR or RIR that may implement the redirection WHOIS 269 service. 271 3.1. Loops in Redirection 273 When redirection is used there is always the risk that bogus user- 274 agents and applications or malicious user can create loops that in 275 turn may become Denial of Service attacks. 277 Commonly used user agents (including HTTP libraries) have loop 278 detection features that are deemed sufficient for breaking loops in 279 RDAP. 281 4. References 283 4.1. Normative References 285 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 286 Requirement Levels", BCP 14, RFC 2119, March 1997. 288 4.2. Informative References 290 [I-D.ietf-weirds-bootstrap] 291 Blanchet, M., "Finding the Authoritative Registration Data 292 (RDAP) Service", Internet-Draft draft-ietf-weirds- 293 bootstrap-03, June 2014. 295 [I-D.ietf-weirds-rdap-query] 296 Newton, A. and S. Hollenbeck, "Registration Data Access 297 Protocol Query Format", Internet-Draft draft-ietf-weirds- 298 rdap-query-02, December 2012. 300 [I-D.ietf-weirds-using-http] 301 Newton, A., Ellacott, B. and N. Kong, "Using the 302 Registration Data Access Protocol (RDAP) with HTTP", 303 Internet-Draft draft-ietf-weirds-using-http-01, December 304 2012. 306 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 307 Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext 308 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 310 [lacnic-joint-whois] 311 LACNIC, "LACNIC Joint WHOIS Implementation", 2005, . 315 Authors' Addresses 317 Carlos M. Martinez, editor 318 LACNIC 319 Rambla Mexico 6125 320 Montevideo, 11400 321 Uruguay 323 Phone: +598-2604-2222 324 Email: carlos@lacnic.net 326 Linlin Zhou, editor 327 CNNIC 328 No. 4, South 4th Steet, Zhongguancun 329 Beijing, 100190 330 China 332 Phone: +8610-5881-2677 333 Email: zhoulinlin@cnnic.cn 335 Gerardo Rada 336 LACNIC 337 Rambla Mexico 6125 338 Montevideo, 11400 339 Uruguay 341 Phone: +598-2604-2222 342 Email: gerardo@lacnic.net