Per-Entity Metadata Working Group

[Nick Roy <>]

> On Aug 7, 2016, at 9:27 PM, Patrick Radtke 
> <>
>  wrote:
> 
> On Fri, Aug 5, 2016 at 7:22 AM, Cantor, Scott 
> <>
>  wrote:
>>> Given some number of sign ons per day, and assuming
>>> some reasonable cache lifetime in memory, with no restarts, perhaps we
>>> could figure out how many hits per hour/minute/second an MDQ
>>> infrastructure would need to handle to fulfill the needs of InCommon’s
>>> 434 identity providers and 3,107 service providers.
>> 
>> The tricky part is that you need to know how many different SPs or IdPs
>> a peer is connecting with, because hitting the same one over and over
>> just hits the cache. For example, I can cull logs and find out how many
>> different IdPs log into my services, though of course it would be a hell
>> of a lot easier if I customize the SP logging format first.
> 
> 
> I would be more concerned with handling denial of service attacks than
> well behaving clients and legitimate federation queries. The proposal
> for pushing files to a CDN makes the most sense to me for handling
> availability for unexpected loads. Caching HTTP proxies can actually
> make DoS attacks easier to perform since the attacker can now make
> cache-missings requests to the various proxies which will then all hit
> the MDQ servers.

Is this risk at all mitigated if we are just serving static content?

Nick

> I was looking through Amazon's CDN documentation and they aim for
> greater than 99.9% availability. Azure seems to delegate to Akamai or
> Verizon and I couldn't find uptime targets for either of those.
> 
> -Patrick