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

[Roman Shpount <[e-mail]>]

On Wed, Aug 16, 2017 at 7:06 PM, Adam Roach <[e-mail]> wrote:

> Section 5.4 says:
>
>    NOTE: A new DTLS association can be established based on changes in
>    either an SDP offer or answer.  When communicating with legacy
>    endpoints, an offerer can receive an answer that includes the same
>    fingerprint set and setup role.  A new DTLS association MUST still be
>    established if such an answer was received as a response to an offer
>    which requested the establishment of a new DTLS association.
>
> Unless I've misunderstood something important, this isn't going to work
> with
> legacy implementations, unless you also specify that an "offer which
> requested
> the establishment of a new DTLS association" must also change something
> else
> that the legacy answerer will recognize as requiring a new DTLS
> association.
> For example, if I send a re-offer with a changed tls-id but the same
> fingerprint, setup, and transport, the far end will have no reason to
> think it
> needs to establish a new DTLS association. So I'll sit there waiting for a
> new
> association to be established, and the remote side will never send one.
>
> This doesn't seem backwards-compatible. At the very least, more text needs
> to
> be added explaining how this is intended to work.
>

The intention was to specify that an offering party sends an offer with new
value of tls-id, it can get back an answer without tls-id, unchanged remote
fingerprint values and setup role . In this case new DTLS association MUST
be established.

As you have correctly mentioned, tls-id can be changed with no changes in
fingerprints, but current specification requires changing the transport
parameters whenever tls-id is changed. The transport parameter change
should cause new DTLS association to be established, even if remote is a
legacy end point. In this case, even if remote legacy end point responds
with existing fingerprints, transport parameters and setup role, it is
safer to assume that new DTLS association should be established.


> I agree with the core assertion of EKR's DISCUSS: this document needs to be
> aligned with JSEP. I think we're going to need a little additional work
> figuring out which document needs to change where they disagree. In
> addition to
> those areas he highlights in his DISCUSS, the following text is also in
> conflict:
>
> DTLS-SDP: "the offerer and answerer generate their own local 'tls-id'
> attribute
> values, and the combination of both values identify the DTLS association."
>
> JSEP: "If this is an answer, the tls-id value, if present, MUST be the
> same as
> in the offer."
>

JSEP needs to be adjusted in this case. Specification does not work if
tls-id is reflected in the answer. Different tls-id in the answer are used
to disambiguate multiple DTLS associations in case of forking.

_____________
Roman Shpount