Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

[Roman Shpount <[e-mail]>]

We need to make sure dtls-association-id works in cases of 3pcc where a new
session can be connected to an existing session or two existing sessions
can be connected with each other. In all of those cases new DTLS
association must be established. The case of merging two existing sessions
especially worry me if we chose monotonically increasing IDs. Imagine two
sessions, each hitting IVR for an announcement, and then being connecting
directly with each other. If monotonically increasing from zero ID is used,
both sessions will have dtls-association-id=1, but clearly a new session
would need to be established.

I think in general monotonically increasing IDs have a high chance of
collision when unrelated end points are used. Randomly assigned IDs are
safer in this regard.

Another option is to state that dtls-association-id should be unique for a
given security certificate fingerprint. So if new certificate is created
for each DTLS association, then dtls-association-id can stay at value 0 or
be omitted. If certificate is reused a unique value should be used for each
new DTLS association created with this certificate. This uniqueness can be
achieved by using a counter associated with each self signed certificate or
using sufficiently large random or pseudo random (server id + time stamp +
per server counter would be an example of the pseudo random) value
associated with pre-provisioned permanent certificates.

Does anybody else have any suggestions or concerns about
dtls-association-id generation scheme?
______________
Roman Shpount

On Mon, Mar 7, 2016 at 9:15 PM, Justin Uberti <[e-mail]> wrote:

> Keep in mind that this id value isn't actually sent anywhere. So it's not
> like the ICE ufrag that needs a certain amount of entropy. It can just as
> easily be a monotonically increasing number.
>
> IOW, a string with a 1-byte minimum seems right.
>
> On Mon, Mar 7, 2016 at 10:26 AM, Roman Shpount <[e-mail]> wrote:
>
>>
>> On Mon, Mar 7, 2016 at 12:21 PM, Paul Kyzivat <[e-mail]>
>> wrote:
>>
>>> On 3/7/16 12:12 PM, Roman Shpount wrote:
>>>
>>>> On Mon, Mar 7, 2016 at 11:52 AM, Paul Kyzivat <[e-mail]
>>>> <mailto:[e-mail]>> wrote:
>>>>
>>>>     On 3/7/16 11:26 AM, Christer Holmberg wrote:
>>>>
>>>>         I suggest dtls-association-id. In my opinion there is no longer
>>>>         the same
>>>>         need to be aligned with the name of the connection attribute.
>>>>
>>>>
>>>>     This seems plausible. But I want to reserve judgement until the
>>>>     detailed semantics of the attribute are worked out:
>>>>
>>>> I wanted to model this attribute on ICE ufrag
>>>>
>>>>     - is it numeric, or a token?
>>>>
>>>>
>>>> I was thinking something like this:
>>>> dtls-association-id-attr = "dtls-association-id" ":" dtls-association-id
>>>>
>>>> dtls-association-id = 4*256dtls-association-id-char
>>>>
>>>> dtls-association-id-char = ALPHA / DIGIT / "+" / "/"
>>>>
>>>
>>> Why this in particular? Is it your intent to reuse values that were
>>> generated for another purpose? Or to reuse code that is also used for
>>> another purpose?
>>
>>
>> This is reusing the definition (and generation code) from ice-ufrag
>> attribute (https://tools.ietf.org/html/rfc5245#section-15.4).
>>
>>     - any rules for how the value chosen?
>>>>
>>>>
>>>> The dtls-association-id attributes MUST be chosen randomly when new DTLS
>>>> association is requested.  The dtls-association-id attribute MUST
>>>> contain at least 24 bits of randomness.  This means that
>>>> the dtls-association-id  attribute will be at least 4 characters
>>>> long since the grammar for this attribute allows for 6 bits of
>>>> randomness per character.  The attribute MAY be longer than 4
>>>> characters, respectively, of course, up to 256 characters.  The upper
>>>> limit allows for buffer sizing in implementations.  Its large upper
>>>> limit allows for increased amounts of randomness to be added over time.
>>>>
>>>
>>> What is the reason for using random values, rather than some well
>>> defined sequence of values? (Where the sequence might start with a random
>>> value, or perhaps every sequence would start with 0.)
>>>
>>
>> We are dealing with multiple end points which can be reconnected in more
>> or less random order. Each end point needs to detect when it is talking to
>> a new end point or to a new DTLS association. This is why I picked a random
>> value. Once again, if this works for ICE, should work for DTLS just as well.
>>
>> Let me know if you have a better idea for ID generation.
>>
>> Regards,
>> _____________
>> Roman Shpount
>>
>>
>
>