Draft: draft-ietf-sframe-enc

Commentary: This PR addresses a few outstanding formatting cleanup issues : Fixes the list formatting problems identified in ... as well as a few others Wraps paragraphs to 80 columns 
 Merging on my own since these are just formatting changes . 
 This : ... is probably not a single paragraph . Similar problems and . It might be worth a more thorough proof - read of the document for others similar formatting problems .
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.
This field MUST be set to zero on sending, and MUST be ignored by
receivers.
This field indicates the length of the CTR field in bytes, minus
one (the range of possible values is thus 1-8).
Indicates if the key field contains the key id or the key length.
This field contains the key id (KID) if the X flag is set to 0, or
the key length (KLEN) if set to 1.
Selective Forwarding Units (SFUs) as described in
https://tools.ietf.org/html/rfc7667#section-3.7 receives the RTP
streams from each participant and selects which ones should be
forwarded to each of the other participants.  There are several
approaches about how to do this stream selection but in general, in
order to do so, the SFU needs to access metadata associated to each
frame and modify the RTP information of the incoming packets when
they are transmitted to the received participants.
Selective Forwarding Units (SFUs) as described in Section 3.7 of
RFC7667 receives the RTP streams from each participant and selects
which ones should be forwarded to each of the other participants.
There are several approaches about how to do this stream selection
but in general, in order to do so, the SFU needs to access metadata
associated to each frame and modify the RTP information of the
incoming packets when they are transmitted to the received
participants.
The SFU may choose to send only a certain number of streams based on
the voice activity of the participants.  To reduce the number of SDP
O/A required to establish a new RTP stream, the SFU may decide to
reuse previously existing RTP sessions or even pre-allocate a
predefined number of RTP streams and choose in each moment in time
which participant media will be sending through it.  This means that
in the same RTP stream (defined by either SSRC or MID) may carry
media from different streams of different participants.  As different
keys are used by each participant for encoding their media, the
receiver will be able to verify which is the sender of the media
coming within the RTP stream at any given point if time, preventing
the SFU trying to impersonate any of the participants with another
participant's media.
The SFU may choose to send only a certain number of streams based on
the voice activity of the participants.  To reduce the number of SDP
O/A required to establish a new RTP stream, the SFU may decide to
reuse previously existing RTP sessions or even pre-allocate a
predefined number of RTP streams and choose in each moment in time
which participant media will be sending through it.
This means that in the same RTP stream (defined by either SSRC or
MID) may carry media from different streams of different
participants.  As different keys are used by each participant for
encoding their media, the receiver will be able to verify which is
the sender of the media coming within the RTP stream at any given
point if time, preventing the SFU trying to impersonate any of the
participants with another participant's media.
The encryption overhead will vary between audio and video streams,
because in audio each packet is considered a separate frame, so it
will always have extra MAC and IV, however a video frame usually
consists of multiple RTP packets.  The number of bytes overhead per
frame is calculated as the following 1 + FrameCounter length + 4 The
constant 1 is the SFrame header byte and 4 bytes for the HBH
authentication tag for both audio and video packets.
Using three different audio frame durations 20ms (50 packets/s) 40ms
(25 packets/s) 100ms (10 packets/s) Up to 3 bytes frame counter (3.8
days of data for 20ms frame duration) and 4 bytes fixed MAC length.
RFC8723 has significant overhead over SFrame because the overhead is
per packet, not per frame, and OHB (Original Header Block) which
duplicates any RTP header/extension field modified by the SFU.  I-
D.murillo-perc-lite <https://mailarchive.ietf.org/arch/msg/perc/
SB0qMHWz6EsDtz3yIEX0HWp5IEY/> is slightly better because it doesn't
use the OHB anymore, however it still does per packet encryption
using SRTP.  Below the the overheard in I-D.murillo-perc-lite
implemented by Cosmos Software which uses extra 11 bytes per packet
to preserve the PT, SEQ_NUM, TIME_STAMP and SSRC fields in addition
to the extra MAC tag per packet.
The encryption overhead will vary between audio and video streams,
because in audio each packet is considered a separate frame, so it
will always have extra MAC and IV, however a video frame usually
consists of multiple RTP packets.
The constant 1 is the SFrame header byte and 4 bytes for the HBH
authentication tag for both audio and video packets.
Up to 3 bytes frame counter (3.8 days of data for 20ms frame
duration) and 4 bytes fixed MAC length.
RFC8723 has significant overhead over SFrame because the overhead is
per packet, not per frame, and OHB (Original Header Block) which
duplicates any RTP header/extension field modified by the SFU.
I-D.murillo-perc-lite <https://mailarchive.ietf.org/arch/msg/perc/
SB0qMHWz6EsDtz3yIEX0HWp5IEY/> is slightly better because it doesn't
use the OHB anymore, however it still does per packet encryption
using SRTP.
Below the the overheard in I-D.murillo-perc-lite implemented by
Cosmos Software which uses extra 11 bytes per packet to preserve the
"PT", "SEQ_NUM", "TIME_STAMP" and "SSRC" fields in addition to the
extra MAC tag per packet.
An implementation should reproduce the output values given the input
values: * An implementation should be able to encrypt with the input
values and the plaintext to produce the ciphertext.  * An
implementation must be able to decrypt with the input values and the
ciphertext to generate the plaintext.
An implementation should be able to encrypt with the input values
and the plaintext to produce the ciphertext.
An implementation must be able to decrypt with the input values
and the ciphertext to generate the plaintext.