add autonat v2 spec #538
add autonat v2 spec #538
Conversation
There was a problem hiding this comment.
Very nice, this is a solid starting point for the spec!
What's the plan for resolving #536? Would you open a new PR that targets this PR here?
|
thanks for your review @thomaseizinger. Proposal: use a list of addresses in priority order for autonat v2 dial requests #539 |
I don't have anything to add to those at the moment :) |
There was a problem hiding this comment.
On a brief skim, this looks good! I'm curious if we'll want to relax the "implementations MUST NOT dial any multiaddress unless it is based on the IP address the requesting node is observed as". Would it be useful to do this, and we can mitigate the amplification attack some other way?
It seems like there's a healthy discussion already going on, so I'll step back here and let other folks stay involved. If there's anything I can help with, please don't hesitate to ping.
|
Thanks for your review @MarcoPolo
The suggested strategy is discussed here: #536 Here's the PR for those changes: #542 |
|
Another quick question, I probably missed something: When the server successfully dials the client and provides the nonce. The client closes the stream either way. How does the server know if the provided nonce was correct? |
|
In the spec it says that all private IP address should be excluded, but it also says it's just for checking reachability on the public internet. That said, we should exclude: For IPv4:
For IPv6:
In the rust-libp2p implementation there was a PR discussing those globally reachable IP address: libp2p/rust-libp2p#3814 Also this list is probably not complete and not formal, it's also a small nitpick. |
|
@umgefahren it'd be better if you can add the comments as a review, commenting on the specific section.
It means non public. Happy to change the wording to
A correct server will always provide the correct nonce, no? This issue should be easy enough to debug for implementors without signalling from the client. Is there any benefit to the server knowing that it provided an incorrect nonce? |
I will do that the next time. I'm sorry.
Thanks for clarification.
I think there is a benefit. There is a pathological example where the network configuration or a NAT forward traffic to the wrong libp2p node. Not the one that requested the dial back, but a different one. In that case the server would report reachability on that address, but it's actually not reaching the peer in question. I'm not an expert enough here to think of any case where that might occur apart from a bad config or a malicious actor. |
|
In this case, the client sees that the server is reporting OK-Reachable but it has not received the nonce, so it should reject the response. |
If we dial the node with |
|
So since that is not possible, the implementation doesn't needs to handle this case, right? But thanks for the clarification and sorry for the dumb questions. |
Yep I think you are right! We can assume that this will never happen. Feel free to use
No worries at all! I think your questions are pretty spot on actually :) |
|
|
||
| Cli -> Srv: [dial] DialRequest:{nonce: 0xabcd, addrs: (addr1, addr2, addr3)} | ||
| Srv -> Cli: [attempt]addr2 DialAttempt:{nonce: 0xabcd} | ||
| Srv -> Cli: [dial] DialResponse:{status: OK, dialStatuses:(E_TRANSPORT_NOT_SUPPORTED, OK)} |
There was a problem hiding this comment.
This mentions E_TRANSPORT_NOT_SUPPORTED but that is missing from the protobufs?
|
While doing the rust-libp2p implementation, we discovered a race condition, which we are now circumventing by a 100ms delay. You can read the finally comment by @thomaseizinger here: umgefahren/rust-libp2p#1 (comment) It happens when the server successfully performs a dial back, thus sends the confirmation of the address back to the client. However the client hasn't progressed enough to be notified of that successful dial back when receiving the confirmation. In that case the client wrongly assumed an address was confirmed where no dial back occurred. |
Minor correction here: The behaviour is usually that the client discards the "successful" confirmation because it has not yet processed the dial-back so it thinks the server is sending it a confirmation without having actually done the dial. I think the correct way to solve this would be to add an ACK message from the client back to the server for the dial-back where the client can say: "Yes I've processed your dial-back". The server can then proceed to respond on the other stream and thus guarantee that we don't have a race condition between the two streams. |
|
You can read the closing of the stream as the ACK. See: https://github.com/libp2p/go-libp2p/blob/sukun/autonat-v2-2/p2p/protocol/autonatv2/server.go#L251-L257 The spec also dictates closing the stream: https://github.com/libp2p/specs/blame/autonat-v2/autonat/autonat-v2.md#L87 Do you think an explicit ACK is better? |
Yeah I think so. I associate closing a stream with "I have no more data to write". The client never writes data so why wouldn't it immediately close the stream? Also, reading a stream and waiting for that to fail because it has been closed it also somewhat odd 🤷♂️ |
That's a fair point. I'll add an ACK. |
|
Updated the specs with a |
Closes: #4524 This is the implementation of the evolved AutoNAT protocol, named AutonatV2 as defined in the [spec](https://github.com/libp2p/specs/blob/03718ef0f2dea4a756a85ba716ee33f97e4a6d6c/autonat/autonat-v2.md). The stabilization PR for the spec can be found under libp2p/specs#538. The work on the Rust implementation can be found in the PR to my fork: umgefahren#1. The implementation has been smoke-tested with the Go implementation (PR: libp2p/go-libp2p#2469). The new protocol addresses shortcomings of the original AutoNAT protocol: - Since the server now always dials back over a newly allocated port, this made #4568 necessary; the client can be sure of the reachability state for other peers, even if the connection to the server was made through a hole punch. - The server can now test addresses different from the observed address (i.e., the connection to the server was made through a `p2p-circuit`). To mitigate against DDoS attacks, the client has to send more data to the server than the dial-back costs. Pull-Request: #5526.
| same key repeatedly. The only benefit of going via the server to do this attack | ||
| is not spending bandwidth required for a handshake. So the prevention mechanism | ||
| only focuses on bandwidth costs. There is a minor benefit of bypassing IP | ||
| blocklists, but that's made unattractive by the fact that servers may ask 5x |
There was a problem hiding this comment.
I don't think we can simply shrug this off. This is called a reflection attack and has been a huge issue for open DNS resolvers.
Fixing the amplification side does go a long way, but paying a 5x bandwidth cost for a bunch of free IP addresses seems like a pretty reasonable tradeoff from an attacker's standpoint (especially because said attacker isn't paying for the bandwidth, but likely needs to compromise one machine per IP address).
There was a problem hiding this comment.
Also note: home NAT users likely don't need this feature. That is:
- They likely only need 1 dialable address.
- They likely don't care which one.
- Their outbound and inbound IPs are likely identical.
Being willing to dial other addresses does matter for, e.g., AWS and other special settings where there are separate ingress IP addresses. But, in that case, maybe the user should just configure their node correctly rather than relying on AutoNAT? AutoNAT specifically exists to enable home users.
There was a problem hiding this comment.
It simplifies client implementations as they don't need to worry about IPv4 peer vs IPv6 peer. Though the benefit isn't huge since most IPv4 servers won't have IPv6 connectivity so they any way cannot check the IPv6 address.
Fixing the amplification side does go a long way, but paying a 5x bandwidth cost for a bunch of free IP addresses seems like a pretty reasonable tradeoff from an attacker's standpoint (especially because said attacker isn't paying for the bandwidth, but likely needs to compromise one machine per IP address).
Can you elaborate here? why isn't the attacker paying for the bandwidth.
|
@sukunrt given that AutoNatv2 is merged in two reference implementations libp2p/rust-libp2p#5526 (released in 0.13.0) and libp2p/go-libp2p#2469 (released in 0.36.1) Are there any outstanding comments that need to be addressed before this pull request can be merged? - if there are any that are non-blocking, can they be addressed in follow up PRs? |
@sukunrt and I did interop testing and successfully verified that they are working together. |
|
The implementation is not used in go-libp2p yet. We should merge this after we start inferring reachability in go-libp2p. |
Closes: libp2p#4524 This is the implementation of the evolved AutoNAT protocol, named AutonatV2 as defined in the [spec](https://github.com/libp2p/specs/blob/03718ef0f2dea4a756a85ba716ee33f97e4a6d6c/autonat/autonat-v2.md). The stabilization PR for the spec can be found under libp2p/specs#538. The work on the Rust implementation can be found in the PR to my fork: umgefahren#1. The implementation has been smoke-tested with the Go implementation (PR: libp2p/go-libp2p#2469). The new protocol addresses shortcomings of the original AutoNAT protocol: - Since the server now always dials back over a newly allocated port, this made libp2p#4568 necessary; the client can be sure of the reachability state for other peers, even if the connection to the server was made through a hole punch. - The server can now test addresses different from the observed address (i.e., the connection to the server was made through a `p2p-circuit`). To mitigate against DDoS attacks, the client has to send more data to the server than the dial-back costs. Pull-Request: libp2p#5526.
First draft for autonat v2. #503
This protocol allows for testing reachability on exactly one address. This helps determine reachability at an address level. This also simplifies the protocol a lot.
I'll change the spec to reflect the discussion on dialing a different ip address from the nodes observed ip address: #536
Discussion for nonce in message is here: libp2p/go-libp2p#1480
and this comment in particular libp2p/go-libp2p#1480 (comment)