libp2p
feat(identify): push changes of external addresses
Description
Related: #4867.
Notes & open questions
None
Change checklist
- [x] I have performed a self-review of my own code
- [x] I have made corresponding changes to the documentation
- [ ] I have added tests that prove my fix is effective or that my feature works
- [x] A changelog entry has been made in the appropriate crates
Interestingly, Kademlia test adding_an_external_addresses_activates_server_mode_on_existing_connections (at least) became non-deterministic, so I disabled this new feature for Kademlia tests.
A historical note, I believe this has not been done in the past due to the following attack:
Attacker continuously tells target a new (fake) external address of the target. Target sends N updates each time where N is the number of connected peers. I.e. an amplification attack.
That said, this was pre-autonat where we could validate external addresses. With AutoNATv2, and only pushing the update after validation, this should be fine.
Attacker continuously tells target a new (fake) external address of the target. Target sends N updates each time where N is the number of connected peers. I.e. an amplification attack.
That said, this was pre-autonat where we could validate external addresses. With AutoNATv2, and only pushing the update after validation, this should be fine.
This attack is a problem if we treat an observed address as an external address. We don't do that but users might easily do (take the identify event and call Swarm::add_external_address with it).
This makes me think that this behaviour should definitely not be the default. Instead, I think we should put a good warning and explanation to this option that educates users about this attack vector.
