Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

[Eric Rescorla <[e-mail]>]

In my opinion, things should behave as follows. The semantics of the
indicators are:

tls-id     old ufrag                    new ufrag
------     --------------------------------------------------
none       No change                    ICE restart, same DTLS
old        ICE restart                  ICE restart, same DTLS
new        Error                        ICE restart, new DTLS

However, in all cases but one, the answer MUST match the offer. I.e., the
answer must
do an ICE restart iff the offer had one and a new DTLS connection iff the
offer had one.
However, if the answerer does not support tls-id, then it might respond to
a new tls-id
with no tls-id, which means it does not intend to make a new DTLS
connection. The offerer
can either accept that or tear everything down.

I agree that the specs do not currently make this clear

-Ekr





On Sat, Sep 2, 2017 at 10:51 PM, Christer Holmberg <
[e-mail]> wrote:

> Hi,
>
>
>
> >Yes. Indeed, that's the crux of the disagreement between JSEP and this
> document
>
>
>
> So, just to clarify: in your opinion, if an endpoint receives an
> offer/answer WITHOUT a tls-id, but with a NEW ufrag (read: ICE restart),
> the new urfag will NOT trigger a new DTLS association. Right?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
> On Sat, Sep 2, 2017 at 3:31 PM, Christer Holmberg <
> [e-mail]> wrote:
>
> Hi Ekr,
>
>
>
> What if the remote peer does not support/include the tls-id attribute?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* mmusic [mailto:[e-mail]] *On Behalf Of *Eric
> Rescorla
> *Sent:* 02 September 2017 22:36
> *To:* Bernard Aboba <[e-mail]>
> *Cc:* [e-mail]
> *Subject:* Re: [MMUSIC] DTLS-SDP and JSEP Conflicts
>
>
>
>
>
>
>
> On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba <[e-mail]>
> wrote:
>
> On Issue 1, Adam said:
>
>
>
> "
>
> 1.      (Issue 1c) The crux of the matter: does ICE restart cause DTLS to
> restart? The primary rationale outlined in RFC5245 for restarting ICE is
> changing the destination (IP address or port) of an ongoing media stream --
> which would commonly involve changing to a different physical device. While
> it would, in theory, be possible to transfer the TLS state associated with
> the connection between devices, this is rather cumbersome (and, as far as I
> know, not generally supported by TLS libraries). From that perspective, it
> is my opinion that the DTLS-SDP document is correct that an ICE restart
> necessitates a new DTLS connection; and I conclude that JSEP needs to
> change.
>
> "
>
>
>
> [BA] Agree that for consistency, it is best for an ICE restart to
> necessitate a new DTLS connection, since an ICE restart can result in
> connection to a different device (and the need for a new DTLS connection).
>
>
>
> I'm not persuaded by this: the primary reason for an ICE restart is not
> changing devices but rather trying to deal with topology changes and/or
> connectivity check failures. If you actually *do* change devices, then it's
> also quite probably you will have a new certificate fingerprint, in which
> case you will get a new DTLS connection in any case. In other words, tls-id
> should be used to say "I want a new DTLS connection in spite of the
> fingerprint being the same" (what JSEP says), not "I want to keep the DTLS
> connection even though I am doing an ICE restart"
>
>
>
> -Ekr
>
>
>
>
>
> On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach <[e-mail]> wrote:
>
> MMUSIC --
>
> [I will be posting a separate message to RTCWEB directing interested
> parties to discuss this issue on the MMUSIC mailing list]
>
> During the IESG review of draft-ietf-mmusic-dtls-sdp, EKR identified some
> conflicts between the procedures in DTLS-SDP and JSEP were identified. This
> note is an attempt to summarize them. I have also made an initial proposal,
> for each conflict, regarding which document needs to change, in and which
> way.
>
> Issue 1 (quoting EKR), which raises a couple of additional sub-issues:
>
> 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
>
> need 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.
>
>
>
> My observations/recommendations:
>
>    1. (Issue 1a) EKR is correct that the first sentence of the bullet
>    from JSEP needs to be removed so as to enable interoperation with non-JSEP
>    implementations.
>    2. (Issue 1b) Additionally the final sentence of that bullet ("If this
>    is an answer, the tls-id value, if present, MUST be the same as in the
>    offer") conflicts with the definition of tls-id ("the offerer and answerer
>    generate their own local 'tls-id' attribute values, and the combination of
>    both values identify the DTLS association"). In this case, the DTLS-SDP
>    document would appear to be correct (the fact that the two parties choose
>    different IDs is integral to the mechanism's design), so JSEP needs to
>    change.
>    3. (Issue 1c) The crux of the matter: does ICE restart cause DTLS to
>    restart? The primary rationale outlined in RFC5245 for restarting ICE is
>    changing the destination (IP address or port) of an ongoing media stream --
>    which would commonly involve changing to a different physical device. While
>    it would, in theory, be possible to transfer the TLS state associated with
>    the connection between devices, this is rather cumbersome (and, as far as I
>    know, not generally supported by TLS libraries). From that perspective, it
>    is my opinion that the DTLS-SDP document is correct that an ICE restart
>    necessitates a new DTLS connection; and I conclude that JSEP needs to
>    change.
>
>
>
> Issue 2 (quoting EKR):
>
> 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.
>
>
> (Issue 2) JSEP is aligned with draft-ietf-mmusic-sdp-bundle-negotiation-38,
> while DTLS-SDP does not. This is a largely aesthetic decision (although the
> JSEP/BUNDLE approach does save a tiny handful of bytes), but I think
> changing one document (DTLS-SDP) makes more sense than changing two. (I
> suspect the BUNDLE formulation more closely tracks consensus anyway).
>
>
>
> /a
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>