autonat: don't use AutoNAT to discover addresses

[marten-seemann]

          > Is there any reason to keep the `address` field on the `autoNATresult`?

It's used in the PublicAddr method which is used by host.AllAddrs.
This seems to me that it is mostly redundant information with information received from the ObservedAddressManager.

Originally posted by @sukunrt in #2092 (comment)

[marten-seemann]

According to the address validation logic (see spec), an AutoNAT implementation will only accept dial-back requests originating from IP addresses that don't match the remote IP address of the connection that the request was received on.

Since the node will only dial us back on addresses we send in the dial-back request, this means that assuming a spec-compliant peer, it should be impossible to discover new addresses via AutoNAT. At best, the logic we have is worthless.

This mechanism however could be used by a malicious peer to feed us incorrect addresses. This is not a very interesting attack, since 1. the node will only advertise a single such address, and only until we've obtained a new AutoNAT observation (15 minutes refresh interval) and 2. it's not replacing any addresses, we're just adding this address to our list of addresses.
The worst scenario I can think of is that this leads to increased handshake load on that incorrect address.

[sukunrt]

STUN RFC suggests an attack here

In this case, the attacker provides a large number of clients with
the same faked MAPPED-ADDRESS that points to the intended target.
This will trick all the STUN clients into thinking that their
addresses are equal to that of the target. The clients then hand out
that address in order to receive traffic on it (for example, in SIP
or H.323 messages). However, all of that traffic becomes focused at
the intended target. The attack can provide substantial
amplification, especially when used with clients that are using STUN
to enable multimedia applications.

Could this mechanism of using autonat for address discovery have been used to launch such attacks. The attacker runs a malicious autonat server and to all dialback requests it responds with the ip of the target. These dialback clients will then possibly advertise this address as their address for 15 minutes and this would lead to increased traffic on the target.

Metrics on a kubo node show that a particular node doesn't get many dial requests so this would have been mostly fine. However we should keep this scenario in mind for future changes.

@marten-seemann thoughts?

[marten-seemann]

Yes, there’s a million ways to have clients traffic some way. You don’t even need AutoNAT for that. libp2p comes with a number of address discovery mechanisms, and I bet you could use every single one of them.

This is also not limited to libp2p. Every webserver can embed an image from a target in the HTML code. At some point you’ll need to accept the fact that if you’re running a publicly reachable server, you’ll have to deal with incoming connections.

So what does mean for our DoS defenses? Realistically, all that we hope to achieve is making these attacks cumbersome enough that they’re not very attractive. Ideally, we can also achieve some smoothing, so an attacker is not able to create a short-lived burst of traffic that might be able to overwhelm a server, but realistically, there’s also just so much we can do.