[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fwd: Minutes / Notes

Masataka Ohta wrote:

Yes, lacking proper acknowledgements from 131.112.32.132, the
peer will terminate the stream.

Exactly.


That is, you can't send proper acknowledgements, unless you can
receive packets to 131.112.32.132, which is the return routability.

Not true.  If you open a TCP session and receive the first
few packets, it is easy enough to generate fake ACKs.
I can dig up a reference if needed.  You can even make
it look like the bandwidth is much higher than it is,
thereby clogging a pipe even with just one or few
streams.  All you need to do is to get a stream that
is originally directed to yourself to be now directed
to the victim, with the possibility of generating faked
ACKs.

Some people claim that it is even easier to fake ACKs
for some UDP based protocols, but I don't know the details.


It should also be noted that there is no amplificaiton here that
it is no worse than ICMP echo requests with spoofed source addresses.

Not true, see above.


Yes, similar attack is, for example, possible with

    pnr.iki.fi.         IN MX        10 pnr.iki.fi,
    pnr.iki.fi.         IN MX        20 necom830.hpcl.titech.ac.jp
    pnr.iki.fi.         IN A         81.17.193.194
    necom830.hpcl.titech.ac.jp IN A        131.112.32.132

and sending a lot of erroneous mails from pnr.iki.fi to
random recipients.

So?

The problem is that the attacker is able to make the
stream to continue uninterrupted, since it can fake
the acks very easily.

If you make a false MX, the MXed host will not
accept the mail.  Hence, in that case application
level stops the attack.

--Pekka Nikander