Subject: Re: Issue 22: Part 2: Timestamp Delta time

From: Pekka Nikander <[email-masked]>
Date: Wed, 01 Oct 2003 12:43:35 +0300

[Resending to the list, apparently the list failed on
  me again.  Sorry if you see this multiple times.]

Jari Arkko wrote:

> I agree with Jon that it seems like it is still possible
> to fill the cache. The point is that attackers can come up
> with new (perhaps precomputed) CGA addresses, and the timestamp
> cache needs to be per source in multicast messages. Tuomas'
> CGA generation formula does prevent the attack if Sec > 0,
> but we may not be able to rely on that, or can we?
> 
> But there seems to be two ways to deal with unbounded
> caches, like the ones that exist for tracking something
> related to a the source address of a packet.
> 
> 1. Throw out entries.
> 2. Reduce the allowed clock difference.
> 
> In the past, I have assumed we are doing #2. Though I can't
> claim I have thought it through fully. Here's what #2 would
> do: if there is no lack of space, accept all messages and store
> all cache entries that have used a timestamp within Delta. If
> you can store only half of the entries that would be required
> for this, reduce Delta to half and remove those entries that
> were furthest away from the node's own time. If the attacker
> is sending you a constant stream of messages from new source
> addresses with exactly the right time, reduce Delta to 0.
> At this point, you can still communicate with legitimate peers,
> but only if they have exactly the same clock as you do. When
> new space becomes available, Delta can again be increased.
> 
> Does this work? You tell me...

I think that we basically have two distinct attack scenarios:

   1. There are a number of hosts on a link, and someone
      launches an attack.  The goal here is clearly make
      sure that the hosts can continue to communicate even
      if the attack is going on.

   2. There is an attack going on, and a new host arrives
      to the link.  The goal here is to make it possible
      for the new host to become attached to the network,
      inspite of the attack.

 From this point of view, it is clearly better to be very
selective in how to throw out entries.  Reducing Delta
is very discriminative against those hosts that have a
large clock difference, while an attacker can reduce its
clock difference into arbitrarily small.  Throwing out old
entries just because their clock difference is large seems
like a bad approach.

In my opinion, the exact algorithm for expiring cache entries
in the case of a full cache is clearly a local policy issue,
and should not be specified in the document.  However, it might
be a good idea to give some guidance for implementors.

It also looks like that all the previous ideas of reducing
Delta are really bad, since the attacker can easily select
its own Delta, and make it whatever small.  A better idea
seems to be to have a separate cache space for new entries and
old entries, and under an attack more eagerly drop new cache
entries than old ones.  One could track traffic, and only allow
those new entries that receive genuine traffic to be converted
into old cache entries.

It also looks like a good idea to consider the sec parameter
when forcing cache entries out, and let those entries with
a larger sec a higher chance of staying in.

--Pekka Nikander

--------------------------------------------------------------------
To unsubscribe from this list, send email with "UNSUBSCRIBE" in the
body to <[email-masked]>.
Archive: http://standards.ericsson.net/lists/ietf-send/maillist.html
--------------------------------------------------------------------

---

From: Jari Arkko <[email-masked]>
Date: Mon, 06 Oct 2003 17:04:11 +0300

> entries just because their clock difference is large seems

Ok, I'm convinced.

> those new entries that receive genuine traffic to be converted

Ok. We could perhaps say the following: "When there is a very
large number of hosts on the same link, or when an attack is
in progress, it is possible that the cache holding the most recent
timestamp per sender becomes full. In this case the node MUST
remove some entries from the cache or refuse some new requested
entries. The specific policy as to which entries are preferred
over the others is left as an implementation decision. However,
typical policies may prefer existing entries over new ones,
CGAs with a large Sec value over smaller Sec values, and so on."

> a larger sec a higher chance of staying in.

Yes.

--Jari