[ On Sunday, July 6, 2003 at 10:16:02 (-0500), Jerry Jorgenson wrote: ]
> Subject: Re: [Exim] error response rate limiting vs. overloaded systems
>
> Idle connections take up resources: 1 slot in the TCP stack per
> connection. Most systems that I know about don't have an infinite TCP
> stack. But if you know of one please post it.
Of course -- but would you rather have one socket and one process
sitting idle and twiddling its thumbs, or have to close and reopen
sockets, and fork ne processes, multiple times a minute just to send the
same error response to the same client?
Holding a connection open and idle for some time before you send the
last line of an error response will save you massive amounts of
resources at only a tiny expense. Pay a little, save a lot.
I'm not expert enough at queuing and operational theory to explain the
math (and it wouldn't be simple if it were explained), but I have more
than enough direct experience to understand intuitively that this is
true.
Think of it like a highway and instant matter transport working in
combination. In traffic management you want to get the vehicles off the
road as quickly and efficiently as possible or else they'll back up and
cause a jam as they slow down to street speeds. Imagine there are two
types of cars: black ones and white ones. Now imagine that every black
car that exits suddenly reappears on the highway going at full speed
only a few hundred meters before the exit. Remember there are still new
cars entering the highway too and they all want to get off at your exit.
If this happens you can never prevent jam-up, not matter how quickly you
allow those bad cars to exit as eventually there will be more cars
trying to exit the highway than can fit with safe distance between them
and they'll start to slow down while still in the traffic lanes and you
have an instant traffic jam on your hands. Now this is the worst case
scenario of course, but that's what you have to design for. Now let us
say we introduce a one-minute delay to the matter transport device --
I.e. when the black card exit then they disappear for 60 seconds before
they re-appear on the highway. Let us also say that in those 60 seconds
the black car could have driven down to the previous on-ramp and got
back on the highway themselves just as if they had exited normally. Now
suddenly you've forced the black cars to do no worse than they could
have done if they were behaving within the laws of physics and so if
you've scaled your highway to local peak traffic demands then you'll
never have a jam-up even if someone does invent a matter transporter
because you'll be able to force their matter transporter to delay for
the same time as they would delay without it. I.e. you can force the
laws of physics on them even if they initially think they've found a
loophole.
Now as with all analogies there are probably flaws in this one, but I
can assure you that the end result is the same.
I can also assure you that the bigger the highway and the more traffic
there is on it, the bigger the savings gained by delaying that matter
transport. Indeed if 75% of the cars are black but only 5% of those go
through the matter transport to come back and cause you trouble then
delaying the whole 75% is still less far expensive than not delaying
any of them. Brute force engineering only works when everyone is well
behaved and even then there's still always a finite limit to how far you
can go.
What you want to always let through with no impedance are the good guys
who are just going about their normal business and who won't ever cause
any errors and who won't ever come back and hammer at you over and over
again even when you've tried to tell them not to do so.
It is always wrong to let those who cause errors go because at least
some of them will always turn right around and cause the same error
again right away. You can't force good behaviour on everyone, but you
can lock them up to prevent them from making the same mistakes twice in
short succession.
> Example: One spammer using 6000 separate ip-addresses in one minute.
If you have a machine that can accept 6000 separate connections in the
space of one minute then it doesn't matter if you hold them open for
another minute when you you reject them all because if you actually had
accepted an e-mail message from any significant number of those
connections then your machine require far greater resources to store,
process, and deliver those messages. Holding the connections open and
idle in order to rate-limit the error responses is a tiny cost in
comparison to actually delivering messages.
What does matter is that if you reject them and drop them immediately
and then they all re-connect again immediately to try to re-deliver the
message you rejected, well then you're hosed because they're likely to
just keep doing that for several minutes, hours (or as I've seen in some
cases, days). Meanwhile if you simply hold those connections open
you'll have lots of resources left over to accept another few thousand
connections from legitimate clients which make no errors and which
simply deliver messages to you.
I.e. holding errant connections open and idle is a tiny cost in
comparison to going into a tight accept, reject, close loop.
> DoS protection assumes that one server or a small group of servers is
> hitting you numerous times.
If that's what _your_ DoS protection does then it's broken by design.
SMTP error response rate limiting works regardless of the number of
simultaneous attackers (thanks to the store and forward nature of SMTP).
> Correct, you actually have to have the capacity to filter out these before
> they hit the mail servers. It's not fun, of course if it was fun, people
> would pay to do it :-)
Well, you guys have fun with your silly firewalling tricks. I'll stick
to things that work automatically and don't need my direct attention and
management.
--
Greg A. Woods
+1 416 218-0098; <g.a.woods@???>; <woods@???>
Planix, Inc. <woods@???>; VE3TCP; Secrets of the Weird <woods@???>
