Draft: draft-omara-sframe

Commentary: LGTM 
 I have a doubt about why an SRC for the CTR is needed at all and if a global counter for all streams would be equally secure in terms forming the IV or was due to implementation details to be able to have different context for each streams ? 
 Because the key is used to encrypt all outgoing stream , we need a global counter for the IV to avoid counter reuse . If we use the frame counter only , then each stream will have their own counter and IV will collide 
 If the frame counter is global for the participant instead that per stream , i.e. increased whenever a new frame is encoded regarding the media stream , there would be no IV collision . 
 Correct . But I imagine this will be more complex to implement , having a single global counter across all media sources including audio and video 
 Prepared a PR to change it to a global counter , however I want to make sure I understand how the counter is maintained globally , If the frame N is encrypted in 3 different layers , they will have different counter values right ? One potential benefit of having a global counter it will free up some bits in the header which we can use as a keyId ( up to 16 keys ) which is nice 
 Yes , each call to the frame encryptor which would require to atomically increment the counter . In the case of the simulcast , the same input image will produce N different encoded frames which would have their unique counter . Regarding the free bits , I was thinking in something like this : If x=0 then K is the key i d ( 0 - 7 ) if x=1 then K is the length of the key that is inserted before the This would allow to avoid the extra byte for conferences with less than 9 participants . Another option would be to always use the KLEN / KEYID and reserve that bit for extensions in the future . 
 I like it :-)
The first byte in the header is fixed and contains the header
metadata S 1 bit Signature flag, indicates the payload contains a
signature of set.
LEN (3 bits) The length of the CTR fields in bytes.
As each sender will use their own key for encryption, so the SFrame
header will include the key id to allow the receiver to identify the
key that needs to be used for decrypting.
Signature flag (S): 1 bit This field indicates the payload contains a
signature of set.  Counter Length (LEN): 3 bits This field indicates
the length of the CTR fields in bytes.  Extended Key Id Flag (X): 1
bit
Indicates if the key field contains the key id or the key length.
Key or Key Length: 3 bits This field containts the key id (KID) if
the X flag is set to 0, or the key length (KLEN) if set to 1.
Key id (KID): 3 bits The key id (0-7).  Frame counter (CTR):
(Variable length) Frame counter value up to 8 bytes long.
Key length (KLEN): 3 bits The key length in bytes.  Key id (KID):
(Variable length) The key id value up to 8 bytes long.  Frame counter
(CTR): (Variable length) Frame counter value up to 8 bytes long.
The sending client maps the outgoing streams and give them unique
indices: 0, 1,.. etc.  As mentioned above SFrame supports up to 16
outgoing stream.  After encoding the frame and before packetizing it,
the necessary media metadata will be moved out of the encoded frame
buffer, to be used later in the RTP header extension.  The encoded
frame, the metadata buffer and the stream index are passed to SFrame
encryptor which internally keeps track of the number of frames
encrypted so far for that stream.  The encryptor constructs SFrame
header using the stream index and frame counter and derive the
encryption IV.  The frame is encrypted using the encryption key and
the header, encrypted frame and the media metadata are authenticated
using the authentication key.  The authentication tag is then
truncated (If supported by the cipher suite) and prepended at the end
of the ciphertext.
After encoding the frame and before packetizing it, the necessary
media metadata will be moved out of the encoded frame buffer, to be
used later in the RTP header extension.  The encoded frame and the
metadata buffer are passed to SFrame encryptor which internally keeps
track of the number of frames encrypted so far.  The encryptor
constructs SFrame header using frame counter and key id and derive
the encryption IV.  The frame is encrypted using the encryption key
and the header, encrypted frame and the media metadata are
authenticated using the authentication key.  The authentication tag
is then truncated (If supported by the cipher suite) and prepended at
the end of the ciphertext.
The sender of a simulcast stream may use the same SRC for all the
simulcast streams from the same media source or use a different SRC
for each of them, in any case it is transparent to the SFU which will
be able to perform the simulcast layer switching normally.  The
senders are already able to receive different SRCs from different
participants due to LastN and RTP Stream reuse, so supporting
simulcast uses same mechanisms.
When using simulcast, the same input image will produce N different
encoded frames (one per simulcat layer) which would be processed
inpependently by the frame encryptor and assigned an unique counter
for each.
In both temporal and spatial scalability, the SFU may choose to drop
layers in order to match a certain bitrate or forward specific media
sizes or frames per second.  In order to support it, the sender MUST
encode each spatial layer of a given picture in a different frame.
That is, an RTP frame may contain more than one SFrame encrypted
frame with same source (SRC) and incrementing frame counter.
In both temporal and spatial scalability, the SFU may choose to drop
layers in order to match a certain bitrate or forward specific media
sizes or frames per second.  In order to support it, the sender MUST
encode each spatial layer of a given picture in a different frame.
That is, an RTP frame may contain more than one SFrame encrypted
frame with an incrementing frame counter.