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

From: [email-masked]
Date: Wed, 24 Sep 2003 17:53:42 +0000

> -----Original Message-----
> From: Pekka Nikander 
> 
>  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.

I agree.

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

While such a scheme would make attacks harder, it would not
fully prevent them. For example, an attacker could send a little
traffic (i.e. a ping or TCP syn) after each NS to trick the victim into
promoting its cache entry to the old cache.

I think it is becoming apparent that a method that will fully prevent
replay attacks will be very complex to implement and administer.

Perhaps we should drop the cache idea altogether, and just use
timestamp delta checking? The security provided, while not perfect,
could still be reasonably good (depending on the local policy).  It
would also be very simple for locals admins to understand and tweak.

Jon

--------------------------------------------------------------------
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: Jonathan Wood <[email-masked]>
Date: Thu, 25 Sep 2003 17:49:30 -0700

>
> On the other hand, I think we can leave all these concerns
> as SHOULD, and leave the implementation the freedom to ignore
> them and just use e.g. Delta, if really needed.
>

This pretty much works for me. Right now my feeling is that the
complexity of developing a reasonably effective cache scheme
would outweigh its security benefits, so I would be a little happier
with "MAY" rather than "SHOULD".

Jon