STREAM_ATTACH needs a STREAM_ATTACH_ACK
frochet opened this issue · 2 comments
if multiple stream_attach are sent at the same time through different TCP connections, and those stream_attach share the same cryptographic context, then the peer may receive the wrong order of stream_attach records and fail the decryption.
authorizing one stream_attach per cryptographic context in fly would fix the issue
if multiple stream_attach are sent at the same time through different TCP connections, and those stream_attach share the same cryptographic context
You mean if those STREAM_ATTACH are sent over a given stream split over several TCP connections ?
No. You may have N TCP connections, and N stream creations going on at the same time. Let's assume those N TCP connections are fresh, and the TCPLS handshakes (the main one, and the JOIN ones) just finished. You may have a Stream creation message going on in parallel over all TCP connection. Since those messages use the same cryptographic context (there is only one at this stage), they must be processed in the same order as sent. Which is not the case currently. You may get the wrong order on the receiver side.
This bug might be fixed by adding a STREAM_ATTACH_ACK, and sending stream attach messages with the same crypto context only when we're sure the receiver already processed the previous one. We're sure of this fact when we would see the _ACK message