RTP Retransmission Payload Format
draft-ietf-avt-rtp-retransmission-12

[Note]: 'proto shepherd: colin perkins (csp@csperkins.org)
Need to check on Discusses - DLNA requests approval by 12 Oct.  The
rev was given to the ADs (not published) Aug 22, then submitted Sep 15
with another request for re-review.  (Before Aug: some discussion of the issues).' added by Allison Mankin

[Note]: 'proto shepherd: colin perkins (csp@csperkins.org)
Need to check on Discusses - DLNA requests approval by 12 Oct - rev with
fixes was presented (pre-pub) 22 Aug, then published 15 Sep. ' added by Allison Mankin

The authors agreed to make significant changes to the Security Considerations.  I leave it to the Proto Shepherd and the Shepherd AD to ensure that these words appear in the approved document.  Thay are:

"12. Security considerations

RTP packets using the payload format defined in this specification are subject to the general security considerations discussed in RTP, Section 9.

In common streaming scenarios message authentication, data integrity, replay protection and confidentiality are desired. The absence of authentication may enable man-in-the-middle and replay attacks, which can be very harmful for RTP retransmission. For example: tampered RTCP packets may trigger inappropriate retransmissions that effectively reduce the actual bitrate share allocated to the original data stream, tampered RTP retransmission packets could cause the client's decoder to crash, tampered retransmission requests may invalidate the SSRC association mechanism described in Section 5 of this document. On the other hand, replayed packets could lead to false re-ordering and RTT measurements (required for the retransmission request strategy) and may cause the receiver buffer to overflow. Further, in order to ensure confidentiality of the data, the original payload data needs to be encrypted. There is actually no need to encrypt the 2-byte retransmission payload header since it does not provide any hints about the data content.

Furthermore, it is RECOMMENDED that the cryptography mechanisms used for this payload format provide protection against known plaintext attacks. RTP recommends that the initial RTP timestamp SHOULD be random to secure the stream against known plaintext attacks. This payload format does not follow this recommendation as the initial timestamp will be the media timestamp of the first retransmitted packet. However, since the initial timestamp of the original stream is itself random, if the original stream is encrypted, the first retransmitted packet timestamp would also be random to an attacker. Therefore, confidentiality would not be compromised.

If cryptography is used to provide security services on the original stream, then the same services, with equivalent cryptographic strength, MUST be provided on the retransmission stream.  The use of the same key for the retransmitted stream and the original stream may lead to security problems, e. g., two-time pads.  Refer to Section 9.1 of the Secure Real-Time Transport Protocol (SRTP)[12] for a discussion the implications of two-time pads and how to avoid them.

At the time of writing this document, SRTP does not provide all the security services mentioned. There are, at least, two reasons for this: 1) the ocurrence of two-time pads and 2) the fact that this payload format typically works under the RTP/AVPF profile while SRTP only supports RTP/AVP.  An adapted variant of SRTP shall solve these shortcomings in the future.

Congestion control considerations with the use of retransmission are dealt with in Section 7 of this document."

[Ballot discuss]
I'm a bit concerned about Section 7, and the whole story regarding congestion control here.

In the first place, we do not make a practice of passing Proposed Standard congestion control systems which lack sufficient implementation experience. It is more common for such mechanisms to spend considerable time as Experimental RFCs before we consider them for PS. Is there any reason why this document is not going to Experimental now?

The sorts of statements made in Section 7 seem to provide just cause for caution. The entire section is scoped to a SHOULD, and offers no guidance as to when or why this SHOULD might not apply. The same applies to the other SHOULDs sprinkled through the ensuing paragraphs - if the authors envision a condition like the following:

  If the packet loss rate exceeds an
  acceptable level, it SHOULD be concluded that congestion is not
  kept under control and retransmission SHOULD NOT then be used.

... i.e., in which implementations merely SHOULD NOT ignore evidence of increasing packet loss due to the use of this mechanism, then this specification would be the right place to raise counterexamples; otherwise these normative statements ought to be MUSTs.

The second paragraph of Section 7 seems to allude to the congestion control guidance in Section 2 of RFC3551, and the remainder of the section uses this guidance as a yardstick. However, this document offers no concrete advice to implementers on how an application might determine if packet loss is within acceptable limits as those guidelines suggest.

[Ballot discuss]
The introduction says:
  >
  > At this point, the attention of the reader is called to the fact
  > that the retransmission mechanism for RTP described in this
  > document may be encumbered by patent applications filed from
  > Panasonic.  Please refer to the IPR Notices section for details.
  >
  Thanks for the warning, but we should not name Panasonic here.
  The first sentence could end after "patent applications."
  Alternatively, the whole paragraph could be deleted.

  Sections 8.2, 8.3, 8.4, and 8.5 include change controller
  items.  They indicate that change control is with the AVT WG.
  I assume that the AVT WG will shut down at some point.  I think
  this should indicate that IETF standards action is needed to
  make a change.

  The first paragraph of the security considerations says:
  >
  > If cryptography is used to provide security services on the
  > original stream, then the same services, with equivalent
  > cryptographic strength, MUST be provided on the retransmission
  > stream.  Old keys will likely need to be cached so that when the
  > keys change for the original stream, the old key is used until it
  > is determined that the key has changed on the retransmission
  > packets as well.
  >
  > The use of the same key for the retransmitted stream and the
  > original stream may lead to security problems, e.g. two-time pads. 
  > This sharing has to be evaluated towards the chosen security
  > protocol and security algorithms.
  >
  I like the first sentence of the first paragraph very much.  However,
  the second sentence implies that the same keying material might be
  used to encrypt the retransmission, even though it is being sent on a
  separate stream.  The second paragraph points to the possible security
  flaw if this is done.  Since a SRTP-variant is the security protocol
  that would be used in this context and SRTP is almost always used with
  counter mode, the result could be a loss of confidentiality.  If the
  same keying material is used, then a mechanism is needed to ensure
  that the counter value will be different.  SRTP seems to be prepared
  to support this situation, but not without some guidance.  RFC 3711
  says:
  >
  > In addition, there can be cases (see Sections 8 and 9.1) where
  > several SRTP streams within a given RTP session, identified by their
  > synchronization source (SSRCs, which is part of the RTP header),
  > share most of the crypto context parameters (including possibly
  > master and session keys).  In such cases, just as in the normal
  > SRTP/SRTCP parameter sharing above, separate replay lists and packet
  > counters for each stream (SSRC) MUST still be maintained.

[Ballot discuss]
Well-written overall, though I have a few issues:

6.3 Retransmission requests

>    The receiver should not send a retransmission request as soon as
>    it detects a missing sequence number but should add some extra
>    delay to compensate for packet reordering.  This extra delay may,
>    for example, be based on past observations of the experienced
>    packet reordering.

If packet reordering is determined to be extremely rare (e.g., essentially never - perhaps due to the underlying datalink preventing misordering) then the optimum delay here could in fact be zero except in the rarest of cases. I'm afraid that an implementor might take this too literally and always include some minimum delay, inhibiting performance for no good reason. Perhaps it should be pointed out that "some delay" may in fact be zero in some cases.

Also, the best "possible reorder delay" algorithm may not actually be time based, but packet based. e.g., if n number of packets are received after a gap is detected, then assume that the packet was truly lost rather than out of order (something, incidentally, which may be far easier to code on some platforms as a very short fixed FIFO packet buffer rather than via a timer-based mechanism).

>    To increase the robustness to the loss of a NACK or of a
>    retransmission packet, a receiver may send a new NACK for the same
>    packet.  This is referred to as multiple retransmissions.  Before
>    sending a new NACK for a missing packet, the receiver should rely
>    on a timer to be reasonably sure that the previous retransmission
>    attempt has failed in order to avoid unnecessary retransmissions.

Simply stating "should rely on a timer" doesn't really give the implementor much to go on as to what interval the timer should be set to. Earlier in this section, calculation of an RTT was referenced. Perhaps this RTT should be used as part of the algorithm for when one might send a multiple retransmission NACK request? From this text alone, it isn't obvious what to base this timer on, what the default value might be, whether it should be adaptive, etc.

Page 13, Section 7, Congestion control.

>    In addition, the sender MAY selectively retransmit only the
>    packets that it deems important and ignore NACK messages for other
>    packets in order to limit the bitrate. 

I think this could end up creating a situation where one side asks for a packet repeatedly (multiple retransmission NACKs), and the other side ignores the request repeatedly (not sending due to selective retransmission)? Is this considered a reasonable and expected behavior of the protocol?

>    the one the RTP flow achieves.  If the packet loss rate exceeds an
>    acceptable level, it SHOULD be concluded that congestion is not
>    kept under control and retransmission SHOULD NOT then be used.  It

What is "an acceptable level"?

What I am afraid of in a few cases here is that if someone is handed this document code from without a reference implementation to go by, some of the lack of details in these sections would end up in: (1) several questions posted to a list asking for help, (2) a lot of guesses made, or (3) an unusable number of configuration commands to tweak each and every possible parameter.

[Ballot discuss]
Please add an RFC Editor note to update the MIME-type change controllers to include "as designated by the IESG".

What exactly is the CNAME described in section 5.2 et al.?  I don't see a definition or a reference; are we talking about a DNS CNAME?

This is in AD evaluation, in that I'm looking at it after Publication Requested, but the Chairs have informed me that  it will go through a rev because of IPR and other WG issues.  This rev is not based on any AD evaluation.

[Note]: 'This is in AD evaluation, in that I''m looking at it after Publication Requested, but the Chairs have informed me that  it will go through a rev because of IPR and other WG issues.
This rev is not based on any AD evaluation.' added by Allison Mankin

Magnus Westerlund wrote:

Also the "RTP Retransmission Payload Format"
(draft-ietf-avt-rtp-retransmission-09.txt) is on the 3GPP dependencies
list, it has in the current list a lower priority, however it will soon
be updated to show its higher desirability by 3GPP. 3GPP SA4 decided
last week to take the usage of this draft as a working assumption.

Please note that there is no need to progress the current draft version,
as we due to IPR issue discussions will need to submit an update to the
current version (09) to address these. We will notify you when the new
version is available.