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

[Ted Hardie <[e-mail]>]

Howdy,

On Thu, Mar 3, 2016 at 3:05 PM, Eric Rescorla <[e-mail]> wrote:

> I’ve been going over draft-ietf-mmusic-dtls-sdp-10 and would like to
> suggest some changes.
>
> Here are my starting assumptions:
>
>
>    -
>
>    We do want the ability to do an ICE restart without a DTLS reconnect.
>    -
>
>    It’s not safe to do a DTLS reconnect without an ICE restart (and new
>    transport parameters) because you would need to demux the connections.
>    -
>
>    Although RFC 5763 says that ICE restart implies a DTLS reconnect,
>    that’s not something people actually do.
>    -
>
>    There are cases where people want to do a DTLS reconnect without
>    changing fingerprints.
>
>
Can you unpack what these cases are?  I'm a little worried with the
interaction with ICE, especially in the convergence case described in 6.7.1
of RFC 5763.  That already gives a case where the IP address associated
with a DTLS handshake can shift; in a reconnect, is this supported?


>
>    -
>
>    It needs to be safe to repeatedly apply the same description (e.g.,
>    setLocalDescription() idempotently) in WebRTC.
>
>
> Accordingly, I think we can get away with a something simpler:
>
>
>    -
>
>    Remove the requirement in RFC 5763 to DTLS reconnect on ICE restart.
>    -
>
>    A DTLS reconnect is required if *either*
>    -
>
>       The fingerprint changes
>
>
If it is not changing on reconnect, what causes it to change?  Someone
explicitly calling SetRemoteFingerprint?



>
>    -
>
>       A (TBD, see below) indicator indicator is in the SDP
>       -
>
>    Require that if a DTLS reconnect is done for any reason you also do an
>    ICE restart and it’s an error to have either of the two conditions above
>    without also changing the ICE credentials.
>
>
> I believe this meets all the actual use cases while discarding the legacy
> use cases that are in protocol documents but not actually implemented.
>
>
> Assuming you are comfortable with the above, I think the indicator we want
> is some sort of “connection-id” parameter, either as a standalone value or
> as a value which is unique in association with the fingerprint. This seems
> cleaner than having a “new” versus “reuse” token. The semantics would be
> that if you see a new identifier that means you need to form a new
> association but that multiple replays of the same identifier mean that you
> reuse the same association (i.e., do not DTLS reconnect).
>
> This resolves the idempotency concern that present with the existing
> proposal, and also makes backwards compatibility simpler; a change in
> either a=fingerprint or a=dtls-connection-id will trigger a new DTLS
> connection.
>
> What do people think of this?
>

Off-list because I don't want to rock a boat that's moving, but I don't
think this message motivated the change that well.


> -Ekr
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>