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

[Harald Alvestrand <[e-mail]>]

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 
> <[e-mail] 
> <mailto:[e-mail]>> 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 <[e-mail]
>     <mailto:[e-mail]>> 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 <[e-mail]
>         <mailto:[e-mail]>> 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
>         >>> <[e-mail]
>         <mailto:[e-mail]>> 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
>         <[e-mail] <mailto:[e-mail]>> escribió:
>         >>>>>
>         >>>>> On 3/3/21 4:06 PM, Nils Ohlmeier wrote:
>         >>>>>>> Am 3/3/21 um 06:31 schrieb Paul Kyzivat
>         <[e-mail] <mailto:[e-mail]>>:
>         >>>>>>>
>         >>>>>>> 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
>         >>>>>> [e-mail] <mailto:[e-mail]>
>         >>>>>> https://www.ietf.org/mailman/listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >>>>>
>         >>>>> _______________________________________________
>         >>>>> mmusic mailing list
>         >>>>> [e-mail] <mailto:[e-mail]>
>         >>>>> https://www.ietf.org/mailman/listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >>>> _______________________________________________
>         >>>> mmusic mailing list
>         >>>> [e-mail] <mailto:[e-mail]>
>         >>>> https://www.ietf.org/mailman/listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >>> _______________________________________________
>         >>> mmusic mailing list
>         >>> [e-mail] <mailto:[e-mail]>
>         >>> https://www.ietf.org/mailman/listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >>>
>         >>
>         >> _______________________________________________
>         >> mmusic mailing list
>         >> [e-mail] <mailto:[e-mail]>
>         >> https://www.ietf.org/mailman/listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >
>         > _______________________________________________
>         > mmusic mailing list
>         > [e-mail] <mailto:[e-mail]>
>         > https://www.ietf.org/mailman/listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>         >
>
>         _______________________________________________
>         mmusic mailing list
>         [e-mail] <mailto:[e-mail]>
>         https://www.ietf.org/mailman/listinfo/mmusic
>         <https://www.ietf.org/mailman/listinfo/mmusic>
>
>     _______________________________________________
>     mmusic mailing list
>     [e-mail] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/mmusic
>     <https://www.ietf.org/mailman/listinfo/mmusic>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic