Re: 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