(AEAD) Which fields of the data packet are to be authenticated?

[maxsharabayko]

Which fields of the SRT data packet should be authenticated?

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+- SRT Header +-+-+-+-+-+-+-+-+-+-+-+-+-+
   |0|                    Packet Sequence Number                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |P P|O|K K|R|                   Message Number                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                           Timestamp                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Destination Socket ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +                             Payload                           +
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                        Authentication Tag                     |
   |                 (GCM: 16 bytes / CCM: 14 bytes)               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Only the data field (the payload) is a subject for encryption.
However, more fields can be authenticated. Please note the authenticator has to be added to the packet's payload.

The following fields in the data packet are to be either authenticated (✔️) or not (❌).

Field	Auth-ed?	Motivation
Packet Sequence Number	✔️	Is used to derive the IV, authenticate.
Packet Position Flag (PP)	✔️	Authenticate packet position within a message.
Order Flag (O)	✔️	Authenticate the flag, defining if a packet can be read out of order.
Key-based Encryption Flag (KK)	✔️	The same encryption key is used for the initial sending, and further retransmissions. Authenticate.
Retransmitted Packet Flag (R)	❌	The value is modified by retransmission. Exclude from authentication.
Message Number	✔️	Authenticate.
Timestamp	✔️ ❓	Timestamp is very important for live streaming, and changing it somewhere could ruin the transmission. However, it might cause implications for packet re-routing. Also changed by retransmission if TSBPD is disabled.
Destination Socket ID	✔️	Authenticate to not compromise security. Possible use cases of routing to a different receiver might be affected, e.g. load balancing. But nothing critical comes in mind.
Payload	✔️	The very purpose of authentication.

[ethouris]

If this is about a digitally signed packet than it should embrace all data that are identical in the first-sent packet and retransmitted packet, and the only thing that isn't preserved here is the R retransmission flag. Note though that in case of timestamp, only in the live mode the timestamp is the same in original and retransmitted packet, although I think live mode is the only case for digital signing.

[ethouris]

One more thing: in case of packet re-routing, note that there are only two possibilities:

1. Re-routing on the UDP level. In this case the packet is unchanged, and so it stays with the original signature.
2. Re-routing by the application. In this case the only possibility is to use a "derived signature": the reader application must authenticate the incoming packets, that is, read and verify the signature, and if the signature was confirmed, it should set up its own signature for the outgoing stream. In case when the verification failed, the application may decide whether to stop sending a falsified payload, or to set up a fake signature and continue.

For cases of pass-through signatures, that is, if the SRT rerouting application is unable to verify the signature, but it should be able to reroute packets, it should then use authentication of payload only and maybe also the timestamp, as long as the application will be doing timestamp passthrough (not every one does). Note that both have consequences: if you include timestamp, then the stream is protected against timestamp tampering, but then the application must do timestamp passthrough. Otherwise the application can chose to do timestamp passthrough or not, but then tampering with the timestamps is potentially possible.

I think SRT should support all 3 possibilities.

[maxsharabayko]

With #2581 in the long term and #2573 as the current temporal solution, this issue is now resolved.