From: Theo Schlossnagle
Sent: Wednesday, May 26, 2004 3:23 PM
On May 26, 2004, at 3:36 PM, Seth Goodman wrote:
I didn't ask if anyone ever did a CBV on your site, I asked if you
know of
any instances where CBV's were used as a DDoS mechanism. If you know
of
any, please say so. Since at least two large providers have the
necessary
"attack engines" in place for quite some time, why hasn't this been
used
this to propagate an attack?
No. My description of a DDoS involved several thousand independent
entities running CBV. "two large providers" isn't sufficient to
perform a DDoS.
My whole argument is that it shouldn't be deployed because it can. But
I'll take the liberty of dropping a 'D'. We have one managed client
that has been DoSed by Verizon's CBV. And another that has been DoSed
quite regularly by AOL's DSNs.
I take that to mean that one client was maliciously knocked off the net by a
concerted attack by Verizon. I take the second instance as meaning that AOL
intentionally targeted that server and saturated its network bandwidth to
the point where it had no effective internet connectivity left. If,
instead, you are saying that the first site got more CBV's than it wanted,
the second site received lots of forged bounce spam and both were very
annoyed, that's life on the uncontrolled internet, not a DoS attack.
If UPS started delivering 100 empty boxes per day to my house, it would not
be unreasonable for me to make the delivery person wait while I called the
purported senders to verify that they have sent me a non-empty box. If the
return addresses on the boxes were fake, I would unavoidably be bothering
some innocent third parties to help solve my problem. While those third
parties receive no benefit by helping me out, I seriously doubt any of them
would complain if I told them why I was calling. That is because most
people view society as a cooperative venture, even though we may have
competitive individual interests. If they did complain, I would apologize
for wasting their time and get off the line. Of course, I would never do
business with them after that, but that's their problem.
The internet is no different than any other civil society. One can take an
separatist view or a cooperative view. I prefer to cooperate. CBV's are an
imperfect solution to a practical problem brought about by a series of
protocols that provides no accountability for email senders. It allows
irresponsible senders to drive all of our individual connectivity costs
through the roof. The solution is not free, and it does require
cooperation. If most of us cooperate, our collective costs will go way
down. If we insist on "going it alone", we all go broke together. Like it
or not, our fates linked in either case. We might as well realize this and
cooperate.
AOL sees the errors in their bounce architecture. They are correcting
it. Why? It is exploits innocent victims. Verizon's use of CBV
doesn't make it okay. They are wrong.
I respectfully disagree.
It's an open internet and no one has to answer any connection request
if
they don't care to. On the other hand, if I were a large provider, I
could
say that I require all senders to answer a CBV if they want me to
accept
their mail. Some CBV's will go to third parties that did not
originate the
messages, that is true. If those parties object, they can refuse to
answer
CBV's from my service. The reason that this hasn't happened, at least
in
any significant way, is that the only salient objections to this _are_
philosophical, not practical, and we are dealing with a huge practical
problem. If you really object to CBV's, I encourage you not to issue
any
and to not accept any.
They can't refuse CBV's without refusing real mail. Not accepting
CBV's is quite challenging as they are "disguised" as normal SMTP
transaction initiations. If it were possible to not allow CBVs in a
straight forward way, the problem wouldn't be what it is.
And exactly what problem should we be most concerned about? I thought that
the enormous flow of forged email was the problem, not the CBV's that allow
us to reject the forged mail.
You misrepresent what I am saying. I am arguing that it is a useless
DDoS
mechanism because it is trivial to terminate by refusing any MAIL
FROM:<>
connection request. Terminating those connections does take some
resources,
but it's not crippling.
Terminating those connections is quite expensive and on a large scale
can cripple a system. And rejecting MAIL FROM:<> is not RFC compliant.
I shouldn't have to break the RFC to protect myself from CBV attacks.
You are misusing the meaning of the word "attack". An attack consists of
someone deliberately and maliciously trying to disable or harm your system.
If you consider a CBV an attack, so is every forged incoming message. A
forgery "attack" does less damage if you can stop it before DATA. It is
also an important piece of social engineering to let the spammer know that
he couldn't deliver his payload. Since most email today is spam with a
forged sender address, you will experience fewer total "attacks" if you
cooperate with other systems by mutually answering each other's CBV's to
detect and reject forgeries before DATA. Even if it were a wash for total
system resources, I would still rather spend it on CBV's than accepting the
spammers payload and filtering it later. If we make the spammer's business
unprofitable, he will find some other scam to occupy himself instead of
email.
Here I'd like to ask you a question. Isn't it possible to engineer an MTA
so that a CBV is not as burdensome as you describe? Perhaps it isn't, but
here's the basis for my question. You can't tell after RCPT TO: whether the
SMTP-client is doing a CBV or sending a DSN. If the response to RCPT TO: is
a 250, a CBV request will terminate shortly thereafter but a DSN will go on
to a DATA command. Would it be possible to delay the evaluation of the
user's quota and anything else besides local address validity until after
you get the DATA command? If for some reason the account cannot accept the
DSN, isn't it possible to respond to the DATA command with a 503 or 554 to
terminate the transaction instead of a 354?
The amusing thing here is that I don't particularly like the idea of CBV's,
either. If you can think of a more efficient way to validate MAIL FROM:
after an arbitrary number of forwards, I'd be very interested. I would much
rather that a DNS server could provide the validation, since it is based on
UDP, but that doesn't seem to be terribly feasible. A full PKI system is
far more expensive than CBV's, and shouldn't be necessary to solve this
particular problem. Looking at the big picture, I feel that a cooperative
model, which may include CBV's (or some other mechanism), gets us all
further than a system where we never "bother" each other and continue to
suffer individually. I'm sure that game theory has something to offer
concerning this scenario, but unfortunately, I'm unqualified to comment.
--
Seth Goodman