Subject: [MMUSIC] DTLS-SDP and JSEP Conflicts

From: Adam Roach <[email-masked]>
Date: Fri, 25 Aug 2017 15:30:14 -0500

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

---

From: Roman Shpount <[email-masked]>
Date: Fri, 25 Aug 2017 17:39:23 -0400

On Fri, Aug 25, 2017 at 4:30 PM, Adam Roach <[email-masked]> wrote:

>
>    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.
>
>
> This is a really thorny issue which does not have a good solution. Correct
handling of ufrag change is one of the main reasons why tls-id draft was
written in the first place. Here is a little bit more background on the
problem:

1. If ICE restart was caused by 3pcc and resulted in connection to a new
device, new DTLS association is required. In some cases, connection to a
new device will also result in the new fingerprint set. In some cases (like
transfer withing the same organization which uses the same pre-provisioned
certificate), fingerprints will stay the same and only ufrag will change.
So, this means new DTLS association should be established if ufrag changes
due to device change.

2. If ICE restart is initiated when new network interfaces became
available, such as when WiFi became available on the mobile device. This
means that both existing candidates and new candidates can be present
during ICE restart. This also means, that in some situations, even though
ICE restart completes, the underlying transport does not have to change and
the same ICE candidate pair will be used after ICE restart. Since this is
the same ICE candidate pair, it will mean that packets from old and new
DTLS association can be received over the same 5-tuple and they cannot be
demultiplexed. This means DTLS association should stay the same even if
ufrag changes due to ICE restart but when end points plans to re-use ICE
candidates.

So, we have two situations which both will result in some interop problems
regardless of which decision we will make. Taking into account that most of
existing ICE with DTLS implementations use ephemeral certificates, 3pcc
will likely result in change of both ufrag and fingerprints. Because of
this, I think not establishing new DTLS association on ufrag change is a
safer option. Which means JSEP text is probably a safer option, especially
where WebRTC is concerned.

This being said, going forward tls-id should be used to make sure this is
resolved in unambiguous manner.

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Fri, 25 Aug 2017 17:47:23 -0500

On 8/25/17 4:39 PM, Roman Shpount wrote:
>
> This is a really thorny issue which does not have a good solution. 
> Correct handling of ufrag change is one of the main reasons why tls-id 
> draft was written in the first place. Here is a little bit more 
> background on the problem:
>
> 1. If ICE restart was caused by 3pcc and resulted in connection to a 
> new device, new DTLS association is required. In some cases, 
> connection to a new device will also result in the new fingerprint 
> set. In some cases (like transfer withing the same organization which 
> uses the same pre-provisioned certificate), fingerprints will stay the 
> same and only ufrag will change. So, this means new DTLS association 
> should be established if ufrag changes due to device change.
>
> available, such as when WiFi became available on the mobile device. 
> This means that both existing candidates and new candidates can be 
> present during ICE restart. This also means, that in some situations, 
> even though ICE restart completes, the underlying transport does not 
> have to change and the same ICE candidate pair will be used after ICE 
> restart. Since this is the same ICE candidate pair, it will mean that 
> packets from old and new DTLS association can be received over the 
> same 5-tuple and they cannot be demultiplexed. This means DTLS 
> association should stay the same even if ufrag changes due to ICE 
> restart but when end points plans to re-use ICE candidates.

I hate to throw new engineering into the document at this point, but 
shouldn't it be possible to distinguish between these two circumstances 
by examining the candidates and determining whether they're completely 
new (versus having at least one in common with the existing connection)? 
This means that you won't know whether to restart DTLS until trickling 
has ended (for trickle), but you can solve that by not doing aggressive 
(or passive-aggressive) nomination -- just wait until you have all the 
candidates before you start connecting.

Does that sound like it would work?

/a

---

From: Roman Shpount <[email-masked]>
Date: Fri, 25 Aug 2017 19:23:08 -0400

On Fri, Aug 25, 2017 at 6:47 PM, Adam Roach <[email-masked]> wrote:

> shouldn't it be possible to distinguish between these two circumstances by
> examining the candidates and determining whether they're completely new
> (versus having at least one in common with the existing connection)? This
> means that you won't know whether to restart DTLS until trickling has ended
> (for trickle), but you can solve that by not doing aggressive (or
> passive-aggressive) nomination -- just wait until you have all the

This will theoretically work, but can delay DTLS association setup in case
of tricket ICE past the point of being usable.

More importantly this is not how existing implementations work. They simply
do not start new DTLS association on ufrag change. This is for legacy
interop only, so we might as well do what legacy end points do and ignore
ufrag.

Regards,
_____________
Roman Shpount

---

From: Adam Roach <[email-masked]>
Date: Fri, 25 Aug 2017 18:28:25 -0500

On 8/25/17 6:23 PM, Roman Shpount wrote:
> More importantly this is not how existing implementations work. They 
> simply do not start new DTLS association on ufrag change. This is for 
> legacy interop only, so we might as well do what legacy end points do 
> and ignore ufrag.

This seems pretty compelling, as arguments go.

/a

---

From: Taylor Brandstetter <[email-masked]>
Date: Fri, 25 Aug 2017 16:32:10 -0700

I think I'm just echoing Roman at this point, but might as well send the
email since I already wrote it.

> (Issue 1c) The crux of the matter: does ICE restart cause DTLS to
> which would commonly involve changing to a different physical device.

The purpose of section 4 is to describe what should happen for an "existing
implementation that has not been updated to support the 'tls-id'
attribute", correct? And existing WebRTC implementations do *not* create a
new DTLS association upon ICE restarts. In my experience, ICE restarts are
mostly used to restore connectivity when network interfaces change, not to
transfer a call to a new endpoint. So I'd say the "ICE ufrag value" bullet
in section 4 should be removed.

> means that you won't know whether to restart DTLS until trickling has
> ended (for trickle), but you can solve that by not doing aggressive (or

If I understand correctly, you're saying "wait until trickling has ended,
and use a new DTLS association if the list of candidates is completely new,
and old association if it contains an old candidate"? That doesn't work for
a couple reasons:

   1. The list may be completely new, but the endpoint may still want to
   use the existing DTLS association. This is what existing WebRTC
   implementations do. They continue sending media over the old candidate pair
   while they're doing an ICE restart, but they don't trickle the old
   candidate again.
   2. It could take a long time to tell that trickling ended, which would
   delay media. It would defeat a large part of the benefit of trickle ICE.

On Fri, Aug 25, 2017 at 4:28 PM, Adam Roach <[email-masked]> wrote:

>> legacy interop only, so we might as well do what legacy end points do and
>> ignore ufrag.
>>
>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Aug 2017 06:49:26 +0000

Hi,

>I suspect this is old text.

Correct, and it has been fixed in the IESG-review PR I have submitted.

Regards,

Christer

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Aug 2017 07:10:39 +0000

Hi,

So, does anyone *OBJECT* to the remove-ufrag-from-section-4 proposal? I
assume Justin and Cullen would be ok with it, since it is what JSEP does,
but it would still be nice to hear them say that :)

I assume we could still keep section 3.3, but we should remove the ³(see
Section 4)² part. Because, section 3.3 does not say that a ufrag change
triggers a new DTLS association, it simply says that if one changes the
ufrag AND wants to create a new DTLS association, the tls-id must be
changed.

We could also clarify section 3.3:

   "If an endpoint uses ICE, and modifies a local ufrag value, and if the
   modification requires a new DTLS association, the endpoint MUST
   change its local SDP 'tls-id' attribute value, <new> as a modification
of 
   the local ufrag value does not itself trigger a new DTLS association
</new>"

Regards,

Christer

From:  mmusic <[email-masked]> on behalf of Taylor Brandstetter
<[email-masked]>
Date:  Saturday 26 August 2017 at 02:32
To:  "[email-masked]" <[email-masked]>
Cc:  "[email-masked]" <[email-masked]>
Subject:  Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

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

The purpose of section 4 is to describe what should happen for an
"existing implementation that has not been updated to support the 'tls-id'
attribute", correct? And existing WebRTC implementations do not create a
new DTLS association upon ICE restarts.
 In my experience, ICE restarts are mostly used to restore connectivity
when network interfaces change, not to transfer a call to a new endpoint.
So I'd say the "ICE ufrag value" bullet in section 4 should be removed.

I hate to throw new engineering into the document at this point, but
shouldn't it be possible to distinguish between these two circumstances by
examining the candidates and determining whether they're completely
 new (versus having at least one in common with the existing connection)?
This means that you won't know whether to restart DTLS until
 trickling has ended (for trickle), but you can solve that by not doing
aggressive (or passive-aggressive) nomination -- just wait until you have
all the candidates before you start connecting.

If I understand correctly, you're saying "wait until trickling has ended,
and use a new DTLS association if the list of candidates is completely
new, and old association if it contains an old candidate"? That doesn't
work for a couple reasons:

1. The list may be completely new, but the endpoint may still want to use
the existing DTLS association. This is what existing WebRTC
implementations do. They continue sending media over the old candidate
pair while they're doing an ICE restart, but they don't
 trickle the old candidate again.

On Fri, Aug 25, 2017 at 4:28 PM, Adam Roach
<[email-masked]> wrote:

/a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Aug 2017 10:12:23 +0000

Hi Adam,

I don’t know if you left the following out by mistake, if you assumed the issue had been solved, or if I simply missed it, but just in case:

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

As I said earlier (and I think others who have commented agree) this needs to be fixed in JSEP.

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Date: Friday 25 August 2017 at 23:30
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [MMUSIC] DTLS-SDP and JSEP Conflicts

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.

   o  DTLS setup role; or

   o  fingerprint set; or

   o  ICE ufrag value

   ...

  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:

(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

---

From: Adam Roach <[email-masked]>
Date: Mon, 28 Aug 2017 12:39:33 -0500

On 8/28/17 5:12 AM, Christer Holmberg wrote:
> Hi Adam,
>
> I don’t know if you left the following out by mistake, if you assumed 
> the issue had been solved, or if I simply missed it, but just in case:
>

That was my "Issue 1b":

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

/a

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 28 Aug 2017 19:26:03 +0000

Hi,

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

Correct. My mistake.

Regards,

Christer

---

From: Bernard Aboba <[email-masked]>
Date: Tue, 29 Aug 2017 09:07:59 -0400

On Issue 1, Adam said:

"

"

[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-masked]> wrote:

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