Subject: [SeaMoby] Topic #3: Cache contamination

From: "Eunsoo Shim" <[email-masked]>
Date: Wed, 12 Mar 2003 13:08:00 -0800

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Mar 2003 13:46:59 -0800

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

---

From: "James Kempf" <[email-masked]>
Date: Thu, 13 Mar 2003 13:46:59 -0800

jak