Subject: Re: [MMUSIC] Finding a max length of "a=mid" attribute

From: Harald Alvestrand <[email-masked]>
Date: Thu, 11 Nov 2021 13:00:05 +0100

Since no conclusion was reached on this thread, and we had to do 
*something* (crashing is not user friendly), we've decided that Chrome 
will reject with an error all SDP that contains a MID longer than 16 bytes.

Thanks to Philip Hancke for actually submitting the fix!

Harald

On 3/8/21 8:18 AM, Harald Alvestrand wrote:
>
> Please note - we *know* that no 17-byte MID is being used with WebRTC 
> in Chrome today, because there is code that causes a disruptive 
> failure when a MID or RID longer than 16 bytes occurs in the SDP.
>
> WebRTC's BUNDLE is, however, not the only user of the grouping 
> framework, so this doesn't guarantee that there isn't such an usage in 
> some other place - but this can't be checked by Chrome counters.
>
> The choices available to me as an implementor (short term) are:
>
> A - Return an error on set*Description that attempts to set a MID > 16 
> bytes (my preference, needs to be a standard change)
>
> B - Silently ignore attempts to set MIDs > 16 bytes (less disruptive 
> than current behavior)
>
> C - Do B, but add a comment to the code saying "TODO() - implement 
> support for 256 byte MIDs (low priority bug)"
>
> D - Leave the current behavior
>
> I do agree that new restrictions should be preceded with counters 
> (except where there is a security issue) - but this isn't a new 
> restriction, it's trying to document an existing one.
>
> On 3/4/21 10:26 PM, Justin Uberti wrote:
>> I would argue that even without an enforced limit, things are 
>> already breaking out there silently as packets exceed some link MTU. 
>> So having a deterministic failure seems like
>> an improvement.
>>
>> That said, I agree it would be prudent to add some counter to Chrome 
>> first to ensure enforcing a 16 limit would be safe, and this should 
>> be performed for all SDP-defined values carried in RTP header extensions.
>>
>> On Thu, Mar 4, 2021 at 9:15 AM Sergio Garcia Murillo 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>>     A limit of 16bytes is more than enough (1 or 2 bytes is the max
>>     you should use).
>>
>>     However IMHO implementations should be ready to receive up to the
>>     maximum of the 2 header bytes header extensions (there is always
>>     crazy people out there).
>>
>>     Is there any similar limit for RID values?
>>
>>     Best regards
>>     Sergio
>>
>>
>>
>>     El jue., 4 mar. 2021 18:07, Paul Kyzivat <[email-masked]
>>     <mailto:[email-masked]>> escribió:
>>
>>         On 3/4/21 12:40 AM, Nils Ohlmeier wrote:
>>         > When Firefox started putting its original MID values of
>>         ‘mid0’, ‘mid1’ etc into the RTP header extension we received
>>         several complaints about wasting bytes on the wire. Because
>>         of that we switched to ‘0’, ‘1’, … to save bytes. So it seems
>>         everyone is interested in using as little bytes as possible
>>         for this.
>>         >
>>         > In other words: I believe 16 bytes should be enough.
>>
>>         I don't see any conceptual problem with imposing a limit. But
>>         when
>>         imposing a limit retroactively there is the potential for
>>         breaking some
>>         existing implementations in the wild. I think that is
>>         unlikely, but hard
>>         to verify.
>>
>>                 Thanks,
>>                 Paul
>>
>>         > Best
>>         >    Nils
>>         >
>>         >> On 3Mar, 2021, at 14:43, Martin Thomson <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>         >>
>>         >> What Justin said.
>>         >>
>>         >> Does anyone *need* more than 16 bytes?
>>         >>
>>         >> On Thu, Mar 4, 2021, at 08:55, Justin Uberti wrote:
>>         >>> We have limits on a lot of values for exactly this reason
>>         - UDP packets
>>         >>> have a finite length, and therefore when it comes to RTP
>>         packetization,
>>         >>> overly long values make things screech to halt.
>>         >>>
>>         >>> So I think defining such a limit would be a good idea,
>>         but I think
>>         >>> you'd have to reject it rather than ignore it to get
>>         deterministic
>>         >>> behavior (which seems like another upside to me).
>>         >>>
>>         >>> On Wed, Mar 3, 2021 at 1:43 PM Sergio Garcia Murillo
>>         >>> <[email-masked]
>>         <mailto:[email-masked]>> wrote:
>>         >>>> If length is >16, shouldn't the 2 byte header extension
>>         be used instead? that would allow mid values up to 256 bytes.
>>         >>>>
>>         >>>> Best regards
>>         >>>> Sergio
>>         >>>>
>>         >>>>
>>         >>>> El mié., 3 mar. 2021 22:40, Harald Alvestrand
>>         <[email-masked] <mailto:[email-masked]>> escribió:
>>         >>>>>
>>         >>>>> On 3/3/21 4:06 PM, Nils Ohlmeier wrote:
>>         >>>>>>> Am 3/3/21 um 06:31 schrieb Paul Kyzivat
>>         <[email-masked] <mailto:[email-masked]>>:
>>         >>>>>>>
>>         >>>>>>> On 3/3/21 3:51 AM, Harald Alvestrand wrote:
>>         >>>>>>>> I'm searching for the source of a max length limit
>>         on the "a=mid" attribute.
>>         >>>>>>>> I couldn't find it in RFC 5888 (grouping framework)
>>         or RFC 8843 (BUNDLE).
>>         >>>>>>>> Does anyone remember where it's supposed to be?
>>         >>>>>>>> (I have code that will insist that it should be 16
>>         bytes or less, but I'm trying to verify that this is the
>>         correct limit.)
>>         >>>>>>> Its defined as a token (from RFC4566/8866). And that is:
>>         >>>>>>>
>>         >>>>>>>   token = 1*(token-char)
>>         >>>>>>>
>>         >>>>>>> There is no upper limit on the length. You can't
>>         impose a limit for implementation convenience. But
>>         practically speaking it is limited by the length of the
>>         message body that contains it, so you could code using an
>>         offset+length into the message buffer.
>>         >>>>>> While the SDP side might be able to handle really long
>>         MID values I
>>         >>>>>> doubt the RTP header extension allow or support that.
>>         Maybe your 16
>>         >>>>>> byte length limitation comes from the RTP side?
>>         >>>>>
>>         >>>>> I found that it is impossible to encode an 1-byte RTP
>>         header extension
>>         >>>>> longer than 16 bytes (the length is a 4-bit field with
>>         a bias value of
>>         >>>>> 1). So in practice, it's an RTP restriction.
>>         >>>>>
>>         >>>>> I think Postel once advised that one should always have
>>         length limits -
>>         >>>>> "if you don't have a length limit, you just have an
>>         implementation
>>         >>>>> defined limit, and that's worse".
>>         >>>>>
>>         >>>>> So the next question (now that we've settled that the
>>         standards don't
>>         >>>>> impose one) is: Should the standards specify a limit?
>>         >>>>>
>>         >>>>> And the third question: if asked to handle a BUNDLEd
>>         connection where
>>         >>>>> the MID is > 16 bytes, is it reasonable to just ignore
>>         the over-long MID
>>         >>>>> value?
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>>>>
>>         >>>>>>
>>         >>>>>> Best
>>         >>>>>>    Nils
>>         >>>>>>
>>         >>>>>> _______________________________________________
>>         >>>>>> mmusic mailing list
>>         >>>>>> [email-masked] <mailto:[email-masked]>
>>         >>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>         <https://www.ietf.org/mailman/listinfo/mmusic>
>>         >>>>>
>>         >>>>> _______________________________________________
>>         >>>>> mmusic mailing list
>>         >>>>> [email-masked] <mailto:[email-masked]>
>>         >>>>> https://www.ietf.org/mailman/listinfo/mmusic
>>         <https://www.ietf.org/mailman/listinfo/mmusic>
>>         >>>> _______________________________________________
>>         >>>> mmusic mailing list
>>         >>>> [email-masked] <mailto:[email-masked]>
>>         >>>> https://www.ietf.org/mailman/listinfo/mmusic
>>         <https://www.ietf.org/mailman/listinfo/mmusic>
>>         >>> _______________________________________________
>>         >>> mmusic mailing list
>>         >>> [email-masked] <mailto:[email-masked]>
>>         >>> https://www.ietf.org/mailman/listinfo/mmusic
>>         <https://www.ietf.org/mailman/listinfo/mmusic>
>>         >>>
>>         >>
>>         >> _______________________________________________
>>         >> mmusic mailing list
>>         >> [email-masked] <mailto:[email-masked]>
>>         >> https://www.ietf.org/mailman/listinfo/mmusic
>>         <https://www.ietf.org/mailman/listinfo/mmusic>
>>         >
>>         > _______________________________________________
>>         > mmusic mailing list
>>         > [email-masked] <mailto:[email-masked]>
>>         > https://www.ietf.org/mailman/listinfo/mmusic
>>         <https://www.ietf.org/mailman/listinfo/mmusic>
>>         >
>>
>>         _______________________________________________
>>         mmusic mailing list
>>         [email-masked] <mailto:[email-masked]>
>>         https://www.ietf.org/mailman/listinfo/mmusic
>>         <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>     _______________________________________________
>>     mmusic mailing list
>>     [email-masked] <mailto:[email-masked]>
>>     https://www.ietf.org/mailman/listinfo/mmusic
>>     <https://www.ietf.org/mailman/listinfo/mmusic>
>>
>>
>> _______________________________________________
>> mmusic mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic