One document matched: draft-ietf-weirds-redirects-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC2616 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml">
<!ENTITY RFC2629 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2629.xml">
<!ENTITY RFC3552 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3552.xml">
<!ENTITY I-D.narten-iana-considerations-rfc2434bis SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.narten-iana-considerations-rfc2434bis.xml">
<!ENTITY I-D.ietf-weirds-using-http SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-weirds-using-http-01.xml">
<!ENTITY I-D.ietf-weirds-rdap-query SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.draft-ietf-weirds-rdap-query-02.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-ietf-weirds-redirects-01" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="RESTWhois Redirection Service">Redirection Service for Registration Data Access Protocol</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<!-- Another author who claims to be an editor -->
<author fullname="Carlos M. Martinez" initials="C.M." role="editor"
surname="Martinez">
<organization>LACNIC</organization>
<address>
<postal>
<street>Rambla Mexico 6125</street>
<city>Montevideo</city>
<region></region>
<code>11400</code>
<country>Uruguay</country>
</postal>
<phone>+598-2604-2222</phone>
<email>carlos@lacnic.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<!-- Another author who claims to be an editor -->
<author fullname="Arturo L. Servin" initials="A." role="editor"
surname="Servin">
<organization>LACNIC</organization>
<address>
<postal>
<street>Rambla Mexico 6125</street>
<city>Montevideo</city>
<region></region>
<code>11400</code>
<country>Uruguay</country>
</postal>
<phone>+598-2604-2222</phone>
<email>aservin@lacnic.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Linlin Zhou" initials="L." role="editor"
surname="Zhou">
<organization>CNNIC</organization>
<address>
<postal>
<street>No. 4, South 4th Steet, Zhongguancun</street>
<city>Beijing</city>
<region></region>
<code>100190</code>
<country>China</country>
</postal>
<phone>+8610-5881-2677</phone>
<email>zhoulinlin@cnnic.cn</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Dario Gomez" initials="D."
surname="Gomez">
<organization>LACNIC</organization>
<address>
<postal>
<street>Rambla Mexico 6125</street>
<city>Montevideo</city>
<region></region>
<code>11400</code>
<country>Uruguay</country>
</postal>
<phone>+598-2604-2222</phone>
<email>dario@lacnic.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<author fullname="Gerardo Rada" initials="G."
surname="Rada">
<organization>LACNIC</organization>
<address>
<postal>
<street>Rambla Mexico 6125</street>
<city>Montevideo</city>
<region></region>
<code>11400</code>
<country>Uruguay</country>
</postal>
<phone>+598-2604-2222</phone>
<email>gerardo@lacnic.net</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="Feb" year="2013" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<!-- Meta-data Declarations -->
<area>General</area>
<workgroup>Internet Engineering Task Force</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>weirds</keyword>
<keyword>whois</keyword>
<keyword>redirection</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>
The traditional WHOIS protocol has several important shortcomings,
and over the past few years several approaches to a better Registration
Data Access Protocol (RDAP) have been discussed and proposed.</t>
<t>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.</t>
<t>This document describes a redirection service for
RESTful WHOIS queries. This service allows users to query a single
WHOIS service and be redirected to the authoritative registry.</t>
<t>The solution implemented proposed here applies to Regional Internet
Registries(RIRs) and Domain Name Registries(DNRs).</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>A user interested in obtaining registration information for a given
number or domain resource normally uses the WHOIS service provided by the RIRs
and DNRs.</t>
<t>In order to avoid having to query several databases until obtaining an
answer, some approaches have been discussed and implemented in the
past, most notably the Joint WHOIS <xref target='lacnic-joint-whois' /> initiative. However, among
other shortcomings, Joint WHOIS is implemented using proxies and
server-side referrals.</t>
<t>The RESTful approach to WHOIS services (<xref target="I-D.ietf-weirds-using-http">draft-ietf-weirds-using-http</xref>) makes it comparatively easy to
implement client-side redirects based on normal HTTP 1.1 semantics and behavior.</t>
<t>The goal of this I-D is to describe a RESTful WHOIS
redirection service and to encourage discussion on the topic of redirects in this
problem domain.</t>
<section title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section anchor="prop_approach" title="Proposed Approach">
<section anchor="rest" title="The REST Approach to Web Services">
<t>While a full introduction to REST and RESTful <eref target="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.</t>
<t>As WHOIS is a read-only service only the GET verb is implemented.</t>
<t>HTTP status codes provide signaling for errors and other conditions,
including the concept of "client-side redirection" as outlined below.</t>
</section>
<section anchor="rest_whois_redir" title="Query Redirection for RESTful WHOIS Queries">
<t>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".</t>
<t>For all other queries, a RESTful WHOIS server could provide a 301 MOVED PERMANENTLY
redirect answer pointing to an URL hosted on a different RESTful
WHOIS server.</t>
<t>As all requests are to be performed employing HTTP GETs, a user agent
can transparently follow the HTTP 30x redirection hints (<xref target="RFC2616"/>)
until obtaining a non-error answer (HTTP 20x) or an unrecoverable error condition (HTTP
40x or 50x).</t>
</section>
<section anchor="joint_whois" title="A Single RESTful WHOIS trough HTTP Redirection">
<t>
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
which could provide the authoritative WHOIS server address.
</t>
<t>
The redirect server is responsible for tracking and returning the authoritative sources
for IP, AS, domain name, name server or entity queries. All the query format are described
in the <xref target="I-D.ietf-weirds-rdap-query">draft-ietf-weirds-rdap-query</xref> Until now, there are some alternative solutions for 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 will be discussed further in the following drafts
in WEIRDS working group.
</t>
<t><xref target="jwhois_tree" /> shows the general scheme of a single RESTWhois
Redirection Service serving three different RIRs standalone RESTWhois
while providing a seamless query interface to clients.</t>
<figure align="center" anchor="jwhois_tree">
<artwork align="center"><![CDATA[
......................
| |
| WHOIS REDIRECTOR |
| |
`....................'
_, | ._
,,' | `.
,-' | `-.
,-' | `._
_,-' | `.
.' | `-.
+-----------Y +-------------. ,------------b
| LACNIC | | RIPE-NCC | | ARIN |
| | | | | |
'`''''''''''' '`'''''''''''' '`''''''''''''
]]></artwork>
<postamble>RESTful Joint WHOIS Tree.</postamble>
</figure>
<t><xref target='redir_example' /> 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.</t>
<figure align="center" anchor="redir_example">
<artwork align="left"><![CDATA[
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) |
|
|
.
]]></artwork>
<postamble>Querying WHOIS data for 23.1.1.1</postamble>
</figure>
</section>
<section title='Loops in Redirection'>
<t>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.</t>
<t>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.</t>
<t>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. </t>
<t>A simple scenario that creates a loop is shown in <xref target='simple_loop' />. 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).</t>
<figure align="center" anchor="simple_loop">
<artwork align="left"><![CDATA[
+--------------+ +--------------+
| | | |
| 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 |
| |
+--------------+
]]></artwork>
<postamble>A simple loop</postamble>
</figure>
<t>The loop described could be avoided by simple forbidding 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 <xref target='complex_loop' />.</t>
<figure align="center" anchor="complex_loop">
<artwork align="center"><![CDATA[
+--------------+ +--------------+
| | | |
| 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 |
| |
+--------------+
]]></artwork>
<postamble>A more complex loop.</postamble>
</figure>
<t>In the scenario depicted in <xref target='complex_loop' /> 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. </t>
<t>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.</t>
<t>When a RESTful WHOIS operator redirects a user to retrieve an object
from another operator, the operator making the redirection operator
MAY append or modify a special URI.</t>
<t>When using an URI to indicate redirection, the URI MUST have the
following structure:</t>
<t>/redirect/[step]</t>
<t>Where [step] is a consecutive counter that MUST be increased by every
operator when the URI is encountered in a query object.</t>
<t>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</t>
<t>"http://whois.example.com/restfulwhois/ip/200.7.84.0/24/redirect/1"</t>
<t>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. </t>
<t>Operators that support the redirect URI MUST never 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.</t>
</section>
</section>
<section anchor="service_discovery" title="Service Discovery">
<t>TBD</t>
</section>
<section anchor="security_considerations" title="Security Considerations">
<t>
Firstly, redirect server settings cannot be modified by someone other than the user validated by the redirection server.
</t>
<t>
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.
</t>
<t>
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.
</t>
</section>
<!-- This PI places the pagebreak correctly (before the section title) in the text output. -->
<?rfc needLines="8" ?>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<!-- References split into informative and normative -->
<!-- There are 2 ways to insert reference entries from the citation libraries:
1. define an ENTITY at the top, and use "ampersand character"RFC2629; here (as shown)
2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xml"?> here
(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.xml")
Both are cited textually in the same manner: by using xref elements.
If you use the PI option, xml2rfc will, by default, try to find included files in the same
directory as the including file. You can also define the XML_LIBRARY environment variable
with a value containing a set of directories to search. These can be either in the local
filing system or remote ones accessed by http (http://domain/dir/... ).-->
<references title="Normative References">
<!--?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?-->
&RFC2119;
</references>
<references title="Informative References">
<!-- Here we use entities that we defined at the beginning. -->
&RFC2616;
&I-D.ietf-weirds-using-http;
&I-D.ietf-weirds-rdap-query;
<reference anchor="lacnic-joint-whois" target="ftp://anonymous@ftp.registro.br/pub/gter/gter20/02-jwhois-lacnic.pdf">
<front>
<title>Joint WHOIS</title>
<author>
<organization>LACNIC</organization>
</author>
<date year="2005" />
</front>
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:09:08 |