Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Can PATH_RESPONSE be sent on a different path than PATH_CHALLENGE? #4064

Closed
DavidSchinazi opened this issue Aug 31, 2020 · 4 comments · Fixed by #4068
Closed

Can PATH_RESPONSE be sent on a different path than PATH_CHALLENGE? #4064

DavidSchinazi opened this issue Aug 31, 2020 · 4 comments · Fixed by #4068
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing

Comments

@DavidSchinazi
Copy link
Contributor

Currently, the Path Validation Responses subsection does not specify which path a PATH_RESPONSE needs to be sent over. That was somewhat surprising to me, as I had expected it to be scoped to the path that PATH_CHALLENGE was received on. If it isn't, could we add a sentence to the Path Validation Responses subsection to explicitly state that a PATH_RESPONSE is not scoped to a given path (and ideally explaining why it isn't)?
@LPardue LPardue added this to Triage in Late Stage Processing Sep 1, 2020
@martinthomson
Copy link
Member

So I thought we were really crisp about this, but we were not.

PATH_RESPONSE does not need to follow the path on which PATH_CHALLENGE was received. We're clear about this when it comes to preferred address handling, but there is some vestigial text that contradicts this. That should be fixed.

@martinthomson martinthomson added the editorial An issue that does not affect the design of the protocol; does not require consensus. label Sep 2, 2020
@project-bot project-bot bot moved this from Triage to Editorial Issues in Late Stage Processing Sep 2, 2020
martinthomson added a commit that referenced this issue Sep 2, 2020
@martinthomson
Path validation is not return reachability
fa52af4 
The original design for path validation attempted to validate return
reachability by requiring that PATH_RESPONSE followed the same path as
PATH_CHALLENGE.  We removed that long ago, but the text retained echoes
of that choice.

Closes #4064.
@martinthomson martinthomson mentioned this issue Sep 2, 2020
Merged
@DavidSchinazi
Copy link
Contributor Author

For the record, I personally believe that #4068 adequately resolves this issue while remaining purely editorial.

@martinthomson
Copy link
Member

Thanks for being so prompt David. I will leave this for a bit to allow others a chance to spot errors, but I plan to merge this before we publish -30 (real soon now, I hope).

@MikeBishop
Copy link
Contributor

Yes, the requirement was removed but the inverse statement was never explicitly added. #4068 corrects that.

Late Stage Processing automation moved this from Editorial Issues to Issue Handled Sep 4, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
-transport editorial An issue that does not affect the design of the protocol; does not require consensus.
Projects
Late Stage Processing
  
Issue Handled
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Path validation is not return reachability quicwg/base-drafts
4 participants
@martinthomson @MikeBishop @DavidSchinazi @LPardue