idnits 2.17.1 draft-lacnic-weirds-restwhois-redirects-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 : ---------------------------------------------------------------------------- ** 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 7 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 7 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with non-RFC3849-compliant IPv6 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 (May 17, 2012) is 4359 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-02) exists of draft-newton-et-al-weirds-rir-query-00 -- 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 D. Gomez 5 Expires: November 18, 2012 G. Rada 6 LACNIC 7 May 17, 2012 9 LACNIC's Redirection Service for Number Resource RESTful WHOIS Queries 10 draft-lacnic-weirds-restwhois-redirects-00 12 Abstract 14 The traditional WHOIS protocol has several important shortcomings, 15 and over the past few years several approaches to a better WHOIS have 16 been discussed and proposed. 18 Among these shortcomings, different registries operate different 19 WHOIS services. For users this implies that several WHOIS queries to 20 different registries may be necessary in order to obtain data for a 21 given resource. 23 This document describes a proof-of-concept redirection service for 24 RESTful WHOIS queries as implemented by LACNIC. This service allows 25 users to query a single WHOIS service and be redirected to the 26 authoritative registry. 28 The main goal of this document is to encourage discussion on the 29 topics of Joint WHOIS services and query redirection in a RESTful 30 WHOIS world. 32 The solution implemented by LACNIC proposed here applies to numbering 33 resources (IPv4, IPv6 and autonomous system numbers). 35 Status of this Memo 37 This Internet-Draft is submitted in full conformance with the 38 provisions of BCP 78 and BCP 79. 40 Internet-Drafts are working documents of the Internet Engineering 41 Task Force (IETF). Note that other groups may also distribute 42 working documents as Internet-Drafts. The list of current Internet- 43 Drafts is at http://datatracker.ietf.org/drafts/current/. 45 Internet-Drafts are draft documents valid for a maximum of six months 46 and may be updated, replaced, or obsoleted by other documents at any 47 time. It is inappropriate to use Internet-Drafts as reference 48 material or to cite them other than as "work in progress." 49 This Internet-Draft will expire on November 18, 2012. 51 Copyright Notice 53 Copyright (c) 2012 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents 58 (http://trustee.ietf.org/license-info) in effect on the date of 59 publication of this document. Please review these documents 60 carefully, as they describe your rights and restrictions with respect 61 to this document. Code Components extracted from this document must 62 include Simplified BSD License text as described in Section 4.e of 63 the Trust Legal Provisions and are provided without warranty as 64 described in the Simplified BSD License. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 70 2. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. The REST approach to web services . . . . . . . . . . . . 4 72 2.2. Query redirection for RESTful WHOIS queries . . . . . . . 5 73 2.3. A global Joint WHOIS trough HTTP redirection . . . . . . . 5 74 2.4. Loops in redirection . . . . . . . . . . . . . . . . . . . 9 75 3. LACNIC RESTful WHOIS redirector implementation . . . . . . . . 12 76 3.1. Accessing the redirector . . . . . . . . . . . . . . . . . 12 77 3.1.1. Redirection URI . . . . . . . . . . . . . . . . . . . 12 78 4. Security Considerations . . . . . . . . . . . . . . . . . . . 13 79 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.1. Normative References . . . . . . . . . . . . . . . . . . . 13 81 5.2. Informative References . . . . . . . . . . . . . . . . . . 13 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 84 1. Introduction 86 A user interested in obtaining registration information for a given 87 number resource normally uses the WHOIS service provided by the RIRs 88 (AfriNIC, APNIC, ARIN, LACNIC and RIPE-NCC). 90 In order avoid having to query several databases until obtaining an 91 answer some approaches have been discussed and implemented in the 92 past, most notably the Joint WHOIS [lacnic-joint-whois] initiative. 93 However, among other shortcomings, Joint WHOIS is implemented using 94 proxies and server-side referrals. 96 The RESTful approach to WHOIS services 97 (draft-newton-weirds-arin-whoisrws [I-D.newton-weirds-arin-whoisrws], 98 draft-newton-rir-query [I-D.newton-et-al-weirds-rir-query], 99 [draft-lacnic-restful-whois]) makes it comparatively easy to 100 implement client-side redirects based on normal HTTP 1.1 semantics 101 and behavior. 103 The goal of this I-D is to document LACNIC's current implementation 104 of a RESTful WHOIS redirection service and to encourage discussion on 105 the topic of redirects in this problem domain. 107 1.1. Requirements Language 109 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 110 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 111 document are to be interpreted as described in RFC 2119 [RFC2119]. 113 2. Proposed Approach 115 2.1. The REST approach to web services 117 While a full introduction to REST and RESTful 118 interfaces is out of the scope of this document it is important to 119 note that these interfaces employ the verbs defined in HTTP (GET, 120 POST, HEAD, DELETE) and HTTP response codes to signal the semantics 121 and outcomes of an operation. 123 As WHOIS is a read-only service only the GET verb is 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 RESTful WHOIS queries 130 Each RESTful WHOIS server should answer directly only those queries 131 for which it is authoritative. In this case, being authoritative 132 equals "having direct access to a given registry database". 134 For all other queries, a RESTful WHOIS server could provide a 301 135 MOVED PERMANENTLY Redirect answer pointing to an URL hosted on a 136 different RESTful WHOIS server. 138 Currently the format of the RESTful WHOIS URIs is different across 139 implementations ([I-D.newton-weirds-arin-whoisrws], RIPE RESTful 140 Interface [1], [draft-lacnic-restful-whois]), so the redirecting 141 server implemented by LACNIC currently maps the original query URI to 142 the URI format expected by the receiving server. 144 As all requests are to be performed employing HTTP GETs, a user agent 145 can transparently follow the HTTP 30x redirection hints ([RFC2616]) 146 until obtaining a non-error answer (HTTP 20x) ) or an unrecoverable 147 error condition (HTTP 40x or 50x). 149 If the work of WEIRDS progresses far enough so that an uniform URI 150 format is agreed upon, the need for server-side URI mappings may 151 become unnecessary. 153 LACNIC's current implementation splits the authoritative RESTful 154 WHOIS service from the redirection service. The redirection service 155 provides a "switching point" for the whole resource tree. No Inter- 156 RIR coordination, database replication nor RIR-side proxies are 157 needed. 159 2.3. A global Joint WHOIS trough HTTP redirection 161 A single redirection-only RESTful WHOIS server could provide a single 162 root to which all RIR RESTful WHOIS servers could point queries for 163 which they are not authoritative. 165 In LACNIC's implementation the redirect server's database was 166 initialized from IANA's registries for IPv4, IPv6 and AS numbers. 168 Implementation was very simple even when adding the server-side URI 169 mapping requirement outlined above. LACNIC's staff was able to 170 implement a proof of concept redirect-only server in about two days 171 of effort including importing IANA's IPv4 registry into a database 172 and implementing URI mapping for LACNIC, ARIN and RIPE's RESTful 173 WHOIS services. 175 Figure 1 shows the general scheme of a single WHOIS redirector 176 serving three different RIRs standalone WHOIS while providing a 177 seamless query interface to clients. 179 ...................... 180 | | 181 | WHOIS REDIRECTOR | 182 | | 183 `....................' 184 _, | ._ 185 ,,' | `. 186 ,-' | `-. 187 ,-' | `._ 188 _,-' | `. 189 .' | `-. 190 +-----------Y +-------------. ,------------b 191 | LACNIC | | RIPE-NCC | | ARIN | 192 | | | | | | 193 '`''''''''''' '`'''''''''''' '`'''''''''''' 195 RESTful Joint WHOIS Tree. 197 Figure 1 199 Figure 2 shows how HTTP 301 redirection hints guide a client looking 200 for registration data for the IPv4 address 23.1.1.1 (administered by 201 ARIN) from LACNIC's WHOIS, the redirector and finally ARIN's WHOIS. 203 LACNIC REDIRECTOR ARIN 204 WHOIS WHOIS WHOIS 205 . . . 206 Q: 23.1.1.1? ----> | | | 207 | | | 208 <-- HTTP 301 --- | | | 209 ('Try Redirector') | | | 210 | | | 211 | | | 212 Q: 23.1.1.1? -----------------> | | 213 | | 214 <---------- HTTP 301 --------| | 215 ('Try ARIN WHOIS') | | 216 | | 217 | 218 Q: 23.1.1.1? -------------------------------> | 219 | 220 <---------- HTTP 200 --------------------- | 221 (WHOIS response is returned) | 222 | 223 | 224 . 226 Querying WHOIS data for 23.1.1.1 228 Figure 2 230 Figure 3 shows the output of the well-known 'wget' tool where the 231 redirection hints (HTTP 301's) for the same query can be seen. 232 Figure 3 also shows how the URL mapping function operates, 233 transforming the LACNIC REST URI into an ARIN REST URI. 235 wget --output-document=- 236 http://restwhois.labs.lacnic.net/restfulwhois/ip/23.1.1.1 238 --2012-01-10 15:37:46-- 239 http://restwhois.labs.lacnic.net/restfulwhois/ip/23.1.1.1 241 Resolving restwhois.labs.lacnic.net (restwhois.labs.lacnic.net)... 242 200.7.84.21 244 Connecting to restwhois.labs.lacnic.net 245 (restwhois.labs.lacnic.net)|200.7.84.21|:80... connected. 246 HTTP request sent, awaiting response... 307 Temporary Redirect 248 Location: http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1 249 [following] 250 --2012-01-10 15:37:46-- 251 http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1 253 Resolving www.labs.lacnic.net (www.labs.lacnic.net)... 254 2001:13c7:7001:4000::10, 200.7.84.10 255 Connecting to www.labs.lacnic.net 256 (www.labs.lacnic.net)|2001:13c7:7001:4000::10|:80... connected. 257 HTTP request sent, awaiting response... 301 MOVED PERMANENTLY 259 Location: http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1/ 260 [following] 261 --2012-01-10 15:37:46-- 262 http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1/ 263 Connecting to www.labs.lacnic.net 264 (www.labs.lacnic.net)|2001:13c7:7001:4000::10|:80... connected. 265 HTTP request sent, awaiting response... 301 MOVED PERMANENTLY 267 Location: http://whois.arin.net/rest/ip/23.1.1.1 [following] 269 --2012-01-10 15:37:46-- http://whois.arin.net/rest/ip/23.1.1.1 271 Resolving whois.arin.net (whois.arin.net)... 2001:500:31::47, 272 2001:500:13::46, 2001:500:13::47, ... 273 Connecting to whois.arin.net (whois.arin.net)|2001:500:31::47|:80... 274 connected. 275 HTTP request sent, awaiting response... 200 OK 276 Length: 1038 (1.0K) [application/xml] 277 Saving to: `STDOUT' 279 --- output suppressed for brevity --- 281 Detailed 'wget' output for a RESTful WHOIS query for 23.1.1.1 282 Figure 3 284 2.4. Loops in redirection 286 When redirection is used there is always the risk that bogus user- 287 agents and applications or malicious user can create loops that in 288 turn may become Denial of Service attacks. 290 To minimize the risk of loops created by bogus applications and user- 291 agents operators MAY use the mechanism shown in Section 3.1. 292 However, this mechanism could be forged and bypassed by malicious 293 users possibly creating a Denial of Service attack against the 294 operator. To avoid completely the risk of DoS operators should use 295 other methods such as rate-limit and authentication that are outside 296 the scope of this document. 298 One of the challenges by using redirection is loop avoidance. Even 299 though recommendation from REFERENCE** indicates that user-agents 300 should have a mechanism to break loops, due to sometimes not 301 carefully coded user-agents and other applications or due to 302 malicious users' activities loops that could end up in a Denial of 303 Service for the RESTful WHOIS operator. 305 A simple scenario that creates a loop is shown in Figure 4. An user 306 request (1) an object from Operator 1; Operator 1 do not have the 307 object but it has a pointer that Operator 2 has it, so it redirects 308 (2) the user to Operator 2; user request Object X to Operator 2 (3); 309 Operator 2 does not have the object either object but it has a 310 pointer that Operator 1 has it, so it redirects (4) the user to 311 Operator 1; it creates a loop (5). 313 +--------------+ +--------------+ 314 | | | | 315 | Operator A | | Operator B | 316 | | | | 317 +---^-----+----+ +----^----.----+ 318 1) | | 2) 3) | | 4) Redirect 319 Request | | Redirect Request | | to 320 Object X | | to Object X | | Operator A 321 | | Operator B | | 322 | |____________ _______________| | 323 |_______________ | | _________________| 324 | | | | 325 +--------------+ 326 | | 5) Loop 327 | User | 328 | | 329 +--------------+ 331 A simple loop 333 Figure 4 335 The loop described could be avoided by simple forbidding to redirect 336 a response when the query has been originated by a redirect. However 337 this solution only allows one redirection. A less restrictive 338 approach forbidding redirection to only when the destination is the 339 same than the originator for the redirection does not work either as 340 shown in Figure 5. 342 +--------------+ +--------------+ 343 | | | | 344 | Operator A | | Operator B | 345 | | | | 346 +---^-----+----+ +----^----+----+ 347 1) | | 2) 3) | | 4)Redirect 348 Request | | Redirect Request | | to 349 Object X | | to Object X | | Operator C 350 | | Operator B | | 351 | |____________ _____________| | 352 |_______________ | | _______________| 353 | | | | 354 +---\/------\/-+ 355 7) Loop | | 356 | User | 357 | | 358 +---^-----+----+ 359 6) Redirect | | 5) 360 to Operator A | | Request 361 | | Object X 362 +--------\/----+ 363 | | 364 | Operator C | 365 | | 366 +--------------+ 368 A more complex loop. 370 Figure 5 372 In the scenario depicted in Figure 5 the user request object X from 373 Operator A which redirects him/her to Operator B which in turn 374 redirects the user to Operator C. Operator C then redirects the user 375 back to Operator A again creating a loop. 377 To avoid loops created by not well-programmed user-agents or 378 applications when redirecting operators MAY append or modify a 379 special URI indicating that a redirection and how many times it has 380 been done. The format of the URI is described in the next section. 382 In the scenario depicted in Figure 5 the user request object X from 383 Operator A which redirects him/her to Operator B which in turn 384 redirects the user to Operator C. Operator C then redirects the user 385 back to Operator A again creating a loop. 387 To avoid loops created by not well-programmed user-agents or 388 applications when redirecting operators MAY append or modify a 389 special URI indicating that a redirection and how many times it has 390 been done. The format of the URI is described in the next section. 392 3. LACNIC RESTful WHOIS redirector implementation 394 LACNIC's staff was able to implement a proof-of-concept WHOIS 395 redirect without committing to a large development effort (around 12 396 man-hours were consumed). 398 The redirector was implemented in the Python programming language and 399 employing the Django web framework library for handling HTTP requests 400 and responses. 402 The choice of technology was dictated more by the developers' 403 familiarity with it. No claim regarding performance or suitability 404 for a production service is made. 406 3.1. Accessing the redirector 408 Currently there are two ways for accessing the redirector: 410 o By querying LACNIC's RESTful WHOIS for a non-LACNIC resource: 412 wget --output-document=- 413 http://restwhois.labs.lacnic.net/restfulwhois/ip/23.1.1.1 415 o Directly at: 417 http://www.labs.lacnic.net/restwhois/rwhois_redir 419 The redirector currently supports queries for IPv4 address blocks 420 only, employing the REST URIs defined in [!REF:draft-lacnic- 421 restfulwhois]. 423 The current implementation will provide a redirection to an empty 424 answer in case the resources are not found in its registry. 426 LACNIC's current plans currently include extending the redirector so 427 queries for IPv6 blocks as well as autonomous system numbers are 428 supported. 430 3.1.1. Redirection URI 432 When a RESTful WHOIS operator redirects an user to retrieve an object 433 from another operator, the operator making the redirection operator 434 MAY append or modify a special URI. 436 When using an URI to indicate redirection, the URI MUST have the 437 following structure: 439 /redirect/[step] 441 Where [step] is a consecutive counter that MUST be increased by every 442 operator when the URI is encountered in a query object. 444 When an operator is redirecting a query for the first time it MAY 445 append the redirection URI to the original URL. If the redirection 446 URI is used, it MUST use the format previously described and it MUST 447 set "step" equal to 1. For example, the URL 448 "http://whois.lacnic.net/restfulwhois/ip/200.7.84.0/24" would be 449 replaced by 451 "http://whois.example.com/restfulwhois/ip/200.7.84.0/24/redirect/1" 453 If an operator receives a request with the redirect URI it first 454 SHOULD check if "step" is shorter that the defined threshold. If it 455 does the operator SHOULD strip it and process the query. If the 456 query requires further redirection the operator MAY use the 457 redirection URI and it MUST increase "step" in one. 459 Operators that support the redirect URI MUST never process redirects 460 that contain a step value greater that their locally set threshold. 462 4. Security Considerations 464 This document makes no explicit security considerations other than 465 those stated above. 467 5. References 469 5.1. Normative References 471 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 472 Requirement Levels", BCP 14, RFC 2119, March 1997. 474 [min_ref] authSurName, authInitials., "Minimal Reference", 2006. 476 5.2. Informative References 478 [I-D.newton-et-al-weirds-rir-query] 479 Newton, A., Ranjbar, K., and A. Servin, "A Uniform RESTful 480 URL Query Pattern for RIRs", 481 draft-newton-et-al-weirds-rir-query-00 (work in progress), 482 September 2011. 484 [I-D.newton-weirds-arin-whoisrws] 485 Newton, A., "ARIN's RESTful Web Service for Whois Data", 486 draft-newton-weirds-arin-whoisrws-00 (work in progress), 487 June 2011. 489 [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., 490 Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext 491 Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 493 [draft-lacnic-restful-whois] 494 LACNIC, "LACNIC's RESTful WHOIS Interface for Registry 495 Data", 2011, . 498 [lacnic-joint-whois] 499 LACNIC, "Joint WHOIS", 2005, . 503 URIs 505 [1] 508 Authors' Addresses 510 Carlos M. Martinez (editor) 511 LACNIC 512 Rambla Mexico 6125 513 Montevideo, 11400 514 Uruguay 516 Phone: +598-2604-2222 517 Email: carlos@lacnic.net 519 Arturo L. Servin (editor) 520 LACNIC 521 Rambla Mexico 6125 522 Montevideo, 11400 523 Uruguay 525 Phone: +598-2604-2222 526 Email: aservin@lacnic.net 527 Dario Gomez 528 LACNIC 529 Rambla Mexico 6125 530 Montevideo, 11400 531 Uruguay 533 Phone: +598-2604-2222 534 Email: dario@lacnic.net 536 Gerardo Rada 537 LACNIC 538 Rambla Mexico 6125 539 Montevideo, 11400 540 Uruguay 542 Phone: +598-2604-2222 543 Email: gerardo@lacnic.net