Re: DTLS-SDP and JSEP Conflicts

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

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