Subject: [Seamoby] CARD Draft

From: "James Kempf" <[email-masked]>
Date: Tue, 4 Mar 2003 11:17:43 -0800

Folks,

The CARD draft got hung up on an SMTP server and missed the deadline, but Marco
posted a public copy to the URL below. Please read and send comments to the
list.

     http://www.ccrle.nec.de/I-D/draft-ietf-seamoby-card-protocol-01.txt

            jak

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

---

From: Robert Chalmers <[email-masked]>
Date: Thu, 06 Mar 2003 14:17:52 -0800

For my own sanity as well as for some others on the mailing list, let me 
try to summarize some of the key points concerning the DT draft as it 
compares to a serverless, learning-based approach (dyCARD). I'll try to 
be fair, but I should note that I'm in favor of the latter approach.

1. What are the advantages of a server-based approach?

1.a. AR-AP mappings are known to be valid.
However, in a learning-based approach, each AR knows about its own AP 
mappings. So, why can't I ask the AR in question rather than the server. 
Won't the validity of the answer be equivalent?

1.b. AR-AP mappings are more convenient to manage.
Actually, the way I read the DT draft, the ARs register their AP 
mappings with the server. This implies that the management is not done 
centrally at the server. In any case, using a centralized server to 
manage the valid AP-AR mappings is a fine idea, but doesn't imply that 
the server must be part of the resolution process. Rather, it seems like 
a completely separate issue: how to manage configuration data (AR-AP 
mappings) for a large number of routers. There are a number of existing 
techniques for doing that, and they are orthogonal to how the mappings 
are used at the AR.

1.c. Populating the cache with an initial entry does not require handover.
This is the strongest argument for the server-based approach, but there 
are a number of issues that must be addressed to understand the true 
benefit available. First, the expectation of both techniques, 
server-based and learning-based, is that the cache is fully populated 
during steady-state operation. For the learning-based approach, if a 
AP-AR mapping does not exist, no help is available. In the server-based 
approach, the time to resolve the mapping with the server, as well as 
gather any necessary capabilities from the neighboring AR cannot be 
expected to complete prior to the information being needed for TAR 
selection.

Consider a MN moving through an AP's coverage area. Let's say from left 
to right for simplicity. Performing resolution early will most likely 
provide mappings and capabilities for the APs on the left of the 
coverage area, thus behind the mobile node. The APs to the right won't 
become "visible" until the MN approaches the righthand border (unless 
there is extreme overlap). At this point, the time necessary to resolve 
the new APs as well as decide to handover may be short. In short, early 
resolution won't gain you much in way of eventual targets, and late 
resolution requires cache hits.

So for both techniques, proper configuration of lifetimes (or even 
dynamic lifetimes as Dirk? suggested) are necessary to ensure viable 
response times. So, the real question is whether both techniques can 
maintain satisfactory cache fill ratios. This needs some experimentation 
  to confirm, but I think that the server-based approach may have a 
slight advantage here, and I do mean slight.

Just for note, there are techniques that can be used to improve the 
cache fill ratio of the learning-based technique. In particular, once 
one handover between two ARs occurs, they can exchange a list of 
attached APs as a special form of capabilities. This means that as long 
as handovers continue between the two ARs, no matter which APs are 
involved, all AR-AP mappings are maintained for the two neighbors.

2. What are the advantages of a learning-based approach.

2.a. No single point of failure.

2.b. No extra entity in the network necessary for the protocol to operate.

2.c. Cache entries actually represent neighboring AR/APs rather than 
simply valid AR-AP mappings.
This could be beneficial if we later wanted to allow a MN to query it's 
current router with a wildcard. The entries in the cache are known to be 
neighbors, and thus provide valuable information. This of course ignores 
the fact of malicious entries, etc. I'll address that in a bit.

2.d. The same protocol scales to the inter-domain case without change.

3. How secure are the two techniques.

3.a. Both techniques rely on an authoritative mapping between and AR and 
its APs. For the server-based approach this is the server. For the 
learning-based approach the authority lies at the individual ARs.

3.b. Both techniques rely on a cache to operate without unacceptable 
delay. Both techniques rely on MN reports to populate the cache. If we 
accept the fact that MNs may be malicious, the cache must be limited in 
size to eliminate the chance of exhausting AR memory. Once the cache is 
limited in size, malicious entries could replace valid entries thus 
causing a cache-miss. So, the only way to overcome this problem is to 
validate the cache entries prior to creation, or employ a very clever 
cache replacement policy.

3.c. The server-based approach cannot adequately validate MN reports 
prior to creating cache entries. Since the reports are simply MN 
requests for information, there is little to use for verification. The 
scope ID concept doesn't seem very applicable. It seems like the network 
admin would have to very carefully layout these scope IDs to match the 
overlapping coverage areas, which could change without having to change 
the network topoloogy (a big building is erected near a base station). 
Moreover, each AP may be part of many scopes, yes.

3.d. The learning-based approach validates the MN report. Since the 
report is based on a handover between two APs, the current AR checks 
whether the current AP is locally attached, the previous AR checks 
whether the previous AP is locally attached (AR-AP map validation), and 
the previous AR checks whether the MN was recently present (neighbor 
validation).

3.e. Other techniques, common to both CARD approaches, exist to limit 
the impact that a malicious MN can have on the contents of an ARs cache. 
In particular, an AR can limit the number of entries that any given MN 
can indirectly create.

3.f. Smart cache replacement policies should be implemented at the AR, 
no matter which CARD approach you choose. Cache entries derived from 
local information (learning-based) should be favored over remote info. 
Entries that are accessed more often for resolution should also be favored.

In the end, I don't think that the server is really necessary. It may 
provide a small benefit for keeping the cache full, but this is 
completely dependant upon the properties of the network and the dynamics 
of the MNs. Moreover, I think that the server-based approach is harder 
to secure against malicious mobiles. For the learning-based approach, an 
attack requires a large number of mobiles spread across numerous 
networks working in tight synchronization. For the server-based 
approach, a few local malicious mobiles could fill the current AR's 
cache with little effort.

enjoy,
bob

-- 
/****************************************************************

  Robert Chalmers
  UCSB Computer Science Doctoral Candidate
  Network and Multimedia Systems Lab (NMSL)

  "My heart is in the code, but my soul lies in the process"

  | [email-masked] || http://www.cs.ucsb.edu/~robertc/ |

*****************************************************************/

---

From: Robert Chalmers <[email-masked]>
Date: Thu, 06 Mar 2003 14:17:52 -0800

enjoy,
bob

  Robert Chalmers

---

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Mar 2003 16:59:12 -0800

Robert,

Thank you for your very clearly thought out and well reasoned comments. Some
responses below.

> In any case, using a centralized server to

Yes, this is a key point. The server shouldn't need to be involved in the
immediate resolution when an MN requests a mapping. That could be done from the
AR's cache.

However, if the mapping isn't in the cache, the AR must go to some
authenticatble source of information on what APs are authorized. That's the
point of the server. It acts as a kind of ACL list for APs.

> expected to complete prior to the information being needed for TAR

I view these approachs as complimentary. In a small, home network, the router
may have an ACL list of authorized APs built in and the server is not needed. In
a large corporate network, a sysadmin may find it easier to program the ACL list
into a server.

But, I think the ACL list is required somewhere. The AR can't simply trust
information provided by the MN without verifying that the AP is authorized. So a
pure learning based approach, without any information about whether an AP is
authorized, would not satisfy security requirements.

> involved, all AR-AP mappings are maintained for the two neighbors.

The performance aspects of this aren't the key issue, IMHO. The key issue is
security.

> cache with little effort.

A server provides a convenient way for enterprises and ISPs to configure their
network. I think it is important to have, but not part of the base draft.

That is why I have suggested it be moved out of the base draft. It is a
complementary technology used for large networks. Exactly how the AR verifies an
MN-offered AP as being authorized or not is out of scope for the base protocol.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 6 Mar 2003 16:59:12 -0800

Robert,

            jak