Providing unknown addresses to the user, helps them infer whether autonatv2 has any more addresses it might confirm.
There's no upside to not sending this information.
This also changes host.ConfirmedAddrs to return all the three categories, Reachable, Unreachable, and Unknown addrs.
This rate limits new connections to prevent DoS attacks.
For effectively rate limiting QUIC connections, we now gate QUIC connection attempts before the handshake, so that we don't spend compute on handshakes for connections that will eventually be cancelled.
We can only set a single ConnContext per quic-go Transport, as there's only 1 listener per quic-go Transport. So we cannot set a different ConnContext for listeners on the same address.
As we're now gating QUIC connections before the handshake, we use source address verification to ensure that spoofed IPs cannot DoS new connections from a particular IP. This is done by ensuring that some of the connection attempts always verify the source address. We get DoS protection at the expense of increased latency of source address verification.
This introduces addrsReachabilityTracker that tracks reachability on
a set of addresses. It probes reachability for addresses periodically
and has an exponential backoff in case there are too many errors
or we don't have any valid autonatv2 peer.
There's no smartness in the address selection logic currently. We just
test all provided addresses. It also doesn't use the addresses provided
by `AddrsFactory`, so currently there's no way to get a user provided
address tested for reachability, something that would be a problem for
dns addresses. I intend to introduce an alternative to
`AddrsFactory`, something like, `AnnounceAddrs(addrs []ma.Multiaddr)`
that's just appended to the set of addresses that we have, and check
reachability for those addresses.
There's only one method exposed in the BasicHost right now that's
`ReachableAddrs() []ma.Multiadd`r that returns the host's reachable
addrs. Users can also use the event `EvtHostReachableAddrsChanged`
to be notified when any addrs reachability changes.
The rate limits id pushes from peers to one every five second with an allowed burst of 10 pushes. This should be enough for all but malfunctioning and malicious peers.
We can use the exact same code for autonat, autonatv2, circuit v2, etc.
Introducing limits to identify separately to get some feedback for #3265. For this PR, I'd like to ignore issues regarding where should this piece of code go, and focus on how specifically it should behave. See the long comment in rateLimiter.allow for example.
Part of: #3265
In experiments with js we've found that increasing the message size
increases throughput. See: libp2p/specs#628 (comment)
for details.
This changes the protobuf reader for the stream to read 256kB messages.
This also forces a change to the connection SCTP read buffer to be
increased to about 2.5 MB, to support 1 message being buffered for 10
streams.
This isn't enough to support larger messages. We most likely need to
change the inferred SDP of the server to use 256kB maxMessageSize, and
need some backwards compatible mechanism in the handshake to opt in to
large messages. See: libp2p/specs#628 for
details
This also removes the go-leveldb-datastore dependency. There's no
reason to test with levelDB. This code should work with any compliant
go-datastore.
Bumps go-datastore to latest as it removes the go-process dependency.
Fixes: #3250
We were testing with both badger and LevelDB. Removing badger as just testing with LevelDB should be enough. Not sure if we need LevelDB either, but for now just removing badger as it is any way unused.
See: #3250
This introduces a new GatedMaListener type which gates conns
accepted from a manet.Listener with a gater and creates the rcmgr
scope for it. Explicitly passing the scope allows for many guardrails
that the previous interface assertion didn't.
This breaks the previous responsibility of the upgradeListener method
into two, one gating the connection initially, and the other upgrading
the connection with a security and muxer selection.
This split makes it easy to gate the connection with the resource
manager as early as possible. This is especially true for websocket
because we want to gate the connection just after the TCP connection is
established, and not after the tls handshake + websocket upgrade is
completed.
