Re: DTLS-SDP and JSEP Conflicts

On Sun, Sep 3, 2017 at 1:31 PM, Christer Holmberg <
[email protected]> wrote:

> Hi,
>
>
>
> >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
>
>
>
> Because that’s not how the procedures are currently written.
>

Again, JSEP and this document are in conflict, hence it's unclear.



> Now, based on your suggestion, if the offerer doesn’t know whether the
> answerer supports tls-id, does that mean that the only way for the offerer
> to ensure that the re-offer will trigger a new DTLS association is by
> modifying the fingerprint set in the offer?
>

That's true in any case, because we have implementations which behave that
way and we can't change them.



> And, if the offerer does not change the fingerprint set, does not receive
> tls-id in the answer, and chooses to “accept” it, would the offerer then
> still start using (in subsequent offers/answers etc) the new tls-id, even
> if a new DTLS association was not created?
>

I'm not sure it matters, as in this case the answerer doesn't care about
tls-id.

-Ekr


> OR, would the offerer consider the new tls-id “rejected” by the answerer,
> and continue using the old tls-id?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
>
>
>
>
>
>
>
>
>
>
> On Sat, Sep 2, 2017 at 10:51 PM, Christer Holmberg <
> [email protected]> 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 <
> [email protected]> wrote:
>
> Hi Ekr,
>
>
>
> What if the remote peer does not support/include the tls-id attribute?
>
>
>
> Regards,
>
>
>
> Christer
>
>
>
> *From:* mmusic [mailto:[email protected]] *On Behalf Of *Eric
> Rescorla
> *Sent:* 02 September 2017 22:36
> *To:* Bernard Aboba <[email protected]>
> *Cc:* [email protected]
> *Subject:* Re: [MMUSIC] DTLS-SDP and JSEP Conflicts
>
>
>
>
>
>
>
> On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba <[email protected]>
> 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 <[email protected]> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
> _______________________________________________
> mmusic mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>
>
>
>
>
>

_______________________________________________
mmusic mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/mmusic