Subject: [Ietf-not43] requirements for port 43 alternative

From: [email-masked] (Andrew Newton)
Date: Tue, 21 Aug 2001 12:31:31 -0400

Now that IETF-51 is over and we've all had a bit of a
chance to recover, I guess it is time to start talking
about requirements for an alternative to whois.  Here
are some of the topics I remember being discussed:

Client Authentication
  The ability for the client to authenticate to the server.

Referrals
  We simply discussed the need for these, but not the richness
  of them.

Existing schema language
  While few were committed to any specific technology, the
  desire to not invent another schema language seemed reasonable.

Awareness or Symmetry with PROVREG
  I believe this was just mentioned... there seemed to be no
  real consensus either way.

Useful by both Domain and RIR entities
  The solution should be useful to both domain registrars/registries
  and RIR's.  There was some discussion about name hierarchies
  as they relate to IP addresses.

The following are issues / assumptions / requirements we may want
to discuss:

1) The Handle Issue
   Randy Bush brought this up in the whoisfix BOF, and it would
   seem applicable to this topic as well.  
   Possible solutions to this problem (not definitive):
   a) A recognized and authoritative entity that registers handles.
      This is probably fraught with all sorts of political
      issues.
   b) An algorithmic assignment of handle identifiers for
      uniqueness.  This doesn't address the problem of having
      more than one handle for a contact, host, etc.. when it
      is not desired.
   c) Use of a URI as the handle to reference a contact, host,
      etc.. already registered / recognized at another server.

2) Expression of Privacy Policy
   This seems to come up in other related areas, so giving it
   air-time here seems justifiable.  Would the new protocol or
   solution need to have the ability to express the privacy
   policy and rights of the registrants, etc.
   (my own personal feeling is "no").

3) Naming Hierarchy
   Because domains, IP addresses, etc.. are hierarchical in
   nature, the naming structure of the solution must support
   hierarchy within the confines of supporting the constituent
   uses (domains and IP).

4) Structured Queries
   Given the talk about use of an existing schema language and
   #3), it is possible to assume structured queries would be
   a by-product.  However, it probably needs to be addressed
   or at least stated.

5) Ditto for structured responses.

6) Client Processing
   With the discussion of LDAP, XML, etc. it was probably assumed
   that clients would process both queries from users and responses
   from servers.  While there was some discussion on this, it
   should probably be stated as an assumption.

7) Existing tool-kits, etc.
   Given the requirement for use of an existing schema language,
   it might also be reasonable to state an assumption that existing
   tool-kits and known technologies for many parts of the solution
   should already exist.  In other words, I don't think many of
   us would really opt for XML DTD's as the schema language of
   choice if we all had to write our own validating XML parsers
   because none existed (this is just an example).

-andy

-- 
Andrew Newton
VeriSign Applied Research
[email-masked]

---

From: [email-masked] (Shane Kerr)
Date: Tue, 28 Aug 2001 12:43:17 +0200

Andrew,

Thanks for putting this together!

>   The ability for the client to authenticate to the server.

Do we want to consider the reverse?  In the RIR community, we are
currently looking at what you might consider a special case of server
authentication:  heirarchical route authorization.  I guess more
properly this isn't really "Server Authentication" but more of a "Data
Integrity Trail".  It's an evil, scary problem, but perhaps necessary,
especially if we want....

>   We simply discussed the need for these, but not the richness

:) 

I'm not sure what is meant by "richness" here.  Are you trying to get at
the motivation for referral mechanisms or the possible approaches to
referrals?

I see two primary (possibly conflicting?) motivations for referral.  One
is simply scalability.  The other is to provide query clients with more
complete and/or accurate information in some way (whether more specific,
less specific, or simply a record stored elsewhere).

Given the current load on our servers, my interest is definately in
improving quality of information returned rather than on scaling
characteristics.  But that may change in a year.  :P

>       etc.. already registered / recognized at another server.

<discussion of the Handle Issue left to a separate e-mail>

>    (my own personal feeling is "no").

While I agree with this feeling personally, it does seem to me that
anyone running a public, global database may not have any choice in this
matter in the long run.  Pursuing per-user policy may not be
appropriate, but I can see organizations being forced to restrict access
to specific data about various classes of users (e.g. Germans).

Unless somebody could please explain to these elected officials that
their national soverignty has been superceded by a bunch of geeks
wearing tee shirts and jeans?  :)

I think we can all agree we can't solve the larger problem of
restricting access to a public database BY various classes of users
(for instance, we can't keep anyone under 18 from viewing specific
data).

>    because none existed (this is just an example).

100% agree with all of this.  Does "structured" imply potential security
problems, e.g. trivial DOS attacks?

-- 
Shane
Carpe diem

---

From: [email-masked] (Shane Kerr)
Date: Tue, 28 Aug 2001 13:08:26 +0200

Excuse me for a second while I drag this soap box over here to the
middle....

>       etc.. already registered / recognized at another server.

No matter how I look at it, I don't see any real problem with handles.

Do you expect your Amazon.com customer identifier to be the same as your
ICQ identifier?  Do you expect your social security number to be the
same as your phone number?  Of course not.  Would it be easier on the
you if they were all the same?  Of course it would.  But these are
disparate databases, with disparate identifiers. (*)

It would be irresponsible of Eddie Bauer to use a customer record in the
database of my local library - it is in their own best interest to keep
my information correct, and they should pursue any means possible to do
this.  Meaning my information has to be stored in two places, with two
identifiers.

The real problem is that at some point somebody decided to make things
easier on users and allow them to use InterNIC handles in other
databases.  The *solution* to the problem is to recognize a handle for
what it is:  an identifier for a database.  Any similarity to actual
handles, living or dead, is purely coincidental.

Even if we develop a algorithm for unique naming, and some URI scheme
for locating handles, what is the point?  Would we really expect
register.com to use my contact information from apnic.net - a non-profit
company that operates in a different country?  I would be very surprised
if they would!

To me what it sounds like people want is, well, Microsoft's Passport
service (or a distributed, open version of said service).  Some location
where they can enter in whatever personal information they want and have
it magically updated everywhere they want when it changes.  Which is
fine, but when people bring up the Handle Issue it sounds easy, and
trivializes the fundamental problem.

-- 
Shane
Carpe Diem

(*) I won't even mention the wailing and gnashing of teeth among the
    paranoid due to some U.S. states using the social security number
    for driver licenses.  Apparently if somebody knows your SSN they can
    actually travel back in time and kill your father before he meets
    your mother.  :)

---

From: [email-masked] (Andrew Newton)
Date: Tue, 28 Aug 2001 10:12:22 -0400

Shane,

> especially if we want....

Well, server authentication has been going on in the HTTPS world
for a long time now, so I don't see that as "problem" issue... 
just one of "would we want it".  My feeling is that it would be 
a good thing and probably wouldn't be that much harder to do.

As for your larger, scary problem... Can you explain the use case 
for this.  I think I know what you are getting at, but I don't want 
to assume it.  In general, server authentication may be enough to 
do what you need.  If host X says, "get this info from host Y" and 
you can authenticate that host Y is host Y, it would seem the trail 
has integrity from a standpoint of who said what.  Now data 
accuracy... that's a different story.

> characteristics.  But that may change in a year.  :P

I guess richness means more than just "go look over there".  And it
probably depends on who you talk to about the other rich features
should be.  Personally, I don't want to get to fancy and start
describing referrals with RDF or whatever.  However, I do think, for
the benefit of a client, that a server should distinquish between
"continue searching at location X" and "you can find the object you
are looking for at location X".  In addition, when handing out a
referral, it seems reasonable that sometimes a server may want to
give meta-data about it.

As for scalability, they are probably needed.  But I think there is
a more politically charged reason for them in our environment -
nobody wants to hand ALL their data over to somebody else.

> problems, e.g. trivial DOS attacks?

I'm not sure I follow this.  Can you explain?

-andy

---

From: [email-masked] (Andrew Newton)
Date: Tue, 28 Aug 2001 10:24:18 -0400

So I guess, before going after a or many possible solutions to the
problem, we should ask ourselves the following:

 1) Is this a problem many people would like solved?
 2) Or is this just a particular nit from R. Bush?

-andy

---

From: [email-masked] (Andrei Robachevsky)
Date: Wed, 29 Aug 2001 04:33:37 +0200

>  1) Is this a problem many people would like solved?

Perhaps the problem should be split into several ones:

a) People need to maintain exactly the same information in several whois
databases. This is something related to registrations, and we need to
agree whether this is within the scope of this discussion group.

b) People need to know which database to query for a particular
nic-handle.

c) People don't know which nic-handle is theirs.

> _______________________________________________
> Ietf-not43 mailing list
> [email-masked]
> http://lists.research.netsol.com/mailman/listinfo/ietf-not43

-- 
Andrei Robachevsky
RIPE NCC

---

From: [email-masked] (Eric A. Hall)
Date: Tue, 28 Aug 2001 22:37:47 -0500

> are some of the topics I remember being discussed:

A couple of other issues which should be added to a requirements documents
are language and charset. Take a peek at whois.nic.or.kr and whois.nic.jp
for proof that users want to enter/extract data in a non-ASCII charset and
language.

I'm not saying that there needs to be a mandate for multilingual data in
the system, but I am saying that there is a need for multilingual data, 
and the protocol[s] must be capable of supporting this requirement.

-- 
Eric A. Hall                                        http://www.ehsco.com/
Internet Core Protocols          http://www.oreilly.com/catalog/coreprot/

---

From: [email-masked] (Eric A. Hall)
Date: Tue, 28 Aug 2001 22:41:25 -0500

> Take a peek at whois.nic.or.kr and whois.nic.jp for proof

                                     ^^^^^^^^^^^^
                                     whois.nic.ad.jp

doh

---

From: [email-masked] (eppen)
Date: Wed, 29 Aug 2001 08:58:07 +0200

Hello Andy

Many thanks for taking this up and starting the discussion.
I'd like not to focus on features (structured query/response, multiple 
charsets, client/server authentication, privacy protection, ...) but on 
functionality. Once we have found out what functionality we need, we need 
to define which of the above features are needed for each specific 
functionality. And once we have cleared this hurdle, I suggest to have one 
TCP/UDP Port for each functionality (or maybe some can be grouped according 
to their features, although this might casue problems with future 
extensions).

The current port 43 sufferes heavily from overgrouping of functionality 
onto one port. Basically it is a window into a huge database of different 
object types (domains, addresses, nameservers, networks, ASs, routing 
policies). Having only one port to offer all needed functions and feature 
combinations is a problem and leads to one BOF after another without 
progress.

The ietf-not43 approach is one step which might help. We need to make a 
list of functions we want. Some might be offered already over port 43, we 
list them nevertheless. Because the next step is to attribute the features.

Here is one example which should make myself clearer.

Function:  Find out if a domain is registered or not
   Query to the server: a domain
   Answer from the server: a keyword stating something like registered |
                           available | blocked | ...
   Features: very quick answer needed
             10s to 1000s of queries per second should be supported
             no privacy protection needed
             no client authentication needed

Some might say you can get this function over port 43 already. But 
generally contact addresses are sent together with the answer, which brings 
those people with privacy concerns onto the plan, especially if 1'000'000s 
of queries are made. This means we have the function on port 43, but not 
the features. To have the features as listed above on port 43 would break 
requirements on other functionalities on port 43. Therefore my guess is 
that if there is a general consensus, that the above mentioned function 
with the features is needed, we put it onto a different port, specify the 
protocol and then we are done. This unloads burden on 43 and on other 
functionality we would like from the WHOIS databases.

Does my writing make sense to some of you?

Kind regards,

Urs Eppenberger, SWITCH  (ccTLD registry for .ch and .li)

---

From: [email-masked] (Jaap Akkerhuis)
Date: Wed, 29 Aug 2001 15:33:30 +0200

Some might say you can get this function over port 43 already.

As I explained at the whoisfix bof, we actually did:

    bartok.sidn.nl> telnet whois.nic.nl 43
    Trying 193.176.144.138...
    Connected to gw.domain-registry.nl.
    Escape character is '^]'.
    is sidn.nl
    domein is actief
    Connection closed by foreign host.

Note the ``is sidn.nl''. We call this the ``is'' service. The standard
service (se below), will answer ``limit reached'' (or something
like that) after n queries from the same ip-number.

	jaap

bartok.sidn.nl> !!
 telnet whois.nic.nl 43
Trying 193.176.144.138...
Connected to gw.domain-registry.nl.
Escape character is '^]'.
sidn.nl

   Rights restricted by copyright. See
   http://www.domain-registry.nl/bestaat.lp

   Domain name:
      sidn.nl (second domain)

   Organisation:
      Stichting Internet Domeinregistratie Nederland
      Utrechtseweg 310
      6812 AR ARNHEM

   Administrative Contact:
      B. Boswinkel
      Phone: +31 26 3563681
      E-mail: [email-masked]

   Technical Contact:
      J. Akkerhuis
      Phone: +31 26 3563681
      E-mail: [email-masked]

   Registrar:
      Stichting Internet Domeinregistratie NL
      Utrechtseweg 310 
      6812 AR ARNHEM

   Domain Nameservers:
      bureau.sidn.nl                193.176.144.162
      dns1.kema.nl                  194.53.253.50

   Domain first registered: 18-11-1999
   Record last updated: 18-11-1999
   Record maintained by: NL Domain Registry

Connection closed by foreign host.
bartok.sidn.nl>

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 29 Aug 2001 08:54:35 -0500

eppen wrote:

> We need to make a list of functions we want. Some might be offered
> already over port 43, we list them nevertheless. Because the next
> step is to attribute the features.

> Function:  Find out if a domain is registered or not

Given that the Internet is a collection of independent networks (physical,
logical and virtual), each of which have separate operational and
administrative staffs, I would say that the most important function of
whois has historically been to provide a locator/information service for
the operators and administrators of the distributed networks for the
purpose of facilitating problem resolution (routing error, mail delivery
error, lame DNS delegations, security problems, spam, etc). This
information isn't available anywhere else.

I can see that there are intellectual property and domain-name lookup
features which are also useful, but the primary concern should be as an
operational and administrative resource, IMO.

It may also be responsible to provide some of the other services by way of
extended response codes or messages ("domain not registered," "domain on
hold").

---

From: [email-masked] (eppen)
Date: Wed, 29 Aug 2001 15:55:26 +0200

Hello Jaap and the others

> like that) after n queries from the same ip-number.

I know, the 'is_this_domain_registered_?'-service is needed. But does your 
service use the same access control as all other services on your port 43? 
My opinion is that the 'is_this_domain_registered_?'-service would not need 
the same access controls, maybe even none (except for DOS attacks). 
Therefore it is a good example for a service which should run on its own 
port.

I heard from DENIC, that they modified a finger daemon for such a 
functionality, check it for yourself with 'finger [email-masked]'
It is a misuse of the finger port as your example is a misuse of the whois 
port. But misuse or not, it offers a needed service, so do not kill me 
because I use the word misuse.

Kind regards,

Urs.

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 29 Aug 2001 09:11:24 -0500

>  2) Or is this just a particular nit from R. Bush?

Stepping back a bit, I think that NIC handles are a reflection of 1970s
database technology, and are not a requirement going forward. While unique
identifiers are necessary, "handles" are not.

---

From: [email-masked] (Jordyn A. Buchanan)
Date: Wed, 29 Aug 2001 10:19:52 -0400

>identifiers are necessary, "handles" are not.

Practically, what's the difference?  For contacts, there's not 
necessarily another field or a combination of fields that can be 
considered to be reliably unique and reproducible.

So, we make one up.  We can call it something other than a handle if 
we want, but that doesn't help us fix this problem, does it?

Jordyn

---

From: [email-masked] (Eric A. Hall)
Date: Wed, 29 Aug 2001 09:25:48 -0500

> >Stepping back a bit, I think that NIC handles are a reflection of
> >1970s database technology, and are not a requirement going forward.
> >While unique identifiers are necessary, "handles" are not.
> 

We can use a direct pointer such as an LDAP URI, or an RP RR with an
explicit DNS domain name, or... Handles are localized aliases for
uncoordinated references; we can and probably should use direct referrals
going forward, instead of trying to manage multiple aliases in multiple
locations.

---

From: [email-masked] (Andrew Newton)
Date: Wed, 29 Aug 2001 11:33:24 -0400

> and the protocol[s] must be capable of supporting this requirement.

I believe this came up at the WhoisFix BOF too.  And it is a good 
point.

So here are two possible requirements:
 1) the protocol must support character sets other than ASCII 
    with a goal of targetting the best common practices in this 
    area (is this Unicode?).
 2) not just support of character sets other than ASCII, but
    support for localization (or results change based on the
    needs of the clients, etc... )

Personally, I think the first is o.k.  The second I think is
thorny.

-andy

---

From: [email-masked] (Andrew Newton)
Date: Wed, 29 Aug 2001 13:16:12 -0400

Urs,

At present, these discussions are going pretty well and I
see no problem with simultaneous discussions of features
and functions.  We haven't managed to descend into
ASN.1 vs XML vs MIME or whatever wars, which is a good
thing (for now).

With discussing functionality, I feel we have the following
groups of people to serve:
  1) domain registrars
  2) domain registries
  3) RIR registries
  4) implementers
     (I make this distinction because of the growing
      cottage industry of consultants doing this )
  5) intellectual property holders
  6) civil liberties groups
  7) internet service providers
  8) law enforcement

  did I miss any major group?

> functionality we would like from the WHOIS databases.

Speaking of this particular function, I think this may actually
fall under the control of the PROVREG working group.  It depends on
who the intended users of such a function would be.  Is this for
customers of domain registrars/domain registries, or the public in
general.  If for the general public, I would imagine that they may
want to see other info about a domain and I can't imagine why an
operator would want to support a service level for the general
public for such a function of X number of queries per time unit.
If this is for the customers of domain registrars/registries, then
PROVREG should be doing this.

-andy

---

From: [email-masked] (Shane Kerr)
Date: Fri, 31 Aug 2001 14:41:08 +0200

>   did I miss any major group?

I think that we should keep in mind that the binding mission of a !43
should be a public database:

9) end users

And perhaps "law enforcement" is a special case of "government
officials"?

10) Government

Does any network operator count as an "internet service provider"?  The
reason I ask is that certainly large academic, corporate, or
governmental organizations should be represented as users (e.g.
configuring filters based on routing registries):

11) network operators

I also envision some day where any business may be forced to use
information retrieved from a !43 server before proceeding with a
transaction (e.g. no cigars from Cuba to America).

12) The Man

:P

-- 
Shane
Carpe Diem

---

From: [email-masked] (Andrew Newton)
Date: Fri, 31 Aug 2001 10:52:02 -0400

> And perhaps "law enforcement" is a special case of "government

I think "end users" and "government" are much too broad to
determine what functionality they would desire.

> configuring filters based on routing registries):

I agree with this.  All network operators are not necessarily
ISP's.  And while there is overlap, ISP's may have commercial
obligations that not all network operators posses.

> transaction (e.g. no cigars from Cuba to America).

I guess you are talking from an e-commerce standpoint. I know
that software download farms use to do reverse lookups on the
source IP to determine the country of origin.  But is this still
a problem?  This would be geo-location of an IP address, right?

Speaking of e-commerce, there is one more category of users
I thought of yesterday 

  13) Certificate Authorities
      The need to verify that a person attempting to purchase
      a digital server certificate for a given domain actually
      is a representative of the registrant of the domain.

-andy

---

From: [email-masked] (Jaap Akkerhuis)
Date: Fri, 31 Aug 2001 22:27:25 +0200

You are right. Currently the ``is'' is unrestricted but monitored.
The standard whois queries are restricted and monitored.

I vaguely remember that Uwhois uses port 823 or so, for a similar
service. However, before starting to use different ports, what you
really want to define is the protocol and its function. The main
problem with port 43 is that that isn't defined for anything
particular at all.

It is a long time since I read the finger rfc but I remember it is
nearly just as nebulous about the service that is povided on the
port (79) it uses as whois.  It allows creative use.

	jaap

PS. I couldn't resist to look it up. Here is the basic protocol quoted
from rfc 742:

    To use via the network:

       ICP to socket 117 (octal, 79. decimal) and establish two 8-bit
       connections.

       Send a single "command line", ending with <CRLF>.

       Receive information which will vary depending on the above line and
       the particular system.  The server closes its connections as soon as
       this output is finished.

There is more stuff in this rfc (about the comaand line and the
information one might expect). A severe nostalgia kicked in while
reading this.