Sender peer identity discarded — no application-layer message authentication

[MastaP]

Summary

network/libp2p_network.go:234-241 — The `receivedMsg` function receives the `from` peer.ID parameter (from `s.Conn().RemotePeer()`) but discards it, sending only the message into the `receivedMsgs` channel. Downstream handlers in `partition/node.go` process messages with no knowledge of which peer sent them.

While libp2p provides transport-level authentication, the application layer cannot verify that the sender is an authorized validator. Any peer that can connect can inject protocol messages.

Impact

• Block proposals: mitigated by cryptographic signature verification in `BlockProposal.IsValid()`
• Replication requests/responses: no authentication — any connected peer can forge these
• Handshake messages: no authentication — any peer can impersonate a validator
• No per-peer rate limiting possible since peer identity is lost

Severity

High

Suggested Fix

Wrap messages with sender identity before putting on the channel:

type ReceivedMessage struct {
    From peer.ID
    Msg  any
}

Then validate sender identity in the message handlers against the known validator set.

Related

• All protocols share a single untyped channel (cap 1000). A single peer can flood it, causing legitimate messages from all peers to be dropped.
• No per-peer backpressure or rate limiting exists.

[lploom]

This is likely WONTFIX

1. Block proposals are already cryptographically validated.
2. Replication requests are public by design (likely from non-validator days)
3. Handshake messages - this is confusing - handshake message is a message sent from partition node to root node to which root node replies with UC, so it's probably AI hallucination.