-
Notifications
You must be signed in to change notification settings - Fork 53
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bug: failed to retrieve peer info via peer exchange protocol #2875
Comments
Morning @jm-clius ! I considered this issue as not super urgent, given the low relevance that we give to the PX protocol. Let me know if I am right :) |
Hey @Ivansete-status, I think we do prioritise peer exchange (nwaku as a server) for Status mobile clients. If this is an occasional failure (i.e. if simply retrying the peer exchange lookup works) or if this is not reported as an issue by js-waku or go-waku in light mode, I would say it's indeed simply a testing issue and has relatively low priority. @chaitanyaprem can perhaps confirm if there are any noticeable issues with peer exchange to the fleets from Status mobile. |
Hi, I went again to check if the multiaddr to dial is actually the correct one: This is happening on Node3:
Corresponding REST API request to Node1 to get the peer store. It contains Node2's info which is then provided to Node3 during startup.
And finally
node1_2024-07-09_09-56-46__095ff8e5-6bc5-4156-81bc-8cc2153afd91__harbor.status.im_wakuorg_nwaku:latest.log |
Nwaku as Node1 and Gowaku as Node2 (responder) combination works. |
I am kind of happy to not having peer exchange working. Peer exchange and peer & connection management through REST API are aid features for Discv5 not being good enough. Could we evolve to "discv6" being able to deal with lightweight discovery and bootstrap scenarios well ? Especially the part when outside intervention is needed is my concern. If I am attacker I would start from these two features to destabilize running network. I'm ready to help with discv6 simulations. |
While I understand your concerns about the REST API for peer management, I'm not sure I see the relation here with the peer exchange protocol. Peer exchange is simply a req-resp protocol where a service node is requested to return a random sampling from the discv5 dht. There are of course the usual security concerns as with all req-resp protocols, but I don't see this as necessarily tied to similar concerns about gaining access to a node's local Admin API?
:D Such a protocol will be great. The next development in discv5 would likely be introducing topic advertisements to improve efficiency, although this seems to be a particularly tough research problem. |
If I remember correctly we need "REST API for peer management" to have possibility to add node to peer store to speedup network bootstrap process. And the reason is Discv5 takes very long to do it for us when we need tests to run quickly. Am I missing something ? |
When I personally see non linear reward for my time, I am hooked :) Better DiscvX might reduce possible attack surface, and steal work for QAs and integrators. It might not be necessary to change discv5 engine, maybe just move those "aid features" closer to it, and remove external access to them ? Converting security recommendations into more opinionated code. Not sure I am clear here... I recall combustion engine needed someone to actually start it physically with handle. Later electronic starter was used to everyone's satisfaction. Engine design was kept intact. |
Not quite. I'm sure it can be used in some test scenarios for this purpose, but its purpose is more general: as an admin of my node I want to be able to connect to a user-specified peer. This is a common use case for p2p networks - it may be because I know of a peer that is not using discv5, because I'm running a local network or simply because I want to test connectivity to a specific address. In other words, if I want to quickly force connection to a list of peers that's known to me for whichever reason I can use this API, but it's not meant (or used currently) to replace/augment discv5 or other discovery methods. |
For the normal operation of the network and its operator this feature is low frequency of usage and high impact. While for attacker it is high frequency and high impact. This asymmetry skewed in favor of an attacker is what troubles me. Sure attacker needs to first obtain access to the REST API port, local box. After that however, is unstoppable. No authentication, no authorization. Our achilles heel is more vulnerable than it is the case for traditional server based services e.g. DB engines, K8S. They all have well protected service ports, if that is what we can compare our admin API endpoint to. Surely REST API calls to add peer don't replace/augment discv5 or other discovery methods, but they modify content of the peer store. All discovery methods purpose is exactly the same. Except API call does that without any sensitivity or inteligence. Don't know if that would be too daring to try, simply remove those endpoints for few days/weeks and evaluate after ? Prod fleet for Status. What is the worst case, network not operational ? What lessons we might learn ? We are still beta. |
Problem
During interop test_get_peers execution, docker container reported an error:
This issues is only happening for nwaku. Peer exchange works fine for go-waku, going through the same steps.
Impact
High occurrence, low impact.
To reproduce
Expected behavior
Peer exchange requestor (node3) would be able to retrieve peers from peer exchange responder (node2).
Screenshots/logs
node1_2024-07-04_09-44-17__19dc257d-3891-43f6-935a-6735eb6d5a7d__harbor.status.im_wakuorg_nwaku:latest.log
node2_2024-07-04_09-44-17__19dc257d-3891-43f6-935a-6735eb6d5a7d__harbor.status.im_wakuorg_nwaku:latest.log
node3_2024-07-04_09-44-17__19dc257d-3891-43f6-935a-6735eb6d5a7d__harbor.status.im_wakuorg_nwaku:latest.log
nwaku version/commit hash
Custom Docker build from wakunode2-v0.30.1 on ARM/MacOS
The text was updated successfully, but these errors were encountered: