idnits 2.17.1 draft-ietf-weirds-redirects-03.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 (February 14, 2014) is 3722 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-weirds-using-http' is defined on line 303, but no explicit reference was found in the text == 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 (~~), 6 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 LACNIC 4 Intended status: Informational L. Zhou, Ed. 5 Expires: August 18, 2014 CNNIC 6 G. Rada 7 LACNIC 8 February 14, 2014 10 Redirection Service for Registration Data Access Protocol 11 draft-ietf-weirds-redirects-03 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 August 18, 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 61 (http://trustee.ietf.org/license-info) in effect on the date of 62 publication of this document. Please review these documents 63 carefully, as they describe your rights and restrictions with respect 64 to this document. Code Components extracted from this document must 65 include Simplified BSD License text as described in Section 4.e of 66 the Trust Legal Provisions and are provided without warranty as 67 described in the Simplified BSD License. 69 Table of Contents 71 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 72 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 73 2. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . . 4 74 2.1. The REST Approach to Web Services . . . . . . . . . . . . . 4 75 2.2. Query Redirection for RDAP Queries . . . . . . . . . . . . 4 76 2.3. A Joint RDAP Tree through HTTP Redirection . . . . . . . . 5 77 2.4. The Redirection Table. The Bootstrap Problem. . . . . . . . 7 78 2.5. Loops in Redirection . . . . . . . . . . . . . . . . . . . 8 79 2.6. Service Discovery . . . . . . . . . . . . . . . . . . . . . 8 80 2.7. Security Considerations . . . . . . . . . . . . . . . . . . 8 81 3. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.1. Normative References . . . . . . . . . . . . . . . . . . . 8 83 3.2. Informative References . . . . . . . . . . . . . . . . . . 8 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 86 1. Introduction 88 A user interested in obtaining registration information for a given 89 number or domain resource normally uses the WHOIS service provided by 90 the RIRs and DNRs. 92 In order to avoid having to query several databases until obtaining 93 an answer, some approaches have been discussed and implemented in the 94 past, most notably the Joint WHOIS [lacnic-joint-whois] initiative. 95 However, among other shortcomings, Joint WHOIS is implemented using 96 proxies and server-side referrals. 98 The RDAP protocol (draft-ietf-weirds-using-http [I-D.ietf-weirds- 99 using-http]) makes it comparatively easy to implement client-side 100 redirects based on normal HTTP 1.1 semantics and behavior. 102 The goal of this I-D is to describe an implementation of an RDAP 103 redirection service and to encourage discussion on the topic of 104 redirects in this problem domain. 106 1.1. Requirements Language 108 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 109 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 110 document are to be interpreted as described in RFC 2119 [RFC2119]. 112 2. Proposed Approach 114 2.1. The REST Approach to Web Services 116 While a full introduction to REST and RESTful interfaces is out of 117 the scope of this document it is important to note that these 118 interfaces employ the verbs defined in HTTP (GET, POST, HEAD, DELETE) 119 and HTTP response codes to signal the semantics and outcomes of an 120 operation. 122 As WHOIS is a read-only service only the GET and HEAD verbs are 123 usually implemented. 125 HTTP status codes provide signaling for errors and other conditions, 126 including the concept of "client-side redirection" as outlined below. 128 2.2. Query Redirection for RDAP Queries 130 Each RDAP server should answer directly only those queries for which 131 it is authoritative. In this case, being authoritative equals 132 "having direct access to a given registry database". 134 For all other queries, a RDAP server could provide a 301 MOVED 135 PERMANENTLY redirect answer pointing to an URL hosted on a different 136 RDAP server. 138 As all requests are to be performed employing HTTP GETs, a user agent 139 can transparently follow the HTTP 30x redirection hints ([RFC2616]) 140 until obtaining a non-error answer (HTTP 20x) or an unrecoverable 141 error condition (HTTP 40x or 50x). 143 2.3. A Joint RDAP Tree through HTTP Redirection 145 When a registry does not have the authoritative answers to the user 146 agent's query, user agent's query can be redirected to a redirection- 147 only RDAP server which could provide the authoritative RDAP server 148 address. 150 The redirect server is responsible for tracking and returning the 151 authoritative sources for IP, AS, domain name, name server or entity 152 queries. All the query format are described in the 153 draft-ietf-weirds-rdap-query [I-D.ietf-weirds-rdap-query]. We will 154 call this redirect server "the redirector". 156 The redirect server needs access to data sources that, given a 157 queried resource, provide a pointer to the authoritative RDAP server. 158 For lack of a better name, we will call this data source the 159 "redirection table". 161 Assuming the redirector has access to a redirection table, the 162 following pseudo code describes its expected behaviour: 164 while(true) { 165 query = read_query_from_network() 166 auth_rdap_svr = redirect_table_lookup (query.resource) 167 if (auth_rdap_svr != null) { 168 write_http_301(auth_rdap_svr) 169 } else { 170 write_http_404("resource not in redirect table") 171 } 172 } 174 Redirector state machine 176 Figure 1 178 Figure 2 shows the general scheme of a single RDAP Redirection 179 Service serving three different RIRs standalone RDAPs while providing 180 a seamless query interface to clients. 182 ...................... 183 | | 184 | RDAP REDIRECTOR | 185 | | 186 `....................' 187 _, | ._ 188 ,,' | `. 189 ,-' | `-. 190 ,-' | `._ 191 _,-' | `. 192 .' | `-. 193 +-----------Y +-------------. ,------------b 194 | LACNIC | | RIPE-NCC | | ARIN | 195 | | | | | | 196 '`''''''''''' '`'''''''''''' '`'''''''''''' 198 RDAP Joint WHOIS Tree. 200 Figure 2 202 Figure 3 shows how HTTP 301 redirection hints guide a client looking 203 for registration data for the IPv4 address 23.1.1.1 (administered by 204 ARIN) from LACNIC's WHOIS, the redirector and finally ARIN's WHOIS. 206 LACNIC REDIRECTOR ARIN 207 RDAP RDAP RDAP 208 . . . 209 Q: 23.1.1.1? ----> | | | 210 | | | 211 <-- HTTP 301 --- | | | 212 ('Try Redirector') | | | 213 | | | 214 | | | 215 Q: 23.1.1.1? -----------------> | | 216 | | 217 <---------- HTTP 301 --------| | 218 ('Try ARIN RDAP') | | 219 | | 220 | 221 Q: 23.1.1.1? -------------------------------> | 222 | 223 <---------- HTTP 200 --------------------- | 224 (WHOIS response is returned) | 225 | 226 | 227 . 229 Querying WHOIS data for 23.1.1.1 231 Figure 3 233 2.4. The Redirection Table. The Bootstrap Problem. 235 For the redirection table lookup function, the redirector can either 236 have pre-populated local table or have access to a service provided 237 by some form of directory service. How either this local table or 238 directory service is fed is known as the "bootstrapping problem". 240 The bootstrapping problem was initially declared out of scope of the 241 WEIRDS WG. However, the problem has been discussed and several 242 proposals have been presented (**insert references to Marc's docs**). 243 Some of these solutions contemplate using the DNS tree as directory 244 service while others, for the specific case of number resources, 245 contemplate using IANA's XML registry files as seed files for a local 246 redirection table. 248 The bootstrapping problem needs to be addressed differently for names 249 and numbers as the coount of potential authoritative RDAP servers for 250 names (huge) is vastly different from the count for numbers 251 (currently 5). 253 2.5. Loops in Redirection 255 When redirection is used there is always the risk that bogus user- 256 agents and applications or malicious user can create loops that in 257 turn may become Denial of Service attacks. 259 Commonly used user agents (including HTTP libraries) have loop 260 detection features that are deemed sufficient for breaking loops in 261 RDAP. 263 2.6. Service Discovery 265 TBD 267 2.7. Security Considerations 269 HTTP 30x-based redirection could offer an attack vector for a Man-in- 270 the-Middle type of attack, where the adversary modifies the 271 redirection URL offered by the server to the client. 273 For example, an attacker able to modify HTTP traffic could modify the 274 redirect URL from 275 http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1 and 276 change it into 277 http://www.labs.somenic.net/restwhois/rwhois_redir/ip/23.1.1.1, where 278 bogus information can be offered to the client. 280 This particular type of attack can be prevented by usint HTTPS for 281 the RDAP connection. However, this certainly places a load burden 282 upon the servers. 284 While security practices are outside the scope of this document, the 285 authors believe it is important to identify such problematic use 286 cases to any DNR or RIR that may implement the redirection WHOIS 287 service. 289 3. References 291 3.1. Normative References 293 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 294 Requirement Levels", BCP 14, RFC 2119, March 1997. 296 3.2. Informative References 298 [I-D.ietf-weirds-rdap-query] 299 Newton, A. and S. Hollenbeck, "Registration Data Access 300 Protocol Query Format", draft-ietf-weirds-rdap-query-02 301 (work in progress), December 2012. 303 [I-D.ietf-weirds-using-http] 304 Newton, A., Ellacott, B., and N. Kong, "Using the 305 Registration Data Access Protocol (RDAP) with HTTP", 306 draft-ietf-weirds-using-http-01 (work in progress), 307 December 2012. 309 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 310 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 311 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 313 [lacnic-joint-whois] 314 LACNIC, "Joint WHOIS", 2005, . 318 Authors' Addresses 320 Carlos M. Martinez (editor) 321 LACNIC 322 Rambla Mexico 6125 323 Montevideo, 11400 324 Uruguay 326 Phone: +598-2604-2222 327 Email: carlos@lacnic.net 329 Linlin Zhou (editor) 330 CNNIC 331 No. 4, South 4th Steet, Zhongguancun 332 Beijing, 100190 333 China 335 Phone: +8610-5881-2677 336 Email: zhoulinlin@cnnic.cn 337 Gerardo Rada 338 LACNIC 339 Rambla Mexico 6125 340 Montevideo, 11400 341 Uruguay 343 Phone: +598-2604-2222 344 Email: gerardo@lacnic.net