\section {Security Analysis}

In this section we will show our authentication header
packet format and briefly discuss various link-layer threats and associated
defence mechanisms.

The header format is roughly:

\begin{center}
\begin{tabular}{|l|l|l|}\hline
size & name & info \\ \hline
byte & tag & this is an authentication header \\ \hline
byte & len & size in bytes \\ \hline
byte & flags & type of authentication, network or ad hoc \\ \hline
byte & pad & zero \\ \hline
long & seconds & NTP time in seconds \\ \hline
long & fractions & NPT time in fractional seconds \\ \hline
long & agent & agent IP address for mobile node \\ \hline
long & spi & Security Parameter Index (type of MAC algorithm used) \\ \hline
byte & hash[16] & MAC checksum (for example, MD5) \\ \hline
\end{tabular}
\end{center}

The flags field tells the listener whether the authentication suffix
is of the "network authentication" or "ad hoc" type.  The agent IP address
field is set to 0 by agents and to a current IP address for an agent by a Mobile
Node.  This is an optimization that allows agents to quickly discard
beacons that are not for them, before they authenticate the beacon.
The 64-bit NTP portion includes both seconds and fractional seconds.
We will discuss its function below in reference to replay attacks.
The security parameter index specifies which MAC algorithm is used
for the authentication checksum and the hash itself contains the
checksum.
	
There are at least four threats that are addressed here:
\begin{enumerate}
\item
ARP spoofing in the active sense; i.e., a spoofing system
steals the IP address of another system by sending fake ARP messages.
With traditional ARP spoofing, the spoofer changes its IP address
and retains its MAC address.  
\item
denial of service due to loss of a link-layer route courtesy of an
ARP spoof.
\item
denial of service due to unauthenticated ICMP beacons sent by
a fake agent.  This is more dangerous in a radio topology if handoff
mechanisms (like our current Mobile-IP handoff mechanism) are based on signal
strength.
\item
the possibility that a user might due to frustration decide
to give away the network authentication key.   This is why we want to
emphasize and make available a key that can be easily manufactured,
destroyed, and given away in short term face to face situations.
In such a scenario, laptops from different domains may be present and all 
may be disconnected from the Internet.
\end{enumerate}
Cases 1 and 4 are probably the most important cases that need to be
considered.  Case 2 is an outgrowth of case 1.  Case 3 
is a very real possibility and should not be considered unimportant.   
For case 3, our beacons are authenticated, and the MAC address is pushed
up high enough to be covered by the authentication.  
We have also introduced some simple replay protection 
mechanisms that do not make replay impossible,
but do make it more difficult.  We will come back to case 3.

Without explaining exactly how to do this, (although we fear the
mechanism is all too obvious), we have "successfully" performed an
ARP spoof at a Foreign Agent.  One mobile node (the attacker) overwrote the
ARP cache for another system (the victim) at a Foreign Agent.  The
result was that the attacker, which assumed the IP address of
the innocent node, was able to steal both the link layer routing
entry and the tunnel between the Home Agent and the Foreign Agent.
As a result, without running Mobile-IP, the attacking system was
able to use the victim's Mobile-IP setup.  The only Mobile-IP
attribute that the attacking system needed was the ability to bind
the default route to a agent not on its subnet.  Of course, at a
Home Agent the attacker would not need that ability, but at home,
the scenario is exactly equivalent to traditional ARP spoofing.
On a radio link, it is further possible that an ARP cache re-write
at the agent might not be detectable by the victim, 
due to the non-transitive nature of the radio link topology 
we discussed earlier.  Possibly, something even
worse might be accomplished, as there might be a way for an attacker
to feed the Mobile-IP UDP reply packets returning from the HA back
to the victim and thus keep the Mobile-IP connection fresh.

We suggest that ARP is not a very good foundation for Mobile-IP,
especially on radio links where a radio cell might easily extend
outside buildings, even to passing vehicles.  Mobile-IP has decent
mechanisms for authentication of its UDP control messages including
replay prevention.  However we hijacked an authenticated MN/HA UDP
Mobile-IP connection.  Further if there had been authentication
between the mobile node and the Foreign Agent, it would not have
mattered.  Mobile-IP authentication mechanisms only apply currently
to its UDP control packets (registration/reply).  We might judge
the hijacking of such a Mobile-IP connection to be a more serious
breach than a traditional ARP spoof, since we highjacked an
authenticated tunnel.

One might think that ARP over ethernet is fine since
ethernet links are (maybe) more subject to physical control 
than radio links.  Under certain circumstances, this idea may very well
be an illusion.  There is nothing to prevent our authenticated
beacons from being used on ethernet too.  

IPSEC\cite{Atkinson1} (IETF proposed network layer security) can be used to
authenticate and encrypt ordinary data traffic, or new applications
like {\it ssh/slogin} might be used for authenticated and encrypted TCP
sessions.  However neither Mobile-IP or IPSEC address ARP as a
protocol.  Use of IPSEC could reduce such a highjacking to simple denial
of service (we hope).  However our protocol could prevent a 
denial of service attack base on loss of link-layer routing or at least make
it more difficult.

The use of authenticated MAC and IP addresses changes the playing
field for spoofing.  An attacking system that hopes to appear
as a victim, must now spoof both the
MAC address and IP address.  Certainly some lan controllers have
programmable MAC addresses and it is possible to adapt some other
system's MAC address.  Note however that
since the attacker intends to use the MAC address of the victim,
the victim may possibly see returning packets (or all packets) due to the
shared unicast MAC address.  For example, think again about our
radio setup with the three systems, A, B (FA), and C.  If A spoofs
C, C might not be able to see A's packets.  However packets returning
from B to A would be seen by C because A and C would have the
same unicast MAC address.  C therefore has an opportunity
that it would not have had with a simple ARP/IP spoof, where the
attacker's MAC address is different.  If A starts a TCP connection,
C might issue a TCP reset against it.  In general, C should be "alert" 
and notice anything peculiar going on at the link.  
It should note use of its own MAC address elsewhere.  It would
be useful to have a user interface that informs the user about network stack
security events of interest including packets with your own MAC
address, TCP resets, UDP ICMP "no such port" 
reachability errors and the like.  

On the other hand, an attacker might simply be passive, listen,
and do traffic analysis.  This may be more useful and simpler than
going to the trouble of reprogramming ones MAC interface address.
IPSEC's  encryption mechanisms or higher-level application encryption
would address such a threat.  IPSEC provides network and transport
authentication, encryption, issues and we feel that our ad hoc
mechanism is complimentary with IPSEC.  An authenticated ad hoc
link-layer routing  protocol coupled with IPSEC mechanisms between
MN and HA may be said to form the "moat" and "castle wall" of a
more secure roaming node.

One question remains and that is what if anything should
be done about possible replay attacks?  What if an attacker soaks
up your link-layer authenticated beacon at one FA and goes to
another and plays it back?  In this case, the victim would not be
present to notice what is going on.  Possibly replay attacks are
a higher level problem and we should not worry about them here.
After all, all you gain is a route in either a mobile node or agent.
However, we have ruled replay attacks out at agents due to careful
implementation.  Our agents will not install the link-layer route
(at either HA or FA), until the Mobile-IP UDP registration packet
returns successfully.  This means that an attacker must also
minimally successfully breach at least the MN/HA Mobile-IP security
relationship.  Thus at agents, we are taking advantage of
Mobile-IP replay protection and authentication.  The remaining
question may be reduced to what, if anything should be done about
MN to MN relations?  We have experimentally specified a 64-bit NTP timestamp as
part of the protocol.  We want the mechanism to have sub-second
granularity in case fast handoff is an issue.  However for now
we are limiting our mobile node implementation to simply check
the timestamp issued to make sure that it is increasing, and to not
compare it with an inner clock.  This is a weaker implementation choice,
and does not rule out a stronger time check, when and if a mobile
node has a distributed source of time it can trust.  In effect,
the timestamp is simply a nonce, but a nonce that does not have
to be saved over a reboot.  Also it does make replay of authenticated
beacons somewhat harder since a set of beacons must be recorded and
played back in order to make the attack.
