Subject: [dhcwg] Proposal for experimental DHCP option

From: "Giuseppe Paternò (Gippa)" <[email-masked]>
Date: Mon, 23 Oct 2006 17:02:56 +0200

Dear working group,
I wrote an I-D describing an experimental DHCP option for LDAP service
discovery and I wish to submit to your attention:

ftp://ftp.rfc-editor.org/internet-drafts/draft-gpaterno-dhcp-ldap-03.txt

Any suggestion is appreciated.
Thank you.
Regards,
   Giuseppe Paterno'

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Oct 2006 11:24:37 +0200

> Any suggestion is appreciated.

My first thought before reading the draft, was that you could just use 
DNS SRV. I agree though, as you stated in the draft, that it may be
problematic to locate the closest replica.

Have you discussed this issue with other LDAP people? It would be
interesting to hear what people think at the LDAP list at umich, or
I believe ldapext and ldapbis wg mailing lists might still exist...

Stig

---

From: "Giuseppe Paternò (Gippa)" <[email-masked]>
Date: Tue, 24 Oct 2006 13:16:28 +0200

Sorry, I forgot to include in CC the working group. My apologies.
  Giuseppe

---------- Forwarded message ----------
From: Giuseppe Paternò (Gippa) <[email-masked]>
Date: Oct 24, 2006 1:15 PM
Subject: Re: [dhcwg] Proposal for experimental DHCP option
To: Stig Venaas <[email-masked]>

Dear Stig,

first of all thank you for your attention. It's the first time I
interact with an IESG working group,so I please the group forgive me
if I make some mistake.

You pointed out exactly the main reason why I wrote the I-D: locate
the closest replica that fit the "network". It's basically the same
problem of specifying DNS: you might decide that a given site, or even
subnet, has a totally different DNS. As for that, you can decide that
this or that subnet has a different LDAP server (you can have several
reasons for that).

Before posting the draft, I exchanged a lot of email and talked over
IRC with an internal group of the company I work for (Red Hat):
they're basically former netscape people (that  came in with the AOL
acquisition). Please note that I'm not writing on behalf of Red Hat. I
wrote as indipendant, this has been done on non-working time. I also
talked to some OpenLDAP developers: I wasn't aware of an LDAP working
group in IESG ...

I evaluated with them the DNS SRV option, but it is not always the
best. If you have a global flat DNS, you cannot distinguish what is
the local replica: look at Active Directory for example, that do more
or less the same thing. The LDAP client would go round-robin through
the DNS SRV records. Yes, you could split the DNS in geographical
region, eg: Italy. But, again on the example, Milan and Rome offices
might have a local LDAP replica.

That come in the DHCP option: it gives you the flexibility of
automatically configure the client  for LDAP queries and to choose the
best LDAP server as decided by the network admin (say the closest or
the best one).

The draft you saw came from the discussion with our internal LDAP team
and some OpenLDAP developers: I initially wrote a draft in which two
options were defined. One for a list of IPs (such as DNS) and one of
the Base DN. (I attached it in this mail for reference). Both teams
preferred the LDAP URI as they said it gives you more flexibility in
terms of LDAP options (such as port, TLS, ....). And that's true. The
only concern I have is that you can specify only one ldap server,
while it would be great to have a secondary choice. On this concern,
they replied that most of the customers have a load balancers for
multiple LDAPs or an HA solution, but I'm still not 100% sure...

Any hits/concerns/help/suggestion is appreciated!!
Regards,

  Giuseppe

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Oct 2006 14:23:49 +0200

Giuseppe,

I read your draft, and I have two lingering questions about the 
applicability of the options in question.  First, from a security point 
of view, I wonder whether simply referring to LDAPS is enough.  After 
all, if I'm a rogue DHCP server, I'm going to hand you an address of an 
LDAP server.  What additional real effort is it for me to get a certificate?

But beyond this, I wonder whether you are running into a conflict 
between locality of service and what data would be returned.  Consider 
the case where you take your laptop or PDA on the road.  Do you want to 
vary your directory service based on where you are plugged in?  Would 
you want to make use of Cisco's directory service when you are on 
Cisco's network and Sun's when you are on Sun's?  In other words I 
believe you may want the best value for a /particular/ LDAP service you 
want to reach and not just /any/ LDAP server.

Eliot

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Oct 2006 14:44:40 +0200

> LDAP server.  What additional real effort is it for me to get a certificate?

I believe there are ways to do this (e.g. clients may require server
certificate signed by some specific CA), but as you say, just ldaps 
itself is not enough.

> want to reach and not just /any/ LDAP server.

Another problem I see, is that you may have several LDAP servers where
which one to contact may depend on what information you're looking for.

An alternative solution might be that the LDAP server you contact
could give you a referral to a replica closer to you. In that case it 
doesn't matter if you initially contact a more remote one.

We need to find some LDAP people to look into this I think. I've asked
a certain person that knows LDAP very well if he has any thoughts. I'm
trying to think where else this could be considered.

Stig

> 
> Eliot
> 
> 
> ------------------------------------------------------------------------
>

---

From: "Giuseppe Paternò (Gippa)" <[email-masked]>
Date: Tue, 24 Oct 2006 18:53:41 +0200

Hi everybody!

> certificate signed by some specific CA), but as you say, just ldaps

Yes, LDAPS itself cannot be enough: I can forge whatever certificate on server.
What you should implement (but I left it open) is to have a mutual
authentication.
You can, for example:
1) Provide kerberos tickets for the machine itself (laptop, ...)
2) Provide client X.509 certificate
3) Provide user authentication (that might be cached at logon)
4) ..... (whatever)

I left it open because you might want -for example- to give e-mail
addressbook for those not authenticated to the directory.

> > want to reach and not just /any/ LDAP server.

You do not need to do that: I mean, this is client implementation on
its behaviour.
What's wrong in receiving LDAP directory information while in Sun? It
is in charge of sun-ds.holland (for example) to decide what privileges
you have. sun-ds can also "chain" other directories (referrals) such
as it happens in DNS.
However I believe it is a client implementation that should decide how
to handle that information: I was working on a reference
implementation of dhclient that leaves this info in /etc/ldap.dhcp so
each application can choose to take into consideration the file or
not.

I'm in this situation, I'll provide as an example: I'm an admin of an
organization of 100.000 desktops plus 50.000 roaming laptops. How
should I configure automatically each laptop to find the closest ldap
replica, without forcing to query the LDAP of its country ?

> trying to think where else this could be considered.

For sure! I'm not saying it's the best solution for all the problems,
but it's an issue I'd wish to address.
Thank you so much!
Regards,

   Giuseppe

---

From: Eliot Lear <[email-masked]>
Date: Tue, 24 Oct 2006 22:37:56 +0200

Giuseppe,
> What's wrong in receiving LDAP directory information while in Sun?
Because (a) I might not be entitled to it and (b) I might only want the 
LDAP information I was previously getting for my own company or service, 
especially with certain mailers that entirely hide the email address and 
only list display names.  So put yourself in the place of an OS vendor.  
What should the default be?  To take the information or not?  If you 
take it perhaps something gets misdirected.  If you don't take it, then 
the administrator has to touch the device anyway for bootstrap, in which 
case the problem is different.

> replica, without forcing to query the LDAP of its country ?
I am sympathetic to your point.  The reason I didn't recommend a 
different approach was because I don't know of one that exists that 
scales to the size of the Internet.

Eliot

---

From: Stig Venaas <[email-masked]>
Date: Tue, 24 Oct 2006 22:00:42 +0100

> scales to the size of the Internet.

I'm not exactly sure what the scenario is, but the idea is that the
organisation has several sites around the world, a laptop is visiting
one of these sites and should use the organisations closest LDAP server?
I'm assuming it is at one of the sites, else I don't see how DHCP could
be used to tell you what LDAP server to use.

First thing that comes to my mind is to use SRV based on the laptop's
domain name unless configured otherwise. Assuming DNS responds the same
independent of where you are, I see two options.

One is as I mentioned, that you contact one of the replicas listed in
the SRV, and that it might give you an LDAP referral to a more
appropriate replica based on your address.

Another approach might be to use anycast. Have all the replicas share an
address (in addition to having unique addresses), and make sure that at
all locations, there is always exactly one that is the closest
(according to your routing).

Stig