DoS protection in PeerHandler

[ariard]

Was thinking we may need some DoS protection at the PeerHandler, like some noisy peer sending too much ping msgs or unknown message types. May need to take some Duration in do_read_event.

[TheBlueMatt]

Why? The Correct (tm) approach to DoS handling is: * make sure all responses to trivial-to-generate messages are roughly smaller than the original message, * make sure no trivial-to-generate messages take an inordinate amount of CPU time. Problem solved. Now, we could add something to disconnect useless peers (ie incoming connections which are not opening channels with us), as long as we have a configuration option for it, but I don’t see any material DoS concern atm?

…

On Oct 23, 2019, at 12:54, Antoine Riard ***@***.***> wrote:  Was thinking we may need some DoS protection at the PeerHandler, like some noisy peer sending too much ping msgs or unknown message types. May need to take some Duration in do_read_event. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[ariard]

• make sure all responses to trivial-to-generate messages are roughly smaller than the original message,

What's about me sending you a never-stopping flow of ping messages ? Beyond ensuring responses to be smaller, shouldn't we check also the frequency ? Do we already have check like that in PeerHandler ?

Seems to be an advice in BOLT 1 at least: "SHOULD fail the channels if it has received significantly in excess of one ping per 30 seconds."

[TheBlueMatt]

For mobile it may make sense to measure bytes received / utility gained (ie how many bytes are they sending us per htlc-addition/-removal/routing graph update) and disconnect if the peer is being too chatty, but, in general, trying to play whack-a-mole with "DoS" issues where someone is just sending you a lot of stuff is error-prone and also not really all that useful. If we want to go down that route, however, we should have some API to limit bandwidth consumption, because that's really what we're talking about (eg on mobile devices where you don't want to use more bandwidth than the user is willing to pay for).