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

From: Roman Shpount <[email-masked]>
Date: Tue, 15 Aug 2017 19:58:54 -0400

Eric,

Thank you for your comments.

On Tue, Aug 15, 2017 at 7:07 PM, Eric Rescorla <[email-masked]> 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.

> 2. S 4 says:
>
>    The mux category [I-D.ietf-mmusic-sdp-mux-attributes] for the 'tls-
>    id' attribute is 'IDENTICAL', which means that the attribute value
>    must be identical across all media descriptions being multiplexed
>    [I-D.ietf-mmusic-sdp-bundle-negotiation].
>
> This is not actually what JSEP requires:
>
>    different categories.  To avoid unnecessary duplication when
>    bundling, attributes of category IDENTICAL or TRANSPORT MUST NOT be
>    repeated in bundled m= sections, repeating the guidance from
>    [I-D.ietf-mmusic-sdp-bundle-negotiation], Section 8.1.  This includes
>
> I suspect this is old text.
>

This is old text and should be corrected

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.

4. The demux instructions seem to have gotten lost from 6.7.1. At minimum
> these need a reference to RFC 7983.
>

We will add the reference to ICE considerations section.

> 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.

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.

> 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.

Regards,
______________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Tue, 15 Aug 2017 17:09:16 -0700

+Juberti, Cullen

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

> 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

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.

> 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.

> There are implementations that do this to avoid unauthenticated media.

Fair enough.

S 10.
> This is the best we came up with so far. If you have a better option,

Please provide a summary of what's changed.

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 23 Aug 2017 10:02:37 +0000

Hi Ekr,

Thanks for your comments!

We¹ll deal with the JSEP alignment issue separately, and Roman has
addressed your other comments. A few additions from me below.

> This is the best we came up with so far. If you have a better option,

We can add a few words about what has been changed.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 25 Aug 2017 11:05:12 +0000

Cullen/Justin, do you have some input on this?

Regards,

Christer

From: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Date: Wednesday 16 August 2017 at 03:09
To: Roman Shpount <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Flemming Andreasen <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Justin Uberti <[email-masked]<mailto:[email-masked]>>, Cullen Jennings <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] Eric Rescorla's Discuss on draft-ietf-mmusic-dtls-sdp-28: (with DISCUSS and COMMENT)
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: Christer Holmberg <[email-masked]<mailto:[email-masked]>>
Resent-Date: Wednesday 16 August 2017 at 03:10

+Juberti, Cullen

On Tue, Aug 15, 2017 at 4:58 PM, Roman Shpount <[email-masked]<mailto:[email-masked]>> wrote:
Eric,

On Tue, Aug 15, 2017 at 7:07 PM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:
1. Assuming I understand this document correctly, it conflicts with
the guidance in JSEP. Specifically, S 4 says:

   o  DTLS setup role; or

   o  fingerprint set; or

   o  ICE ufrag value

   ...

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:

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.

Fair enough.

S 10.

This is the best we came up with so far. If you have a better option, please suggest.

S 9.
   Regardless of the

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.

-Ekr

Regards,
______________
Roman Shpount