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

From: [email-masked]
Date: Fri, 14 Mar 2003 16:44:39 -0500

OK, you are right if MN has assigned bandwidth slice for which it is paying for. - Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Friday, March 14, 2003 12:23 PM
To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston); [email-masked]; [email-masked]
Subject: Re: [SeaMoby] Topic #3: Cache contamination

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
>
> -----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: "Eunsoo Shim" <[email-masked]>
Date: Fri, 14 Mar 2003 16:48:53 -0800

Well, there are various pricing models.
Also we are doing engineering. Being free does not mean we can abuse it.

Eunsoo

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

OK, you are right if MN has assigned bandwidth slice for which it is paying
for. - Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Friday, March 14, 2003 12:23 PM
To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston);

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]>;

> 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
needed
solutions.
about this replacement
the number
and more
each MN has
scenario,
cache entries of
communicate
capabilities
non-zero probability
bad

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 14 Mar 2003 16:48:53 -0800

Eunsoo

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Friday, March 14, 2003 12:23 PM
To: Chaskar Hemant (NRC/Boston); Krishnamurthi Govind (NRC/Boston);

Hemant,

I don't understand.

            jak

----- Original Message -----
From: <[email-masked]>
To: <[email-masked]>; <[email-masked]>;

needed
solutions.
about this replacement
the number
and more
each MN has
scenario,
cache entries of
communicate
capabilities
non-zero probability
bad