Sequence number: constraints?

[aboba]

Are there any constraints on the value of sequence numbers that can be set? For example:

1. In RTP, initial sequence numbers SHOULD be unpredictable. Can an application set the initial sequence number, or is this provided by the user agent?

2. Subsequently, can an application set the sequence number to an arbitrary value, or are there constraints that need to be obeyed? For example:
   a. Is it possible to set the sequence number to a previous (duplicate) value without the ROC having incremented?
   b. Can the sequence number be set to an arbitrary value or need it be set within a window?

[alvestrand]

I think the reason it should be unpredictable is that it provides a part of input to encryption that the user cannot set (section 9.1).
However, I'm unsure if this is still a concern when SRTP is used; SRTP is a good deal more designed than section 9.1 is.

[alvestrand]

Conservative me would be more comfortable if RTP sequence number was always set by the platform, and couldn't be changed by the app.

[tonyherre]

Considering usecases, UC1's "custom packetizer" usecase doesn't need app control over seq numbers at all (hence #22), so the UA can control it entirely. Assuming pacing and padding is being done by the UA, it's required to control the seq numbers so it can insert padding packets itself.

UC2 when taken to the point of app-controlled pacing, padding, prioritization etc for everything could control sequence numbers, but the UA could also control them entirely afaict, just set based on the ultimate send order. Would be much simpler to require that for both app and UA implementor.

The answer is the opposite if we want to go as far as @Philipel-WebRTC's #40 and support near arbitrary packet sending with far less guardrails. That would require arbitrary values, but potentially with a UA-supplied initial number? Not sure how the app would get told about it though? I would guess the app-set value would have to be the exact value sent on the wire, to enable out-of-band communication which refers to specific packets.

[aboba]

@tonyherre One concern about allowing the application to set SEQ arbitrarily is the potential for the sender and receiver ROC to get out of sync (e.g. by having the sender SEQ skip 2^15 packets), or for the sender "packet index" ( 2^16 * ROC + SEQ) to be set outside the rekey window without triggering rekey, causing SRTP decryption failures on the receiver.

[Philipel-WebRTC]

Conservative me would be more comfortable if RTP sequence number was always set by the platform, and couldn't be changed by the app.

AFAIK the recommendation of starting with a random sequence number is not relevant when SRTP is used. I'm certainly not an expert, but I really don't want to bring in limitations based on outdated advice. If the app can't set the sequence number then client-node networks will be limited, no out-of-order forwarding, no stream filtering.

We should probably have some form of limitation to avoid breaking encryption and authentication. I think having a window of acceptable sequence numbers and checking that no duplicate is sent within that window should work.

[algesten]

For fan-out scenarios with encrypt once and decrypt on multiple clients, the start sequence number (or rather ROC), needs to be sent out of band since the extended sequence number is used to derive the IV for SRTP. I think that means that at least the receiving side needs to be able to set the expected sequence number (or ROC).

https://datatracker.ietf.org/doc/html/rfc3711#section-3.3.1

"Receivers joining an on-going session MUST be given the current ROC value…"

2. Is it possible to set the sequence number to a previous (duplicate) value without the ROC having incremented?

Allowing the IV/nonce derived from the sequence number to repeat, would maybe break encryption?