Ralith
commented
2 months ago This is working as intended. No action is required on reciving PATH_RESPONSE on an old path. See §9.3.3:
If the [previous] path is no longer viable, the validation attempt will time out and fail; if the path is viable but no longer desired, the validation will succeed but only results in probing packets being sent on the path.
The true purpose of sending that PATH_CHALLENGE is to facilitate this mitigation:
An endpoint that receives a PATH_CHALLENGE on an active path SHOULD send a non-probing packet in response. If the non-probing packet arrives before any copy made by an attacker, this results in the connection being migrated back to the original path. Any subsequent migration to another path restarts this entire process.
This behavior is already implemented.
nemethf
When the server notices a migration, it sends a path-challenge on the previous path as well. However, the server cannot validate the path-response to this challenge as it only checks the token of the path-challenge sent on the new path. I think this means if the new path cannot be validated, then the server switches back to the previous path, but it still needs to be validated, although there was plenty of time to re-validate the previous path.
I think the server here behaves sub-optimally, but the failure of the new path is an abnormal situation and the server will eventually validate the previous path and everything will go back to normal. So probably this is not a serious issue. I wanted to report it in case you are not aware of it.