On Mon, Oct 09, 2017 at 06:24:36PM +0000, Brotman, Alexander wrote:
> Do we think we really need to allow caching? From what are we trying to
> protect the backend systems?
NOT the backend systems, rather the rather more constrained reverse
proxies of the customers.
Caching can of course be disabled by provider, but I think that's
needless inconsiderate of the reverse proxies.
> Feels like it would be easier to disallow
> caching (or recommend against). I understand the sense that a smaller
> company could be overwhelmed by an attacker or ill-configured legit sender,
> but I don�t know how much caching will really help there. The caching
> server would be similarly overwhelmed I would imagine, and be unable to
> serve policies to any other requesting systems.
The defense is not against deliberate DDoS, rather it significally
reduces proxy concurrency, by making it possible to serve content
from a cache, rather than go upstream for each request. This
can significantly improve scalability at little cost.
All the provider has to do is delay the publication of the TXT
record, until the corresponding new policy has been the only
one available for > 60s. This is a low cost to pay, and allows
cooperative caching to be supported by providers that wish to
do so. I think that providers should support caching, but
this specification will not require them to do so.
--
Viktor.
_______________________________________________
Uta mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/uta
