[evla-sw-discuss] An "In Use" flag for the MIB interface

[Bill Sahr]

The "In use" flag, a proposal:

The idea of implementing an "in use" flag as a part of the MIB
framework software has been around for years.  Hichem, with
consultation from Barry, has developed a proposal for the
functionality and implementation of such a flag.  The proposal
is presented below.  We would like comments.  Please either post
your comments to evla-sw-discuss, &/or send them by email directly
to me (bsahr at nrao.edu) or Hichem (hbenfrej at nrao.edu).  The comment
period will be considered to be closed 1 week from the date of
posting, - on Tue 8/22/2006.

Thank you.

Purpose
-------
The purpose of the "in use" flag will be to prevent accidental
interference with an observation.  For the sake of simplicity and to
provide a backdoor to break locks that were left set by mistake or
misadventure, the term "accidental interference" has been defined
to mean interference by the appearance of conflicting commands on
the MIB UDP server port. (This definition would include the device
browser, which uses the UDP port.)

The telnet port into a MIB will _not_ honor the "in use" flag.  That
such will be the case does mean that a person or program can log into
the telnet port of a MIB and  send commands that could interfere with
an observation.  It is felt that 1) use of the telnet port during an
observations is sufficiently rare to justify this risk, and 2) the
protection that is provided is still worth the time & trouble needed
to implement it.

Please keep in mind that the purpose of the "in use" flag is to prevent
accidental interference.  It is not intended to deter malicious attacks.

Details
-------
- The network binary representation of the sender IP address will be
used as the password for the lock.  The password can, therefore, be
obtained directly from the UDP packet containing the command to set
the lock with no need to hardcode or prompt for a password.

- Two monitor points will be associated with the lock: 1 to report
the status of the lock and 1 containing the password.  That there
will be a monitor point containing the password means 1) it will
be possible to determine the system from which the set lock command
was sent, and 2) the password is in no way "secret".  However, to
use the password to unset the lock, one would have to send the
unlock command from the same system or go to the time & trouble
to falsify an ethernet packet.

- One command with 1 parameter will be used to set and unset the lock.
The value of the parameter determines if the lock is to be set or unset.
Of course, a request received via the UDP port to unset the lock is
honored only if it originates from the IP address (password) that sent
the request to set the lock.

- Since the telnet port does not honor the "in use" flag, it will be
possible to telnet into a MIB and then issue the command to unset a
lock.

- Once a MIB is locked, any set commands received via the UDP port
that do not originate from the IP address used to set the lock will
be ignored.  However, get commands received via the UDP port will
be processed regardless of the originating IP address or the state
of the lock.

- On reboot, the MIB will initialize in the unlocked state.

- The analogous statements apply for the virtual antennas presented
by the CMP:
   - A given DCS number will be locked by the command used to set a
     lock and the originating IP address will be be the password.
   - Once locked, a given DCS number will accept set commands only
     from the locking IP address.
   - A locked DCS number will ignore the lock state for get commands.
   - The telnet port associated with a DCS# will ignore the state of
     the "in use" flag
   - On reboot of the CMP, all DCS#s (VLA virtual antennas) will be
     in the unlocked state.

Discussion
----------
Using the caller IP address as the password allows the "in use" flag
to be implemented with minimal changes to the MIB/CMP code.  Every
incoming TCP/IP or UDP packet embeds the IP address of the sender.
If the "in use" flag is set, the MIB/CMP will compare the originating
IP address stored in the packet to the IP address saved as the
password.  There is no need to change the command/message format.

This change will require that all MIBs currently in the field eventually
be updated with a new image that supports the "in use" flag.

The MIB _device_ that is a part of every MIB will be locked along with
all other devices in a locked MIB.  This characteristic has the dual
advantage of simplifying the implementation and preventing reboots
triggered from a source other than the lock originator.  That the
telnet port does not honor the "in use" flag still allows breaking a
lock or requesting a reboot via that path.

Any application that locks through a servlet or applet is not guaranteed
to have exclusive use of a lock because all other applications going
through the same servlet or application will be seen as having set the
lock, i.e., will have the same originator IP address (the password).