search

libp2p / specs

Technical specifications for the libp2p networking stack
https://libp2p.io
1.56k stars 273 forks source link

mDNS: the spec to explicitly allow for configurability of the service name #620

Open dhuseby opened 3 months ago

dhuseby commented 3 months ago 
          https://github.com/libp2p/specs/blob/master/discovery/mdns.md#definitions

If a private network is in use, then the service-name contains the base-16 encoding of the network's fingerprint as in _p2p-X._udp.local. This prevents public and private networks from discovering each other's peers.

The spec mentions that when using a private network, you can contains the network's fingerprint in the service name to prevent the private network and the public network from discovering each other.

In the Go implementation, I use a service name like this: _p2p-dced2aa3b9ea8def145b7f80271517b6._udp

Originally posted by @fei-ke in https://github.com/libp2p/rust-libp2p/issues/2898#issuecomment-2171749317

dhuseby commented 3 months ago

also https://github.com/libp2p/rust-libp2p/issues/2898#issuecomment-2171977190

dhuseby commented 3 months ago

@aschmahmann has some thoughts

aschmahmann commented 3 months ago

A few thoughts:

  1. There is already some configurability/fragmentation described in the spec for private swarms / pnet which addresses this a little but not enough for some users
    • We've seen this people use pnet for isolation ("this isn't really meant to talk to other systems) more than security, speaking to a desire for some level of isolation
    • We've also seen this in say forks of protocols like Bitswap where some will use the same protocol + implementation but fork the protocol ID to have a base level of separation
    • This pushes towards allowing users to fragment by "application" (e.g. like the service-name)
  2. AFAICT it seems like the main reason for this proposal is for users to save the resources around making connections + performing identify or a similar protocol before deciding if they want to talk to some peer.
    • If doing this it might be helpful to remind users they should have a plan in place for receiving connections from peers not in their "service" since having an application-specific service name does not mean you won't get libp2p connections from other sources
    • Someone with greater expertise should check me, but I'm not sure we'd want to encourage too many mDNS service names since IIRC various devices run into problems with too many mDNS messages (not sure how much the problems were about bandwidth vs just the number of messages).
      • If this is an issue that would push us away from many service names, perhaps it'd help to modify the spec to enable sending back more "identify-like" information than just a multiaddr (depends on what the scale issues are)