Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

From: Paul Kyzivat <[email-masked]>
Date: Thu, 1 Oct 2015 12:20:30 -0400

Inline...

On 9/29/15 6:27 PM, Roman Shpount wrote:
> On Tue, Sep 29, 2015 at 5:26 PM, Paul Kyzivat <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>         This proposal is good except that it is unclear how to deduce which
>         version of connection or setup attribute is supported by the
>         remote end
>         point. Without such indication there is a high chance that
>         remote end
>         point will not be able to correctly parse and process the
>         connection or
>         setup attribute with transport suffix.
>
>
>     Can you clarify what situation you are concerned about?
>
>     As long as we are defining behavior for cases that aren't currently
>     supported at all, then it is simply a matter of writing the specs
>     the way we want them.
>
>     Are you concerned with backward compatibility with implementations
>     in the wild?
>
>
> I am concerned about existing implementations which are currently in the
> wild. There are plenty of implementations that do support "setup"
> attribute for DTLS (including all the WebRTC enabled browsers). If
> existing "setup" attribute would be extended to include the protocol
> suffix it will not be properly handled by current implementations.

Yes, that is a potential issue with extending the syntax of an existing 
attribute that wasn't specified with a hook for extensions.

> If
> setup attribute is used with protocol prefix, it is unclear if it will
> be correctly recognized by the remote party.

Am I right that there is no rfc specifying use of the setup attribute 
with dtls? (The IANA registry only has rfc4145 covering TCP.)

Once we get RFCs in place for this we can assume that those who conform 
to the RFCs will support whatever is specified. Those that don't support 
the rfc defining the new attribute should must it.

I do recognize that there are pre-rfc implementations in the field and 
we need to avoid breaking them. But I think that could be handled by 
having existing implementations start using *both* for awhile to handle 
the transition.

> On the other hand we can definitely use protocol attribute syntax for
> the connection attribute for DTLS, since this behavior is not defined
> anywhere yet.
>
> Also, please let me know if you need a more detailed explanation of
> dtls_ufrag option and its rational or if you simply need more time to
> get it sorted out.

I haven't seen a clear explanation - just a couple of sentences in an email.

But as best I understand it, I find it disturbing. It entangles dtls 
with ICE, even though the two are separate layers.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Thu, 1 Oct 2015 15:32:03 -0400

On Thu, Oct 1, 2015 at 12:20 PM, Paul Kyzivat <[email-masked]> wrote:

> Am I right that there is no rfc specifying use of the setup attribute with
> dtls? (The IANA registry only has rfc4145 covering TCP.)
>

RFC 5763 seciont 5 (https://tools.ietf.org/html/rfc5763#section-5)
specifies how SDP setup attribute is used when DTLS association is
established. So, we are dealing with existing, standard compliant
implementations.

> But as best I understand it, I find it disturbing. It entangles dtls with
> ICE, even though the two are separate layers.

Let me try to explain this again:

The "dtls-ufrag" has little to do with ICE and exists in a completely
different layer. We can call this attribute "dtls-connection-id" if this
will makes it less spooky. The problem that I am trying to resolve with new
attribute is related to when new DTLS association needs to be established.
I would argue that original intent was, that new DTLS association needs to
be established on change of one of the end points or DTLS association setup
attributes (setup role or fingerprint).

Originally, end point change was detected based on transport 5-tuple
change. This, of cause, does not work for ICE, where 5-tuple is not known
in advance and all 5-tuples associated with the same ICE component should
be treated as the same connection. One option was to detect end point
change when ICE is used based on ICE ufrag change, but this does not work
either since ufrag can change due to ICE restart, but the same end points
will continue to communicate.

I would also argue that setting up new DTLS association on 5-tuple change
does not always work for non-ICE case either, since we can have an end
point which can initiate a re-INVITE when it detects the local IP changes
due to DHCP lease expiration or any other reason. This transport change
does not necessarily require DTLS association change, and new DTLS
handshake is undesirable since it will delay the media flow
re-establishment but several network round trips.

So, we need to detect when two new end-points are communicating and new
DTLS association needs to be setup. What we originally proposed is that end
point will simply tell that it is setting up a new session by using SDP
connection attribute or some renamed version of it.

What I am saying here is that end point cannot always identify if it needs
to setup a new DTLS association. The problem arises when new offer is
generated in response to an offerless INVITE. In such case, an end point
does not know if it is continuing to communicate with the same end-point or
if this offer is intended to be sent to a new end point.

There are two solution possible to this:

1. We specify that if an end points generates an offer in response to an
offer-less INVITE it should always assume it is communicating with a new
end point, it MUST add "connection:new" and MUST make sure that none of the
existing transports can be possibly reused for this new DTLS association by
allocating new IP:port for non ICE or a complete new set of ICE candidates
in case of ICE. This will work, but it is wasteful when offer-less INVITE
re-establishes connection between two existing end points. In such cases
additional ports will be consumed, TURN tunnels will be allocated, and time
spent on creating a DTLS session when all of this can be simply reused.

2. Instead of asking the end point which generates the offer to determine
if it is establishing a new DTLS association, we will ask the end point to
identify itself. So, instead of SDP connection attribute, an end point will
provide some sort of randomly generated end point identifier in the new
attribute (dtls-ufrag or dtls-connection-id). When the connection ID pair
stays the same, the existing DTLS association continues to run over the
negotiated transport. If one of the connection IDs changes, this would mean
new DTLS association would need to be established. This nicely uncouples
end point change identification from transport and makes negotiation follow
the original intent.

In case of response to an offer-less INVITE, an offer with the existing
connection ID will be generated. If this offer is sent to a new end point,
both end points will detect that new DTLS association is required due to
connection ID change of the answering end point. If this offer will be sent
to an end point which is already a part of the existing DTLS association,
no new DTLS association will be necessary, since both connection IDs will
stay the same.

This also gives us path to a more "strategic" solution in the future. DTLS
handshake can be extended to include the connection ID. Each DTLS handshake
can negotiate a association identifier similar to SSRC which can be used in
the all subsequent DTLS messages for this association. This way multiple
DTLS associations can be multiplexed over the single transport and each of
them can be tied to an m= line in offer/answer. This, of cause, is not part
of the current draft and is outside of MMUSIC chapter, but does provide a
natural extension path for DTLS in the future.

In general Christer and I are trying to understand if there is interest in
formalizing the dtls-connection-id option (more complex) or if we should
stick with SDP connection:new/existing attribute and force new DTLS
association always be established in response to offer-less INVITE (simpler
option but can waste resources).

Please let us know if these options need further clarification or if you
have any additional questions or opinions.
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Fri, 2 Oct 2015 06:20:42 +0000

Hi,

>>> If setup attribute is used with protocol prefix, it is unclear if it will
>> Am I right that there is no rfc specifying use of the setup attribute with dtls? (The IANA registry only has rfc4145 covering TCP.)
>
> RFC 5763 seciont 5 (https://tools.ietf.org/html/rfc5763#section-5) specifies how SDP setup attribute is used when DTLS association
> is established. So, we are dealing with existing, standard compliant implementations.

RFC 7345 (UDPTL-DTLS) also uses the same procedures, as does BFCPbis AFAIR.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 2 Oct 2015 10:56:03 -0400

I think there has been a screw up, in that the IANA SDP attributes 
registry has not been updated to reference these as uses of the attribute.

	Thanks,
	Paul

On 10/2/15 2:20 AM, Christer Holmberg wrote:
> _______________________________________________
> mmusic mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christer Holmberg <[email-masked]>
Date: Tue, 13 Oct 2015 18:24:17 +0000

Hi,

> I think there has been a screw up, in that the IANA SDP attributes registry has not been updated to reference these as uses of the attribute.

I guess we can fix that as part of the DTLS-SDP work.

Regards,

Christer

On 10/2/15 2:20 AM, Christer Holmberg wrote:
> Hi,
>
>>>> If setup attribute is used with protocol prefix, it is unclear if 
>>>> it will be correctly recognized by the remote party.
>>>
>>> Am I right that there is no rfc specifying use of the setup 
>>> attribute with dtls? (The IANA registry only has rfc4145 covering 
>>> TCP.)
>>
>> specifies how SDP setup attribute is used when DTLS association is established. So, we are dealing with existing, standard compliant implementations.
>