\section {Solution Overview}

In this section, we will present an overview of how the ad hoc system 
operates.  

We have enhanced the ICMP Router Discovery packets (beacons) used
in Mobile-IP so that they contain MAC and IP addressing information,
and authentication similar in style to that currently used in
the UDP registration packets in Mobile-IP.  There are no other
packet exchanges in the protocol.  We assume that if you can hear
a beacon, you can talk to the sender.

The protocol is fundamentally multicast in outlook, since a beacon
may be addressed to either IP limited broadcast (255.255.255.255) or
to the multicast group 224.0.0.1.  All systems, either Mobile-IP
agent (HA/FA) or mobile nodes (MNs) will beacon at a certain
periodicity.  We are currently experimenting with agents beaconing
at the rate of 1/sec.  Our MNs beacon at a slower rate, say 5 or 10 
second intervals.
We assume that an interface is either ARP-capable or adhoc-capable.
A mobile agent typically will have an ARP-capable ethernet interface
and an ad hoc capable WaveLAN interface.  The MNs, of course, only
use the ad hoc system.  It is not desirable for security reasons
to mix ARP and adhoc on the same link.  

Beacons logically consist of the following headers:

\begin{tabbing}
123\=456\=789\=\kill
\>	(IP, ICMP, Mobile-IP extension, optional MAC, \\
\>\>		optional location, optional network authentication, \\ 
\>\>		extremely optional ad hoc authentication) \\
\end{tabbing}

If a link is ad hoc, beacons sent on it must contain the MAC
portion, and at least one authentication suffix, which must come last.  
Both MAC and IP addresses must come before all authentication headers,  
else they would not be authenticated.
The IP address itself is in the ICMP portion.
We will discuss the authentication headers more below.

An optional information string may be provided.  Our agents currently
state where they are, along the lines of "Bridgeport: PCAT room 128C".
Mobile nodes might state their user's email address or might simply not use 
this facilty at all if privacy is desired.
Location information is displayed in our X user interface for laptops
and allows a user to easily discern the current Mobile-IP agent's name
and location.

One or two authentication extensions must complete a packet.  
Our authentication mechanism here is analogous to the Mobile-IP authentication
mechanisms; i.e, we authenticate via a shared secret based on a
MAC algorithm (currently MD5, but there is a SPI (Security Parameter Index)
in the authentication
extension, and the algorithm in use could of course be changed).
We will discuss the authentication header more below, but for now
there are several important points that need to be made:  
\begin{itemize}
\item
Note that we are essentially associating a secret 
key with a link.  Key distribution is currently "out of band"
(a priori distributed) and as a software problem falls in
with the general problem of multicast key distribution.
\item
The authenticated information logically includes at 
least the following information: 
\begin{verbatim} 
	(ip address, MAC address, a few other items)
\end{verbatim}
The authentication
is done over the ICMP header (where the IP address is), and all
higher headers up to and including the SPI in the authentication
extension.  System "names" (addresses) are authenticated.
\item
There are at least two possible keys that may be concatenated.  
Each may be thought to be paired with a logical link.
\end{itemize}

Any agent (FA or HA) or mobile node that belongs to the same logical link
define themselves in terms of a fundamental network authentication
extension via one or more shared keys.  For now, assume one key
for the links at a given site.  We call that key the 
{\it network authentication key}.  Since one can easily argue, 
that the more a key is used, the less secret it is, we point out 
that each agent at a site might have its own key.  
In that case, the MNs would be expected to know
a list of such {\it network authentication} keys.  A second ad hoc key
may be generated on the spot and given away for a brief period for
face to face meetings between end systems from different sites.
For example, the key might be generated via a shared passphrase
fed to MD5 when visitors come to your site or when your laptop has
a face to face rendezvous with some other laptop anywhere.  
We call this the {\it ad hoc} key.  This
key exists primarily so that no user ever gives away the site
{\it network authentication} keys.  Depending on the user interface policy
setup, beacons are accepted if either key is successfully authenticated.
This allows MNs that are at home to speak to the ad hoc systems
(the visitors) directly and retain their own current agent connection.
It also allows a site manager to teach a FA about the ad hoc key
for the duration of a meeting, thus visitors may (or may not) be allowed 
controlled access to the Internet.  Further, a site manager would not have to 
give a visitor a local network key that was in use by others, thus
compromising the link.  

In order to maintain compatibility with Mobile-IP, our agents and
mobile nodes are capable of acting in two link modes.  We call one
mode "ARP" and the other "ad hoc".  "ARP" mode means whatever
Mobile-IP specifies for correct mobile node behavior with ARP.  
Users will get information based on beacon inspection
from our user interface about what kind of links (agents) they are visiting,
and can instruct their laptop to move from one mode to another
by clicking on a button.  This is a
high-level security policy decision.  A user configured with our
ad hoc link system might choose to not speak ARP for security
reasons, but we have decided to allow them to make that choice.
The system itself will not dynamically switch from one mode to
the other.  Agents are presumably configured beforehand and can either 
use (Mobile-IP style) ARP or run with the ad hoc beaconing system.

Our mobile nodes send a beacon out in front of the UDP Mobile-IP
registration.  As a result, they can beacon more slowly if one
feels that mobile node to mobile node interaction is not very likely.

The use of beacons as outlined above solves a number of routing problems.
MNs that do not share
a common subnet can now communicate directly sans router or agent.
If you can hear a system (and you share a key), you
can install a link-layer route for the other system.  
As another example, two systems
that cannot hear each other directly but are present at a cooperating
Foreign Agent, will simply route through the Foreign Agent because
link-layer routes will be present in the FA's routing table.
If those systems used ARP in the classic sense and did not share
a subnet association, they would be able to talk, but their packets
(sans a routing optimization not currently present in IPv4) 
would have to go the Mobile-IP Home Agent before returning to the FA.

Due to the previously mentioned ARP/subnet semantic, we can also cleanly
heal certain problems that the Mobile-IP specification cannot (but
in fairness, could claim is a link-layer/routing implementation
problem).  For example, when we use ARP paired with
the clone route in our FreeBSD systems,
two laptops that share a common subnet cannot talk to each other
when they are both at different Foreign Agents.  This problem exists
because the per link clone route on each box causes them
to assume that their peer is local.
Since both systems at both FAs exhibit such behavior, even if
one system behaved correctly, two-way communication would still fail.
With our ad hoc scheme, they won't use the clone route (or ARP) and will
know that the peer is not local, as there won't be local link routes
in the routing table.  As a result, thanks to Mobile-IP,
packets will be correctly forwarded to the 
agents and the systems will be able to communicate.
