Subject: [SeaMoby] Topic #2:Do we need a server for CARD

From: "Eunsoo Shim" <[email-masked]>
Date: Tue, 11 Mar 2003 14:47:42 -0800

Hi,

Currently a series of discussion about DoS attack is going on about CARD.
Also we had lots of discussion about possible problems about the server
approach.

But I'd like to raise a more fundamental question about the server approach
taken in the DT draft.
Dycard shows that CARD is possible without introducing any server which
causes concerns about reliability and scalability.
Then why do we need the server at all? Or why do we have to introduce the
server for CARD?
I look forward to hearing the necessity of introducing the server before how
the server approach can or cannot defend certain threats or resolve certain
issues.
Regards,

Eunsoo

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

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 14:39:10 -0800

Why are these approaches mutually exclusive?

One of the drawbacks of Dycard is that it needs a learning period. Naturally,
the ISP can hire somebody to walk around and seed the cache, but that's
expensive. A server could prime the cache in the router with a collection of
AP/AR mappings that may not be geographically adjacent, but over time the ones
that aren't would drop out. Thus, the ISP would not have to go through the
timeconsuming task of classifying whether they APs are geographically adjacent.

After the server has been used to initially populate the cache, any changes
would be propagated directly by CARD.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 11 Mar 2003 14:39:10 -0800

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 13:00:57 -0800

> would be propagated directly by CARD.

[eunsoo] As Govind and Dirk pointed out, the first handoff between two ARs
leads to populating the cache with an entry for the newly discovered CAR in
Dycard.
If you claim that the server will be used only for initial populating the
cache at ARs, please clarify difference from the DT draft. The DT draft does
not say each AR will download a bunch of L2-L3 mapping information from the
server in the beginning of its operation. It will download one by one as MN
requests the mapping or reports a new BS L2 address.

The only difference between Dycard and the server approach in the learning
period is that MN may be able to do fast handoff for the very first handoff
between two ARs in the server approach while MN will have to do slow handoff
in Dycard. Well, if we are talking about ISP, I don't think they just
install a box and start commercial services. They will go through many
stages of network tests including roaming support. So most likely initial
discoveries will be done during the process and thus they would not feel any
concern for the impact of the learning period for consumers. If we are
talking about more ad-hoc and casual network deployment, I am not sure the
slow handoff for the very first handoff is such a big concern, let say, for
corporate networks or campus networks. I don't think it justifies
introducing a sever.

Also even if an ISP wants populating the cache by the information from the
server, they cannot tell exactly which entry should be inserted into a cache
unless they know exactly the radio map of the base stations. Well, all this
work is to remove such requirement. Then what they do only is just copying a
bunch of entries from the server to the cache as you suggested. If really
they want to do such a thing, they can use many existing tools. For example,
we can simply define MIB for CARD and they can use SNMP for setting the
values for CARD. This should not affect the fundamental structure of the
protocol. Actually it should be independent of the CARD protocol. Thus it
should not be a part of the CARD protocol except MIB definitions. Defining
MIB does not bring in any need of a server, of course.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 13:00:57 -0800

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 10:30:41 -0800

The server will allow an AR to determine which APs are authorized. The dycard
draft has nothing about this. This is an important security measure, though not
directly related to exchanging the CAR information.

        jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 10:30:41 -0800

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 13:47:57 -0800

> directly related to exchanging the CAR information.
[eunsoo] The routing protocol (for the wired Internet) has a similar
problem. They want to know whether a router is authorized to participate in
the route discovery. So for intra-domain routing protocols, usually shared
secret is proposed. Also Dycard assumes it in the expression that there
should be a security association between ARs. If we consider only
intra-domain communication between ARs, shared secret would be sufficient
for authorization and message authentication. If you consider central NMS
system that allows remote configuration of ARs, it would be very easy to
configure the shared secret among ARs. If there is no such thing, people do
the configuration by remotely logging into ARs. This one time configuration
removes concerns about scalability and reliability. You don't need a server
running up 24/7 for this authorization since you don't expect a new AR that
often.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 13:47:57 -0800

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 12:48:56 -0800

I obviously did not make myself clear.

There is need for some mechanism, independent of any interrouter exchange of
information, for a router to determine whether a particular AP is, in fact,
authorized. This mechanism functions as a trust root, if you will. That is what
I was referring to.

Or were you proposing a protocol between APs and ARs to allow the AR to validate
whether an AP is authorized?

            jak

---

From: "James Kempf" <[email-masked]>
Date: Wed, 12 Mar 2003 12:48:56 -0800

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 16:00:56 -0800

Well, I do not propose any protocol between AP and AR for authorization
check at this moment,
In general, AP is a L2 device and communication between AP and AR is L2
communication thus such a protocol would be specific to each L2 technology
unless we assume AP has an IP address.
For checking AP authorization, I'd say it is sufficient to have static
configuration for the list of authorized and associated APs at each AR as
Govind mentioned.

Also please note that Hemant pointed out the server is not meant to provide
authorization of APs.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 16:00:56 -0800

Eunsoo