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

My apologies; that was meant to go to Eric, and not the list; obviously I
am shy of caffeine.  I will remedy that while I experience shame.

Ted

On Thu, Mar 3, 2016 at 3:21 PM, Ted Hardie <ted.ietf@gmail.com> wrote:

> Howdy,
>
> On Thu, Mar 3, 2016 at 3:05 PM, Eric Rescorla <ekr@rtfm.com> 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
>> mmusic@ietf.org
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>