Tracks #791

Description

This enhancement proposes extending the existing Kad-DHT message schema to support the propagation of signed-peer-records (Envelope(PeerRecord)) alongside routing data in DHT message exchanges.

This will be achieved by introducing two new optional fields to protocol buffer definitions:

1. optional bytes sender_record - contains the sender's signed peer-record
2. optional bytes signed_record - added to each Peer message in closerPeers and ProviderPeers lists, holding that peer's signed record.

The final schema will look something like this:

syntax = "proto3";

message Record {
    bytes key = 1;
    bytes value = 2;
    string timeReceived = 5;
};

message Message {
    enum MessageType {
        PUT_VALUE = 0;
        GET_VALUE = 1;
        ADD_PROVIDER = 2;
        GET_PROVIDERS = 3;
        FIND_NODE = 4;
        PING = 5;
    }

    enum ConnectionType {
        NOT_CONNECTED = 0;
        CONNECTED = 1;
        CAN_CONNECT = 2;
        CANNOT_CONNECT = 3;
    }

    message Peer {
        bytes id = 1;
        repeated bytes addrs = 2;
        ConnectionType connection = 3;
        optional bytes signed_record = 4; // Envelope(PeerRecord) encoded
    }

    MessageType type = 1;
    int32 clusterLevelRaw = 10;
    bytes key = 2;
    Record record = 3;
    repeated Peer closerPeers = 8;
    repeated Peer providerPeers = 9;

    optional bytes sender_record = 12; // Envelope(PeerRecord) encoded
}

Upon receiving DHT message, if there are any signed records attached with the message, we process those records with the utilities already in place in Certified-Addr-Book interface in the PeerStore module.

RFC reference:
https://github.com/libp2p/specs/blob/master/RFC/0002-signed-envelopes.md
https://github.com/libp2p/specs/blob/master/RFC/0003-routing-records.md

Motivation

Currently, DHT messages contain only peer-ids and unverified addresses. There's no cryptographic proof that the addresses belong to the claimed peer.

By embedding signed peer records:

• Nodes can opportunistically validate peer identity and associated addresses during DHT interactions.
• Peerstores can be populated with authenticated peer info, improving the quality of the routing table and connection reliability.
• It reduces trust on raw multiaddrs and helps defent against Sybil and eclipse attacks by requiring signed identify/address associations.

This aligns with libp2p's direction of treating the PeerRecord as the canonical representation of a peer’s identity and listen addresses.

Current Implementation

The current Kad-DHT implementation in py-libp2p does not propagate signed peer records in any part of the DHT message exchange.

Only the peer ID and a list of unverified multiaddrs (as raw bytes) are included in:

• closerPeers (from FIND_NODE, GET_VALUE)
• providerPeers (from GET_PROVIDERS)

There is no mechanism in place to send or receive Envelope(PeerRecord) structures over the wire in DHT messages, nor a protocol-level indication of the authenticity of peer information.

The signed-peer-record transfer is functional in the Identify protocol, for reference.

Are you planning to do it yourself in a pull request ?

Yes