Subject: [MMUSIC] BUNDLE - MID Security - Updated text proposal

From: Magnus Westerlund <[email-masked]>
Date: Wed, 2 Nov 2016 10:36:33 +0100

Hi,

I didn't receive any feedback. Below you will find a further updated 
text proposal attempting to be non-controversial. If you find the below 
erroneous or problematic, I do need you to speak up, because then I 
don't understand your issue:

---- Text Proposal ----

The identfication-tag when included in the RTP MID SDES item, 
independent of transport, RTCP SDES packet or RTP header extension, can 
expose the value to parties beyond the signaling chain. Therefore, the 
identification-tag MUST NOT contain any user related information for 
privacy reasons, nor hardware based identifiers. That as such 
information could enable tracking of the sending end point.

The identification-tag is used to route the media stream to the right 
application functionality, thus is important that the value received is 
the one intended by the sender. Malicious modifications can result in 
that a media stream is wrongly attributed or fails to be played. Thus, 
verifying integrity and the authenticity of the source are RECOMMENDED 
to prevent these attacks on the application. Security mechanisms for 
RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201].

---- End of Text Proposal ----

There has been discussion if the MID identification-tag should have a 
proposed or mandated construction pattern. I think there are benefits to 
that. Using the same ASCII based pattern that RID suggest is fine, 
however I think it can clarify which character in the range above dec 48 
("0") in the ASCII table should be used, and if one have more tags than 
what fits a single character, what one would do in that case.

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: Cullen Jennings <[email-masked]>
Date: Wed, 2 Nov 2016 13:11:20 -0600

Yes that seems like a good path. I'd also like to give any reasonable advice we can on creating MIDs such that they meet that goal.  Is there any reason not to just make MID a 16 bit integer ? same for RID ?

> On Nov 2, 2016, at 3:36 AM, Magnus Westerlund <[email-masked]> wrote:
> 
> Hi,
> 
> I didn't receive any feedback. Below you will find a further updated text proposal attempting to be non-controversial. If you find the below erroneous or problematic, I do need you to speak up, because then I don't understand your issue:
> 
> 
> ---- Text Proposal ----
> 
> The identfication-tag when included in the RTP MID SDES item, independent of transport, RTCP SDES packet or RTP header extension, can expose the value to parties beyond the signaling chain. Therefore, the identification-tag MUST NOT contain any user related information for privacy reasons, nor hardware based identifiers. That as such information could enable tracking of the sending end point.
> 
> The identification-tag is used to route the media stream to the right application functionality, thus is important that the value received is the one intended by the sender. Malicious modifications can result in that a media stream is wrongly attributed or fails to be played. Thus, verifying integrity and the authenticity of the source are RECOMMENDED to prevent these attacks on the application. Security mechanisms for RTP/RTCP are discussed in Options for Securing RTP Sessions [RFC7201].
> 
> There has been discussion if the MID identification-tag should have a proposed or mandated construction pattern. I think there are benefits to that. Using the same ASCII based pattern that RID suggest is fine, however I think it can clarify which character in the range above dec 48 ("0") in the ASCII table should be used, and if one have more tags than what fits a single character, what one would do in that case.
> 
> Cheers
> 
> Magnus Westerlund
>

---

From: Adam Roach <[email-masked]>
Date: Wed, 2 Nov 2016 15:07:45 -0500

On 11/2/16 14:11, Cullen Jennings wrote:
> I'd also like to give any reasonable advice we can on creating MIDs such that they meet that goal.  Is there any reason not to just make MID a 16 bit integer ? same for RID ?

draft-ietf-avtext-rid is in the RFC editors' queue. We *might* be able 
to pull off minor editorial changes. As far as I understand things, 
changing the format of a field would require us to pull it back and put 
it through IETF LC and IESG review again.

In terms of the actual proposed change ("16 bit integer"), SDES is 
defined to be a UTF-8 string. Unless we want to define a whole other 
thing instead of using SDES, these identifiers have to be valid UTF-8.

/a

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 3 Nov 2016 14:52:56 +0100

Den 2016-11-02 kl. 21:07, skrev Adam Roach:
>> I'd also like to give any reasonable advice we can on creating MIDs
>> such that they meet that goal.  Is there any reason not to just make
>> MID a 16 bit integer ? same for RID ?
>
>

I agree with Adam here that going to something that isn't UTF-8 makes it 
more difficult. It will not match the standard SDES format. I think it 
is desirable that we can have a single character and single byte in most 
cases, while still allowing for multiple ones in cases where there are 
many MIDs or RIDs. But basically if one uses 0-9, a-z, A-Z, and then 
goes to 00, 01, .. 0a, etc, then one can with two characters 62^2 = 3844 
possible ids, and the scheme should not be restricted to just two if 
actually needed. The SDES has an upper limit of 255 bytes.

Cheers

Magnus Westerlund

---

From: Ted Hardie <[email-masked]>
Date: Thu, 3 Nov 2016 09:36:03 -0700

On Thu, Nov 3, 2016 at 6:52 AM, Magnus Westerlund <
[email-masked]> wrote:

> more difficult. It will not match the standard SDES format. I think it is
> desirable that we can have a single character and single byte in most
> cases, while still allowing for multiple ones in cases where there are many
> MIDs or RIDs. But basically if one uses 0-9, a-z, A-Z, and then goes to 00,
> 01, .. 0a, etc, then one can with two characters 62^2 = 3844 possible ids,
> and the scheme should not be restricted to just two if actually needed. The
> SDES has an upper limit of 255 bytes.
>
>
Okay, so I was going to suggest we leave RID alone and have an optional
suggestion that MID be a 16 bit integer, represented as an SDES-compatible
UTF-8 string (that should be 5 octets maximum).  Someone interested in code
re-use could always use that with RID as well, even though the RID document
doesn't have the same suggestion.  While this would be optional advice,
you're concerned that someone taking it would consume 10 of the  255
available octets?

regards,

Ted

> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 4 Nov 2016 16:17:58 +0100

Den 2016-11-03 kl. 17:36, skrev Ted Hardie:
> On Thu, Nov 3, 2016 at 6:52 AM, Magnus Westerlund
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
>     I agree with Adam here that going to something that isn't UTF-8
>     makes it more difficult. It will not match the standard SDES format.
>     I think it is desirable that we can have a single character and
>     single byte in most cases, while still allowing for multiple ones in
>     cases where there are many MIDs or RIDs. But basically if one uses
>     0-9, a-z, A-Z, and then goes to 00, 01, .. 0a, etc, then one can
>     with two characters 62^2 = 3844 possible ids, and the scheme should
>     not be restricted to just two if actually needed. The SDES has an
>     upper limit of 255 bytes.
>
>
> suggestion that MID be a 16 bit integer, represented as an
> SDES-compatible UTF-8 string (that should be 5 octets maximum).  Someone
> interested in code re-use could always use that with RID as well, even
> though the RID document doesn't have the same suggestion.  While this
> would be optional advice, you're concerned that someone taking it would
> consume 10 of the  255 available octets?
>

As RTP header extensions are added in some potentially quite a lot of 
RTP packets and they take away from the available codec payload MTU, we 
consume quite a lot of space. For allowing rapid start performance for 
an RTP stream that hasn't been sent before, and the signalling answer 
hasn't made it yet, one need to include CNAME, MID, and RID in the RTP 
header extension. Assuming the MID and RID SDES items are 5 bytes each, 
that would drive the full RTP header extension to become:

4 bytes Header Extension common header
1 byte HE Item header
16 bytes CNAME data
1 byte HE item header
5 bytes MID data
1 byte HE item header
5 bytes RID data
3 bytes padding (for 32 bit-word alignment)
Total: 36 bytes

Compare this with 1 byte MID and RID:

4 bytes Header Extension common header
1 byte HE Item header
16 bytes CNAME data
1 byte HE item header
1 bytes MID data
1 byte HE item header
1 bytes RID data
3 bytes padding (for 32 bit-word alignment)

Total: 28 bytes

So in this case it ended up being just the 8 extra bytes the format.
Also without the CNAME, it is just 8 bytes difference, but then the 
total sizes are 16 vs 8 bytes.

Looking at this from where it does matter. As soon as one have more than 
9 media descriptions (m=) then one adds 4 bytes to the size of the 
Header Extension when using an integer scheme. Using a enumeration with 
like 0-9, a-z and A-Z then that break point happens after 62 media 
descriptions. Looking at today's cases, the first is likely, the second 
much less so.

I also don't quite see that enumerating using digits and a-z is 
particular difficult. It may require some few more sentence in the 
description, but not particular lot of code. Writing a m= line index to 
mid ID converter is very small function. And it is just the generation 
side that needs to care. After that they are just opaque identifiers.

And this would save both bytes on the wire and MTU.

Cheers

Magnus Westerlund