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

From: Jari Arkko <[email-masked]>
Date: Sat, 20 Sep 2003 16:41:19 +0300

Pekka Nikander wrote:
> Issue 22 deals with timestamp validity period and avoiding a
> cache filling DoS attack.  For background, see
> http://www.arkko.com/publications/send/issues/issue22.txt
> 
> My (perhaps flawed) analysis of the issue boils down to
> two points:
> 
>   1. The value for the timestamp delta
> 
>   2. What to do if the ND cache becomes full
> 
> I'll describe these separate messages, focusing on the
> the Delta time here.
> -----------------------------------------------------------------
> 
> The current specifications states the following
> 
>  >  Recommended default value for the allowed Delta is 3,600 seconds.
> 
> Francis Dupond made a comment that this is far too large.
> 
> The function of the Delta value can be described as follows:
> 
>  - A larger Delta allows hosts with differently running
>    clocks to communicate, while a small Delta requires
>    better clock synchronization.
> 
>  - A larger Delta potentially requires more memory, since
>    it may require the host to remember more other hosts.
> 
>  - A larger Delta exposes the host to replay attacks in the
>    case that its cache becomes full, thereby requiring it
>    to accept ND messages from new hosts.
> 
> The situation that seems to be most worrisome is one where
> an attacker fulfils the cache, thereby forcing the host to
> drop some cache entries, and then launches a replay attack.
> 
> It looks like the suggestion in the Part 1 message of this
> issue plugs the attack.  If so, the exact value of Delta
> is not a concern from the memory usage and DoS/replay attack
> point of view.

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...

--Jari

--------------------------------------------------------------------
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: Pekka Nikander <[email-masked]>
Date: Fri, 19 Sep 2003 13:35:21 +0300

Hence, it looks like that the default value for Delta becomes
mostly a policy issue.  On the other hand, there seems to be
some possible replay attack scenarios against nodes that arrive
to a new link.  (More on that on a separate message).

Anyway, I suggest that if we can change the caching algorithm
so that the default Delta value is a pure policy issue, we
would keep 3600 seconds or even use a larger value.

--Pekka Nikander