Internet Engineering Task Force                         C. Martinez, Ed.
Internet-Draft                                            A. Servin, Ed.
Intended status: Informational                                  D. Gomez                                    LACNIC
Expires: April 18, August 5, 2013                                     L. Zhou, Ed.
                                                                   CNNIC
                                                                D. Gomez
                                                                 G. Rada
                                                                  LACNIC
                                                        October 15, 2012

 LACNIC's
                                                                Feb 2013

       Redirection Service for Number Resource RESTful WHOIS Queries
                     draft-ietf-weirds-redirects-00 Registration Data Access Protocol
                     draft-ietf-weirds-redirects-01

Abstract

   The traditional WHOIS protocol has several important shortcomings,
   and over the past few years several approaches to a better WHOIS
   Registration Data Access Protocol (RDAP) have been discussed and
   proposed.

   Among these shortcomings, different registries operate different
   WHOIS services.  For users this implies that several WHOIS queries to
   different registries may be necessary in order to obtain data for a
   given resource.

   This document describes a proof-of-concept redirection service for RESTful WHOIS queries as implemented by LACNIC.
   queries.  This service allows users to query a single WHOIS service
   and be redirected to the authoritative registry.

   The main goal of this document is to encourage discussion on the
   topics of Joint WHOIS services and query redirection in a RESTful
   WHOIS world.

   The solution implemented by LACNIC proposed here applies to numbering
   resources (IPv4, IPv6 and autonomous system numbers). Regional Internet
   Registries(RIRs) and Domain Name Registries(DNRs).

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
   This Internet-Draft will expire on April 18, August 5, 2013.

Copyright Notice

   Copyright (c) 2012 2013 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Requirements Language  . . . . . . . . . . . . . . . . . .  4
   2.  Proposed Approach  . . . . . . . . . . . . . . . . . . . . . .  4
     2.1.  The REST approach Approach to web services Web Services  . . . . . . . . . . . .  4
     2.2.  Query redirection Redirection for RESTful WHOIS queries Queries  . . . . . . .  5  4
     2.3.  A global Joint Single RESTful WHOIS trough HTTP redirection . Redirection . . . . . .  5
     2.4.  Loops in redirection Redirection . . . . . . . . . . . . . . . . . . .  9  6
   3.  LACNIC RESTful WHOIS redirector implementation . . . . . . . . 12
     3.1.  Accessing the redirector . . . . . . . . . . . . . .  Service Discovery  . . . 12
       3.1.1.  Redirection URI . . . . . . . . . . . . . . . . . . . 12  9
   4.  Security Considerations  . . . . . . . . . . . . . . . . . . . 13  9
   5.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10
     5.1.  Normative References . . . . . . . . . . . . . . . . . . . 13 10
     5.2.  Informative References . . . . . . . . . . . . . . . . . . 13 10
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 10

1.  Introduction

   A user interested in obtaining registration information for a given
   number or domain resource normally uses the WHOIS service provided by
   the RIRs
   (AfriNIC, APNIC, ARIN, LACNIC and RIPE-NCC). DNRs.

   In order to avoid having to query several databases until obtaining
   an
   answer answer, some approaches have been discussed and implemented in the
   past, most notably the Joint WHOIS [lacnic-joint-whois] initiative.
   However, among other shortcomings, Joint WHOIS is implemented using
   proxies and server-side referrals.

   The RESTful approach to WHOIS services
   (draft-newton-weirds-arin-whoisrws [I-D.newton-weirds-arin-whoisrws],
   draft-newton-rir-query [I-D.newton-et-al-weirds-rir-query],
   [draft-lacnic-restful-whois]) (draft-ietf-weirds-using-http
   [I-D.ietf-weirds-using-http]) makes it comparatively easy to
   implement client-side redirects based on normal HTTP 1.1 semantics
   and behavior.

   The goal of this I-D is to document LACNIC's current implementation
   of describe a RESTful WHOIS redirection
   service and to encourage discussion on the topic of redirects in this
   problem domain.

1.1.  Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

2.  Proposed Approach

2.1.  The REST approach Approach to web services Web Services

   While a full introduction to REST and RESTful <http://www.rest.org>
   interfaces is out of the scope of this document it is important to
   note that these interfaces employ the verbs defined in HTTP (GET,
   POST, HEAD, DELETE) and HTTP response codes to signal the semantics
   and outcomes of an operation.

   As WHOIS is a read-only service only the GET verb is implemented.

   HTTP status codes provide signaling for errors and other conditions,
   including the concept of "client-side redirection" as outlined below.

2.2.  Query redirection Redirection for RESTful WHOIS queries Queries

   Each RESTful WHOIS server should answer directly only those queries
   for which it is authoritative.  In this case, being authoritative
   equals "having direct access to a given registry database".

   For all other queries, a RESTful WHOIS server could provide a 301
   MOVED PERMANENTLY Redirect redirect answer pointing to an URL hosted on a
   different RESTful WHOIS server.

   Currently the format of the RESTful WHOIS URIs is different across
   implementations ([I-D.newton-weirds-arin-whoisrws], RIPE RESTful
   Interface [1], [draft-lacnic-restful-whois]), so the redirecting
   server implemented by LACNIC currently maps the original query URI to
   the URI format expected by the receiving server.

   As all requests are to be performed employing HTTP GETs, a user agent
   can transparently follow the HTTP 30x redirection hints ([RFC2616])
   until obtaining a non-error answer (HTTP 20x) ) or an unrecoverable
   error condition (HTTP 40x or 50x).

   If the work of WEIRDS progresses far enough so that an uniform URI
   format is agreed upon, the need for server-side URI mappings may
   become unnecessary.

   LACNIC's current implementation splits the authoritative RESTful
   WHOIS service from the redirection service.  The redirection service
   provides a "switching point" for the whole resource tree.  No Inter-
   RIR coordination, database replication nor RIR-side proxies are
   needed.

2.3.  A global Joint Single RESTful WHOIS trough HTTP redirection

   A single Redirection

   When a registry does not have the authoritative answers to the user
   agent's query, user agent's query will be redirected to a
   redirection-only RESTful WHOIS server could provide a single
   root to which all RIR RESTful WHOIS servers could point queries for
   which they are not authoritative.

   In LACNIC's implementation provide the
   authoritative WHOIS server address.

   The redirect server's database was
   initialized from IANA's registries server is responsible for IPv4, IPv6 tracking and AS numbers.

   Implementation was very simple even when adding returning the server-side URI
   mapping requirement outlined above.  LACNIC's staff was able to
   implement a proof of concept redirect-only
   authoritative sources for IP, AS, domain name, name server or entity
   queries.  All the query format are described in about two days
   of effort including importing IANA's IPv4 registry into a database
   and implementing URI mapping the
   draft-ietf-weirds-rdap-query [I-D.ietf-weirds-rdap-query] Until now,
   there are some alternative solutions for LACNIC, ARIN the bootstrapping problem of
   redirect server, such as using DNS SRV or NAPTR records.  But this
   problem is out of scope of this document and RIPE's RESTful
   WHOIS services. will be discussed
   further in the following drafts in WEIRDS working group.

   Figure 1 shows the general scheme of a single WHOIS redirector RESTWhois Redirection
   Service serving three different RIRs standalone WHOIS RESTWhois while
   providing a seamless query interface to clients.

                           ......................
                           |                    |
                           |  WHOIS REDIRECTOR  |
                           |                    |
                           `....................'
                                 _,  |   ._
                              ,,'    |     `.
                           ,-'       |       `-.
                        ,-'          |          `._
                    _,-'             |             `.
                  .'                 |               `-.
             +-----------Y    +-------------.    ,------------b
             |   LACNIC  |    |  RIPE-NCC   |    |   ARIN     |
             |           |    |             |    |            |
             '`'''''''''''    '`''''''''''''     '`''''''''''''

                         RESTful Joint WHOIS Tree.

                                 Figure 1

   Figure 2 shows how HTTP 301 redirection hints guide a client looking
   for registration data for the IPv4 address 23.1.1.1 (administered by
   ARIN) from LACNIC's WHOIS, the redirector and finally ARIN's WHOIS.

                          LACNIC      REDIRECTOR       ARIN
                          WHOIS       WHOIS            WHOIS
                            .           .               .
        Q: 23.1.1.1? ---->  |           |               |
                            |           |               |
          <-- HTTP 301 ---  |           |               |
         ('Try Redirector') |           |               |
                            |           |               |
                            |           |               |
        Q: 23.1.1.1? -----------------> |               |
                                        |               |
           <---------- HTTP 301 --------|               |
                  ('Try ARIN WHOIS')    |               |
                                        |               |
                                                        |
          Q: 23.1.1.1? -------------------------------> |
                                                        |
             <---------- HTTP 200 --------------------- |
                    (WHOIS response is returned)        |
                                                        |
                                                        |
                                                        .

                     Querying WHOIS data for 23.1.1.1

                                 Figure 2

   Figure 3 shows the output of the well-known 'wget' tool where the
   redirection hints (HTTP 301's) for the same query can be seen.
   Figure 3 also shows how the URL mapping function operates,
   transforming the LACNIC REST URI into an ARIN REST URI.

 wget --output-document=-
  http://restwhois.labs.lacnic.net/restfulwhois/ip/23.1.1.1

--2012-01-10 15:37:46--
 http://restwhois.labs.lacnic.net/restfulwhois/ip/23.1.1.1

 Resolving restwhois.labs.lacnic.net (restwhois.labs.lacnic.net)...
200.7.84.21

Connecting to restwhois.labs.lacnic.net
 (restwhois.labs.lacnic.net)|200.7.84.21|:80... connected.
HTTP request sent, awaiting response... 307 Temporary Redirect

Location: http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1
 [following]
--2012-01-10 15:37:46--
 http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1

Resolving www.labs.lacnic.net (www.labs.lacnic.net)...
 2001:13c7:7001:4000::10, 200.7.84.10
Connecting to www.labs.lacnic.net
 (www.labs.lacnic.net)|2001:13c7:7001:4000::10|:80... connected.
HTTP request sent, awaiting response... 301 MOVED PERMANENTLY

Location: http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1/
 [following]
--2012-01-10 15:37:46--
 http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1/
Connecting to www.labs.lacnic.net
 (www.labs.lacnic.net)|2001:13c7:7001:4000::10|:80... connected.
HTTP request sent, awaiting response... 301 MOVED PERMANENTLY

Location: http://whois.arin.net/rest/ip/23.1.1.1 [following]

--2012-01-10 15:37:46--  http://whois.arin.net/rest/ip/23.1.1.1

Resolving whois.arin.net (whois.arin.net)... 2001:500:31::47,
 2001:500:13::46, 2001:500:13::47, ...
Connecting to whois.arin.net (whois.arin.net)|2001:500:31::47|:80...
 connected.
HTTP request sent, awaiting response... 200 OK
Length: 1038 (1.0K) [application/xml]
Saving to: `STDOUT'

 --- output suppressed for brevity ---

   Detailed 'wget' output for a RESTful WHOIS query for 23.1.1.1
                                 Figure 3

2.4.  Loops in redirection Redirection

   When redirection is used there is always the risk that bogus user-
   agents and applications or malicious user can create loops that in
   turn may become Denial of Service attacks.

   To minimize the risk of loops created by bogus applications and user-
   agents operators MAY use the mechanism shown in Section 3.1.
   However, this mechanism could be forged and bypassed by malicious
   users possibly creating a Denial of Service attack against the
   operator.  To avoid completely the risk of DoS operators should use
   other methods such as rate-limit and authentication that are outside
   the scope of this document.

   One of the challenges by using redirection is loop avoidance.  Even
   though recommendation from REFERENCE** indicates that user-agents
   should have a mechanism to break loops, due to sometimes not
   carefully coded user-agents and other applications or due to
   malicious users' activities loops that could end up in a Denial of
   Service for the RESTful WHOIS operator.

   A simple scenario that creates a loop is shown in Figure 4.  An 3.  A user
   request (1) an object from Operator 1; Operator 1 do not have the
   object but it has a pointer that Operator 2 has it, so it redirects
   (2) the user to Operator 2; user request Object X to Operator 2 (3);
   Operator 2 does not have the object either object but it has a
   pointer that Operator 1 has it, so it redirects (4) the user to
   Operator 1; it creates a loop (5).

        +--------------+                     +--------------+
        |              |                     |              |
        |  Operator A  |                     |  Operator B  |
        |              |                     |              |
        +---^-----+----+                     +----^----.----+
   1)       |     |  2)                3)         |    | 4) Redirect
   Request  |     |  Redirect          Request    |    |    to
   Object X |     |  to                Object X   |    |  Operator A
            |     |  Operator B                   |    |
            |     |____________    _______________|    |
            |_______________  |    |  _________________|
                           |  |    |  |
                         +--------------+
                         |              |      5) Loop
                         |     User     |
                         |              |
                         +--------------+

                               A simple loop

                                 Figure 4 3

   The loop described could be avoided by simple forbidding to redirect redirecting
   a response when the query has been originated by a redirect.  However
   this solution only allows one redirection.  A less restrictive
   approach forbidding redirection to only when the destination is the
   same than the originator for the redirection does not work either as
   shown in Figure 5. 4.

            +--------------+                   +--------------+
            |              |                   |              |
            |  Operator A  |                   |  Operator B  |
            |              |                   |              |
            +---^-----+----+                   +----^----+----+
       1)       |     |  2)                3)       |    | 4)Redirect
       Request  |     |  Redirect          Request  |    |   to
       Object X |     |  to                Object X |    |  Operator C
                |     |  Operator B                 |    |
                |     |____________    _____________|    |
                |_______________  |    |  _______________|
                               |  |    |  |
                             +---\/------\/-+
          7) Loop            |              |
                             |     User     |
                             |              |
                             +---^-----+----+
             6) Redirect         |     |    5)
                to Operator A    |     |     Request
                                 |     |     Object X
                             +--------\/----+
                             |              |
                             |  Operator C  |
                             |              |
                             +--------------+

                           A more complex loop.

                                 Figure 5

   In the scenario depicted in Figure 5 the user request object X from
   Operator A which redirects him/her to Operator B which in turn
   redirects the user to Operator C. Operator C then redirects the user
   back to Operator A again creating a loop.

   To avoid loops created by not well-programmed user-agents or
   applications when redirecting operators MAY append or modify a
   special URI indicating that a redirection and how many times it has
   been done.  The format of the URI is described in the next section. 4

   In the scenario depicted in Figure 5 4 the user request object X from
   Operator A which redirects him/her to Operator B which in turn
   redirects the user to Operator C. Operator C then redirects the user
   back to Operator A again creating a loop.

   To avoid loops created by not well-programmed user-agents or
   applications when redirecting operators MAY append or modify a
   special URI indicating that a redirection and how many times it has
   been done.  The format of the URI is described in the next section.

3.  LACNIC RESTful WHOIS redirector implementation

   LACNIC's staff was able to implement a proof-of-concept WHOIS
   redirect without committing to a large development effort (around 12
   man-hours were consumed).

   The redirector was implemented in the Python programming language and
   employing the Django web framework library for handling HTTP requests
   and responses.

   The choice of technology was dictated more by the developers'
   familiarity with it.  No claim regarding performance or suitability
   for a production service is made.

3.1.  Accessing the redirector

   Currently there are two ways for accessing the redirector:

      o By querying LACNIC's RESTful WHOIS for a non-LACNIC resource:

      wget --output-document=-
      http://restwhois.labs.lacnic.net/restfulwhois/ip/23.1.1.1

      o Directly at:

      http://www.labs.lacnic.net/restwhois/rwhois_redir

   The redirector currently supports queries for IPv4 address blocks
   only, employing the REST URIs defined in [!REF:draft-lacnic-
   restfulwhois].

   The current implementation will provide a redirection to an empty
   answer in case the resources are not found in its registry.

   LACNIC's current plans currently include extending the redirector so
   queries for IPv6 blocks as well as autonomous system numbers are
   supported.

3.1.1.  Redirection URI follows.

   When a RESTful WHOIS operator redirects an a user to retrieve an object
   from another operator, the operator making the redirection operator
   MAY append or modify a special URI.

   When using an URI to indicate redirection, the URI MUST have the
   following structure:

   /redirect/[step]
   Where [step] is a consecutive counter that MUST be increased by every
   operator when the URI is encountered in a query object.

   When an operator is redirecting a query for the first time it MAY
   append the redirection URI to the original URL.  If the redirection
   URI is used, it MUST use the format previously described and it MUST
   set "step" equal to 1.  For example, the URL
   "http://whois.lacnic.net/restfulwhois/ip/200.7.84.0/24" would be
   replaced by

   "http://whois.example.com/restfulwhois/ip/200.7.84.0/24/redirect/1"

   If an operator receives a request with the redirect URI it first
   SHOULD check if "step" is shorter that the defined threshold.  If it
   does the operator SHOULD strip it and process the query.  If the
   query requires further redirection the operator MAY use the
   redirection URI and it MUST increase "step" in one.

   Operators that support the redirect URI MUST never process redirects create a new
   redirect that contain a step value greater that their locally set
   threshold.  However if the operator has an authoritative response to
   the agent it MUST respond regardless to the threshold value.

3.  Service Discovery

   TBD

4.  Security Considerations

   This document makes no explicit security considerations

   Firstly, redirect server settings cannot be modified by someone other
   than
   those stated above. the user validated by the redirection server.

   Secondly, insure the redirection URL data must not be able to modify
   URL in data transmission process.  Such as
   http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1 cannot
   be modified to
   http://www.labs.somenic.net/restwhois/rwhois_redir/ip/23.1.1.1.

   While security practices are outside the scope of this document, the
   authors believe it is important to identify such problematic use
   cases to any DNR or RIR that may implement the redirection WHOIS
   service.

5.  References

5.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

   [min_ref]  authSurName, authInitials., "Minimal Reference", 2006.

5.2.  Informative References

   [I-D.newton-et-al-weirds-rir-query]

   [I-D.ietf-weirds-rdap-query]
              Newton, A., Ranjbar, K., and A. Servin, "A Uniform RESTful
              URL and S. Hollenbeck, "Registration Data Access
              Protocol Query Pattern for RIRs",
              draft-newton-et-al-weirds-rir-query-00 Format", draft-ietf-weirds-rdap-query-02
              (work in progress),
              September 2011.

   [I-D.newton-weirds-arin-whoisrws] December 2012.

   [I-D.ietf-weirds-using-http]
              Newton, A., "ARIN's RESTful Web Service for Whois Data",
              draft-newton-weirds-arin-whoisrws-00 Ellacott, B., and N. Kong, "Using the
              Registration Data Access Protocol (RDAP) with HTTP",
              draft-ietf-weirds-using-http-01 (work in progress),
              June 2011.
              December 2012.

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [draft-lacnic-restful-whois]
              LACNIC, "LACNIC's RESTful WHOIS Interface for Registry
              Data", 2011, <http://www.labs.lacnic.net/site/sites/
              default/files/draft-lacnic-weirds-restwhois-03.pdf>.

   [lacnic-joint-whois]
              LACNIC, "Joint WHOIS", 2005, <ftp://
              anonymous@ftp.registro.br/pub/gter/gter20/
              02-jwhois-lacnic.pdf>.

URIs

   [1]  <https://labs.ripe.net/ripe-database/database-api/
        api-documentation>

Authors' Addresses

   Carlos M. Martinez (editor)
   LACNIC
   Rambla Mexico 6125
   Montevideo,   11400
   Uruguay

   Phone: +598-2604-2222
   Email: carlos@lacnic.net
   Arturo L. Servin (editor)
   LACNIC
   Rambla Mexico 6125
   Montevideo,   11400
   Uruguay

   Phone: +598-2604-2222
   Email: aservin@lacnic.net

   Linlin Zhou (editor)
   CNNIC
   No. 4, South 4th Steet, Zhongguancun
   Beijing,   100190
   China

   Phone: +8610-5881-2677
   Email: zhoulinlin@cnnic.cn

   Dario Gomez
   LACNIC
   Rambla Mexico 6125
   Montevideo,   11400
   Uruguay

   Phone: +598-2604-2222
   Email: dario@lacnic.net

   Gerardo Rada
   LACNIC
   Rambla Mexico 6125
   Montevideo,   11400
   Uruguay

   Phone: +598-2604-2222
   Email: gerardo@lacnic.net