the forums at degreez.net

Hi,

Could you implement this extension?
It should be quite easy if you're comfortable with Python (which I am not).

Handshake:
int64: 2 (byte 7, bit 1)

Messages:
get_peers:
int32: 7
int8: 11
int16: local port

When get_peers is received, send peers unless peers was send less than five minutes ago

peers:
int32: 7 + 6 * count
int8: 12
int16: local port

int32: host
int16: port

When peers is received, ignore the message if get_peers was not send less than one minute ago

NO. Gossip functions are prone to turn P2P systems into DDoS engines. We are working on ways of doing it properly, to reduce the chances of this problem, but until then there will be no such extensions.

If you only send out addresses of peers you're currently connected too and only accept addresses of peers you asked, then how can this be prone to DDoS?

Could you at least tell me what is wrong with my design?

Because the peer you are connected to could simply ly to you about his peers.
Just take a torrent with a lot of leechers, connect to the tracker to get peers and tell all of them ip and port numbers of the client(s) you want to ddos. You can even ul/dl some parts of the file to look serious.
As TheSHAD0W said it is already thought of implementing something like this, but it needs to be more foolproof.

So you connect to 1000 peers, tell 1000 peers the address you want to DDoS and all of those peers will try a single TCP connection to the target.
The target receives 1000 connect requests.
Wouldn't it be much faster and simpler to send the connect requests yourself?
It'd also cost you less bandwidth, so I don't see how this extension can help DDoS attacks.

Or rather, they submit a list of 20 or so addresses they want to DDoS and each peer of the 1000 tries to make a connection -- at which point the attacker has caused 20x the number of connections that they could send out themselves.

Eh, peers are only supposed to forward addresses of currently active connections, so your theory doesn't work.

but not all peers can be trustworthy.

You wouldn't wind up with a real amplification effect, probably, but a TCP connect flood (assuming the DoS is pointed at an active port) can cause a lot of damage, especially since the attacker would be redirecting his attack from a large number of different IPs, and it would also be difficult to trace the attacker back.

We're working on ways to minimize this sort of feature's usefulness as a DoS engine, and will release a specification when we can.

Why not?
Because they're attackers or badly coded?
If the first case, it's still easier and faster to send the connect packets directly.
In the second case, there's little you can do.

With IP spoofing, the attacker can cause the same effect all by himself.

A SYN flood can be IP-spoofed. An actual connection flood can use much more resources per connection.

True, but besides IP spoofing, what other advantages does this have for the attacker over a direct attack?

The spoofing is bad enough to make me want to fix things so it won't work.