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

[Justin Uberti <[e-mail]>]

I think the id should be alphanumeric, but how it is assigned can be left
to the application.


On Tue, Mar 8, 2016 at 4:59 PM, Roman Shpount <[e-mail]> wrote:

> I would make the dtls-association-id value random alphanumeric to keep it
> shorter.
>
> I would also make dtls-association-id optional if any of the fingerprints
> is for a newly generated self-signed certificate which will not be reused
> for any other DTLS association.
>
> Regards,
>
> _____________
> Roman Shpount
>
> On Tue, Mar 8, 2016 at 2:54 AM, Christer Holmberg <
> [e-mail]> wrote:
>
>> Hi,
>>
>> There is no need to track the “order” of DTLS associations, so I think we
>> should use random value. I am not sure we need “+” and “-“. Would a numeric
>> value be enough? The number of DTLS associations between the connected
>> endpoints is going to be very small, so we shouldn’t over-engineer it.
>>
>> Regarding the id being unique for a given fingerprint, keep in mind that
>> we now allow multiple fingerprints.
>>
>> Regards,
>>
>> Christer
>>
>> From: Roman Shpount <[e-mail]>
>> Date: Tuesday 8 March 2016 at 06:24
>> To: Justin Uberti <[e-mail]>
>> Cc: "[e-mail]" <[e-mail]>, Christer Holmberg <
>> [e-mail]>, "[e-mail]" <[e-mail]>
>> Subject: Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics
>>
>> 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
>>>>
>>>>
>>>
>>>
>>
>