search

martinthomson / train-protocol

Choo Choo!
Other
0 stars 0 forks source link

Allow SCID to match the next packet #16

Closed martinthomson closed 3 weeks ago

martinthomson commented 3 weeks ago

Closes #13.

martinthomson commented 3 weeks ago

Good catch. Though I realize now, when writing this up, that this is not necessarily possible.

Let's say that you process packets in order. The order of events is something like this:

  1. You process the TRAIN packet. It looks fine, but you can't validate the SCID yet. You save the indicated rate for later.
  2. You process the v1 packet that follows. It is fine and you handle it.
  3. You now go back to the indicated rate and apply it.

At what point do you recognize that the SCID in the TRAIN packet is bad? You could, I guess, interrupt the processing of the v1 packet at the point that you read off the SCID and abort the entire thing. That might be possible in our implementation, though it is a little bit weird because it requires acting on state that might not be saved otherwise. But it's a bit intrusive and I can't see how that would be easy to do in a general fashion.

I'm going to go with "MAY" for the requirement, because I can't see how this would be reliably implemented without a whole lot of back and forth. The harm here is minimal, so if it isn't enforced, that's OK as long as the packet is well-formed.