Subject: RE: [SeaMoby] Topic #3: Cache contamination

From: Singh Ajoy-ASINGH1 <[email-masked]>
Date: Fri, 14 Mar 2003 13:53:42 -0600

-----Original Message-----
From: Eunsoo Shim [mailto:[email-masked]]
Sent: Friday, March 14, 2003 4:33 PM
To: Singh Ajoy-ASINGH1; 'James Kempf'; [email-masked];
[email-masked]; [email-masked]
Subject: Re: [SeaMoby] Topic #3: Cache contamination

> > The first topic is the main thing of this thread. I think the server
> > approach cannot filter out false information or prevent cache
> contamination.
> > I think Dycard can make cache contamination very difficult.
> >
>
> AJOY->Why not ? I am confused here.  Could you please explain why do you
> think so?
>

In the server approach, MN sends the L2 address of an AP to the current AR.
Then the AR retrieves the L2-L3 mapping entry from the server and puts it in
its cache. There is no check whether MN received the beacon of the AP
within the
coverage area of the current AR. So MN can send L2 address of any AP which
is registered in the server and thus the cache of the AR can contain all the
L2-L3 mapping entries even though some of them are not of CARs of the
current AR.

AJOY-> What is the probability that a malicious MN will send fake AP 
id which is also stored in the server ? I am really having hard 
time imagining any real scenario like this. 

Obviously scope-id is not helpful in verifying the information from MN.

AJOY-> Scope id is used to avoid the cache overflow problem. I do 
not see  how this can cause any cache overflow if the router cache is 
appropriately sized to store entries for all the routers belonging to the
scope. 

Now please can you explain how this can be prevented in the server approach?

AJOY-> BTW, I have a cache contamination question about dycard. Let us
assume that 
a fake MN has some collaboration with fake router which is 
also connected to the internet and the fake MN sends 
a message  to the current AR indicating that fake router 
is the valid CAR ?  How the dycard assures that it 
does create an entry in its local cache?

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

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 14 Mar 2003 15:12:29 -0800

> time imagining any real scenario like this.

[eunsoo] We are talking about malicious MNs, that is, malicious human beings
actually. They can find out AP L2 addresses in the domain by simply walking
around. And they can use the information to fill the cache with the L2
addresses. So probabality is not an issue here.

> appropriately sized to store entries for all the routers belonging to the
[eunsoo]Right. I am pointing it because it was claimed as if scope-id would
prevent cache contamination. If nobody claims that scope id prevents cache
contamination, then we can skip this.

> does create an entry in its local cache?

[eunsoo] To defeat the attack, a simple approach is to accept only
authorized ARs as CARs. There are many ways to check authorization of ARs.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 14 Mar 2003 15:12:29 -0800

Eunsoo

---

From: Robert Chalmers <[email-masked]>
Date: Fri, 14 Mar 2003 12:18:03 -0800

Singh Ajoy-ASINGH1 wrote:

<snip>
> does create an entry in its local cache?
It is clearly stated in the draft that the two routers must mutually
authenticate one another with the explicit authorization to perform
CARD. Are you assuming that this fake AR can in some way authenticate
and authorize itself with respect to the attacked AR? If not, the
question is moot. If so, then I would question your
authentication/authorization scheme.

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: Fri, 14 Mar 2003 12:18:03 -0800

<snip>

enjoy,
bob

 Robert Chalmers