Subject: RE: [Seamoby] Comments on DT CARD draft

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Thu, 6 Mar 2003 15:57:21 -0600

Hello Govind,
Please find my inline reply.
Regards,
Ajoy 

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]
Sent: Thursday, March 06, 2003 12:51 PM
To: Ajoy Singh; [email-masked]
Subject: RE: [Seamoby] Comments on DT CARD draft

Hi Ajoy,
My replies are embedded.
-Govind.

I meant every time cache times out, your proposed scheme (dycard) 
will perform slow handoff. But in case of server based approach this may 
not be the case. In server based approach, AR cache is updated when a mobile 
node scans the neighboring channel and detects a new link layer id. In this it is likely 
that the server cache will be updated prior to layer 3 handoff. 
Hence, the current AR may not be required to query AR server during critical
path of handoff. Also, by properly placing the server with 
respect to AR, you can minimize the round trip delay with server.

[Govind] Why will cache time out if there are frequent handovers. Plus once two ARs 
have recognized each other as CARs, why can't we setup a refresh procedure. 
Doesn't that take care of it?

AJOY-> Sure you can but I think you are complicating the protocol. 
The L2-> L3 mapping is a simple problem and we should keep it 
simple. 

Secondly, what do you mean "properly placing the server
with respect to the AR, we minimize the round trip delay". 

AJOY-> BTW, you do not need do this because L2->L3 mapping 
is initiated by link layer trigger that happens 
prior to L2 handoff. Hence, I do not see any reason 
to optimize this RTT. This is probably noto relevant 
in this context.

The scope-id reduces the cache contamination problem, the 
potential growth of AR cache is bounded. This will eliminate the problem 
introduced due to unbounded cache growth. For example, in case of dycard, 
you might have a situation where the AR cache will overflow if a mobile node 
keeps injecting wrong information to the AR. This will cause 
AR to either crash or remove the old  useful cache entries. Potentially 
this will create a situation where AR will loose valid cache entries 
to populate invalid entries. Is it not correct? 

[Govind] First, if you read dycard you will see that the "overflow" problem
that you talk about is almost impossible. We do this by a scheme wherein
we restrict the number of entries that can be created by each MN. 

AJOY-> I am not sure just limiting the number of entries created by 
single MN will fix this problem. The attacker can use multiple MN to 
launch such attack. Whereas this type of attack is not possible 
when scope-id is used? 

Also, I don't think your scope-id solution anyway reduces the problem. You
are saying that if we have "n" incorrect entries in the cache it is not 
a problem, where n can be arbitrarily large right (atleast w.r.t the cache size)
? I don't quite agree with that.

AJOY-> You can configure the appropriately sized 
cache at AR if you know the number of ARs being covered 
by a given scope-id. This will also ensure that cache 
overflow would never happen. Hence, 
it will be impossible for an attacker to inject 
fake message to remove the useful entries from the 
AR. I do not see how will you achieve this in 
dycard?  

[snip]

Won't next handoff performed by dycard will
be slow after cache timeout? BTW, 
this is necessarily not a problem with server based approach. 
The AR cache is updated when a mobile node scans the neighboring 
channel and detects a new link layer id. In this it is likely 
that the server cache will be updated prior to layer 3 handoff. 
Hence, the AR may not be required to query CARD server during critical
path of handoff. Also, by properly placing the server with 
respect to AR, you can minimize the round trip delay with server.

[Govind] I disagree with your premise that dycard introduces frequent
cache misses. This statement is terribly flawed. Rather, I think
in the steady state the server is useless. If you have a proper
cache update policy and make sure DoS is hard, we are through.

AJOY-> This is difficult to justify without proper data from 
real deployment or simulation.  Do have any real data to 
prove me otherwise? 

[Govind] Yes, the first handover case. So are you saying the cost of the first handover being not seamless is worth introducing a new element in the network? 

Could you please explain how dycard plans to avoid the problem of 
cache overflow? 

[Govind] Sure, we restrict the number of entries that each MN can create in the server.
The number of entries is configurable.
We make sure that the MN was actually present in the previous ARs domain in the "recent" past.
Where "recent" is a variable that can be configured. 

AJOY-> This does not fix the problem. The attacker can use multiple MN to launch 
such attack. Do you believe that service provider would deploy an 
such network that can be disabled by few malicious attackers? 

It is relatively inexpensive to provide redundancy of a
server that only does L2->L3 mapping. This function can be 
easily piggybacked upon existing high availability server 
platform. 

[Govind] I don't disagree with the fact that it might be relatively
inexpensive to provide reliability. 

AJOY-> OK 

But look at the cost in terms
of any benefit you receive from the server. It doesn't add up.
Plus, you have consistency issues to take care of when you have redundancy.
Instead, why not have a server at each AR then?

AJOY-> What is the cost? You can deploy the CARD server on existing 
server platform for example AAA platform. I do not see any extra cost
of doing this. 

[Govind] What advantage do you have by manually configuring scope-ids? 
If that is the case, why don't you program it in routers themselves
and make themselves aware of their scope-id? 

AJOY-> Well you can. This means that every time you configure 
a router, you have to configure its scope-id. Whereas 
in former case, you can do it at once?  

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 6 Mar 2003 17:21:25 -0800

> launch such attack. Whereas this type of attack is not possible
(eunsoo) Ajoy, can you please provide a scenario of how scope id prevents
cache contamination?

> AR. I do not see how will you achieve this in

(eunsoo) Now you are proposing the network admin should configure each AR
with knowledge of the number of ARs covered by scope id. I am not sure how
much the work load is different from configuring each AR with the whole
L2-L3 mapping table from the first place. Whenever you reconfigure scope id,
you may have to do this for lots of ARs.

In the case of dycard, it will make it very difficult to cheat the AR
because two cooperating ARs (previous AR and current AR) will verify the
information provided by the MN. Also it allows only one report from each MN
per handoff. You said an attacker could use multiple MNs. Certainly it
requires lots of effort even after assuming the attacker can cheat the two
cooperating ARs.

Please be aware that you would need multiple scope id per AR. For you don't
want to limit the CARD operation into separate scopes.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Thu, 6 Mar 2003 17:21:25 -0800

Eunsoo