Subject: [avtext] My comments on draft-ietf-avtext-rtp-stream-pause-06

From: Magnus Westerlund <[email-masked]>
Date: Fri, 20 Feb 2015 16:54:32 +0100

Hi,

This is one more case of me trying to catch up with what has happened to
my documents during by parental leave. The benefit is that I do read
them with less than usual home-blindness. I may also contradict previous
consensus agreements, in those case just tell me so.

Here are some comments on the draft:

1. Section 2.2:

   Feedback Messages:  CCM [RFC5104] categorized different RTCP feedback
      messages into four types, Request, Command, Indication and
      Notification.  This document places the PAUSE and RESUME messages
      into Request category, PAUSED as Indication and REFUSED as
      Notification.

      PAUSE  Request from an RTP stream receiver to pause a stream

      RESUME  Request from an RTP stream receiver to resume a paused
         stream

      PAUSED  Indication from an RTP stream sender that a stream is
         paused

      REFUSED  Indication from an RTP stream sender that a PAUSE or
         RESUME request will not be honored

I think there need to be some separator character between the message
name and the explanation. Maybe ":" is the simplest but I guess " - "
would also work.

There is also an inconsistency here about the usage of Indication vs
Notification that for PAUSE and REFUSED that needs to be addressed.

2. Section 5.4:

   There may be local considerations at the RTP stream sender, for
   example that the media device is not ready, making it temporarily
   impossible to resume the stream at that point in time, and the RTP
   stream sender MAY then respond with a REFUSED containing the same
   PauseID as in the RESUME.  When receiving such REFUSED with a PauseID
   identical to the one in the sent RESUME, RTP stream receivers SHOULD
   then avoid sending further RESUME requests for some reasonable amount
   of time, to allow the condition to clear.

I see a potential issue in this text regarding the case ones RESUME
request is refused. The participant sending the RESUME has clearly
indicated that it desires the media stream, given that it was available.
However, there is no recommendation here that the media sender actually
starts sending by making a local decision to resume if the reason for
refusing a resume is removed. That is however clearer in Section 6.4
that it is a local consideration. The requesting party being remote has
no or little insight into the reason and can thus not determine when it
really suitable to request a resume again.

I would propose that we add to this a recommendation for the media
sender that REFUSED a RESUME request to make a local decision to resume
upon it being able to resume again. I would propose to add the following
sentence to end of the above paragraph:

   A RTP stream sender having sent a REFUSED, is responsible to resume
   the media stream through local consideration upon the disappearance
   of the reason for sending that REFUSE.

3. Handling of TMMBR/TMMBN bounding set and who becomes the owner of the
limitations.

I think we have a potential issue with the handling of the bounding set
for TMMBR/TMMBN when one sets the maximum total-bitrate to 0. Looking at
the suggested algorithm (Section 3.5.4 in RFC 5104) for how to handle
this, I draw the conclusion that this bounding set will become a single
value. It will be the TMMBR value with the highest overhead value that
will survive in this matching among any with a bit-rate value of 0.

This will impact who becomes the owner (a single SSRC) and the handling
of Local Pause. Lets look at the passage which are impacted by this:

Section 5.2:

   There may be local considerations making it impossible or infeasible
   to pause the stream, and the RTP stream sender can then respond with
   a REFUSED.  In this case, if the used PauseID would otherwise have
   been effective, REFUSED contains the same PauseID as in the PAUSE
   request, and the PauseID is kept as available.  Note that when using
   TMMBR 0 as PAUSE, that request cannot be refused (TMMBN > 0) due to
   the existing restriction in section 4.2.2.2 of [RFC5104] that TMMBN
   shall contain the current bounding set, and the fact that a TMMBR 0
   will always be the most restrictive point in any bounding set.

This note is not completely correct and should be modify to clarify that
the bounding set will be a single point from a TMMBR 0 with the higher
measured average overhead.

Section 5.4:

   A pausing RTP stream sender can apply local considerations and MAY
   resume a paused RTP stream at any time.  If TMMBR 0 was used to pause
   the RTP stream, it cannot be resumed due to local considerations,
   unless the RTP stream is paused only due to local considerations
   (Section 5.3) and thus no RTP stream receiver has requested to pause
   the stream with TMMBR 0.

That last sentence is mostly right, with the exception of a loop-hole
that a local pause could become owner if and only if its measured
over-head is larger than what is currently in the bounding set. The
implication of applying this loop-hole is that the peer endpoint will
become unable to send any type of resume message, as the Media Sender
has become the owner of the restriction. But, this is a general
limitation of the TMMBR 0 usage of pausing.

Section 5.5:

   TMMBN 0:  Corresponds to PAUSED when the RTP stream was paused with
      TMMBR 0, but may, just as PAUSED, also be used unsolicited.  An
      unsolicited RTP stream pause based on local sender considerations
      uses the RTP stream's own SSRC as TMMBR restriction owner in the
      TMMBN message bounding set.  Also corresponds to a REFUSED
      indication when a stream is requested to be resumed with TMMBR >0.

I think there are two potential issues around this paragraph that needs
clarification. First, is the remote peer allowed to send a TMMBR 0 when
the TMMBN 0 with a bounding set owned by the media sender, when the
receiver has a Overhead value that is bigger than what is in the TMMBN 0
message?

Secondly, I think it should be further clarified that in the last case,
if one media sender refuses to Resume the media sending, it becomes the
owner of the TMMBR restriction by sending that TMMBN 0.

That clarification could be as simple as:

                                       Also corresponds to a REFUSED
      indication when a stream is requested to be resumed with TMMBR
      >0, thus resulting the stream sender becoming the owner of the
      bounding set in the TMMBN message.

Section 6.4:

   When using TMMBN 0 as PAUSED indication, being in paused state, and
   entering local paused state, the RTP stream sender SHALL send TMMBN 0
   with itself included in the TMMBN bounding set.

The SHALL as currently formulated is in conflict with RFC5104 in those
cases when the local limitation point is not the one selected by the
algorithm.

Based on the above, I think the most reasonable way forward is simply to
define the behaviour that is desirable and have this specification
update the TMMBR specification. I think the important thing is to avoid
enabling stealing of the bounding set by simple changing the overhead
parameter as this is completely meaningless when one declared the total
bandwidth as 0. Thus, allowing a peer SSRC that has paused to keep
owning the bounding set, and then if a RESUME (TMMBR >0) is to be
REFUSED have the media sender take over the limitation by sending a
TMMBN with itself as owner of the TMMBR 0 limitation.

4. Section 6.2:

   The hold-
   off period MAY be set to 0 by some signaling (Section 9) means when
   it can be determined that there is only a single receiver, for
   example in point-to-point or some unicast situations.

I think we should clarify what we really means with a "single receiver"
in this context. Are we talking about Endpoints or what defines a
receiver in this context. This becomes especially important in the next
paragraph:

   If the RTP stream sender has set the hold-off period to 0 and
   receives information that it was an incorrect decision and that there
   are in fact several receivers of the stream, for example by RTCP RR,
   it MUST change the hold-off to instead be based on the above formula.

How does the media sender determine that there is not only a single
receiver. Fortunately we have already had a bit of
private discussion around this with my co-authors for
draft-ietf-avtcore-rtp-multi-stream where we have the same issue when
addressing open issues in the -06. What we intended to propose is a
solution that is:

Only one CNAME in use among all SSRCs received (CSRC do not matter if
they have different CNAMES) unless reporting groups
(draft-ietf-avtcore-rtp-multi-stream-optimisation) is used, in which
case a single report group is what matters to determine that it is still
point to point, even in mixer or SFM middlebox cases. The report group
addition is to deal with cases of SFMs and multi-synchronization context
endpoints which are the cases that fails to be correctly classified when
using CNAME.

Thus, I suggest aligning the solutions here.

5. Section 6.3:

   When entering the state, the RTP stream sender SHALL send a PAUSED
   indication to all known RTP stream receivers, and SHALL also repeat
   PAUSED in the next two regular RTCP reports.

I think the later part of the sentence needs an escape clause for the
case when a RESUME request is received prior to having sent the two
regular RTCP reports, this due to the fact that this is a sentence with
a SHALL.

6. Section 6.3.2:
   Any
   streams that were paused by that removed participant SHALL be
   resumed.

I think a SSRC should be added or replace "participant" in the above
sentence.

7. Section 6.4:

   This state can be entered at any time, based on local decision from
   the RTP stream sender.  As for Paused State (Section 6.3), the RTP
   stream sender SHALL send a PAUSED indication to all known RTP stream
   receivers, when entering the state, and repeat it a sufficient number
   of times to reach a high probability that the message is correctly
   delivered, unless the stream was already in paused state
   (Section 6.3).

The exception of a RESUME prior to having concluded on the repetition of
the PAUSED Indication?

8. Section 6.4:

   When leaving the state, the stream state SHALL become Playing,
   regardless whether or not there were any RTP stream receivers that
   sent PAUSE for that stream, effectively clearing the RTP stream
   sender's memory for that stream.

I think it needs to be clarified what "leaving the state" means and who
is performing this leaving in this case. Yes, that is the media sender,
but its responsibility for doing this should be clarified. See issue 2,
so this does not become a dead lock situation.

9. Section 8.1:

   When an RTP stream sender in Playing State (Section 6.1) receives a
   valid PAUSE, and unless local considerations currently makes it
   impossible to pause the stream, it SHALL enter Pausing State
   (Section 6.2) when reaching an appropriate place to pause in the
   stream, and act accordingly.

I wonder why "when reaching an appropriate place to pause in the
stream," is relevant for moving to PAUSING state? It appears much more
relevant for having text along this line when entering "PAUSED" or
"Local PAUSED" as that is when media transmission ceases, and it is that
ceasing that should be done on media boundaries to avoid leaving
receivers hanging in repair or perform concealment.

10. Section 8.2:
   PAUSED SHALL contain a 32 bit parameter with the RTP extended highest
   sequence number valid when the RTP stream was paused.  Parameter Len
   MUST be set to 1.

I think "RTP extended highest sequence number" shall contain a reference
to Section 6.4.1 of RFC 3550.

In addition I wonder if it is so good to write like this: "Parameter Len
   MUST be set to 1." what about any future extension parameters?

11. Section 7:

I wonder if there should be some definitions that ensure that one can
extended the parameter space in the future. The reason I am raising this
is that if one like to extend for example PAUSED with an optional
information field, unless a clear definition of what a first gen
implementation does with unknown parameters this is going to be
impossible. Instead one will have to define new sub-message types which
the implementation doesn't know of.

I would also note that the specification is not clear on that a
implementation SHALL ignore FCIs with unknown types, that should be added.

12. Section 9.

   This specification follows
   all the rules defined in AVPF [RFC4585] and CCM [RFC5104] for an
   rtcp-fb attribute relating to payload type in a session description.

I think the relation between this being a general transport mechanism
and specific payload types might need a bit more discussion. From a
basic perspective one can in most case assume a general capability to
pause. Then there might be cases where the pausing of specific payload
types are more complex due to media boundary alignment requirements and
thus a differentiation in capabilities may arise.

13. Section 9:
      Note: When TMMBR 0 / TMMBN 0 are used to implement pause and
      resume functionality (with the restrictions described in this
      specification), signaling rtcp-fb attribute with ccm tmmbr
      parameter is sufficient and no further signaling is necessary.
      There is however no guarantee that TMMBR/TMMBN implementations
      pre-dating this specification work exactly as described here when
      used with a bitrate value of 0.

I was wondering if there is a point to define that if one signals both
"tmmbr" and "pause" one MUST be capable of handling pause functionality
where applicable using TMMBR 0?

14. Section 9:
   When signaling a config value other than 1, an implementation MAY
   ignore non-supported messages on reception, and MAY omit sending non-
   supported messages.

I wonder if the first "MAY" should be a "MUST" instead. I think it is
reasonable that implementation are cable of ignoring messages that they
declared they can't support. In multi-endpoint cases there might be some
sub-set that perform certain operations and others that do a fuller set,
when this do not collide.

15. Section 9, Figure 7:
   rtcp-fb-ccm-param  =/ SP "pause" [SP pause-attr]
   pause-attr         = [pause-config] [SP "nowait"] [SP byte-string]
   pause-config       = "config=" pause-config-value
   pause-config-value = %x31-38
   ; byte-string as defined in RFC 4566, for future extensions

I think there is an error in this specification. If one excludes the
"pause-config" then one ends up with "pause  nowait", i.e. two spaces
between the pause type and its other parameters.

I think the ABNF could be adjusted to read like this:

   rtcp-fb-ccm-param  =/ SP "pause" [pause-attr]
   pause-attr         = [SP pause-config] [SP "nowait"] [SP byte-string]
   pause-config       = "config=" pause-config-value
   pause-config-value = %x31-38 ; Config value 1-8
   ; byte-string as defined in RFC 4566, for future extensions

That would ensure that there is one and only one space between each
parameter. I also note that this definition ends up with a strict
ordering requirement.

Further I wonder if the "pause-config-value = %x31-38" would benefit
from being defined as pause-config-value = 1*2DIGIT instead? That way
future new values for the config could be added up to the full space of
0-99. Of course that also means that one needs to define what it means
to a receiver to see a config value it doesn't know of.

I also think there be missing specification what do with any unknown
(Future defined) parameters in a implementation according to this spec.

16. Section 9.1 and 9.2:

I am missing a discussion of the meaning of PAUSE and TMMBR methods when
both are present in a SDP.

17. Section 9.2:

   First, the "config" attribute and its message directions are
   interpreted based on the node receiving the SDP.

I am think this is missing words on what requirement levels it means to
have included a particular config value for the declarative usage. Is
that the RECOMMENDED operation configuration or is a mandated one and if
one doesn't support it one SHALL NOT join the session?

18. Section 10.2:

Figure 11 and Figure 12:

As the example include a PAUSE at t6, shouldn't the corresponding PAUSED
be included as it is a mandated response?

19. Section 10.4:

   A transport Translator in an RTP session forwards the message from
   one peer to all the others.

I think this text should use the word "Relay" for this type to make it
clearer in relation to the updated topologies draft.

20. Section 12:

   This document extends the CCM [RFC5104] and defines new messages,
   i.e.  PAUSE and RESUME.  The exchange of these new messages MAY have
   some security implications, which need to be addressed by the user.
   Following are some important implications,

   1.  Identity spoofing - An attacker can spoof him/herself as an
       authenticated user and can falsely pause or resume any source
       transmission.  In order to prevent this type of attack, a strong
       authentication and integrity protection mechanism is needed.

   2.  Denial of Service (DoS) - An attacker can falsely pause all
       source streams which MAY result in Denial of Service (DoS).  An
       Authentication protocol may prevent this attack.

   3.  Man-in-Middle Attack (MiMT) - The pausing and resuming of an RTP
       source is prone to a Man-in-Middle attack.  Public key
       authentication may be used to prevent MiMT.

I think this section needs some work.

In regards to 2. If we start on a none secured session, then anyone,
even off-path attackers can spoof PAUSE message. Thus, integrity
protection with at least group source authentication needs be used. I
think a pointer to 7201 is suitable here. That should be the starting
point.

This leads to the current 1. Which is in cases where only group
authentication, i.e. SRTP with symmetric crypto, then anyone in the
group can perform identity spoofing and claim to be another user. This
can be combated either using a stronger source authentication and in
case of middlebox based groups, the middlebox can police against
impersonations.

Thirdly, I don't understand the man-in-the-middle attack here. The only
addition on the two first points is the trust likely placed in the
middlebox. To avoid third parties to inject a middlebox the signalling
and security establishment needs to have sufficient security
functionalities to prevent modification and provide identities that can
be used in source authentication of any signalling messages.

My initial proposal for a new section is below.

12.  Security Considerations

   This document extends the CCM [RFC5104] and defines new messages,
   i.e.  PAUSE, RESUME, PAUSED and REFUSED.  The exchange of these new
   messages have some security implications, which need to be addressed
   by the user.

   The messages defined in this specification can have substantial
   impact on the perceived media quality if used in a malicious way.
   First of all is the risk for Denial of Service (DoS) on any RTP
   session that uses the PAUSE-RESUME functionality.  By injecting one
   or more PAUSE requests into the RTP Session an attacker can
   potentially prevent any media from flowing, especially when the hold-
   off period is zero.  The injection of PAUSE messages is quite simple,
   requiring knowledge of the SSRC and the PauseID.  Information visible
   to an on-path attacker unless RTCP messages are encrypted.  Even off-
   path attacks are possible as signalling messages often carry the SSRC
   value, while the 16-bit PauseID have to be guessed or tried.  The way
   of protecting the RTP session from these injections are perform
   source authentication combined with message integrity to prevent
   other than intended session participants from sending these messages.
   There exist several different choices for securing RTP sessions to
   prevent this type of attack.  SRTP is the the most common, but also
   other methods exists as discussed in "Options for Securing RTP
   Sessions" [RFC7201].

   Most of the methods for securing RTP however, does not provide source
   authentication of each individual participant in a multi-party use
   case.  In case one of the session participants are malicious they can
   wreck significant havoc within the RTP session and similarly cause a
   DoS on the RTP session from within.  That damage can also be
   attempted to be obfuscated by having the attacker impersonate other
   endpoints within the session.  These attacks can be mitigated by
   using a solution that provides true source authentication of all
   participant's RTCP packets.  However, that has other implications.
   For multi-party sessions which includes a middlebox, that middlebox
   is RECOMMENDED to perform checks on all forwarded RTCP packets so
   that each participant only uses its set of SSRCs, to prevent the
   attacker utilizing other participants SSRCs.

   The above text has been focused on using the PAUSE message as the
   tool for malicious impact on the RTP session.  That is because of the
   greater impact from denying users access to RTP media streams.  In
   contrast if an attacker attempts to use RESUME in a malicious purpose
   it will result in that the media streams are delivered.  However,
   such an attack basically prevents the use the Pause and Resume
   functionality.  Thus, potentially forcing a reduction of the media
   quality due to limitation in available resources, like bandwidth that
   must be shared.

   The session establishment signalling is also a potential venue of
   attack as that can be used to prevent the enabling of Pause and
   Resume functionality by modifying the signalling messages.  The above
   mitigation of attacks based on source authentication also requires
   the signalling system to securely handle identities and assert that
   only the intended identities are allowed into the RTP session and
   provided the relevant security contexts.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
FÃ¤rÃ¶gatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------