draft-ietf-weirds-redirects-01.txt   draft-ietf-weirds-redirects-02.txt 
Internet Engineering Task Force C. Martinez, Ed. Internet Engineering Task Force C. Martinez, Ed.
Internet-Draft A. Servin, Ed. Internet-Draft A. Servin, Ed.
Intended status: Informational LACNIC Intended status: Informational LACNIC
Expires: August 5, 2013 L. Zhou, Ed. Expires: January 16, 2014 L. Zhou, Ed.
CNNIC CNNIC
D. Gomez D. Gomez
G. Rada G. Rada
LACNIC LACNIC
Feb 2013 July 15, 2013
Redirection Service for Registration Data Access Protocol Redirection Service for Registration Data Access Protocol
draft-ietf-weirds-redirects-01 draft-ietf-weirds-redirects-02
Abstract Abstract
The traditional WHOIS protocol has several important shortcomings, The traditional WHOIS protocol has several important shortcomings,
and over the past few years several approaches to a better and over the past few years several approaches to a better
Registration Data Access Protocol (RDAP) have been discussed and Registration Data Access Protocol (RDAP) have been discussed and
proposed. proposed.
It is worth noting that the term WHOIS is sometimes used
interchangeably to mean either (a) the registration data itself or
(b) the protocol used to access registration data
Among these shortcomings, different registries operate different Among these shortcomings, different registries operate different
WHOIS services. For users this implies that several WHOIS queries to WHOIS services. For users this means that several WHOIS queries to
different registries may be necessary in order to obtain data for a different registries may be necessary in order to obtain data for a
given resource. given resource.
This document describes a redirection service for RESTful WHOIS This document describes a redirection service for RDAP queries. This
queries. This service allows users to query a single WHOIS service service allows clients to query a single RDAP service and expect
and be redirected to the authoritative registry. either an authoritative answer or a redirection hint pointing to
another, possibly authoritative, RDAP server.
The solution implemented proposed here applies to Regional Internet The solution implemented proposed here applies to Regional Internet
Registries(RIRs) and Domain Name Registries(DNRs). Registries(RIRs) and Domain Name Registries(DNRs).
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2013.
This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4
2. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 4 2. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . . 4
2.1. The REST Approach to Web Services . . . . . . . . . . . . 4 2.1. The REST Approach to Web Services . . . . . . . . . . . . . 4
2.2. Query Redirection for RESTful WHOIS Queries . . . . . . . 4 2.2. Query Redirection for RDAP Queries . . . . . . . . . . . . 4
2.3. A Single RESTful WHOIS trough HTTP Redirection . . . . . . 5 2.3. A Joint RDAP Tree through HTTP Redirection . . . . . . . . 5
2.4. Loops in Redirection . . . . . . . . . . . . . . . . . . . 6 2.4. The Redirection Table. The Bootstrap Problem. . . . . . . . 7
3. Service Discovery . . . . . . . . . . . . . . . . . . . . . . 9 2.5. Loops in Redirection . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 3. Service Discovery . . . . . . . . . . . . . . . . . . . . . . . 8
5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 8
5.1. Normative References . . . . . . . . . . . . . . . . . . . 10 5. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.2. Informative References . . . . . . . . . . . . . . . . . . 10 5.1. Normative References . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Informative References . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9
1. Introduction 1. Introduction
A user interested in obtaining registration information for a given A user interested in obtaining registration information for a given
number or domain resource normally uses the WHOIS service provided by number or domain resource normally uses the WHOIS service provided by
the RIRs and DNRs. the RIRs and DNRs.
In order to avoid having to query several databases until obtaining In order to avoid having to query several databases until obtaining
an answer, some approaches have been discussed and implemented in the an answer, some approaches have been discussed and implemented in the
past, most notably the Joint WHOIS [lacnic-joint-whois] initiative. past, most notably the Joint WHOIS [lacnic-joint-whois] initiative.
However, among other shortcomings, Joint WHOIS is implemented using However, among other shortcomings, Joint WHOIS is implemented using
proxies and server-side referrals. proxies and server-side referrals.
The RESTful approach to WHOIS services (draft-ietf-weirds-using-http The RDAP protocol (draft-ietf-weirds-using-http
[I-D.ietf-weirds-using-http]) makes it comparatively easy to [I-D.ietf-weirds-using-http]) makes it comparatively easy to
implement client-side redirects based on normal HTTP 1.1 semantics implement client-side redirects based on normal HTTP 1.1 semantics
and behavior. and behavior.
The goal of this I-D is to describe a RESTful WHOIS redirection The goal of this I-D is to describe an implementation of an RDAP
service and to encourage discussion on the topic of redirects in this redirection service and to encourage discussion on the topic of
problem domain. redirects in this problem domain.
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Proposed Approach 2. Proposed Approach
2.1. The REST Approach to Web Services 2.1. The REST Approach to Web Services
While a full introduction to REST and RESTful <http://www.rest.org> 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 interfaces is out of the scope of this document it is important to
note that these interfaces employ the verbs defined in HTTP (GET, note that these interfaces employ the verbs defined in HTTP (GET,
POST, HEAD, DELETE) and HTTP response codes to signal the semantics POST, HEAD, DELETE) and HTTP response codes to signal the semantics
and outcomes of an operation. and outcomes of an operation.
As WHOIS is a read-only service only the GET verb is implemented. As WHOIS is a read-only service only the GET and HEAD verbS are
usually implemented.
HTTP status codes provide signaling for errors and other conditions, HTTP status codes provide signaling for errors and other conditions,
including the concept of "client-side redirection" as outlined below. including the concept of "client-side redirection" as outlined below.
2.2. Query Redirection for RESTful WHOIS Queries 2.2. Query Redirection for RDAP Queries
Each RESTful WHOIS server should answer directly only those queries Each RDAP server should answer directly only those queries for which
for which it is authoritative. In this case, being authoritative it is authoritative. In this case, being authoritative equals
equals "having direct access to a given registry database". "having direct access to a given registry database".
For all other queries, a RESTful WHOIS server could provide a 301 For all other queries, a RDAP server could provide a 301 MOVED
MOVED PERMANENTLY redirect answer pointing to an URL hosted on a PERMANENTLY redirect answer pointing to an URL hosted on a different
different RESTful WHOIS server. RDAP server.
As all requests are to be performed employing HTTP GETs, a user agent As all requests are to be performed employing HTTP GETs, a user agent
can transparently follow the HTTP 30x redirection hints ([RFC2616]) can transparently follow the HTTP 30x redirection hints ([RFC2616])
until obtaining a non-error answer (HTTP 20x) or an unrecoverable until obtaining a non-error answer (HTTP 20x) or an unrecoverable
error condition (HTTP 40x or 50x). error condition (HTTP 40x or 50x).
2.3. A Single RESTful WHOIS trough HTTP Redirection 2.3. A Joint RDAP Tree through HTTP Redirection
When a registry does not have the authoritative answers to the user When a registry does not have the authoritative answers to the user
agent's query, user agent's query will be redirected to a agent's query, user agent's query can be redirected to a redirection-
redirection-only RESTful WHOIS server which could provide the only RDAP server which could provide the authoritative RDAP server
authoritative WHOIS server address. address.
The redirect server is responsible for tracking and returning the The redirect server is responsible for tracking and returning the
authoritative sources for IP, AS, domain name, name server or entity authoritative sources for IP, AS, domain name, name server or entity
queries. All the query format are described in the queries. All the query format are described in the
draft-ietf-weirds-rdap-query [I-D.ietf-weirds-rdap-query] Until now, draft-ietf-weirds-rdap-query [I-D.ietf-weirds-rdap-query]. We will
there are some alternative solutions for the bootstrapping problem of call this redirect server "the redirector".
redirect server, such as using DNS SRV or NAPTR records. But this
problem is out of scope of this document and will be discussed
further in the following drafts in WEIRDS working group.
Figure 1 shows the general scheme of a single RESTWhois Redirection The redirect server needs access to data sources that, given a
Service serving three different RIRs standalone RESTWhois while queried resource, provide a pointer to the authoritative RDAP server.
providing a seamless query interface to clients. For lack of a better name, we will call this data source the
"redirection table".
Assuming the redirector has access to a redirection table, the
following pseudo code describes its expected behaviour:
while(true) {
query = read_query_from_network()
auth_rdap_svr = redirect_table_lookup (query.resource)
if (auth_rdap_svr != null) {
write_http_301(auth_rdap_svr)
} else {
write_http_404("resource not in redirect table")
}
}
Redirector state machine
Figure 1
Figure 2 shows the general scheme of a single RDAP Redirection
Service serving three different RIRs standalone RDAPs while providing
a seamless query interface to clients.
...................... ......................
| | | |
| WHOIS REDIRECTOR | | RDAP REDIRECTOR |
| | | |
`....................' `....................'
_, | ._ _, | ._
,,' | `. ,,' | `.
,-' | `-. ,-' | `-.
,-' | `._ ,-' | `._
_,-' | `. _,-' | `.
.' | `-. .' | `-.
+-----------Y +-------------. ,------------b +-----------Y +-------------. ,------------b
| LACNIC | | RIPE-NCC | | ARIN | | LACNIC | | RIPE-NCC | | ARIN |
| | | | | | | | | | | |
'`''''''''''' '`'''''''''''' '`'''''''''''' '`''''''''''' '`'''''''''''' '`''''''''''''
RESTful Joint WHOIS Tree. RDAP Joint WHOIS Tree.
Figure 1 Figure 2
Figure 2 shows how HTTP 301 redirection hints guide a client looking Figure 3 shows how HTTP 301 redirection hints guide a client looking
for registration data for the IPv4 address 23.1.1.1 (administered by 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. ARIN) from LACNIC's WHOIS, the redirector and finally ARIN's WHOIS.
LACNIC REDIRECTOR ARIN LACNIC REDIRECTOR ARIN
WHOIS WHOIS WHOIS RDAP RDAP RDAP
. . . . . .
Q: 23.1.1.1? ----> | | | Q: 23.1.1.1? ----> | | |
| | | | | |
<-- HTTP 301 --- | | | <-- HTTP 301 --- | | |
('Try Redirector') | | | ('Try Redirector') | | |
| | | | | |
| | | | | |
Q: 23.1.1.1? -----------------> | | Q: 23.1.1.1? -----------------> | |
| | | |
<---------- HTTP 301 --------| | <---------- HTTP 301 --------| |
('Try ARIN WHOIS') | | ('Try ARIN RDAP') | |
| | | |
| |
Q: 23.1.1.1? -------------------------------> | Q: 23.1.1.1? -------------------------------> |
| |
<---------- HTTP 200 --------------------- | <---------- HTTP 200 --------------------- |
(WHOIS response is returned) | (WHOIS response is returned) |
| |
| |
. .
Querying WHOIS data for 23.1.1.1 Querying WHOIS data for 23.1.1.1
Figure 2
2.4. Loops in 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 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 3 Figure 3
The loop described could be avoided by simple forbidding redirecting 2.4. The Redirection Table. The Bootstrap Problem.
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 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 4
In the scenario depicted in Figure 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 as follows.
When a RESTful WHOIS operator redirects a user to retrieve an object For the redirection table lookup function, the redirector can either
from another operator, the operator making the redirection operator have pre-populated local table or have access to a service provided
MAY append or modify a special URI. by some form of directory service. How either this local table or
directory service is fed is known as the "bootstrapping problem".
When using an URI to indicate redirection, the URI MUST have the The bootstrapping problem was initially declared out of scope of the
following structure: WEIRDS WG. However, the problem has been discussed and several
proposals have been presented (**insert references to Marc's docs**).
Some of these solutions contemplate using the DNS tree as directory
service while others, for the specific case of number resources,
contemplate using IANA's XML registry files as seed files for a local
redirection table.
/redirect/[step] The bootstrapping problem needs to be addressed differently for names
Where [step] is a consecutive counter that MUST be increased by every and numbers. Not only the coount of potential authoritative RDAP
operator when the URI is encountered in a query object. servers for names (huge) is vastly different from the count for
numbers (currently 5), but also the relationships between the RIRs
and name registries and registrars are very different.
When an operator is redirecting a query for the first time it MAY For the number resources case, parsing IANA's XML registries for
append the redirection URI to the original URL. If the redirection IPv4, IPv6 and Autonomous System Numbers (**insert refs**) allows a
URI is used, it MUST use the format previously described and it MUST simple way for building a redirection table.
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" 2.5. Loops in Redirection
If an operator receives a request with the redirect URI it first When redirection is used there is always the risk that bogus user-
SHOULD check if "step" is shorter that the defined threshold. If it agents and applications or malicious user can create loops that in
does the operator SHOULD strip it and process the query. If the turn may become Denial of Service attacks.
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 create a new Commonly used user agents (including HTTP libraries) have loop
redirect that contain a step value greater that their locally set detection features that are deemed sufficient for breaking loops in
threshold. However if the operator has an authoritative response to RDAP.
the agent it MUST respond regardless to the threshold value.
3. Service Discovery 3. Service Discovery
TBD TBD
4. Security Considerations 4. Security Considerations
Firstly, redirect server settings cannot be modified by someone other
than 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 While security practices are outside the scope of this document, the
authors believe it is important to identify such problematic use authors believe it is important to identify such problematic use
cases to any DNR or RIR that may implement the redirection WHOIS cases to any DNR or RIR that may implement the redirection WHOIS
service. service.
5. References 5. References
5.1. Normative References 5.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
 End of changes. 34 change blocks. 
181 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/