Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Sep 2017 14:35:59 -0600

On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba <[email-masked]>
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-masked]> 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-masked]
>> https://www.ietf.org/mailman/listinfo/mmusic
>>
>>
>
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>
>

---

From: Christer Holmberg <[email-masked]>
Date: Sat, 2 Sep 2017 21:31:37 +0000

Hi Ekr,

What if the remote peer does not support/include the tls-id attribute?

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Eric Rescorla
Sent: 02 September 2017 22:36
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

On Tue, Aug 29, 2017 at 7:07 AM, Bernard Aboba <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>> 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.

   o  DTLS setup role; or

   o  fingerprint set; or

   o  ICE ufrag value

need not be present:

   ...

      channel.

  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

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

_______________________________________________
mmusic mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/mmusic

---

From: Eric Rescorla <[email-masked]>
Date: Sat, 2 Sep 2017 16:00:13 -0600

Yes. Indeed, that's the crux of the disagreement between JSEP and this
document

-Ekr

On Sat, Sep 2, 2017 at 3:31 PM, Christer Holmberg <
[email-masked]> wrote:

> *From:* mmusic [mailto:[email-masked]] *On Behalf Of *Eric
> Rescorla
> *Sent:* 02 September 2017 22:36
> *To:* Bernard Aboba <[email-masked]>
> *Cc:* [email-masked]
> *Subject:* Re: [MMUSIC] DTLS-SDP and JSEP Conflicts
>
>
>
>
>
>
>
>    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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 3 Sep 2017 05:51:42 +0000

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-masked]<mailto:[email-masked]>> wrote:
Hi Ekr,

Regards,

Christer

From: mmusic [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Eric Rescorla
Sent: 02 September 2017 22:36
To: Bernard Aboba <[email-masked]<mailto:[email-masked]>>
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

"

-Ekr

MMUSIC --

   o  DTLS setup role; or

   o  fingerprint set; or

   o  ICE ufrag value

need not be present:

   ...

      channel.

Issue 2 (quoting EKR):

2. S 4 says:

/a

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Sep 2017 12:59:34 -0700

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

-Ekr

On Sat, Sep 2, 2017 at 10:51 PM, Christer Holmberg <
[email-masked]> wrote:

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

---

From: Christer Holmberg <[email-masked]>
Date: Sun, 3 Sep 2017 20:31:38 +0000

Hi,

>In my opinion, things should behave as follows. The semantics of the indicators are:
>
>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

Because that’s not how the procedures are currently written.

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?

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?

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-masked]<mailto:[email-masked]>> wrote:
Hi,

Regards,

Christer

Regards,

Christer

"

-Ekr

MMUSIC --

   o  DTLS setup role; or

   o  fingerprint set; or

   o  ICE ufrag value

need not be present:

   ...

      channel.

Issue 2 (quoting EKR):

2. S 4 says:

/a

---

From: Eric Rescorla <[email-masked]>
Date: Sun, 3 Sep 2017 13:56:25 -0700

> 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

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 4 Sep 2017 10:14:28 +0000

Hi,

>>>indicators are
 
>> Because that¹s not how the procedures are currently written.
>
 
>> 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.

On GitHub you also suggested
(https://github.com/cdh4u/draft-dtls-sdp/issues/37) that the answerer,
even if it supports tls-id, shall not be able to trigger a new DTLS
association (read: change the tls-id value). I assume that means the
answerer would not be able to change its fingerprint set either, or do
anything else that would trigger a new DTLS association?

Regards,

Christer

 
On Sat, Sep 2, 2017 at 10:51 PM, Christer Holmberg
<[email-masked]> wrote:

Hi,

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

Hi Ekr,

Regards,
 
Christer
 
From: mmusic [mailto:[email-masked]]
On Behalf Of Eric Rescorla
Sent: 02 September 2017 22:36
To: Bernard Aboba <[email-masked]>
Cc: [email-masked]
Subject: Re: [MMUSIC] 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.
"

 

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

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 withthe
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'tincredibly clear on this point, but 5.7.3 seems to say that
tls-idneed 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 clearlycan'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, thesetwo documents clearly must match.

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: Eric Rescorla <[email-masked]>
Date: Mon, 4 Sep 2017 04:07:48 -0700

Yes, that seems like the logical extension of this. Note that this is only
in the edge case
where the offerer offers an ICE restart, because if the offerer does not,
we all agree that
you need to keep the existing fingerprint.

-Ekr

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 4 Sep 2017 10:37:20 -0400

> anything else that would trigger a new DTLS association?

Why would you want to *prevent* the answerer from triggering a new DTLS 
association???

	Thanks,
	Paul

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Sep 2017 07:41:00 -0700

> Why would you want to *prevent* the answerer from triggering a new DTLS

As noted previously, it's confusing and it's only possible at all in the
edge case where the offerer offers an ICE restart but not a new DTLS
association.

-Ekr

        Thanks,

---

From: Roman Shpount <[email-masked]>
Date: Mon, 4 Sep 2017 23:48:54 -0400

> edge case where the offerer offers an ICE restart but not a new DTLS
The main reason new DTLS association can started by the answering party is
third party call control. The new DTLS association will be required if as a
result of the offer/answer exchange two new end points ends up being
connected with each other by a third party call control agent. This is a
fairly common scenario. If it is not supported interoperability with
existing implementations will be seriously affected. Please note that in
existing specification new DTLS association can already be started by the
answerer changing fingerprints, transport parameters, or setup role.

As far as possible implementation options are concerned there are two
possible solutions:

a. Always require a new DTLS association whenever an offer is generated in
the response to a request for a new offer (INVITE with no SDP in case of
SIP). This will match ICE behavior where new ICE restart is required in
such case. This is workable, but is excessive and will generate new DTLS
association establishment when it is not required. This is why we preferred
the currently described solution.

b. Allow answering party to force a new DTLS association by changing
dtls-id. This is something that will address third party call control case,
since new end point will generate a new tls-id. This also removes unneeded
DTLS associations if third party call control ends up connecting to the
same end point (which happens more often then expected due to 3pcc agents
doing connectivity checks).

This is why I would strongly prefer to leave current specification as it is.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Mon, 4 Sep 2017 21:03:13 -0700

> answerer changing fingerprints, transport parameters, or setup role.

Well, as has been noted, the current specification is fairly unclear (I
feel comfortable saying that as one of the authors), but as a practical
matter, this only works if you already are doing an ICE restart. Is that
what is happening in this instance?

-Ekr

---

From: Roman Shpount <[email-masked]>
Date: Tue, 5 Sep 2017 00:16:14 -0400

On Tue, Sep 5, 2017 at 12:03 AM, Eric Rescorla <[email-masked]> wrote:

>> The main reason new DTLS association can started by the answering party
>> is third party call control. The new DTLS association will be required if
>> as a result of the offer/answer exchange two new end points ends up being
Current specification is not very specific about ICE. It does allow
answerer to start a new DTLS association even if ICE restart is not
initiated. I am not sure how this will work in all the cases, but it
definitely works for third party call control, which, as far as I am
concerned, is the only useful use case of answerer triggering a new DTLS
association. ICE restart is required in case of the new offer generated in
response to INVITE with no SDP. Because of this, answerer can successfullu
establish a new DTLS association by changing fingerprints. And, since
answerer is a new end point, ICE candidate pair nominated for transport
will end up to be a new distinct 5-tuple so new and old DTLS associations
can be easily demuxed. So, in some sense, current specification works
almost by accident.

I would really like for this to continue to work since this is being used.

Regards,
_____________
Roman Shpount

---

From: Eric Rescorla <[email-masked]>
Date: Thu, 7 Sep 2017 07:25:42 -0700

On Mon, Sep 4, 2017 at 9:16 PM, Roman Shpount <[email-masked]> wrote:

>>>>> Why would you want to *prevent* the answerer from triggering a new
>>>>> DTLS association???
>>>>>
>>>>
>>>> As noted previously, it's confusing and it's only possible at all in
>>>> the edge case where the offerer offers an ICE restart but not a new DTLS
>>>> association.
>>>>
>>>>
> establish a new DTLS association by changing fingerprints.
>

Well, to recap, ICE restart can only be initiated by the offerer:
https://tools.ietf.org/rfcmarkup?doc=5245#section-9.2.2

And as we discussed in detail, there's no real way to demux without an ICE
restart, so I'm not interested in trying to preserve that case in the
situations when it happens to work. In general, the offerer can simply
offer a new tls-id if it's willing to accept a new TLS connection. I
appreciate that this will also cause a TLS association even when the
endpoints haven't changed, but this just doesn't seem like that big a deal.

If you have a specific case in mind that this causes a problem for, I'd
need to see a call-flow diagram to understand it.

-Ekr

And, since answerer is a new end point, ICE candidate pair nominated for
> transport will end up to be a new distinct 5-tuple so new and old DTLS
> associations can be easily demuxed. So, in some sense, current
> specification works almost by accident.
>

---

From: Roman Shpount <[email-masked]>
Date: Thu, 7 Sep 2017 14:10:48 -0400

> need to see a call-flow diagram to understand it.
There are two specific scenarios that concern me:

1. Third Party Call Control

a. End point A is connected to end point B through third party call control
agent 3PCC
b. 3PCC sends a request for a new offer to A (using SIP INVITE with no SDP
body).
c. End point A sends an offer with ICE restart (required in response to
INVITE with no SDP) and existing tls-id
d. 3PCC agent sends this offer as a new call offer to end point C
e. This is a new offer for C, so it sends an answer with a new tls-id to
3PCC
f. 3PCC sends an answer to end point A
g. Since A got an answer with a new tls-id, a new DTLS association is
established between A and C

This also has an optional case, when end point C is legacy and it does not
send back tls-id attribute, but does send new fingerprint values. I would
prefer that new implementations were allowed for the same scenario using
tls-id.

Note that in step d, 3PCC can also send the  re-offer back to B, which will
result in existing DTLS association reuse. This is very common when session
timers are implemented by 3PCC agents.

2. Connection Recovery

a. End point is connected to a service (like conference service) which is
comprised from multiple redundant media servers behind a single signaling
proxy
b. End point detects a network connectivity disruption via keep-alive
timeout
c. End point initiates connection recovery process by generating an offer
with ICE restart and existing DTLS association (and media settings) and
sends it to the signaling proxy
d. If the network connectivity is restored to the same media server via a
different network path, for instance due to client address change, existing
DTLS association and media are re-used
e. If connectivity failure was due to media server failure, connectivity is
restored but to a different media server. New DTLS  association and media
connection is established in this case.

Please note that case d is much less common then case e.

In both cases it is possible to make things work by forcing new tls-id
value in the offer. This will result in extra DTLS association, local ICE
candidate allocations (which are required if new DTLS association is
requested via new tls-id), and new media setup. All of those things will
waste resources and more importantly will increase connection setup time.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 12 Sep 2017 07:20:59 +0000

OK, how do we move forward? Silence won’t do it. Can people live with the current text?

(Version –30 was submitted last week, with the ufrag change removed from the list in section 4.)

Regards,

Christer

From: mmusic <[email-masked]<mailto:[email-masked]>> on behalf of Roman Shpount <[email-masked]<mailto:[email-masked]>>
Date: Thursday 7 September 2017 at 21:10
To: Eric Rescorla <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [MMUSIC] DTLS-SDP and JSEP Conflicts

On Thu, Sep 7, 2017 at 10:25 AM, Eric Rescorla <[email-masked]<mailto:[email-masked]>> wrote:

And as we discussed in detail, there's no real way to demux without an ICE restart, so I'm not interested in trying to preserve that case in the situations when it happens to work. In general, the offerer can simply offer a new tls-id if it's willing to accept a new TLS connection. I appreciate that this will also cause a TLS association even when the endpoints haven't changed, but this just doesn't seem like that big a deal.

If you have a specific case in mind that this causes a problem for, I'd need to see a call-flow diagram to understand it.

a. End point A is connected to end point B through third party call control agent 3PCC
b. 3PCC sends a request for a new offer to A (using SIP INVITE with no SDP body).
c. End point A sends an offer with ICE restart (required in response to INVITE with no SDP) and existing tls-id
d. 3PCC agent sends this offer as a new call offer to end point C
e. This is a new offer for C, so it sends an answer with a new tls-id to 3PCC
f. 3PCC sends an answer to end point A
g. Since A got an answer with a new tls-id, a new DTLS association is established between A and C

This also has an optional case, when end point C is legacy and it does not send back tls-id attribute, but does send new fingerprint values. I would prefer that new implementations were allowed for the same scenario using tls-id.

Note that in step d, 3PCC can also send the  re-offer back to B, which will result in existing DTLS association reuse. This is very common when session timers are implemented by 3PCC agents.

2. Connection Recovery

a. End point is connected to a service (like conference service) which is comprised from multiple redundant media servers behind a single signaling proxy
b. End point detects a network connectivity disruption via keep-alive timeout
c. End point initiates connection recovery process by generating an offer with ICE restart and existing DTLS association (and media settings) and sends it to the signaling proxy
d. If the network connectivity is restored to the same media server via a different network path, for instance due to client address change, existing DTLS association and media are re-used
e. If connectivity failure was due to media server failure, connectivity is restored but to a different media server. New DTLS  association and media connection is established in this case.

In both cases it is possible to make things work by forcing new tls-id value in the offer. This will result in extra DTLS association, local ICE candidate allocations (which are required if new DTLS association is requested via new tls-id), and new media setup. All of those things will waste resources and more importantly will increase connection setup time.

Regards,
_____________
Roman Shpount