Secure Candidate Access Router Discovery

maidtweetΔίκτυα και Επικοινωνίες

29 Οκτ 2013 (πριν από 3 χρόνια και 10 μήνες)

88 εμφανίσεις

Abstract
--
The Candidate Access Router

[CAR] d
iscovery
protocol
is designed for use in wireless

IP networks to
dynamically collect information about neig
hboring access
routers and their capabilities dynamically enables the mobile
nodes to execute low
-
latency handoffs and select the target
access router intelligently. This paper presents our security

analysis on currently publish
ed CAR discovery approaches, as
well as
a new approach
that uses
ge
ographical information and
novel security mechanisms
.



Methods
Keyword
s

System design


Keywords
--

Access Router, Neighbor, CAR, Discovery, Security,
Wireless


I.

INT
RODU
CTION


The number of wireless network users has
rapidly
grown. In particular, the number of wireless Internet
terminals is
soon
expected to exceed that of the fixed
Internet terminals soon. On the other hand, the wireless
access network environment

has become heterogeneous
and the tendency is continuing. One of the fundamental
differences of the wireless Internet

from the wired
Internet is
mobility
support
. A key requirement for high
levels of Quality of Service [QoS] in wireless networks is

low lat
ency handoffs, since large latencies,

si
nce it may
cause considerable quality degradation. MobileIP [14] is
most likely the Internet standard for mobility support and
the MobileIP working group of the IETF
has
proposed a
low
-
latency handoff mechanism [11]
that can reduce
handoff latency significantly compared to base MobileIP.
However the proposed low
-
latency handoff mechanism
requires the knowledge of the IP address of the target
AR (access router) (or foreign agent in the MobileIPv4
case) while the MN (mo
bile node) is attached to the
current AR. Unless we assume soft handoff capability in
the underlying L2 wireless technologies, the MN can
know only the L2 ID (layer 2 identity
,

such as MAC
address) of the target BS

(base station) that is associated
to the
target AR. So the low
-
latency handoff mechanism
requires mapping of the L2 ID of the BS to the IP
address of the target AR during the handoff procedure.





There are cases when a MN is in a location where
si
gnals from multiple BSs are above the reception
thre
shold
. The BSs could be
using t
he same or different
wireless technologies. The latter

would often
be
the case
in heterogeneous wireless overlay networks such as a
wireless network consisting of GSM/CDMA cellular
networks and WLANs. Then
,

selecting a BS jus
t based
on signal strength does not make much sense. There are
many attributes of the link to each BS
,

or the associated
AR
,

that can affect the preference such as price,
available bandwidth, account requirement
s
, protocol
support, and
the
availability of
certain other features. Just
simply
communicating

with all the available BSs is not
preferable in most cases since the mobile user may have
to pay more and/or the overall system capacity is
reduced. The MN may talk to the AR or the NAS
(netw
ork access serv
er) associated with

each BS one by
one and find out all such attributes and choose an AR.
But
this process may introduce disruption of

the
application traffic if the MN’s wireless interface(s)
cann
ot support simultaneous access and completion the

L2 attach
ment procedure for a short message exchange
on each wireless link
. In this case,

the information
exchange
is not power
-
efficient compared to the case

when

the necessary information is given to the MN
through the currently active wireless link. So
,

it is
de
sirable for the MN to be able to collect the information
about the available BSs and the associated ARs via the
currently active air link.

Also
,

when a dual
-
interface MN supporting, for
example, GSM and WLAN is in a GSM
-
only coverage
area, the MN
will like
ly

turn off

the WLAN interface to
save
power.
Consequently, the
MN cannot know the
availability of the WLAN coverage even if it enters a
WLAN coverage area. In the case, it is desirable for the
AR to inform the MN of the WLAN coverage
availability.

When a
BS or AR is congested because too many
MNs are attached, the network may pursue load
-
balancing by guiding some of the MNs to hand over to
other attachment points. This requires the network
knows the congestion states or resource statuses of the
BSs or ARs
to which the MNs can hand over without
moving.

Eunsoo Shim
,
Jens
-
Peter Redlich
, and
Rich
ard D.

Gitlin

Secure Candidate Access Router Discovery

CCRL, NEC USA, Inc.

4 Independence Way, Princeton, NJ 08540 USA



For sim
plicity of presentation, we will denote

the L2 ID

of the BS associated to a certain AR the AR’s L2 ID
hereafter. The
n an AR can have multiple L2 ID
s if it
serves multiple BSs. One obviou
s solution for a
ll the
abovementioned
problems
is using

a

static configuration
in which the information such as the IP addresses and
the L2 IDs of all the ARs that ca
n be a target AR in a
handoff are

statically configured at each AR or even
each MN. Such static configurat
ion is inflexible and may
not be a viable solution where the target AR belongs to a
different administrative authority. T
he reasoning leads us
to a
mechanism for
dynamic

collection of the
information about the possible target AR
. T
he
CAR
(candidate access
router)

discovery protocol has been
proposed

for

this application, and
[22] describes
the
scope of the protocol and related issues
.

A candidate AR is an AR to which a MN can hand
over from the current access router, that is, a candidate
for the target acce
ss router in the next handoff. We
define the AR coverage area as the collection of the
coverage areas of the BSs associated with the AR. And
we use AR IP address hereafter to represent anything
equivalent to the IP
-
level identity of the AR that enables
IP
-
based

communication to the target AR. Then the
coverage of the CAR overlaps at least partially with that
of the current AR to which the MN is attached. So the
set of the candidate ARs can be different for each MN
since each MN may support different wireles
s access
technologies. Whereas the candidate AR is from the
viewpoint of a MN, the neighboring AR is from the
viewpoint of an AR. A neighboring AR is an AR that
can be a candidate AR of a MN that is currently being
served or can be served by the current AR
. So the set of
the neighboring ARs of an AR includes all

of
the
candidate ARs of every MN the AR can serve. Also as
the term ‘neighboring’ indicates, the neighboring access
routers can be said
to be
as the ARs whose geographical
coverage overlap at least
partially or are adjacent to that
of the current AR.

One thing to be noticed is that a neighboring access
router does not have to be a neighbor in the wired
network. It can be across several hops or in a different
administrative domain. That is why the IP

routing
protocol cannot be used for CAR discovery. The CAR
discovery protocol is one of the charter items of the
SeaMoby working group in the IETF and already
several

proposals have been submitted [2] [21]. Still the work is
quite primitive and security i
ssues have not been
thoroughly analyzed and addressed yet. This paper
p
resents our security analysis of the

currently published
CAR discovery approaches
, as well as

a new approach
using the geog
raphical information and also
novel secure
mechanism
s
.

In this

paper, we review briefly the security issues and
measures for protocols used for dynamic discovery in the
Internet, in particular, the Internet routing protocols and
the ARP protocol. Then we review possible CAR
discovery mechanisms including the two prop
osals
under
discussion
in the IETF and analyze security threats for
the mechanisms and investigate the requirements for
secure CAR discovery. A brief conclusion of the paper
is followed with discussions about other remaining issues
of CAR discovery.


II.

R
ELA
TED WORK


There are many protocols in the Internet for dynamic
discovery of certain network entities. To list a few
examples, those are the Internet routing protocols such
as OSPF [8] and BGP [16], the ARP protocol [15], the
service location protocol [23],

and the IPv6’s neighbor
discovery protocol [12].
It is generally the case that
whenever information

is to be discovered dynamically,
there are security issues. The routing protocols are the
core signaling protocol of the Internet and thus protection
of th
e routing protocols is critical for the correct
operation of the Internet.

Wrong routing information can result in congestion of a
link by advertising the link as the be
st route to many
networks. Or this

can cause unnecessary traffic
overhead by generating

routes containing loops or longer
paths than necessary.
In this case, p
ackets will be
discarded due to timeout and longer delays will result.
Of
particular significance

is that a portion of the network
may look unreachable even when usable routes exist.[1
0]

Kumar [6] analyzed the security requirements of
network routing protocols and identified two sources of
attacks: subverted routers and subverted links. He
proposed neighbor
-
to
-
neighbor digital signature
s

of
routing updates, the addition of sequence numb
ers and
timestamps to the updates, and the addition of
acknowledgements and retransmissions of routing
updates for distance
-
vector routing protocols. Kumar and
Crowcroft [7] analyzed the security threats and security
measures of the IDRP and particularly l
ink
-
level
encryption on inter
-
domain links. Digital signature
s

using
public keys on routing messages were proposed by
Perlman [13], Murphy and Badger [9] [10], Kent, et al
[5], and Smith and Garcia
-
Luna
-
Aceves [19], and
others

to provide authentication of
the routing messages.
Sequence numbers and/or timestamps in the routing
messages are used to prevent replay attacks. OSPF can
detect false advertisement about a nonexistent link if only
one router distributes the information but it cannot if two
routers co
operate about it but its damage is very limited.
A more serious case is when a router advertises a subnet

which does not exist and thus authorization is introduced
for that

subnet
. In particular, [10] lets a router be
authorized to advertise a certain addr
ess range with the
certificate by the parent organization owning the address
range since it was required to verify whether the router
was supposed to advertise a certain set of reachable
prefixes and the authorization is done at each level of
domain along
the address hierarchy with the ICANN as
the root authority. Authorization prevents a router from
advertising an address space illegitimately but cannot
prevent a router from omitting a certain address space in
its UPDATE messages. So authorization is cruci
al for
secure routing even though the infrastructure
requirement and computation overhead for verifying the
certific
ates or signatures are substantial. However

it
cannot
still be verified

whether the advertisement
topology or route information is 100% corr
ect and
complete.


III.

A
PPROACHES FOR
CAR

DISCOVERY


CAR discovery can be divided into two steps:
discovering the IP address (or IP
-
level identity) of the
neighboring AR and then finding the capability of the
AR. Once two neighboring ARs know each other’s IP
address, they can exchange information about their
capabilities. We focus on how to discover the IP address
of the neighboring AR. We pursue distributed and
scalable mechanisms and thus we require each AR
collect the information of its own neighboring ARs.

There are three
cases

when

we can say

an AR is a
neighboring AR to another
AR. The first
case

is
when

a
MN detects
at the same location
the L2 beacons f
rom
two

base station
s

associated with the
two
AR
s
respectively
. The second
case

is
when

a MN
is
handed
over fr
om/to the AR to/from the oter

AR. The third base
is
when

the coverage area of the AR overlap
s

with that
of the current AR. So we can list three approaches

for
CAR discovery
: L2 Beacon
-
Based Discovery, Handoff
-
Based Discovery and Geographical Informa
tion
-
Based
Discovery.


A.

L2
Beacon
-
Based Discovery


The MN receives the L2 beacons of the neighboring
ARs and informs
the AR of
the L2 identit
ies included in
the beacons of

the
neighboring

AR. Then the current AR
sends
an
inquiry including the L2 identity u
sing multicast
in the wired network and the corresponding access
router replies to it with its IP address [2]. This
mechanism is depicted in Figure 1. It is very similar to
the ARP protocol. One can notice that it may cause too
much traffic overhead if the

multicast inquiry messages
cross the domain boundaries. As mentioned above,
geographi
cal
adjacenc
y is
independ
ent of
domain
boundary and thus inter
-
domain search is inevitable. One
can improve the protocol by having
a
per
-
domain
discovery agent that handl
es inter
-
domain inquiry. That
is, the access router sends

an

inquiry using unicast to the
per
-
domain discovery agent and the agent sends
a
multicast inquiry within the local domain if it does not
have an answer. Also
,

if the discovery agent does not get

a
response from the local domain ARs, it sends
an
inquiry to the discovery agents in other domains using
multicast. Eac
h discovery agent may answer
the inquiry
or sends
an
inquiry to its own domain ARs using
multicast. This new mechanism will have much less
traffic overhead since a much less number of nodes
participate in the inter
-
domain multicasting
,

but it
introduces more infrastructure requirements and
complexity.
Furthermore,

we can introduce multiple level
hierarchies among discovery agents to reduce tr
affic
overhead further and the traffic overhead will
be

significantly
reduced
as the system converges, that i
s,
Current

AR

MN

CAR

Other AR

Beacon

CAR L2ID

(Multicasted)
Inquiry

Reply

Figure 1. L2 Beacon
-
Based Discovery, A Simple Form

Cur
rent
AR

MN

Old AR (CAR)

Attachment

Old AR IP, L2 ID

Figure 2. Handoff
-
Based Discovery,

A Simplified
View

Handoff

Neighbor AR Identity

when most access routers have

replied to the discovery
agents.


B.

Handoff
-
Based Discovery


This idea is shown in [17][18][21] and depicted in
Fig
ure 2. The MN hands ov
er from AR to AR and thus it

will

know the IP address of neighboring ARs. In
the
most straightforward

simple form, the MN remembers
the IP address of
the AR it attached previously with (old
AR) and relays this information

to the AR to

which it is
currently attached after the handoff (current AR). Then
the current AR gets to know the IP address of the old
AR. The current AR informs the old AR of the current
AR’s IP address so that the old AR also gets to know
the current AR as a neighbo
r. A variation of this
mechanism is that the MN informs the old AR of the
current AR’s IP address directly via the wired network.
Then the old AR gets to know the IP address of the
current AR. It is a delicate distinction to differentiate
who discovers who
m in this approach but it affects the
security requirements and the details of the protocol.


C.

Geographical Information
-
Based Discovery


Since we are dealing eventually geographical
overlapping
of AR coverage areas
, one may think the
information of the loca
tion and the coverage area
shape
and size of the ARs could be

distributed and each AR
figures out its neighboring ARs from
this

information.
The location information and the coverage area shape
and size should be configured statically.
In this case,

the
AR
s
would
flood the information among the ARs using
multicast as the link state routing protocol like OSPF
does. OSPF can use broadcasting since it advertises on
its local links
,

but the CAR discovery mechanism should
use multicast since the ARs are remotely

distributed in
the wired network. A problem
with

this approach is tha
t
the coverage shape and area are

not easy to define
precisely
. M
any times it is affected by the geographical
objects such as buildings or walls. The coverage area
may not look like a ci
rcle in many cases even if we
consider only two dimensions. It becomes much more
complicated if we consider three
-
dimensional coverage,
which is necessary for WLANs in multi
-
story buildings.
Another problem with this approach is that the flooding
of the ge
ographical information is not scalable over
domain boundaries. So we need to introduce something
like

an

inter
-
domain CAR discovery protocol for the
information flooding. The inter
-
domain CAR discovery
agents should be configured to exchange the informatio
n
with the discovery agents of certain domains which have
ARs neighboring to ARs of the local domain. That is, the
administrator should know which domain will have ARs
adjacent to the AR of

the local domain in advance. This
approach

reduces the meaning of
the dynamic discovery.
Also we cannot define summary of the geographical
information. Pretty much the whole information of one
domain should be flooded to another domain. Thus this
could be information large enough to cause
a
scalability
concern since a do
main may have multiple geographically

neighboring domains. This approach is distinguished from
the former two approaches in that it does not rely on MN
at all. On the other hand, having GPS equipment would
not be a problem for operators or big corporations

but it
is not a simple thing for small offices or home WLAN
users unless the BS is equipped with the GPS terminal
function. This is another disadvantage of this mechanism.


IV.

S
ECURITY THREAT ANALY
SIS AND SECURITY
REQUIREMENTS


What harm could the attackers
achieve regarding the
CAR discovery protocol?

First, the attacker may have false information inserted
in the CAR t
able or the neighbor table that

includes
information about the neighboring ARs. If the table is
filled up with garbage, the table will become
useless and
all the advantages of CAR discovery will disappear. For
example, low
-
latency handoff using the CAR table will
fail. If the information in the CAR table is used to guide
the MN in search for target ARs, the corrupted CAR
table results in misguid
ance of the MNs. The attacker
may pursue blocking of handoff to a certain AR or
seduce the MNs to handover to a certain AR f
rom which

the attacker can learn

the passwords of other mobile
users. Or the AR simply does not exist and the MNs
may waste power to

search for a nonexistent AR.

Second, the attacker may have its computer inserted
as an AR in the CAR table of an AR and collect the
information of the AR status.

Third, the attacker may make the ARs simply busy
with the CAR discovery process and have no
time to do
other jobs. It is a typical DoS (Denial of Service) attack.

Certainly we require the CAR discovery protocol
should be d
esigned to prevent all the above harmful
behaviors
.

We see that the MN plays a key role in the dynamic
discovery in the first
two approaches, where the MN
reports the ID of a neighboring AR.
In the context of
security measures for dynamic routing protocols,
authentication and authorization of the parties
participating in the discovery process are the most
important methods for se
curity. We can certainly apply
this philosophy for the MN as well,

but

the problem with
the MN is that the MN does not have physical security.
That is, the routers are typically maintained by the
administrators and physical access to such equipment
can be
controlled relatively easily. Thus we may assume
,
without too much risk,

that the authenticated and
authorized equipment is not compromised by attackers.
However a mobile device such as handset or PDA can
be lost or stolen and the
entire

software can be
co
mpromised. A careless user may not report
a

lost
device for a while.
Unconditional trust of the MN is

almost equal to trusting the human users using the MNs
,

and trusting such a huge number of mobile users is
a
security nightmare
. We can consider trusting

mobile
users and thus the MNs only in an environment where
the number of MNs is small and it is easy to track the
devices. In this paper, we consider MNs as not trustable
in general.

In the first two mechanisms, there are three parties
involved in the dis
covery process basically: the first AR
(the AR collecting the information), the second AR (the
AR to be discovered) and a MN. Actually the MN
specifies the second AR to participate in the process. So
if the second AR as well as the MN is malicious and the
two cooperate, there is no way for the first AR to know
the truth. Since we cons
ider that

MNs can be malicious
in general, at least the second AR should be trustable.
Otherwise, the discovery process is not reliable as a
whole. So
it is essential verifying

whether
the second AR

is authorized by a trustable authority to participate in the
CAR discovery process
.

Digital signatures can be used
for authorization.

Since the neighboring ARs may
exchange the capability information

with each other
,
information acce
ss control

is necessary to determine the

level of information exchange.
In everyday life, we
would only exchange important information with a
neighbor who we can trust.
The

authorization of a

neighboring AR should tell whether the information from
the AR c
an be trusted and how much information can be
disclosed to it. There are two types of information from
an AR: information related to the discovery process and
the AR’s capability information.

Assuming availability of the AR authorization
mechanism and
that

authorized

and authenticated

ARs
won’t lie, the key issue for secure CAR discovery is how
to deal with the MN. Remembering that
the network can
observe

the MN reports about a CAR, one approach for
the security is pursuing the correctness of the
informatio
n, that is, making sure the claimed CAR is a
real CAR. Another approach is taking a loose position
about the truthfulness and use the informatio
n about a
discovered CAR only for those

MNs that reported about
the CAR. Then false information from a malicious

MN
does not affect the other MNs. Then the only harm
possible by a malicious MN is DoS (denial
-
of
-
servic
e)
.
The
damage caused by
collecting information is assumed
to be prevented by
authentication and
authorization

of the
CARs
. We can say the former appro
ach is to build a
shared CAR table for all the MNs and the latter is to
build a separate CAR table for each MN. In the former
approach, we should put the top priority in assuring the
correctness of the information collected in the CAR table
and thus we may

sacrifice the time to collect the
information or even completeness of the information for
the sake of information correctness.

The best
approach
would be
to make

sure

that

only
correct information is inserted into the CAR tab
le as in
the former approach.
This

comes with a cost. So we will
compare the two security approaches in terms of the
benefit and the cost for the case of Handoff
-
Based
Discovery.


A.

Security Analysis for L2 Beacon
-
Based
Discovery


Here we consider attacks only by malicious MN
s
. We
assu
me

all the involved ARs are trusted and legitimate
.
Also we assume the MN can receive only L2 be
acons
from the neighboring ARs
, that is, it cannot establish links
to the neighboring ARs and thus it cannot communicate
with the neighboring ARs while it has an
active link with
the current AR, which is a minimum requirement for all
L2 wireless technologies.

In the first attack scenario, the MN reports the L2 ID
of an AR which is far away from the current AR. The
MN can simply remember the L2 ID of an AR to which
it was attached in the past and it can reports it to the
current AR after several handoffs. The current AR will
send an inquiry message and the corresponding AR will
reply. This problem will occur no matter how the inquiry
and the reply messages are delive
red in the wired
network.

To prevent this attack, the L2 beacons should include a
ticket (which is a message block) and the validity of the
ticket should be limited with a timeout period. That is, the
ticket contains
a
timestamp that tells when the L2 bea
con

was transmitted and the ticket should be authenticated.
Such

a

ticket is encrypted so that only the AR associated
with the BS sending the L2 beacon can recognize it. One
issue with this solution is that we need to modify the L2
beacon structure, which
is not preferable for the existing
wireless technologies.

Now we assume the L2 beacons include such a ticket.
Then the MN can play the following attack. The MN has
a proxy MN, that is, it has
a cooperating

malicious MN
friend. The MN receives a L2 beacon i
ncluding the ticket

and it sends the ticket to the proxy MN
that

is attached
to an AR far away. Then the proxy MN reports the
ticket to the AR. Then the recipient AR has no way to
know that the ticket was delivered by the proxy MN
since the ticket cannot c
ontain any information about the
identity of the delivering MN. We think there is no
solution for this attack with the L2 beacon
-
based
discovery approach. It is because the L2 beacons are
broadcasted and thus the ARs cannot verify whether the
MN reporting
the L2 beacon is the same MN that
received the L2 beacon. Therefore
,

the L2 beacon
-
based CAR discovery mechanism is vulnerable to the
attack of malicious MNs providing false information.



B.

Security Analysis for Handoff
-
Based
Discovery

with Shared CAR Table
s


First we look for the requirements to guarantee the
correctness of the information in the CAR table, which is
the first security approach abovementioned.

We claim
that se
cure CAR discovery using the
handoff
-
based
approach

with
a
shared CAR table
requir
e
s

that the
old AR

know when the M
N hands off from it, the ARs

authenticate the MN based on the MN’s physical ID
which is not compromisable, and a pair of ARs
neighboring to each other should have a trust
relationship based on authentication and
authorizat
ion.

Why such things are required is explained
by showing possible security threats and corresponding
security measures in the following.

Again we assume the MN can be malicious. Since the
MN delivers the IP address of the peer AR (the old AR
to the curren
t AR or the current AR to the old AR), the
two ARs can communicate with each other immediately.
We consider the cases when both of the ARs are
honest

and honest and then look into the cases when one of
them is also malicious and cooperates with the
malicio
us MN.

We start from a very simple mechanism and review a

possible attack and then extend the mechanism to
defeat the attack. We repeat this procedure. First of all,
the IP handoff
-
based discovery depends on the IP
address of the old AR delivered by the MN
. The key is
whether the information is true. The old AR is in the
best position to judge it. Eventually the current AR
should rely on the old AR’s confirmation about it. So
we put the old AR in the central position of the
discovery mechanism.

In the firs
t scenario, the MN knows the IP address of
the old AR through MobileIP agent advertisement or
IPv6 router advertisement and the L2 ID from the L2
beacons. After a handoff, the MN reports the
information to the current AR. Then the current AR
sends a Neighb
or AR identity messaging including its
own IP address, the current BS L2 address, old AR IP
address, the old BS L2 address, and the MN home IP
address. Then the old AR can check the history of its
binding table (the old AR maintains the history for a
certa
in time period) and confirm that the MN was with it
and thus the current AR is one of its neighboring ARs.

A possible attack is that the MN again reports the old
AR IP address and the old BS (base station) L2 address
to the current AR after several handoff
s.

Current

AR

Proxy MN

MN

False CAR

Beacon

(Ticket)

Ticket

Inquiry (Ticket)

Reply

Figure 3. At t ack using a p
roxy MN on t he

L2 beacon
-
based
discovery

Ticket

To defeat this attack, we again introduce a ticket
including timestamp, which is called AR ID ticket. That
is, now the old AR provides the MN an AR ID ticket
including timestamp, the old AR IP address and L2 ID,
the MN home IP address, and the ticket I
D. Actually the
information in the ticket can be arbitrary as long as the
old AR can later confirm all the information with its
locally stored record. So it might include just a ticket ID,
old AR IP address and a random string where the ticket
ID is the in
dex of the local binding history record
containing all the necessary information. The old AR
should be able to authenticate the ticket that it was from
itself and was not modified. The requirement here is the
ticket authentication by the sender and thus th
ere can be
many ways to achieve it. One way is appending a
random string to the information payload, appending the
hash value of the payload and the random string and then
encrypting some part of the payload, the random string
and the hash value. To put on
e more requirement, it is
better to encrypt most
of
the information payload to avoid

any possibility of reply attack. To simplify the discussion,
we assume all the necessary information is included in
the ticket and it is encrypted. The MN delivers the AR
ID ticket and the old AR IP address to the current AR
after handoff and the current AR sends the old AR a
Neighbor AR Identity message including the current
AR’s IP address and L2 ID, the MN home IP address
and the AR identity ticket delivered by the MN.

A
ctually relying on timestamp is tricky. Since there is
no rule about how long a MN should stay with an AR
before handoff, just checking time does not tell whether
the current AR is the current AR after one handoff or
several handoffs. One may think the old

AR should
provide the MN the ticket right before the L2 handoff
and the MN should deliver the ticket to the current AR
right after it gets the router advertisement and acquires a
care
-
of
-
address. It requires something like
a
L2 source
trigger in the old A
R or the MN
,

as required in the low
-
latency handoff propo
sal [11] of the MobileIP WG. But

if the link between the MN and the old AR deteriorates
quickly, there may be no time for a message delivery. So
we can loose
n

the requirement by having the old AR
rec
ord two moments: when the ticket is provided to the
MN and when the L2 source trigger is issued. That is,
the old AR sends the MN the ticket after the MobileIP
registration and records the time and then checks the
time of the L2 source trigger that indicat
es that the MN
is leaving the coverage area. If the L2 source trigger is
issued in the MN, the MN should inform the old AR
about it. The advantage of this scheme is
that the MN
has to exchange fewer

messages between the L2 source
trigger and the moment the

link to the old AR is
terminated. Still there are other variables such as the
time taken for the MN to receive the router
advertisement and for the Neighbor AR Identity message

to be generated and delivered to the old AR. To take
account of the router adv
ertisemen
t time factor, the
Neighbor AR i
dentity message includes the
advertisement period of the current AR. And the old AR
measures the round trip time between the old AR and the

current AR. Then the old AR accepts the Neighbor AR
Identity message only w
hen the ticket is verified as
authentic and the following time constraint is met:


(Time when the Neighbor AR Identity message is
received


time when the L2 source trigger is issued
for the MN )


(round trip time + current AR
advertisement period) / 2 <
ticket timeout period


As we can see, if the ticket timeout period is too short,
we may miss the valid discovery. It is better to set the
timeout period somewhat conservatively to defeat the
attack.
In this case we pursue
the CAR table integrity by
even ta
king a chance of missing valid information. Also
we can apply different timeout values for different type
of handoffs. For example, the timeout value for inter
-
domain handoff can be larger than that of intra
-
domain
handoff.

Here

the attacker can use a pro
xy MN to pass the
time check of the above measure as in the case of L2
beacon
-
based discovery. That is, the malicious MN
sends the ticket to its proxy MN and has it deliver the
ticket to the target access AR. To pass the MN home IP
address check, the two M
Ns switch their home IP
Current AR

MN

Old AR


(CAR)

Ticket

Ticket, Old AR IP, L2

ID

Figure 4. A Handoff
-
Based Discovery Mechanism with
Shared CAR Table

Handoff

Neighbor AR Identity (Ticket, Current AR IP,




MN IP, MN Phy ID)

(L2 Trigger )

ACK

ACK

ACK

addresses immediately after the ticket is delivered to the
proxy MN. They can do this right after the MN hands
over from the old AR to another AR and right before the
proxy MN enters the coverage area of the target current
AR. This
kind of attack is not so trivial but can be done
with good coordination or relatively easily if the MNs
have multiple interfaces in the
h
eterogeneous overlay
network. That is, if there are two remote and distant
WLAN areas under a cellular network and the
two MNs
have a WLAN interface and a cellular network
interface, they can maintain the links to the cellular
network active and use it for communication while they
attack the WLAN ARs.

This attack means that we need to verify that the MN
delivering the tick
et to the current AR is the same MN
that received the ticket from the old AR and that the
home IP address of the MN is not really useful to identity

the MN in this case. We need p
hysical identity of the
MN that

is not duplicable, com
promisable or transfera
ble
by software commands or communication. The MAC
address of the interface is not helpful
,
since the handoff
might be

an

inter
-
technology handoff and thus the MN
may use different interfaces
before and after the handoff
---

also some products in the marke
t allow changing the
MAC address by softwa
re commands. One example of
a

physical ID satisfying the requirements is the SIM card
used in the GSM networks. If the home registration and
the associated authentication include verification of the
physical ID of
the MN, we can use the MN home IP
address as the physical ID of the MN as well. In any
case, the MN should be equipped with something like the
SIM card. This requirement comes from the fact that we
are dealing with
the
geographical structure of the
wireles
s network and the MN is carrying the key
information (=the AR ID ticket). The Neighbor AR
Identity message from the current AR should include the
physical ID so that the old AR can compare it with the
physical ID of the MN in its locally stored record or i
n
the ticket. Figure 4 depicts a handoff
-
based discovery
mechanism described so far.

Now we should take care of a
man
-
in
-
the
-
middle

attack that can be done for the Neighbo
r AR i
dentity
message transferred in the wired network. A middle man
can capture the
Neighbor AR identity message and
change the current AR IP address. Since the old AR can
verify only the ticket, it will accept the false current AR
IP address as the CAR IP address.

To defeat this attack, the messages between the old
AR and the curren
t AR
should be authenticated. This

can be done by establishing
a
security association
---

for
example,
by using IPsec.

So far, we assumed the claimed current AR is benign
and is the real current AR. What if the claimed current
AR is actually malicious?
In parti
cular, if the current
AR cooperates with the malicious MN, there is no
way to detect that the claimed current AR is
providing false information to the old AR.

IP
authentication does not tell whether the claimed current
AR won’t do any bad thing. This could

happen, in
particular, at an AR in the external domain. So we need
to
verify whether
the AR
is authorized to participate

in
the CAR discovery process. The authorization for AR
has two aspects: one is for the authority to allow the AR
to participate in the

CAR discovery process, which
means that the node is an access node and maintained
with physical security. The other is for the authority to
sign the static attributes of the access router such as the
L2 IDs, the wireless interface types, and maximum
bandw
idth of each interface. The authorization does not
tell whether the authorized AR is a CAR of a certain AR
and thus still it cannot help verifying whether the claimed
AR is a real CAR
,

but it can tell whether the AR is
under a trustable organization’s cont
rol with good
physical security. If then, the AR is considered to be
trustable and the discovery mechanism is trustable as
well. So
the handoff
-
based CAR discovery
mechanism with shared CAR table can result in
reliable CAR table
s

only with authorized and
p
rotected ARs by trustable organizations.

If the authorization status of the claimed current AR is
not satisfactory to the old AR, it depends on the policy
set in the old AR how to use the received Neighbor AR
Identity message. Also the old AR should apply
a pre
-
configured access control policy about how much
information about the AR capability can be exchanged
with the peer AR.

As the last possible attack, we consider denial of
service attack by a malicious MN or a malicious AR. A
malicious MN can send lots

of tickets to the current AR
causing the current AR to spend too much time on
communication with other ARs. To defeat this attack, the

AR should allow only one ticket message from each MN
during its attachment and simply ignores the ticket
messages more t
han one. A malicious node may send
lots of Neighbor AR Identity message
s

to an AR. The
AR allows only a limited number of Neighbor AR
Identity message from the same node within a certain
time period. We risk missing valid Neighbor AR identity
messages to d
efend the AR from the possible denial of
service attack.

Until this moment, the current AR is just helping the
old AR discover the current AR
.
Using only the message
provided by the MN, the current AR cannot verify
whether the old AR is one of its neighbor
ing ARs.
However since we require a trust relationship between

the old AR and the current AR, the old AR can tell the
current AR that they are neighboring to each other and
the current AR can accept this message
after it is
confirmed

by the authorization m
echanism.

Note that the MN does not have to do any
cryptography calculations for CAR discovery except that
required for its physical ID authenticat
ion. We assumed
that the AR
know
s

the home IP address and the physical
ID of the MN during the attachment pr
ocess. As long as
the AR can get the home IP address and the physical ID
as a result of the attachment process, the details of the
attachment process are independent of the CAR
discovery process. Also how the AR gets the information

is independent of the C
AR discovery process.
Authenticating a MN’s physical identity using the SIM
card in the GSM network is described in [3][4].


C.

Security Analysis for Handoff
-
Based
Discovery with Separate CAR Tables


As described in the above, the idea is that a malicious
MN

cannot affect other MNs by causing false CAR
information to result in the discovery process because a
logically separate CAR table is setup for each MN.

Since the MN has much less motivation to provide a
false CAR IP address in this mechanism and the MN
knows the IP address of the current AR, the old AR can
use the MN more seriously. Figure 5 depicts the
discovery process modified from Figure 4. The old AR
provides a secret key to the MN in addition to the ticket
and the MN generates a new ticket which co
ntains the
original ticket from the old AR and the encrypted current
AR’s IP address and L2 ID with the secret key. Then
the current AR’s IP address inserted in the Neighbor AR

Identity message by the current AR and the current
AR’s IP address in the modif
ied ticket are compared by
the old AR. It is a double
-
checking.

Two important security requirements of the
mechanism depicted in Figure 4 are omitted in the new
mechanism in Figure 5. Those omitted are the L2 trigger
and the MN physical ID. As to be descri
bed later, for the

given number of CARs, the average time to be taken to
discover all the CARs is in inverse proportion to the
number of involved MNs. Since only a MN is involved
for its own CAR table, it is important not to take all the
valid discoveries.

So we don’t want to lose the valid
discovery result due to the tight ticket timeout period we
enforced in the previous mechanism. The L2 trigger
requirement was for the old AR to know when the MN
hands off the old AR which is necessary to apply the
tight
ticket timeout period and thus we omitted it. Since a
malicious MN cannot affect other MNs, we think the
requirement of MN physical ID is an unnecessarily
expensive requirement and thus it is omitted. The ticket is

still kept since it is useful to detect m
isbehavior of the
MN. For example, if the MN stores the old AR’s IP
address and then is turned off. Then it moves far away
and is turned on and reports the old AR’s IP address to
the AR there. The timestamp information in the ticket
will make sure this kin
d of misbehavior is detected.

A new concept, MN Class ID card, is introduced in
Figure 5, which is related the scalability aspect
of

having
separate CAR table
s
. For example, let say an AR has
200 CARs and the number of MNs is 10,000,000. This is
possible

for an AR covering several cells of a cellular
network in the metropolitan area where many WLANs
are deployed. Storing a physically separate CAR table
for each MN is a big overhead in the AR’s memory
space. Just having only the CAR IP address in each
CAR
table is still a big overhead not to mention the case
having also the CAR capability information in the CAR
table. We can reduce the memory requirement by having
a common CAR table in the memory and assigning to
each MN a bitmap each of whose bit correspon
ds to an
entry of the CAR table in the sequential order. So if the
bit 10 of the bitmap of a MN is 1, the 10
th

entry of the
CAR table is an entry of the logical CAR for the MN.
The maximum memory requirement then is
[total
MN

Ticket, Secret Key

Ticket’, Old AR IP, L2 ID, old MN Class ID

Figure 5. A Handoff
-
Based Discovery Mechanism wit h Separat e CAR
Tables

Handoff

Neighbor AR Identity (Tick
et’, Current AR IP,







MN IP)

ACK, new MN

Class ID

ACK, old MN Class ID

card

ACK, new MN Class ID

Ticket’ = Ticket | Enc (Current AR IP, L2 ID)

Old AR (CAR)

Current AR

number of the MNs] x [size of the

bitmap] + [total
number of the CARs] x [size of a CAR table entry]
.
As the number of the MNs increases, the memory
requirement increases linearly. If the AR should
remember which CARs a certain MN discovered, such
linearly increasing memory requirement is

unavoidable. A

solution is using a permanent storage in the AR or putting
separate databases in the network and letting each AR
store the data in the databases. Another solution is letting
the MN remember which CARs it discovered. The MN
Class ID card con
tains the bitmap abovementioned and it
is digitally signed by the AR. So each AR issues a MN
Class ID card to a MN that ever reported a CAR to the
AR. Then a MN can have many such cards. The AR
can use a simple secret key based encryption to digitally
sign

the card since it is the issuing AR that will read the
card. Every time the MN reports a new CAR, the bitmap

in the card is updated. And the MN submits the card to
the AR when it wants to get information about the AR’s
CARs.

The advantage of
the separate
CAR table scheme is
that it has little requirement for the underlying
technologies

whereas the shared CAR table scheme
requires the L2 trigger and the MN physical ID. Also the
separate CAR table scheme can produce useable CAR
tables without authorization o
f ARs which is required by
the shared CAR table scheme. Still access control is
required about how much information to be shared with a
certain CAR. But its disadvantage is that a MN should
discovery the CAR to use the information of the CAR
whereas any MN

can use the information in the shared
CAR table scheme. A MN roams a lot and can discover
all the interesting CARs for itself. An analysis and
related simulation result about the aspect is present in the
Simulation Result section later.


D.

Security Analysis

for Geographical Information
-
Based Discovery


Since the MN is not involved and there is no way
among the ARs to verify the information delivered by
other ARs, the whole security depends on the
authentication of the messages and the trust relationship
amon
g the ARs. So each AR should be
authenticated
and then
authorized to participate
in the process. One
way to do this

is
via a
digital signature using
the
public
key on the advertisement message for the coverage area
information of each AR. Then the major is
sue is how an
AR can know the public keys of all the ARs. Since the
advertisement messages containing the geographical
information contains the sending AR’s IP address, an
efficient way to distribute the public keys is attaching the
certified public key to

the advertisement message. Then
each administrative domain should have an authority to
sign
the
publi
c
keys
of
the
ARs
in the

doma
in.
Then
the
publi
c key

of external domain’s authority should be signed again by
a central authority like ICANN. Like the rou
ting protocol,

the advertisement message should include also sequence
number and timestamp to prevent replay attacks and
allow expiration of obsolete information. Since the
discovery mechanism is very similar to the routing
protocol operation, the security

measures are also every
similar to those of the routing protocols.


V.

S
IMULATION RESULTS


From the perspective of the network administrator, if
the CAR tables of the ARs in the network are fully filled,
that is, each AR discovers all of its CARs, the netw
ork
can serve any mobile node’s need about CAR
information and also the network can do load
-
balancing
at its best effect. When a CAR table of an AR is in
such a state, we call the CAR table converged to its full
state. The time taken for an AR to discover

all its CARs
is also the time taken for its CAR table’s convergence.

In the handoff
-
based discovery mechanism, whenever
there is a handoff of MN from an AR to another AR, the
old AR discovers the current AR. Assuming trust
relationship between the two AR
, the current AR
accepts the old AR as one of its CARs as well. So the
discovery time is the time necessary for a handoff to
occur between the two ARs. Using the fluid flow
mobility model [1] [12], the handoff rate across a
boundary is





where
is the handoff rate or cell boundary
-
crossing
rate (1/sec),
is the active mobile node density (1/m
2
),
is the mobile moving speed (m/sec), and L is the cell
perimeter (m)
. So the CAR table c
onvergence time
increases in inverse proportion to the active number of
MNs
,

when other parameters are the same.

We did a simulation on the ns
-
2 simulator for the CAR
table convergence time. We used the hexagonal cell
structure typical for the cellular net
works where the cell
diameter (distance from a vertex to the opposite vertex)
is 200m, the air interface’s bandwidth is 2Mbps, there is
an AR for each cell, and each AR is connected to its
neighboring ARs with a 10Mbps wired link. We
implemented a break
-
be
fore
-
make handoff model with
L2 beacons every 100ms. Figure 6 shows the cell
structure and the wired network topology used for the
simulation where the rectangle is the region the MNs are
roaming in and Figure 7 shows the simulation result.


Figure 6. The
geographical structure of the cells and the wired network
topology for the simulation



Figure 7. CAR table convergence time vs. MN density


We can see that the CAR table convergence time for
the separate CAR table scheme will be very large since
the e
ffective MN density is very low for each (logical)
CAR table.
From the perspective of the MN, the
separate CAR table means that the MN cannot achieve
a low
-
latency handoff for every first time handoff to an
AR and the MN won’
t be informed of the capabiliti
es

of
the ARs that the MN has not visited before.

The CAR
table convergence time does not mean the MN won’t
have low
-
latency handoffs all the time during the period.
For example, let say there are three ARs
and all of them
are neighboring to the others
.
If

a MN roams only
between two of them, the MN won’t have low
-
latency
handoff only once and then all other handoffs will have
low latency even though the MN’s CAR table is not
converged. So such a case is not a big problem.
However the separate CAR table sch
eme could be a
problem in a wireless overlay network.

For example, a
GSM/CDMA cell overlaps a WLAN. If a MN is
attached to the GSM/CDMA AR and it does not scan
the WLAN signals, it won’t be informed of the
availability of the WLAN. So a flexible policy is
required
in applying the separate CAR tables; for example, the
CAR entries common to above a threshold number of the

CAR tables co
uld be shared for all the MNs, which
is
a
policy loosening the security level.


VI.

CONCLUSION


Like most dynamic discovery protoc
ols
,

such as the
Internet routing protocols, the CAR discovery protocol
faces lots of security challenges. We presented three
approaches for CAR discovery and

analyzed the security
issues associated

each approach. We found
that
the L2
beacon
-
based approach

is vulnerable to a malicious
MN’s attack providing a false L2 beacon to the AR.
The handoff
-
based discovery mechanism with shared
CAR table can produce a single reliable CAR table
,

but
it has somewhat heavy security requirements including
authorization of

the participating ARs,
a mechanism
like
a
L2 trigger to inform the AR the moment when a MN
hands off, and the physical identity verification of the
participating MNs. On the other hand, the handoff
-
based discovery mechanism with
a
separate CAR table
can p
roduce separate CAR table
s

for each MN so that
the damage by a malicious MN’s false inform
ation does
not affect other MNs;

this results in reasonably

secure
mechanism with much less security requirements than
the

shared CAR table scheme. But this

comes wit
h the
price of longer CAR table convergence time for each
MN. The geographical information
-
based approach is
most similar to the link
-
state routing protocol and ha
s
similar security requir
ements. It’s most difficult aspect is
to obtain

the geographical inf
ormation about each AR’s
location and coverage shape and size.

We think the
handoff
-
based approach is most reasonable for CAR
discovery considering the security, feasibility and
scalability aspects of the approach. Since the SIM card is

widely used in the
commercial cellular networks, the
shared CAR table scheme of the handoff
-
based
approach

would be most appropriate in the large public
wireless networks.

The CAR discovery protocol is in its early
development stage and more research on various aspects
is ne
cessary. How to represent the AR’s capability
flexibly and efficiently is one of the aspects
,

and
interaction with mobility management techn
iques should
be looked into. Also,

applications of the information in the
CAR table should be investigated in furth
e
r detail
---

including an algorithm

in the MN’s side to request
and
manage
the information and control the BS search.


REFERENCES


[1]

Balarkrishnan,H., Seshan,S., Katz,R.. “Improving
Reliable
Transport and Handoff Performance in Cellular Wireless
Networks”
, ACM Wireless Networks 1(4), December 1
995

[2]

Funato, D.,He, X.,Williams, C.,Takeshita,A.,”Geographically
Adjacent Access Router Discovery Protocol,” draft
-
funato
-
seamoby
-
gaard
-
00.txt, work in progress, November 2001

[3]

GSM 03.20: “Digital cellular teleco
mmunications system (Phase
2+); Security related network functions”

[4]

GSM 02.17: “Digital cellular telecommunications system (Phase
2+); Subscriber Identity Modules (SIM); Functional characteristics”

[5]


Kent, S., Lynn, C., Seo, K., “Secure Border Gateway
Protocol
(Secure
-
BGP),” IEEE Journal on Selected Areas in Communications
18, no.4 pp582
-
592, 2000

[6]


Kumar, B., “Integration of Security in Network Routing
Protocols,” ACM SIGSAC Review 11, no.2 pp18
-
25, 1993

[7]


Kumar, B., Crowcroft, J., “Integrating Sec
urity in Inter
-
Domain
Routing Protocols,” ACM SIGCOM Computer Communication
Review 23, no.5 pp36
-
51 1993

[8]


Moy, J., “OSPF Version 2,” RFC 1583, March 1994.

[9]

Murphy, S., Badger, M., Wellington, B., “OSPF with Digital
Signatures,” RFC 2154, June 1997

[10]

Mur
phy, S. L., Badger, M.R., “Digital Signature Protection of the
Ospf Routing Protocol,” Proceedings of the Symposium on
Network and Distributed System Security:93
-
102. Los Alamitos,
CA 1996

[11]

Mommety, G., Yegin, A., Perkins, C., Tsirtsis, G., El
-
Malki, K.,
Kh
alil, M., “Fast Handovers for Mobile IPv6,” draft
-
ietf
-
mobileip
-
fast
-
mipv6
-
04.txt, work in progress, March 2002

[12]

Narten, T., Nordmark, E., Simpson, W., “Neighbor Discovery for
IP Version 6 (Ipv6),“ RFC 2461, December 1998

[13]

Perlman, R., “Network Layer Protoco
ls with Byzantine
Robustness,” Diss., Massachusetts Institute of Technology, 1998

[14]

Perkins, C.,”IP Mobility Support,” RFC 2002, October 1996

[15]

Plummer D. C., “An Ethernet Address Resolution Protocol,” RFC
826, November 1982

[16]

Rekhter, V., Li, T., “A Border Gate
way Protocol 4 (BGP
-
4),” RFC
1771, March 1995

[17]

Shim, E., Gitlin, R., “Fast Handoff Using Neighbor Information,”
draft
-
shim
-
mobileip
-
neighbor
-
00.txt, work in progress, Novemebr
2000

[18]

Shim, E., Wei, H., Chang, Y., Gitlin, R., “Low Latency Handoff for
Wireless

IP QOS with NeighborCasting,“ Proceedings of ICC 2002,
New York

[19]

Smith, B. R., Garcia
-
Luna
-
Aceves, J.J., “Securing the Border
Gateway Routing Protocol,” IEEE Globecom pp81
-
85, London
1996

[20]

Thomas,R., Glibert,H., Mazziatto,G.. “Influence of the Mobile
Statio
n on the Performance of a Radio Mobile Cellular Network”,
Proc. 3rd Nordic Seminar, Denmark 1988.

[21]

Trossen, D., Krishnamurthi,G., Chastar,H., Shim,E., Gitlin,R.,
“Protocol for Candidate Access Router Discovery for Seamless IP
-
level Handovers.“ draft
-
trosse
n
-
seamoby
-
cardiscovery
-
00.txt,
work in progress, November 2001

[22]

Trossen, D., Krishnamurthi, G., Chaskar, H., Kempf, J.,“Issues in
candidate access router discovery for seamless IP
-
level handoffs,“
draft
-
ietf
-
seamoby
-
cardiscovery
-
issues
-
03.txt, work in prog
ress,
June 2002

[23]

Veizades, J., Guttman, E., Perkins, C., Kaplan, S., “ Service
Location Protocol.“ RFC 2165, June 1997