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

From: Christer Holmberg <[email-masked]>
Date: Fri, 18 Sep 2015 06:48:17 +0000

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.

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.

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

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 25 Sep 2015 16:06:48 -0400

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.
>
> 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.
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mmusic
>

---

From: Christian Groves <[email-masked]>
Date: Tue, 29 Sep 2015 16:29:29 +1000

Hello Christer,

I'm for keeping it simple and having a specific dtls_connection attribute.

Regards, Christian

On 18/09/2015 4:48 PM, Christer Holmberg wrote:
> 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.
>
> 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?
>
> "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.
>
> "dtls-ufrag" values changed, then new DTLS association would need to 
> be established.
>
> 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 
> "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.
>

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Tue, 29 Sep 2015 08:23:33 +0000

Hello Christer,

there might be another approach by qualifying the "generic" attribute with protocol (stack) information.
Paul made a good proposal as far as I remember:

see
Re: [MMUSIC] SCTP-SDP: SDP connection attribute considerations
http://www.ietf.org/mail-archive/web/mmusic/current/msg14156.html 

=> a=setup ... and "And do the same thing for a=connection."

Regards,
Albrecht

-----Original Message-----
From: mmusic [mailto:[email-masked]] On Behalf Of Christian Groves
Sent: Dienstag, 29. September 2015 08:29
To: [email-masked]
Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

Hello Christer,

Regards, Christian

On 18/09/2015 4:48 PM, Christer Holmberg wrote:
> DTLS (e.g. 'SCTP/DTLS' or 'UDP/DTLS/SCTP') "connection" attribute 
> connection oriented protocols (e.g. 'TCP/DTLS/SCTP'). In such cases 
> DTLS layer. E.g. in the case of 'UDP/DTLS/SCTP' it would be possible

---

From: Roman Shpount <[email-masked]>
Date: Tue, 29 Sep 2015 15:40:16 -0400

> => a=setup ... and "And do the same thing for a=connection."
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.

Regards,
_____________
Roman Shpount

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Sep 2015 17:26:19 -0400

On 9/29/15 3:40 PM, Roman Shpount wrote:
> On Tue, Sep 29, 2015 at 4:23 AM, Schwarz, Albrecht (Albrecht)
> <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     there might be another approach by qualifying the "generic"
>     attribute with protocol (stack) information.
> 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?

	Thanks,
	Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 29 Sep 2015 17:36:41 -0400

BTW: in addition to the proposal Gunnar mentions:

in a more recent message I offered another way to do same thing:

   http://mailarchive.ietf.org/arch/msg/mmusic/uhTpEitCbI9x5oIoDU4MAfcEJW0

The latter is a more general mechanism. But I think the issues are 
largely the same with either one.

	Thanks,
	Paul

---

From: Roman Shpount <[email-masked]>
Date: Tue, 29 Sep 2015 18:27:34 -0400

On Tue, Sep 29, 2015 at 5:26 PM, Paul Kyzivat <[email-masked]> wrote:

> 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. If setup attribute is used
with protocol prefix, it is unclear if it will be correctly recognized by
the remote party.

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.

Regards,
_____________
Roman Shpount

---

From: Christer Holmberg <[email-masked]>
Date: Wed, 30 Sep 2015 07:38:42 +0000

Hi,

The scope of the document is to define generic SDP offer/answer procedures for DTLS. That includes re-using/clarifying the existing procedures in DTLS-SRTP as much as possible, and make some technical changes (mainly related to how/if a change transport address information affects a DTLS association), and define an attribute that can be used to explicitly indicate whether to create a new DTLS association.

The intention is NOT to change the existing setup attribute, or do to anything else.

Regards,

Christer

From: mmusic [mailto:[email-masked]] On Behalf Of Roman Shpount
Sent: 30. syyskuuta 2015 1:28
To: Paul Kyzivat
Cc: [email-masked]
Subject: Re: [MMUSIC] DTLS-SDP: connection, dtls_connection, or dtls_ufrag?

On Tue, Sep 29, 2015 at 5:26 PM, Paul Kyzivat <[email-masked]<mailto:[email-masked]>> wrote:

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. If setup attribute is used with protocol prefix, it is unclear if it will be correctly recognized by the remote party.

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.

Regards,
_____________
Roman Shpount