Hi,
I understand the reverse gas model is a good strategy to make
internet computer content seamlessly available.
However, I do not fully grasp what happens if when a malicious actor exploits
such a model [D]DOS-ing a, say, IC static website. IC = (eventual) infinite scaling, so one
would naively imagine that the canister runs out of cycles and stops.
How can such an attack be prevented/mitigated/stopped?
Thanks! Keep up the good work
I imagine in similar ways to how it’s mitigated on AWS Lambda and Fargate, which are similarly structured.
Amazon has this DDoS service
Dfinity has this (and prob others in the works)
… Or maybe it’s fleek that has the Dfinity as an option to be exact?
Either way, I assume that’s how it will look, a service that is likely abstracted away from the user.
The main concept of Dfinity is to abstract away as much of the boilerplate as possible.
While the gateway could shield IC from DDOS with some policy, I don’t think this is how it meant to be handled.
I read in the IC Interface Spec that canister can export a inspect_message function that’ll called by system before actually delivering the message. And within that function canister can decide on its own whether it wants to accept the current message.
To me it sounds like canister code will be responsible for shielding itself from DDOS. But I don’t know any suggested strategy or best practice to implement such logic.
Hi,
Very interesting, thanks.
inspect_message reminds me of AWS lambda api-gateway authorizers or
lambda@edge for CloudFront, so it might be an appropriate architectural pattern
to fight against DDOS/gas exhaustion.
I also came to the conclusion that such problems have then to be dealt in code.
It ‘sounds’ more difficult and less efficient than using firewalling, CDN, etc.
It is probably the price to pay for the IC paradigm change. Maybe, there are some better practices?!
In any case, these ‘side-code’ mechanisms consume cycles/money (in AWS too) and are probably more expensive (think firewalling done by iptables vs AWS shield, or HTTP basic auth done by nginx or with a lambda authorizer), therefore it all boils down on how much CPU and RAM are priced on the IC.
How can one extract some metrics of canister cost, in dollars?
Cheers
Don’t worry, inspect_message does not consume cycle.
I’m also interested in IC pricing. Don’t know where to check 
The way I see it, the protocol is already handling security and lots of other mundane non app specific things, you would think DDoS protection would be list of things to abstract away too eventually and have some sort of config to enable a good default policy from your dfx.json or something… of course only you would know how your app and APIs need to be throttled as it would be different for each use case, but I assume a base-level DDoS protection could be abstracted away?
and that’s cool if that call doesn’t consume a cycle, I like that.
Just came across what you were mentioning here as skimming through it:
Would be nice to have some sort of sensible defaults for throttling, etc…
I guess that can be the low end target fleek and other frameworks will implement either way.