Security: Consider always using observed address for NAT peers to prevent spoofing #2198
Description
Problem
When a peer sends a message with PeerAddr::Unknown, the gateway correctly fills it in from source_addr (the observed UDP source). However, if a malicious peer sends PeerAddr::Known(fake_address), the system uses that address instead of the observed one.
Current Behavior
// subscribe.rs:416-426
if subscriber.peer_addr.is_unknown() { // Only fills if Unknown
subscriber.set_addr(addr);
}A malicious peer could claim PeerAddr::Known(fake_address) and the system would use that instead of the observed address.
Potential Impact
- Medium severity: Could potentially misdirect update broadcasts to unintended targets
- Amplification attacks: If addresses are incorrectly filled in, an attacker could cause the system to send updates to victims
- Trust model violation: The system trusts peer-provided addresses when it has ground truth from the transport layer
Suggested Fix
For certain message types (subscribe requests, connect requests), always override with the observed address:
// For subscribe/connect requests, always use observed address
subscriber.set_addr(addr); // Override regardless of Unknown/KnownThis is a defense-in-depth measure - honest peers will always send Unknown when behind NAT, so overriding has no effect on them.
Importance
Medium priority - This is a security hardening measure. The current implementation works correctly for honest peers, but doesn't defend against malicious address claims.
Context
- Discovered during Claude bot review of PR fix: handle NAT address in subscribe and seeding operations #2193
- Related to NAT address handling in subscribe/seeding operations
[AI-assisted - Claude]