Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)

[Eric Rescorla <[e-mail]>]

+Juberti, Cullen

On Tue, Aug 15, 2017 at 4:58 PM, Roman Shpount <[e-mail]> wrote:

> Eric,
>
> Thank you for your comments.
>
> On Tue, Aug 15, 2017 at 7:07 PM, Eric Rescorla <[e-mail]> wrote:
>
>> 1. Assuming I understand this document correctly, it conflicts with
>> the guidance in JSEP. Specifically, S 4 says:
>>
>>    No default value is defined for the SDP 'tls-id' attribute.
>>    Implementations that wish to use the attribute MUST explicitly
>>    include it in SDP offers and answers.  If an offer or answer does not
>>    contain a 'tls-id' attribute (this could happen if the offerer or
>>    answerer represents an existing implementation that has not been
>>    updated to support the 'tls-id' attribute), unless there is another
>>    mechanism to explicitly indicate that a new DTLS association is to be
>>    established, a modification of one or more of the following
>>    characteristics MUST be treated as an indication that an endpoint
>>    wants to establish a new DTLS association:
>>
>>    o  DTLS setup role; or
>>
>>    o  fingerprint set; or
>>
>>    o  local transport parameters; or
>>
>>    o  ICE ufrag value
>>
>> This seems to say that if there is no tls-id attribute, then an ICE
>> restart
>> (which necessitates a ufrag change) requires a DTLS restart. JSEP isn't
>> incredibly clear on this point, but 5.7.3 seems to say that tls-id
>> neeed not be present:
>>
>>       *  tls-id value, which MUST be set according to
>>          [I-D.ietf-mmusic-dtls-sdp], Section 5.  If this is a re-offer
>>          and the tls-id value is different from that presently in use,
>>          the DTLS connection is not being continued and the remote
>>          description MUST be part of an ICE restart, together with new
>>          ufrag and password values.  If this is an answer, the tls-id
>>          value, if present, MUST be the same as in the offer.
>>
>> I believe that the first sentence is in error, as we clearly
>> can't have JSEP implementations requiring that tls-id be present.
>>
>>    ...
>>
>>    o  If the remote DTLS fingerprint has been changed or the tls-id has
>>       changed, tear down the DTLS connection.  This includes the case
>>       when the PeerConnection state is "have-remote-pranswer".  If a
>>       DTLS connection needs to be torn down but the answer does not
>>       indicate an ICE restart or, in the case of "have-remote-pranswer",
>>       new ICE credentials, an error MUST be generated.  If an ICE
>>       restart is performed without a change in tls-id or fingerprint,
>>       then the same DTLS connection is continued over the new ICE
>>       channel.
>>
>> I think the best interpretation of this is that if tls-id is not present
>> (and hence unchanged) then ICE restart does not cause DTLS restart.
>> This is also my memory of the consensus in RTCWEB. In any case, these
>> two documents clearly must match.
>>
>
> In regard to ICE ufrag change without tls-id we just have to make a
> choice. Both choices are bad since they both cause things to break when one
> side would initiate new DTLS association and another side would not. I
> would agree that not starting DTLS association on ICE restart is slightly
> safer.  In any case, tls-id is needed to avoid this ambiguity. For anything
> compliant with the new draft, tls-di must be present.
>

I agree that going forward we need this. My sense is that the JSEP version
is better,
but I've CCed Cullen and Justin to see what they think.




>
> 3. S 7.1 says:
>>    If DTLS is transported on top of a connection-oriented transport
>>    protocol (e.g., TCP or SCTP), where all IP packets are acknowledged,
>>
>> This is incorrect, because none of these protocols ack all IP packets.
>>
>>
>>    all DTLS packets associated with a previous DTLS association MUST be
>>    acknowledged (or timed out) before a new DTLS association can be
>>    established on the same instance of that transport (5-tuple).
>>
>> More generally, I'm not sure that this is useful, because the
>> required semantic isn't *acknowledged* but rather that the receiver
>> can appropriately demux. So, say you just stop sending DTLS on
>> connection A and start sending on B, what's the delimiter, given
>> that you don't require close_notify here? IIRC, we just decided to
>> punt on this whole thing. Does anyone try to have successive
>> connections over the same transport, even when it's connection oriented?
>>
>
>
> Please see my comment to Mirja Kühlewind regarding this. This text is here
> because somebody thought this draft should cover DTLS-over-SCTP. Since you
> are one of the authors of RFC6083, can you suggest what is appropriate
> here for DTLS-over-SCTP implementations? My preference would be not to
> cover DTLS-over-SCTP in this draft and limit it to only DTLS over UDP or
> TCP.
>

I agree with you. I don't think it's helpful to cover this here. Is this a
question for the
WG.



> S 5.1.
>>    media session immediately (see [RFC8122]).  Note that it is
>>    permissible to wait until the other side's fingerprint(s) has been
>>    received before establishing the connection; however, this may have
>>    undesirable latency effects.
>>
>> I agree that it's permissible, but why would you do this? This does
>> not seem like helpful guidance.
>>
>
> There are implementations that do this to avoid unauthenticated media.
>

Fair enough.


S 10.
>> Please do something about the "NEW" constructions. I literally had to
>> pull these into ediff to know what had changed. That's not useful to
>> people. I'm not a fan of this construction in general, but at minimum
>> you need to explain what has changed.
>>
>
> This is the best we came up with so far. If you have a better option,
> please suggest.
>

Please provide a summary of what's changed.



>
>> S 9.
>>    Regardless of the
>>    previous existence of a DTLS association, the SDP 'setup' attribute
>>    MUST be included according to the rules defined in [RFC4145] and if
>>    ICE is used, ICE restart MUST be initiated.
>>
>> What is the rationale for this rule?
>>
>
> This just restates the requirement from https://tools.ietf.org/
> html/rfc5245#section-12.5 . Not doing so breaks third party call control,
> since in this case it is not known if this offer is intended for an
> existing connection or to establish connection with a new end point.
>

A citation here would help.

-Ekr


>
> Regards,
> ______________
> Roman Shpount
>