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

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

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

[Reordered quotes to make answering easier]

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

I don't believe it is possible to fully prevent reply attacks,
given all the other requirements we have.  Hence, the real
question is to find out what is reasonable effort and what
is clearly too little.

Furthermore, as I wrote ...

>> In my opinion, the exact algorithm for expiring cache entries
>> in the case of a full cache is clearly a local policy issue,...

... we probably do not want to specify too much in the doc.
More like hints and concerns than a recommendation for a
full blown algorithm.

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

Right.  The whole point is to make the effort required by an
attacker higher.  If an attacker has to generate a number of
keys with sec > 0, change its MAC address, send not only
unsoliciated messages but also trigger solications and answer
them, and also send some regular traffic, it needs to do quite
a lot of work.  That reduces the "appeal" of the cache filling
attacks, probably leading a potential attacker to try to find
a weaker spot somewhere else.

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

I think having Delta and cache dropping separately seem like a
good idea.  It clearly improves resiliance in many situations.
For example, it even allows hosts with a large clock difference
to communicate if they somehow are able to create cache entries
through solicited (nonce carrying) packets.

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.

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