\section{X User Interface - Security Aspects}

We have implemented an X-based graphical user interface tool that provides
both mobile node status information and control over the underlying
system software.  It includes several panels that are
focused on security.   Please refer to Figure 2.
\begin{figure} [h]
\begin{center}
\mbox{\psfig{figure=/netauth.ps}}
\caption{Link Authentication Panel}
\end{center}
\end{figure}
It shows the panel that provides
high-level security policy information and status indicators about
current link security.   One may choose ARP (in Mobile-IP terms)
or ad hoc modes.  If a system is in ad hoc mode, agents
and mobile nodes are ignored if packets are lack authentication
or the authentication fails; i.e., routes will not be installed.

If one chooses ad hoc security,  it is necessary to have 1 or more
keys in place and the keys must a priori be in place on
other systems.  For the ad hoc choice,  on a per key type basis,
one can choose to totally accept or reject beacons that use those
keys.  In this mode a system might be configured to accept beacons
authenticated with the {\it net authentication} key and reject any
beacons that show up with the {\it ad hoc authentication} key.  Elsewhere in
a part of the interface that is not pictured, the user can generate an ad
hoc key via a face to face passphrase fed to the MAC algorithm.
The passphrase is used to generate a shared key.  For example, a 
professor could write the passphrase on a blackboard and the
students might install it.  The
ad hoc users would then change the ad hoc policy to accept such
authenticated beacons for the
duration of a meeting, and then change the policy to rejec them when the
meeting was over.  

Various "dumb lights" exist that attempt to
communicate the link status in terms of authentication to the user.
The valid light shows the arrival of correct beacons (actually
slower than they arrive) and if it isn't blinking, the user knows
that there are either no agents nearby or there is a link problem
of some sort.  The various other lights allow the user to tell 
if authenticated beacons are present
(or not present) or if certain gross errors exist (key failures).
