Re: DTLS-SDP and JSEP Conflicts

Hi,

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

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

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

Hi Ekr,
 
What if the remote peer does not support/include the tls-id attribute?
 
Regards,
 
Christer
 
From: mmusic [mailto:[email protected]]
On Behalf Of Eric Rescorla
Sent: 02 September 2017 22:36
To: Bernard Aboba <[email protected]>
Cc: [email protected]
Subject: Re: [MMUSIC] 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 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.

 
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