Subject: [avtext] draft-ietf-avtext-rid-05: A couple of issues

From: Magnus Westerlund <[email-masked]>
Date: Tue, 12 Jul 2016 16:29:55 +0200

Hi,

Doing a review across the whole RID+RID and Simulcast document I have 
some significant comment on draft-ietf-avtext-rid-05. I am sorry I 
missed WGLC for this document. So please consider this early IETF last 
call comments.

1. The definition of the RepairedRtpStreamId in Section 3 is not 
particular clear on the limitations this design have. As the SDES item 
can only contain a single RtpStreamId value the implication is that 
RepairedRtpStreamId can only be used when the redundancy mechanism has a 
one to one relation with a source RTP stream. This can't be used with 
redundancy mechanisms that protects multiple RTP streams. I think this 
could be made clearer in Section 3.

2. Section 4.4:

Extension URI: urn:ietf:params:rtp-hdrext:sdes:repair-rtp-sream-id

Why is this URI not "Extension URI: 
urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-sream-id"?

3. Section 3.3 and 5:

I think the privacy considerations in the security consideration needs 
to be strengthen.

Section 3.3:
    Implementors are warned, in particular, not to include any
    information in the identifier that is derived from potentially user-
    identifying information, such as user ID or IP address.  To avoid
    identification of specific implementations based on their pattern of
    tag generation, implementations are encouraged to use a simple scheme
    that starts with the ASCII digit "1", and increments by one for each
    subsequent identifier.

Section 5:
    The actual identifiers used for RtpStreamIds (and therefore
    RepairedRtpStreamIds) are expected to be opaque.  As such, they are
    not expected to contain information that would be sensitive, were it
    observed by third-parties.

I think my main criticism is how section 5 is formulated. I think it 
could start out in the risks, as an SDES items can carry any UTF-8 
string that is not to long. Therefore the generation of the string is 
important so that it does not contain any privacy sensitive information.

I will also note that this fails to discuss the importance of the labels 
being possible to trust. Otherwise replacing the labels have interesting 
effects in the applications.

I would suggest for Section 5:

--- Start of proposed text ---

The SDES items has the potential to carry any UTF-8 string. Therefore it 
exists a risk that it carries privacy sensitive information. 
Implementations needs to take care when generating identifiers so that 
they do not contains information that can identify the user or allow for 
long term tracking of the device. Following the generation 
recommendations in Section 3.3 will result in non instance specific 
labels, with only minor fingerprinting possibilities in the total number 
of used RtpStreamIds and RepairedRtpStreamIds.

Even if the SDES items are generated to be as information less as 
possible, it is RECOMMENDED that the SDES items are encrypted to 
preserve privacy against third parties. The means encryption of both 
RTCP as well as the RTP header extension part.

As the SDES items are used for identification of the RTP streams for 
different application purposes, it is important that the intended values 
are received. An attacker, either a third party or malicious RTP 
middlebox, that removes, or exchanges the values for these SDES items 
can severely impact the application. The impact can include failure to 
decode or display the media content of the RTP stream, it can also 
result in incorrectly attribute media content to identifiers of the 
media source, such as the wrongly label the speaker. To prevent this 
from occurring due to third party attacks, integrity and source 
authentication is needed.

Options for Securing RTP Sessions [RFC7201] discusses options for how 
the encryption, integrity and source authentication can be accomplished.

--- End of proposed text ---

4. Section 3:

    This specification defines two new RTCP SDES items [RFC3550].  The
    first item is 'RtpStreamId', which is used to carry RTP stream
    identifiers within RTCP SDES packets.  This makes it possible for a
    receiver to associate received RTP packets (identifying the RTP
    stream) with a media description having the format constraint
    specified.

The definition of the RtpStreamId is missing a discussion of 
requiremetns on the value.

mmusic-rid document in Section 4 is indicating through the following line:

  A given
    "rid-id" MUST NOT be repeated in a given media description ("m="
    section).

 From my perspective I do wonder if the definition in this document 
needs to makes this clear. And also possibly make it clear that there 
exist no requirement for it be unique across all RTP streams in the RTP 
session, something the name may imply. This clearly also indicates that 
if one have multiple media sources that can use the same RtpStreamIds 
then one needs some additional mechanism to identify them. Media sources 
from different endpoints can be seperated using SDES CNAME.

So the main issue appears to exist in cases where one endpoint sends 
multiple media sources in the same RTP session, such as when BUNDLE is 
used.

See my review of draft-ietf-mmusic-rid for additional aspects of this on 
the a=rid side.

5. Section 3.

I think adding a sentence that SDES items are UTF-8 and have a maximum 
length of 255 Octets, and with a warning that as many symbols encoded in 
UTF-8 have multi-octet representations, the limit to the number of 
symbols that fits may be much lower than 255.

This as RFC3550 is not super clear on this implication, even if the 
limitations are clear when it comes to SDES items having a max length of 
255 octets.

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: Adam Roach <[email-masked]>
Date: Thu, 14 Jul 2016 18:17:58 -0500

On 7/12/16 09:29, Magnus Westerlund wrote:
> RepairedRtpStreamId can only be used when the redundancy mechanism has 
> a one to one relation with a source RTP stream. This can't be used 
> with redundancy mechanisms that protects multiple RTP streams. I think 
> this could be made clearer in Section 3.

I'm not sure that's a limitation of the current design -- packet types 
are allowed to appear more than once, right? It seems that it would be 
reasonable to include more than one RepairedRtpStreamId SDES packet in a 
single compound packet, right? I agree that we need to say more about 
this, but the limitation you imply is necessary seems artificial.

I'm adding: "For those schemes in which a redundancy stream contains 
information used to repair more than one stream, multiple 
RepairedRtpStreamId SDES items may appear in a single compound packet. 
Due to the foregoing scoping rules, the RepairedRtpStreamId cannot be 
used to indicate streams in multiple sessions or with varying MIDs."

> urn:ietf:params:rtp-hdrext:sdes:repaired-rtp-sream-id"?

Jetlag. I've fixed it.

> ...
> The SDES items has the potential to carry any UTF-8 string. Therefore 
> it exists a risk that it carries privacy sensitive information. 
> they do not contains information that can identify the user or allow 
> for long term tracking of the device. Following the generation 
> labels, with only minor fingerprinting possibilities in the total 
> number of used RtpStreamIds and RepairedRtpStreamIds.
>
> different application purposes, it is important that the intended 
> values are received. An attacker, either a third party or malicious 
> RTP middlebox, that removes, or exchanges the values for these SDES 
> items can severely impact the application. The impact can include 
> failure to decode or display the media content of the RTP stream, it 
> can also result in incorrectly attribute media content to identifiers 
> of the media source, such as the wrongly label the speaker. To prevent 
> this from occurring due to third party attacks, integrity and source 

Excellent. Thanks for sending text. I'm editing it slightly and 
replacing the entire security section with it.

> exist no requirement for it be unique across all RTP streams in the 
> RTP session, something the name may imply. This clearly also indicates 
> that if one have multiple media sources that can use the same 
> RtpStreamIds then one needs some additional mechanism to identify 
> them. Media sources from different endpoints can be seperated using 
> SDES CNAME.

Yes, a discussion of scoping is certainly called for. I propose:

   RtpStreamId and RepairedRtpStreamId values are scoped by source 
identifier
   (e.g., CNAME) and by media session. When the media is multiplexed
   using the BUNDLE extension {{I-D.ietf-mmusic-sdp-bundle-negotiation}},
   these values are further scoped by their associated MID values.
   For example: an RtpStreamId of "1" may be present in the stream
   identified with a CNAME of "[email-masked]", and may also be
   present in a stream with a CNAME of "[email-masked]", and these
   would refer to different streams. Similarly, an RtpStreamId of "1"
   may be present with an MID of "A", and again with a MID of "B",
   and also refer to two different streams.

> length of 255 Octets, and with a warning that as many symbols encoded 
> in UTF-8 have multi-octet representations, the limit to the number of 

I would think that "make them as small as possible" and "use this 
approach that keeps them one character long" should be sufficient, but 
I'll add text just to be triple-sure.

   As with all SDES items, RtpStreamId and RepairedRtpStreamId are limited
   to a total of 255 octets in length. Since the values of these items
   are encoded with UTF-8, the use of multi-octet characters will result
   in limitations smaller than 255 characters. It is in implementations'
   interests to keep these values as small as possible in any case, so
   this limitation is not expected to have any significant impact.

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 19 Jul 2016 15:33:07 +0200

> this, but the limitation you imply is necessary seems artificial.

I agree that this may not be really clear in RFC 3550, but use of 
multiple SDES items of the same type within a session is likely very 
error prone. Such usage would require an RTP extension, that is straight 
forward, but should not be attempted without prior agreement.

> used to indicate streams in multiple sessions or with varying MIDs."

I am really worried about adding this to this document.

>   and also refer to two different streams.

Yes, I think this works. My one comment is to call "CNAME" for source 
identifier. With MID it is clearly the media source, but otherwise CNAME 
= Canonical End-Point Identifier, so it identifies the endpoint only. 
When I read it as currently formulated, it reads like Source IDentity = 
CNAME. That I find problematic.

>   this limitation is not expected to have any significant impact.

Yes, works for me.

Cheers

Magnus Westerlund

---

From: Adam Roach <[email-masked]>
Date: Fri, 29 Jul 2016 16:19:30 -0500

> I am really worried about adding this to this document. 

Okay, so let's not support it and simply document that restriction.

"Note that the RepairedRtpStreamId mechanism is limited to indicating 
one repaired stream per redundancy stream. If systems require 
correlation for schemes in which a redundancy stream contains 
information used to repair more than one stream, they will have to use a 
more complex mechanism than the one defined in this specification."

/a