I've already posted a ballot to Tony, but I didn't post it to the list.

I DO believe DHCP would be an important addition to the HP 3000, but I see
it as an important addition because of the needs of a specific (and rather
large) customer - the US Navy.  Security is important to the Navy, and
audit trails tend to be long and detailed.

The Navy project I deal with has been involved in a security related DHCP
battle for about a year now.  When all devices accessing the HP 3000s were
connected to a *private* network, one set of security and audit trail rules
applied.  Once field sites started having internet access, or access
between the HP 3000 LANs and the base LANs, the rules (and thus, security
requirements) became more strict.  Basically, if the network is private,
the security (and audit trail) requirements are not as strict as they are
if your hosts are connected to the internet - and the assumption is that
someone CAN and WILL get through your firewall.

But access from the internet is just one problem, and really has very
little to do with DHCP.  DHCP mainly becomes an issue because of
unauthorized access by a user connected to a Navy LAN.

This makes DHCP is a MAJOR security concern.  To comply with *THE LAW* you
must be able to collect and maintain a detailed audit trail.  In the old
days each terminal had a LDEV number that was fixed.  Then there were DTCs
and while the data moving between the DTC and the HP 3000 moved across the
network, the user activity could still be nailed to a specific LDEV.  DHCP
broke all the rules.

<Begin RANT>
With DHCP you fail to meet the test of being able to *from the HP 3000*
(the host system) be able to "immediately and at all times know the
specific device" (and location of that device) "that is accessing the host"
(HP 3000) "from the host" (HP 3000).  Once again, in the old days there
were databases which mapped LDEV number to site, building, floor, wing,
room, seat, user name, and phone number of user.  With DHCP running on
another box, this is no longer possible.  DHCP becomes a major problem and
concern because the IP lease information is logged to a file on the DHCP
server, and thus, is not (as required) a part of the logs maintained on the
host (the HP 3000), is not threaded in the HP 3000 logs along with the
system and application information, and not immediately available from the
HP 3000.

Basically, data extracted from the system logs, NM logs, application logs,
and logs created by a logon UDC barely cover the requirements if static IP
addresses are used, but just won't cover the legal requirements if DHCP is
used and the DHCP leases are not directly and immediately logged to the HP
3000, preferably in the system log files or NM log files.

Periodic copying of the DHCP logs to the HP 3000 was proposed (once every
five minutes), but it failed several of the audit tests (sorry, can't
disclose the details).

Long lease times have been used, but because of the time lag between when
the lease was issued and when the lease information was posted on the HP
3000, that approach also failed audit approval.

Infinite leases (an NT DHCP setting) were also ruled out, for the same reason.

So, at present, DHCP cannot be used with any device connecting to the HP
3000, and still have the application pass the security and audit
requirements.  As a result, they must use static IP addresses on all PCs
connecting to the HP 3000s.  As you can imagine, this means that they eat
up many, many, many, many IP addresses -- far more than would be needed
with DHCP.  ...and they have just about exhausted all their class C addresses.

This means that non-HP 3000 platforms which "can do it all, including DHCP"
have an advantage over the HP 3000.

Having DHCP on the HP 3000 then becomes a competative issue.  To be able to
meet the security requirements and not keep eating up class C addresses,
the applications either 1) have to run on a non-HP 3000 platform which
itself provides DHCP services and can log the lease information, or 2) run
on an HP 3000 which itself runs DHCP server software and logs lease
information to either the system logs or the NM logs.

What needs to be logged?  Mostly just the obvious.  IP address issued,
hardware address to which IP was issed, workstation name, date/time lease
issued, date/time lease extended, date/time lease terminated, duration of
lease, address collision information, etc.
</RANT>

<changing subject somewhat, beginning new RANT>
Enough on DHCP, but it brings up one major audit trail problem the HP 3000
has, particularly when Telnet is used.  The HP 3000 system log files still
track LDEV numbers, which with the exception of the system console, the
remote support port, and terminals connected to a DTC, are useless for
audit trail purposes.

When NSVT connections are made, and the user logs on, CI variables are set
up which contain the IP address of the session's client, and the
workstation name of the session's client (HPSTDIN_NETWORK_ADDR and
HPSTDIN_NETWORK_NODE).  This information *SHOULD* be logged in the system
log files.

When a client FAILS to connect - for any reason (no such user, no such
account, bad password, etc.) - the IP address and workstation name of the
clent which made the attempt *SHOULD* be included in the console log record.

Since Telnet doesn't provide the workstation name and NSVT does, the system
manager can (and should) disable Telnet if an audit trail is required
(Telnet only provides HPREMIPADDR).  Using only NSVT partially gets around
the problems of an audit trail for DHCP, but is not a viable solution, and
won't be a viable solution until failed login attempts log both the IP
address and workstation name to the system log files.

Also, programmatic sessions initiated via RPM should have their origin
logged (IP address and workstation name), whether the origin is the same HP
3000 or an HP 3000 somewhere, in a network, far, far away.
</RANT>

John
--------------------------------------------------------------
John Korb                            email: [log in to unmask]
Innovative Software Solutions, Inc.

The thoughts, comments, and opinions expressed herein are mine
and do not reflect those of my employer(s), or anyone else.