Investigate ROC mismatch with initial packets

[pabuhler]

As the test added in #725 demonstrated, if the initial sequence number is very close to 0xFFFF and the fist packets are lost or arrive out of order it is possible that the stream will never be able to achieve ROC synchronization and so all packets will fail authentication.

[pabuhler]

@fippo I looked in to this a bit more and in general I think we do the right thing with regard to https://datatracker.ietf.org/doc/html/rfc3711#section-3.3.1 once the stream has been initialized, it is only the initial packets that can cause the problem as shown in your test. It would have been an ok idea to try with ROC + 1 if the first packet fails, but also as your test showed, when using GCM based cipher and in-place io the buffer is modified during the decryption & authentication step. That means it would no longer be possible to try again with ROC + 1 with out making a copy of the original packet. This allocation & copy would have to be made for first packet of every new SSRC when using GCM and in-place io. So the question is if it would be worth doing this. It could be possible to add config to opt in or out. What do you think? It is still possible for the application to do this them self with the set roc command.

[fippo]

GCM adds that additional challenge here indeed!

I do not think it is worth doing, we have pretty good consensus on "pick your initial sequence number low enough". Maybe it is time to "formalize" that consensus through a FYI errata to 3711?