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

From: [email-masked]
Date: Thu, 13 Mar 2003 16:59:45 -0500

Bogus entries in cache also means that AR indulges in inter-AR capability and update exchange with bogus ARs, and hence, it has bearing on router processing overhead. I do not know if this matters a lot as there are no numbers available on frequency and size of those capability updates. - Hemant

-----Original Message-----
From: ext James Kempf [mailto:[email-masked]]
Sent: Thursday, March 13, 2003 4:47 PM
To: Eunsoo Shim; [email-masked]
Subject: Re: [SeaMoby] Topic #3: Cache contamination

Cache contamination is only an issue if it results in an MN getting a wrong
mapping, where a wrong mapping means that the MN presents the AR with an AP
address for an AP that it is hearing, and it gets back an presumptive AR address
that is not a GAAR (Geographically Adjacent AR) or that is not a valid AR. If a
legitimate MN always presents an AP address that it is hearing, then the AP is a
GAAP (Geographically Adjacent AP). If the source of the mapping information
(either interrouter ala dycard or backend database ala DT draft) always returns
a correct AP to AR mapping, then the MN cannot possibly get a mapping back for a
router that is not a GAAR or a valid AR.

The issue of nonGAAR mappings consuming cache space can be handled by aging out
cache entries. If the probability that a cache entry is dropped depends on the
number of MNs that report the AP, then attacks will be quickly flushed. For
example, suppose that the probability that a cache entry gets dropped at time T
is equal to 1/n, where n is the number of MNs reporting the AP at time T-1. Then
if a single MN mounts an attack, its bogus cache entry is flushed every time.
Thus, the cache need only be sized slightly large than the expected number of
GAAP to GAAR entries.

In short, a properly specified cache timeout algorithm, together with an
authoritative source of AP to AR mappings should handle it.

            jak

----- Original Message -----
From: "Eunsoo Shim" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, March 12, 2003 1:08 PM
Subject: [SeaMoby] Topic #3: Cache contamination

> Hi,
>
> Since we don't have much time until the IETF meeting next week, I think it
> would be better to check important points in the mailing list before
> off-line discussion for a short time during the meeting.
> As always pointed out, security is a big concern.
> It was pointed out there was no way to prevent cache contamination in the
> server approach. Scope-ID was claimed as a solution but it was not really
> explained in my understanding.
> I look forward to an explanation of how cache contamination can be prevented
> in the server approach.
> Regards,
>
> Eunsoo
>
> _______________________________________________
> Seamoby mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/seamoby
>

_______________________________________________
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: Thu, 13 Mar 2003 14:58:32 -0800

> Bogus entries in cache also means that AR indulges in inter-AR capability and
update exchange with bogus ARs, and hence, it has bearing on router processing
overhead. I do not know if this matters a lot as there are no numbers available
on frequency and size of those capability updates.

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.

So, I don't see how interrouter capability and update exchange are affected.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Mar 2003 14:58:32 -0800

jak

---

From: "Dirk Trossen" <[email-masked]>
Date: Fri, 14 Mar 2003 08:05:50 -0500

Hi James,

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.

[DOT] Isn't it the issue how the AAPL (we have a new term now??) is
determined?
In the server approach, one entry after another is retrieved from the
server (including
some retrievals that are not successful or unnecessary, i.e., bogus
APs). In the dycard
approach, the list is generated through learning. The only way to have
no interaction beyond
the server in order to compare AP against AAPL after receiving AP id
is to entirely download all possible APs of the GAARs a priori to the
AR. That's what I said a few days ago, and it basically results in a
administrator approach. However, the administrator is not only
required for the authentication of the APs (this is done already
today) but for the determination of what ARs are adjacent, something I
though we want to avoid, when I recall the issues draft correctly.

Dirk

> address for an AP that it is hearing, and it gets back an
presumptive AR
address
> that is not a GAAR (Geographically Adjacent AR) or that is not a
valid AR. If
a
> legitimate MN always presents an AP address that it is hearing, then
the AP is
a
> (either interrouter ala dycard or backend database ala DT draft)
always
returns
> a correct AP to AR mapping, then the MN cannot possibly get a
mapping back for
a
> The issue of nonGAAR mappings consuming cache space can be handled
by aging
out
> example, suppose that the probability that a cache entry gets
dropped at time
T
> is equal to 1/n, where n is the number of MNs reporting the AP at
time T-1.
Then

---

From: "Dirk Trossen" <[email-masked]>
Date: Fri, 14 Mar 2003 08:05:50 -0500

Hi James,

Dirk

presumptive AR
address
valid AR. If
a
the AP is
a
always
returns
mapping back for
a
by aging
out
dropped at time
T
time T-1.
Then

---

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

Dirk,

> though we want to avoid, when I recall the issues draft correctly.

Even with Dycard there will need to be some authoritative source of information
about which APs are on the AAPL. I quote from the Dycard draft (pg. 5):

    First, nAP must be authorized as one of nAR's local access points. This can
be achieved through
    a managed list of APs currently attached to nAR, or by a larger set of APs
that could possibly be
    attached over a given period of time. The size and variability of this
authorization list is
    controlled by the ARs administrator. A larger set of authorized APs provides
a higher level of
    reconfigurability, but also increases the possibility of malicious MNs
polluting the AR's PNC.

The list could be maintained on a server and pushed periodically, just as in the
so-called server based approach.

The difference between the server approach (I don't like that name, but let's
use it for now) and Dycard is that in Dycard, the AR validates its own APs
against the list, whereas in the server approach, the AR validates the GAAP
against a list of allowed APs in some localized area. The issue of memory size,
which some have brought up, appears irrelevant because even in Dycard the list
can be larger than the set of authorized APs, as the above text indicates.

Or am I missing something?

            jak

---

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

Dirk,

            jak