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

[Roman Shpount <[e-mail]>]

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.


> 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