Subject: [weirds] Thoughts on Names Redirection

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 7 Nov 2012 15:18:01 +0000

As requested by Carlos during the meeting...

I agree with the sentiment in the room that there isn't much of an issue for the com/net thin registry model. Verisign has referral info for all of the registrars we work with, though the specific info we collect (currently we have a URL to a web page that may or may not be dedicated to providing whois service) will probably need to be changed to support this service. With appropriate info collected from registrars we can redirect as needed.

A more interesting case involves redirects for objects managed by other service providers. I believe there is an opportunity here for both TLD operators and RDAP proxies to receive requests, determine an appropriate redirect using service discovery techniques, and then respond with that redirect. This would provide a more user-friendly operational experience than a 404 response.

The challenge with this second case is that we haven't made any decisions about service discovery. It would be difficult to document an approach in the redirect draft without being able to explain how service discovery works.

Carlos, I'm willing to contribute text as needed.

Scott

---

From: "John Levine" <[email-masked]>
Date: 7 Nov 2012 16:05:30 -0000

>A more interesting case involves redirects for objects managed by other
>service providers. ...

>The challenge with this second case is that we haven't made any
>decisions about service discovery. It would be difficult to document an
>approach in the redirect draft without being able to explain how service
>discovery works.

Here are three issues:

A) Courtesy redirects for clients who start at the wrong server

B) Service discovery, how to find the initial server for a query

C) Server authorization, does a server have the real answer to a query

They're all actually the same issue.

If you know how to find the right initial server, you don't have to
worry about courtesy redirects or authorization, since you know you
have a valid chain of redirects to whatever server has the answer.

For authorization, if you had some way to tell which servers are
allowed to answer what questions, you'd just ask those servers,
so it's the same as service discovery.

For courtesy redirects, if we had service discovery, we wouldn't need
it.  Or if we like the current arrangement with the RIRs, where each
RIR has authoritative redirects for the whole IP space (enough that
there's a non-looping chain to the answer for any IP), we've solved
the discovery and authorization problem.

I don't feel strongly about how we solve this (give or take the
implementability problems we discussed in Vancouver), but we do need
to keep in mind that we need to consider all three at the same time.

R's,
John

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Nov 2012 12:55:16 -0500

At 15:18 +0000 11/7/12, Hollenbeck, Scott wrote:

>service providers.

Looking at this is from the perspective of a protocol engineer, the 
question is a little different.

Here's the basic question form:
What is the response to a query for which I have no information?

Here's a subdivision of that question to home in on the topic of redirection.

(a) What is the response to a query for which I have no information - 
and I think I am the authority?
(b) What is the response to a query for which I have no information - 
and I think that I know who the authority is?
(c) What is the response to a query for which I have no information - 
and I can't determine who the authority is?

This isn't about "name redirection," it's about query redirection. 
It's possible that an IPvX address has been reallocated "downstream" 
or the domain name's details are at a registrar.  (One of the ways 
name and numbers seem different but are not to the protocol.)

The redirection comes into play in the above questions "b" and "c" 
form.  In these two situations the server is advised to respond with 
something that will at least make the client stop asking the server 
and at best help the client select a different server to contact.

To protect the server, the protocol response for (b) and (c) should 
result in no extra processing on the server (and no state retained). 
I.e., no DNS-like recursion nor anything like a CNAME or DNAME 
"chasing."  In the case that the server knows a "downstream" has the 
answer, the response should include that location.  In all other 
cases the server should respond with something that is not larger 
than the query.  (In DNS, the "root referral" response given when 
lame was used as an amplification tool by DDoS.)

To protect the client, the client has to perform so-called loop 
detection.  The client is free to maintain state as it is chasing 
information and part of the state should include whatever is 
necessary to realize it's "chasing it's own tail."

The example I usually resort to - and just because it's a working 
example - is the DNS.  For CNAME, servers limit chains of CNAMEs to 5 
(it's in the RFCs), but if this protocol does not do anything like 
"chasing CNAMEs" this is not needed in the server.  I'll repeat that 
I think the server should do nothing like "chasing CNAMEs".  In DNS 
all the client does is recognize that a loop was in play and knows to 
stop.  For this protocol, I'd recommend the client be the only one 
involved in loop detection and management.

These are my thoughts phrased as requirement and design points - I am 
not implying any particular implementation detail.  And I'm not 
giving thought to the "bootstrap" problem.

Other advice - it doesn't matter why a query arrives at a server.  It 
only matters how the server response and how the client reacts to the 
response.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

2012...time to reuse those 1984 calendars!

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Wed, 7 Nov 2012 18:20:29 +0000

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Edward Lewis
> Sent: Wednesday, November 07, 2012 12:55 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: Re: [weirds] Thoughts on Names Redirection
> 

Of course. I used "Names Redirection" in the subject to focus the discussion in the service provider context since the discussion in the room was that there is no issue here for RIRs.

Scott

---

From: Edward Lewis <[email-masked]>
Date: Wed, 7 Nov 2012 13:39:03 -0500

At 18:20 +0000 11/7/12, Hollenbeck, Scott wrote:

>Of course. I used "Names Redirection" in the subject to focus the discussion
>in the service provider context since the discussion in the room was that
>there is no issue here for RIRs.

That thought crossed my mind, but the considerations for names are 
also considerations for numbers when viewing this as a single 
protocol.

Not all queries are made in earnest, neither are all responses. 
Applying this idea to the protocol at hand, even if we assume all 
traffic is carried over TLS protected streams (meaning we can discard 
message insertion and message alteration in-flight), it is still 
possible that the response might lead to a "loop."

It might be through some one misconfiguring where downstream numbers 
are covered by another server.  Perhaps it's an SQL injection, or an 
operational mistake, I'm not really trying to get deep into how this 
happens here - I'm just trying to say "I postulate that it's 
possible."

Even if "it is not possible" the client interacting with the names 
servers and the numbers server might be the same code, same code 
path.  If the client is written assuming that it will only ever 
connect to the numbers and then later to the names, it could be 
vulnerable if it lacks any management of loops.

PS - I'd like to stamp out the notion that names and numbers are 
different with respect to this protocol.  But that isn't what this 
thread is about.
-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis
NeuStar                    You can leave a voice message at +1-571-434-5468

---

From: "John Levine" <[email-masked]>
Date: 8 Nov 2012 00:37:29 -0000

>possible that the response might lead to a "loop."

Sure, but if we assume they're done via http 302 redirects, it's a
familiar problem, and clients already deal with it.

R's,
John

---

From: "Carlos M. martinez" <[email-masked]>
Date: Wed, 07 Nov 2012 19:44:27 -0500

The question that I tried to bring up during last Tuesday session is
whether we believe that such loops represent a risk for _servers_ ,
rather tan clients.

I'm not saying they do, maybe they don't, I just want to have the views
of the ML on the issue.

regards

Carlos

On 11/7/2012 7:37 PM, John Levine wrote:
> _______________________________________________
> weirds mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/weirds
>

---

From: "John R Levine" <[email-masked]>
Date: 7 Nov 2012 20:00:11 -0500

> rather than clients.

Seems unlikely.  If people use existing clients and client libraries, they 
have loop breaking code.  Conversely, a sufficiently hostile or broken 
client can flood you with requests no matter what you do, so you'd better 
be prepared for it, just like any other server on the public Internet.

Redirects are fairly common on the web in general.  I can think of some 
cases where clients were hammering on my server, but I don't recally any 
of them being 302 loops.

R's,
John

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 8 Nov 2012 01:16:03 +0000

> Behalf Of John R Levine
> Sent: Wednesday, November 07, 2012 8:00 PM
> To: Carlos M. martinez
> Cc: [email-masked]
> Seems unlikely.  If people use existing clients and client libraries,
> they have loop breaking code.  Conversely, a sufficiently hostile or
> broken client can flood you with requests no matter what you do, so
> you'd better be prepared for it, just like any other server on the
> public Internet.
> 
> cases where clients were hammering on my server, but I don't recally
> any of them being 302 loops.

I'm struggling to see how this is a new problem, too. If we use standard http redirects, clients and servers would just do what they normally do.

Scott

---

From: SM <[email-masked]>
Date: Wed, 07 Nov 2012 17:31:31 -0800

Hi Carlos,
>whether we believe that such loops represent a risk for _servers_ ,

I think that there is ample discussion of the issue in the HTTP 
specifications.  I don't see it as an additional risk as the 
mitigation techniques are already known.

Regards,
-sm

---

From: Edward Lewis <[email-masked]>
Date: Thu, 8 Nov 2012 12:37:33 -0500

The best that can be done is make the client responsible for loop 
management and then you've eliminated this from being a problem on 
the server.  If the underlying transport (HTTP) manages it, that much 
better.

Of course, traffic flooding (DoS) is still a problem.  A traffic 
flood could be a result of mismanaging a loop (as has been the case 
in at least one example), but flooding problems are much more 
general.  Under the title of "it doesn't matter why a query arrived, 
you have to deal with it," whether the flood is from a loop or some 
other cause (perhaps intentional) ... cutting out some steps ... the 
server doesn't need to worry about loops (if the protocol places the 
onus on the client to do this).

In DNS, the protocol does not place the onus on the client, so 
servers are the ones that do loop management.  I'd call that a design 
flaw in DNS, one not to be copied elsewhere.  (It's not a fatal or 
serious flaw, nonetheless the DNS protocol could have been better 
defined here.)

---

From: "John Levine" <[email-masked]>
Date: 8 Nov 2012 19:05:15 -0000

>servers are the ones that do loop management.

Huh?  How does a server deal with NS or CNAME loops?

R's,
John

---

From: Edward Lewis <[email-masked]>
Date: Fri, 9 Nov 2012 10:58:07 -0500

I was a bit surprised by what's in this draft.  In the sense that I 
would have expected that every object would have a registrant, I'm 
surprised.

Of the 118 whois services contacted, all of them domain name 
registries, there were 118 domain names found and just 65 registrant 
names.  My expectation is that the most significant report of a whois 
is the registrant name.  I wonder if the low count is due to the 
specific name queried or misinterpretation of results.

Given what is in section 6 ("Limitations") is there a plan to re-run 
this survey?  In a re-run I would encourage the survey to be one of 
intent of the registry as opposed to what is seen.

By that I mean, looking for nic.cctld might be a very objective, 
"fair" means to discover how the various TLDs differ, but it is 
likely (as noted) misleading.  There's no domain name guaranteed to 
be in all TLDs (except maybe Google ;)), but relying on one name 
isn't that important.

I'd rather see the set of labels used at a registry than what is used 
for a particular name across all registries.

And there's no reason this survey can't include the number 
registries.  Of course there's no google.10.in-addr.arpa, but as I 
mentioned it's not about a common query across all servers - it's 
about what servers return.

I'd be interested in knowing:

What number (or % of all registries) have running whois?
What number display the object name (100%?)?
What number indicate a registrant (or admin)?  What is the label?
What number have admin/tech/abuse/billing/other contacts?
(For other, what's common?)
How are names (personal, entity) represented (letters/local script)?
How is contact information rendered (postal, email, telephone)?

And so on.

I do like the counting of "how many labels" are used for entries.

In 5.1, there is this break down:

#   (1)  About 5% of data elements are supported by over 111 (90%)
#        registries.
#
#   (2)  About 30% of data elements are supported by over 44 (35%)
#        registries.
#
#   (3)  About 60% of data elements are supported by over 32 (26%)
#        registries.
#
#   (4)  About 90% of data elements are supported by over 14 (11%)
#        registries.

Is this subject to teh limitation in 6?

---

From: "John Levine" <[email-masked]>
Date: 9 Nov 2012 21:05:52 -0000

>specific name queried or misinterpretation of results.

It sounds right to me.  Unless you have some sort of enhanced access,
a lot of ccTLD registries simply confirm the existence of a name
without providing any details, e.g.:

$ whois cafe.de
[whois.denic.de]
Domain: cafe.de
Status: connect

-- 
Regards,
John Levine, [email-masked], Primary Perpetrator of "The Internet for Dummies",
Please consider the environment before reading this e-mail. http://jl.ly

---

From: "Linlin Zhou" <[email-masked]>
Date: Wed, 14 Nov 2012 17:10:33 +0800

Thanks Edward,

My feedback is as below.

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Edward Lewis
Sent: Friday, November 09, 2012 11:58 PM
To: [email-masked]
Cc: [email-masked]
Subject: [weirds] draft-zhou-weirds-dnrd-ap-object-inventory-00.txt

I was a bit surprised by what's in this draft.  In the sense that I would
have expected that every object would have a registrant, I'm surprised.

Of the 118 whois services contacted, all of them domain name registries,
there were 118 domain names found and just 65 registrant names.  My
expectation is that the most significant report of a whois is the registrant
name.  I wonder if the low count is due to the specific name queried or
misinterpretation of results.

[Linlin]

I think there may be several reasons for that only 65 registries have
registrant name.

1. The response does not contain registrant, such as ".as". The following is
the response from .as for querying nic.as.

Name:            nic.as

Registered by:   AS Domain Registry

Nameservers:     dca.ns.gdns.net (130.94.25.65)

                        phx.ns.gdns.net (216.69.168.151)

                                   cmh.ns.gdns.net (76.10.212.82)

2. IDN response, such as ".cl". Our program does not know how to classify
the IDN responses. I think maybe we could do it manually in the future.

3. Some responses are in the following format. There's no sub object name
for registrant name.

Registrant:

      AM NIC

      Isaakian 28, 3rd Floor

      Yerevan,  375009

      AM

[Linlin]

Given what is in section 6 ("Limitations") is there a plan to re-run this
survey?  In a re-run I would encourage the survey to be one of intent of the
registry as opposed to what is seen.

[Linlin]

If the WG think this analysis is useful, we would consider re-running it. I
do think that there are still many improvements we could do the next step.

[Linlin]

By that I mean, looking for nic.cctld might be a very objective, "fair"
means to discover how the various TLDs differ, but it is likely (as noted)
misleading.  There's no domain name guaranteed to be in all TLDs (except
maybe Google ;)), but relying on one name isn't that important.

I'd rather see the set of labels used at a registry than what is used for a
particular name across all registries.

And there's no reason this survey can't include the number registries.  Of
course there's no google.10.in-addr.arpa, but as I mentioned it's not about
a common query across all servers - it's about what servers return.

[Linlin]

Good suggestion.

[Linlin]

[Linlin]

Thank you for your advice. I think some of the results we could get based on
the data we already have. I will consider your requirements and update in
the next version.

[Linlin]

And so on.

 

[Linlin]

The cumulative distribution analysis just shows the result that only a few
registries support all the public objects, most of the registries support
just parts of all the objects. I think this is a trend chart, the
limitations affect a little.

[Linlin]

--