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

From: [email-masked]
Date: Fri, 14 Mar 2003 10:19:21 -0500

James,

[snip]
> Why do you say it assumes the server approach? The AAPL could 
> be programmed into
> the router through a Web page. It doesn't have to come from a 
> server. Something
> like the AAPL will even be needed in Dycard, else how does a 
> router know that an
> access point connected to it is authorized?
> 
[Govind] This is because the cache population schemes are different in the schemes. Therefore,
the effectiveness of any cache contamination scheme is different.

[snip]
> Right, the assumption here is that the probability of an 
> attack decreases
> according to the number of MNs involved. Remember, for an MN 
> to even get on the
> link, it must be auth/authz-ed. So, multiple MNs means a 
> bunch of the operator's
> authorized customers decided to get together and attack. 
> Maybe not such a
> completely outlandish idea these days, but a much lower 
> probablity event than
> one lone customer who is having a bad day and decides to 
> cause some mischief.

[Govind] I agree that the probability of more than one malicious user is lesser than one malicious user. 
However, if this is an inherent deficiency in a scheme that protects the protocol, 
then I believe in no time will more there be more than one hacker trying to bring down the system. 

> 
> >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.
> 
> Why do you assume the server scheme? The cache state would 
> need to be timed out
> for Dycard as well.
> 
[Govind] Because you have talked about adding cache entries based on APs 
sent in by the MN.

> >Consider this scenario,
> > 10 malicious MNs each report say 100 genuine non-GAAPs.
> 
> If I, as an operator, have 10 malicious customers, then I'm 
> pretty bad off.
> After that attack, they get their service cancelled forthwith.
[Govind] There is no way you can recognize the fact that they are
doing something malicious as they are reporting APs that 
are valid and authorized.

> OK, so its a hundred. How big is a cache entry? Let's be 
> conservative and say
> it's 1K (actually, it's probably a lot smaller). that's still 
> only 100K. Given
> Moore's law, that costs nothing.
[Govind] You have no control on what the cache size is yet. This depends on 
what capabilities are transferred, and their respective sizes. But
cache size is not the attack, increase in inter-AR communication
and subsequent processing is the problem.

> 
> The point is, it's not a million. The attack becomes less 
> probable and easier to
> detect the more entries.
> 
[Govind] My point is even a 100 depending what capabilities are
is a lot of unnecessary processing. Remember, the ARs are not there just for CARD
They are involved in other work too.

> It is all a matter of matching the threat. The highest 
> probability threat, in
> this case, is a single MN having a bad day and deciding to 
> try some mischief.
> Now if an average MN reports, say 2 or three APs and suddenly 
> the router starts
> to get a report of 100, it knows something is amiss. 
[Govind] The number of legal APs (including those from other domains) that a 
MN reports depends on the size of  the "cell" as well as the population of APs of
 other operators. By making
an unnecessary restriction on the number of APs we are just compromising
the protocol needlessly.

If 10 
> MNs each start
> reporting 100, it's time to call the Department of Homeland 
> Security. :-)

[Govind] Since you can't control the number of legal  APs around, any ratelimiting
has to be set to a resonably high number (whatever that may be). Otherwise, 
you stand a chance of MNs just reporting APs out of your domain and the network
rejecting the its own AP info sent in by the MN. Thats why I said initially that
ratelimiting in the server based scheme is more difficult.

[Govind]
> Sure. There are always false positives. But typically any one 
> GAAP will be seen
> by more than one MN. And, there are other ways to reduce the 
> probability of
> flushing good entries, for example, using a weighed moving 
> average of reports.
[Govind] Clearly this fails as the number of malicious MNs increase.

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

---

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

Govind,

I'm not convinced Dycard would do any better.

As the number of malicious MNs increases, the number of PNE messages will
increase. Thus, the load on the routers increases in any event. If there are
several millions of malicious MNs bombarding the router with RM messages, the
backhaul will fill with PNE messages as far as I can tell. I assume Dycard is
using a cache for confirmed APs also, so that no PNE message would be sent if
the RM resulted in a hit with a known, good GAAP. Or am I misunderstanding how
Dycard works?

You mentioned previously you had done a simulation on this. Could you or another
of the Dyhard Dycard Team provide some information about what the numbers look
like, or a URL to a published paper?

            jak

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

---

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

Govind,

            jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 14 Mar 2003 13:09:52 -0800

I think we should distinguish two things.

1) Whether the proposed mechanism can filter out false information from MN
and thus prevent cache contamination.
2) What is the impact of malicious MN's bombarding AR with false
information.

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.

The second topic is more related to DoS attack. We talked about it already.
In Dycard, if the AR can know about MN's handoff events, it can limit MN's
report as one per handoff. If not, we need rate limiting. In the server
approach, we need rate limiting. In the case of the sever approach, if there
is a bogus AP (unauthorized AP) transmitting different beacons continuously,
MN will lose the chance to report the L2 address of an authorized AP under
the rate limiting policy.

Anyway I think we should stick to the first topic in this thread and put the
second topic in the DoS attack thread.

Eunsoo

----- Original Message -----
From: "James Kempf" <[email-masked]>
To: <[email-masked]>; <[email-masked]>;
<[email-masked]>; <[email-masked]>
Sent: Friday, March 14, 2003 9:16 AM
Subject: Re: [SeaMoby] Topic #3: Cache contamination

> > [Govind] This is because the cache population schemes are different in
the
> schemes. Therefore,
> > then I believe in no time will more there be more than one hacker trying
to
> bring down the system.
> > is a lot of unnecessary processing. Remember, the ARs are not there just
for
> CARD
> > MN reports depends on the size of  the "cell" as well as the population
of APs
> of
> > rejecting the its own AP info sent in by the MN. Thats why I said
initially
> that

---

From: "Eunsoo Shim" <[email-masked]>
Date: Fri, 14 Mar 2003 13:09:52 -0800

Eunsoo

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

the
to
for
of APs
initially

---

From: Robert Chalmers <[email-masked]>
Date: Fri, 14 Mar 2003 11:10:44 -0800

James,

<snip>
> You mentioned previously you had done a simulation on this. Could you
> or another of the Dyhard Dycard Team provide some information about
> what the numbers look like, or a URL to a published paper?
> 
The simulations we did weren't concerning the security aspects of the
protocol. Rather, we were looking at the advantages of using
higher-level info (capabilities) to improve handover performance. We
also looked at how well the learning-based scheme performed in relation
to the rate of handovers, the probability of errors, etc.

At this point I'm not comfortable with releasing the paper publically
since we just submitted it to a conference for review.

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 11:10:44 -0800

James,

<snip>

enjoy,
bob

  Robert Chalmers

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 11:17:58 -0800

Eunsoo,

I agree with this separation.

> and thus prevent cache contamination.

This is Issue 4. I don't like the term "cache contamination" because it is not
possible to actually cause a false GAAP to GAAR resolution. The issue is more
one of cache sizing and robustness, not one of a failure of the protocol to
properly operate.

> 2) What is the impact of malicious MN's bombarding AR with false

This is Issue 3.

> I think Dycard can make cache contamination very difficult.

I'll let the DT members comment on this.

> report as one per handoff.

The AR might not. It doesn't for 802.11, for example.

I've moved rate-limiting to a separate thread.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 11:17:58 -0800

Eunsoo,

This is Issue 3.

            jak

---

From: Robert Chalmers <[email-masked]>
Date: Fri, 14 Mar 2003 11:32:23 -0800

Robert Chalmers wrote:
> James,
> 
> <snip>
> 
>> You mentioned previously you had done a simulation on this. Could
>> you or another of the Dyhard Dycard Team provide some information
>> about what the numbers look like, or a URL to a published paper?
>> 
> also looked at how well the learning-based scheme performed in
> relation to the rate of handovers, the probability of errors, etc.
> 
Actually, we did look at one of the security aspects, limiting cache
entries per MN. We found that limitiing to 2 entries has almost no
effect on the performance of the learning protocol.

ttyl,
bob

  Robert Chalmers

---

From: Robert Chalmers <[email-masked]>
Date: Fri, 14 Mar 2003 11:32:23 -0800

ttyl,
bob

  Robert Chalmers

---

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

> one of cache sizing and robustness, not one of a failure of the protocol
to

[eunsoo] Well, we have used this term for a while. But now you want to
change it. What do you suggest?
Anyway, it's a failure of CAR discovery. The first task of the protocol is
discovering CARs of a given AR. If the protocol could not provide the list
of CARs for the AR, it failed to do its job.

I am repeating this. The application of CARD is not just L2->L3 mapping. Let
me repeat the example scenario where the false entries are harmful.
MNs have two interfaces, let say, GPRS and 802.11b. Since 802.11b interface
consumes lots of power even during idle mode, MN wants to keep it down while
it is not used. But MN also wants to know whether it should start scanning
802.11 channels for APs. Here CARD becomes useful. The AR in the GPRS
network provides list of CARs to the MN. The information tells that there is
an AP with 802.11b interface but it is not true. Then MN just turns on its
802.11 interface and consumes its power for nothing.

> The AR might not. It doesn't for 802.11, for example.

[eunsoo] 802.11 AP can tell when a MN arrived. Then it can tell its AR about
it. Or AR can poll the APs for the events.

Eunsoo

---

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

Eunsoo

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 13:05:50 -0800

> of CARs for the AR, it failed to do its job.

How about "mapping geographical accuracy"?

> 802.11 interface and consumes its power for nothing.

Ah, right I had forgotten that issue. Thanx for reminding me.

So there are some potential consequences to false information. Though, this
particular consequence is not fatal, just inconvenient. That is, the MN won't
end up handing over to an AP that is a rogue and getting it's traffic stolen,
nor will it get dropped because it handed over to an AP that isn't there, right?
Presumably, when it starts the 802.11 handover, it will do the standard L2 scan
for APs to determine whether a particular AP is there, then discard any CARD
information that is not accurate.

Though I have in the past been a proponent for this use of CARD, there are some
issues with the granularity of resolution. Suppose my GPRS cell is 10 km in
radius and there are 2 disconnected hotspots 100 m in radus. Unless some real
geographical information like GPS or triagulation is used (which isn't in any of
the proposals), the network can only do an approximate job. So the GPRS router
would end up providing the MN with CARD information, even though the 802.11
hotspot might not be available.

But I agree it would be convenient if we could find a way to solve this issue.

> it.

But how? There is no protocol for that (though I personally think there should
be).

>Or AR can poll the APs for the events.
>

 Polling isn't real time, or, if it is, it would consume router cycles.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Fri, 14 Mar 2003 13:05:50 -0800

jak

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sat, 15 Mar 2003 08:51:43 -0800

> How about "mapping geographical accuracy"?

[eunsoo] Well, it is quite confusing and vague.
If a new name is necessary, I'd say "CAR table corruption or contamination".
Cache is a term too specific to the server approach.

> But I agree it would be convenient if we could find a way to solve this
issue.

[eunsoo] What is a matter of convenience and what else is a matter of
vitality?
Maybe battery lifetime is a matter of convenience for some people but more
than that for other people.
I understand it is one of the most significant issues in wireless
communications.

>  Polling isn't real time, or, if it is, it would consume router cycles.

[eunsoo]Information about handoff events is all about L2 triggers.
You advocated for L2 triggers for fast handoff, didn't you?
If they are feasible, certainly we can take advantage of them.

Eunsoo

---

From: "Eunsoo Shim" <[email-masked]>
Date: Sat, 15 Mar 2003 08:51:43 -0800

Eunsoo