You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This features enables the following attack:
- Contact a large number of autonat v2 servers.
- Give them the target's address to connect to
- When requested for data: provide the data slowly:
* The stream timeout is 1 minute
* In the period, with a 1Gbps connection, you can send 60Gb ~= 6GB
* Maximum dial data requirement is 100kB
* So, in theory, you can run this with 60_000 peers in parallel.
* The servers have a random wait of up to 3 seconds precisely for this scenario. So in theory we can have 20k connections a second for 3 seconds to the target.
- We can make a bunch of implementation improvements to reduce the harm here. The simplest ones being: Only wait 10 seconds for the dial data, and wait for 5 seconds before dialing. That would reduce the max new connection rate to 2k / second, which is very manageable.
- The ideal solution is to introduce rate limits for new connections.
There's another problem with this feature related to implementation difficulty:
The primary use for this feature is to allow both IPv4 and IPv6 addresses to be tested without worrying about whether we have a v4 or a v6 connection. So you can ask a v4 peer to test your v6 address. This requires correctly reporting an error in case the server has no v6 connectivity, which is majority of servers.
Avoiding a cryptographic handshake in the dial back stream will make this attack useless. All you'll get are a couple of packets from the server. Moreover, we want to check reachability for the tuple (IP4/IP6, TCP/UDP), not issues with the transport handshake implementation. For UDP, this can be implemented with a scheme similar to the one used by QUIC with Retry Packet. The server can send a UDP packet with a random 64 bit number which is echoed back by the client. We can design a similar lightweight protocol over TCP.
The text was updated successfully, but these errors were encountered:
Originally posted by @sukunrt in #538 (comment)
Avoiding a cryptographic handshake in the dial back stream will make this attack useless. All you'll get are a couple of packets from the server. Moreover, we want to check reachability for the tuple (IP4/IP6, TCP/UDP), not issues with the transport handshake implementation. For UDP, this can be implemented with a scheme similar to the one used by QUIC with Retry Packet. The server can send a UDP packet with a random 64 bit number which is echoed back by the client. We can design a similar lightweight protocol over TCP.
The text was updated successfully, but these errors were encountered: