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

[Christer Holmberg <[e-mail]>]

So, alphanumeric it is :)

From: Justin Uberti [mailto:[e-mail]]
Sent: 09 March 2016 06:35
To: Roman Shpount <[e-mail]>
Cc: Christer Holmberg <[e-mail]>; Paul Kyzivat <[e-mail]>; [e-mail]
Subject: Re: [MMUSIC] Thoughts on draft-ietf-mmusic-dtls-sdp-10 semantics

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]<mailto:[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]<mailto:[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]<mailto:[e-mail]>>
Date: Tuesday 8 March 2016 at 06:24
To: Justin Uberti <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Christer Holmberg <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[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]<mailto:[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]<mailto:[e-mail]>> wrote:

On Mon, Mar 7, 2016 at 12:21 PM, Paul Kyzivat <[e-mail]<mailto:[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]>
<mailto:[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