Non-STOP PKI, Non-STOP LDAP and other security issues

[Chris Wright]

Dominique Chabord wrote:
> Alan:
> I got an answer from Derek about LDAP servers 
> synchronization. I understand
> from Derek that LDAP usually integrates its replication mechanisms and
> doesn't need to swap disks. Therefore it doesn't need drbd 
> nor journalized
> file system. Do you mean it does need them ? Does it depend 
> on the product
> we use or is it part of LDAP standard ? From other sources, I 
> thought LDAP
> could even be parallelised, avoiding failover mechanism as 
> heartbeat. Is
> this mode recommended in secured environments when secret 
> keys are written
> in LDAP directory ?
> 
> Derek:
> Can we have several replicated copies of LDAP data ? for 
> example two local
> copies for high availability inside a site and another two copies in a
> remote mirror site ? Is it as safe against hackers when data 
> are replicated
> as when they are kept private on a local disk ? Is 
> replication encrypted ?

LDAP provides slurpd (an adjunct to slapd) which does the data replication.
AFAIK, slapd on the machine configured to be the master basically copies
modify commands to a replication file (after they have been successfully
completed on the master) which in turn is read by slurpd.  slurpd then
connects to slapd on the replica host and issues the same LDAP modify
commands.  The modify commands require authentication, either simple
password (cleartext) or kerberos.  The data is ASN.1 encoded.  The RFC (2251
- LDAPv3) does not call out any encryption, but does allow for SASL (RFC
2222).  You could always create a secure VPN between the master and the
replica to secure this data.  In theory, being an LDAP server means lots of
reads and few writes, so it seems like slurpd would suffice.

I too am curious to understand the failover/load balance portion of the
equation.  I believe the Netscape LDAP client will allow a list of servers
and try to connect to each server until one answers.  So you do not
necessarily need a concept of failover here, just a couple replicas -- you
can have more than one -- which slurpd will take care of for you.  Granted,
this is a little slow because you have to wait for timeouts instead of just
having the IP address automagically migrate to the active server.  I do not
know if all LDAP clients behave this way??  Let me know what you find ;-)

LDAP uses TCP, and requires authentication, so a failover mechanism would
mean you lose all active connections (they wouldn't transparently migrate to
the new server).  With this in mind, it isn't clear that a failover
mechanism would buy you much more than the already existing replica scheme
except connection speed (assuming your client already knows to try another
server if the first one doesn't answer).

"load balancing" is done via referral.  You contact a master server and get
a referral server as a response to your query.  This means you still need to
be able to make contact with a server that can give you the referral (the
referral may be a list of LDAP servers, not just one).  This is an area that
seems like it could get REALLY slow in the event of a failure.  For example
you timeout on the connection to the first server, then finally get
connected to a server only to get a referral list.  Then (perhaps the
failure was a router leaving more than one machine unavailable) you have to
wait through some more timeouts trying to find a referral server that will
actually answer your query. 

> Another point I have in mind is IP failover. Are there some 
> secured routers
> that might control MAC addresses and refuse "floating" IP 
> addresses in order
> to protect against a potential attack by IP redirection ? 
> Would this prevent
> heartbeat to failover ? Would it then support a list of 
> backup MAC addresses
> ?

I don't know of such a feature in a router.  It would be really interesting
because most HA solutions rely on IP address migration.  Typically this
includes a gratuitous ARP from the new server that took over the IP address
to keep ARP caches up-to-date.  If a router thought that this new address
was an attempt at highjacking the connection, then these HA solutions would
not work!  Let me know if you find such a feature.

cheers,
-chris