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

[Roman Shpount <[e-mail]>]

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

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


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.



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


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