Subject: [Ietf-not43] FIRS demonstration

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Jul 25 16:46:17 2003

I've scratched up a very rough v0.01 FIRS demonstration system which
illustrates how it can work (not necessarily how it will work). This
includes a text-based Perl client and an LDAP database, both of which are
running on the test system.

To use the system, point a line-mode client (eg, WHOIS) to goose.ehsco.com
port 43 and give it the resource name of "example.com". The resulting
entries will return other domain names, IP addresses, etc as attribute
values, and any of those can also be queried (take a look at ex?mple.com
to see how internationalization is handled, for example). There are less
than 10 resources stored in the system, so don't expect too much.

You can give it the command-line switch of "--help" for info. There is an
undocumented switch of "--source" which will return the perl source code.

There are a lot of limitations to what I could build in a week, given the
limited availability (nice way of saying zero) of FIRS servers. Most
noticably, the system does not do any bottom-up or top-down queries (no
servers to query) but instead only does targeted queries to the (default)
partition of ntrg.com. If you create your own FIRS-compliant LDAP
database, you can give the app a "--part=your.domain" switch and it will
work; it *does* do the SRV lookups and everything necessary, just there
aren't any other servers out there, so it's hard-wired to default to my
server. Also, this is a very basic LDAP server that does not support
extended syntaxes or filters, so none of the fancy LDAP stuff is there
(this includes ASN.1 attributes, unfortunately). Secondary limitations
include a lack of support for IPv6 objects and referrals. Otherwise, it
works as a real-world system would work.

It's not all a suck though, and there are some interesting features. For
one, the client will emulate the matching filters if it sees that the
server doesn't support them (this is a new feature in the firs-*-02 I-Ds
that were just published, btw). This means you can give it an IPv4 address
of (eg) 192.168.12.209 and it will find all of the parent delegations
(just like the specs say that servers should do), and it will find the two
matching parents that are in the database now. View the source to see how
this is done.

The purpose of this demonstration is to show that implementation is pretty
simple. I used off-the-shelf perl modules and an LDAP server bundled with
my mail server to implement this, and it took less than a week.

I'm trying to get somebody to help write the matching filters and syntaxes
code for openldap so that a more complete demonstration system can be put
together. Once I get another open of time, I'll also put together a web
front-end that will let people add/delete/modify entries in the back-end.
I'll advise if/when we get there.

disclaimer--This is very rough, slow, undebugged, all of that. I haven't
done any serious programming in over 10 years and my knuckles are rusty.
Please be gentle. :p

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

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Fri Jul 25 19:44:54 2003

on 7/25/2003 3:46 PM Eric A. Hall wrote:

> includes a text-based Perl client and an LDAP database, both of which
> are running on the test system.

Just in case this isn't clear, the client part is indeed separate from the
server part. You can download the client (using the "--source" switch) and
run it from your local workstation without modification; it will go find
the server and issue the queries, just like the hosted version is
currently doing. The demonstration just has the client on tcp/43 on that
particular server for ease-of-demonstration purposes, and there's nothing
about tcp/43 or that particular client that requires such.

---

From: leifj at it.su.se (Leif Johansson)
Date: Sat Jul 26 04:15:01 2003

>running on the test system.
<snip>

A couple of comments on the code ...

You should add version=>3 to your Net::LDAP->new - as it is you are using
LDAPv2 which is doesn't support controls so you will never receive a control
as the result of your bind from a typical ldap servers.

Now I haven't read the FIRS draft (yet) so I am only guessing that FIRS is
supposed to return a control on bind. However (apart from the fact that 
this
requires LDAPv3) the usual way to look for a supported control is to lookup
the root-DSE entry and look for the oid in the supportedControl attribute.
I am not sure if this is a critique of the code or of the draft though :-)

sub isFIRSServer()
{ 
   my $ldap = shift;
   my $res = 
$ldap->search(base=>'',filter=>'objectClass=*',scope=>'base',attrs=>'+');
   $res->code && die $res->error;
   my $e = $res->pop_entry();
   die "No root-DSE" unless $e;

   grep /^1.3.6.1.4.1.7161.1.0.0$/,$e->get_value('supportedControl');
}

       Cheers Leif

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Sat Jul 26 11:33:13 2003

on 7/26/2003 3:11 AM Leif Johansson wrote:

> You should add version=>3 to your Net::LDAP->new - as it is you are

doh!

fixed

> Now I haven't read the FIRS draft (yet) so I am only guessing that FIRS
> is supposed to return a control on bind. However (apart from the fact
> that this requires LDAPv3) the usual way to look for a supported
> control is to lookup the root-DSE entry and look for the oid in the
> supportedControl attribute. I am not sure if this is a critique of the
> code or of the draft though :-)

Yes, the server is supposed to return the firsVersion control on bind.
This is more-or-less modelled on the password-about-to-expire control,
which is an unsolicited server control that tells the client to change the
password immediately.

The control and the usage behavior are described in section 5.3.1 of
draft-ietf-crisp-firs-core-02 with supporting text in some of the
resource-specific documents. Essentially, the control lists the object
classes for the resource-types that the server fully supports. This
provides an easier way to do schema versioning, but it also enables some
distributed processing, in that the client can choose to implement the
necessary logic locally (emulate the matching filter, as in firs.pl) or
skip to the next server in the connection list.

I specifically want to avoid the extra round-trip time needed for an
explicit control query.

---

From: ehall at ehsco.com (Eric A. Hall)
Date: Sat Jul 26 12:03:01 2003

> I specifically want to avoid the extra round-trip time needed for an

Actually, an extra round-trip isn't too bad as a first-step recovery
effort. I've added some text to the draft so that if the server doesn't
automatically provide the control, have the client explicitly request it
just to double-check the server's capabilities before proceeding with
other recovery efforts. I'll add the code to firs.pl in the next window.

---

From: leifj at it.su.se (Leif Johansson)
Date: Sat Jul 26 13:53:39 2003

>other recovery efforts. I'll add the code to firs.pl in the next window.
I was just about to say the same. You should get the AD to arrange for a 
review
of the draft by the LDAP Directorate - imo it is good to have firs 
aligned with
common practice in the ldap community.

          MVH leifj