Skip to content
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

[api] Socket Options: do not allow AES GCM if TSBPD is disabled. #2573

Merged

Conversation

maxsharabayko
Copy link
Collaborator

@maxsharabayko maxsharabayko commented Dec 7, 2022

The AES-GCM mode cannot be used at the moment if TSBPD is disabled.
The main reason is the different handling of the 'timestamp' field of a data packet (see #2337).
When TSPBD is disabled, the timestamp is set at the time of sending, unique for every retransmission. The timestamp field is included in the associated data for integrity check, while encryption happens only the first time a packet is sent. Using the AES-GCM would fail on a retransmitted packet.

This PR restricts using AES-GCM without TSBPD until a further decision is taken to either exclude the 'timestamp' field from the integrity check when TSBPD is disabled or (preferably) use the same timestamping rule in any mode.

  • Do not allow AES GCM if TSBPD is disabled.
  • Do not allow disabling TSBPD if GCM is enabled.

@maxsharabayko maxsharabayko added Type: Enhancement Indicates new feature requests [API] Area: Changes in SRT library API labels Dec 7, 2022
@maxsharabayko maxsharabayko added this to the v1.6.0 milestone Dec 7, 2022
@maxsharabayko maxsharabayko force-pushed the develop/config-aes-gcm-tsbpd branch from 0c55e80 to 9bd8433 Compare December 7, 2022 09:33
@maxsharabayko maxsharabayko changed the title [api] Socket Options: do not allow AES GCM is TSBPD is disabled. [api] Socket Options: do not allow AES GCM if TSBPD is disabled. Dec 7, 2022
@ethouris
Copy link
Collaborator

ethouris commented Dec 7, 2022

In the meantime: I think it doesn't hurt to change the data timestamp for the retransmitted packets preserve the original sending time. The reception facility doesn't use timestamps for anything anyway. Of course, this means a change in the protocol, but at least an improvement idea ticket could be started.

@maxsharabayko
Copy link
Collaborator Author

In the meantime: I think it doesn't hurt to change the data timestamp for the retransmitted packets preserve the original sending time. The reception facility doesn't use timestamps for anything anyway. Of course, this means a change in the protocol, but at least an improvement idea ticket could be started.

Yes, that's the preferable plan for 1.6.0.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[API] Area: Changes in SRT library API Type: Enhancement Indicates new feature requests
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants