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

From: Bo Burman <[email-masked]>
Date: Tue, 3 Mar 2015 12:01:31 +0000

Thank you for this thorough review!
Please find my responses inline.

Note that I specifically would like others to comment on a few of Magnus' items:

- Item 3: How much elaborative text on TMMBR/TMMBN bounding set overhead value considerations do we want to add into section 5.2 (see my response to that item 3 below to get the context)?

- Item 13: Is there a point to define that if both "ccm tmmbr" and "ccm pause" is included in the SDP, the part sending that SDP MUST be capable of handling corresponding pause functionality using TMMBR/TMMBN 0, as defined in this specification?

Cheers,
Bo

> -----Original Message-----
> From: Magnus Westerlund
> Sent: den 20 februari 2015 16:55
> To: [email-masked]
> Cc: Bo Burman; Roni Even
> Subject: My comments on draft-ietf-avtext-rtp-stream-pause-06
> 
> 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.
[BoB] OK

> 
> There is also an inconsistency here about the usage of Indication vs Notification that for PAUSE and REFUSED that needs
> to be addressed.
[BoB] REFUSED should be a Notification, so this is a typo. OK. Should be corrected throughout the document, if there are more places using indication.

> 
> 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.
[BoB] What about
"An RTP stream sender having sent a REFUSED SHOULD resume the stream
through local considerations (see below) when the condition that caused the
REFUSED is no longer true."?

The "see below" is meant to refer to the text two clauses further down, stating
"A pausing RTP stream sender can apply local considerations and MAY resume a
paused RTP stream at any time".

> 
> 
> 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.
[BoB] While I agree that the current text does not mention overhead, I think that the text _is_ in fact strictly correct, because _a_ TMMBR 0 _will_ be the most restrictive point in any bounding set, regardless of its overhead value, and cannot be refused with any TMMBN >0. One TMMBR {0, overhead1} could in principle be "refused" with a TMMBN {0, overhead2} if overhead2 > overhead1 from an RFC 5104 perspective, but I so far thought that detail need not be considered in this specification. I may be wrong here.

Note that TMMBN 0 (regardless of overhead) is defined to correspond to a PAUSED, so a PAUSE through TMMBR 0 can in principle never be refused (cause a TMMBN >0), even if a specific TMMBR 0 may not actually enter the bounding set. Even if the returned TMMBN 0 has a different overhead value, it is still a PAUSED and thus a "successful outcome" of the TMMBR 0 (PAUSE), and confirms that the stream is already paused from the perspective of this specification.

What can actually happen when TMMBR/TMMBN is used and when local and remote have different overhead values, is the party having the larger overhead "takes over" the bounding set when combining a PAUSE request with local paused state. This can in turn impact who can lift the restriction and resume, and I believe that requires a discussion.

The cases where a local party A has larger overhead than a remote party B already work as specified in Section 6.4:

* When A is already paused by B, and A decides to go into local pause, A can (as mandated by 6.4) send a (new) TMMBN (PAUSED) with itself in the bounding set, meaning that A even from a TMMBR/TMMBN perspective is allowed to decide when to leave local paused state.

* When A is in local pause and receives a TMMBR 0 (PAUSE) from B, the received TMMBR 0 is less restrictive and will be ignored, just as a PAUSE would be ignored while already in paused or local paused state.

* When A is in local pause and decides to resume it can do that based on a local decision, since it is in the bounding set and just as described for local paused state in this specification.

The cases where a local party A has less overhead than a remote party B do not work as currently specified in Section 6.4, taking the TMMBR/TMMBN overhead rule into account:

* When A is already paused by B, and A decides to go into local pause, A formally cannot send any new TMMBN 0 with itself owning the bounding set, due to the overhead rules you point out.

* When A is in local pause and receives a TMMBR 0 from B, the new TMMBR will replace the one from local pause, B effectively taking over ownership of the bounding set; as seen from this specification it can still be in local pause, although a TMMBN will not be able to explicitly indicate this because the media senders SSRC is not in the bounding set, but that is in any case specific to TMMBR/TMMBN usage and while it should be mentioned in the text, it does not break anything

* When A is in local pause, and has received a TMMBR 0 from a B that has larger overhead, as above, and when B lifts that restriction with a TMMBR 0 (RESUME), but A cannot resume at this time due to continued local considerations, it can stay in local paused state and simply send a new TMMBN 0 with itself in the bounding set.

* When A is in local pause and wishes to resume it cannot do that simply on a local decision since the restriction is owned by B, which is a deviation from what is currently specified; suggest describing this case as specific to the use of TMMBR/TMMBN. Specifically, the state machine described at the beginning of Section 6 is not really correct for use in TMMBR/TMMBN, since a TMMBR 0 (PAUSE) can effectively take a media sender from Local Paused to Paused state. In terms of media flows, this has very minor impact.

For the cases where local party A has same overhead as remote party B, and from re-reading the algorithm in RFC 5104, which party is chosen to be included in the bounding set is either random or implementation-specific. In any case, the situation formally depends on who paused:

* If A decides to go to local pause, it will own the bounding set, B cannot "take over" by sending a TMMBR, and it will be the same as when A has the larger overhead above.

* If B pauses A, and A later decides to go to local pause, it cannot effectively go to (or rather, signal) local paused state, because B owns the bounding set and the situation is the same as when B has the larger overhead above.

How much of the above elaborative text and clarifications do we need in the draft text?

> 
> 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.
[BoB] Agree that this is a general limitation of TMMBR 0 usage. However, I don't think that the peer is _unable_ to send TMMBR >0 (RESUME) and it is not in any way forbidden to send it; the media sender can still see this message, but it will not be effective. The media sender can resume whenever the situation that caused the local paused state clears, which is entirely in line with how local paused state is currently described.

> 
> 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?
[BoB] Yes, of course, and fully in line with RFC 5104, but it is not really clear to me what reason the remote peer would have to send a TMMBR 0 when it is already pausing (sending TMMBN 0). That will, as elaborated above, make the remote peer become owner of the bounding set and will prohibit the media sender from going out of local paused state.

> 
> 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.
[BoB] Agreed. Just as stated in my long text above.

> 
> 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.
[BoB] OK, with an "in" after "resulting". :)

> 
> 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.
[BoB] Yes, when taking overhead into account that becomes the conclusion, and I think we should follow RFC5104.

> 
> 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.
[BoB] Agreed. This is conformant to RFC5014. I will try to find some good text for it in the next version. See also my question above on how much clarifying text we want to add.

> 
> 
> 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.
[BoB] Agree. This sounds like a good approach and very reasonable!

> 
> 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.
[BoB] If it receives a RESUME it is no longer in the described state, but I can add clarifying text for that.

> 
> 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.
[BoB] OK, suggest SSRC is added.

> 
> 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?
[BoB] OK. As a similar comment above, then it is no longer in that state, but I can add clarifying text.

> 
> 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.
[BoB] OK. The intent is that since local paused state is entered based on local considerations, the state can similarly only be left through local consideration, and it is thus a local decision in the media sender. I can add some text that the state SHOULD be left (becoming Playing) as soon as the condition that caused the local pause clears. That way, the text will not be dependent on what the remote peer(s) sent during the local pause, or require that the local peer remembers how many of the remote peers that (ineffectively) tried to PAUSE or RESUME while in local pause. The exception to that is when using TMMBR/TMMBN and when the remote peer sent a TMMBR 0 with a higher overhead value than the local peer has, in which case the local party cannot (formally) exit the paused state until remote sends a TMMBR >0. Would that address your concerns?

> 
> 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.
[BoB] Reasonable. OK.

> 
> 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.
[BoB] OK.

> 
> 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?
[BoB] OK. I can re-formulate to allow for extensions, especially since we already have hooks for such in the document.

> 
> 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 an implementation SHALL ignore FCIs with unknown types, that
> should be added.
[BoB] OK.

> 
> 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.
[BoB] Seems reasonable. Would you consider suggesting some text?

> 
> 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?
[BoB] Sounds reasonable to me. What do others think?

> 
> 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.
[BoB] Agree. OK.

> 
> 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.
[BoB] OK. AFAIK we did not intend any ordering requirement by design, but I also don't think an ordering requirement does any harm to the current text. Could maybe an ordering requirement make it difficult to add extensions in the future?

> 
> 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.
[BoB] Receive unknown config value: MUST remove the pause line in the answer (not use pause at all)?

Do we also need to restrict the sender in an extensible way, like "Implementations of this specification MUST NOT use any other config value than the ones defined here"? Do you also need to say "but implementations of updates to this specification MAY use other values" to allow for extensibility?

> 
> I also think there be missing specification what do with any unknown (Future defined) parameters in a implementation
> according to this spec.
[BoB] Yes. Suggest MUST ignore and exclude from answer.

> 
> 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.
[BoB] Agree that this is missing. Suggest that if both are accepted in the SDP answer, TMMBR/TMMBN MUST NOT be used for pause/resume purposes (with a bitrate value of 0), to avoid signaling ambiguity.

> 
> 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?
[BoB] Agree that some text should be added. It is a RECOMMENDED operation configuration.

Nothing will break in such session if streams (from the joining client not supporting PAUSE) are not paused when requested, since pause/resume is a bandwidth optimization.

If a joining client does not support RESUME, it will not be able to prevent streams from being paused, or receive paused streams until someone else resumes them, but such restricted client will also not impact the rest of the session in any negative way.

> 
> 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?
[BoB] Yes. Will add it.

> 
> 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.
[BoB] OK

> 
> 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.
[BoB] I think this text is significantly better than the previous one. Will add into next version.

> 
> 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]
> ----------------------------------------------------------------------
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 5 Mar 2015 13:57:11 +0100

WG,

Here is my text proposal for issue 12.

> [BoB] Seems reasonable. Would you consider suggesting some text?
Here is my proposal to add before the last paragraph in Section 9.

   The pause functionality can normally be expected to work independent
   of the payload type.  However, there might exist situations where an
   endpoint likes to restrict or at least differently configure the
   capabilities depending on the payload type carrying the media stream.
   Reasons for this might relate to capabilities to correctly handle
   media boundaries and avoid any pause or resume operation to occur
   where it would leave an receiver or decoder with no choice than to
   attempt to repair or discard the media received just prior or at the
   point of resuming.

Cheers

Magnus Westerlund

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 5 Mar 2015 15:34:35 +0100

Hi,

This email is all about issue 13.

> [BoB] Sounds reasonable to me. What do others think?

Having looked at this again, I am actually coming to the conclusion that
there is no real value in doing what is proposed above. The reason is
that it doesn't resolve the ambiguities around using TMMBR for pause.

So in an O/A context an offer with both TMMBR and PAUSE will give the
answerer the information that Offerer do support pause using TMMBR.
However, we are mandating that if the answerer is capable of supporting
CCM PAUSE it shall use its functionality, not TMMBR. Thus, if the
answerer supports pause, this information is not used. If the answerer
refuses PAUSE, then the offerer is in an information vacuum about the
intentions of the answerer in regards to pause functionality.

Therefore I suggest that we drop the above idea and makes no
modifications in regards to the issue.

Cheers

Magnus Westerlund