idnits 2.17.1 draft-ietf-weirds-redirects-01.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 (Feb 2013) is 4088 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 (~~), 4 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: August 5, 2013 L. Zhou, Ed. 6 CNNIC 7 D. Gomez 8 G. Rada 9 LACNIC 10 Feb 2013 12 Redirection Service for Registration Data Access Protocol 13 draft-ietf-weirds-redirects-01 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 Among these shortcomings, different registries operate different 23 WHOIS services. For users this implies that several WHOIS queries to 24 different registries may be necessary in order to obtain data for a 25 given resource. 27 This document describes a redirection service for RESTful WHOIS 28 queries. This service allows users to query a single WHOIS service 29 and be redirected to the authoritative registry. 31 The solution implemented proposed here applies to Regional Internet 32 Registries(RIRs) and Domain Name Registries(DNRs). 34 Status of this Memo 36 This Internet-Draft is submitted in full conformance with the 37 provisions of BCP 78 and BCP 79. 39 Internet-Drafts are working documents of the Internet Engineering 40 Task Force (IETF). Note that other groups may also distribute 41 working documents as Internet-Drafts. The list of current Internet- 42 Drafts is at http://datatracker.ietf.org/drafts/current/. 44 Internet-Drafts are draft documents valid for a maximum of six months 45 and may be updated, replaced, or obsoleted by other documents at any 46 time. It is inappropriate to use Internet-Drafts as reference 47 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on August 5, 2013. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 69 2. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 4 70 2.1. The REST Approach to Web Services . . . . . . . . . . . . 4 71 2.2. Query Redirection for RESTful WHOIS Queries . . . . . . . 4 72 2.3. A Single RESTful WHOIS trough HTTP Redirection . . . . . . 5 73 2.4. Loops in Redirection . . . . . . . . . . . . . . . . . . . 6 74 3. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 9 75 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 76 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 77 5.1. Normative References . . . . . . . . . . . . . . . . . . . 10 78 5.2. Informative References . . . . . . . . . . . . . . . . . . 10 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 81 1. Introduction 83 A user interested in obtaining registration information for a given 84 number or domain resource normally uses the WHOIS service provided by 85 the RIRs and DNRs. 87 In order to avoid having to query several databases until obtaining 88 an answer, some approaches have been discussed and implemented in the 89 past, most notably the Joint WHOIS [lacnic-joint-whois] initiative. 90 However, among other shortcomings, Joint WHOIS is implemented using 91 proxies and server-side referrals. 93 The RESTful approach to WHOIS services (draft-ietf-weirds-using-http 94 [I-D.ietf-weirds-using-http]) makes it comparatively easy to 95 implement client-side redirects based on normal HTTP 1.1 semantics 96 and behavior. 98 The goal of this I-D is to describe a RESTful WHOIS redirection 99 service and to encourage discussion on the topic of redirects in this 100 problem domain. 102 1.1. Requirements Language 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 2. Proposed Approach 110 2.1. The REST Approach to Web Services 112 While a full introduction to REST and RESTful 113 interfaces is out of the scope of this document it is important to 114 note that these interfaces employ the verbs defined in HTTP (GET, 115 POST, HEAD, DELETE) and HTTP response codes to signal the semantics 116 and outcomes of an operation. 118 As WHOIS is a read-only service only the GET verb is implemented. 120 HTTP status codes provide signaling for errors and other conditions, 121 including the concept of "client-side redirection" as outlined below. 123 2.2. Query Redirection for RESTful WHOIS Queries 125 Each RESTful WHOIS server should answer directly only those queries 126 for which it is authoritative. In this case, being authoritative 127 equals "having direct access to a given registry database". 129 For all other queries, a RESTful WHOIS server could provide a 301 130 MOVED PERMANENTLY redirect answer pointing to an URL hosted on a 131 different RESTful WHOIS server. 133 As all requests are to be performed employing HTTP GETs, a user agent 134 can transparently follow the HTTP 30x redirection hints ([RFC2616]) 135 until obtaining a non-error answer (HTTP 20x) or an unrecoverable 136 error condition (HTTP 40x or 50x). 138 2.3. A Single RESTful WHOIS trough HTTP Redirection 140 When a registry does not have the authoritative answers to the user 141 agent's query, user agent's query will be redirected to a 142 redirection-only RESTful WHOIS server which could provide the 143 authoritative WHOIS server address. 145 The redirect server is responsible for tracking and returning the 146 authoritative sources for IP, AS, domain name, name server or entity 147 queries. All the query format are described in the 148 draft-ietf-weirds-rdap-query [I-D.ietf-weirds-rdap-query] Until now, 149 there are some alternative solutions for the bootstrapping problem of 150 redirect server, such as using DNS SRV or NAPTR records. But this 151 problem is out of scope of this document and will be discussed 152 further in the following drafts in WEIRDS working group. 154 Figure 1 shows the general scheme of a single RESTWhois Redirection 155 Service serving three different RIRs standalone RESTWhois while 156 providing a seamless query interface to clients. 158 ...................... 159 | | 160 | WHOIS REDIRECTOR | 161 | | 162 `....................' 163 _, | ._ 164 ,,' | `. 165 ,-' | `-. 166 ,-' | `._ 167 _,-' | `. 168 .' | `-. 169 +-----------Y +-------------. ,------------b 170 | LACNIC | | RIPE-NCC | | ARIN | 171 | | | | | | 172 '`''''''''''' '`'''''''''''' '`'''''''''''' 174 RESTful Joint WHOIS Tree. 176 Figure 1 178 Figure 2 shows how HTTP 301 redirection hints guide a client looking 179 for registration data for the IPv4 address 23.1.1.1 (administered by 180 ARIN) from LACNIC's WHOIS, the redirector and finally ARIN's WHOIS. 182 LACNIC REDIRECTOR ARIN 183 WHOIS WHOIS WHOIS 184 . . . 185 Q: 23.1.1.1? ----> | | | 186 | | | 187 <-- HTTP 301 --- | | | 188 ('Try Redirector') | | | 189 | | | 190 | | | 191 Q: 23.1.1.1? -----------------> | | 192 | | 193 <---------- HTTP 301 --------| | 194 ('Try ARIN WHOIS') | | 195 | | 196 | 197 Q: 23.1.1.1? -------------------------------> | 198 | 199 <---------- HTTP 200 --------------------- | 200 (WHOIS response is returned) | 201 | 202 | 203 . 205 Querying WHOIS data for 23.1.1.1 207 Figure 2 209 2.4. Loops in Redirection 211 When redirection is used there is always the risk that bogus user- 212 agents and applications or malicious user can create loops that in 213 turn may become Denial of Service attacks. 215 To minimize the risk of loops created by bogus applications and user- 216 agents operators MAY use the mechanism shown in Section 3.1. 217 However, this mechanism could be forged and bypassed by malicious 218 users possibly creating a Denial of Service attack against the 219 operator. To avoid completely the risk of DoS operators should use 220 other methods such as rate-limit and authentication that are outside 221 the scope of this document. 223 One of the challenges by using redirection is loop avoidance. Even 224 though recommendation from REFERENCE** indicates that user-agents 225 should have a mechanism to break loops, due to sometimes not 226 carefully coded user-agents and other applications or due to 227 malicious users' activities loops that could end up in a Denial of 228 Service for the RESTful WHOIS operator. 230 A simple scenario that creates a loop is shown in Figure 3. A user 231 request (1) an object from Operator 1; Operator 1 do not have the 232 object but it has a pointer that Operator 2 has it, so it redirects 233 (2) the user to Operator 2; user request Object X to Operator 2 (3); 234 Operator 2 does not have the object either object but it has a 235 pointer that Operator 1 has it, so it redirects (4) the user to 236 Operator 1; it creates a loop (5). 238 +--------------+ +--------------+ 239 | | | | 240 | Operator A | | Operator B | 241 | | | | 242 +---^-----+----+ +----^----.----+ 243 1) | | 2) 3) | | 4) Redirect 244 Request | | Redirect Request | | to 245 Object X | | to Object X | | Operator A 246 | | Operator B | | 247 | |____________ _______________| | 248 |_______________ | | _________________| 249 | | | | 250 +--------------+ 251 | | 5) Loop 252 | User | 253 | | 254 +--------------+ 256 A simple loop 258 Figure 3 260 The loop described could be avoided by simple forbidding redirecting 261 a response when the query has been originated by a redirect. However 262 this solution only allows one redirection. A less restrictive 263 approach forbidding redirection to only when the destination is the 264 same than the originator for the redirection does not work either as 265 shown in Figure 4. 267 +--------------+ +--------------+ 268 | | | | 269 | Operator A | | Operator B | 270 | | | | 271 +---^-----+----+ +----^----+----+ 272 1) | | 2) 3) | | 4)Redirect 273 Request | | Redirect Request | | to 274 Object X | | to Object X | | Operator C 275 | | Operator B | | 276 | |____________ _____________| | 277 |_______________ | | _______________| 278 | | | | 279 +---\/------\/-+ 280 7) Loop | | 281 | User | 282 | | 283 +---^-----+----+ 284 6) Redirect | | 5) 285 to Operator A | | Request 286 | | Object X 287 +--------\/----+ 288 | | 289 | Operator C | 290 | | 291 +--------------+ 293 A more complex loop. 295 Figure 4 297 In the scenario depicted in Figure 4 the user request object X from 298 Operator A which redirects him/her to Operator B which in turn 299 redirects the user to Operator C. Operator C then redirects the user 300 back to Operator A again creating a loop. 302 To avoid loops created by not well-programmed user-agents or 303 applications when redirecting operators MAY append or modify a 304 special URI indicating that a redirection and how many times it has 305 been done. The format of the URI is described as follows. 307 When a RESTful WHOIS operator redirects a user to retrieve an object 308 from another operator, the operator making the redirection operator 309 MAY append or modify a special URI. 311 When using an URI to indicate redirection, the URI MUST have the 312 following structure: 314 /redirect/[step] 315 Where [step] is a consecutive counter that MUST be increased by every 316 operator when the URI is encountered in a query object. 318 When an operator is redirecting a query for the first time it MAY 319 append the redirection URI to the original URL. If the redirection 320 URI is used, it MUST use the format previously described and it MUST 321 set "step" equal to 1. For example, the URL 322 "http://whois.lacnic.net/restfulwhois/ip/200.7.84.0/24" would be 323 replaced by 325 "http://whois.example.com/restfulwhois/ip/200.7.84.0/24/redirect/1" 327 If an operator receives a request with the redirect URI it first 328 SHOULD check if "step" is shorter that the defined threshold. If it 329 does the operator SHOULD strip it and process the query. If the 330 query requires further redirection the operator MAY use the 331 redirection URI and it MUST increase "step" in one. 333 Operators that support the redirect URI MUST never create a new 334 redirect that contain a step value greater that their locally set 335 threshold. However if the operator has an authoritative response to 336 the agent it MUST respond regardless to the threshold value. 338 3. Service Discovery 340 TBD 342 4. Security Considerations 344 Firstly, redirect server settings cannot be modified by someone other 345 than the user validated by the redirection server. 347 Secondly, insure the redirection URL data must not be able to modify 348 URL in data transmission process. Such as 349 http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1 cannot 350 be modified to 351 http://www.labs.somenic.net/restwhois/rwhois_redir/ip/23.1.1.1. 353 While security practices are outside the scope of this document, the 354 authors believe it is important to identify such problematic use 355 cases to any DNR or RIR that may implement the redirection WHOIS 356 service. 358 5. References 360 5.1. Normative References 362 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 363 Requirement Levels", BCP 14, RFC 2119, March 1997. 365 5.2. Informative References 367 [I-D.ietf-weirds-rdap-query] 368 Newton, A. and S. Hollenbeck, "Registration Data Access 369 Protocol Query Format", draft-ietf-weirds-rdap-query-02 370 (work in progress), December 2012. 372 [I-D.ietf-weirds-using-http] 373 Newton, A., Ellacott, B., and N. Kong, "Using the 374 Registration Data Access Protocol (RDAP) with HTTP", 375 draft-ietf-weirds-using-http-01 (work in progress), 376 December 2012. 378 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 379 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 380 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 382 [lacnic-joint-whois] 383 LACNIC, "Joint WHOIS", 2005, . 387 Authors' Addresses 389 Carlos M. Martinez (editor) 390 LACNIC 391 Rambla Mexico 6125 392 Montevideo, 11400 393 Uruguay 395 Phone: +598-2604-2222 396 Email: carlos@lacnic.net 397 Arturo L. Servin (editor) 398 LACNIC 399 Rambla Mexico 6125 400 Montevideo, 11400 401 Uruguay 403 Phone: +598-2604-2222 404 Email: aservin@lacnic.net 406 Linlin Zhou (editor) 407 CNNIC 408 No. 4, South 4th Steet, Zhongguancun 409 Beijing, 100190 410 China 412 Phone: +8610-5881-2677 413 Email: zhoulinlin@cnnic.cn 415 Dario Gomez 416 LACNIC 417 Rambla Mexico 6125 418 Montevideo, 11400 419 Uruguay 421 Phone: +598-2604-2222 422 Email: dario@lacnic.net 424 Gerardo Rada 425 LACNIC 426 Rambla Mexico 6125 427 Montevideo, 11400 428 Uruguay 430 Phone: +598-2604-2222 431 Email: gerardo@lacnic.net