Re: [AVTCORE] Errata 4192 RFC 3550

[Julius Friedman <[e-mail]>]

Dear Mr. Casner / Audio Video Working Group.

Sincerely thank you for responding in a manner which clearly shows that you
have taken the time to acknowledge my inquiry. I know my previous emails
were hastily written and this one is probably not much better but I will
endeavor to express my concerns and points and then in summary ask you
respond at least once again.

I would like to first start of by saying that if I did have functions which
are not specified they would not be standard and hence not relevant for
errata, the reason I wrote this errata is because I know that others have
also had issues when reading that sentence (and multiple others in the Rtp
RFC [3550]) and I would like to clarify if nothing else why I believe it is
errata and why it can potentially be a security risk.

I don't mean to pick apart your answer but I would like to take some of
your response and ensure I understand it correctly.

"
Let me clarify.  When we wrote that sentence, we were stating why this
field was included.

It was included so that receivers would be able to know the sender's
average payload data rate over various time intervals by taking the value
of this field from two sender reports and dividing by the difference in
time of the two sender reports.

The receiver might want to compare that result with the average of the data
as received (perhaps with some losses).
"

Advising by your statement, particularly the bit about how one could
possibly calculate the data rate over various time intervals, if I were to
disagree I would first have to ascertain the exact meaning of such a term
[payload data rate] thus first we must look at your wording, "sender's
average payload data rate".

To answer this, and some of the latter questions in your email.

What is a payload before we can talk about it's data rate? Well it is
EVERYTHING that is not the header.

What is the header? The header (in terms of Rtp Packets) consists of the
first 3 words (12 octets) which indicate the version, padding, extension,
contributing source count, payload type, marker, sequence number, ssrc and
timestamp.

Before I continue my arguement I will make a statement to show my line of
thinking;

Since each transmission of a "valid" rtp packet might consist of ONLY a
header the payload size in such a case would be 0.

A valid rtp packet may have a contributing source counter <= 15, this
implies that another csrc words following the 12 required header octets.

A valid rtp packet may have an extension, when present will follow
immediately after the csrc words indicated by the csrc nibble in the header.

A valid rtp packet may contain padding, when present it will follow any
"payload data" and such padding must define a count which is set in the
final octet of the raw binary sequence which is defined as the rtp packet.

Because of the above given restraints it can be seen that a receiver must
have a valid RTP Header consisting of 12 octets to properly determine if
the data received is valid / complete.

Given those notions I will continue my arguments;

While the header is technically extended by the presence of csrc, extension
and the payload is proceeded by padding it makes sense to think of them as
contained in the payload section and such calculations regarding their
length (especially padding) can only be made after reception of at least 12
octets.

No matter if RTP Lite is used and the Rtp Header is not 12 octets or ROHC
is employed and the header is not 12 octets, and thus may be re-constructed
or de-compressed the amount of header bytes can explicitly be calculated to
12 octets.

Thus any time the 'sender's packet count' increases one receiver can
multiply that number [sender's packet count] by 12 to receive the amount of
bytes related to rtp headers in transmissions, this would reveal a payload
data rate of 0 in such cases as the sender is sending "rtp header" only
packets to a receiver.

Taking the same example, if I add ONLY padding to the payload and I
followed your recommendation I would still have data rate of 0 in such a
case.

The same would apply for csrc and extensions of combinations of all 3
regardless of their length and contribution to the overall rate of data
(and their subsequent effects on the network [regardless how small they
are]).

When middle boxes receive rtp packets and remove extensions or a mixer
combined several sources and indicates so in the csrc field the payload
data rate technically doesn't change but the overall data rate does, while
when using your recommended count the receiver will not be able to
determine if the path between the two changes due to a mixer or middle box
performing any modification of the data packets from the sender because the
data is "hidden" using your recommended count. While this may be desirable
for some reasons as it would keep the size the same and the count the same,
it removes information which would be able to be used for various purposes
such as determining if alternates routes are followed etc; while a receiver
is very well able to keep on their own of the amount of total bytes they
are receiving, and they as well can calculate the amount of padding and
bytes related to csrc, extensions the problem arises if and when packets
are lost.

In such a case the receiver will not be able to calculate the amount of
data or other bytes because the packet was not received, while the standard
allows for also calculating how much was lost there needs to be a reference
point; This is where [sender's packet count] is needed and using it one can
then indicate roughly how many bytes were missing using the amount of
packets indicated there minus the amount received to determine the exact
amount of packets lost (but I suppose would not be needed if you were JUST
determining payload data rate, it would simply be lower or higher given the
two differences in the [senders octet count] value and the time received).

Finally, the security risk of indicating the amount of bytes related to
payload data (especially considering now your explicitly stating to remove
the extension and csrc data from) versus just bytes for counting purposes
is simply this.

Over a time (regardless if padding only packets are sent or not) one can
quickly determine if extensions, csrc or padding is then in used in rtp
just by monitoring the value in the senders report versus what was actually
sent on the wire.

This also reveals the congruence of the padding with respect to the
payload, and thus reduces complexity in determining the key (by knowing the
padding length using it to lower the amount of attempts required to derive
the correct key) by the amount of bytes not relevant to the portion being
ciphered.

Even though the extension and csrc are probably encrypted  the senders
octet count again reveals the amount of bytes only related to DATA so the
length of these values can be extracted and thus the amount of data which
is probably the same and in any such case not related to the payload can
thus be derived and used to shorten the amount of time in deriving a
correct key.

With my proposed changes (which is simply just using the entire length of
the binary payload - 12 for the header length) one will make the derivation
of bytes related to csrc / extension and padding much more difficult if not
impossible to derive.

It will also increase the accuracy of your given calculation because more
bytes are being included in the value which allow a higher degree of
accuracy when related to the other factors given (e.g. jitter takes into
account the whole packet, not just the payload data rate) It is important
to realize that no distinction should be made after transport of the "rate"
with anything other than whole and valid packets because of middle boxes
and other such devices (mixers) which may alter the end contents of the
packet, and by doing so does not break compatibility in the standard only
allows for more accurate and useful information to be derived without
chaining anything besides removing additional subtraction from a place
where is is not required and poses no benefit and citing my explanations
thus constitutes it as errata from my perspective.

In short, it makes sense to use the property as it was named and give the
receiver the ability to determine average / total or whatever else they
want to by simply giving them the information as required, removing
information serves no positive purpose in this case and let me also point
out that not many (if not all) implementations I can find already are just
giving the "payload" count, there are very very few which actually take
into account extensions and csrcs and slightly more that account for
padding including the software 'rtp tools' which was developed by Mr.
Schulzrinne.

This will actually make software existing more correct in those cases while
not changing anything in the standard although that is not a reason to
change it I hope you also can see there is no negative effect with my
proposed change, e.g. if a person forgets to set extension, csrc or padding
my implementation will see no different but yours will.

If your application changes to include the count as I indicated and
performs the same calculations it performs today, (taking padding into
account as well as extension and csrc) it will not change the result of any
existing algorithm.

Therefore I strongly recommend that you base your decision on those points
and additionally the fact it weakens security is an issue as well.

If you are going to reject it I would at least like an indication of WHY it
needs to be rejected.

E.g. it would break this or that as well as an brief explanation.

If no such argument can be made on how it will cause a problem with
existing implementations then then how can one argue against it especially
considering the security questions which I have given?

I at the very least expect the wording to changed to indicate explicitly
that the extension, csrc should also not be included in the count.

Lastly, what about the errata related to RFC2435 and RFC2326 which I have
submitted?

They have not been responded to, are they being looked into?

Sincerely,
Julius




On Mon, Dec 8, 2014 at 5:36 PM, Stephen Casner <[e-mail]> wrote:

> On Fri, 5 Dec 2014, Julius Friedman wrote:
>
> > Hello All.
> >
> > There is definitely some confusion related to the errata I submitted for
> > RFC3550.
>
> I believe the confusion is within your interpretation of the standard,
> not in our interpretation of your proposed errata.  Perhaps you would
> like RTP to have some functions that are different than those that
> were specified, but those do not constitute errata.
>
> > The RFC clearly states:
> >
> > sender's octet count: 32 bits
> >       The total number of payload octets (i.e., not including header or
> >       padding) transmitted in RTP data packets by the sender since
> >       starting transmission up until the time this SR packet was
> >       generated.  The count SHOULD be reset if the sender changes its
> >       SSRC identifier.  This field can be used to estimate the average
> >       payload data rate.
> >
> > Just because it CAN be used for an average does not mean it should.
>
> Let me clarify.  When we wrote that sentence, we were stating why this
> field was included.  It was included so that receivers would be able
> to know the sender's average payload data rate over various time
> intervals by taking the value of this field from two sender reports
> and dividing by the difference in time of the two sender reports.  The
> receiver might want to compare that result with the average of the
> data as received (perhaps with some losses).
>
> > Further it is the total number of octets in the payload besides the
> > header because the header is always 12 octets.
> >
> > Since csrc and extension octets are included then padding should be
> > also.
>
> The CSRC and extension octets part of the RTP header and the phrase
> "not including header" means that they would not be included in the
> sender's octet count.  What text in RFC 3550 led you to believe that
> the header is always just the first 12 octets and that therefore the
> CSRC and extension octets would be included in the sender's octet
> count?
>
> > Since rtcp also reflects the count with padding this is obviously
> > correct.
>
> I am not sure what you are referring to here.  In another email you
> said "Rtcp counters include this value anyway."  What RTCP counters
> include a count of padding bytes?  Perhaps you are referring to the
> fact that the legnth field in the RTCP header includes padding on the
> RTCP compound packet.  That is irrelevant to the question of whether
> the sender's octet count, which is a count of payload octets, should
> or should not include padding octets.
>
> > Any padding only packet would not change the counter for rtp and is
> > thus a security issue as well as a redundantly conveyed piece of
> > information because each packet contains the number of padding bytes
> > which can be accounted for in the implementation when required.
>
> I do not see a security issue.  Please explain how there would be an
> added security risk for an application that does send RTP data packets
> with padding compared to an application does does not send RTP data
> packets with padding, even if sometimes those applications send RTP
> data packets containing no payload data.
>
> The sender's octet count is an aggregate count of the payload octets
> over some number, often a large number, of RTP data packets.  If the
> receiver gets all of the data packets with no loss, then that same
> count could be calculated.  However, some packets may be lost.  RTP is
> designed to help implementations be tolerant of packet loss.
>
> > To account for padding when padding is not required and would be 0
> > is also contradictory.
>
> I don't understand this sentence.  The sender's octet count does not
> include padding octets, so for implementations that do not send
> padding the number of excluded padding octets is zero, but that does
> not form any contradiction.
>
> > Please read and re read the errata if required.
> >
> > Please advise.  ( intelligently )
>
> I suggest that careful reading and understanding of RFC 3550 is what
> is required here.
>
>                                                         -- Steve
>