peer address update checks #65
Conversation
|
I think the first paragraph of this PR is fine, but the rest is out of scope. The agreed upon intent of this draft is simply to allow flow identification, not to provide a generic address migration facility. That is a complicated topic that should be out of scope here. |
|
I would prefer / appreciate, if the parts after the first paragraph would start with explaining the vulnerability and the attack, which may use it. That would setup the right scope for understanding, when a mitigation is required to protect other systems. In the discussion #64 I tried to point out, that I would prefer to leave the mitigation to the using system and just mention the "heartbeat" as one solution. |
- Remove heartbeat based address validation -- I’ll probably write up the the proposal in a separate draft; - Push peer validation up in the stack by RECOMMENDing that implementations expose peer address updates to their user.
|
We don't have consensus for all of this text. I think the proposal is to address tis in a separate document. Can we close this PR? |
The current version of this PR has expunged the text that outlined an address validation sub-protocol. This can and will be sketched separately. What is left here is just a description of what the problem is and what a receiver must do to counter at least two possible attacks using simple unilateral measures. I'm not sure what is controversial? |
|
I would prefer, if the risk of the "man-in-the-middle" explicitly states, that
In my opinion, too general descriptions of risks tend to be misunderstood. |
|
This PR has been replaced by text offered in #68 |
A first attempt to address #64 , as per discussion with Achim.