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

[Paul Kyzivat <[e-mail]>]

Christer,

Comments inline.

On 9/18/15 2:48 AM, Christer Holmberg wrote:
> Hi,
>
> Currently the draft-ietf-mmusic-dtls-sdp defines the usage of existing
> SDP "connection" attribute for DTLS. The attribute is used to explicitly
> indicate whether a new DTLS association shall be created or not.
>
> One of the open questions is whether we should use existing "connection"
> attribute for this purpose, define a new attribute (working name:
> "dtls_connection") with similar semantics, or design a new usage which
> is more robust in cases of 3PCC.
>
> Why would we use a different attribute?
>
> In most cases (e.g. UDP/DTLS) existing "connection" attribute works
> well. However, if you layer other connection oriented protocols over
> DTLS (e.g. ‘SCTP/DTLS’ or ‘UDP/DTLS/SCTP’) "connection" attribute would
> apply to both the SCTP *and* DTLS layer. This might be an acceptable
> usage, but are there use cases when DTLS connection would need to be
> re-established, but SCTP connection still maintained?
>
> There are also more exotic use cases, when DTLS is layered over
> connection oriented protocols (e.g. ‘TCP/DTLS/SCTP’). In such cases
> "connection" attribute would apply to the SCTP *AND* the DTLS *AND* the
> TCP layer.
>
> Having a dedicated attribute would allow separate control over the DTLS
> layer. E.g. in the case of ‘UDP/DTLS/SCTP’ it would be possible to
> re-establish the SCTP association without touching the DTLS association.

The fundamental problem here is that what is specified in the "protocol" 
field of the m-line is really a protocol stack, not just a single 
protocol. The sdp attributes (and other m-line elements, and 
non-attribute media-level properties) provide parameters for the 
"protocol" assuming there is just one.

When there is more than one protocol in the stack that must be 
parameterized, there has to be some way to associate the attribute with 
the intended protocol in the stack.

Sometimes this just works out, because a given property is only 
meaningful for one protocol in the stack. But that doesn't always work, 
as in this case. Then there is need for some sort of work-around.

One work-around, such as you are suggesting, is to assign different 
names for the property, that bind it to a particular protocol.

Note we had a similar problem with SCTP over DTLS over UDP because both 
of SCTP and UDP need a port number. There we ended up with using the 
port in the m-line for one (UDP) and using an sctp-specific attribute 
for the SCTP port. (And then this introduces an inconsistency with SCTP 
directly over IP.)

Ideally SDP would have a way to provide attributes separately to each 
level in the protocol hierarchy. But is that possible without reviving 
SDPng?

Just thinking on the fly:

m=application 54111 UDP/DTLS/SCTP webrtc-datachannel
c=IN IP4 192.0.2.1
a=protocol:UDP/DTLS/SCTP setup:actpass
a=protocol:UDP/DTLS/SCTP connection:new
a=protocol:UDP/DTLS/SCTP port:5000
a=protocol:UDP/DTLS/SCTP max-message-size:100000
a=protocol:UDP/DTLS setup:active
a=protocol:UDP/DTLS connection:existing

So a=protocol:XYZ becomes a prefix qualifying which protocol the 
following attribute applies to. For convenience and backward 
compatibility, in the absence of the protocol qualifier, the attribute 
would apply to each protocol in the stack where it has meaning.

(Note that port is still a hack. But I have suggested generalizing it 
beyond sctp-oort.)

The advantage of this is that it is a single mechanism that can be used 
to address multiple problems of this sort. It appears to me that we will 
can expect to see more of those in the future. One-off solutions aren't 
very appealing.

> Another option is to define a "ufrag" which identifies an end point in
> DTLS association (working name: "dtls_ufrag"). Each endpoint in the
> offer/answer exchange would generate its own "dtls-ufrag". If either
> "dtls-ufrag" values changed, then new DTLS association would need to be
> established.
>
> Why would we need something like this?
>
> ICE and 3PCC and oferless INVITEs. When ICE end point responds to an
> offer-less INVITE, it will allocate new ufrag, collects the full set of
> ICE candidates, but would still like to keep the existing DTLS
> connection and local ICE candidates which it is currently using. It will
> send the response with the generated answer with all this information,
> but the value for old style "connection" SDP attribute is unclear. If
> value "connection:new" is specified, none of the existing ICE candidates
> can be used, complete new set would need to be allocated to prevent
> transport pair reuse for multiple DTLS associations, and new DTLS
> association would need to be created even if the same two end-points get
> reconnected. If value "connection:existing" is used, then existing DTLS
> association and candidates can be used, but the generated offer cannot
> be used as an initial offer to the new end point.
>
> If "dtls_ufrag" value is used, then in response to offer-less invite the
> existing value of this attribute will be provided in the generated
> offer. The answering party, if it is an end point which is already
> communicating with the current end-point can respond with its current
> "dtls_ufrag" value and the existing DTLS association will be re-used. If
> answering party is a new end point which was not part of the existing
> DTLS association, it will reply with new value of "dtls_ufrag". Since
> one of the values changed, a new DTLS association will be established.
> There is no risk of transport re-use for several DTLS associations,
> since answering party will allocate a complete new set of ICE candidates.

I still haven't got my head around this.

	Thanks,
	Paul

> What do you prefer, wasting resource in response to offer-less invite
> and allocating a complete new set of ICE candidates every time such
> INVITE is receive or dealing with a more complex attribute semantics?
>
> Comments? Preferences?
>
> Regards,
>
> Christer
>
>
>
> _______________________________________________
> mmusic mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mmusic
>