Draft: draft-ietf-sframe-enc

Commentary: I suppose there 's a valid question about how prescriptive we want to be about CTR . On the one hand , the hard requirement is that ( KID , CTR ) pairs be unique , not that CTR be a counter , so you could allow senders flexibility in populating CTR as long as they enforce uniqueness . On the other hand , if CTR is required to be a counter , you can rely on that for things like gap and replay detection or reordering ( as with the RTP sequence number ) . 
 It might be worth an issue . It seems to me we should probably spell out explicitly a good default implementation ( incrementing counter ) given it is simple and efficient .
Since each endpoint can send multiple media layers, each frame will
have a unique frame counter that will be used to derive the
encryption IV.  The frame counter must be unique and monotonically
increasing to avoid IV reuse.
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.
Reserved (R): 1 bit This field MUST be set to zero on sending, and
MUST be ignored by receivers.  Counter Length (LEN): 3 bits This
field indicates the length of the CTR fields in bytes (1-8).
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
contains the key id (KID) if the X flag is set to 0, or the key
length (KLEN) if set to 1.
Frame counter byte length (LEN): 3bits The frame counter length in
bytes (1-8).  Key id (KID): 3 bits The key id (0-7).  Frame counter
(CTR): (Variable length) Frame counter value up to 8 bytes long.
Frame counter byte length (LEN): 3bits The frame counter length in
bytes (1-8).  Key length (KLEN): 3 bits The key length in bytes
(1-8).  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.
An SFrame ciphertext comprises an SFrame header followed by the
output of an AEAD encryption of the plaintext RFC5116, with the
header provided as additional authenticated data (AAD).
The SFrame header is a variable-length structure described in detail
in sframe-header.  The structure of the encrypted data and
authentication tag are determined by the AEAD algorithm in use.
When SFrame is applied per-packet, the payload of each packet will be
an SFrame ciphertext.  When SFrame is applied per-frame, the SFrame
ciphertext representing an encrypted frame will span several packets,
with the header appearing in the first packet and the authentication
tag in the last packet.
Applications MUST ensure that each (KID, CTR) combination is used for
exactly one encryption operation.  Typically this is done by
assigning each sender a KID or set of KIDs, then having each sender
use the CTR field as a monotonic counter, incrementing for each
plaintext that is encrypted.  Note that in addition to its
simplicity, this scheme minimizes overhead by keeping CTR values as
small as possible.
Both the counter and the key id are encoded as integers in network
(big-endian) byte order, in a variable length format to decrease the
overhead.  The length of each field is up to 8 bytes and is
represented in 3 bits in the SFrame header: 000 represents a length
of 1, 001 a length of 2, etc.
Reserved (R): 1 bit This field MUST be set to zero on sending, and
MUST be ignored by receivers.  Counter Length (LEN): 3 bits This
field indicates the length of the CTR field in bytes, minus one (the
range of possible values is thus 1-8).  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 contains the key id (KID) if the
X flag is set to 0, or the key length (KLEN) if set to 1.