David MacQuigg wrote:
>
> Seems to me RFC-5321 could have said: The client MUST pause every
> 1000KB (or 100 seconds, whichever is less) and look for a REJECT.
> Clients who fail to do this risk being blocked by a firewall.
What would be the point of this? A 'bad' client won't do this, and even
if you do send a reject and it does honour it, it will just start
sending data again, so - what's the point. Just block them at the
firewall anyway - not that that would help against a botnet.
I have to agree.
(A much better 'solution' in RFC 5321 would have been to enforce the
SIZE extension, and allow the server to drop the connection if the
client sends more than 10% over the advertised size of the email - it
still wouldn't help in the bigger picture, but it might close this
unexploited loophole)
Mandate an extension in a revision like this? Absent a "do this or the email
service is gone" sort of reason, There was simply no way that was ever going to
happen.
As I see it, you could somehow work out a protocol for telling something
that is sending you 5000 TB of data to 'stop it please', but (a) it
could ignore you or (b) it could stop, but then start again straight
away, so it sends you 10MB, then another 10MB, then another 10MB ad
disk-blow-upeum.
Exactly.
This can happen with pretty much any protocol anywhere.
That's the point I've been trying to make all along.
It has to be handled by heuristics of some sort, or not handled at all -
in my experience serious DoS attacks are relatively rare, and if they
happen there's not a lot you can do at any one level to stop them.
Baddies seem to be more interested in using their botnets to send spam
or phish attacks or whatever - something which has financial gain.
Well, if there's an apetite for standards work in this area, might I suggest a
standardized protocol that can be used tell the routing infrastructure to
impose or remove a block as close to the ingress point as possible? I'd
personally prefer a RESTful web service, but almost anything would work. (But
please, let it not be SNMP with some security model no client library
implements. In fact let's steer clear of SNMP entirely here.)
I don't know about you, but using expect or whatever to script Cisco IOS
commands fails to impress.
Our MTA, and I suspect most others as well, is perfectly capable of
providing a block/unblock notification stream based on either simple
limits or fairly elaborate heuristics. So once you've terminated one of
these endless data streams, or one byte per minute streams, or any of the
many other forms of abuse, you can prevent it from consuming more resources
on anything inside of your administrative domain.
But the problem is typicaly that there's no viable consumer for those events.
And while defining a standard for such things is no guarantee that it will see
implementation, at least there would be a consistent way to talk to such
consumers.
Ned