\section{Criticism and Conclusion}

In summary,  there are two important ideas in this paper.
One is that the MAC, IP address binding should be authenticated
in order to mitigate against spoofing attacks.  The other is that 
notions of subnetting at the link-layer need to be reconsidered. 

The physical security of radio links is harder to guarantee than
that of wired segments like ethernet.  Therefore we feel that the
MAC address portion should be authenticated along with its IP
address binding.  As a result, attacks akin to ARP spoofing and
certain denial of service attacks will be made more difficult and
hopefully not worthwhile.  Our protocol is one way this might be
done, but ARP itself might be authenticated on ethernet in a manner
similar to the way IPSEC authentication works with the IP protocol
itself.  What is needed is that the MAC address has to be made available
at at higher level in a packet.   This might be done in Mobile-IP
by placing the MAC address in the ICMP beacon as we have done or
it might also be placed in the UDP data payload of the Mobile-IP registration
packet where it would be authenticated by current Mobile-IP mechanisms.

We feel that mobile systems should use beaconing to
overcome certain link-layer routing problems caused by subnetting
and by the inherent non-transitive nature of lan radio.  
It is simply not reasonable to assume that ad hoc mobile nodes from different
IP subnets must have a router or agent to communicate.
Mobile links made up of technologies
like radio have their own problems and the notion that IP subnets
can define what is "here" and what is "there" is also not reasonable.
We propose a simple reachability mechanism as a solution, but there
might be other solutions.  Our proposal should not be regarded as an
attack on subnetting "in the large"; i.e., it has nothing to
do with the use of masks to define routing hierarchy.  We simply
point out that subnetting "in the small" cannot be used to determine
local reachability on a radio link.  Other mechanisms like ICMP
routing redirects also need to be reconsidered.

However there are two larger issues that we should discuss,
key management, and scalability.  

Our protocol could use a multicast key management protocol
on top of it, possibly along the lines of GKMP \cite{Harney}.  We are targeted
at lower-level mechanism and there is no reason why a 
higher-level multicast key management
protocol could not be used, if and when, there
is such a protocol with general acceptance in the IETF.   In the meantime,
we will assume "out of band" key distribution.  Our current system
can be enhanced to one agent, one key.   We also have the "ad hoc" key,
which can be generated with suitable carefully constructed software,
so that in a face to face situations, a short-lived meeting key
can be created, used, and thrown away.

Scalability is always an issue with routing protocols.  One must
ask how much beaconing a link can support and how much bandwidth
is lost?  Fundamentally it is hard to see how mobile systems can
avoid beaconing.  A system lacks any way to discern whether a target
is local or remote since subnet associations mean nothing.  It can
only decide to forward a packet to an agent or send it to a host
route that has appeared in the routing table due either to link
proximity (our protocol), by some higher ad hoc routing protocol, or
by human intervention.

The general question is this:
if we are sending packets to agents (assume the current agent is bound to
the default route), is there some way a system can discern who is local
and who is not?

Of course, one might look at the address and a priori know, but
that is exactly what is wrong with the subnetting assumption.
How do  you look at an address and know that someone is local?

In an Internet context, it does not seem reasonable that a system
should try local contact before remote contact.  Most likely
destinations are going to be remote (off-link, think about web
browsing).  If there was no such thing as a remote system, such an
assumption may be reasonable.  

If we assume we will use beaconing, we might ask if we can reduce
its cost?  As an obvious measure, from a policy point of
view, one might simply decide to not talk to other mobile nodes
and only talk to agents.  If this choice is made, our protocol
could be collapsed into Mobile-IP by having agents use it and by
adding an authenticated MAC address in the Mobile-IP UDP registration
message.   Agents would put their MAC address into an authenticated
ICMP packet (or UDP reply).  Mobile nodes could place their MAC
address in the UDP registration.  In effect, our current implementation
behaves along those lines as we push the authenticated beacon out
before the UDP registration (or de-registration) message sent by
mobile nodes.

As a very simple improvement, our mobile nodes beacon far more slowly than 
agents.  We also have an agent field in the authentication extension 
so that agents can quickly ignore MN beacons that are irrelevant to them.
Mobile nodes aren't currently that mobile.  They might move a few times
a day on the busiest day and are more likely to simply migrate from
office to home a couple of times a day.  As a result, slow beaconing
is satisfactory.

Other mechanisms to increase scalability could be tried as well.
At some future date, it is possible that 100 laptop equipped
students might attend the same lecture.  It should not be
difficult for mobile nodes to discern that they have a lot of peers,
and hence scale their own beacons back (presumably exponentially).

The most important consideration here is that mobile nodes really
need to maintain a connection to an agent.  Caceres \cite{Caceres}
has already suggested that agent beacons need to be faster for
quick mobile node handoff.  Agent beacons are more important than mobile
node beacons and represent an umbilical cord to the wired infrastructure.
Possibly if mobile nodes can't hear agents and can only hear mobile
nodes, they might (carefully) ask other mobile nodes which way it
is to the agent as well as scale back their own beacons to make
sure there is breathing room.  A higher level ad hoc routing protocol
or a multicast search mechanism could be employed for that purpose.
