If the peer does not reply with a path_abandon frame, state can never be removed

[mirjak]

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?

[huitema]

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.

[mirjak]

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.

[qdeconinck]

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.

[mirjak]

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.

[huitema]

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:

1. Start a timer after sending the first path Abandon, then close the connection with an error code if the path abandon from the peer is not received in time. Of course, all solutions based on timers introduce some fragility, so the timer will have to be large.

2. Same, but start the timer after the Path Abandon frame is acknowledged. More complicated than 1 because you need to track ACKs, and same fragility.

3. Do nothing. After all, the only effect of having a path lingering in limbo is to reduce the number of path-id available for path creation. If you don't need to create a new path, there is no real issue. This is the option with the least side effects.

4. Put the path in some explicit limbo state after the Abandon is acked or after a short timer. In that state, drop all incoming packets, never ack them. Kinda like doing nothing, but with fewer resource allocated locally.

[michael-eriksson]

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.

[mirjak]

@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!