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

From: [email-masked]
Date: Fri, 14 Mar 2003 10:36:48 -0500

I just realized that there is one more implication of cache contamination, its on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP associated with non-GAAR, its capabilities are downloaded to MN, though MN is never going to be handed off to non-GAAR. - Hemant 

-----Original Message-----
From: ext [email-masked] [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 6:44 PM
To: [email-masked]; Chaskar Hemant (NRC/Boston); [email-masked]; [email-masked]
Subject: RE: [SeaMoby] Topic #3: Cache contamination

> I'm not sure I understand the attack.
> 
> If an attacker sends a completely bogus AP, the AR compares 
> against the AAPL
> (Authorized AP List) and rejects. 
> If an attacker sends an AP that is not bogus but is not a 
> GAAP, then it will
> pass the AAPL test but it will remain in the cache for one 
> iteration and be
> flushed aftewards.
[Govind] This is assuming a particular cache replacement policy and assumes
the server approach. I think we should first settle whether the server is needed
or not before coming to cache contamination and other cache related issues. 
However, if we are not going to do that, then we should propose how any
scheme involving protecting the cache works in either of the proposed solutions.
> 
> So, I don't see how interrouter capability and update 
> exchange are affected.
[Govind]  First thoughts about this cache replacement policy. I will think about this replacement
policy more later.. Its been a long day already, so sorry if I'm wrong :)

If the number of malicious MNs increase, then wouldn't you have an increase of the number
of entries? Also, they might not be removed from the cache. More such entries and more
the unnecessary capability messages. Note, if we are using the server scheme, each MN has
the possibility of reporting a large number of such non-GAAPs. Consider this scenario,
10 malicious MNs each report say 100 genuine non-GAAPs. Also assume that
each AP is assigned to a different AR. Further assume that
you have a limit of 100 reports per MN.  In your scheme, the chance
of it being not removed is (1-1/10)  = 0.9. There is a 90% chance that 100 cache entries of
non GAARs are in the cache after each flush. So the current AR will communicate
unnecessarily with 100 non CARs. Depending on the size and frequency of capabilities
exchanged you do have an unnecessary burden on the ARs. You will never be able
to detect this and yet keep exchanging messages between non-CARs.

Another point, by flipping a coin as you suggest
based on the number of MNs reporting, and removing the cache entry, you have a non-zero probability
of (1 - 1/ n_{good MNs} ) that the cache entry is removed. This policy therefore has the chance that you
keep relying on the server, thus increasing the average response time. 
Instead with a better scheme to reduce the possibility of incorrect cache entries along with lifetimes
 to remove bad entries may be a better approach. I'm not saying that this is a bad
cache replacement scheme yet but I'll think about this tomorrow.

-Govind.
_______________________________________________
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: Fri, 14 Mar 2003 09:22:38 -0800

Hemant,

I don't understand.

If an attacking MN reports something that is not a GAAP, then sure, maybe it
gets some junk, but so what? If the MN wants to be so antisocial, then it gets
to deal with the results. As for wireless bandwidth, I assume the wireless
network is enforcing the MN's QoS so it only gets the amount of bandwidth it
paid for. As for the router, as mentioned in Issue 3 on the issues Web page, the
protocol should include a provision for rate limiting and a provision allowing
the router to selectively drop packets in order to deal with a spike in service
requests.

            jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, March 14, 2003 7:36 AM
Subject: RE: [SeaMoby] Topic #3: Cache contamination

> I just realized that there is one more implication of cache contamination, its
on the wireless bandwidth. When there is non-GAAR in cache and MN reports an AP
associated with non-GAAR, its capabilities are downloaded to MN, though MN is
never going to be handed off to non-GAAR. - Hemant

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 09:22:38 -0800

Hemant,

I don't understand.

            jak