draft-ietf-weirds-redirects-03.txt   draft-ietf-weirds-redirects-04.txt 
Internet Engineering Task Force C. Martinez, Ed. Internet Engineering Task Force C.M. Martinez, Ed.
Internet-Draft LACNIC Internet-Draft LACNIC
Intended status: Informational L. Zhou, Ed. Intended status: Informational L. Zhou, Ed.
Expires: August 18, 2014 CNNIC Expires: December 31, 2014 CNNIC
G. Rada G. Rada
LACNIC LACNIC
February 14, 2014 July 2014
Redirection Service for Registration Data Access Protocol Redirection Service for Registration Data Access Protocol
draft-ietf-weirds-redirects-03 draft-ietf-weirds-redirects-04
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 It is worth noting that the term WHOIS is sometimes used
interchangeably to mean either (a) the registration data itself or interchangeably to mean either (a) the registration data itself or
skipping to change at page 2, line 7 skipping to change at page 1, line 53
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 18, 2014. This Internet-Draft will expire on December 31, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 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/
(http://trustee.ietf.org/license-info) in effect on the date of license-info) in effect on the date of publication of this document.
publication of this document. Please review these documents Please review these documents carefully, as they describe your rights
carefully, as they describe your rights and restrictions with respect and restrictions with respect to this document. Code Components
to this document. Code Components extracted from this document must extracted from this document must include Simplified BSD License text
include Simplified BSD License text as described in Section 4.e of as described in Section 4.e of the Trust Legal Provisions and are
the Trust Legal Provisions and are provided without warranty as 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 . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 4 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. The REST Approach to Web Services . . . . . . . . . . . . 3
2.1. The REST Approach to Web Services . . . . . . . . . . . . . 4 1.3. Request Redirection for RDAP Queries . . . . . . . . . . . 3
2.2. Query Redirection for RDAP Queries . . . . . . . . . . . . 4 1.4. The Redirection Table. The Bootstrap Problem. . . . . . . 3
2.3. A Joint RDAP Tree through HTTP Redirection . . . . . . . . 5 2. Architectural Use Cases of Redirects in RDAP . . . . . . . . . 3
2.4. The Redirection Table. The Bootstrap Problem. . . . . . . . 7 2.1. A Joint RDAP Tree through HTTP Redirection . . . . . . . . 3
2.5. Loops in Redirection . . . . . . . . . . . . . . . . . . . 8 2.2. Helper Service for Constrained RDAP Clients . . . . . . . 5
2.6. Service Discovery . . . . . . . . . . . . . . . . . . . . . 8 3. Security Considerations . . . . . . . . . . . . . . . . . . . 5
2.7. Security Considerations . . . . . . . . . . . . . . . . . . 8 3.1. Loops in Redirection . . . . . . . . . . . . . . . . . . . 6
3. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Normative References . . . . . . . . . . . . . . . . . . . 8 4.1. Normative References . . . . . . . . . . . . . . . . . . . 6
3.2. Informative References . . . . . . . . . . . . . . . . . . 8 4.2. Informative References . . . . . . . . . . . . . . . . . . 6
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7
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.
skipping to change at page 4, line 31 skipping to change at page 3, line 12
The goal of this I-D is to describe an implementation of an RDAP The goal of this I-D is to describe an implementation of an RDAP
redirection service and to encourage discussion on the topic of redirection service and to encourage discussion on the topic of
redirects in this 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 1.2. The REST Approach to Web Services
2.1. The REST Approach to Web Services
While a full introduction to REST and RESTful interfaces is out of While a full introduction to REST and RESTful interfaces is out of
the scope of this document it is important to note that these the scope of this document it is important to note that these
interfaces employ the verbs defined in HTTP (GET, POST, HEAD, DELETE) interfaces employ the verbs defined in HTTP (GET, POST, HEAD, DELETE)
and HTTP response codes to signal the semantics and outcomes of an and HTTP response codes to signal the semantics and outcomes of an
operation. operation.
As WHOIS is a read-only service only the GET and HEAD verbs are As WHOIS is a read-only service only the GET and HEAD verbs are
usually implemented. 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 RDAP Queries 1.3. Request Redirection for RDAP Queries
Each RDAP server should answer directly only those queries for which Each RDAP server should answer directly only those queries for which
it is authoritative. In this case, being authoritative equals it is authoritative. In this case, being authoritative equals
"having direct access to a given registry database". "having direct access to a given registry database".
For all other queries, a RDAP server could provide a 301 MOVED For all other queries, a RDAP server could provide a 301 MOVED
PERMANENTLY redirect answer pointing to an URL hosted on a different PERMANENTLY redirect answer pointing to an URL hosted on a different
RDAP 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 Joint RDAP Tree through HTTP Redirection 1.4. The Redirection Table. The Bootstrap Problem.
When a registry does not have the authoritative answers to the user For the redirection table lookup function, the redirector can either
agent's query, user agent's query can be redirected to a redirection- have pre-populated local table or have access to a service provided
only RDAP server which could provide the authoritative RDAP server by some form of directory service. How either this local table or
address. directory service is fed is known as the "bootstrap problem".
The redirect server is responsible for tracking and returning the RDAP Bootstrap is described in draft-ietf-weirds-bootstrap [I-D.ietf-
authoritative sources for IP, AS, domain name, name server or entity weirds-bootstrap]
queries. All the query format are described in the
draft-ietf-weirds-rdap-query [I-D.ietf-weirds-rdap-query]. We will 2. Architectural Use Cases of Redirects in RDAP
call this redirect server "the redirector".
2.1. A Joint RDAP Tree through HTTP Redirection
In an scenario where a client does not know which registry can
provide authoritative answers***TBC
When an RDAP server receives a query for which it does not have an
authoritative answer to provide, it MAY provide an HTTP 30x
redirection message pointing the client to a redirection-only RDAP
server, which in turn can provide further redirections guiding the
client to an authoritative server.
The redirect-only 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 draft-
ietf-weirds-rdap-query [I-D.ietf-weirds-rdap-query]. We call this
redirect server "the redirector".
The redirect server needs access to data sources that, given a The redirect server needs access to data sources that, given a
queried resource, provide a pointer to the authoritative RDAP server. queried resource, provide a pointer to the authoritative RDAP server.
For lack of a better name, we will call this data source the For lack of a better name, we will call this data source the
"redirection table". "redirection table".
Assuming the redirector has access to a redirection table, the Assuming the redirector has access to a redirection table, the
following pseudo code describes its expected behaviour: following pseudo code describes its expected behaviour:
while(true) { while(true) {
query = read_query_from_network() query = read_query_from_network()
auth_rdap_svr = redirect_table_lookup (query.resource) auth_rdap_svr = redirect_table_lookup (query.resource)
if (auth_rdap_svr != null) { if (auth_rdap_svr != null) {
write_http_301(auth_rdap_svr) write_http_301(auth_rdap_svr)
} else { } else {
write_http_404("resource not in redirect table") write_http_404("resource not in redirect table")
} }
} }
Redirector state machine Redirector state machine
Figure 1
Figure 2 shows the general scheme of a single RDAP Redirection Figure 2 shows the general scheme of a single RDAP Redirection
Service serving three different RIRs standalone RDAPs while providing Service serving three different RIRs standalone RDAPs while providing
a seamless query interface to clients. a seamless query interface to clients.
...................... ......................
| | | |
| RDAP REDIRECTOR | | RDAP REDIRECTOR |
| | | |
`....................' `....................'
_, | ._ _, | ._
,,' | `. ,,' | `.
,-' | `-. ,-' | `-.
,-' | `._ ,-' | `._
_,-' | `. _,-' | `.
.' | `-. .' | `-.
+-----------Y +-------------. ,------------b +-----------Y +-------------. ,------------b
| LACNIC | | RIPE-NCC | | ARIN | | REGY1 | | REGY2 | | REGY3 |
| | | | | | | | | | | |
'`''''''''''' '`'''''''''''' '`'''''''''''' '`''''''''''' '`'''''''''''' '`''''''''''''
RDAP Joint WHOIS Tree. RDAP Joint WHOIS Tree.
Figure 2
Figure 3 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
RDAP RDAP RDAP 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 RDAP') | | ('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 3 2.2. Helper Service for Constrained RDAP Clients
2.4. The Redirection Table. The Bootstrap Problem.
For the redirection table lookup function, the redirector can either
have pre-populated local table or have access to a service provided
by some form of directory service. How either this local table or
directory service is fed is known as the "bootstrapping problem".
The bootstrapping problem was initially declared out of scope of the
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.
The bootstrapping problem needs to be addressed differently for names
and numbers as the coount of potential authoritative RDAP servers for
names (huge) is vastly different from the count for numbers
(currently 5).
2.5. 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.
Commonly used user agents (including HTTP libraries) have loop
detection features that are deemed sufficient for breaking loops in
RDAP.
2.6. Service Discovery It is expected that a significant portion of RDAP clients will be
written for and operate under constrained environments. For example,
simple Javascript clients written to run inside a web browser's
sandbox cannot perform arbitrary DNS queries nor open sockets, thus
limiting the ability of the client to actually access bootstrapping
data
TBD TBD
2.7. Security Considerations 3. Security Considerations
HTTP 30x-based redirection could offer an attack vector for a Man-in- HTTP 30x-based redirection could offer an attack vector for a Man-in-
the-Middle type of attack, where the adversary modifies the the-Middle type of attack, where the adversary modifies the
redirection URL offered by the server to the client. redirection URL offered by the server to the client.
For example, an attacker able to modify HTTP traffic could modify the For example, an attacker able to modify HTTP traffic could modify the
redirect URL from redirect URL from http://www.labs.lacnic.net/restwhois/rwhois_redir/
http://www.labs.lacnic.net/restwhois/rwhois_redir/ip/23.1.1.1 and ip/23.1.1.1 and change it into http://www.labs.somenic.net/restwhois/
change it into rwhois_redir/ip/23.1.1.1, where bogus information can be offered to
http://www.labs.somenic.net/restwhois/rwhois_redir/ip/23.1.1.1, where the client.
bogus information can be offered to the client.
This particular type of attack can be prevented by usint HTTPS for This particular type of attack can be prevented by usint HTTPS for
the RDAP connection. However, this certainly places a load burden the RDAP connection. However, this certainly places a load burden
upon the servers. upon the servers.
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.
3. References 3.1. Loops in Redirection
3.1. Normative References 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.
Commonly used user agents (including HTTP libraries) have loop
detection features that are deemed sufficient for breaking loops in
RDAP.
4. References
4.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
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
3.2. Informative References 4.2. Informative References
[I-D.ietf-weirds-bootstrap]
Blanchet, M., "Finding the Authoritative Registration Data
(RDAP) Service", Internet-Draft draft-ietf-weirds-
bootstrap-03, June 2014.
[I-D.ietf-weirds-rdap-query] [I-D.ietf-weirds-rdap-query]
Newton, A. and S. Hollenbeck, "Registration Data Access Newton, A. and S. Hollenbeck, "Registration Data Access
Protocol Query Format", draft-ietf-weirds-rdap-query-02 Protocol Query Format", Internet-Draft draft-ietf-weirds-
(work in progress), December 2012. rdap-query-02, December 2012.
[I-D.ietf-weirds-using-http] [I-D.ietf-weirds-using-http]
Newton, A., Ellacott, B., and N. Kong, "Using the Newton, A., Ellacott, B. and N. Kong, "Using the
Registration Data Access Protocol (RDAP) with HTTP", Registration Data Access Protocol (RDAP) with HTTP",
draft-ietf-weirds-using-http-01 (work in progress), Internet-Draft draft-ietf-weirds-using-http-01, December
December 2012. 2012.
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., [RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Masinter, L., Leach, P. and T. Berners-Lee, "Hypertext
Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[lacnic-joint-whois] [lacnic-joint-whois]
LACNIC, "Joint WHOIS", 2005, <ftp:// LACNIC, "LACNIC Joint WHOIS Implementation", 2005, <ftp://
anonymous@ftp.registro.br/pub/gter/gter20/ anonymous@ftp.registro.br/pub/gter/gter20/02-jwhois-
02-jwhois-lacnic.pdf>. lacnic.pdf>.
Authors' Addresses Authors' Addresses
Carlos M. Martinez (editor) Carlos M. Martinez, editor
LACNIC LACNIC
Rambla Mexico 6125 Rambla Mexico 6125
Montevideo, 11400 Montevideo, 11400
Uruguay Uruguay
Phone: +598-2604-2222 Phone: +598-2604-2222
Email: carlos@lacnic.net Email: carlos@lacnic.net
Linlin Zhou (editor) Linlin Zhou, editor
CNNIC CNNIC
No. 4, South 4th Steet, Zhongguancun No. 4, South 4th Steet, Zhongguancun
Beijing, 100190 Beijing, 100190
China China
Phone: +8610-5881-2677 Phone: +8610-5881-2677
Email: zhoulinlin@cnnic.cn Email: zhoulinlin@cnnic.cn
Gerardo Rada Gerardo Rada
LACNIC LACNIC
Rambla Mexico 6125 Rambla Mexico 6125
Montevideo, 11400 Montevideo, 11400
Uruguay Uruguay
Phone: +598-2604-2222 Phone: +598-2604-2222
Email: gerardo@lacnic.net Email: gerardo@lacnic.net
 End of changes. 35 change blocks. 
146 lines changed or deleted 144 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/