-
Notifications
You must be signed in to change notification settings - Fork 21
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.
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
If the peer does not reply with a path_abandon frame, state can never be removed #471
Comments
If a peer misbehaves, as in "doesn't send a path_abandon frame ever", you should treat that as an attack. Very much a variant of the Slow loris attack described in the security section of RFC 9000. Closing the connection would be appropriate. |
It's a bit hard to enforce as the PATH_ABANDON frame can get lost and need to be retransmitted. So you basically would need to start a timer after sending the PATH_ABANDON frame and the close the connection after N x 3 PTOs where N is the number of expected retransmission approaches. That seems a bit to radical for me. However, I think we either need to specify this or re-define when state can be finally removed. |
While a peer may indeed misbehave, there may be specific pattern losses making the PATH_ABANDON frame never reach the peer. While the reception of the PATH_ABANDON frame will lead to removal of path state after some delay, it would make sense to me to apply this 3 PTO delay when the PATH_ABANDON is sent. At some point, the peer that has sent the PATH_ABANDON will abandon the path anyway, and dropping state related to the path will just, in the case the PATH_ABANDON does not reach the peer, make the host ignore all incoming packets mapping to that path, such that the peer would interpret this as a completely lossy path that it can eventually abandon. Note that if a PATH_ABANDON is deemed lost, the sender should always resend it, even if the related path state is no more present. |
You have start a start a timer after sending the PATH_ABANDON frame anyway because you may have to retransmit it. I think what we need is to also start a timer after the ACK for the PATH_ABANDON has been received and also specify that the PATH_ABANDON should not be retransmitted more than X time and when you stop retransmitting you also remove all path state. I guess we could also say that you can remove most path state after the first PTO and then only keep information about the PATH_ABANDON in order to retransmit it. But not sure if that makes a big difference. |
I think that we should point out the issue and leave the implementers a choice. As discussed in the WG, we do not have a lot of experience with deployment. This is kind of a research area, and we are exhausting ourselves trying to provide operational guidance or implementation guidance. There are indeed multiple choices:
|
FWIW, I think choice number 3 is the correct one. An endpoint should however be allowed to ignore any incoming packets after some (unspecified) time. Setting a timer to abort the connection is needlessly complex and brutal, and can easily have false positives if the peer's PATH_ABANDON frame is retransmitted. |
@michael-eriksson if you say the endpoint should be allow to ignore incoming packets that is option 4. Anyway, I think we agree that we want to note the issue but don't specify anything normatively. So I created PR #475. Please have a look! |
My view is that the endpoint MAY do option 4, but shouldn't have to.
Looks good to me! |
Currently the draft only says:
"knowledge of the connection identifiers received from the peer and of the state of the number space associated to the path SHOULD be retained while packets from the peer might still be in transit, i.e., for a delay of 3 PTO after the PATH_ABANDON frame has been received from the peer"
Therefore state removal is triggered by reception of the path abandon frame. There is MUST in the text that my peer must send me a path_abandon frame if it has received mine. What if it doesn't send a path_abandon frame ever?
The sentence above is only a SHOULD, so I guess you could remove state any reasonable time after sending the path_abandon frame, however, maybe we should say more explicitly that it makes sense to also start a timer after the ACK for the path_abandon frame was received, or stop retransmitting the path_abandon frame after X tries and then just remove state?
The text was updated successfully, but these errors were encountered: