Dino,
It is a good idea to have instrumentation in place
to detect thrashing of the cache. Implementation experimentation
will be used to determine which cache management strategies work
best.
Yes, but I think we should also acknowledge that defending against cache
trashing attacks is hard:
It is a good idea to have instrumentation in place
to detect thrashing of the cache. Implementation experimentation
will be used to determine which cache management strategies work
best. In general, it is difficult to defend against cache trashing attacks.
(Unless, of course, I'm missing some obvious schemes that show promise of
avoiding some of these issues against determined attackers. It is also possible
that if we described the situation in more detail, we'd be able to describe the
threats in a more rational way. E.g., outsiders can cause some (limited)
problems, insiders could cause big trouble but are generally a bit more
trusted, etc.)
Schemes are work in progress and hence why we don't want to list them. We had
mentioned this before from the Nanog-triggered thread which we moved over to
the [email protected] list.
I agree that we should not mention any schemes. But I do want to add the last
sentence, because I think it is a true statement and more importantly, it
provides IMO a fair assessment of the potential difficulties.
I added this when I responded to you. Is it not sufficient:
cache sizing and maintenance is an issue to be kept in mind during
implementation. It is a good idea to have instrumentation in place
to detect thrashing of the cache. Implementation experimentation
will be used to determine which cache management strategies work
best. In general, it is difficult to defend against cache trashing
attacks. It should be noted that an undersized cache in an ITR/PTR
not only causes adverse affect on the site or region they support,
but may also cause increased Map-Request load on the mapping system.
Yes, this works well for me.
Jari
_______________________________________________
lisp mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/lisp
