
\section{Introduction}

New networks are being created based on nodes communicating
at the link layer via wireless interfaces such as infrared, cellular radio,
and wireless lan radio.  Lan radio devices such as Lucent's
WaveLAN\footnote{They have a web page at http://www.wavelan.com}, 
are capable of broadcast and multicast similar to ethernet.   
Networks based on ethernet-like radio broadcast bring certain topological 
and security challenges with them not previously encountered with 
wired technologies.

Mobile-IP 
\cite{Perkins} specifies how end nodes may move across
IP subnets and retain an IP address, thus dealing with the problem
of how a Mobile host can move and retain a fixed IP identity.
Mobile-IP is a network-layer routing protocol.  It focuses on how
packets from Home (via the {\it Home Agent} or HA as a routing proxy) may be
forwarded to a {\it mobile node} or MN when it has wandered to foreign subnets.
One might claim that the Mobile-IP protocol is
focused on the network-layer only.  There is some focus on link-layer
concerns but for the most part Mobile-IP tries to deal with how
a mobile Node may wander from its subnet and yet retain IP unicast
connectivity.

A group of mobile systems, say laptops carried
by people from different organizations (with different IP subnets), might
show up for a face to face meeting in a hotel room, bar, 
business presentation, or lecture hall.  
Such a collection of systems should be able to talk to each other
sans network administration and without requiring a Mobile-IP
agent or normal IP router to be available.  We may call such a 
situation an {\it ad hoc network}.  Depending upon the size 
of the link-layer wireless
technology, the network might or might not need to span multiple hops.

In this paper
\footnote{ This work was supported by the U.S. Department of Defense
Advanced Research Projects Agency and the U.S. Air Force
Rome Laboratory under contract F30602-95-1-0046.}, 
we present an experimental ad hoc routing protocol
that is focused both on routing survivability on a multicast radio
link and on certain fundamental routing security issues.  The
protocol is integrated with Mobile-IP and is intended to be used
on links deemed to be fundamentally less secure than ethernet;
for example, lan radio links.  However the protocol could be used on
ethernet too if administrators felt the the ethernet link was
subject to physical compromise.  We address certain problems inherent
in both IP subnetting and radio link topologies by adopting 
the postulate {\it "I beacon, therefore I am"}.  In this system, 
we have enhanced the ICMP router discovery \cite{Deering} packets 
used in Mobile-IP
so that all nodes including both agents and mobile nodes
beacon. Thus any system can directly hear what other systems
are reachable.  This simple mechanism solves problems inherent in
IP subnets and allows ad hoc mobile nodes from different subnets
to communicate directly without agents or routers.

The protocol also deals with certain link-layer routing security
problems.  We have done away with ARP 
\cite{PlummerARP} and our beacons 
authenticate the MAC, IP address combination.  Thus we have 
made ARP spoofing more difficult.  It has long been observed in
network security circles that ARP may be easily spoofed
since one node may overwrite another node's (MAC address, IP address)
pairing in an ARP cache, replacing the spoofed system's MAC address
with the spoofer's MAC address.  Mobile nodes running our version
of Mobile-IP can use either our beaconing protocol, or they may choose to
still use ARP, depending on the link they are attached to (and the
type of network adapter they are using).  We provide a user interface
that does not make a dynamic decision to switch link-layer routing
protocols, but allows the user to learn the protocol in use
at a link.  The user can then decide the security policy he/she wishes 
to employ, and communicate this policy to the underlying system software.

Section 2 of our paper presents a discussion of background
issues and problems.  Section 3 presents our architectural solution.
Section 4 presents a security analysis of the solution.  In Sections
5 and 6 we present some operational details including a short
discussion of relevant aspects of our X user interface and some measurements of
the cost of authentication.  In section 7 we present final conclusions,
criticism, and discussion of possible future work.

