Subject: RE: [Seamoby] Re: choices for rev. adr. translation mechanisms [was: CARD between Routers - will CT do?]

From: [email-masked]
Date: Tue, 21 Jan 2003 16:06:46 -0500

Hello Jim,

comments inline.

-Govind.

> I see a few problems with the rev.adr.translation server based approach.
>
> 1) The reverse address translation server can tell only that the there is a
> registered access router with the given L2 address (probably L2 address of
> the BS associated to an access router) but it cannot tell whether the access
> router is a CAR of the current AR. Now the current AR relies on the fact
> that a MN provided the L2 address matching to a registered AR. It comes with
> the following security threat.
>
> Security threat:
> A malicious MN (tampered MN) provides a L2 address which is the L2 address
> of a registered AR but not a CAR of the current AR, that is, no overlapping
> coverage with the current AR. Then the current AR will build a CAR table
> with IP addresses of ARs that are not CARs. As long as we assume a MN can be
> tampered, this attack is very easy to play since it is easy to collect the
> L2 addresses of registered access routers.
>

Doesn't matter.

At the time of handover, the MN or AR will receive from layer 2 the address of
the AP to which the MN is moving. Or, the MN will ask for CARs and match the AP
layer 2 addresses in the CAR table with the addresses of the APs it can hear.
Thus, an AP address that is provided by a malicious MN but has no wireless
connectivity to the current AR will get filtered out when the MN or AR uses the
information for handover, so it can do no harm.

There is still the issue of the bogus AP sticking around. The AR can handle this
by making the CARD information soft state, so it times out AR layer 2 addresses
if it doesn't receive a confirmation from another MN within a certain period of
time. Thus, any bogus information only has limited lifetime, and even within
that lifetime, can't do more than occupy a table slot in the router's memory. In
fact, the AR can use the number of MNs reporting a particular address to weight
the relevence of a reported AP. So if 20 MNs report it, the AP address is more
likely to stick around than if only 1 reports it.

[Govind] This seems to be very similar to the approach taken by dycard. 

A related, but more serious, problem is if the MN undertakes a DoS attack by
flooding the AR with real or bogus layer 2 addresses. The CARD protocol between
the MN and AR must prevent this.

> 2) Another issue with the approach is that it requires static configuration.
> It is better than static configuration of CAR table at each AR but still it
> is much less flexible than something more dynamic. The motivation of CARD is
> dynamic discovery to avoid inflexible static configuration. I'd prefer less
> static configuration.
>

There could be a protocol between the server and the APs that allows them to
dynamically report this information.

The problem with having this information directly exchanged between routers is
that each router would have to keep a table of all AP/AR matches, which could be
lots of information and thus a scalability problem for the ARs.

[Govind] An AR only needs to keep information about its handover neighbors..
 not every AP/AR in the domain (considering only the intra domain case). 
So why is there a scalability issue here? OTOH, there may be scalability/availability
issues for the server for the very reason that you mention. 
 Also, if the server approach also stores the information
that it gets in a local cache, the amount of information that is stored
is the same. 

> 3) It requires a dedicated network element for CARD, that is, the reverse
> address translation server. The requirements draft says it is not allowed.
>

Right, well maybe the requirements are in error here. Why was this requirement
put in? The IESG has not approved the requirements yet, BTW.

[Govind] I agree that the IESG is still considering the draft, but the requirement 
draft has passed WG last call, therefore I don't see the reason (for sake of progress) 
why we should debate this issue now, unless ofcourse if the IESG has issues with this. 

> 4) Scalability:
> Since L2 address does not come with any domain identity typically, I am not
> sure whether the reverse address translation can work inter-domain. Whenever
> the local domain server cannot find a matching entry, it will have to
> forward the query to all of the federated domains' servers. It does not look
> scalable.
>

As Pat mentioned, the interdomain problem is out of scope.

            jak

_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby
_______________________________________________
Seamoby mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/seamoby

---

From: "James Kempf" <[email-masked]>
Date: Tue, 21 Jan 2003 15:21:12 -0800

> that it gets in a local cache, the amount of information that is stored

How does an AR  know what is a handover neighbor or not, independently of the MN
providing this information as part of CARD? The information provided by the MN
establishes wireless connectivity via handover between this AR's APs and another
AR's APs. The authenticated information provided by an authorized server or an
interrouter prototol provides information on what are valid AP to AR mappings
for this service provider. These are not the same, and you cannot deduce one set
of information from the other.

> why we should debate this issue now, unless ofcourse if the IESG has issues
with this.

OK, so it would be interesting to see some scalability figures here, how does
the server based v.s. router based protocol scale? The scalability may not be
such a problem, and there may be ways of limiting the amount of information that
is propagated. From a robustness standpoint, and interrouter protocol might be
preferable, since there is no single point of failure, but I think scalability
might argue in the opposite direction.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 21 Jan 2003 15:21:12 -0800

jak