Len Rose <len @
COM> and Christopher Davis
com>, raised and explored a problem some users have
had with the link between Security Dynamics' ACE/Server
and the resolver in the SunOS 4.1.x shared libraries.
I regret that Mr. Rose did not find our support as informed as he (or
we) would like on this particularly problem. One of the awkward realities
of working in a multi-faceted market is that we sometimes learn of a
problem -- and often get a good idea of how to correct it -- directly from
customers who implement our SecurID technology in many rapidly
evolving technical environments.
In this case, SDI was not as careful as we will be in the future in
tracking the way changes in a host operating system can require a manual
reconfiguration of the ACE/Server's link to the image libraries. We regret
that we didn't recognized the problem earlier. In response to your
comments and an internal review of the problem, SDI is now:
* developing additions to our ACE/Server documentation which will
more clearly identify the link environment used by the ACE/Server.
* developing new documentation on the use of the ACE/Server with
NIS, NIS+, and BIND.
SDI's Development and Engineering staff is also investigating the
possibility of having SDI supply statically-linked images for the ACE
client/server implementations on SunOS. If this proves feasible, it
should deal with this problem completely.
In other postings, Greg Woods <woods @
edu and John R.
Deuel <johnd @
com> discussed a quite different problem: IP
naming conventions and the intimate issues of scaling that have
emerged as our customers link their ACE servers with multi-homed
Mr. Deuel demonstrated a sophisticated understanding of the
problem, which has to do with the difficult in maintaining a primary
linkage between the ACE/Server and the single IP address which is being
guarded by a now multi-homed firewall.
>The only workaround at present (aside from the type of thing Greg is
>doing) is to make sure that the software only ever sees one view of the
>topology. Say the hostname of your client is set to "foo", and the first
>address returned by a lookup on "foo" is A.B.C.D. For the ACE/Server &
>client to work, reverse-resolving A.B.C.D must generate "foo" as the
>first/official/canonical hostname, and this address must be assigned to
>the interface that is used to communicate to the aceserver. If traffic
>goes out to the server over a different interface, it won't work. Also,
>the ACE/Server needs to have the same type of relationship between its
>interface addresses and hostnames.
We realize that this is a real problem, but it is not a easy one to
address any time soon. We have begun to evaluate protocol options for
future ACE/Server-firewall connections that could work around the IP
address, but the solution -- if it must come from SDI -- will emerge only
in future ACE releases. We realize the attractiveness of multi-homed
firewalls, but the link between the IP address, and the authentication
server which controls access through it, is fundamental to our security
There are alternative architectures, and we could adopt them -- but
only after a truly significant test and development effort to guarantee
that we maintain the level of security our customers on this list, and
elsewhere, expect. There has never been a reported incident of a
Security Dynamic's ACE/Server being compromised, and we're a little
obsessed with maintaining that level of credibility as our SecurID technology
You run a great list, Mr. Chapman. Thank you.
Manager, ACE/Server Development
Security Dynamics, Inc.
Security Dynamics Inc. <<< sdi @
One Alewife Center, Cambridge, MA 02140 USA
US Tel: (800) SECURID or (617) 547-7820 Fax: (617) 354-8836
UK Tel: +44 1734 880246 UK Fax: +44 1734 885867